Claude Code Plan mode는 언제 써야 할까? AI 코딩 통제점 10가지

결론부터 말하면 Claude Code의 Plan mode는 사라지지 않았습니다. 한 줄 수정처럼 범위가 작고 명확한 작업은 바로 구현하고, 불확실하거나 여러 파일·데이터·팀에 영향을 주는 작업은 Plan mode로 먼저 검토하는 편이 낫습니다. 이제는 실행 전 계획 하나에 의존하기보다 작업 경계, 완료 조건, 검증 증거, 권한과 훅을 함께 설계해야 합니다.

계획이 사라진 게 아닙니다. AI 코딩의 통제점이 바뀌었습니다.

Claude Code의 공식 best practices는 코드베이스를 탐색하고, 계획하고, 구현하고, 결과를 검증하는 흐름을 권해 왔습니다. Claude Code를 만든 Boris Cherny도 2026년 1월 공개한 워크플로 스레드에서 당시 Plan mode 중심의 운용 방식을 소개했습니다.

그런데 2026년 9월 말, Boris는 Hacker News 댓글에서 최신 모델을 쓰는 자신의 현재 워크플로에서는 별도 Plan mode가 더 이상 유용하지 않다고 설명했습니다. 이는 Anthropic의 제품 폐기 선언이나 모든 숙련 사용자의 합의가 아니라 한 개발자의 기본 작업 방식이 바뀌었다는 1차 발언입니다.

Claude Code의 /plan과 plan 권한 모드는 지금도 현행 기능입니다. 중요한 변화는 “계획을 할 것인가”가 아니라 “어디에서 사람의 통제를 걸 것인가”입니다.

검증 기준일: 2026년 10월 11일

상황별로 먼저 쓸 통제점

상황	먼저 쓸 통제점
한 줄 수정·명확한 반복 업무	바로 구현 + 테스트
불확실하거나 여러 파일을 바꾸는 작업	Plan mode + 사람의 계획 검토
여러 턴 이어지는 작업	/goal + 대화에 남긴 검사 증거 + 턴·시간 중단 조건
외부 전송·삭제·배포를 막아야 하는 작업	permissions·PreToolUse hook + sandbox·인프라 정책
같은 실수가 반복되는 업무	작은 skill + baseline 대조 실험
독립적인 대규모 조사	subagents·Agent Teams + 수·비용 제한

이 표에서 “먼저”라는 말이 중요합니다. 한 가지 기능이 다른 안전장치를 모두 대신하지는 않습니다.

1. 방법 대신 임무를 브리핑한다

좋은 요청은 긴 작업 순서보다 다음 다섯 가지를 분명히 합니다.

• 무엇을 해야 하는가
• 무엇을 바꾸면 안 되는가
• 어떤 상태가 완료인가
• 완료를 무엇으로 증명할 것인가
• 얼마만큼 시도한 뒤 멈출 것인가

이를 LeanX의 5줄 작업 브리핑이라고 부르겠습니다.

작업: CRM 내보내기 파일로 이번 주 고객 보고서를 작성한다.
경계: 기존 템플릿을 바꾸지 않고, 이메일은 전송하지 않는다.
완료: 모든 수치가 원본과 일치하고 필수 섹션이 채워진다.
증거: 검사 결과와 원본 대비표를 함께 제출한다.
예산: 15턴 안에 통과하지 못하면 원인과 남은 문제를 보고하고 멈춘다.

구현 경로는 모델이 탐색하게 두되, 성공과 실패의 경계는 사람이 소유하는 방식입니다.

2. Claude Code Plan mode는 언제 쓰고 언제 생략할까?

작고 되돌리기 쉬운 수정에 매번 별도의 계획 승인을 거치면 품질보다 마찰이 커질 수 있습니다. 반대로 데이터 마이그레이션, 인증·권한 변경, 아키텍처 수정처럼 실패 비용이 큰 일에는 사전 계획이 여전히 유용합니다.

