Claude Code의 Plan Mode: 단계별 가이드와 2026년의 4단계

추가 지침은 Ailoot 문서에서 확인할 수 있습니다.

Plan Mode란 무엇이며, 이것만으로는 왜 충분하지 않을까요?#

일반 모드에서 Claude Code는 곧바로 코드를 작성하므로, 진행 상황을 살피지 않으면 여러 파일에 걸친 diff가 갑자기 나타날 수 있습니다. Plan Mode는 순서를 뒤집습니다. 먼저 조사하고 계획한 뒤 승인받고, 그다음 변경합니다.

Anthropic은 공식 문서에서 Plan Mode를 다음과 같이 설명합니다.

간단해 보이지만 핵심적인 변화가 숨어 있습니다. Plan Mode는 작업의 리듬을 바꿉니다. 먼저 합의하고, 그다음 실행합니다. 단순한 외형상의 조정이 아니라 모드 자체의 변화입니다. 바이브 코딩을 하는 사람들의 어려움은 AI 에이전트가 서두르는 경향이 있다는 점입니다. 일반 모드에서 “Google 인증을 추가해”라고 요청하면 Claude는 1분 만에 코드를 작성하지만, 파일의 절반은 잘못 선택될 수 있습니다. Plan Mode에서는 같은 요청이 텍스트 계획으로 바뀌므로, 코드를 건드리기 전에 2분 동안 읽고 수정할 수 있습니다.

국제 가이드에서는 아무도 언급하지 않는 함정이 있습니다. Plan Mode만으로는 약한 도구입니다. 계획은 현재 대화에만 존재합니다. 창을 닫으면 계획은 사라집니다. 다른 에이전트에게 넘길 수도 없습니다. 버전이나 기록도 없습니다. 작업이 크다면(30개 파일로 된 모듈 리팩터링, 새 데이터베이스로의 마이그레이션 등) 계획은 곧 컨텍스트 창의 한계에 부딪혀 품질이 떨어지기 시작합니다.

그래서 Plan Mode는 저장소의 plans/ 폴더와 함께 쓰면 효과적입니다. 계획을 plans/2026-05-21-google-oauth.md로 저장하고 체크박스가 있는 단계별로 나누면, 다음 에이전트가 이어받을 수 있습니다. 이것이 컨텍스트 엔지니어링의 방식입니다. 프롬프트를 작성하는 도중이 아니라 그 전에 컨텍스트를 관리합니다.

Claude Code에서 Plan Mode를 활성화하려면 어떻게 해야 하나요?#

세션 중 가장 빠른 방법은 키보드를 사용하는 것입니다.

Shift+Tab           # cycles through modes: default → acceptEdits → plan

두 번 누르면 터미널 하단에 ⏸ plan mode on 표시자가 나타납니다. 세 번째로 누르면 일반 모드로 돌아갑니다. 작업이 커지고 있다고 느껴질 때 즉석에서 전환할 수 있어 가장 편리한 방법입니다.

두 번째 방법은 단일 프롬프트 앞에 접두사를 붙이는 것입니다.

/plan write a plan to migrate the database from MySQL to Postgres

자동 수락 모드에 있지만 세션 전체의 모드를 바꾸고 싶지 않을 때 유용합니다. 요청 하나만 Plan Mode로 처리하고, 그다음 작업은 이전처럼 계속됩니다.

세 번째 방법은 세션을 시작할 때 설정하는 것입니다.

claude --permission-mode plan

작업에 계획이 필요하다는 것을 미리 알고 있을 때 사용하세요. 예를 들어 대규모 리팩터링이나 마이그레이션을 시작하기 전입니다.

네 번째 방법은 프로젝트의 .claude/settings.json에서 기본값을 설정하는 것입니다.

{
  "permissions": {
    "defaultMode": "plan"
  }
}

언제 유용할까요? 어떤 변경이든 인접한 모듈에 영향을 줄 수 있는 복잡한 시스템을 팀이 다룰 때입니다. 이때 기본 Plan Mode를 사용하면 실수로 변경하는 일을 막을 수 있습니다.

