플랜 모드는 끝났습니다 — 계획 문서보다 중요한 사람의 이해

AI 요약

AI 코딩 도구를 쓰면 에이전트가 몇 분 만에 수천 줄을 작성합니다. 하지만 개발자가 의도와 설계 결정을 충분히 살피기 전에 코드가 굳어지면, 잘못된 가정이 여러 파일로 퍼지고 결과를 검증하기도 어려워집니다. 이 문제를 해결하려고 저자 Ayman Nadeem은 대화부터 계획 수립, 구현, 검토까지 잇는 데스크톱 코딩 앱 Nuanced를 만들었습니다. 제품을 운영하며 내린 결론은 계획 자체가 쓸모없다는 뜻이 아닙니다. 계획을 별도의 모드나 긴 문서로 고정하는 방식이 더는 적절하지 않을 수 있다는 이야기입니다.

Nuanced가 계획 모드로 풀려던 문제

저자는 계획 모드가 두 가지 역할을 해왔다고 봅니다. 하나는 에이전트가 실행할 만큼 정확한 지시를 만드는 일이고, 다른 하나는 사람이 무엇을 만들고 있는지 이해하도록 돕는 일입니다. 모델이 코드베이스를 더 잘 파악하고 합리적인 가정을 세우면서 첫 번째 역할은 줄어들고 있습니다. 반면 여러 에이전트가 병렬로 작업할수록 사람이 전체 상황을 파악하는 문제는 커집니다.

Nuanced에서는 사용자가 대화로 요구사항을 설명하면 시스템이 모호한 부분과 결정이 필요한 질문을 찾아내고, 함께 지속적으로 관리할 계획을 만든 뒤 구현을 시작하도록 설계했습니다. 저자는 계획을 대화 기록 속에서 사라지는 텍스트가 아니라 개발 흐름을 이끄는 문서로 만들고 싶었습니다. 사람이 무엇을 할지 생각하고, 요구사항을 정확히 정리하고, 진행 상황과 실패 원인을 이해하도록 돕는 제품을 구상했습니다.

하지만 초기 사용자들은 긴 명세 문서를 적극적으로 읽지 않았습니다. 저자는 계획과 계획 문서를 같은 것으로 본 점이 문제였다고 돌아봅니다. 모델 성능이 좋아지면서 매번 세부 지시를 적을 필요도 줄었습니다. 게다가 문서가 많은 정보를 담더라도 명확해지는 것은 아니었습니다. AI가 만든 문장은 길고 구조가 과하게 정돈돼 있어 읽기 어려웠고, 문서의 중요한 결정을 파악하기도 쉽지 않았습니다. 핵심 내용을 따로 보여주는 ‘Spec Tour’를 추가했지만, 읽어야 할 텍스트와 인터페이스만 늘었습니다.

계획과 실행은 한 흐름에서 오갑니다

Nuanced의 절차는 대화, 질문으로 모호성 해소, 명세 생성과 검토, 수정과 승인, 구현과 코드 검토 순서로 진행됐습니다. 저자는 실제 사고가 이렇게 직선적으로 흐르지 않는다고 말합니다. 일부를 이해한 뒤 구현해보고, 결과를 보며 생각을 바꾸고, 다음 질문을 찾아가는 과정이 더 자연스럽습니다. 계획과 구현은 번갈아 이어지는데, 별도 계획 모드는 사용자가 생각을 끝낸 뒤에야 개발을 시작하게 만드는 듯한 단절을 낳았습니다.

저자는 에이전트 작업이 과거의 ‘계획 → 승인 → 실행’에서 ‘이해 → 실행 → 확인 → 명확화 → 조정 → 재실행’으로 바뀌고 있다고 설명합니다. 이 과정에도 계획은 계속 들어갑니다. 다만 계획을 반드시 ‘계획서’라는 문서로 만들 필요는 없습니다. 저자의 가장 큰 실수는 사람의 이해를 돕는 과정을 설계하는 대신 계획을 결과물로 고정한 점입니다. 계획 모드와 구현 모드를 나누면 작업마다 어느 모드를 쓸지 사용자가 판단해야 하는 부담도 생깁니다. 저자는 필요한 순간 대화로 계획하는 일반 채팅 인터페이스가 더 나을 수 있다고 봅니다.

