계획 모드는 왜 죽었는가: 거대 계획 문서의 종말과 Understand-Act-Inspect 루프

계획 모드는 왜 죽었는가: 거대 계획 문서의 종말과 Understand-Act-Inspect 루프

핵심 요약: 초창기 AI 코딩 도구는 환각과 빗나간 코드 생성을 막기 위해 엄격한 사전 계획 모드(Plan Mode)를 도입했습니다. 명세를 작성하고, 사람 승인을 받고, 코드를 생성하는 워터폴(Waterfall) 방식이었습니다. 하지만 모델 성능 향상과 에이전트 자율성 확대로 인해 수백 줄짜리 AI 생성 계획 문서는 사람이 읽기 힘든 인지 부채로 전락했습니다. 전 GitHub 엔지니어이자 Nuanced 창업자인 Ayman Nadeem의 실패 분석과 Claude Code 리드 Boris Cherny의 통찰을 바탕으로, 왜 선형 계획 모드가 퇴색하고 Understand → Act → Inspect 루프와 검증 가능한 작업 지시서(DoD) 체계로 전환되는지 아키텍처 관점에서 살펴봅니다.

---

1. 계획 모드(Plan Mode)의 탄생과 본래 목적

초기 코딩 에이전트(Codex, Claude, GPT-4 등) 환경에서 계획 모드는 필수적인 안전장치였습니다. 모델에게 곧바로 코드를 작성하게 두면 저장소 전체 맥락을 무시한 채 엉뚱한 가정을 사실로 굳히며 대규모 코드를 쏟아냈기 때문입니다.

당시 계획 모드는 두 가지 뚜렷한 목표를 가졌습니다.

1. 에이전트 지시 정밀화: 실행 전 저장소 구조와 요구사항을 스스로 점검하여 방황을 줄인다.
2. 사람의 인지적 통제권 확보: 수천 줄의 코드가 변경되기 전, 아키텍처 결정 포인트를 사람이 미리 검토하고 승인한다.

초기 도구들은 이를 구현하기 위해 선형 워터폴(Waterfall) 파이프라인을 제품 핵심 인터페이스로 채택했습니다.

[전통적 선형 계획 모드 워터폴]
┌─────────────┐      ┌───────────────┐      ┌──────────────┐      ┌─────────────┐
│ 채팅 & 프롬프트 │ ───► │ 거대 계획 문서  │ ───► │ 인간 검토·승인 │ ───► │ 자율 코드 구현│
│ (User Prompt)│      │ (Plan Spec)   │      │ (Approve)    │      │ (Implement) │
└─────────────┘      └───────────────┘      └──────────────┘      └─────────────┘

이 구조는 명쾌해 보였습니다. 하지만 실전 소프트웨어 개발 현장에 투입되자마자 심각한 마찰을 일으켰습니다.

---

2. Nuanced의 시도와 실패: 4가지 구조적 한계

전 GitHub 엔지니어 Ayman Nadeem은 AI 생성 코드의 검토 속도 불일치를 해결하고자 Nuanced를 창업했습니다. 코드가 너무 빠르게 변경될 때 개발자가 일관된 멘탈 모델을 유지하도록 돕는 계획 중심 개발 환경이었습니다.

Nuanced는 대화에서 모호함을 추출해 '지속적인 계획 문서(Living Plan Spec)'를 갱신하고, 명세가 복잡해지면 'Spec Tour'라는 가이드 투어 인터페이스까지 제공했습니다. 하지만 이 시도는 실패로 끝났습니다. Nadeem은 실패 원인을 네 가지로 정리합니다.

1) 계획하기(Planning)와 계획 문서(Plan Document)의 혼동