자주 놓치는 다섯 번째 요령은 Ctrl+G를 눌러 텍스트 편집기에서 계획을 여는 것입니다. 계획이 거의 맞지만 2-3개 항목의 표현을 바꾸거나 제약 조건을 추가해야 할 때 사용하세요. 직접 수정하고 저장하면 Claude가 수정한 버전을 이어서 사용합니다.

Plan Mode에서 Anthropic이 제시하는 정석적인 4단계, Explore, Plan, Implement, Commit은 무엇인가요?#

많은 가이드가 3단계(Explore-Plan-Execute) 또는 2단계(Plan-Implement)만 설명합니다. 이는 단순화한 것입니다. Anthropic은 공식 모범 사례 가이드에서 정확히 4단계를 설명합니다. 이 차이는 중요합니다. Commit을 별도의 단계로 두면 “몇 가지를 더 손봤으니 나중에 커밋해야지”라고 미루지 않고 결과를 기록하게 됩니다. 이런 미루기가 작업을 잃어버리는 가장 흔한 원인입니다.

계획이 정확할수록 구현에 필요한 반복 횟수가 줄어듭니다. 계획에 10분을 쓰면 구현은 프롬프트 한 번으로 끝납니다. 1분 만에 대충 계획을 세우면 한 시간 동안 수정하게 됩니다.

Google OAuth를 추가하는 경우를 예로 들어 4단계가 어떻게 진행되는지 살펴보겠습니다(Anthropic Docs의 예시).

각 단계의 프롬프트도 다릅니다. Explore: “/src/auth를 읽고 세션과 로그인을 어떻게 처리하는지 파악해.” Plan: “Google OAuth를 추가하고 싶어. 어떤 파일을 바꿔야 해? 계획을 작성해.” Implement: “계획에 따라 OAuth 흐름을 구현하고 테스트를 작성해. 테스트 전체를 실행하고 실패를 수정해.” Commit: “설명적인 메시지로 커밋하고 PR을 열어.”

중요한 점은 Plan Mode가 Claude의 조사용 명령 실행을 막지 않는다는 것입니다. Read, LS, Glob, Grep, web fetch 및 탐색용 셸 명령은 허용됩니다. Edit, Write, 그리고 파일시스템을 변경하는 모든 작업만 금지됩니다. 따라서 Claude는 프로젝트 구조를 읽고 git log를 실행하고 테스트를 살펴볼 수 있지만, 실수로 무언가를 바꾸지는 못합니다.

Claude의 계획을 읽고 승인 여부를 판단하려면 어떻게 해야 하나요?#

Claude가 계획 작성을 마치면 다음 작업을 위한 옵션을 표시합니다.

• 승인하고 자동 모드로 시작
• 승인하고 편집 수락
• 승인하고 각 편집을 직접 검토
• 피드백을 주며 계획 계속 작성
• Ultraplan으로 다듬기(브라우저 검토)

계획을 승인할지 판단하는 능력은 Plan Mode의 핵심 기술입니다. 무심코 “승인”을 눌렀다가 나중에 커밋을 되돌려야 하는 일은 흔합니다. 아첨하는 AI는 빠르게 답하려 하고, 사용자는 더 빨리 코드로 넘어가고 싶어 합니다. 둘 다 잘못된 방향입니다.

좋은 계획은 다음 7가지 기준을 충족합니다.

1. 구체적인 파일 이름. “auth를 업데이트하겠습니다”가 아니라 “src/auth/login.ts:42-58을 수정하고, src/auth/oauth-callback.ts를 만들며, src/auth/session.ts:103을 업데이트하겠습니다”라고 해야 합니다.
2. 순서가 명시되어 있습니다. 계획이 단계나 순서로 나뉘어야 합니다. “이 모든 것을 어딘가에서 하겠습니다”라고 하면 안 됩니다.
3. 외부 의존성이 명시되어 있습니다. 새 라이브러리가 필요하면 목록에 있어야 합니다. 환경 변수가 필요하면 함께 표시해야 합니다.
4. 위험 요소가 나열되어 있습니다. 좋은 계획은 “마이그레이션으로 기존 세션이 깨질 수 있으므로 X를 확인해야 합니다”라고 말합니다. 나쁜 계획은 부작용을 언급하지 않습니다.
5. 성공 기준이 있습니다. “test/auth 테스트가 통과하고, 린터에 오류가 없으며, 개발 서버가 오류 없이 시작된다”와 같은 기준입니다.
6. ‘근거 없이 지어낸’ 가정이 없습니다. Claude가 “라이브러리 Z를 사용하겠습니다”라고 하면 프로젝트에 실제로 설치되어 있는지 확인하세요. AI가 지어낸 것이라면 package.json에 나오지 않습니다.
7. 계획이 화면에 들어옵니다. 간단한 기능에 대한 계획이 200줄이라면, 한 번의 계획으로 처리하기에는 작업 범위가 너무 클 수 있습니다. 나누세요.