남은 과제는 시스템에 대한 이해입니다

저자는 계획 모드를 없애면 문제가 모두 해결된다고 주장하지 않습니다. 무엇을 만들지, 왜 필요한지, 설계 선택이 타당한지 검토하는 일은 여전히 중요합니다. 다만 AI가 만든 긴 문서가 사람의 이해를 돕는 최선의 방법인지는 의문이라고 말합니다. 작업 규모가 커지고 에이전트 수가 늘어날수록 모든 대화를 읽고 코드 변경마다 설명을 요구하는 방식은 확장하기 어렵습니다. 에이전트가 사람의 주의가 필요한 지점을 선별하고, 판단에 쓸 맥락을 함께 제공해야 한다는 문제는 아직 해결되지 않았습니다.

Hacker News 반응

• @dbbk — 저는 Claude의 Plan mode를 매일 쓰며 만족합니다. 계획을 다듬을 때 거의 늘 의견이 생기고, 코드를 쓰기 전에 계획할 시간을 분리하고 싶습니다. 계획 모드가 사람이 과정에 참여하고 협력하게 해주는 기능인데, 개발자들이 AI가 일자리를 없앤다고 걱정하면서 그 기능을 없애려는 이유를 모르겠습니다.
  • @spacedcowboy — 저는 사람이 반나절이면 할 작은 작업보다 몇 달에서 1년 걸릴 큰 작업을 LLM에 맡깁니다. 계획서를 살아 있는 문서로 만들고 한두 시간 검토한 뒤에 시작합니다. 프로젝트가 상당히 크다면 무엇을 만들지 자세히 계획하지 않고 접근할 방법이 없습니다.
• @tcdent — 계획 모드가 필요한 진짜 이유는 이제 줄었습니다. 에이전트에게 저장소를 수정하지 말라고 하거나 지정한 문서만 바꾸라고 대화로 지시하면 따릅니다. 예전에는 도구 사용을 제한해야 했지만 이제는 그렇지 않습니다.
  • @throwaway27448 — 대화만으로는 계획과 결정의 감사 기록이 남지 않습니다. 저는 보통 “변경 X의 계획을 제안하고 파일 Y에 쓰세요”, “파일 Y의 M~N단계를 실행하세요”라고 요청합니다. 시간이 낭비되고 나서야 이 절차가 필요한 이유를 알게 됩니다. 원하는 걸 이해하지 못한 채 Claude와 대화하는 이유가 무엇인지 모르겠습니다.
• @bcherny — [Claude Code 제작자] 저자는 대체로 맞습니다. 계획 모드는 유용했지만 지금은 덜 유용합니다. Claude Code에서 계획 모드는 “아직 코딩하지 말라”는 알림을 사용자 메시지마다 추가할 뿐이며, 도구 목록을 바꾸지는 않습니다. 초기 모델을 쓰던 시절에는 새 세션마다 먼저 계획하라고 말하기 번거로워 제가 만든 기능이었습니다. 모델이 발전하고 복잡한 작업의 계획이 상호작용과 반복을 거치는 과정으로 바뀌면서 저도 계획 모드를 덜 쓰게 됐습니다. 복잡한 변경은 필요할 때 다이어그램이나 데모 같은 자료로 설명해 PR에 붙입니다.
  • @akersten — 모델이 더 똑똑해져도 제 의도를 잘못 추측하는 문제는 해결되지 않습니다. 계획 모드에서는 모델이 내릴 결정을 미리 보고, 시간과 토큰을 낭비하기 전에 바로잡을 수 있습니다.
  • @bcherny — 최신 모델에서는 그런 일이 자주 보이지는 않습니다. 그래도 계획 모드는 없어지지 않습니다. /plan을 쓰거나 Claude에게 계획 모드로 들어가라고 하면 됩니다.
  • @aymandfire — 제가 말하려던 구분도 그 부분입니다. 에이전트에게 실행할 만큼 정확한 지시를 주는 역할은 줄지만, 사람이 어떤 일이 일어날지 이해하는 역할은 더 중요해집니다. 제가 바뀐 생각은 그 이해를 돕는 인터페이스입니다. 사람이 직접 쓰지 않은 긴 생성 문서보다 상호작용하고 반복하는 방식이 더 자연스러울 수 있습니다.
