갑자기 구현하게 하지 마라 — Plan Mode와 계획 주도로 Claude Code의 폭주를 막는 패턴

Claude Code에게 조금 규모가 큰 의뢰를 하면, 이런 경험을 해본 적 없으신가요?

• 「로그인 기능을 수정해줘」라고 부탁했더니, 부탁하지 않은 파일까지 수정하기 시작했다
• 5개의 파일이 편집된 후에야 「아, 그런 설계가 아니야」라고 깨닫고, 전부 되돌렸다
• 도중에 방침이 어긋나고 있는데도, 멈출 틈도 없이 커밋(Commit) 직전까지 진행되었다
• 결국
  git checkout .

으로 전부 버리고, 처음부터 다시 지시한다

이것은 「Claude가 똑똑하지 않아서」 발생하는 일이 아닙니다. 갑자기 구현(Implementation) 단계로 돌입시켰기 때문에 발생하는 일입니다.

인간 엔지니어도 갑자기 키보드를 두드리기 시작하는 사람은 없습니다. 먼저 「무엇을 어떻게 바꿀 것인가」를 머릿속에서 (혹은 종이에) 구성한 다음에 손을 움직입니다. Claude Code에게도 똑같은 일을 시키면 됩니다. 그것이 바로 **Plan Mode(계획 모드) / 계획 주도(Plan-driven)**입니다.

이 기사에서는 「갑자기 구현」에서 「계획을 세우게 하고 → 인간이 승인한 뒤에 구현」으로 전환하기 위한 구체적인 패턴을 소개합니다. 모두 오늘 세션부터 바로 시도해 볼 수 있습니다.

Plan Mode는 Claude Code가 파일을 일절 편집하지 않고, 무엇을 할 것인지에 대한 계획만을 제시하는 모드입니다.

통상 모드(Normal Mode)와의 차이점은 다음과 같습니다.

통상 모드:
당신 「X를 수정해줘」
→ Claude가 갑자기 파일을 편집하기 시작함
...

포인트는, 승인 게이트(Approval Gate)가 중간에 한 층 끼어든다는 점입니다. 계획 단계라면, 방침이 어긋나 있더라도 파일은 단 한 줄도 바뀌지 않았습니다. 「아니, 그게 아니야」라고 말하는 비용이 거의 제로에 가깝습니다. 구현 후에 되돌리는 것과는 재작업의 무게가 차원이 다릅니다.

Claude Code(터미널 버전)에서는 Shift + Tab을 누를 때마다 모드가 전환됩니다. Plan Mode에 들어가면 입력창 근처에 모드 표시가 나타납니다.

통상 모드 → (Shift+Tab) → 자동 승인 모드 → (Shift+Tab) → Plan Mode → ...

주의: 모드 전환 키나 UI 표기는 버전에 따라 달라질 수 있습니다. 사용 중인 Claude Code에서 Shift + Tab을 몇 번 눌러 현재의 모드 표시를 확인해 보세요. 「계획을 세운 뒤에 구현해. 승인할 때까지 파일은 건드리지 마」라고 첫 프롬프트(Prompt)에서 명시해도 실질적으로 동일한 계획 주도 운용이 가능합니다.

키로 전환하지 않더라도, 프롬프트로 제약하는 것만으로도 효과는 나타납니다.

이 태스크는 우선 계획만 내놓으세요.
- 해당 파일을 읽고 현상을 파악하는 것은 OK
- 단, 파일의 편집·생성·삭제는 승인 전에는 일절 하지 말 것
...

구체적인 예로 살펴보겠습니다. 「폼의 유효성 검사(Validation)를 추가해줘」라는 의뢰를 가정해 봅시다.

Before (갑자기 구현):

당신 「등록 폼에 유효성 검사를 추가해줘」
Claude (즉시):
- RegisterForm.tsx를 편집 (Yup 도입)
...

5개의 파일이 바뀌고 라이브러리까지 추가된 후에야 전제 조건의 어긋남이 발견됩니다. 되돌리기와 재지시로 시간이 낭비됩니다.

After (Plan Mode로 계획을 먼저 제시):

당신 「등록 폼에 유효성 검사를 추가해줘. 우선 계획만 내놓아줘」
Claude (읽기만 함):
계획:
...

라이브러리 선정이라는 되돌리기 비용이 높은 분기점을, 파일을 건드리기 전에 제거할 수 있었습니다. 이것이 계획 주도의 본질입니다.

Before (갑자기 구현)	After (계획 주도)
방침 어긋남의 발견 타이밍	구현 후
...