생각할 시간을 확보하는 행위(Planning)는 매우 가치 있습니다. 문제를 어떻게 나눌지, 어떤 엣지 케이스가 있을지 고민하는 과정입니다. 하지만 그 산출물로 나오는 방대한 텍스트 문서(Plan)는 다른 문제입니다.
- 개발자가 원한 것: 결정 포인트와 모호함을 짚어주는 대화형 사고 과정
- 도구가 강요한 것: 보존하고 관리해야 할 수백 줄짜리 정적 명세서

계획 모드 도구들은 '문서' 자체를 1급 객체(First-class Primitive)로 다루는 실수를 범했습니다.

2) 모델의 비약적 추론 능력 향상

초기에는 모델이 파일 위치나 라이브러리 사용법을 자주 틀려 명시적인 단계별 지침이 필수였습니다. 그러나 최신 모델(Claude 3.5/3.7/Opus, GPT-4o 등)은 저장소 탐색 도구를 사용해 스스로 기존 컨벤션을 파악하고 올바른 결정을 내립니다.
모델이 자율적으로 판단할 수 있는 영역이 넓어질수록, UI에 사전에 띄워 사람에게 확인받아야 할 결정 포인트는 줄어듭니다.

3) AI 생성 텍스트의 가독성 피로 (Glaze-over)

AI가 작성한 장황하고 구조화된 명세를 읽는 작업은 피로도가 높습니다. 개발자의 눈은 텍스트를 그냥 건너뛰게(Glaze over) 됩니다.
명세가 너무 길어 다시 '명세 요약본'을 생성해야 한다면, 원본 계획 문서는 이미 존재 가치를 잃은 셈입니다.

4) 비현실적인 선형 워터폴 가정

실제 엔지니어링 사고는 선형적이지 않습니다. 코드를 조금 작성해 보아야 의존성 충돌이나 타입 불일치를 발견하고, 그제서야 초기 설계의 모순을 깨닫습니다.
Chat → Spec → Approve → Implement 순서로 굳어진 인터페이스는 첫 실행 후 수정이 발생했을 때 워크플로를 거슬러 올라가야 하는 심각한 역행 비용을 유발합니다.

---

3. 패러다임의 전환: Understand-Act-Inspect 루프

계획 모드가 "죽었다"는 말은 계획 수립 자체가 무의미해졌다는 뜻이 아닙니다. "장문의 사전 계획 문서를 만들어 승인받는 별도 모드"가 종말을 고했다는 의미입니다.

현대 에이전틱 엔지니어링은 선형 파이프라인 대신 인터리브드(Interleaved) 루프로 수렴하고 있습니다.

       ┌────────────────────────────────────────────────────────┐
       │                                                        │
       ▼                                                        │
┌──────────────┐      ┌──────────────┐      ┌──────────────┐    │
│  Understand  │ ───► │     Act      │ ───► │   Inspect    │ ───┘
│ 맥락 파악·가설 │      │ 최소 단위 실행 │      │ 결과·피드백 검증│
└──────────────┘      └──────────────┘      └──────────────┘
       ▲                      │
       │                      ▼
       └────────────── ┌──────────────┐
                       │ Adjust / Fix │
                       │ 가설 수정·조정│
                       └──────────────┘

1. Understand (이해): 저장소 구조, 기존 코드, 관련 테스트를 읽고 작업 가설을 세웁니다.
2. Act (실행): 긴 계획을 승인받는 대신, 가장 불확실성이 높은 최소 단위 코드를 작성하거나 테스트를 돌립니다.
3. Inspect (검사): 린터, 컴파일러, 단위 테스트 출력, 브라우저 DOM 결과를 확인합니다.
4. Adjust (조정): 실행 결과를 바탕으로 다음 행동을 보정합니다.

Claude Code를 개발한 Boris Cherny는 Hacker News 토론에서 다음과 같이 언급했습니다.

"Plan mode는 본래 '아직 코드를 작성하지 마라(Don't code yet)'는 프롬프트 한 줄이었으며 도구셋을 바꾸지도 않았습니다. 모델의 사고 능력이 발전하면서 계획은 별도 모드가 아니라 대화와 턴(Turn) 사이에서 대화형·반복적으로(Interactive and Iterative) 흡수되었습니다."