계획이 검토 기준을 통과하지 못했을 때는 세 가지 방법이 있습니다.

• 피드백을 주며 계획 계속 작성: 마음에 들지 않는 부분을 구체적으로 Claude에게 알려주면 계획을 다시 작성합니다.
• Ctrl+G: 편집기에서 계획을 열고 직접 수정한 뒤 저장합니다. Claude가 수정한 버전을 이어서 사용합니다.
• Ultraplan으로 다듬기: 계획이 Claude Code 웹의 브라우저 모드로 이동합니다. 섹션을 검토하고 의견을 단 뒤 로컬이나 클라우드에서 실행할 수 있습니다.

구현 도중 문제가 생기면 억지로 진행하지 마세요. Plan Mode로 돌아가 계획을 다시 작성하세요. 나중에 커밋 40개를 되돌리는 것보다 비용이 10배 적게 듭니다.

Plan Mode와 plans/ 폴더: 긴 컨텍스트를 위한 조합#

Plan Mode는 Claude Code의 모드입니다. plans/ 폴더는 그 위에 구축한 방법론입니다. 폴더 없이 Plan Mode만 사용하면 한 시간 뒤 한계에 부딪힙니다.

원리는 이렇습니다. Claude의 컨텍스트 창은 세션의 기억입니다. Opus 4.7에서는 1 million tokens를 담을 수 있지만, 이는 대화 전체의 분량입니다. 한 대화에서 복잡한 작업을 계획하고, 구현을 요청하고, 버그를 논의한 뒤 다른 이야기를 하면 창이 “부풀어” 오릅니다. Claude는 초기에 내린 결정을 잊고, 컨텍스트를 혼동하며, 같은 질문을 다시 하기 시작합니다.

해결책은 황금률입니다. 작업 하나에 대화 하나.

방법은 다음과 같습니다.

1. 대화 1—계획 수립. Plan Mode를 활성화하고 작업을 설명하면 Claude가 계획을 작성합니다. 계획을 plans/2026-05-21-feature-name.md에 저장합니다. 창을 닫습니다.
2. 대화 2—단계로 나누기. 새 채팅을 엽니다. “plans/2026-05-21-feature-name.md를 가져와 단계로 나눠 줘”라고 요청합니다. 업데이트된 파일을 저장합니다.
3. 대화 3—1단계 구현. 새 채팅을 엽니다. “plans/2026-05-21-feature-name.md의 1단계를 구현하고 완료한 항목에 체크 표시를 해 줘”라고 요청합니다. 창을 닫습니다.
4. 대화 4—2단계 구현. 같은 방식으로 진행합니다.

이렇게 하면 어떤 효과가 있을까요? 각 대화의 컨텍스트 창이 새 상태로 유지됩니다. 3단계의 Claude는 1단계의 세부 사항을 알지 못하지만, plans/ 파일이 저장소에 있으므로 계획은 알고 있습니다. 이후 어떤 에이전트든(서브에이전트, 새 세션, /goal 실행 등) 계획을 이어받아 계속할 수 있습니다.

접근 방식 비교:

각 기능마다 별도의 계획 파일을 둡니다. 3개월 뒤 결제 공급자 하나를 다른 선택지보다 왜 선호했는지 기억해야 할 때, 해당 계획을 열어 결정 기록을 읽을 수 있습니다. 무엇을 논의했고, 어떤 선택지를 고려했으며, 왜 그 경로를 선택했는지 확인할 수 있습니다.