• @solarkraft — 계획이 쓸모없어진 게 아니라, 모델이 더 긴 작업을 할 수 있게 되면서 계획이 단순한 ‘Plan Mode’ 기능을 넘어선 것이라고 봅니다.
• @bfung — 동의하지 않습니다. 여러 구성요소가 복잡하게 얽힌 작업에서는 계획 모드가 잘 만든 계획을 제공해, 밤새 실행해도 되는 상태를 만들 수 있습니다. 계획 없이 진행하면 계속 사람이 방향을 잡아줘야 합니다.
• @theholygrail — 영향 범위가 큰 작업에서는 계획 모드가 여전히 쓸모 있습니다. 파일 하나를 바꿀 때는 생략하지만 인증, 결제, 공유 스키마를 건드릴 때는 먼저 계획을 적어두고 싶습니다. 모델을 더 똑똑하게 만드는 일이 아니라, 코드가 바뀌기 전에 사람이 멈춰서 살펴보게 하는 기능입니다.
• @loveparade — 저에게 계획 모드의 가장 큰 가치는 계획 문서가 아니라 구현 전 충분한 맥락을 조사하게 하는 점입니다. 계획 모드가 없으면 모델이 코드를 충분히 읽기 전에 잘못된 해결책을 구현할 때가 있습니다. 읽기 전용이라는 점도 유용합니다. 여러 에이전트가 동시에 계획해도 작업 공간 충돌을 걱정하지 않아도 됩니다.
• @taurath — 개발자가 시스템을 이해하지 못하는 상황이 늘고, 코드 검토는 ‘문제 없음’ 표시로 줄어들며, 아무도 읽을 수 없는 코드베이스가 생기는 모습을 봅니다. 계획 모드는 사람이 전략과 설계, 아키텍처를 이해하는 데 도움이 됐습니다. 규율을 지키면 다른 방식으로도 가능하겠지만, 에이전트가 쌓는 기술 부채가 곧 큰 문제가 될까 걱정됩니다.
  • @frankc — 코드베이스를 이해하지 못한다면 에이전트에게 설명을 요청하면 됩니다. 현대의 주요 모델은 코드 작성보다 설명을 더 잘하기도 합니다. 다이어그램과 테스트를 만들고, 설계를 선호하는 방식에 맞춰 리팩터링하게 할 수도 있습니다. 내부 코드보다 에이전트가 성공하도록 시스템과 도구를 만들고, 외부 동작을 검증 가능하고 결정적으로 만드는 데 집중해야 합니다.
  • @spiffytech — 모델이 먼저 설명해주는 부분은 괜찮습니다. 하지만 모델이 중요하지 않다고 판단해 말하지 않은 내용을 놓칠 때가 있습니다. 예전 방식으로 코드를 직접 작업했다면 금방 발견했을 문제입니다.
• @OutOfHere — Codex에서 계획 모드는 명세의 심각한 문제를 찾는 데 유용합니다. 수정한 명세에 문제가 더는 나오지 않을 때까지 계획 모드를 반복 실행한 다음에야 실행합니다.
• @bityard — 기능을 구현하려는 아이디어를 쓸 때는 사람조차 처음부터 제 뜻을 이해한다고 믿지 않습니다. 제 설명에 오류가 있거나 상대가 잘못 가정하는 일은 늘 있습니다. LLM이 아무리 좋아졌다고 해도 사람보다 제 의도를 더 잘 이해한다고 믿을 수 없습니다.

원문: Ayman Nadeem / 번역·요약: Trawling