CHAPTER 06 OF 10

🗺️

Plan Mode Mastery: The Explore-Plan-Implement-Commit Workflow

Plan Mode 마스터리 — Explore→Plan→Implement→Commit 4단계

Claude Code 고수들의 핵심 비밀은 구현 시간보다 탐색과 계획에 더 많은 시간을 투자하는 것이다 — Plan Mode는 그 투자를 강제하는 메커니즘이다.

🍌 NANO BANANA CHEATSHEET · CH 06

Overview

개관

대부분의 Claude Code 초보자가 저지르는 가장 큰 실수는 바로 구현으로 뛰어드는 것이다. 요청을 입력하고 Claude가 코드를 쏟아내기를 기다린다. 잘못된 방향이면 다시 요청하고, 또 기다린다. 이 패턴은 비효율적일 뿐만 아니라, 요청이 복잡할수록 낭비되는 토큰과 시간이 기하급수적으로 커진다.

해외 최고 고수들의 공통된 접근법은 반대다 — 전체 시간의 80%를 탐색과 계획에 투자하고, 구현은 명확한 계획이 확정된 후에 시작한다. Plan Mode는 Claude Code가 이 철학을 강제하는 메커니즘이다. 계획을 작성하고 멈추며, 사용자의 승인 없이 아무것도 실행하지 않는다.

🎯 Learning Goals

Shift+Tab으로 순환되는 3가지 모드의 차이를 설명한다
Plan Mode와 Thinking Mode(Extended Thinking)의 근본적 차이를 이해한다
Explore→Plan→Implement→Commit 4단계 워크플로우를 실제로 적용한다
좋은 계획과 나쁜 계획의 차이를 구분하고 계획을 개선하는 방법을 안다
Ultraplan을 언제 사용해야 하는지 판단한다

Sections

본문

3가지 모드 — Shift+Tab 사이클

Shift+Tab을 누를 때마다 모드가 순환된다:

모드	동작	사용 시점
Normal (기본)	도구 사용 전 권한 요청	일반 작업
Auto-Accept (1번 누름)	모든 도구 호출 자동 승인	반복 작업, 테스트 수정
Plan (2번 누름)	계획 작성 후 정지, 실행 없음	복잡한 기능, 리팩토링

Plan Mode는 claude --permission-mode plan CLI 플래그나 /plan 커맨드로도 진입할 수 있다.

Auto-Accept의 위험: 자동 승인 모드는 Claude가 모든 파일을 임의로 수정할 수 있게 된다. 명확한 태스크 범위가 있고 잘 정의된 CLAUDE.md가 있을 때만 사용하라. 탐색 단계에서는 절대로 사용하지 마라.

Plan Mode의 핵심 보장: 이 모드에서 Claude는 파일을 읽고 탐색할 수 있지만, 어떤 파일도 수정하지 않고 어떤 명령도 실행하지 않는다. 안전하게 아키텍처를 논의할 수 있다.

Explore → Plan → Implement → Commit — 4단계 워크플로우

이것이 해외 최고 고수들이 공통적으로 사용하는 패턴이다:

1단계: Explore (탐색) — Plan Mode에서

관련 파일을 열어보고 현재 구조를 파악하라
의존성과 영향 범위를 확인하라
이 단계에서 '모르는 것'을 발견하는 것이 목표

2단계: Plan (계획) — 여전히 Plan Mode에서

구현 전략을 단계별로 작성하라
각 단계마다 검증 기준을 포함하라
불확실한 부분을 명시하라
계획이 마음에 들 때까지 Claude와 반복적으로 논의하라

3단계: Implement (구현) — Normal 또는 Auto-Accept Mode로 전환

계획에 따라 구현
계획에서 벗어나는 발견이 있으면 멈추고 계획을 업데이트

4단계: Commit — 검증 후

모든 테스트 통과 확인
변경 범위 검토
커밋

핵심 원칙: 계획이 확정되기 전까지는 구현을 시작하지 않는다. 구현 중 계획에서 이탈해야 한다면, 구현을 멈추고 계획을 먼저 업데이트한다.

Plan Mode vs Thinking Mode — 자주 혼동되는 개념

이 두 가지는 근본적으로 다른 개념이다.

Plan Mode = 워크플로우 제어

