VS Code 생산성 높이기: 단축키, 확장, 설정의 실전 기준
그래서 더 중요한 질문은 “어떤 확장을 깔아야 하나”가 아니라 “새 팀원이 이 저장소를 열었을 때 무엇이 바로 동작해야 하나”입니다.
개인 생산성과 팀 생산성은 다르다
개인은 단축키와 개인 설정으로 얼마든지 VS Code를 최적화할 수 있습니다. 하지만 팀은 다른 문제가 있습니다.
- 공유 workspace 설정
- 추천 확장 목록
- 표준 task 정의
- 재현 가능한 debug 설정
- 낮은 온보딩 마찰
저장소가 개인 에디터 노하우에 지나치게 의존하면, 에디터도 또 하나의 문서 없는 시스템이 됩니다.
가장 큰 효과는 workspace 기본값에서 나온다
실무에서 효과가 큰 VS Code 개선은 저장소에 커밋되는 경우가 많습니다.
- save 시 자동 포맷
- 줄바꿈과 공백 규칙 통일
- lint와 fix 액션
- 언어별 설정
- workspace 추천 확장
예를 들면:
{
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
}
}이런 기본값은 사람이 기억해서 맞추는 비용을 줄이고, 저장되는 코드 자체를 더 예측 가능하게 만듭니다.
task와 debug profile은 실제 작업 흐름을 반영해야 한다
팀이 반복해서 치는 명령은 VS Code 안에서 바로 실행 가능해야 합니다.
예를 들어:
- 개발 서버 실행
- 특정 테스트 실행
- 디버거와 앱 동시 구동
- PR 전 lint나 typecheck 실행
README에 있는 명령이 매주 여러 번 반복된다면, 그 시점부터는 task나 launch 설정으로 끌어오는 편이 낫습니다.
확장 수가 많다고 생산성이 높아지지는 않는다
확장이 많아지면 오히려 아래 문제가 자주 생깁니다.
- 역할이 겹치는 확장
- 느린 startup과 indexing
- 포맷터 충돌
- 온보딩 혼란
좋은 기준은 “프로젝트에서 반복적으로 생기는 문제를 해결하는가”입니다. 설명하기 어려운 확장은 optional로 두거나 빼는 편이 낫습니다.
검색, 리팩터링, 탐색이 체감 시간을 가장 많이 줄인다
많은 개발자가 생산성 개선을 UI 취향에서 찾지만, 실제로는 코드 탐색에서 시간을 가장 많이 잃습니다. 체감이 큰 개선은 보통 다음에서 나옵니다.
- symbol search와 file search 습관
- rename/refactor 안정성
- workspace-wide search 필터
- language server 품질
큰 코드베이스를 자신 있게 탐색할 수 있을수록 맥락 전환이 줄고, 결과적으로 속도보다 더 중요한 정확도가 올라갑니다.
원격 개발과 컨테이너 환경도 1급 시민으로 다뤄야 한다
프로젝트에 따라 로컬 머신은 진짜 실행 환경이 아닐 수 있습니다. 컨테이너, WSL, 원격 서버가 실제 개발 기준이라면, VS Code 설정도 그 현실을 반영해야 합니다.
- 기본 개발 환경이 로컬인지 원격인지
- 터미널 경로와 디버그 전제가 일치하는지
- task가 실제 실행 환경에서 그대로 동작하는지
겉으로는 표준화된 것 같아도 실제 환경이 다르면 생산성은 금방 무너집니다.
자주 보이는 실패 패턴
- 개인 설정만 믿고 workspace 설정을 비워 두는 경우
- README 명령은 많지만 task로 연결되지 않은 경우
- 확장을 계속 추가만 하고 정리하지 않는 경우
- 포맷터와 code action이 사람마다 다른 경우
- debug 흐름을 문서로만 남겨 두는 경우
좋은 에디터 구성은 특별해 보이는 구성이 아니라, 흔한 작업이 지루할 만큼 반복 가능하게 느껴지는 구성입니다.
체크리스트
- 저장소가 save, lint, format의 기본 동작을 정의하는가
- 자주 쓰는 명령이 task나 launch config로 들어 있는가
- 확장 목록이 작고 설명 가능한 수준인가
- 새 팀원이 tribal knowledge 없이 실행과 디버그를 할 수 있는가
- 에디터 설정이 실제 실행 환경과 일치하는가
마무리
VS Code 생산성은 확장 쇼핑이 아니라 워크플로 설계입니다. 좋은 구성은 반복되는 결정을 줄이고 기본 경로를 더 선명하게 만듭니다. save, run, search, debug, review가 자연스럽게 이어질 때 비로소 에디터가 개인 취향을 넘어 팀 인프라가 됩니다.
Continue Reading
다음으로 읽기 좋은 글
엔지니어링 노트 운영법
기억에 의존하는 개발은 쉽게 반복 비용을 만듭니다. 개인과 팀이 함께 쓰는 엔지니어링 노트 운영법을 정리합니다.
🔧 ToolsIntelliJ IDEA 단축키와 생산성 팁의 실전 기준
단축키 암기보다 더 중요한 코드 탐색, 안전한 리팩터링, 디버깅 흐름, 팀 단위 IDE 습관을 중심으로 IntelliJ 생산성을 높이는 방법을 정리합니다.
📚 IT 이야기개발자들은 왜 CLI를 사랑하게 되었을까
화려한 GUI가 많은 시대에도 개발자들은 여전히 터미널로 돌아갑니다. CLI가 기술 문화의 중심이 된 이유를 이야기처럼 풀어봅니다.
🚀 DevOpsKubernetes 심화 — HPA, Resource 관리, Pod Scheduling
Kubernetes 운영을 설정 모음이 아니라 자원 배치와 장애 복원력의 관점에서 정리합니다. requests/limits, HPA, affinity, taint, PDB, probe를 언제 어떻게 써야 하는지 실무적으로 설명합니다.
다음 탐색