VS Code 느려졌을 때 원인 찾는 순서

VS Code가 갑자기 느려졌을 때 가장 흔한 대응은 재시작이고, 그다음은 확장을 몇 개 지워보는 것이다. 둘 다 원인을 모른 채 하는 일이라 다시 느려지면 또 반복하게 된다. VS Code에는 무엇이 느리게 만드는지 직접 알려주는 도구가 여러 개 들어 있다. 이 글은 그 도구들을 순서대로 써서 원인을 좁히는 방법을 다룬다.

먼저 확장 때문인지 아닌지부터 가른다

원인의 상당수는 확장이다. 그래서 첫 단계는 "확장이 원인인가"를 가르는 것이다. 방법은 확장 없이 한 번 띄워 보는 것이다.

code --disable-extensions

문서가 안내하는 그대로다. 이 상태에서 멀쩡하면 확장 문제이고, 여전히 느리면 확장은 범인이 아니다. 이 한 줄로 탐색 범위가 절반으로 준다.

확장이 원인이라는 것까지 알았다면 다음은 어느 확장인가다. 하나씩 껐다 켜는 대신 VS Code가 이분 탐색을 대신해 준다. F1을 누르고 Help: Start Extension Bisect를 실행하면, 문서 설명대로 "설치된 확장에 이진 탐색을 수행해 일부를 비활성화하고 창을 다시 로드한 뒤 문제가 여전한지 묻는다". 몇 번 답하면 범인을 지목해 준다.

확장이 스무 개면 하나씩 확인할 때 최대 스무 번이지만, 이분 탐색이면 다섯 번이면 끝난다. 이 기능을 알기 전에는 손으로 껐다 켰는데, 그 시간이 아깝다.

어느 확장이 시간을 쓰는지 숫자로 본다

범인을 지목하기 전에 정황을 먼저 보고 싶다면 두 가지 화면이 있다.

F1에서 Developer: Show Running Extensions를 실행하면 "실행 중인 모든 확장이 담긴 편집기가 열린다". 여기에는 각 확장의 활성화 시각과 소요 시간이 표시된다. 활성화에 수백 밀리초 이상 쓰는 확장이 있으면 눈에 띈다. 이 화면에서 확장별로 프로파일링을 시작할 수도 있다.

시작이 유독 느리다면 F1에서 Startup Performance를 실행한다. 문서 표현으로는 "시작 성능 상세 정보가 담긴 편집기를 연다". 창이 뜨기까지 어느 단계에서 시간을 썼는지 단계별로 나온다. 확장 활성화가 오래 걸렸는지, 워크스페이스를 읽는 데 오래 걸렸는지가 구분된다.

여기서 자주 드러나는 것이 언어 서버다. 타입스크립트, 파이썬, 자바처럼 프로젝트 전체를 분석하는 확장은 큰 저장소에서 CPU를 오래 쓴다. 이건 버그가 아니라 원래 하는 일이라, 확장을 지우는 대신 분석 범위를 줄이는 쪽으로 가야 한다.

프로세스 단위로 무엇이 CPU를 먹는지 본다

VS Code는 여러 프로세스로 돌아간다. 창 하나에 렌더러 프로세스, 확장 호스트 프로세스, 파일 감시 프로세스, 각 언어 서버 프로세스가 따로 있다. 그래서 "VS Code가 느리다"는 말은 사실 어느 프로세스가 느리다는 뜻인지 좁혀야 한다.

Help > Open Process Explorer를 열면 문서 설명대로 "계속 갱신되는 VS Code 프로세스 목록이 담긴 새 창"이 뜬다. 각 프로세스의 CPU와 메모리가 보이고, 이름으로 어떤 확장의 서버인지 알 수 있다. 터미널에서 스냅샷을 뜨려면 code --status를 쓴다.

여기서 특정 언어 서버가 CPU를 계속 100% 쓰고 있다면 그 언어의 설정을 손봐야 한다. 확장 호스트가 튀면 확장 문제이고, 렌더러가 튀면 에디터 자체의 렌더링 문제다.

렌더러가 문제일 때는 한 단계 더 들어갈 수 있다. F1에서 Toggle Developer Tools를 열고 Performance 탭에서 기록을 시작한 뒤, 문서 권장대로 "30초에서 60초 정도 프로파일링하고" 멈춘다. 크롬 개발자 도구와 같은 화면이라 익숙한 사람이면 바로 읽을 수 있다.

파일 감시와 검색 범위가 조용히 자원을 먹는다

확장도 아니고 언어 서버도 아닌데 느린 경우, 파일 개수를 의심해야 한다.

VS Code는 워크스페이스의 파일 변경을 감시한다. node_modules, dist, .venv, target 같은 폴더에 파일이 수만 개 있으면 이 감시만으로 CPU와 메모리가 상당히 나간다. 프로젝트를 열어두기만 해도 노트북 팬이 도는 상황이 이것이다.

해결은 감시에서 빼는 것이다. 워크스페이스 설정에 넣는다.