---

4. 실전 아키텍처: 계획 문서 대신 무엇을 남겨야 하는가?

장황한 계획 문서를 걷어낸 자리에는 무엇이 들어가야 할까요? 상위 1% 에이전틱 엔지니어링 실무에서 검증된 핵심 패턴 세 가지를 정리합니다.

1) 계획 문서 대신 검증 가능한 작업 완료 조건 (Verifiable DoD)

장문의 텍스트 계획을 읽는 대신, 에이전트에게 명확한 작업 지시서 + 제약 조건 + 완료 정의(Definition of Done)를 부여합니다.

<!-- Bad: 에이전트에게 계획 문서를 요구 -->
"인증 모듈을 리팩토링할 상세 계획 문서를 5단계로 작성해줘."

<!-- Good: 검증 가능한 DoD와 실행 수단 제시 -->
"인증 토큰 갱신 로직을 Redis 기반 세션으로 이전해.
제약조건:
- 기존 /api/auth/* 엔드포인트의 반환 스키마를 변경하지 말 것.
- tests/auth_test.py가 모두 통과해야 함.
DoD:
- 신규 테스트 케이스 `test_token_refresh_concurrency` 작성 및 패스.
- 1페이지 분량의 변경 인터페이스 요약과 테스트 실행 로그 출력."

에이전트는 계획을 보고하는 대신 코드를 작성하고 테스트를 실행해 증거(Evidence)를 제시합니다.

2) 훅(Hooks)과 결정론적 가드레일: Zero Token 통제

프롬프트에 "계획을 엄격히 준수하라"는 규칙을 길게 적는 것은 컨텍스트 낭비입니다.
- 파일 수정 전 정적 분석 검사
- 허용되지 않은 디렉토리 쓰기 차단
- 테스트 미통과 시 커밋 금지

이러한 제약은 프롬프트가 아니라 하네스 레벨의 pre-tool-call 훅이나 CI 스크립트로 강제하는 편이 훨씬 경제적이고 안전합니다.

3) 캔버스와 시맨틱 Diff 중심의 사후 검토 인터페이스

에이전트가 5개, 10개로 병렬 실행될 때 개발자가 모든 중간 대화와 계획 문서를 읽는 일은 불가능합니다.
진짜 병목은 '계획 수립'이 아니라 '결과물 검토(Review)'에 있습니다.
- 어떤 가정을 기반으로 분기했는가?
- 아키텍처 경계를 침범한 변경은 없는가?
- 변경 전후의 시맨틱 인터페이스 계약이 깨지지 않았는가?

사전 계획서를 읽는 시간보다, 변경된 결과물의 시맨틱 Diff와 테스트 검증 리포트를 검토하는 최소 접점에 사람의 주의력(Human Attention)을 집중해야 합니다.

---

5. 결론: 워터폴의 종말과 피드백 루프의 복원

소프트웨어 공학의 역사는 '완벽한 사전 명세서'를 만들려던 시도가 언제나 실패했음을 보여줍니다. 애자일과 린(Lean) 방법론이 폭포수 모델을 밀어냈듯, AI 에이전트 하네스 역시 동일한 길을 걷고 있습니다.

• Plan Mode는 죽었습니다: 읽히지 않는 거대 AI 생성 계획 문서는 엔지니어의 인지 부채만 가중시킵니다.
• Planning은 살아있습니다: 모델과의 인터랙티브한 질의응답, 모호함을 제거하는 질문-답변 과정은 더욱 정교해졌습니다.
• 핵심은 빠른 루프와 증거입니다: Understand → Act → Inspect 사이클을 초단위로 돌리며, 사람이 검증할 수 있는 테스트 로그와 인터페이스 요약을 돌려주는 에이전트가 승리합니다.