Plan Mode는 「계획을 내놓게 하는 것」만으로는 절반에 불과합니다. 나머지 절반은 그 계획을 인간이 어떻게 리뷰(Review)하느냐입니다. 계획을 대충 훑어보고 반사적으로 「OK」를 누른다면, 갑자기 구현하는 것과 큰 차이가 없습니다.

승인 버튼을 누르기 전에, 최소한 이 5가지를 확인하십시오.

「관련 파일을 수정하겠습니다」와 같은 모호한 계획은 위험 신호입니다. 어떤 파일을, 몇 개의 파일을 건드리는지가 열거되어 있는지 확인하십시오. 리스트가 예상보다 많다면 태스크가 너무 크거나, Claude가 불필요한 일을 하려고 하는 것입니다.

좋은 계획:
변경: src/auth/login.ts, src/auth/session.ts (2개 파일)
신규: src/auth/token.ts
...

「로그인 버그 수정」을 부탁했는데, 계획에 「덤으로 인증 전체를 리팩터링(Refactoring)"이 섞여 있지는 않은가. 부탁하지 않은 것이 섞여 있다면 깎아내게 합니다. 스코프(Scope) 팽창은 리뷰에서 가장 놓치기 쉽고, 나중에 가장 큰 영향을 미치는 포인트입니다.

라이브러리 추가, DB 스키마 변경, 공통 타입 변경, 공개 API의 시그니처(Signature) 변경——이것들은 한 번 도입하면 다시 걷어내기가 매우 힘듭니다. 계획에 이것들이 포함되어 있다면, 승인 전에 반드시 명시적으로 확인합니다.

「이 프로젝트는 Zod를 사용하고 있다」, 「에러는 공통의 AppError로 던진다」와 같은 기존 규칙을 무시하고 있지는 않은가. 계획 단계에서 「기존의 어떤 패턴에 맞출 것인가」가 적혀 있다면 안심할 수 있습니다. 적혀 있지 않다면 다시 되묻습니다.

구현 후에 어떻게 올바름을 확인할 것인지가 계획에 포함되어 있는가. 「구현한다」라고만 적힌 계획은 동작이 확인되지 않은 코드를 양산하는 온상입니다.

리뷰 관점을 체크리스트로 만들면 다음과 같습니다.

관점	확인 포인트	NG일 경우
변경 파일	구체적으로 열거되어 있는가	다시 열거하게 함
...

계획 주도(Plan-driven) 방식에서 흔히 발생하는 오해는, 「계획은 한 번에 승인하는 것」이라는 고정관념입니다. 실제로는 반대이며, 계획을 읽고 신경 쓰이는 점을 지적하여 계획 자체를 수정하게 만드는 왕복 과정이야말로 가치의 핵심입니다.

당신 「계획을 내놔」
Claude 「계획 A (5개 파일 변경, 라이브러리 X 추가)"
당신 「라이브러리 X는 넣지 마. 기존의 자체 구현을 확장하는 방향으로 계획을 수정해」
...

이 왕복 과정은 파일을 한 줄도 바꾸지 않고 이루어집니다. 코드를 쓰기 전에 설계를 다듬는다——이것은 소프트웨어 개발에서 예전부터 강조되어 온 것을 Claude Code 상에서 재현하고 있을 뿐입니다. 계획 단계에서의 한 번의 왕복은, 구현 후의 10번의 재작업(Rollback)을 방지합니다.

간단한 태스크(오타 수정, 한 줄의 상수 변경)에는 계획 주도가 필요 없습니다. 오히려 오버헤드(Overhead)입니다. 계획 주도가 극적으로 효과를 발휘하는 것은, 태스크가 복잡해질수록입니다. 이유는 세 가지가 있습니다.

태스크가 복잡해지면 「A 방식인가 B 방식인가」라는 설계상의 분기(Branch)가 늘어납니다. 갑자기 구현하게 하면, Claude는 그 분기를 멋대로 하나 선택해서 진행합니다. 선택이 틀렸다면 전부 다시 해야 합니다. 계획 단계라면, 분기에 다다랐을 때 당신에게 물어봐 줄 것입니다.

복잡한 태스크 = 분기의 연속
분기 1: 상태 관리는 기존의 Context인가 신규 Store인가
분기 2: API는 REST 그대로 확장할 것인가 GraphQL을 도입할 것인가
...

단순한 태스크라면, 실수하더라도 파일 하나만 되돌리면 됩니다. 복잡한 태스크는 여러 파일이 얽혀 있기 때문에, 하나의 설계 실수가 모든 파일로 파급됩니다. 되돌리는 비용이 태스크의 복잡도에 비례하여 급증하기 때문에, 파일을 건드리기 전에 방향을 확정 짓는 계획 주도의 가치가 커집니다.

