플랜 모드는 죽었다
요약
AI의 코드 생성 속도가 급증함에 따라, 기존의 '플랜 모드' 방식은 한계에 도달했다는 분석입니다. 플래닝이 에이전트에게 지침을 주는 목적은 약해지고 있으며, 대신 인간 개발자가 시스템 전체의 일관된 정신 모델(mental model)을 유지하는 것이 가장 중요합니다.
핵심 포인트
- AI 코드 생성 속도 증가로 기존 '플랜 모드'는 한계에 도달함.
- 핵심은 에이전트에게 지침 주기보다, 인간 개발자의 시스템 이해력 유지임.
- 빠른 코딩 속도는 높은 유지보수 부담과 설계 오류를 야기할 수 있음.
- 개발자는 제품 결정 및 아키텍처 경계를 명확히 정의해야 함.
올해 초, 저는 AI를 이용해 소프트웨어를 구축하는 데 있어 플래닝(planning)이 가장 중요한 부분이 될 것이라고 믿었습니다.
이 아이디어에 대한 저의 믿음은 너무 강해서, 저는 이와 관련된 전체 데스크톱 코딩 앱을 만들고 출시했습니다. Nuanced는 AI가 코드 생성 속도와 양을 급격히 증가시켰다는 관찰에서 동기를 얻었지만, 이러한 새로운 작업 속도를 지원하는 인터페이스는 아직 따라가지 못하고 있었습니다.
Nuanced의 플래닝 접근 방식은 실패했지만, 이는 또한 저에게 플랜 모드(plan modes)가 더 광범위하게 사용되기에는 그다지 유용하지 않다는 것을 깨닫게 해주었습니다. 역사적으로 플랜 모드는 두 가지 목적을 수행했습니다: (1) 에이전트(agent)에게 충분히 정확한 지침을 지정하고, (2) 인간이 자신이 무엇을 만들고 있는지 이해하는 데 도움을 주는 것이었습니다.
저는 #1이 모델들이 좋아지면서 빠르게 구식이 되고 있다고 생각합니다. 저는 #2가 그 어느 때보다 중요하다고 생각하지만, 플랜 모드는 그것에 적합한 추상화(abstraction)가 아니며, 특히 우리가 실행하는 병렬 에이전트(parallel agents)의 수가 증가함에 따라 더욱 그렇습니다.
Nuanced를 구축한 이유
제가 만들도록 동기를 부여받은 제품은 궁극적으로 제가 여전히 관련성이 있다고 생각하고 항상 관련성이 있을 질문에 답했습니다. 즉, 기계가 인간이 검사할 수 있는 속도보다 빠르게 시스템을 변경할 때, 어떻게 인간이 소프트웨어 시스템의 일관된 정신 모델(mental model)을 유지할 수 있는가 하는 것입니다?
모델들은 몇 분 만에 수천 줄의 코드를 작성할 수 있다는 의미였고, 이는 심지어 무엇을 만들거나 왜 만드는지 생각하기도 전에 엄청난 유지보수 부담을 물려받게 됨을 의미했습니다. 이로 인해 동작에 대해 추론하거나 미리 코드화되어 버린 잘못된 가정을 디버깅하기가 어려웠습니다.
이러한 방식으로 코드를 생성하는 것이 쉬운 점은 더 큰 도파민 보상을 유발했지만, 무언가를 구축하는 것이 왜 중요한지, 심지어 아예 중요한지 여부를 이해하고 제품, 디자인, 인프라 결정을 엄격하게 평가해야 하는 불편한 작업을 모호하게 만들었습니다. 저는 의식적으로 어떤 제품 결정도 내리기 전에 종종 이미 제품을 가지고 있었습니다. 제가 아키텍처를 충분히 명시하지 않으면, 에이전트는 나중에 저에게 문제를 일으킬 수 있는 방식으로 추상화 경계를 만든다 하더라도 그 공백을 채우는 자유를 누렸습니다. 의도된 동작과 디자인에 대한 이러한 오해는 채팅 표면 아래 여러 파일로 전파되었고 쉽게 놓칠 수 있었습니다. 이 표면 아래에서 이해하기 어려운 문제들을 찾아 헤매는 것은 애초에 무언가를 올바르게 설계하는 것보다 덜 효율적으로 느껴졌습니다.
Conductor나 Codex 같은 코딩 앱들이 여러 에이전트를 병렬로 실행할 수 있는 능력을 가능하게 하면서, 이 경험은 제가 정신적으로 단절되고 좀비처럼 느끼게 만들었습니다. 저는 예전에 할 수 있었던 것만큼 작업하고 있는 것에 깊이나 이해에 집중하기 어렵다고 느꼈습니다. 이는 또한 생성된 결과가 올바른지 검증하는 것을 더 어렵게 만들었습니다.
사용자 프롬프트 → 에이전트 결정 → 코드 → 제품 동작 간의 연결을 보여주는 명확하고 해석 가능한 추적(trace)이 없었습니다. 이것이 제가 예전처럼 코드 라인이나 파일을 살펴보는 옛날로 돌아가고 싶다는 의미는 아니었습니다. 사실 저는 자연어로 아이디어에 대해 추론하는 것이 더 쉽고 효율적이라고 느꼈습니다. 시스템이 어떻게 작동하는지에 대한 저의 이해를 희생하지 않으면서, 자신 있게 코드 위를 항해하고 싶었습니다.
기존 플랜 모드는 충분히 협업적이지 않았다
플랜 모드가 존재했음에도 불구하고, 잘 계획하기 위한 적절한 추상화(abstraction)가 없다고 느꼈습니다. Claude Code CLI, Conductor를 거쳐 마침내 Codex가 출시될 때까지 돌아보면서, 저는 명확하게 반복할 수 있는 공간 없이 세심하게 계획을 다듬고 깎아내는 작업을 했습니다. 이전에는 채팅 기능을 사용하고, 그 후 계획의 일부 조각들을 새로운 메시지에 복사하여 수정했습니다 (Codex의 주석 기능이 생기기 전까지). 이 잘라 붙여넣기(cut-and-paste) 방식의 작업 흐름은 투박하게 느껴졌고, 현재 진행 중인 계획을 추적하면서 아이디어를 발전시키는 것이 매우 힘들었습니다.
저는 저의 계획들에 '집'을 주고 싶었고, 그것들을 전반적인 작업 흐름에 근거시키고 싶었으며, 대화가 진행됨에 따라 스크롤 뒤로 사라지는 일시적인 텍스트 덩어리(ephemeral blobs of text)에서 살아 숨 쉬는 영구적인 문서(persistent document)로 만들고 싶었습니다. 저는 몇 가지 이유 때문에 플랜 모드를 '최상위 원시 요소(first-class primitive)'로 만들어 개발을 안내하는 도구로 만들고 싶었습니다:
- 무엇을 해야 할지 생각해야 했습니다.
- 그것을 충분히 정확하게 설명해야 한다는 것을 확실히 해야 했습니다.
- 무엇이 완료되었는지 이해해야 했습니다.
- 상황이 잘못되었을 때 왜, 그리고 어떻게 되었는지 이해해야 했습니다.
꿈의 구축(Building the dream)
저는 저의 이상적인 작업 흐름에 대해 생각했고, 그것을 제품으로 인코딩하여 현실화하기로 결정했습니다. Nuanced는 각 스레드가 채팅 대화였던 스레드를 생성할 수 있게 해주었습니다. 사용자는 무엇을 만들고 싶은지 이야기하면, 시스템은 모호한 부분과 사용자 입력이 필요한 결정을 제시하고, 함께 구현이 시작되기 전에 영구적인 계획에 도달하게 됩니다. 그런 다음 Nuanced는 그 계획을 구현하여, 생성된 코드가 요구 사항을 준수하는지 확인합니다. 저는 의도(intent)에서 시작하여 구현, 검토, 검증까지 모든 과정으로 이어지는 엔드투엔드 파이프라인(end-to-end pipeline)을 원했습니다. 그것은 단순히 또 다른 코딩 앱이라기보다는 인간의 정신(혹은 저의 ADHD를 앓는 정신)을 위한 의수(prosthesis)처럼 보였는데, 왜냐하면 그것은 도움을 주는 것만큼이나 무엇이 일어나고 있는지 추적하도록 지시하는 역할을 하도록 설계되었기 때문입니다.
제가 틀렸던 이유 (Why I was wrong)
제가 기존 도구의 격차나 SDLC가 어떻게 변화하는지에 대한 아이디어가 틀렸던 것이 아니라, 저희 구현이 기대했던 솔루션을 제공하지 못했기 때문입니다. 그 이유는 다음과 같습니다:
- 계획(planning)을 계획서(plan)와 혼동했습니다.
- 모델들이 정말 좋아졌습니다.
- 아무도 AI가 생성한 텍스트를 읽고 싶어 하지 않습니다.
- 저희는 계획과 구축(building)을 분리했는데, 이것이 파괴적이었습니다.
계획(Planning) != 계획서(Plan)
저희가 가장 먼저 배운 것은 계획(planning)을 계획서(plan)와 혼동했다는 것입니다. 이 둘은 실제로 같지 않습니다. 저는 무언가를 구현하기 전에 충분히 생각할 수 있는 공간이 가치 있다고 가정했습니다. 또한 프로젝트가 발전함에 따라 그러한 사고 과정을 대규모의 구조화된 아티팩트 형태로 보존하는 것도 가치 있다고 생각했습니다. 하지만 초기 사용자들은 그 사양서(spec)에 대해 놀라울 정도로 낮은 관심을 보였습니다.
모델들이 정말 좋아졌습니다
모델들이 컨텍스트와 메모리를 통해 대규모 코드베이스를 이해하는 능력이 향상되면서, 리포지토리를 탐색하고 합리적인 가정을 하는 데 탁월함을 보였습니다. 모델에게 잘 생각된 결과를 명시적으로 지시할 필요성이 줄어들었습니다.
저는 원래 모델의 역량을 인간 사고를 위한 더 나은 인터페이스를 설계하는 것과 경쟁한다고 생각하지 않았지만, 여러 면에서 실제로 그랬습니다. 왜냐하면 모델이 스스로 신뢰성 있게 내릴 수 있는 결정 하나하나가 표면화되어야 할 결정이 하나씩 줄어들었기 때문입니다.
AI가 생성한 텍스트는 읽기 고통스럽다
사양서에는 더 많은 정보가 담겨 있었지만, 명확성을 높이지는 못했습니다. 이는 저희의 사양서가 길었기 때문입니다. 그것들은 중요한 결정들을 포착하고 유용해 보이는 많은 컨텍스트를 포함했지만, 문제는 다음과 같았습니다. 그것들이 AI가 생성했다는 것입니다. AI가 생성한 텍스트 특유의 속도감과 지나치게 구조화된 성격 때문에 읽기가 매우 어렵습니다. 제 눈이 계속 초점을 잃었습니다.
이 발견에 반응하여 스펙을 폐기하는 대신, 우리는 Spec Tour를 구축하여 이 문제를 해결했습니다. 저희는 누군가에게 전체 문서를 흡수하도록 요청하기보다는, Spec Tour가 중요한 부분들을 안내해 줄 수 있을 것이라고 생각했습니다. 하지만 이것은 단지 추가적인 복잡성 계층만을 덧붙였을 뿐이며, 제 화면에는 주의를 요구하는 더 많은 텍스트만 생겼습니다. 만약 스펙을 사용 가능하게 만들기 위해 더 짧은 표현이 필요하다면, 애초에 전체 문서의 의미가 무엇이었을까요?
연속적이어야 하는 프로세스를 분리함
저희의 워크플로우는 너무 선형적이고 순차적이었습니다. 저희의 과정은 다음과 같았습니다:
채팅(chat) → 질문에 답하여 모호성 해소(disambiguate by answering questions) → 스펙 생성(generate spec) → 스펙 검토(review spec) → 스펙 수정(revise spec) → 승인(approve) → 구현(implement) → 코드 검토(review code)
실제 사고는 이런 방식으로 일어나지 않으며, 이 부분들 사이의 분리는 인위적이고 강요된 느낌이었습니다. 보통은 문제의 일부를 이해하고, 무언가를 시도해 보고, 초기 생성 과정에서 새로운 것을 배우게 되며, 이는 당신으로 하여금 그것에 대한 마음을 바꾸고 다른 무언가를 시도하게 만들 수 있습니다. 각 단계는 새로운 질문을 노출합니다. 계획(planning)과 구축(building)은 교차하며(interleaved) 더 유기적으로 나타나는데, 특히 Nuanced에서 우리가 구축한 방식이 그렇습니다. 저희의 인터페이스는 사용자가 빌드를 시작할 수 있도록 너무 일찍 '사고를 마무리'하도록 강요했습니다. 일단 구현이 시작되면, 이전 채팅 기반 추론으로 돌아가는 것은 워크플로우상 뒤로 물러나는 것처럼 느껴졌습니다. 폭포수(waterfall)처럼 되돌아갈 방법이 없었습니다.
Codex가 현재 어떻게 작동하는지 살펴보면, 계획과 실행 사이의 경계는 이 둘이 하나로 붕괴되면서 사라지고 있습니다. 이전에는 코딩 에이전트들이 인간이 다음과 같은 워크플로우를 수행함으로써 이점을 얻었습니다:
계획(plan) → 승인(approve) → 실행(execute)
그때는 잘못된 방향으로 나아가는 비용이 훨씬 더 높았습니다. 하지만 에이전트들이 시스템을 이해하는 능력이 향상됨에 따라, 스스로 자율적으로 행동하고 자신의 작업을 테스트하는 능력도 함께 향상되었습니다. 또한 결과물을 검사한 후 접근 방식을 수정하는 데에도 능숙합니다. 이는 다음과 같은 다른 루프를 가능하게 합니다:
이해(understand) → 행동(act) → 검사(inspect) → 명확화(clarify) → 조정(adjust) → 재행동(act again)
여전히 그 루프 안에서 엄청난 양의 계획이 진행되지만, 반드시 “계획서”라는 문서 형태로 나타날 필요는 없습니다. 제가 저지른 가장 큰 실수는 계획을 개선된 인간 이해를 위한 프로세스를 설계하는 대신 하나의 결과물(artifact)로 만들었다고 생각합니다.
플랜 모드와 빌드 모드는 이상한 분리였다
Nuanced는 플랜 모드와 빌드 모드를 가지고 있었고, 사용자는 둘 중 어느 것으로든 시작할 수 있었습니다. 플랜 모드는 항상 명세서(spec)를 생성했지만, 빌드 모드는 사용자에게 명세서를 강요하지 않았으며 명세서가 필요 없는 작은 작업에 사용될 수 있었습니다. 하지만 이 두 모드 간의 분리는 어색했고, 사용자가 과연 어떤 작업이 계획을 할 가치가 있는지라는 메타 질문을 스스로 던지고, 만약 그렇다면 버튼이나 단축키를 통해 플랜 모드를 활성화하는 것을 기억해야 했습니다. 이는 AI가 이미 가지고 있는 맥락(context)을 기반으로 사용자에게 만들어주어야 하는 구분처럼 느껴졌고, 어떤 모드에 있어야 하는지 기억하는 것은 더 많은 인지 부하(cognitive load)를 유발하는 것 같았습니다.
이러한 깨달음은 저를 미드위트 밈(midwit meme)을 느끼게 했는데, 즉 계획이 기본값으로 이루어지는 것이 아니라 필요할 때만 이루어지는 채팅 인터페이스의 단순함이 실제로 매우 좋다는 생각이 들었습니다.
우리는 여전히 이해 문제를 해결하지 못했다
무엇을 구축할지, 왜 중요한지, 그리고 결정을 평가하는 과정을 생각하는 것은 여전히 중요합니다. 사람들은 무슨 일이 일어나고 있는지에 대한 일관된 정신 모델(mental model)을 구축해야 하지만, 저는 대량의 AI가 생성한 텍스트가 그 인터페이스로 적절하지 않다고 생각합니다. 채팅에서 결정을 처리하는 것이 더 직관적으로 느껴지지만, 시스템이 변경됨에 따라 그 이해를 최신 상태로 유지하는 것은 여전히 해결되지 않은 문제입니다.
이 문제는 에이전트(agent)의 수가 5개에서 수백 개로 늘어날수록 더욱 어려워집니다. 모든 대화를 읽고 각 코드 변경 사항에 대한 설명을 프롬프트로 요청하려고 노력하는 것으로 따라잡을 수는 없습니다. 에이전트는 인간의 주의가 가장 큰 영향을 미칠 수 있는 최소한의 지점을 식별하고, 그 주의를 유용하게 만들 충분한 컨텍스트(context)를 노출해야 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 HN Claude Code Search의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기