개발 속도를 2배로 올려주는 VS Code 단축키와 실전 활용법

들어가며

예전 팀에 있던 한 선임 개발자의 화면을 옆에서 보다가 신기했던 기억이 있습니다. 코드 리뷰 중 지적받은 부분을 고칠 때, 그는 마우스에 손을 대지 않았습니다. 파일 트리를 클릭해서 폴더를 펼치는 대신 키보드로 몇 글자를 치자 원하는 파일이 바로 열렸고, 비슷한 이름의 변수 열댓 개를 한 번에 바꿀 때도 드래그로 선택하는 대신 커서를 순식간에 여러 개로 늘려서 동시에 타이핑했습니다. 함수 정의를 확인할 때도 새 탭을 열지 않고 그 자리에서 코드를 살짝 들여다보고 다시 원래 위치로 돌아왔습니다. 같은 작업인데 걸리는 시간이 눈에 띄게 달랐습니다.

이 차이는 타이핑 속도나 재능의 문제가 아닙니다. VS Code가 제공하는 단축키 체계를 얼마나 워크플로우에 녹여냈는지의 차이입니다. 마우스로 메뉴를 찾고 클릭하는 동작은 매번 손을 키보드에서 마우스로 옮기고, 화면에서 원하는 항목을 시각적으로 찾고, 다시 손을 키보드로 되돌리는 세 단계를 거칩니다. 반면 단축키는 손이 홈 포지션을 벗어나지 않은 채로 같은 결과를 냅니다. 한 번의 동작으로는 몇 초 차이도 안 나지만, 하루에 파일을 수백 번 열고 닫고, 변수명을 수십 번 바꾸고, 같은 패턴의 코드를 반복해서 편집하는 개발자에게 이 차이는 누적됩니다.

이 글은 단축키를 표로만 나열하는 치트시트가 아닙니다. 각 단축키가 왜 마우스 조작보다 실제로 빠른지, 어떤 상황에서 진짜 효과가 있는지, 그리고 언제는 오히려 단축키를 쓰는 것이 손해인지를 함께 설명합니다. 단축키는 도구일 뿐이고, 도구를 잘못된 상황에 쓰면 오히려 시간을 더 쓰게 되는 경우도 분명히 있기 때문입니다.

이 글에서 다루는 범위

이 사이트에는 이미 우분투 환경에서 VS Code를 쓸 때의 특유 문제(Wayland 렌더링, inotify 한도, Remote-SSH)를 다룬 글과 VS Code 확장 개발 가이드, C++ 개발을 위한 VS Code 세팅이 있습니다. 이 글은 그런 환경 설정이나 확장 개발이 아니라, 에디터 자체를 키보드로 다루는 순수한 조작 방법에만 집중합니다. 터미널을 완전히 키보드로만 다루는 것에 관심이 있다면 Vi/Vim 완전 가이드도 참고할 만합니다. VS Code는 Vim 확장을 켜지 않아도 이번 글에서 다루는 단축키만으로 상당한 수준의 키보드 중심 워크플로우를 만들 수 있습니다.

표기 규칙: 이 글에서는 Windows/Linux 기준 단축키를 먼저 쓰고, macOS 단축키를 괄호 안에 병기합니다. macOS에서는 대부분 Ctrl → Cmd, Alt → Option으로 그대로 대응되지만, 일부는 예외가 있으므로 다를 때만 별도로 표시합니다.

1. 커맨드 팔레트: 모든 기능의 진입점

단축키: Ctrl+Shift+P (macOS: Cmd+Shift+P)

VS Code의 모든 명령어는 이름을 가지고 있고, 커맨드 팔레트는 그 이름으로 명령어를 검색해서 실행하는 창입니다. 메뉴 어딘가에 숨어 있는 기능을 마우스로 찾아 헤매는 대신, 대략적인 이름만 기억하면 바로 실행할 수 있습니다. 예를 들어 “줄바꿈 문자를 CRLF에서 LF로 바꾸고 싶다”는 생각이 들면 메뉴를 뒤지는 대신 Ctrl+Shift+P를 누르고 line ending이라고만 쳐도 관련 명령어가 바로 나타납니다.

