목차
- VS Code에서 네비게이션 시간이 코딩보다 긴 이유
- 파일 탐색과 심볼 이동 단축키 — 마우스를 놓는 첫 단계
- 멀티커서와 라인 조작 — 편집 속도의 실제 병목
- 터미널·Git·디버깅 — 창 전환 없는 단축키
- 익스텐션 30개에서 12개로 — 뺄수록 빨라졌다
- settings.json 세팅 — GUI보다 빠르고 버전 관리가 된다
- 프로필 분리 — 프론트와 백엔드 환경을 따로 관리하기
# 30분간의 작업 결과물 — 5줄
@app.get("/users/{user_id}")
async def get_user(user_id: int):
user = await db.get(User, user_id)
if not user:
raise HTTPException(status_code=404)
return user
FastAPI 엔드포인트 하나 짜는 데 실제 타이핑은 5분이 채 안 걸린다. 나머지 시간은 파일 찾기, 함수 정의 추적, 탭 전환, 원래 파일로 돌아오기 같은 네비게이션이다.
백엔드 작업은 프론트와 달리 파일 간 이동이 잦다. import 추적, 함수 점프, 모델 참조가 계속 발생한다. 마우스 없이 Cmd+P, Cmd+Shift+O, 멀티커서 조합만으로 작업하면 속도 차이가 확실하다.
실무에서 자주 쓰는 VS Code 단축키 30가지와 settings.json 세팅을 정리했다. macOS 기준이며, Windows/Linux에서는 Cmd 대신 Ctrl을 쓰면 대부분 동일하다.
VS Code에서 네비게이션 시간이 코딩보다 긴 이유
결론부터 쓰면, 대부분의 개발자는 코딩보다 코드를 찾는 데 더 많은 시간을 쓴다. 이건 체감이 아니라 측정 가능한 사실이다. JetBrains의 Developer Ecosystem Survey 2023에 따르면, 개발자의 하루 평균 코딩 시간 중 실제 타이핑에 할애하는 비율은 30~40%에 불과하다 (출처: JetBrains Developer Ecosystem Survey 2023). 나머지는 읽기, 검색, 네비게이션이다.
VS Code의 기본 설정은 이 문제를 해결하지 못한다. 사이드바에서 파일을 클릭하고, 탭을 하나씩 넘기고, Ctrl+클릭으로 정의를 따라가다가 원래 위치를 잃어버린다. 이 워크플로우의 문제는 마우스가 느린 게 아니라, 컨텍스트 전환이 잦다는 거다. 손이 키보드에서 마우스로, 다시 키보드로 오가는 동안 사고의 흐름이 끊긴다.
프론트엔드 작업에서는 이게 덜 두드러졌다. 컴포넌트 파일 하나 안에서 JSX, 스타일, 로직을 같이 보는 구조라 파일 간 이동이 상대적으로 적다. 백엔드 코드는 다르다. 라우터, 서비스, 모델, 스키마가 각각 분리되어 있고, 한 기능을 수정하려면 4~5개 파일을 동시에 열어야 한다. 여기서 키보드 중심 워크플로우의 차이가 극명하게 드러난다.
파일 탐색과 심볼 이동 단축키 — 마우스를 놓는 첫 단계
마우스로 사이드바 파일 트리를 클릭하는 습관과 키보드 단축키 기반 탐색을 비교하면 차이가 뚜렷하다.
사이드바 클릭 방식: 폴더 열기 → 하위 폴더 열기 → 파일 클릭 → 스크롤 → 원하는 위치 찾기. 깊이가 3단계만 돼도 클릭 횟수가 5~6번이다.
Cmd+P 방식: Cmd+P 입력 → 파일명 일부 타이핑 → Enter. 2초면 끝난다. 파일명 전체를 기억할 필요도 없다. user_ser만 쳐도 user_service.py가 나온다. VS Code의 퍼지 매칭은 꽤 정확하다.
여기에 몇 가지를 더 조합하면 네비게이션 시간이 확 줄어든다. Cmd+Shift+O는 현재 파일 내 심볼(함수, 클래스, 변수)로 바로 이동한다. 파일이 500줄이 넘어가면 스크롤로 함수를 찾는 건 비효율적이다. @을 입력하면 심볼 목록이 뜨고, :을 붙이면 종류별로 그룹핑된다. Cmd+T는 이걸 워크스페이스 전체로 확장한다. 프로젝트 어딘가에 있는 UserSchema 클래스를 찾고 싶으면 Cmd+T → UserSchema → Enter. 해당 클래스가 어느 파일에 있는지 기억할 필요가 없다.
F12는 정의로 이동하는 단축키인데, 더 유용한 건 Alt+F12(Peek Definition)다. 현재 위치에서 팝업으로 정의를 보여준다. 정의를 잠깐 확인만 하고 싶을 때 파일을 새로 열지 않아도 된다. 탭이 끝없이 늘어나는 걸 방지할 수 있어서 과소평가된 기능이라고 본다.
Ctrl+G는 특정 줄 번호로 직접 이동한다. 에러 로그에 line 142가 찍혀 있으면 Ctrl+G → 142 → Enter. 스크롤하면서 줄 번호를 눈으로 세는 건 시간 낭비다. Cmd+Shift+F는 워크스페이스 전체 텍스트 검색이다. 특정 문자열이 프로젝트 어디에서 쓰이는지 추적할 때 grep보다 빠르다. 정규식도 지원하니까 패턴 매칭이 필요한 경우에도 쓸만하다.
Ctrl+Tab은 최근 열었던 파일 간 전환이다. 브라우저의 탭 전환과 비슷한데, 이걸 의식적으로 쓰기 시작하면 탭을 정리하려는 강박에서 벗어난다. 탭이 20개 열려 있어도 최근 작업한 2~3개 파일 사이를 빠르게 오갈 수 있다.
Cmd+\로 에디터를 분할하는 것도 빠뜨리면 안 된다. 라우터 코드와 서비스 코드를 나란히 놓고 작업하면 파일 전환 자체가 사라진다. 백엔드에서 모델 정의와 스키마를 동시에 참조할 때 특히 유용하다.
파일 탐색 관련 핵심 단축키는 이 8가지다: Cmd+P, Cmd+Shift+O, Cmd+T, F12, Alt+F12, Ctrl+G, Cmd+Shift+F, Ctrl+Tab. 이것만 손에 익혀도 사이드바 클릭은 거의 안 하게 된다.
멀티커서와 라인 조작 — 편집 속도의 실제 병목
편집 속도에서 가장 큰 차이를 만드는 건 멀티커서다. 알면서도 안 쓰는 사람이 많은데, 한 번 손에 익으면 되돌리기 어렵다.
가장 자주 쓰는 조합은 Cmd+D다. 단어를 선택한 상태에서 Cmd+D를 누르면 같은 단어의 다음 등장 위치가 추가 선택된다. 변수명을 일괄 변경할 때 F2(Rename Symbol)가 더 안전하지만, import 구문이나 주석처럼 심볼로 인식되지 않는 텍스트에서는 Cmd+D가 더 직관적이다. Cmd+Shift+L은 파일 내 모든 동일 텍스트를 한 번에 선택한다. 10개든 50개든 한 번에 바꿀 수 있다.
Alt+Click은 원하는 위치에 커서를 하나씩 추가한다. JSON이나 YAML 같은 구조화된 데이터에서 여러 줄의 같은 위치를 동시에 편집할 때 쓴다. 환경변수 10개의 값을 한꺼번에 ""로 감싸야 한다고 치자. 하나씩 수정하면 30초, Alt+Click으로 멀티커서를 잡으면 5초다.
라인 단위 조작도 빈번하게 등장한다. Alt+Up/Down은 현재 줄을 위아래로 이동시킨다. 코드 순서를 바꿀 때 잘라내기-붙여넣기보다 깔끔하다. Alt+Shift+Up/Down은 줄을 복제한다. 비슷한 구조의 코드를 반복 생성할 때 쓸만하다. Cmd+Shift+K는 줄 삭제로, 선택 없이 커서가 있는 줄이 바로 사라진다.
Cmd+/은 주석 토글이다. 범위 선택 후 누르면 선택한 줄 전체가 한 번에 주석 처리된다. 디버깅 과정에서 코드 블록을 임시로 비활성화하는 용도로 빈번하게 쓴다.
Cmd+.은 Quick Fix다. ESLint 경고나 타입 에러에 커서를 놓고 누르면 자동 수정 옵션이 뜬다. 누락된 import 추가, 미사용 변수 제거 같은 반복 작업을 자동화한다는 점에서 시간 절약 효과가 크다. F2(Rename Symbol)도 여기서 같이 언급해두면, 이건 프로젝트 전체에서 해당 심볼의 이름을 안전하게 바꿔준다. 단순 텍스트 치환과 달리 스코프를 인식하기 때문에 의도하지 않은 변경이 발생하지 않는다.
터미널·Git·디버깅 — 창 전환 없는 단축키
이 영역은 간단하다. 핵심은 VS Code 밖으로 나가지 않는 것이다.
Cmd+\``(백틱)은 내장 터미널 토글이다. iTerm이나 별도 터미널 앱으로 전환하는 대신 에디터 안에서 바로 명령을 실행한다. Ctrl+Shift+“는 새 터미널 인스턴스를 생성한다. 서버 실행용, 테스트 실행용, git 명령용으로 분리해두면 작업 흐름이 끊기지 않는다.
Cmd+Shift+G는 소스 컨트롤 패널을 연다. 변경된 파일 목록, diff, 스테이징, 커밋까지 한 화면에서 처리 가능하다. 터미널에서 git add, git commit을 치는 것과 비교하면 변경 내역을 시각적으로 확인하기 편하다. Cmd+B는 사이드바 토글로, 코드에 집중할 때 닫아두고 필요할 때만 잠깐 열었다 닫는다. 13인치 노트북에서 작업할 때 체감이 크다.
디버깅 단축키는 F5(Start Debugging), F9(Toggle Breakpoint), F10(Step Over), F11(Step Into)이 기본이다. print 디버깅에 익숙한 사람이 많은데(나도 그랬다), 브레이크포인트 기반 디버깅을 한 번 써보면 변수 상태를 실시간으로 확인하는 경험이 완전히 다르다는 걸 알게 된다. 이건 별도로 깊게 다룰 주제라 여기서는 단축키만 남겨둔다.
Cmd+Shift+P는 Command Palette인데, 사실 VS Code에서 가장 강력한 진입점이다. 모든 명령을 검색으로 실행할 수 있다. 단축키를 외우기 전에 Command Palette로 먼저 해당 기능을 찾고, 자주 쓰는 것만 단축키를 외우는 접근이 현실적이다.
익스텐션 30개에서 12개로 — 뺄수록 빨라졌다
백엔드로 전환하고 6개월쯤 됐을 때, VS Code 시작이 실제로 느려져서 Developer: Show Running Extensions를 실행해봤다. 활성화된 익스텐션이 34개, 그중 Activation Time이 1000ms를 넘는 게 4개 있었다. 전체 시작 시간이 5초를 넘기고 있었다. 기존 방식이 느려서 직접 파봤더니, 원인이 코드가 아니라 에디터 환경 자체였던 셈이다.
기준을 세 가지로 잡았다. 하루에 한 번 이상 쓰는가, 활성화 시간이 500ms 이하인가, VS Code 내장 기능이나 단축키로 대체 가능한가. 이 기준으로 걸러낸 결과 살아남은 익스텐션은 12개였다.
매일 쓰는 핵심 익스텐션
Error Lens는 에러와 경고를 해당 줄 옆에 인라인으로 표시한다. Problems 패널을 열지 않아도 에러 위치와 내용을 바로 확인할 수 있다. VS Code Marketplace 기준 다운로드 1700만 이상(2026년 3월 기준)인 데는 이유가 있다. 한 번 써보면 이게 없던 시절로 돌아가기 어렵다.
GitLens는 git blame을 인라인으로 보여준다. 누가 언제 왜 이 줄을 수정했는지 바로 확인 가능하다. 다만 기능이 워낙 많아서 전부 켜두면 UI가 지저분해진다. Current Line Blame만 활성화하고 나머지는 꺼두는 게 깔끔하다. GitLens v15(2025년 11월 릴리즈) 기준으로 성능이 꽤 개선됐다. 그 이전 버전을 쓰고 있다면 업데이트를 권한다 (출처: GitLens Release Notes v15).
GitHub Copilot은 코드 자동완성과 인라인 채팅을 지원한다. 월 $10의 비용이 드는데, 반복적인 보일러플레이트 코드 작성 시간을 줄여주는 건 확실하다. 다만 Copilot이 제안하는 코드를 무비판적으로 수용하면 오히려 디버깅 시간이 늘어난다. 제안을 읽고 판단하는 습관이 필요하다.
REST Client는 .http 파일에서 바로 API 요청을 보낸다. Postman을 별도로 띄울 필요가 없다. 백엔드 API를 개발할 때 테스트 요청을 코드 옆에 두고 바로 실행할 수 있어서 컨텍스트 전환이 사라진다.
Prettier와 ESLint(Python이라면 Ruff)는 포매팅과 린팅 자동화다. 저장 시 자동 포맷되도록 설정해두면 코드 스타일에 쓰는 인지 비용이 0이 된다. Pylance는 Python 개발 시 타입 체킹과 자동완성을 담당한다. 동적 타입 언어의 약점을 IDE 수준에서 보완해주는 역할이다.
내장 기능과 중복되는 익스텐션
나머지 22개 중 상당수는 이미 VS Code에 내장된 기능과 겹치고 있었다. Bracket Pair Colorization은 v1.60(2021년 9월)부터 내장이다 (출처: VS Code v1.60 Release Notes). Auto Close Tag도 Emmet으로 충분하고, 인덴트 가이드 역시 기본으로 제공된다. 내장 기능으로 이미 대체된 익스텐션을 중복 설치하고 있는 경우가 의외로 많다. 한 번쯤 Developer: Show Running Extensions로 점검해보는 걸 권한다.
Docker와 Remote – SSH, Project Manager 세 개는 매일 쓰지는 않지만 필요할 때 없으면 곤란한 부류라 남겨뒀다. Docker는 컨테이너 로그 확인과 이미지 관리가 CLI보다 직관적이고, Remote – SSH는 원격 서버 파일 편집 시 scp + vim 조합을 대체한다. Project Manager는 3~4개 프로젝트를 동시에 진행할 때 프로젝트 단위 전환을 지원한다.
결과적으로 시작 시간이 5초에서 1.8초로 줄었다. 실측 기준으로 완전히 다른 도구를 쓰는 느낌이었다.
settings.json 세팅 — GUI보다 빠르고 버전 관리가 된다
VS Code 설정을 GUI(Cmd+,)로 바꾸는 사람이 많은데, settings.json을 직접 편집하는 게 몇 가지 면에서 낫다. 첫째, 설정을 검색하고 토글을 클릭하는 것보다 JSON으로 한 번에 복사-붙여넣기하는 게 빠르다. 둘째, .vscode/settings.json에 프로젝트별 설정을 넣으면 팀원과 공유가 된다. 셋째, Git으로 변경 이력을 추적할 수 있다.
// settings.json — 현재 사용 중인 세팅 (발췌)
{
// 저장 시 자동 포맷
"editor.formatOnSave": true,
// 탭 사이즈 — 프론트(2) 백엔드(4) 프로젝트별로 다르게 설정
"editor.tabSize": 4,
// 미니맵 끄기 — 13인치 노트북에서는 공간 낭비
"editor.minimap.enabled": false,
// 1초 후 자동 저장
"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000,
// 줄바꿈 활성화
"editor.wordWrap": "on",
// 브래킷 페어 가이드
"editor.guides.bracketPairs": true,
// 터미널 폰트 크기
"terminal.integrated.fontSize": 13,
// Git 자동 fetch
"git.autofetch": true,
// Copilot 인라인 제안
"github.copilot.editor.enableAutoCompletions": true,
// Python 타입 체크
"python.analysis.typeCheckingMode": "basic",
"[python]": {
"editor.defaultFormatter": "charliermarsh.ruff",
"editor.formatOnSave": true
}
}
몇 가지 설명을 덧붙이면, editor.minimap.enabled: false는 호불호가 갈린다. 큰 모니터에서는 미니맵이 유용할 수 있지만, 노트북 화면에서는 코드 영역만 좁힐 뿐이다.
files.autoSave를 afterDelay로 설정하면 Cmd+S를 누르는 습관에서 벗어날 수 있다. auto save와 format on save를 동시에 쓸 때 주의할 점이 있는데, 타이핑 도중에 포매터가 실행되면서 커서 위치가 튀는 현상이 간혹 발생한다. autoSaveDelay 값을 1000ms 이상으로 잡으면 어느 정도 완화된다. 이건 공식 문서에 잘 나와 있지 않은 부분이라 직접 겪어봐야 안다.
python.analysis.typeCheckingMode는 "basic"이 적당한 균형점이다. "strict"로 올리면 타입 힌트가 없는 서드파티 라이브러리에서 경고가 쏟아져서 실용적이지 않더라. "off"는 Pylance의 장점을 포기하는 것이니 권하지 않는다.
Cmd+K Cmd+S로 키보드 단축키 설정 화면을 열 수 있다. 여기서 기존 단축키 확인과 커스텀 바인딩 추가가 가능하다. keybindings.json을 직접 편집해도 되는데, GUI 쪽이 충돌 감지를 해주므로 처음에는 GUI에서 작업하는 게 안전하다.
프로필 분리 — 프론트와 백엔드 환경을 따로 관리하기
VS Code 1.75(2023년 1월)부터 프로필(Profile) 기능이 정식 지원된다 (출처: VS Code v1.75 Release Notes). 프로필별로 익스텐션, 설정, 키바인딩, UI 상태를 분리할 수 있다.
프론트엔드 작업과 백엔드 작업에서 필요한 익스텐션이 다르다. 프론트에서는 Tailwind CSS IntelliSense, Auto Rename Tag가 필요하고, 백엔드에서는 Pylance, REST Client, Docker가 필요하다. 전부 한 프로필에 몰아넣으면 불필요한 익스텐션이 항상 활성화 상태로 메모리를 점유한다. "Frontend"와 "Backend"로 프로필을 분리하고 각각 필요한 익스텐션만 설치했더니, 프로필 전환 시 익스텐션 로딩이 줄어들면서 전환 속도가 눈에 띄게 빨라졌다.
이 기능의 한계도 있다. 프로필 전환 시 VS Code가 창을 다시 로드하는데, 열려 있던 탭과 터미널 상태가 초기화된다. 작업 중간에 프로필을 바꾸면 흐름이 끊길 수 있다. 그래서 프로젝트마다 VS Code 창을 따로 여는 방식이 현실적으로 더 쓸만한 경우도 있다. 이 부분은 아직 더 실험해봐야 할 것 같다.
VS Code 단축키를 30개 전부 외우는 것보다, 자기 워크플로우에서 가장 반복되는 동작 5개를 먼저 키보드로 바꾸는 게 생산성 측면에서 투자 대비 효과가 크다고 본다.