{
  "files.watcherExclude": {
    "**/node_modules/**": true,
    "**/dist/**": true,
    "**/build/**": true,
    "**/.venv/**": true,
    "**/target/**": true
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/*.min.js": true
  }
}

files.watcherExclude는 감시를 줄이고, search.exclude는 검색 대상을 줄인다. 둘은 별개 설정이라 양쪽 다 넣어야 한다. 검색이 느리다면 후자가, 그냥 열어두기만 해도 느리다면 전자가 효과가 크다.

큰 파일 하나가 원인인 경우도 있다. 수만 줄짜리 로그나 압축되지 않은 번들 파일을 에디터로 열면 구문 강조와 토큰화 때문에 버벅인다. 이럴 때는 언어별 설정으로 토큰화 한계를 낮추거나, 아예 구문 강조를 끄는 편이 낫다.

{
  "[log]": { "editor.largeFileOptimizations": true },
  "[javascript]": { "editor.maxTokenizationLineLength": 2500 }
}

확장을 지우는 것이 늘 답은 아니다

느려진 원인이 확장으로 밝혀지면 지우고 싶어진다. 나는 지우기 전에 두 가지를 먼저 시도한다.

하나는 워크스페이스 단위로 비활성화하는 것이다. 확장 목록에서 톱니를 누르면 전역과 워크스페이스 중에 골라 끌 수 있다. 자바 확장이 필요한 프로젝트와 필요 없는 프로젝트가 섞여 있다면, 필요 없는 쪽에서만 끄는 것이 맞다. 전역으로 지우면 다음에 그 언어를 만질 때 다시 깔아야 한다.

다른 하나는 설정으로 범위를 줄이는 것이다. 앞서 말한 언어 서버가 대표적이다. 타입스크립트라면 tsconfig.json의 include를 좁히고, 파이썬이라면 분석 대상 경로를 지정한다. 확장이 느린 게 아니라 시켜놓은 일이 많은 것이라면, 일을 줄이는 게 정답이다.

정말로 지워야 하는 확장도 있다. 기능이 겹치는 확장이 여러 개 깔린 경우다. 포매터가 두 개, 린터가 두 개 있으면 저장할 때마다 서로 결과를 덮어쓰며 싸운다. 느린 것보다 나쁜 건 결과가 매번 달라지는 것이다. 겹치는 것은 하나만 남겨야 한다.

창을 여러 개 여는 것과 폴더를 여러 개 두는 것은 다르다

프로젝트 여러 개를 동시에 볼 때 두 가지 방법이 있는데, 자원 소모가 꽤 다르다.

창을 여러 개 띄우면 창마다 렌더러 프로세스와 확장 호스트 프로세스가 따로 뜬다. 언어 서버도 창마다 하나씩이다. 타입스크립트 프로젝트 창을 세 개 열어두면 타입스크립트 서버도 세 개가 돌면서 각각 메모리를 잡는다.

멀티 루트 워크스페이스는 창 하나에 폴더를 여러 개 붙이는 방식이다. 프로세스가 하나로 공유되므로 메모리 면에서 유리하다. 다만 확장 설정이 워크스페이스 단위로 섞이고, 폴더마다 다른 언어 버전을 써야 하는 경우에는 오히려 꼬인다.

기준은 이렇다. 함께 보며 오가는 프로젝트라면 멀티 루트, 서로 무관한 프로젝트라면 별도 창이 맞다. 무관한 것들을 한 창에 밀어 넣으면 검색 결과에 엉뚱한 프로젝트 파일이 섞여 나와서 오히려 불편하다.

메모리가 계속 불어나는 느낌이라면 Process Explorer에서 창별 프로세스 수부터 세어 보자. 안 쓰는 창을 닫는 것만으로 해결되는 경우가 생각보다 많다.

정리하면 순서는 이렇다

느려졌을 때 나는 이 순서로 확인한다.

1. code --disable-extensions로 확장 여부를 가른다
2. 확장이면 Help: Start Extension Bisect로 범인을 찾는다
3. Developer: Show Running Extensions로 활성화 시간을 본다
4. Help > Open Process Explorer로 어느 프로세스가 CPU를 먹는지 본다
5. 확장이 아니면 files.watcherExclude와 search.exclude를 점검한다
6. 시작이 느리면 Startup Performance를 본다

이 순서의 요점은 추측하지 않는다는 것이다. "확장이 많아서겠지" 하고 지우기 시작하면 필요한 것까지 지우고도 원인을 모른 채 끝난다. 도구가 숫자를 보여주니 그걸 먼저 보면 된다.

참고 자료

• Performance Issues — microsoft/vscode Wiki — Extension Bisect, Startup Performance, Show Running Extensions, Process Explorer, 렌더러 프로파일링
• Managing Extensions — Visual Studio Code Docs — 워크스페이스 단위 비활성화와 Extension Bisect 접근 경로
• User and workspace settings — Visual Studio Code Docs — files.watcherExclude, search.exclude 를 넣을 위치와 우선순위