이 단축키가 진짜 유용한 이유는 단축키 자체를 몰라도 되게 해주기 때문입니다. 어떤 기능이 있다는 것은 알지만 정확한 키 조합을 기억하지 못할 때, 커맨드 팔레트에서 명령어를 실행하면 그 옆에 해당 명령의 단축키가 함께 표시됩니다. 즉 커맨드 팔레트는 기능을 찾는 도구이자, 다른 단축키를 자연스럽게 외우게 되는 학습 경로이기도 합니다. 반대로 이미 단축키를 외운 동작(파일 저장, 줄 이동 등)까지 매번 커맨드 팔레트를 거쳐서 실행하면 오히려 손해입니다. 이름을 타이핑하고 검색 결과에서 원하는 항목을 확인하는 과정 자체가 전용 단축키 한 번 누르는 것보다 느리기 때문입니다. 커맨드 팔레트는 “잘 안 쓰는 기능을 찾을 때” 쓰는 도구지, 매일 반복하는 동작의 기본 실행 경로로 삼을 도구는 아닙니다.

2. 파일과 탐색: 마우스로 폴더를 뒤지지 않기

Ctrl+P — 빠른 열기 (Quick Open)

단축키: Ctrl+P (macOS: Cmd+P)

저는 VS Code를 쓰기 시작한 초반 몇 달 동안 이 단축키의 존재를 몰랐습니다. 파일을 열 때마다 사이드바의 파일 탐색기를 클릭해서 폴더를 하나하나 펼치고, 원하는 파일을 찾을 때까지 스크롤을 내렸습니다. 프로젝트 구조가 깊어질수록 이 과정은 점점 느려졌고, 가끔은 폴더 구조를 착각해서 엉뚱한 곳을 뒤지다가 시간을 허비하기도 했습니다. 나중에 동료가 Ctrl+P를 누르고 파일명 일부만 타이핑하는 걸 보고 나서야, 그동안 같은 작업을 몇 배나 느리게 하고 있었다는 걸 깨달았습니다.

Ctrl+P는 파일명의 일부, 심지어 정확한 철자가 아니어도 퍼지 매칭으로 후보를 좁혀줍니다. usercontroller.ts라는 파일을 열고 싶다면 usrctl처럼 대략적인 글자만 입력해도 웬만하면 상위 후보로 뜹니다. 이게 마우스 탐색보다 빠른 이유는 명확합니다 — 폴더 트리를 몇 단계 펼치는 데 필요한 클릭 횟수와 시각적 탐색 시간이, 몇 글자를 입력하고 엔터를 치는 시간보다 항상 더 오래 걸리기 때문입니다. 다만 파일이 정확히 몇 개 없는 아주 작은 프로젝트, 혹은 애초에 어떤 파일을 찾아야 할지 이름조차 모르는 상황(구조를 처음 파악할 때)에서는 파일 탐색기를 눈으로 훑는 것이 오히려 더 빠를 수 있습니다.

Ctrl+Tab — 최근 연 파일 순환

단축키: Ctrl+Tab (macOS: Cmd+Tab은 시스템 단축키와 겹치므로 Ctrl+Tab 그대로 사용)

두 개나 세 개 파일을 번갈아 가며 작업할 때, 매번 Ctrl+P로 파일명을 입력하는 것보다 Ctrl+Tab으로 최근 사용한 파일 목록을 순환하는 것이 더 빠릅니다. 브라우저의 탭 전환과 비슷한 감각으로, 누르고 있는 동안 목록이 뜨고 손을 떼면 선택한 파일로 이동합니다. 다만 열어둔 탭이 10개를 넘어가면 원하는 파일을 찾기 위해 여러 번 눌러야 하므로, 이럴 때는 차라리 Ctrl+P가 더 빠릅니다. 즉 “방금 작업하던 파일로 돌아가기”에는 Ctrl+Tab, “특정 파일을 정확히 찾아가기”에는 Ctrl+P라는 역할 분담이 명확합니다.

