계획 모드는 줄어들어도, 시스템을 이해하는 일은 남는다

TL;DR

• Ayman Nadeem은 계획 중심 코딩 앱 Nuanced의 접근이 실패했다고 돌아본다. 모델에 정밀한 절차를 일일이 알려 줄 필요는 줄었지만 사람이 시스템을 이해할 필요는 커졌다. 계획 모드에 대한 비판은 사고 과정 자체를 없애자는 주장이 아니다.
• 오래 보존한 명세가 곧 지속되는 이해는 아니었다. 긴 AI 생성 문서는 정보를 많이 담아도 읽기 어려웠고 핵심을 안내하는 Spec Tour도 복잡성을 더했다. 문서를 만들고 요약하는 작업이 사용자의 판단을 돕는지 따로 확인해야 한다.
• 계획과 구현을 엄격히 나누면 실행에서 배운 내용을 반영하기 어려워진다. Nuanced의 순차적인 승인 절차는 생각을 마쳐야 코딩을 시작할 수 있는 구조였다. 저자는 이해와 실행, 관찰과 수정이 이어지는 반복 과정을 더 적합하게 본다.
• 병렬 에이전트가 늘수록 사람의 주의를 어디에 쓸지가 중요해진다. 모든 대화와 변경을 읽는 방식으로는 시스템의 이해를 유지하기 어렵다. 에이전트가 판단이 필요한 지점과 그 맥락을 골라 보여 주는 문제는 아직 풀리지 않았다.

빠르게 만들어진 제품에 결정의 흔적이 없었다

Ayman Nadeem이 Nuanced를 만든 출발점은 코드 생성 속도와 이해 속도의 차이였다. 모델은 짧은 시간에 많은 코드를 만들었지만 사용자는 무엇을 왜 만들지 충분히 판단하기도 전에 유지보수할 제품을 떠안았다. 아키텍처를 덜 설명한 부분은 에이전트의 가정으로 채워졌고 잘못 나눈 추상화 경계가 여러 파일에 퍼졌다. 채팅 화면에서 보이는 답변만으로는 이런 결정을 알아차리기 어려웠다.

Conductor와 Codex처럼 여러 에이전트를 병렬로 돌리는 환경에서는 집중과 검증도 더 힘들어졌다. 사용자의 요청이 어떤 에이전트 판단을 거쳐 코드와 제품 동작으로 이어졌는지 명료한 흔적이 부족했기 때문이다. 저자가 원한 것은 모든 코드와 파일을 다시 직접 살피는 과거로의 회귀가 아니었다. 자연어로 아이디어를 다루면서도 시스템이 어떻게 작동하는지 놓치지 않는 작업 방식이었다.

계획을 보존하면 이해도 남을 것이라는 가정

Nuanced는 스레드별 대화에서 모호한 요구와 사용자가 결정할 사항을 드러내고 구현 전에 지속적으로 보관할 계획을 만들었다. 채팅 기록 속으로 사라지는 텍스트를 개발의 중심 문서로 끌어올린 셈이다. 이후 구현이 요구를 따르는지 확인하며 의도에서 구현·리뷰·검증까지 이어지는 흐름을 지향했다. 계획은 모델을 지시하는 도구이면서 사람이 진행 상황을 이해하는 보조 수단이어야 했다.

실제 사용에서는 생각을 정리하는 과정의 가치가 큰 명세를 보관하는 가치로 그대로 이어지지 않았다. 초기 사용자는 구조화된 문서를 읽는 데 예상보다 관심이 적었다. 여기에 모델의 저장소 탐색과 문맥 이해가 좋아지면서 사람이 미리 명시해야 할 결정도 줄었다. 더 나은 사고 인터페이스를 만들려던 시도는 모델이 스스로 해결하는 범위의 확대와도 경쟁했다.

긴 명세를 읽게 하려고 설명을 하나 더 붙였다

명세에는 결정과 배경이 많이 들어 있었지만 독자가 얻는 명료함은 그만큼 늘지 않았다. 저자는 AI 생성 문장의 리듬과 지나친 구조화 때문에 자신도 문서를 읽다가 집중을 잃었다고 돌아본다. 무엇을 기록했는지와 사람이 그것을 소화할 수 있는지는 다른 문제였다. 정보를 잘 보관하는 기능만으로는 사용자의 이해가 갱신되지 않았다.

이를 해결하려고 만든 Spec Tour는 문서의 중요한 부분을 순서대로 안내했다. 그러나 읽어야 할 설명이 추가되면서 화면과 작업 흐름은 더 복잡해졌다. 긴 명세를 이용하려면 다시 짧은 표현을 만들어야 한다면 원래의 큰 문서가 누구에게 필요한지 되묻게 된다. 실패의 원인을 문서 부족으로 해석하고 설명을 더하는 대응이 오히려 부담을 키운 사례다.

계획과 구현을 오가야 하는데 절차는 한 방향이었다

Nuanced의 작업은 대화와 모호함 해소를 거쳐 명세 생성·검토·수정·승인·구현·코드 리뷰 순으로 진행됐다. 하지만 실제 문제 해결에서는 일부만 이해한 상태로 시도하고 결과를 본 뒤 생각을 바꾸는 일이 흔하다. 구현을 시작해야 새로운 질문을 발견하기도 한다. 이 과정에서 앞선 사고로 돌아가는 행동이 제품 안에서는 이미 끝낸 단계로 되돌아가는 것처럼 느껴졌다.

저자는 모델이 자율적으로 실행하고 결과를 검사하며 접근을 고칠 수 있게 되면서 계획과 실행의 경계도 흐려진다고 본다. 이해한 뒤 행동하고 결과를 살펴 질문을 명확히 하며 조정한 다음 다시 실행하는 반복이다. 그 안에서도 계획은 계속 일어나지만 반드시 별도의 계획 문서로 나타날 필요는 없다. 고정된 계획을 승인하는 순간보다 작업 중 이해가 어떻게 바뀌는지가 중요해진다.

사람에게 남겨야 할 것은 모드 선택보다 판단이다

Nuanced는 작은 작업에 명세를 강요하지 않도록 계획 모드와 빌드 모드를 나눴다. 그러자 사용자는 작업 전에 계획이 필요한지부터 판단하고 버튼이나 단축키로 올바른 모드를 선택해야 했다. 저자는 이미 문맥을 가진 AI가 도울 수 있는 판단을 사용자의 추가 기억 과제로 만든 셈이라고 평가한다. 필요할 때 대화로 계획하는 단순한 인터페이스가 오히려 자연스러웠다는 결론이다.

그렇다고 채팅만으로 이해의 문제가 해결되지는 않는다. 병렬 에이전트가 많아질수록 모든 대화를 읽거나 각 코드 변경에 설명을 요청하는 방식은 버티기 어렵다. 에이전트는 사람이 개입했을 때 효과가 큰 소수의 지점을 찾고 판단에 충분한 맥락을 보여 줘야 한다. 이 글은 Nuanced의 제품 회고이며 모든 프로젝트에서 계획 문서가 무용하다는 실험 결과는 아니다. 저자가 남긴 문제는 문서 생성이 아니라 변화하는 시스템을 사람이 계속 이해하도록 돕는 인터페이스다.

참고 자료

Ayman Nadeem — Plan mode is dead — 제품 실패에 대한 저자의 회고와 견해를 바탕으로 정리했다. 선형·반복 워크플로 비교 그림도 대조했다.