VS Code 확장 정리 기준과 문제 확장 찾는 법

확장을 서른 개 넘게 깔아두고 그중 절반이 뭘 하는지 모른다면, 그 상태가 VS Code를 느리게 만들고 가끔 이상하게 동작하게 만드는 원인이다. 이 글은 확장을 정리하는 기준과, 팀에 필요한 확장을 강요하지 않고 알리는 방법, 그리고 확장 하나가 말썽을 일으킬 때 범인을 찾는 방법을 다룬다. 결론부터 말하면 확장은 적을수록 좋고, 프로젝트마다 다르게 켜는 것이 맞다.

확장은 VS Code와 같은 권한으로 돈다

정리를 이야기하기 전에 전제를 하나 짚어야 한다. 공식 문서의 문장이다. "확장은 VS Code 자체와 동일한 권한을 가진다." 그리고 설치 전에 게시자를 확인하라고 권한다.

이 말의 무게가 가볍지 않다. 확장은 내 파일을 읽을 수 있고, 네트워크를 쓸 수 있고, 터미널 명령을 실행할 수 있다. 별 다섯 개에 다운로드 수가 많다는 것만 보고 깔면 안 되는 이유다. 게시자가 누구인지, 저장소가 공개돼 있는지, 최근에 갱신됐는지를 본다. 특히 이름이 유명한 확장과 비슷한데 게시자가 다른 것은 의심해야 한다.

그래서 "일단 깔아보고 아니면 지우지" 하는 습관은 생각보다 위험하다. 지워도 그동안 무엇을 했는지는 알 수 없다.

지워야 할 확장을 가르는 세 가지 기준

내가 쓰는 기준은 셋이다.

기능이 겹치는 것. 포매터 두 개, 린터 두 개가 깔려 있으면 저장할 때마다 서로 결과를 덮어쓴다. 어느 쪽이 이길지가 실행 순서에 따라 달라져서, 같은 파일을 저장했는데 결과가 매번 다른 상황이 생긴다. 겹치는 것은 반드시 하나만 남긴다. editor.defaultFormatter를 명시적으로 지정해 두면 실수로 다른 게 끼어드는 일도 막는다.

VS Code가 이미 하는 것. 예전에는 확장이 필요했지만 지금은 기본 기능이 된 것들이 있다. Git 연동, 마크다운 미리보기, 자동 import, 코드 폴딩 같은 것이다. 오래 쓴 환경일수록 이런 유물이 쌓여 있다.

석 달 동안 안 쓴 것. 특정 언어나 프레임워크를 잠깐 만지느라 깐 것들이다. 나중에 또 쓸 것 같아서 남겨두게 되는데, 실제로 다시 쓸 때는 새 버전을 깔면 그만이다.

지우기 전에 한 번 고민할 것은, 지우는 대신 워크스페이스에서만 끄는 선택지다. 문서는 확장을 "전역 또는 워크스페이스 단위로" 비활성화할 수 있다고 설명한다. 자바 확장이 필요한 프로젝트와 필요 없는 프로젝트가 섞여 있다면, 필요 없는 쪽에서만 끄는 것이 맞다.

프로젝트마다 다른 확장 조합을 유지한다

확장을 전역으로 다 켜두면, 파이썬 프로젝트를 여는데 자바 언어 서버가 뜨고 러스트 분석기가 뜬다. 쓰지도 않는데 메모리와 CPU를 먹는다.

그래서 나는 공통으로 쓰는 최소한만 전역에 두고 나머지는 워크스페이스 단위로 켠다. 전역에 두는 것은 Git 관련, 편집 보조, 테마 정도다. 언어별 확장은 해당 프로젝트에서만 켠다.

명령 팔레트에는 "설치된 모든 확장을 빠르게 비활성화"하는 명령도 있다. 무언가 이상할 때 전부 끄고 시작하는 용도로 쓴다. 문서는 확장이 "다시 활성화할 때까지 세션을 넘어 비활성 상태로 유지된다"고 밝히고 있으니, 껐다는 사실을 잊지 않도록 주의해야 한다.

팀에는 강요하지 말고 추천으로 알린다

프로젝트에 필요한 확장이 있다면 README에 적는 대신 저장소가 직접 알리게 하는 편이 낫다. Extensions: Configure Recommended Extensions (Workspace Folder) 명령을 실행하면 .vscode/extensions.json이 만들어진다.

{
  "recommendations": [
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode"
  ]
}

식별자는 게시자.확장이름 형식이다. 확장 페이지에서 복사할 수 있다. 이 파일이 있으면, 워크스페이스를 열 때 VS Code가 추천 확장을 설치하겠냐고 묻는다.

이 방식의 장점은 강제가 아니라는 것이다. 설정으로 확장을 강제로 켜는 방법은 없고, 있다 해도 남의 에디터를 마음대로 바꾸는 것은 좋지 않다. 추천은 알리되 선택은 각자에게 남긴다.

린터나 포매터처럼 결과물에 영향을 주는 도구는 확장에만 의존하지 않는 것이 좋다. npm run lint처럼 명령줄에서도 같은 검사가 돌아야 CI에서 막을 수 있다. 확장은 편의를 위한 것이고, 규칙의 강제는 CI가 하는 일이다. 이 구분이 없으면 "내 에디터에서는 통과했는데" 하는 상황이 반복된다.

