← 목록으로

계획 모드는 죽었다

• 모델이 저장소를 탐색하고 합리적인 가정을 세우는 능력이 좋아지면서, 구현 방법을 사람이 미리 상세히 지시하는 계획(Plan) 모드의 필요성이 줄어들고 있음
• 구현 전에 생각을 정리하는 과정은 유용하지만, 그 결과를 방대한 계획 문서로 남긴다고 이해까지 깊어지는 것은 아님
• 계획 문서를 먼저 검토하고 승인하는 선형 절차보다, 이해하고 실행한 뒤 결과를 살펴 접근법을 바꾸는 반복 과정이 실제 개발에 더 잘 맞음
• Nuanced에서 계획을 지속적으로 편집하는 기능을 만들었지만, 사용자에게는 명세를 관리하고 모드를 선택하는 절차보다 단순한 대화 흐름이 더 자연스러웠음
• 여러 에이전트가 코드를 바꿔도 사람이 시스템을 이해하고 통제할 수 있어야 함. 필요한 것은 더 많은 문서가 아니라, 사람이 판단해야 할 핵심 지점과 그에 필요한 맥락임

Nuanced가 해결하려던 이해의 문제

• Nuanced는 AI가 코드 생성 속도와 양을 크게 늘렸지만, 이를 뒷받침할 인터페이스는 따라오지 못한다는 문제에서 출발한 데스크톱 코딩 앱임
• 중심 질문은 기계가 사람이 검토할 수 있는 속도보다 빠르게 소프트웨어를 바꿀 때, 사람이 어떻게 시스템에 대한 일관된 멘탈 모델을 유지할 수 있느냐는 것임
• 모델이 몇 분 만에 수천 줄의 코드를 만들면, 무엇을 왜 만드는지 충분히 생각하기도 전에 유지보수 부담을 떠안게 됨
  • 잘못된 가정이 일찍 코드로 굳어져 동작을 추론하고 문제를 디버깅하기 어려워짐
  • 코드 생성의 즉각적인 보상은 제품이 필요한 이유와 제품/디자인/인프라 결정을 엄밀히 평가하는 일을 가릴 수 있음
  • 아키텍처를 충분히 지정하지 않으면 에이전트가 빈틈을 채우며, 그 과정에서 정한 추상화 경계가 나중에 문제를 일으킬 수 있음
  • 의도한 동작과 설계에 대한 오해가 채팅에 드러나지 않은 채 여러 파일로 퍼져 쉽게 눈에 띄지 않음
• Conductor와 Codex처럼 여러 에이전트를 병렬로 실행하는 앱에서는 작업에 깊이 집중하고 결과의 정확성을 검증하기가 더 어려웠음
• 필요한 것은 코드 줄과 파일을 일일이 읽는 방식으로 돌아가는 것이 아니라, 사용자 프롬프트 → 에이전트 결정 → 코드 → 제품 동작의 연결을 이해할 수 있는 추적 경로였음
  • 자연어로 아이디어를 다루는 효율성을 유지하면서도 시스템 이해를 포기하지 않는 작업 방식이 목표였음

계획을 지속적인 작업 문서로 만들려던 시도

• Claude Code CLI, Conductor, Codex를 오가며 계획을 다듬는 과정에는 이를 지속적으로 수정할 마땅한 공간이 없었음
  • Codex의 주석 기능이 나오기 전에는 채팅에서 계획 일부를 복사해 새 메시지에 붙여 넣으며 수정했음
  • 이 방식은 아이디어를 발전시키면서 현재 계획을 추적하기에 번거로웠음
• 대화가 길어지면 위로 밀려나는 일시적인 텍스트 대신, 계획을 개발 흐름에 자리 잡은 지속적인 문서로 만들려 했음
  • 무엇을 할지 생각해야 함
  • 원하는 작업을 충분히 정확하게 기술해야 함
  • 무엇이 완료됐는지 이해해야 함
  • 무엇이 언제 잘못됐고 그 이유가 무엇인지 이해해야 함
• Nuanced에서는 각 스레드가 하나의 채팅 대화였으며, 만들고 싶은 것을 논의하면 시스템이 모호한 부분과 사용자 판단이 필요한 결정을 드러냈음
  • 구현 전에 지속적으로 유지할 계획을 함께 만들고, 이후 생성 코드가 요구사항을 따르도록 구현하는 흐름이었음
  • 의도에서 구현, 검토, 검증까지 이어지는 전체 파이프라인을 지향했음
  • 단순한 코딩 앱보다는 지시를 전달하고 진행 상황을 파악하도록 돕는 인간 사고의 보조 장치가 목표였음

계획하기와 계획 문서는 다름

• 구현 전에 충분히 생각할 공간의 가치와, 그 생각을 대규모 구조화 문서로 보존하는 가치를 같은 것으로 취급한 것이 첫 번째 실패였음
• 초기 사용자들은 명세 문서에 예상보다 관심이 적었음. 생각을 정리하는 과정이 유용하다고 해서 그 결과를 방대한 문서로 남기는 것까지 유용한 것은 아니었음