이것은 살아 있는 작업 계획입니다. 정적인 문서는 몇 달이면 오래된 정보가 됩니다.

Plan Mode와 /goal을 사용해 잠자는 동안 Claude를 일하게 하려면 어떻게 해야 하나요?#

AI를 오래 실행할 때 가장 큰 한계는 모델 자체가 아니라 Enter 키를 누르는 사람입니다. Claude가 매 턴 끝에 도달할 때마다 사용자의 응답을 기다립니다. /goal은 그 기다림을 없앱니다.

문법은 간단합니다.

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

조건은 최대 4000자까지 작성할 수 있습니다. 세션당 목표는 하나입니다. 매 턴이 끝날 때마다 Haiku mini 모델이 대화 기록을 살펴보고 “조건 충족—종료” 또는 “미충족—다음 턴”이라고 판단합니다. 평가자는 도구를 호출하지 않고 읽기만 합니다.

해제 별칭: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Plan Mode와 결합하면 다음과 같이 진행합니다.

1. Plan Mode를 활성화합니다(Shift+Tab을 두 번 누릅니다).
2. “데이터베이스를 MySQL에서 Postgres로 마이그레이션하는 계획을 만들고, 단계와 기준을 포함해 plans/2026-05-21-postgres-migration.md에 저장해 줘”라고 요청합니다.
3. 계획을 검토하고 수정한 뒤 승인합니다.
4. Plan Mode를 종료합니다(Shift+Tab을 한 번 더 누릅니다).
5. 목표를 설정합니다. “plans/2026-05-21-postgres-migration.md의 모든 단계를 완료하고 체크박스를 표시해. 모든 테스트가 통과하거나 50턴 뒤에 중단해.”
6. 노트북을 닫고 잠자리에 듭니다.

아침에 결과를 확인합니다. 수행한 작업의 기록과 함께 “✓ 목표 완료” 또는 “◎ 50턴 뒤 중단”이 표시됩니다.

토큰을 낭비하지 않으려면 /goal에서 지켜야 할 필수 규칙이 세 가지 있습니다.

규칙 1: 측정 가능한 최종 상태. “보기 좋게 만들어”는 좋지 않은 조건입니다. “npm test가 0을 반환하고, npm run lint가 0을 반환하며, CHANGELOG.md에 항목이 추가된다”는 좋은 조건입니다.

규칙 2: 명시적인 검증. 조건은 명령, 파일 또는 엔드포인트처럼 확인할 수 있는 항목을 가리켜야 합니다. “모든 것이 작동한다”가 아니라 “curl localhost:3000/api/users가 200을 반환한다”라고 해야 합니다.

규칙 3: 턴 수 제한. 항상 “또는 N턴 뒤에 중단”을 추가하세요. Anthropic도 문서에서 명시적으로 권장합니다.

/goal을 “또는 중단” 제한 없이 활성화하면 예산이 밤사이 사라질 수 있습니다.

Plan Mode를 엔지니어링 프로세스로 바꾸는 4단계 주기는 무엇인가요?#

흔한 실수는 “어떻게 고치면 될까?”라고 묻는 것입니다. Claude가 해결책을 제시하고 이를 적용해도 아무것도 해결되지 않거나 상황이 더 나빠집니다. 이것이 “AI의 아첨하는 성향”입니다. AI는 빠르게 답하도록 훈련되어 있고, 사용자는 코드로 빨리 넘어가고 싶어 합니다. 4단계 주기가 이 문제를 해결합니다.

4단계 주기는 이러한 행동을 막습니다. 하나의 Plan Mode 세션에서 순서대로 진행합니다.

1단계. 해결책 없이 사실을 확인합니다.

프롬프트: “다음과 같은 문제가 발생하고 있습니다: [증상 설명]. 지금 할 일은 사실을 확인하는 것입니다. 해결책, 아이디어, 조언은 금지합니다. 관찰한 내용, 재현 가능한 단계, 확보된 데이터, 부족한 데이터만 기록하세요. 엄격한 중단 조건: 해결책을 제안하지 말고 진단만 기록하세요.”