확장 하나가 말썽일 때 범인을 찾는 방법

자동완성이 안 뜨거나, 저장할 때 이상한 변경이 들어가거나, 창이 자꾸 멈춘다면 확장을 의심하게 된다. 하나씩 껐다 켜지 않아도 된다.

문서가 안내하는 Extension Bisect를 쓴다. 확장 뷰의 점 세 개 메뉴에서 실행하거나 F1에서 Help: Start Extension Bisect를 고른다. 확장 절반을 끄고 창을 다시 로드한 뒤 문제가 여전한지 묻는다. 답을 몇 번 하면 범인을 찾아준다. 스무 개 중에서 찾는 데 다섯 번이면 된다.

확장이 원인인지 아닌지부터 가르고 싶으면 터미널에서 이렇게 띄운다.

code --disable-extensions

이 상태에서 멀쩡하면 확장 문제이고, 그래도 이상하면 확장은 범인이 아니다.

범인을 찾은 뒤에는 바로 지우기보다 버전을 낮춰보는 것을 권한다. 문서에 나오듯 특정 버전이나 사전 릴리스 버전을 골라 설치할 수 있다. 최근 업데이트에서 생긴 문제라면 이전 버전으로 되돌리고 자동 업데이트를 꺼두면 된다. 그동안 해당 확장 저장소에 이슈가 올라왔는지 확인해 보는 것도 방법이다.

새 확장을 고를 때 보는 것들

정리만큼 중요한 것이 처음에 잘 고르는 일이다. 나는 설치 버튼을 누르기 전에 네 가지를 본다.

게시자를 먼저 본다. 확장 페이지에 게시자 이름이 나오고, 검증된 게시자에는 표시가 붙는다. 유명한 확장과 이름이 비슷한데 게시자가 다르면 거의 확실히 의심해야 한다. 인기 확장의 이름을 살짝 바꿔 올리는 사례가 실제로 있다.

저장소가 공개돼 있는지 본다. 소스가 공개된 확장은 무엇을 하는지 확인할 수 있고, 이슈 목록에서 다른 사람들이 어떤 문제를 겪는지도 보인다. 저장소 링크가 없는 확장은 선택지가 없을 때만 쓴다.

마지막 갱신 시점을 본다. 몇 년째 갱신이 없는 확장은 VS Code 업데이트를 따라오지 못해 어느 날 조용히 동작을 멈춘다. 특히 언어 서버처럼 API를 많이 쓰는 확장일수록 그렇다.

설치 수와 평점은 마지막에 참고만 한다. 숫자가 크다고 안전하다는 뜻은 아니고, 작다고 나쁜 것도 아니다. 틈새 도구는 원래 설치 수가 적다.

확장 없이 설정만으로 되는 것도 꽤 있다

확장을 깔기 전에 기본 기능으로 되는지 한 번 확인해 볼 만하다. 자주 겹치는 것들을 꼽으면 이렇다.

괄호 색 구분은 editor.bracketPairColorization.enabled가 기본으로 켜져 있다. 예전에는 확장이 필요했다. 들여쓰기 가이드 강조도 editor.guides.bracketPairs로 켠다. 파일 저장 시 줄 끝 공백 정리는 files.trimTrailingWhitespace면 되고, 이를 위해 별도 확장을 깔 이유가 없다.

git.autofetch를 켜두면 원격 변경을 주기적으로 가져와 상태 표시줄에 알려준다. Git 상태를 보여주는 확장 상당수가 기본 기능과 겹친다.

이런 것들을 먼저 확인하면 확장 목록이 짧아진다. 기본 기능은 VS Code와 함께 갱신되므로 관리 부담도 없다.

확장을 줄이면 잃는 것도 있다

여기까지 정리를 권했지만 반대 의견도 있다. 확장이 많다는 것은 그만큼 도구를 잘 쓰고 있다는 뜻일 수도 있다. 실제로 어떤 확장은 없으면 작업이 훨씬 번거로워진다.

그래서 나는 "개수를 줄여라"가 아니라 "쓰는 이유를 설명할 수 있어야 한다"를 기준으로 삼는다. 왜 깔았는지 기억나지 않는 확장은 지우고, 이유가 분명한 것은 열 개든 스무 개든 남긴다. 남의 목록을 보고 따라 까는 것이 아니라, 내가 겪은 불편에서 출발해 고른 것들이면 대체로 문제가 없다.

한 가지만 덧붙이면, 확장을 정리한 뒤에는 시작 시간을 한 번 재보는 것이 좋다. F1에서 Startup Performance를 실행하면 무엇이 시간을 썼는지 단계별로 나온다. 정리 전후를 비교하면 효과가 숫자로 보인다. 감으로 판단하지 않게 된다.

참고 자료

• Managing Extensions — Visual Studio Code Docs — 설치와 비활성화, 워크스페이스 추천 확장, Extension Bisect, 버전 지정 설치
• Performance Issues — microsoft/vscode Wiki — --disable-extensions, Startup Performance, Show Running Extensions
• User and workspace settings — Visual Studio Code Docs — editor.defaultFormatter 를 지정해 포매터 충돌을 막는 방법