Plan Mode & Execution Control
이 문서는 CCAF Domain 3를 이해하기 위한 개념 설명용 노트다.
여기서는 전체 작업 루프보다, 언제 실행을 보류하고 먼저 사고를 정렬할 것인가를 다룬다. 즉 plan mode를 단순한 사전 설명 기능이 아니라, Claude Code의 실행 전 제어(execution control) 장치로 이해하는 데 초점을 둔다.
왜 plan과 execution을 나눠야 하는가
Claude Code는 바로 수정에 들어갈 수도 있고, 먼저 계획을 세우고 방향을 정렬한 뒤 실행할 수도 있다.
작은 작업에서는 바로 실행이 편할 수 있다.
하지만 작업이 커지거나 위험이 커질수록, 바로 실행하는 방식은 다음 문제를 만들 수 있다.
- 문제를 충분히 이해하기 전에 수정에 들어감
- 변경 범위가 과도하게 커짐 (Task Decomposition 부재)
- 중요한 검증 단계를 빠뜨림
- 사용자와 기대 결과가 어긋난 채 진행됨
즉 plan mode의 핵심은 느리게 만드는 것이 아니라,
실행 전에 방향을 정렬해 잘못된 착수를 줄이는 것
이다.
plan mode는 무엇을 하는가
plan mode는 단순히 “생각을 말해보기”가 아니다.
실제로는 아래를 정리하는 단계에 가깝다.
- 문제를 어떻게 이해했는지
- 무엇이 아직 불확실한지
- 어떤 파일이나 영역을 볼 것인지
- 수정 전략을 어떻게 잡을지
- 어떤 검증을 거칠지
즉 plan mode는 실행 전의 자유 메모가 아니라,
실행 전에 작업의 방향과 경계를 명시하는 단계
다.
언제 바로 실행해도 되는가
모든 작업이 plan mode를 요구하는 것은 아니다.
바로 실행해도 되는 경우는 보통:
- 수정 범위가 작고 명확할 때
- 영향 범위가 제한적일 때
- 변경 의도가 분명할 때
- 실패 비용이 낮을 때
- 검증 방법이 단순할 때
예:
- 오타 수정
- 작은 문구 변경
- 명백한 단일 함수 수정
- 단순 lint fix
이런 경우 plan을 길게 세우는 것은 오히려 오버헤드가 될 수 있다.
즉 중요한 것은 “항상 계획 먼저”가 아니라,
불확실성과 영향 범위가 커질수록 계획의 가치가 커진다
는 점이다.
언제 plan mode가 특히 중요한가
다음 경우에는 plan mode가 특히 유용하다.
1. 변경 범위가 넓을 때
여러 파일이나 여러 계층을 건드려야 하면, 수정 전에 구조를 정리하는 편이 좋다.
2. 요구사항이 모호할 때
무엇을 어떻게 바꿔야 하는지 애매하면, 먼저 해석과 접근법을 분명히 해야 한다.
3. 위험한 변경일 때
배포, 데이터 변경, 중요한 리팩터링처럼 실수 비용이 큰 작업은 바로 실행보다 계획 정렬이 중요하다.
4. 단계적 진행이 필요할 때
한 번에 다 밀기보다, 계획 → 확인 → 실행 식으로 나눠 가는 편이 안정적인 작업이 있다. 이런 반복 루프 구조는 Coding Workflow Design에서 더 구체적으로 다룬다.
즉 plan mode는 기능 소개가 아니라,
실행 리스크를 낮추는 제어 정책
에 가깝다.
execution control은 무엇을 뜻하는가
execution control은 단순히 “실행할지 말지”를 뜻하지 않는다.
실제로는 아래를 포함한다.
- 지금 바로 수정할지
- 먼저 읽고 조사할지
- 계획을 먼저 보여줄지
- 한 번에 수정할지 단계적으로 수정할지
- 중간 확인을 받을지
- 어떤 조건이 충족되어야 다음 단계로 갈지
즉 execution control의 핵심은,
작업을 한 번에 밀어붙이지 않고, 적절한 경계에서 멈추고 확인하고 진행하게 만드는 것
이다.
왜 이게 harness engineering과 닿아 있는가
이건 거의 직접적인 하니스 문제다.
좋은 하니스는 모델이 항상 곧바로 행동하게 두지 않는다.
상황에 따라:
- 먼저 계획하게 하고
- 그 계획을 검토하게 하고
- 일정 조건이 충족되면 실행하게 하고
- 필요한 경우 단계적으로 진행하게 한다
이 구조는 Agent Loop의 반복 실행 모델과 맞닿아 있다. 즉 plan mode와 execution control은
단순 기능이 아니라,
Claude Code의 실행 정책(execution policy)
으로 볼 수 있다.
흔한 오해
“plan mode는 느리기만 하다”
아니다. 큰 작업에서는 오히려 재작업을 줄여 전체 시간을 아낄 수 있다.
“항상 계획을 먼저 세워야 한다”
그렇지 않다. 작은 작업에는 오버헤드가 될 수 있다.
“계획은 설명용이고 실행 품질과는 별개다”
아니다. 좋은 계획은 실행 범위와 검증 경계를 더 안정적으로 만든다.
한 문장 요약
Plan mode는 답을 늦추는 기능이 아니라, Claude Code가 실행 전에 방향과 경계를 정렬하도록 만드는 execution control 장치다.