이렇게 하면 AI의 첫 번째 충동인 “해결책은 이렇습니다”를 막을 수 있습니다. Claude는 “무엇을 알고 있고 무엇을 모르는지”에서 멈춰야 합니다.

2단계. 선례를 바탕으로 선택지를 개발합니다.

프롬프트: “진단이 끝났으니 이제 비슷한 문제를 해결한 선례를 온라인에서 찾아보세요. 서로 다른 접근 방식이 최소 3개 필요합니다. 각 접근 방식에 대해 1차 출처 링크, 간단한 설명, 우리 상황에서의 장단점을 제시하세요.”

이렇게 하면 AI의 두 번째 충동인 “즉석에서 해결책을 지어내기”를 막을 수 있습니다. 외부 자료를 찾아 검토 가능한 접근 방식을 가져오게 합니다.

3단계. 위험 요소를 포함한 상세 계획을 작성합니다.

프롬프트: “2단계에서 찾은 최선의 선택지를 바탕으로 상세 계획을 작성하세요. 수정할 구체적인 파일, 추가하거나 제거할 내용, 작성할 테스트, 발생 가능한 문제, 2-3단계 앞에 놓인 위험을 포함하세요.”

익숙한 Plan 단계와 같지만 한 가지 차이가 있습니다. Claude의 추측이 아니라 2단계에서 검증한 선택지를 바탕으로 합니다.

4단계. 계획을 자체 점검합니다.

프롬프트: “이제 필수 자체 점검을 수행하세요. 계획을 솔직하게 다시 확인하세요. 코드, 문서 또는 2단계의 선례와 대조해 확인하지 않고 근거 없이 지어낸 내용이 있나요? 있다면 표시하고 계획을 수정하세요.”

마지막 필터입니다. Claude는 자신의 추론을 점검하고 환각을 일으킨 부분을 인정해야 합니다. 이 단계에서 보통 계획 항목을 최소 2개 수정합니다.

4단계를 마치면 계획을 승인할 준비가 끝납니다. 작업을 이해했고, 선택지를 검토했으며, 위험을 고려했다는 확신을 갖고 구현을 시작할 수 있습니다.

이 방법론은 어려운 버그를 진단하고 오류 비용이 큰 아키텍처 결정을 내리기 위한 것입니다. Plan Mode에 적용하면 바이브 코딩을 하는 사람들이 겪는 주된 문제, 즉 “AI가 해결책을 줘서 적용했더니 모든 것이 망가졌다”를 없앨 수 있습니다.

흔한 작업에 활용할 수 있는 Plan Mode 프롬프트 템플릿 5가지는 무엇인가요?#

템플릿 1. 모듈 리팩터링.

Plan Mode를 활성화합니다. 작업: {module-name} 모듈을 리팩터링합니다.

1단계: {module-path} 모듈의 현재 구조를 살펴보세요. 다음을 설명하세요.
- 모듈에 포함된 파일
- 외부 의존성
- 중복된 부분
- 지나치게 복잡한 함수

2단계: 비슷한 모듈을 리팩터링한 온라인 사례 2-3개를 찾으세요.
출처 중 최소 1개는 Anthropic 또는 관련 프레임워크의 공식 문서여야 합니다.

3단계: plans/YYYY-MM-DD-refactor-{module}.md에 리팩터링 계획을 작성하세요.
- 이름을 바꿀 파일
- 별도 모듈로 분리할 함수
- 유지할 테스트와 다시 작성할 테스트
- 위험: 사용자에게 문제가 생길 수 있는 부분

4단계: 자체 점검. 계획에 “근거 없이 지어낸” 가정이 있나요?
다시 작성하거나 제거하세요.

템플릿 2. 데이터베이스 마이그레이션.

Plan Mode를 활성화합니다. 작업: 데이터베이스를 {old}에서 {new}로 마이그레이션합니다.

1단계: {schema-reading-command}를 사용해 현재 데이터베이스 스키마를 살펴보세요. 다음을 설명하세요.
- 존재하는 테이블과 크기
- 관계, 인덱스, 제약 조건
- 마이그레이션 파일의 위치
- 중요한 데이터