LeanX의 Plan mode 판단 규칙은 간단합니다. 구현이 틀렸을 때의 비용보다 계획을 검토하는 비용이 작은가? 그렇다면 Plan mode를 씁니다.

기능·권한·지침 파일의 차이를 먼저 비교하려면 Claude Code와 Codex 비교 가이드를 함께 참고할 수 있습니다.

3. /effort와 ultrathink는 어떻게 다른가?

현재 Claude Code는 /effort로 세션의 실제 추론 노력 수준을 조절합니다. 대부분의 작업은 권장 기본값에서 시작하고, 중요한 버그나 복잡한 경계 조건처럼 추가 탐색이 필요한 경우에만 높이는 편이 효율적입니다.

최고 수준을 늘 켜두면 더 좋은 결과가 보장되는 것이 아니라 시간과 토큰, 과잉 구현이 늘 수 있습니다. 현재 문서상 think, think hard 같은 표현은 일반 텍스트입니다. ultrathink는 한 번의 요청에 더 깊게 추론하라는 인컨텍스트 지시를 추가하는 예외 키워드지만, API로 전달되는 effort 수준 자체를 바꾸지는 않습니다.

지속적인 운용은 단어 주문보다 /effort 설정과 실제 결과 비교로 관리하는 편이 명확합니다.

4. Claude Code의 검증은 통과·실패로 설계한다

“다시 검토해 줘”라는 문장을 반복해도 완료를 증명할 수는 없습니다. 보고서라면 원본 수치 대조 스크립트, 코드라면 테스트·타입 검사·린트, 화면이라면 실제 브라우저 시나리오처럼 통과와 실패가 드러나는 기준이 필요합니다.

문서 작업도 필수 항목 체크리스트나 승인된 브랜드 보이스 예시로 판정할 수 있습니다. 중요한 것은 검증기가 결정적으로 확인할 수 있는 범위를 늘리는 일입니다.

좋은 자율 실행은 다음 묶음으로 끝납니다.

결과물 + 실행한 검사 + 검사 결과 + 남은 불확실성

사람은 결과 전체를 처음부터 다시 만드는 대신, 결과와 증거가 맞물리는지를 검토합니다.

5. 긴 작업은 /goal로 종료 상태까지 이어간다

검사에 실패할 때마다 사람이 continue를 입력해야 한다면 아직 자율적인 흐름은 아닙니다. Claude Code의 /goal은 정한 조건을 향해 여러 턴에 걸쳐 작업을 이어가게 돕습니다.

다만 “보고서를 완성하라” 같은 목표는 너무 모호합니다.

/goal check-report의 모든 검사가 통과하고 실제 결과가 출력될 때까지 계속하라.
원본 템플릿과 외부 시스템은 변경하지 않는다.
20턴이 지나면 남은 문제를 보고하고 중단한다.

/goal의 별도 평가 모델은 파일이나 도구를 직접 다시 열지 않고 대화에 나타난 조건과 증거로 목표 달성 여부를 판정합니다. 따라서 “테스트 통과”라고만 쓰기보다 실행한 명령과 실제 결과가 대화에 남아야 합니다. 다만 목표가 불가능하다고 판단되거나 사용자가 고쳐야 할 오류가 생기면 종료될 수 있고, 진행이 정체되면 사람의 입력을 기다릴 수 있습니다. /goal은 기존 권한 모드도 바꾸지 않습니다.

반복 실행은 판정 가능한 종료 상태와 턴·시간 중단 조건이 있을 때 유용합니다. 이 조건은 평가 모델이 대화로 판정하므로 하드 리밋과 같지 않습니다. 실제 비용 상한이 필요하면 조직 설정이나 외부 실행 환경에서 별도로 강제해야 합니다.

6. CLAUDE.md와 AGENTS.md는 매뉴얼보다 인덱스에 가깝게 만든다

