Claude Code Plan Mode를 제대로 쓰는 법: Shift+Tab 이후가 진짜 시작이다

Plan Mode를 안 쓰면 무슨 일이 벌어지는가

Claude Code를 처음 깔았을 때 나는 Plan Mode를 몰랐다. 그래서 어떻게 됐냐 하면, 30분짜리 작업 하나를 시킬 때마다 결과물을 뜯어고치는 데 또 30분이 걸렸다. AI는 일단 코드부터 쓰고 봤고, 나는 일단 결과부터 보고 후회했다.

Plan Mode는 그 사이에 한 단계를 끼워 넣는다. 코드를 쓰기 전에 계획을 세우고, 사용자가 승인할 때까지 파일을 건드리지 않는 모드다. Shift+Tab 한 번이면 진입한다. 단축키 하나에 작업 품질이 체감으로 달라진다.

진입과 종료

Claude Code 입력창에서 Shift+Tab을 누르면 모드가 토글된다. 화면 상단에 plan mode on 같은 표시가 나타나면 활성화된 거다.

> 회원가입 페이지에 이메일 인증을 추가해줘
[plan mode on]

이 상태에서 명령을 보내면 Claude는 파일을 읽고, 영향 받는 파일을 분석하고, 단계별 구현 계획을 마크다운으로 보여준다. 코드는 한 줄도 안 쓴다.

계획이 마음에 들면 ExitPlanMode를 승인하라는 프롬프트가 뜨고, 거기서 Yes를 누르면 그제서야 코드 작업이 시작된다. 마음에 안 들면 "DB 부분은 빼고 다시"라고 추가 지시할 수 있다.

빠져나오는 방법은 두 가지다. 한 번 더 Shift+Tab을 누르거나, 계획을 승인하면 자동으로 종료된다.

언제 Plan Mode를 켜야 하는가

모든 작업에 다 켤 필요는 없다. 오히려 단순한 작업에는 방해가 된다. 내가 정리한 기준은 이렇다.

Plan Mode가 필수인 상황

• 여러 파일을 수정하는 기능 추가 — 회원가입 같은 페이지 추가, 새 API 엔드포인트, 인증 미들웨어 같은 것들
• 리팩토링 — 함수 분리, 폴더 구조 변경, 네이밍 일괄 수정
• 마이그레이션 — 라이브러리 버전 업, 프레임워크 업데이트, DB 스키마 변경
• 모르는 코드베이스에서의 작업 — 새로 합류한 프로젝트, 처음 보는 모듈

이런 상황에서는 Claude가 잘못 짠 코드를 되돌리는 비용보다, 미리 계획을 검토하는 비용이 훨씬 적다.

Plan Mode를 끄는 게 나은 상황

• 타이포 수정, 변수명 변경 같은 단발성 작업
• 이미 계획이 머릿속에 있고 그대로 받아쓰게 하는 작업
• 에러 메시지를 보고 즉시 고치는 디버깅 — 빠른 반복이 중요할 때

매번 계획서를 읽고 승인하는 것도 시간이다. 작업이 작을수록 Plan Mode 비용이 작업 비용보다 커진다.

실전에서 효과 본 패턴

1. 계획서가 너무 짧으면 의심한다

Plan Mode에서 나온 계획서가 3줄이면 Claude가 코드를 충분히 안 읽었다는 신호다. "이 변경이 영향을 주는 다른 파일도 같이 정리해줘"라고 다시 시키면, 그제서야 Glob, Grep을 돌려서 더 많은 컨텍스트를 본다.

2. "왜 이렇게 하려고 하는지" 한 줄을 요구한다

계획서에 단계만 있고 근거가 없으면, AI가 관습적으로 짜는 건지 의도가 있는 건지 구분이 안 간다. "각 단계 옆에 한 줄로 이유를 적어줘"라고 시키면 어색한 단계가 드러난다. 거기서 잡을 버그가 본격 작업 들어간 다음에 잡는 버그보다 훨씬 싸다.

3. 계획을 분리해서 실행한다

큰 기능 하나를 한 번에 시키지 말고, 계획서가 나오면 단계별로 끊어서 실행한다. 단계 1을 끝내고 결과를 검증한 다음 단계 2로 넘어가는 식이다. Plan Mode의 진짜 가치는 "AI에게 한 번에 다 시키는 일"을 줄이는 데 있다.

자주 만나는 함정

함정 1: 계획서가 항상 맞다고 믿는다

Plan Mode가 켜져 있다고 해서 계획이 정답인 건 아니다. Claude는 여전히 추측을 한다. 특히 코드베이스의 도메인 규칙(예: "결제는 항상 트랜잭션 안에서") 같은 건 모르는 채 그럴듯한 계획을 만든다. 계획서는 시작점일 뿐, 도메인 검증은 사람이 해야 한다.

함정 2: 계획만 하고 실행을 안 시킨다

Plan Mode에 너무 익숙해지면, 계획서를 읽고 만족한 다음 실행은 다음 날로 미루게 된다. 그러면 컨텍스트가 사라져서 다시 처음부터 시작해야 한다. 계획서가 나오면 그 자리에서 승인하거나, 안 할 거면 닫는다. 어중간하게 두면 가장 비싸다.

함정 3: ExitPlanMode를 무지성 승인한다

승인 프롬프트가 뜨면 그냥 Yes를 누르고 싶은 유혹이 있다. 하지만 그게 Plan Mode를 켠 의미를 무력화한다. 계획서를 처음부터 끝까지 한 번 읽는 데 1~2분이면 충분하다. 그 1분이 30분짜리 잘못된 구현을 막는다.

다른 모드와의 관계

Plan Mode는 Superpowers의 brainstorming 스킬, OMC의 /deep-interview와 비슷한 결을 가진다. 모두 "코드 쓰기 전에 한 번 멈춘다"는 철학이다.

차이는 깊이다. Plan Mode는 가장 가볍다. 단축키 하나로 토글되고, 계획서 한 장이 나온다. brainstorming은 사용자와 대화로 요구사항을 파고든다. deep-interview는 모호함을 수치화해서 게이팅한다.

작업 규모가 작으면 Plan Mode, 중간이면 brainstorming, 크면 deep-interview. 이 순서로 무게를 늘리면 된다.

정리

Plan Mode의 본질은 "AI가 코드를 쓰기 전에 사람이 한 번 더 본다"는 강제 장치다. Shift+Tab 하나로 켜고 끌 수 있는 게 핵심이다.

추천은 단순하다. 여러 파일에 손이 가는 작업이면 일단 켠다. 계획서가 만족스러우면 승인, 아니면 거기서 수정. 계획서를 읽는 1~2분이 잘못된 30분을 막는다는 걸 한 번만 경험해보면, 그 다음부터는 자연스럽게 손이 Shift+Tab으로 간다.