2단계: 프로덕션 프로젝트에서 {old → new} 마이그레이션을 수행한 선례를 찾으세요.
서로 다른 접근 방식이 최소 3개 필요합니다: pg_dump, dual-write, blue-green.
각 방식이 우리 데이터 규모에서 갖는 장점과 위험을 나열하세요.

3단계: plans/YYYY-MM-DD-db-migration.md에 마이그레이션 계획을 작성하세요.
- 단계 (백업, 마이그레이션, 검증, 전환)
- 각 단계의 성공 기준
- 문제가 생길 경우의 롤백 계획
- 다운타임 여부

4단계: 자체 점검. 모든 수치는 문서로 뒷받침되나요?
모든 단계를 개발 환경과 대조해 머릿속으로 확인했나요?

템플릿 3. 새 기능 추가.

Plan Mode를 활성화합니다. 작업: 프로젝트에 {description} 기능을 추가합니다.

1단계: 프로젝트에서 비슷한 기능이 현재 어떻게 작동하는지 살펴보세요.
구체적으로 다음을 확인하세요.
- {file-1}
- {file-2}
- 사용 중인 아키텍처 패턴
- 비슷한 기능에 작성된 테스트

2단계: 비슷한 아키텍처를 가진 오픈 소스 프로젝트에서 이 기능이
어떻게 구현되었는지 찾으세요. 서로 다른 접근 방식이 최소 2개 필요합니다.

3단계: plans/YYYY-MM-DD-feature-{name}.md에 계획을 작성하세요.
- 새 파일 목록
- 구체적인 줄 번호가 포함된 변경 파일 목록
- 구현 순서
- 추가할 테스트
- 향후 세션을 위한 규칙으로 CLAUDE.md에 추가할 내용

4단계: 자체 점검. 계획이 프로젝트 아키텍처를 따르나요?
아직 설치하지 않은 라이브러리를 가정하고 있나요?

템플릿 4. 테스트 작성.

Plan Mode를 활성화합니다. 작업: {name} 모듈에 대한 테스트를 작성합니다.

1단계: {path} 모듈을 살펴보세요. 다음을 파악하세요.
- 공개 함수와 시그니처
- 테스트하지 않을 내부 함수(구현 세부 사항)
- 경계 사례: 빈 입력, 오류, 동시 접근

2단계: 같은 프레임워크를 사용하는 인기 오픈 소스 프로젝트에서
비슷한 종류의 작업을 위한 테스트 사례를 찾으세요.

3단계: plans/YYYY-MM-DD-tests-{module}.md에 테스트 계획을 작성하세요.
- 공개 함수별 테스트 목록
- 필요한 mock
- 필요한 fixture
- 검증 방식(어설션 스타일)

4단계: 자체 점검. 모든 테스트가 구현 세부 사항이 아니라 동작을 검증하나요?
경계 사례가 테스트 범위에 포함되어 있나요?

템플릿 5. 복잡한 오류 디버깅.

Plan Mode를 활성화합니다. 작업: 오류 {symptom-description}의 원인을 파악합니다.

1단계: 사실을 확인하세요. 해결책과 아이디어는 금지합니다. 다음만 확인하세요.
- 관찰 내용(오류의 정확한 문구)
- 재현 가능한 단계
- 확보된 데이터(log, trace, 라이브러리 버전)
- 부족한 데이터(추가로 수집해야 할 내용)

2단계: 이 오류와 관련된 선례를 찾으세요.
출처가 최소 3개 필요합니다: GitHub 이슈, 문서, 공식적인 기술 자료.
각 출처의 링크와 해결책 요약을 간략히 제시하세요.

3단계: plans/YYYY-MM-DD-bug-{name}.md에 진단 계획을 작성하세요.
- 확인할 가설(가능성이 높은 순서)
- 각 가설을 확인하기 위해 실행할 명령/script
- 각 확인에서 예상되는 결과

4단계: 자체 점검. 계획에 “근거 없이 지어낸” 가설이 있나요?
모든 가설이 1단계에서 확인한 사실에 근거하나요?

각 템플릿을 복사하고 {parameters}를 자신의 값으로 바꾼 다음, Plan Mode에서 Claude Code에 붙여 넣으세요. plans/에 구현을 위해 승인하고 사용할 수 있는 실용적인 계획이 생성됩니다.

