Claude의 기획자 포지셔닝과 Plan Mode의 결합 — 평판이 안전장치가 되는 조건

핵심 명제

HC의 볼트에는 "Claude가 오케스트레이션·전체 기획·검토에 강하고 실행은 다른 모델에 맡긴다"는 패턴이 여러 시점(2026-05-31, 06-01, 06-26, 06-30 agent-korea 브리핑)에 걸쳐 반복 관찰되어 있다. 이 평판 자체는 아무것도 강제하지 않는다 — 그것을 실제 작업 안전성으로 바꾸는 것은 Plan Mode라는 구체적 메커니즘(계획 제시 → 사용자 검토 → 승인 → 실행)이며, 반대로 Plan Mode가 있어도 그 안을 채울 기획 역량이 없으면 승인 절차는 빈 형식으로 전락한다.

역할 분담 / 비교 매트릭스

심층 분석

(1) 왜 평판만으로는 안전이 보장되지 않는가. Claude 엔티티 노트에 누적된 관찰 사례들은 모두 "Claude에게 상위 기획·오케스트레이션을 맡기고 실행은 다른 곳(Codex 등)에 위임한다"는 하이브리드 패턴을 보여준다. 2026-05-31 기록은 "Ultracode 도구와의 협업에서 상위 레벨 기획·설계는 Claude에, 하위 정밀 코드 구현은 Codex 서브에이전트에 위임"한다고 적었고, 2026-06-01 기록은 Claude를 "작업의 기획 및 하위 서브에이전트 실행을 제어하는 최상위 디렉팅 에이전트"로, 2026-06-30 기록은 "오케스트레이션 및 전체 기획과 결과물 리뷰는 클로드에 맡기고 실제 구현은 코덱스에 분담"한다고 적었다. 그런데 2026-06-26 기록은 같은 역할을 설명하면서도 "오류가 간혹 발생하지만 실행을 맡기기 전 상위 기획을 조율하는 역할로 활용됨"이라고 오류 가능성을 전제로 달아둔다. 즉 이 관찰들이 말하는 것은 "이 모델을 기획에 쓰면 쓸 만하다"이지 "이 모델의 계획은 검증 없이 실행해도 안전하다"가 아니다. 이 간극을 메우는 것이 Plan Mode의 검토·승인 단계다 — 이 단계가 없으면 "기획에 강하다"는 평판은 실행 전 확인 장치 없이 곧바로 실행으로 이어질 위험을 그대로 남긴다.

(2) 반대로 메커니즘만 있고 기획 역량이 약하면. Boris Cherny의 CLAUDE.md는 Plan Mode Default를 "3단계 이상, 다중 파일 변경, 설계 결정, 생산 영향"이라는 4가지 진입 조건과, 계획에 검증 단계를 포함하고 새 정보가 계획을 무효화하면 중단 후 갱신하며 요구사항이 모호하면 명확한 명세서(입력/출력, 엣지 케이스, 성공 기준)부터 쓰라는 3가지 운영 규칙으로 구성한다. 이 틀 자체는 어떤 모델에도 적용 가능한 절차일 뿐이며, 그 안을 실제로 쓸모 있는 내용으로 채우려면 모델이 요구사항의 모호함을 짚어내고 되물을 수 있어야 한다. AI Skill 45(n8n 채용 자동화 워크플로우)에서 Opus 4.5는 "LinkedIn에서 채용 공고 찾아서 콜드 이메일 자동화해줘" 같은 요청에 곧바로 워크플로우를 만드는 대신 "사용자가 검색 조건을 어떻게 입력하게 할까요", "결과 선택은 어떤 방식으로 할까요", "Apify API 키는 가지고 계신가요"라는 설계 질문을 먼저 던졌고, 답변을 받은 뒤에야 22개 노드짜리 워크플로우로 이어졌다. 평가는 "논리적으로 타당하며" 80~90% 수준의 뼈대라는 것이었다 — 처음부터 완벽한 원샷이 아니라 수정 가능한 구조를 준다는 것이다. Plan Mode라는 틀이 있어도 이 질문을 던질 역량이 없었다면 계획은 형식만 남았을 것이다.

(3) 진입 기준의 표현 차이는 정직하게 다뤄야 한다. Boris Cherny의 CLAUDE.md와 초보자용 가이드(claude-code-harness-beginner-guide-v2)는 같은 방향을 가리키지만 문구가 다르다. 전자는 "3단계 이상 / 다중 파일 변경 / 설계 결정 / 생산 영향"이라는 4가지 진입 조건에 "검증 단계 포함 / 무효화 시 중단·갱신 / 모호하면 스펙 먼저"라는 3가지 운영 규칙을 별도로 둔다. 후자는 "3단계 이상 작업 / 여러 파일 동시 수정 / 새 기능을 처음 만드는 경우 / 복잡한 구조 변경"으로 4가지를 든다. 겹치지만 완전히 같지는 않다 — 이를 하나의 "4조건 체크리스트"로 뭉뚱그리면 왜곡이다. 여러 출처에서 유사하지만 조금씩 다른 표현으로 반복 확인되는 패턴이라고 보는 편이 정확하다.

