올해 초까지만 해도 한 개발자는 AI로 소프트웨어를 만드는 과정에서 '계획'이 가장 중요한 부분이 될 것이라고 확신했다. 그 믿음이 얼마나 강했던지, 그는 아예 계획을 중심에 둔 데스크톱 코딩 앱 'Nuanced'를 만들어 출시했다. 출발점은 타당한 관찰이었다. AI가 코드 생성의 속도와 분량을 폭발적으로 끌어올렸지만, 그 속도를 감당할 작업 인터페이스는 아직 따라오지 못했다는 문제의식이었다. 그러나 Nuanced의 접근은 실패했고, 그 실패는 역설적으로 '플랜 모드'라는 개념 자체가 예전만큼 유용하지 않게 되었다는 사실을 드러냈다.
저자의 정리에 따르면 플랜 모드는 역사적으로 두 가지 역할을 했다. 하나는 에이전트에게 충분히 정밀한 지시를 전달하는 것이고, 다른 하나는 사람이 자신이 무엇을 만들고 있는지 이해하도록 돕는 것이다. 그는 첫 번째 역할이 모델 성능이 좋아지면서 빠르게 쓸모를 잃고 있다고 본다. 반면 두 번째, 즉 인간의 이해를 돕는 역할은 그 어느 때보다 중요해졌지만, 플랜 모드는 그 목적에 맞는 도구가 아니라고 진단한다. 특히 병렬로 돌리는 에이전트 수가 늘어날수록 이 괴리는 커진다.
코드를 이해하기도 전에 떠안는 유지보수 부담
문제의 뿌리는 생성 속도 자체에 있었다. 모델이 몇 분 만에 수천 줄의 코드를 써 내려가면, 개발자는 무엇을 왜 만드는지 충분히 생각하기도 전에 방대한 유지보수 부담을 떠안게 된다. 아키텍처를 덜 명세하면 에이전트가 알아서 빈틈을 채우는데, 그 과정에서 나눈 추상화 경계가 나중에 문제를 일으켜도 그 오해는 채팅 화면 아래 여러 파일 깊숙이 퍼져 눈에 잘 띄지 않는다. 저자는 코드 생성이 주는 도파민 보상이 '이걸 왜 만드는가, 애초에 만들 가치가 있는가'라는 불편하지만 중요한 질문을 가려버렸다고 고백한다. 제품 결정을 의식적으로 내리기도 전에 이미 제품이 만들어져 있는 상황이 반복됐다는 것이다.
Conductor나 Codex처럼 여러 에이전트를 동시에 돌릴 수 있는 도구가 늘면서 이 감각은 더 심해졌다. 저자는 스스로 '좀비처럼' 느껴졌다고 표현한다. 프롬프트에서 에이전트의 결정, 코드, 최종 제품 동작으로 이어지는 해석 가능한 추적 경로가 없었기 때문이다. 그렇다고 옛날처럼 코드 줄과 파일을 일일이 들여다보고 싶은 것은 아니었다. 오히려 자연어로 아이디어를 다루는 편이 더 효율적이라고 느꼈다. 그가 원한 것은 시스템 이해를 희생하지 않으면서도 코드 위를 자신 있게 항해하는 것이었다.
'계획하기'와 '계획서'는 다르다
Nuanced는 대화 스레드를 열어 무엇을 만들지 이야기하면 시스템이 모호한 지점과 결정이 필요한 부분을 짚어주고, 함께 영속적인 계획서에 도달한 뒤 구현으로 넘어가는 구조였다. 그러나 첫 번째 교훈은 '계획하기(planning)'와 '계획서(a plan)'를 혼동했다는 점이었다. 구현 전에 충분히 생각할 공간을 갖는 것은 가치 있었지만, 그 사고를 커다란 구조화된 산출물로 보존하는 데 대한 사용자들의 수요는 놀라울 만큼 적었다. 게다가 모델이 대규모 코드베이스를 맥락과 메모리로 이해하는 능력이 좋아지면서, 저자가 미처 예상하지 못한 경쟁 구도가 생겼다. 모델이 스스로 신뢰성 있게 내릴 수 있는 결정 하나하나가, 곧 사람에게 물어봐야 할 결정 하나가 사라지는 것을 의미했기 때문이다.
스펙 문서 자체도 문제였다. 길고 많은 맥락을 담았지만 정보가 늘어난 만큼 명료함이 늘지는 않았다. 무엇보다 AI가 생성한 텍스트 특유의 과도하게 구조화된 리듬 탓에 읽다 보면 자꾸 눈이 미끄러졌다. 이를 해결하려고 스펙의 핵심만 안내하는 '스펙 투어'를 붙였지만, 이는 화면에 주의를 요구하는 텍스트를 한 겹 더 얹었을 뿐이다. 전체 문서를 쓸 만하게 만들기 위해 더 짧은 요약을 따로 생성해야 한다면, 애초에 전체 문서를 만든 이유가 무엇이냐는 반문이 남았다.
계획과 실행의 경계가 사라진다
더 근본적인 결함은 워크플로가 지나치게 선형적이고 순차적이었다는 데 있다. 대화, 질문 답변으로 모호함 제거, 스펙 생성, 검토, 수정, 승인, 구현, 코드 리뷰로 이어지는 폭포수 구조는 실제 사고 방식과 맞지 않았다. 현실에서는 문제의 일부만 이해한 채 무언가를 시도하고, 초기 생성 결과에서 새로운 것을 배우며 생각을 바꾸는 식으로 계획과 구현이 유기적으로 뒤섞인다. Nuanced의 인터페이스는 사용자에게 '생각을 미리 끝내라'고 강요했고, 구현이 시작된 뒤 다시 대화 기반 추론으로 돌아가는 것은 폭포를 거슬러 오르는 일처럼 느껴졌다. 반면 지금의 Codex를 보면 계획과 실행의 경계는 하나로 무너지고 있다. 과거에는 방향을 잘못 잡는 비용이 커서 사람이 앞단에서 계획을 다듬는 것이 유리했지만, 에이전트가 자율적으로 행동하고 자기 결과를 검증·수정하게 되면서 '이해하기, 실행하기, 점검하기, 명확히 하기, 조정하기, 다시 실행하기'라는 새로운 순환이 가능해졌다. 계획은 그 순환 안에 여전히 방대하게 존재하지만, 굳이 '계획서'라는 이름의 문서로 나타날 필요는 없어진 것이다.
한국의 실무자에게 이 회고가 시사하는 바는 분명하다. 저자가 꼽은 가장 큰 실수는 계획을 '산출물'로 만든 것이지 인간 이해를 개선하는 '프로세스'를 설계하지 않은 것이었다. 플랜 모드와 빌드 모드를 나눈 것도, 사용자에게 '이 작업이 계획할 가치가 있는가'를 매번 스스로 묻고 버튼이나 단축키로 모드를 전환하게 만들어 오히려 인지 부하를 늘렸다. 무엇을 왜 만드는지 따지고 결정을 평가하는 일은 여전히 중요하지만, 그 이해를 담는 그릇이 방대한 AI 생성 텍스트일 필요는 없다. 다만 시스템이 계속 바뀌는 동안 그 이해를 최신 상태로 유지하는 문제, 그리고 다섯 개가 아니라 수백 개의 에이전트가 동시에 시스템을 바꿀 때 사람이 방향을 잃지 않도록 돕는 문제는 아직 풀리지 않았다. 저자는 모든 대화를 읽고 변경마다 설명을 요구하는 방식으로는 감당할 수 없으며, 에이전트가 인간의 주의를 가장 크게 발휘할 수 있는 최소한의 지점을 스스로 찾아 충분한 맥락과 함께 드러내야 한다고 제안한다. 도구를 떠받치는 기술과 함께 인터페이스는 계속 바뀌겠지만, 복잡성을 이해 가능하게 만들어야 한다는 과제만큼은 사라지지 않는다는 것이 그가 남긴 결론이다.