Plan Mode와 일반 모드 중 무엇을 선택해야 하나요?#

Anthropic은 문서에서 이를 분명히 말합니다.

실제 diff가 작고 이해됐으며 위험이 낮을 때만 별도 계획을 생략하세요. 접근을 찾아야 하거나 구성 요소 간 위험한 변경을 조정해야 하면 계획하세요. 파일명을 알거나 목표를 한 문장으로 요약해도 마이그레이션, 인증, 데이터 무결성 위험은 사라지지 않습니다.

판단표:

모드 선택 전에 접근, 부작용, 검증을 이해했는지 물으세요. 작고 국소적이며 위험이 낮고 검사가 분명한 변경은 직접 처리하세요. 불확실성, 낯선 코드, 마이그레이션, 인증, 구성 요소 조정이 있으면 파일 3-5개를 이미 알아도 먼저 계획하세요.

안정적인 작업을 위해 Plan Mode, CLAUDE.md, 서브에이전트를 어떻게 결합하나요?#

CLAUDE.md는 Claude가 Plan Mode를 포함한 모든 세션의 시작에 읽는 파일입니다. CLAUDE.md에 “날짜를 하드코딩하지 말고 항상 데이터베이스에서 가져와”라고 적혀 있다면 계획에서 날짜 하드코딩을 제안하지 않습니다. 그런 규칙이 없으면 계획은 무엇이든 제안할 수 있습니다.

조합은 다음과 같이 작동합니다.

계층 1. CLAUDE.md에서 규칙을 정합니다.

이 파일은 프로젝트의 기술 스택, 아키텍처 원칙, 금지 사항(“지원 중단된 API를 사용하지 말 것”), 요구 사항(“모든 이메일은 공통 레이아웃을 사용할 것”)을 지정합니다. 자세한 안내: CLAUDE.md 설정 방법.

계층 2. Plan Mode가 작업에 규칙을 적용합니다.

Plan Mode를 활성화하고 “OAuth를 추가해”라고 요청하면 Claude는 CLAUDE.md를 읽고 “토큰은 데이터베이스가 아니라 Redis에 저장할 것”과 같은 규칙을 확인해 계획에 즉시 반영합니다. 계획은 프로젝트 아키텍처에 맞춰집니다.

계층 3. 서브에이전트가 작업을 나눕니다.

계획을 단계로 나눴다면 각 단계를 별도의 서브에이전트에 맡길 수 있습니다. 각 서브에이전트는 주 컨텍스트 창을 복잡하게 만들지 않고 자체 창에서 작업합니다. plans/의 계획은 중심적인 기준 문서로 남습니다. 서브에이전트가 이를 읽고 각 단계를 수행한 뒤 체크박스를 업데이트합니다.

Plan Mode를 망치는 7가지 실수는 무엇인가요?#

실수 1. 계획이 채팅에만 남습니다.

증상: 계획을 작성하고 창을 닫은 뒤 다음 날 돌아오려는데 아무것도 없습니다. 컨텍스트가 사라졌습니다. 해결책: 저장소의 plans/YYYY-MM-DD-feature-name.md에 계획을 항상 저장하세요. 채팅은 책상이고 파일은 보관소입니다.

실수 2. 모든 작업을 한 채팅에서 처리합니다.

증상: 한 세션에서 auth를 논의하고, 그다음 마이그레이션, UI 디자인, 버그를 이야기합니다. 컨텍스트 창이 “부풀어” 오르면서 Claude가 이전 내용을 잊습니다. 해결책: 작업 하나에 대화 하나. 계획을 마쳤나요? 창을 닫으세요. 구현을 시작하나요? 새 창을 여세요.

실수 3. 단계가 없는 3000줄짜리 계획 하나만 작성합니다.

증상: 계획은 있지만 체크박스나 구분이 없습니다. 무엇이 끝났고 무엇이 남았는지 알 수 없습니다. 작업을 나눠 맡기는 것도 불가능합니다. 해결책: 각 계획을 3-7단계로 나누세요. 각 단계에는 구체적인 작업을 체크박스 목록으로 적습니다.