(4) "역질문"과 n8n 설계 질문은 개념적 근친일 뿐 같은 출처가 아니다. 역질문 개념은 raw/legacy_sources/ChatGPT 생산성 혁신 전문가 가이드.md에서 나온 것으로, "이 작업을 시작하기 전에, 나에게 필요한 상황 파악을 위해 명확히 해야 할 질문이 있다면 먼저 물어봐 줘"라는 프롬프트로 AI가 먼저 되묻게 만드는 기법이다. AI Skill 45의 n8n 사례에서 Opus 4.5가 던진 설계 질문은 완전히 별개의 출처에서 관찰된 현상이다. 둘 다 "AI가 실행 전에 되묻는다"는 점은 같지만, 하나는 사용자가 프롬프트로 유도한 결과이고 다른 하나는 Plan Mode/Blueprint 맥락에서 모델이 자체적으로 보인 행동이라는 차이가 있다 — 두 출처를 섞어 하나의 근거처럼 인용해서는 안 된다.

실무 적용 / 선택 기준

언제 이 조합이 필요한가. 모호한 지시를 그대로 실행에 넘기면 예상 밖 범위까지 변경이 번지는 사고가 난다. claude-code-harness-beginner-guide-v2의 예시가 이를 보여준다 — "계획 먼저 세워줘. 고객 주문 관리 앱을 만들고 싶어"라는 요청에 Claude는 곧바로 앱을 만들지 않고 "주문을 어디서 받나요?", "몇 명이 사용하나요?", "기존에 쓰는 스프레드시트나 도구가 있나요?"부터 물었다. 이 질문에 답하고 나서야 단계별 계획이 나오고, "좋아, 시작해"라고 답한 뒤에야 실제 작업이 시작된다. Plan Mode 없이 시작하면 "Claude가 작성하다가 중간에 이미 만든 것을 재구성해야 한다는 걸 깨닫는다"는 사례가 같은 문서에 AI Master의 경험으로 인용되어 있다.

어떻게 켜는가. /plan 또는 Shift+Tab으로 진입한다. 대규모 리팩토링, 새 기능 아키텍처 설계, 데이터베이스 마이그레이션처럼 되돌리기 어려운 작업에서는 곧바로 파일을 고치게 두지 않고 먼저 계획 단계를 거치는 편이 안전하다.

언제 켜야 하는지 판단하는 기준. Boris Cherny 기준으로는 진입 조건 4가지(3단계 이상 작업, 다중 파일 변경, 설계 결정이 필요한 작업, 생산 환경에 영향을 주는 작업) 중 하나에 해당하면 계획 모드로 들어가고, 그 안에서 검증 단계를 처음부터 포함시키며, 작업 도중 새 정보가 나와 기존 계획을 무효화하면 임의로 이어가지 말고 중단한 뒤 계획을 갱신하고 나서 재개한다. 요구사항이 모호하면 바로 계획을 짜지 말고 입력/출력, 엣지 케이스, 성공 기준부터 명세서로 써 둔다. 이 기준을 자신의 업무에 대입해보는 것이 체크리스트로서의 실무 적용점이다.

계획이 뼈대(80~90%)라는 것을 받아들이는 것. Blueprint 개념이 강조하듯, Plan Mode가 내놓는 계획은 처음부터 완성된 답이 아니라 사용자와의 질의응답을 거쳐 다듬어지는 80~90% 완성도의 구조다. n8n 채용 자동화 사례처럼 모호한 목표를 던지면 모델이 핵심 설계 질문으로 되받아치고, 그 답을 채워 넣은 뒤에야 실행 가능한 뼈대가 나온다는 워크플로우를 스스로의 업무에 재현해볼 수 있다 — 다만 실습 화면·단축키는 Claude Code 버전에 따라 달라질 수 있으므로 사용 전 확인이 필요하다.

관련 synthesis

[[wiki/synthesis/계획을_절차로_굳히기_—_Plan_Mode로_반복_업무_워크플로우_설계하는_4단계]]는 같은 Boris Cherny 4가지 진입 조건과 3가지 운영 규칙을 다루지만 각도가 다르다 — 그 문서는 Plan Mode가 내놓은 계획서를 반복 업무의 워크플로우 명세(입출력 정의 → 사람 승인 지점과 자동화 지점 분리 → 운영 규칙)로 옮겨 적는 절차에 초점을 둔다. 이 문서는 그보다 앞선 질문, 즉 "왜 Plan Mode라는 절차가 애초에 필요한가"를 Claude의 기획자 포지셔닝이라는 관찰된 평판과 엮어 다룬다 — Plan Mode 없는 평판은 검증되지 않은 위임이 되고, 평판 없는 Plan Mode는 빈 형식이 된다는 상호 의존 관계가 두 문서를 가르는 지점이다.