지침 파일이 길어질수록 모든 세션이 그 비용을 지불하고 중요한 규칙도 묻힙니다. Anthropic의 메모리 문서는 CLAUDE.md를 간결하게 유지하고 상세 정보는 필요한 파일로 나누는 방식을 안내합니다.

항상 남겨둘 내용은 많지 않습니다.

• 모델이 추측할 수 없는 프로젝트 명령과 도구
• 일반적인 방식과 다르게 처리해야 하는 규칙
• 실제로 반복된 실패와 그 교정법
• 삭제·배포·외부 전송처럼 반드시 지켜야 하는 경계
• 세부 자료를 언제 읽어야 하는지 알려주는 경로

@파일 import는 시작 시 컨텍스트에 포함되므로 비용 절감 수단이 아닙니다. 필요할 때만 정보를 읽히게 하려면 경로별 규칙이나 조건부 참조를 사용해야 합니다.

기본 설정에서 Claude Code는 현재 작업 디렉터리와 상위 경로에 적용되는 CLAUDE.md나 CLAUDE.local.md가 없을 때 AGENTS.md를 fallback으로 읽습니다. /config에서 두 파일을 함께 읽도록 바꿀 수도 있지만 항상 자동 병합되는 것은 아닙니다. 팀이 어떤 파일을 정본으로 삼을지와 우선순위를 정해야 합니다. 기존 지침에 오래된 규칙·서로 충돌하는 지시·사라진 경로가 남지 않았는지도 주기적으로 별도 감사해야 합니다.

처음 설정하는 독자는 Claude Code 기초 강의에서 설치와 지침 파일의 역할부터 이어서 볼 수 있습니다.

7. skill은 상상한 절차가 아니라 관찰한 실패에서 만든다

자동화할 일이 생기자마자 거대한 skill부터 만드는 것은 순서가 거꾸로일 수 있습니다. Anthropic의 Agent Skills 작성 가이드는 먼저 대표 과제를 baseline으로 실행하고, 실패 지점을 확인하며 최소 지침을 추가하는 평가 흐름을 권합니다.

1. 실제로 사용할 모델에 skill 없이 일을 맡긴다.
2. 완료 조건으로 결과를 평가한다.
3. 반복 실패만 기록한다.
4. 그 교정 사항을 작은 skill로 만든다.
5. 같은 과제로 적용 전후를 비교한다.

skill은 업무 전체를 다시 가르치는 교과서가 아니라, 모델이 실제로 넘지 못한 턱을 낮추는 보조 장치에 가깝습니다.

8. /skill-doctor와 plugin eval로 skill을 비교한다

별이 많은 skill이 내 작업에도 효과가 있다는 보장은 없습니다. LeanX가 권하는 실험은 동일한 입력과 판정 기준으로 다음 세 조건을 비교하는 것입니다.

• skill 없는 기본 모델
• 실제 skill을 적용한 모델
• 길이만 비슷한 중립적인 대조 지침을 받은 모델

정확도는 같고 비용과 지연만 늘었다면 그 skill은 제거 후보입니다. Claude Code의 skill 관리 기능에서 /skill-doctor로 컨텍스트 비용과 사용 현황을 살필 수 있습니다. plugin eval은 플러그인 적용·미적용 두 조건을 격리된 세션에서 기본 비교합니다. 길이만 비슷한 중립 지침은 LeanX가 제안하는 별도의 수동 대조군입니다.

모델이 좋아질수록 과거의 보정 장치가 현재의 방해물이 될 수 있습니다. skill 목록은 수집품이 아니라 주기적으로 가지치기할 가설입니다.

9. hooks·permissions·sandbox로 금지선을 만든다

“절대로 고객에게 이메일을 보내지 마라”를 대문자로 적어도 물리적인 차단이 되지는 않습니다. 실수 가능성을 허용할 수 없는 행동은 hooks와 permissions로 막아야 합니다.