Claude가 계획을 작성하고 멈춘다
사용자 승인 없이는 아무 것도 실행되지 않는다
Shift+Tab 또는 /plan으로 진입
계획 품질에 영향을 주는 것이 아니라, 계획 후 실행을 막는 것

Thinking Mode (Extended Thinking) = 추론 제어

Claude가 응답 전에 더 오래, 더 깊이 생각한다
실행은 여전히 일어난다
alwaysThinkingEnabled: true 설정
계획의 품질을 높이지만 실행을 막지는 않는다

Ultraplan (2026년 4월 도입):

/ultraplan 커맨드로 호출
더 깊은 컨텍스트 분석 + Plan Mode 결합
복잡한 멀티파일 리팩토링이나 아키텍처 변경에 적합
일반 Plan Mode보다 지연시간이 길지만 계획 품질이 높음

세 가지를 조합하면: Ultraplan(깊은 분석) + Thinking Mode(깊은 추론) = 가능한 가장 높은 계획 품질. 구현은 이 계획이 승인된 후에만 시작된다.

좋은 계획 vs 나쁜 계획

Plan Mode에서 좋은 계획을 얻기 위해서는 구체적인 컨텍스트를 제공해야 한다.

나쁜 요청 (모호한):

'인증을 구현해주세요'

좋은 요청 (구체적인):

'현재 Express 서버에 JWT 기반 인증을 추가해주세요. 기존 user 테이블 구조는 src/models/User.ts에 있고, 보안 요구사항은 CLAUDE.md에 있습니다. 영향받는 파일 목록, 변경 순서, 각 단계의 검증 방법을 계획으로 작성해주세요.'

좋은 계획이 포함해야 하는 요소:

## 구현 계획: JWT 인증

### 영향받는 파일
- src/middleware/auth.ts (새 파일)
- src/routes/auth.ts (새 파일)
- src/routes/users.ts (수정: 인증 미들웨어 추가)

### 구현 순서
1. auth.ts 미들웨어 생성
   → 검증: 단위 테스트 통과
2. auth 라우트 생성 (/login, /logout)
   → 검증: Postman으로 토큰 발급 확인
3. users 라우트에 미들웨어 적용
   → 검증: 기존 테스트 통과, 인증 없이 접근 시 401

### 의존성
- jsonwebtoken 패키지 필요
- JWT_SECRET 환경 변수 필요 (.env에 추가)

이 수준의 계획이 나오기 전까지 '계획이 충분히 구체적이지 않습니다, 단계를 더 세분화해주세요'로 반복 요청하라.

💡 Analogy · 비유

건축가와 시공업자

건물을 짓는 과정을 생각해보자. 건축가와 의뢰인이 수개월 동안 설계도를 다듬는다. 의뢰인의 요구를 반영하고, 구조 엔지니어의 검토를 받고, 각종 규제를 확인하고, 예산을 계산한다. 설계도가 완전히 확정된 후에야 첫 삽을 뜬다.

이유는 간단하다 — 설계 단계에서 변경하는 것이 시공 단계에서 변경하는 것보다 100배 저렴하다. 이미 지어진 벽을 허무는 것은 비용이 엄청나다.

코딩도 마찬가지다. Plan Mode에서 계획을 수정하는 것은 토큰 몇 개다. 이미 작성된 코드를 삭제하고 다시 쓰는 것은 많은 토큰, 시간, 그리고 에너지다. 해외 고수들이 구현 전 탐색/계획에 80%의 시간을 쓰는 이유다 — 그게 실제로 더 빠르기 때문이다.

Plan Mode에서 실제로 주고받는 대화 흐름이다. 처음부터 구체적인 컨텍스트를 제공할 때와 그렇지 않을 때의 차이를 보여준다.

markdown

# Plan Mode 활용 예시 — 좋은 패턴

# 1. /plan 으로 Plan Mode 진입
# 2. 구체적인 컨텍스트와 함께 요청:

사용자:
현재 상황:
- Next.js 14 + Prisma + PostgreSQL 프로젝트
- src/app/api/users/ 에 CRUD API 있음
- 현재 인증 없음