복잡한 태스크에서 갑자기 구현하게 했다가 도중에 방침이 어긋나면, 어긋난 구현을 시도하며 시행착오를 겪는 과정이 전부 컨텍스트(Context)를 잡아먹습니다. 계획 단계에서 방향을 확정해 두면, 구현 페이즈는 일직선으로 진행되어 무의미한 시행착오로 컨텍스트를 낭비하지 않을 수 있습니다.

태스크의 복잡도와 계획 주도의 효과를 정리하면 다음과 같습니다.

태스크 복잡도	예시	계획 주도 필요 여부
극소	오타 수정 · 상수 변경	불필요 (오버헤드)
...

「헷갈리면 계획부터」를 기본 원칙으로 삼고, 명백히 작을 때만 통상 모드로 직행합니다. 이 선을 긋는 것이 실무적입니다.

마지막으로, 계획 주도를 「내키면 하는 것」에서 「기본값(Default)」으로 만들기 위한 작은 팁 세 가지.

1. CLAUDE.md에 한 문장 넣기

프로젝트의 CLAUDE.md에 방침을 적어 두면, 매번 프롬프트로 지시하지 않아도 계획 주도가 잘 작동하게 됩니다.

## 구현 진행 방식
- 여러 파일에 걸친 변경은 먼저 계획(변경 파일 · 변경 내용 · 영향 범위)을 제시하고, 승인을 얻은 후 구현한다
...

2. 「계획 → 승인 → 구현」을 입버릇으로 만들기

첫 프롬프트 끝에 「먼저 계획만」이라고 붙이는 것을 습관화합니다. 단 몇 글자만으로 되돌아갈 리스크를 크게 낮출 수 있습니다.

3. 계획이 허술하다면 구현시키지 않기

계획이 모호한 상태에서 「일단 승인」해 버리는 것이 가장 아까운 사용법입니다. 허술한 계획은 허술한 구현의 예고입니다. 계획의 해상도가 낮다고 느껴지면, 「더 구체적으로. 어떤 파일을 몇 줄 변경할 것인가」라고 다듬은 후에 승인합니다.

포인트	요점
Plan Mode란	파일을 편집하지 않고 계획만 출력하게 하여, 승인 게이트 (Approval Gate)를 거치는 모드
진입 방법	Shift+Tab으로 모드 전환, 또는 프롬프트로 "계획만"이라고 제약하기
Before/After	어긋남의 발견 시점이 "구현 후"에서 "계획 단계"로 앞당겨짐
계획 리뷰	변경 파일/스코프 (Scope)/되돌리기 비용 (Rollback Cost)/규약/검증의 5가지 관점에서 확인
계획의 왕복	단 한 번의 승인이 아니라, 계획 자체를 수정하게 만드는 왕복 과정이 가치의 핵심
복잡한 태스크에서 효과적인 이유	분기가 많고, 되돌리기 비용이 높으며, 컨텍스트 (Context)의 낭비를 방지할 수 있기 때문

Claude Code의 "폭주" 대부분은 지능의 문제가 아니라 승인 게이트 (Approval Gate)를 두지 않은 설계의 문제입니다. 계획을 먼저 내놓게 하고, 인간이 방향을 확인한 뒤 구현에 들어갑니다. 이 하나의 게이트를 사이에 두는 것만으로도, 되돌리는 횟수가 체감상 급격히 줄어듭니다.

우선 다음의 여러 파일에 걸친 태스크에서, 프롬프트 끝에 "먼저 계획만 출력해줘"라고 붙이는 것부터 시도해 보세요.

본 기사의 내용을 실제 프로젝트에서 테스트하려면, 토대가 되는 CLAUDE.md와 폴더 구성이 있으면 원활합니다. 제가 사용하고 있는 스타터 구성을 무료로 공개하고 있습니다.

무료 스타터 (GitHub):

더 나아가, 워크플로우 (Workflow)나 서브 에이전트 (Sub-agent) 설계를 "실행 가능한 스킬 파일"로 정리한 패키지도 준비되어 있습니다. 로컬에서 /명령어로 호출할 수 있는 형태입니다.

스타터 팩 (¥1,980): CLAUDE.md 템플릿 7종 · Hooks · MCP 설정
https://streamsolty.gumroad.com/l/gliwz

워크플로우 OS (¥9,800): 79개의 스킬 + 워크플로우 3개 + 프롬프트 10종

우선 무료 리포지토리 (Repository)부터 시도해 보시고, 더 체계적으로 사용하고 싶어지면 검토해 주셔도 충분합니다. 기사의 내용만으로도 효과는 나타납니다.

최신 팁은 X에서도 발신하고 있습니다: @k___n___t_1125