Ctrl+Shift+E — 탐색기 포커스

파일 탐색기 자체가 필요할 때(새 파일 생성, 폴더 구조 파악, 드래그 앤 드롭으로 파일 이동)는 사이드바를 마우스로 클릭하는 대신 Ctrl+Shift+E로 포커스를 옮길 수 있습니다. 포커스가 옮겨진 뒤에는 방향키만으로 트리를 탐색하고 엔터로 파일을 열 수 있어서, 손을 마우스로 옮기지 않고도 탐색기의 모든 기능을 쓸 수 있습니다.

아래 다이어그램은 “무엇을 찾고 있는가”에 따라 어떤 탐색 방법을 골라야 하는지 정리한 것입니다. 실제로 대부분의 탐색 시간 낭비는 상황에 안 맞는 방법을 습관적으로 쓰는 데서 발생합니다.

flowchart TD
    A[지금 필요한 것은?] --> B{파일명을 대략 아는가?}
    B -->|예| C["Ctrl+P
퍼지 매칭으로 즉시 열기"]
    B -->|아니오| D{함수/클래스 이름을 아는가?}
    D -->|예| E["Ctrl+T (전역 심볼 검색)
또는 Ctrl+Shift+O (파일 내 심볼)"]
    D -->|아니오| F{특정 텍스트/문자열을 아는가?}
    F -->|예| G["Ctrl+Shift+F
프로젝트 전체 검색"]
    F -->|아니오| H{방금 작업하던 파일인가?}
    H -->|예| I["Ctrl+Tab
최근 파일 순환"]
    H -->|아니오| J["Ctrl+Shift+E
탐색기에서 구조 파악"]

3. 멀티커서와 다중 선택: 반복 작업을 한 번에

멀티커서는 VS Code의 단축키 중에서 배우고 나면 가장 극적인 변화를 체감하는 기능입니다. 저도 이걸 모르던 시절에는 같은 변수명을 여러 곳에서 바꿔야 할 때 Ctrl+F로 찾아서 하나씩 다음으로 넘어가며 수동으로 고쳤습니다. 한 번은 열 몇 군데에 흩어진 변수명을 이런 식으로 고치다가 중간에 한 곳을 빠뜨렸고, 빌드가 통과하는 바람에 그 실수를 코드 리뷰에서야 지적받은 적이 있습니다. 변수명이 부분적으로만 바뀐 상태로 커밋을 올렸던 것입니다. 지금 생각하면 멀티커서로 한 번에 선택해서 동시에 고쳤다면 애초에 “빠뜨린다”는 실수 자체가 불가능했을 상황이었습니다.

Ctrl+D — 다음 일치 항목 선택

단축키: Ctrl+D (macOS: Cmd+D)

커서가 놓인 단어와 동일한 다음 일치 항목을 순차적으로 선택에 추가합니다. 변수명이나 함수 호출을 하나씩 확인하면서 원하는 것만 골라 고칠 때 유용합니다. 전체를 한 번에 바꾸는 것이 아니라 “이 중 3개만 바꾸고 나머지는 그대로 둔다”처럼 선택적으로 처리해야 할 때, 찾아 바꾸기의 정규식보다 훨씬 직관적입니다. 눈으로 각 일치 항목을 확인하면서 진행하기 때문에 정규식 치환보다 실수할 확률이 낮습니다.

Ctrl+Shift+L — 모든 일치 항목 동시 선택

단축키: Ctrl+Shift+L (macOS: Cmd+Shift+L)

Ctrl+D를 계속 눌러서 하나씩 추가하는 대신, 파일 안의 모든 일치 항목을 한 번에 선택합니다. 변수명이나 함수명을 파일 전체에서 일괄적으로 바꿀 게 확실할 때 씁니다. 다만 이 명령은 “확실할 때”만 써야 합니다. 같은 문자열이 의미가 다른 곳(예: 주석 안의 설명, 다른 스코프의 동명 변수)에도 등장한다면 의도치 않은 부분까지 한 번에 바뀝니다. 이럴 때는 뒤에서 다룰 F2(이름 변경)가 훨씬 안전한 대안입니다. F2는 스코프와 참조 관계를 실제로 분석해서 바꾸지만, Ctrl+Shift+L은 단순 텍스트 일치이기 때문입니다.

Alt+클릭 — 임의 위치에 커서 추가

단축키: Alt+클릭 (macOS: Option+클릭)

정형화된 패턴이 아니라 서로 다른 줄의 서로 다른 위치에 동시에 커서를 놓고 싶을 때 씁니다. 예를 들어 여러 줄의 끝에 각각 세미콜론이나 쉼표를 추가해야 하는데 줄 길이가 제각각이라 Ctrl+D로는 처리할 수 없는 경우입니다. 다만 이 조작은 마우스를 필요로 하므로, 이미 손이 키보드에 있는 상태라면 다음에 설명할 Ctrl+Alt+↓(열 선택)가 더 빠를 때도 많습니다.

Ctrl+Alt+↑ / ↓ — 열 방향 멀티커서

단축키: Ctrl+Alt+↑/↓ (macOS: Cmd+Option+↑/↓)

같은 열(column) 위치에 커서를 위아래로 늘립니다. 표 형태로 정렬된 데이터나 비슷한 구조의 여러 줄에서 같은 컬럼 위치를 동시에 수정할 때 씁니다. 정렬이 깨진 코드에서는 오히려 원하지 않는 위치에 커서가 생기므로, 이 단축키는 코드가 어느 정도 정렬되어 있을 때만 효과적입니다.

4. 코드 이동과 편집

Alt+↑ / Alt+↓ — 줄 이동

단축키: Alt+↑/↓ (macOS: Option+↑/↓)

현재 줄(또는 선택 영역)을 위아래로 이동시킵니다. 잘라내기(Ctrl+X)로 줄을 제거하고 커서를 옮긴 뒤 붙여넣기(Ctrl+V)하는 3단계 조작을, 커서 위치를 바꾸지 않고 단 한 번의 키 입력으로 끝냅니다. 함수 안에서 실행 순서를 바꾸거나, import 문의 순서를 조정하거나, 조건문 블록의 배치를 바꿀 때 특히 자주 씁니다. 코드의 들여쓰기 레벨이 다른 곳으로 옮기면 자동으로 들여쓰기도 재조정해준다는 점도 잘라내기·붙여넣기보다 나은 점입니다.

Shift+Alt+↓ — 줄 복제

단축키: Shift+Alt+↓ (macOS: Shift+Option+↓, 위쪽은 ↑)

현재 줄을 그대로 복사해서 바로 아래(또는 위)에 붙여 넣습니다. 비슷한 코드를 하나 더 작성해야 할 때 — 예를 들어 필드가 하나 더 필요한 구조체나, 비슷한 테스트 케이스를 하나 더 추가할 때 — Ctrl+C → 이동 → Ctrl+V의 3단계를 1단계로 줄여줍니다. 다만 복제 후에 값이 조금씩 달라져야 하는 경우가 많으므로, 복제 직후 멀티커서(Ctrl+D)로 바뀔 부분만 골라 잡는 조합이 실전에서 가장 많이 쓰입니다.

Ctrl+Shift+K — 줄 삭제

단축키: Ctrl+Shift+K (macOS: Cmd+Shift+K)

커서를 줄 끝까지 옮기고, Shift+Home으로 선택하고, Delete를 누르는 대신 한 번에 줄 전체를 삭제합니다. 커서가 줄의 어느 위치에 있든 상관없이 동작하므로, 커서 위치를 신경 쓸 필요가 없다는 점이 특히 편합니다.

Ctrl+Enter / Ctrl+Shift+Enter — 줄바꿈 없이 새 줄 삽입

단축키: Ctrl+Enter(아래에 삽입) / Ctrl+Shift+Enter(위에 삽입) (macOS 동일)

커서가 줄 중간에 있을 때, 일반 Enter는 커서 위치에서 줄을 나눕니다. 하지만 현재 줄은 그대로 두고 그 아래(혹은 위)에 새 줄만 추가하고 싶을 때가 있습니다. 예를 들어 함수 호출 인자 중간에 커서가 있는데 그 아래에 새로운 코드를 쓰고 싶다면, 커서를 줄 끝까지 옮기는 수고 없이 이 단축키 하나로 해결됩니다.

5. 검색과 치환: 정규식으로 프로젝트 전체 바꾸기

단축키: Ctrl+Shift+F (macOS: Cmd+Shift+F) — 프로젝트 전체 검색 단축키: Ctrl+H (macOS: Cmd+Option+F) — 파일 내 찾아 바꾸기

Ctrl+Shift+F는 워크스페이스 전체에서 텍스트를 검색합니다. 파일 이름이 아니라 특정 문자열이나 패턴이 어느 파일들에 쓰이고 있는지 파악할 때, 예를 들어 특정 API 함수가 프로젝트 전체에서 몇 군데서 호출되는지 확인할 때 씁니다. 검색 결과 패널에서 정규식 모드를 켜면(.* 아이콘 클릭 또는 Alt+R), 캡처 그룹을 활용한 치환도 가능합니다. 예를 들어 console\.log\((.+)\)를 찾아서 logger.debug($1)로 한 번에 바꾸는 식입니다.

정규식 치환은 강력한 만큼 위험도 큽니다. 정규식 패턴이 의도보다 넓은 범위를 매칭하면, “미리 보기” 없이 바로 전체 적용을 눌렀을 때 손상된 코드가 수십 개 파일에 퍼질 수 있습니다. 그래서 실전에서는 반드시 다음 순서를 지키는 것이 안전합니다.

1. 검색 결과 패널에서 매칭된 항목들을 먼저 훑어보고 의도한 범위인지 확인합니다.
2. 파일이 많다면 전체 치환 대신 파일 단위로 하나씩 적용(Replace in file)하며 결과를 확인합니다.
3. 치환 전에 반드시 커밋되지 않은 변경 사항이 없는 깨끗한 상태에서 시작해서, 문제가 생기면 git checkout으로 되돌릴 수 있게 합니다.

이 검증 절차를 생략하고 “다 바꾸기”부터 누르는 습관은, 텍스트 몇 줄 아끼려다 리뷰에서 훨씬 큰 시간을 잡아먹는 전형적인 사례입니다. 정규식 치환은 빠르지만, 빠른 만큼 실수도 빠르게 퍼진다는 것을 항상 염두에 둬야 합니다.

6. 코드 탐색: 정의로 이동, 피킹, 심볼 검색

F12 — 정의로 이동

단축키: F12 (macOS 동일)

커서가 놓인 함수나 변수가 실제로 어디에서 정의되었는지 즉시 이동합니다. IDE의 정적 분석(TypeScript, Go, Python 언어 서버 등)을 활용하기 때문에, 이름만 보고 프로젝트 전체를 텍스트로 검색하는 것보다 훨씬 정확합니다. 특히 같은 이름의 함수가 여러 모듈에 존재할 때, 텍스트 검색은 전부 다 보여주지만 F12는 실제로 이 호출부가 참조하는 정확한 정의 하나로 데려다줍니다.

Alt+F12 — 정의 피킹(Peek)

단축키: Alt+F12 (macOS: Option+F12)

F12가 실제로 파일을 이동시키는 반면, Alt+F12는 현재 파일을 벗어나지 않고 인라인 창으로 정의를 보여줍니다. 지금 읽고 있는 코드의 맥락(스크롤 위치, 열린 탭)을 잃지 않으면서 “이 함수가 정확히 뭘 하는지”만 잠깐 확인하고 싶을 때 씁니다. 정의를 확인한 뒤 실제로 그 코드를 수정해야 한다면 피킹 창에서 바로 F12를 눌러 완전히 이동할 수도 있습니다. 반대로 확인만 하고 끝날 거라면 굳이 탭을 새로 열 필요가 없으므로, 탭이 늘어나는 것을 방지하는 효과도 있습니다.

Ctrl+Shift+O — 파일 내 심볼로 이동

단축키: Ctrl+Shift+O (macOS: Cmd+Shift+O)

지금 열려 있는 파일이 길 때, 스크롤 대신 함수/클래스/메서드 이름으로 바로 점프합니다. Ctrl+F로 텍스트를 검색하는 것과 다르게 이건 코드의 구조(함수, 클래스, 변수 선언)를 파싱한 결과를 보여주므로, 주석이나 문자열 안의 우연한 일치에 걸리지 않습니다. 500줄이 넘는 파일에서 특정 메서드를 찾을 때 스크롤보다 압도적으로 빠릅니다.

Ctrl+T — 워크스페이스 전체 심볼 검색

단축키: Ctrl+T (macOS: Cmd+T)

Ctrl+Shift+O가 현재 파일 안의 심볼만 찾는다면, Ctrl+T는 프로젝트 전체에서 클래스나 함수 이름으로 검색합니다. 어느 파일에 있는지는 모르지만 함수 이름은 정확히 아는 상황 — 예를 들어 리뷰 코멘트에서 언급된 validateUserInput이라는 함수를 찾아야 할 때 — 파일을 하나씩 열어보는 대신 이름으로 바로 찾아갑니다.

7. 리팩토링 단축키

F2 — 이름 변경(Rename Symbol)

단축키: F2 (macOS 동일)

변수, 함수, 클래스의 이름을 프로젝트 전체에서 안전하게 바꿉니다. 앞서 Ctrl+Shift+L과 비교했듯이, 이 명령은 언어 서버가 실제 참조 관계를 분석해서 바꾸기 때문에 같은 이름이지만 다른 스코프에 있는 변수는 건드리지 않습니다. 예를 들어 함수 매개변수 data의 이름을 바꾸고 싶을 때, 같은 파일의 다른 함수에 있는 별개의 data 변수는 그대로 둡니다. 이것이 단순 텍스트 치환과 리팩토링 도구의 근본적인 차이입니다.

다만 F2도 만능은 아닙니다. 동적 타입 언어(JavaScript, Python)에서는 타입 추론이 불완전할 경우 일부 참조를 놓칠 수 있으므로, 이름을 바꾼 뒤에는 반드시 테스트를 돌리거나 Ctrl+Shift+F로 이전 이름이 남아있지 않은지 한 번 더 검색하는 습관을 들이는 것이 안전합니다.

Ctrl+. — 빠른 수정 / 코드 액션

단축키: Ctrl+. (macOS: Cmd+.)

커서 위치에서 가능한 자동 수정이나 리팩토링 제안을 보여줍니다. import 문 자동 추가, 사용하지 않는 변수 제거, 함수를 화살표 함수로 변환, 인터페이스 추출 등 언어 서버와 린터가 제안하는 수정 사항이 여기 모입니다. 에러나 경고 밑줄이 보일 때 마우스로 전구 아이콘을 클릭하는 대신 커서만 그 줄에 두고 Ctrl+.을 누르면 같은 메뉴가 뜹니다. 작은 차이 같지만, 에러가 여러 줄에 흩어져 있을 때 마우스로 각 전구를 정확히 클릭하는 것보다 커서만 옮기고 단축키를 누르는 쪽이 훨씬 안정적입니다.

8. 터미널과 패널 관리

Ctrl+` — 통합 터미널 토글

단축키: Ctrl+\`` (백틱, macOS: Ctrl+“으로 동일)

에디터와 터미널 사이를 오갈 때 별도의 터미널 애플리케이션(iTerm, Windows Terminal 등)으로 창을 전환하는 대신, 에디터 안에서 바로 터미널을 열고 닫습니다. 창 전환은 운영체제 수준의 컨텍스트 스위칭이라 화면을 찾는 시각적 탐색이 추가되지만, 통합 터미널은 같은 창 안에서 포커스만 옮기므로 그 과정이 생략됩니다. 다만 대형 빌드나 로그를 오래 스트리밍해야 하는 작업은, 에디터의 렌더링 자원을 함께 쓰는 통합 터미널보다 독립된 터미널 앱을 쓰는 편이 더 안정적일 수 있습니다.

Ctrl+Shift+5 — 터미널 분할

단축키: Ctrl+Shift+5 (macOS: `Cmd+“)

하나의 터미널 패널 안에서 화면을 나눠 여러 세션을 동시에 띄웁니다. 프론트엔드 개발 서버와 백엔드 서버를 동시에 띄워두고 로그를 나란히 보거나, 한쪽에서는 테스트를 계속 돌리고 다른 쪽에서는 git 명령을 실행하는 식의 작업에 유용합니다. 다만 터미널을 3개 이상 분할하면 각 패널의 가로 폭이 좁아져 로그 줄바꿈이 잦아지므로, 화면 크기가 작다면 분할보다 탭 전환(Ctrl+PageDown/PageUp)이 더 낫습니다.

Ctrl+B — 사이드바 토글

단축키: Ctrl+B (macOS: Cmd+B)

코드 작성에 집중할 때 파일 탐색기 사이드바를 잠깐 숨겨서 편집 영역을 넓힙니다. 특히 노트북처럼 화면이 좁은 환경에서, 파일을 다 열어둔 뒤에는 사이드바가 필요 없어지는 경우가 많으므로 이 토글을 습관적으로 쓰면 화면 공간을 효율적으로 씁니다.

9. 단축키가 오히려 손해가 되는 경우

지금까지 다룬 단축키들은 전부 “반복되는 정형화된 작업”에서 강력합니다. 하지만 다음과 같은 상황에서는 단축키를 억지로 쓰려다 오히려 시간을 더 씁니다.

• 일회성 작업: 프로젝트 생애 전체에서 딱 한 번만 할 작업이라면, 단축키를 찾아보고 외우는 데 드는 시간이 그냥 마우스로 몇 번 클릭하는 것보다 길 수 있습니다. 단축키는 “자주 반복하는 동작”에 투자할 때 회수됩니다.
• 탐색적 작업: 코드베이스 구조를 처음 파악하는 단계에서는 Ctrl+P로 정확한 파일명을 치는 것보다, 파일 탐색기를 눈으로 훑으며 폴더 구조 자체를 이해하는 것이 목적에 더 맞습니다. 목적지를 모르는 상태에서는 목적지로 빨리 가는 도구가 의미가 없습니다.
• 정규식 치환의 과신: 앞서 언급했듯, 검증 없이 프로젝트 전체 치환을 실행하면 빠른 대신 실수도 빠르게 퍼집니다. 안전장치(미리 보기, 파일 단위 적용, 클린 상태에서 시작)를 생략할 정도로 서두를 이유가 없다면 속도보다 안전을 우선해야 합니다.
• 팀 협업 중 화면 공유: 페어 프로그래밍이나 리뷰 세션에서 자신만 아는 단축키를 남발하면, 상대방이 화면에서 무슨 일이 일어났는지 따라오지 못합니다. 이런 상황에서는 의도적으로 조금 느리더라도 마우스나 명시적인 동작으로 의사소통하는 것이 전체 세션의 효율을 높입니다.

마무리

VS Code 단축키를 익히는 것은 한 번에 전부 외우는 것이 아니라, 반복되는 작업 하나를 발견할 때마다 “이걸 더 빠르게 하는 방법이 있을까”라고 스스로 묻는 습관에 가깝습니다. 이 글에서 다룬 것 중에서도 실제로 매일 여러 번 쓰게 되는 것은 Ctrl+P(파일 열기), Ctrl+D/F2(멀티커서와 이름 변경), Alt+↑/↓(줄 이동), F12(정의로 이동) 정도입니다. 이 네다섯 개만 손에 붙어도 체감 속도 차이는 상당히 크고, 나머지는 필요할 때 커맨드 팔레트에서 그때그때 찾아 쓰는 것으로 충분합니다. 중요한 것은 단축키 개수를 늘리는 것이 아니라, 자신이 가장 자주 반복하는 동작이 무엇인지 스스로 파악하고 거기에 맞는 단축키부터 익히는 순서입니다.