목표:
- JWT 기반 인증 추가
- /api/users/* 모든 엔드포인트 보호
- src/lib/auth.ts에 토큰 검증 로직

요구사항:
- 기존 테스트 통과 유지
- TypeScript 에러 0개
- .env.local에 JWT_SECRET 추가 필요

계획을 작성해주세요. 영향받는 파일, 구현 순서,
각 단계 검증 방법을 포함해주세요.

# Claude의 계획 (Plan Mode - 실행 없음):
Claude:
## 구현 계획: JWT 인증 시스템

### 신규 파일
1. src/lib/auth.ts — JWT 서명/검증 유틸리티
2. src/middleware/requireAuth.ts — Next.js 미들웨어

### 수정 파일  
3. src/app/api/users/route.ts — requireAuth 적용
4. src/app/api/users/[id]/route.ts — requireAuth 적용
5. .env.local — JWT_SECRET 추가
6. package.json — jsonwebtoken 의존성 추가

### 구현 순서 및 검증
1. pnpm add jsonwebtoken @types/jsonwebtoken
   → 검증: pnpm build 성공
2. src/lib/auth.ts 생성
   → 검증: 단위 테스트 (test/lib/auth.test.ts)
3. src/middleware/requireAuth.ts 생성
   → 검증: 단위 테스트
4. 기존 라우트에 미들웨어 적용
   → 검증: 기존 테스트 통과 + 인증 없이 401 반환

### 주의사항
- 기존 테스트가 인증을 통과해야 하므로
  테스트에 mock 토큰 주입 필요

# 사용자: 계획 승인. 구현 시작하세요.
# → Normal/Auto-Accept 모드로 전환 후 구현 시작

이 흐름의 핵심은 Claude가 Plan Mode에서 아무것도 실행하지 않는다는 것이다. 파일을 읽고, 구조를 파악하고, 계획을 작성하지만 변경하지 않는다. 사용자가 '계획 승인'을 하기 전까지. 계획 단계에서 '주의사항'이 발견된 것도 중요하다 — 기존 테스트가 인증을 통과해야 한다는 사실을 구현 전에 발견했다.

🏭 현업에서의 평가

Plan Mode를 활용하는 개발자와 그렇지 않은 개발자의 차이는 복잡한 기능을 구현할 때 두드러진다. 전자는 명확한 계획을 가지고 예측 가능하게 진행하고, 후자는 반복적인 수정과 롤백을 반복한다.

✅ 시니어가 보는 것

Plan Mode를 사용하는 습관이 있는지
계획이 충분히 구체적인지 (파일 목록, 순서, 검증 기준)
계획과 실제 구현의 편차를 어떻게 관리하는지

⚠️ 레드 플래그

Plan Mode를 알고 있지만 사용하지 않는 경우
계획을 승인하자마자 바로 수정하는 경우 (계획을 읽지 않음)
구현 중 계획을 벗어나도 계획을 업데이트하지 않는 경우

🎤 예상 인터뷰 질문

Plan Mode와 Auto-Accept Mode를 각각 어떤 상황에서 사용하시나요?
계획이 구현 중 현실과 맞지 않을 때 어떻게 처리하시나요?
Ultraplan과 일반 Plan Mode의 실제 품질 차이를 경험한 사례가 있나요?

숙달 vs 익숙함: 단순히 아는 수준: Plan Mode의 존재를 안다. 마스터 수준: 복잡도에 따라 Normal/Plan/Ultraplan을 의도적으로 선택하고, 계획 단계에서 적극적으로 피드백을 주어 계획 품질을 높이며, 구현 전 80% 투자 원칙을 팀 문화로 만들었다.

Key Takeaways

핵심 정리

80%를 탐색/계획에 투자하라

해외 최고 고수들의 공통 원칙. 구현 전 충분한 계획이 실제로 더 빠른 결과를 낸다.

Shift+Tab으로 3가지 모드 순환

Normal → Auto-Accept → Plan. 복잡한 기능은 Plan Mode로, 반복 수정은 Auto-Accept로.

Plan Mode ≠ Thinking Mode

Plan Mode는 실행을 막는 워크플로우 제어. Thinking Mode는 추론 깊이 제어. 둘은 독립적이고 조합 가능하다.

계획에 검증 기준을 포함하라

각 구현 단계마다 검증 방법을 포함한 계획이 좋은 계획이다. '완료'의 정의가 없는 계획은 불완전하다.

계획 벗어나면 먼저 업데이트

구현 중 계획과 다른 것을 발견하면, 구현을 멈추고 계획을 먼저 업데이트한다. 계획이 항상 현실을 반영해야 한다.

← Ch05 · Hooks: Event-Driven Automation Ch07 · Multi-Agent Orchestration: Dynamic Workflows →