모델 성능 향상이 줄인 지시의 필요성

• 모델은 맥락과 메모리를 활용해 큰 코드베이스를 이해하고, 저장소를 탐색하며 합리적인 가정을 세우는 데 능숙해졌음
• 충분히 숙고한 결과를 얻기 위해 사람이 명시적으로 지시해야 할 필요가 줄어듦
• 모델이 스스로 신뢰할 만하게 내릴 수 있는 결정이 하나 늘어날 때마다, 인터페이스가 사람에게 드러내야 할 결정은 하나 줄어듦
  • 이런 점에서 모델 능력 향상은 인간의 사고를 돕는 인터페이스 설계와도 경쟁하게 됨

긴 AI 생성 명세와 Spec Tour의 한계

• 명세는 중요한 결정과 유용해 보이는 맥락을 담았지만, 정보량 증가가 명료함 증가로 이어지지 않았음
• 긴 AI 생성 텍스트 특유의 전개와 과도한 구조화는 읽기를 어렵게 했음
• 명세를 없애는 대신 Spec Tour를 만들어 중요한 부분을 안내하려 했지만, 이는 화면에서 주의를 요구하는 텍스트와 복잡성을 한 겹 더 늘렸음
  • 명세를 쓸 만하게 만들기 위해 더 짧은 표현을 다시 생성해야 한다면, 처음부터 전체 문서가 왜 필요한지 의문이 남음

계획과 구현을 분리한 선형 흐름의 실패

• Nuanced의 작업 흐름은 채팅 → 질문에 답해 모호함 해소 → 명세 생성 → 명세 검토 → 명세 수정 → 승인 → 구현 → 코드 검토로 이어졌음
• 실제 사고는 문제 일부를 이해하고, 시도하고, 생성 결과에서 새로 배우고, 생각을 바꿔 다시 시도하는 식으로 진행됨
  • 각 단계에서 새로운 질문이 생기므로 계획과 구현은 서로 교차함
  • Nuanced의 인터페이스는 구현을 시작하려면 생각을 먼저 끝내도록 강요했음
  • 구현 이후 채팅 기반 추론으로 돌아가는 일은 작업 흐름을 거슬러 올라가는 것처럼 느껴졌음
• 과거 코딩 에이전트는 계획 → 승인 → 실행 흐름에서 이점을 얻었으며, 잘못된 방향으로 진행했을 때의 비용도 훨씬 컸음
• 현재 Codex에서는 계획과 실행의 경계가 흐려지고 있음
  • 에이전트는 시스템 이해뿐 아니라 자율 실행, 자체 테스트, 결과 검토 후 접근법 수정에도 능숙해졌음
  • 이에 따라 이해 → 실행 → 검토 → 명확화 → 조정 → 재실행의 반복이 가능해짐
• 이 반복 안에서도 많은 계획 활동이 일어나지만, 반드시 ‘계획’이라는 문서로 나타날 필요는 없음
  • 핵심 실수는 인간의 이해를 높이는 과정을 설계하는 대신 계획을 산출물로 만든 데 있었음

계획 모드와 구현 모드가 더한 인지 부담

• Nuanced는 계획 모드와 구현 모드 중 하나로 작업을 시작할 수 있었음
  • 계획 모드는 항상 명세를 생성했음
  • 구현 모드는 명세를 강제하지 않아, 명세가 필요하지 않은 작은 작업에 사용할 수 있었음
• 이 구분은 사용자가 작업에 계획이 필요한지 먼저 판단하고, 필요하면 버튼이나 단축키로 계획 모드를 켜도록 요구했음
• 이미 가진 맥락으로 AI가 판단해야 할 구분을 사용자가 기억하고 선택해야 했으며, 이는 인지 부담을 늘렸음
• 계획을 기본으로 강제하지 않고 필요할 때 채팅에서 진행하는 단순한 인터페이스가 오히려 더 나았음

수백 개 에이전트 시대에도 남는 이해의 과제

• 무엇을 만들지, 왜 중요한지, 어떤 결정을 내릴지 생각하는 일은 여전히 중요하지만, 방대한 AI 생성 텍스트가 이를 위한 적절한 인터페이스는 아님
• 채팅으로 결정을 다루는 방식은 더 직관적이지만, 시스템이 변할 때 사람의 이해도 함께 최신 상태로 유지하는 문제는 아직 해결되지 않았음
• 에이전트가 5개에서 수백 개로 늘어나면 모든 대화를 읽고 코드 변경마다 설명을 요청하는 방식으로는 따라갈 수 없음
  • 에이전트는 사람의 주의가 가장 큰 효과를 낼 최소한의 지점을 찾아야 함
  • 그 주의가 유용한 판단으로 이어질 만큼의 맥락도 제공해야 함
• 사람이 시스템을 이해하고 복잡한 정보 계층을 탐색하며 강력한 도구를 사용하는 문제는 지속됨
• 기술과 함께 인터페이스는 바뀌지만, 복잡성을 이해할 수 있게 만들어야 한다는 필요는 사라지지 않음