• 고객 이메일 전송 차단
• 특정 디렉터리 삭제 금지
• 운영 환경 배포 전 승인 요구
• 비밀정보의 외부 업로드 차단

자연어는 판단에, 코드는 불변 조건에 사용합니다. PreToolUse command hook과 permissions는 도구 실행 전에 작업을 차단할 수 있습니다. 하지만 prompt hook과 agent hook은 다시 모델을 사용하므로 모든 hook이 결정론적이거나 토큰 비용이 0인 것은 아닙니다.

훅이나 Bash 패턴은 운영체제 보안 경계가 아닙니다. 비밀정보와 운영 배포처럼 피해가 큰 영역에는 OS·네트워크 sandbox와 인프라 정책을 함께 둬야 합니다.

10. subagents와 Agent Teams는 언제 쓰는가?

작은 작업에 여러 하위 에이전트를 붙이면 품질보다 비용과 조율 부담이 커질 수 있습니다. 반면 대규모 조사, 긴 도구 출력, 서로 독립적인 검토는 하위 에이전트로 격리하면 메인 컨텍스트를 깨끗하게 유지할 수 있습니다.

Claude Code의 Agent Teams는 현재 실험 기능이며 기본적으로 비활성화되어 있습니다. 팀 구성을 모델이 제안하게 하더라도 사람은 최대 에이전트 수, 시간과 비용, 접근 가능한 데이터, 병렬 편집 범위, 승인할 행동을 정해야 합니다.

자동화된 작업의 최종 산출물은 결과 하나가 아니라 다음 묶음이어야 합니다.

• 최종 결과물
• 변경한 내용
• 실행한 검사와 결과
• 작업 중 세운 전제
• 해결하지 못한 항목
• 사람이 승인해야 할 다음 행동

스킬·훅·하위 에이전트까지 확장하는 운영 방식은 에이전틱 엔지니어링 심화 과정에서 이어서 확인할 수 있습니다.

결국 프롬프트의 시대에서 환경의 시대로

최신 Claude Code를 잘 쓰는 방법은 더 긴 프롬프트나 더 많은 skill을 모으는 일이 아닙니다.

모델이 기본적으로 할 수 있는 일은 비워두고, 모델이 알 수 없는 우리 업무의 기준을 넣고, 절대 넘으면 안 되는 경계는 코드와 권한으로 막고, 완료 여부는 외부 검증기로 판정하게 만드는 일입니다.

한 문장으로 정리하면 이렇습니다.

모델이 강해질수록 지침은 줄이고, 완료 조건과 검증 증거는 더 선명하게 만들어야 합니다.

오늘 실제 작업 하나를 작업·경계·완료·증거·예산 다섯 줄로 다시 써 보세요. 그런 다음 skill 없이 baseline을 실행하고, 반복되는 실패만 작은 규칙으로 남기고, 절대 금지할 행동은 hooks·permissions·sandbox로 옮기면 됩니다.

공식 참고 자료

Anthropic 공식 문서는 2026년 10월 11일에 확인했습니다. Boris Cherny의 Hacker News 댓글은 제품 정책이 아니라 개인 워크플로 변화의 근거로만 사용했습니다.

• Boris Cherny의 2026년 1월 Claude Code 워크플로 스레드 — 당시 Plan mode 중심의 운용 방식
• Boris Cherny의 Hacker News 댓글 — 현재 개인 사용 방식의 변화
• Anthropic, Claude Code best practices
• Claude Code 명령어와 /plan
• Claude Code permissions와 Plan mode
• Claude Code 모델과 effort 설정
• Claude Code /goal
• CLAUDE.md와 AGENTS.md
• Agent Skills 작성 best practices
• Claude Code skills와 /skill-doctor
• Claude Code hooks
• Claude Code plugin eval
• Claude Code Agent Teams

기능과 권장 방식은 빠르게 바뀔 수 있습니다. 실제 적용 시점에는 위 공식 문서와 현재 설치된 Claude Code의 도움말을 다시 확인하세요.