실수 4. 계획 전에 충분히 조사하지 않습니다.

증상: 선례를 찾아보라고 요청하지 않아 Claude가 즉석에서 해결책을 내놓습니다. 일주일 뒤 오픈 소스에 이미 더 나은 접근 방식이 있었다는 사실을 알게 됩니다. 해결책: 4단계 주기의 2단계를 따르세요. 계획을 세우기 전에 Claude가 온라인에서 선례 2-3개를 찾게 하세요.

실수 5. AI가 진단 없이 해결책을 내놓습니다.

증상: “오류 X를 어떻게 고치지?”라고 물으면 Claude가 해결책을 내놓습니다. 적용해도 해결되지 않거나 상황이 악화됩니다. 해결책: 항상 “사실을 확인해. 해결책은 금지야”로 시작하세요. 진단이 끝난 뒤에만 선택지를 검토합니다.

실수 6. 자체 점검을 건너뜁니다.

증상: 계획은 그럴듯하지만 “근거 없이 지어낸” 가정이 2-3개 들어 있습니다(만들어낸 라이브러리, 존재하지 않는 API, 잘못된 버전 등). 구현은 바로 그 지점에서 실패합니다. 해결책: 4단계 주기의 4단계를 따르세요. Claude에게 계획을 솔직하게 다시 확인하고 가정을 표시하도록 하세요.

실수 7. /goal에 모호한 조건을 사용합니다.

증상: /goal 보기 좋게 만들어라고 설정하고 밤새 실행해 둔 뒤, 아침에 $200의 할당량이 소진된 것을 확인합니다. 해결책: 검증 명령과 반드시 “또는 N턴 뒤에 중단” 조건이 포함된 측정 가능한 조건만 사용하세요. “잘 만들어” 또는 “다듬어” 같은 표현은 쓰지 마세요.

바이브 코딩을 하는 사람들이 가장 흔히 저지르는 여덟 번째 실수는 plans/ 폴더 자체를 무시하는 것입니다. plans/ 폴더가 없는 Plan Mode는 방법론이 아니라 장난감입니다. Plan Mode를 사용하면서 파일을 만들지 않으면 기능의 10%만 활용하는 셈입니다.

Plan Mode를 처음 사용한 뒤에는 무엇을 해야 하나요?#

난이도가 낮은 것부터 높아지는 세 가지 구체적인 단계입니다.

1단계. 아직 없다면 CLAUDE.md를 설정합니다.

CLAUDE.md가 없으면 Plan Mode는 “진공 상태”에서 작동합니다. Claude는 프로젝트 규칙을 모르므로 아키텍처를 깨뜨리는 계획을 제안합니다. 전체 안내: CLAUDE.md 설정 방법. 최소한의 CLAUDE.md는 기술 스택, 규칙, 금지 사항을 설명하는 50-80줄이면 됩니다. 길이보다 구체성이 중요합니다.

2단계. 저장소에 plans/ 폴더를 만듭니다.

프로젝트 루트에 plans/ 폴더를 추가합니다. 파일 이름 형식을 정합니다: YYYY-MM-DD-feature-name.md. 계획마다 파일을 하나씩 둡니다. 한 달 뒤에는 20-30개, 6개월 뒤에는 100개 이상이 쌓입니다. 이는 프로젝트 결정의 살아 있는 기록입니다.

3단계. 작업 하나에 /goal을 시험합니다.

보통 직접 처리하는 데 30-40분 걸리는 작업을 고르세요. Plan Mode를 활성화하고 계획을 작성해 plans/에 저장합니다. Plan Mode를 종료합니다. /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns를 설정합니다. 한 시간 동안 노트북을 닫아 두고 다른 일을 하세요. 돌아와 결과를 확인합니다.

이 세 단계가 최소한의 시작입니다. 이 과정은 점진적으로 진행해야 합니다. 한 저녁에 모든 것을 한꺼번에 구성하려 하지 마세요. CLAUDE.md부터 시작하고, 일주일 뒤 plans/를 추가한 다음, 한 달 뒤 밤새 /goal을 시험해 보세요.

준비가 되면 Ailoot을 만나 보세요.