코딩 에이전트의 계획(Plan) 모드는 죽었다?

GeekNews에 소개된 Ayman Nadeem의 글 Plan Mode Is Dead(계획 모드는 죽었다)를 읽었습니다. 저자가 만들던 코딩 앱 Nuanced의 회고로, 모델의 추론 능력과 판단력이 좋아지면서 구현 방법을 미리 상세히 지시하는 계획 모드의 필요성이 줄고 있다는 내용입니다.

원문의 요지를 제 나름대로 정리하면 다음과 같습니다.

모델이 저장소를 스스로 탐색하고 합리적으로 가정하는 능력이 좋아져, 사람이 구현 방법을 미리 세세하게 지시해야 할 일이 줄었다.
코드를 짜기 전에 생각을 정리하는 건 여전히 가치 있지만, 그 생각을 긴 계획 문서로 남긴다고 이해가 깊어지지는 않는다.
계획 → 승인 → 구현의 선형 절차보다, 조금 이해하고 실행해 본 뒤 결과를 보고 방향을 고치는 반복이 실제 개발 방식에 가깝다.
저자가 Nuanced에 계획 모드와 명세 편집 기능을 넣어 봤지만, 사용자들은 모드를 고르고 문서를 관리하기보다 대화로 풀어 가는 쪽을 더 편하게 여겼다.
에이전트가 많아질수록 필요한 건 더 많은 문서가 아니라, 사람이 판단해야 할 지점과 그 판단에 필요한 맥락이다.

저는 일부 동의하지만, 동의하지 않는 부분이 더 많았습니다.

먼저 동의하는 부분입니다. 모델이 좋아지면서 계획 모드로 세운 계획에서 지적하고 고칠 부분이 크게 줄어든 건 저도 체감하고 있습니다. 코드베이스를 충분히 이해하고 있고 통제할 수 있는 작은 변경이라면, 계획 모드를 건너뛰고 바로 구현을 맡겨도 무방하다는 데에는 전적으로 동의합니다.

원문의 문제의식에도 공감합니다. 저자는 “에이전트가 사람이 검토하는 속도보다 빠르게 코드를 바꿀 때, 사람이 시스템을 어떻게 계속 이해할 것인가”라는 질문에서 출발했고, 저도 같은 고민을 하고 있습니다. 다만 해법이 다릅니다. 저자는 계획을 별도의 모드와 문서로 떼어 내지 말고 대화와 반복 속에 녹이자고 하는데, 저는 적어도 규모가 있는 작업이라면 구현 전에 계획을 명세로 정리하고 검토하는 단계를 따로 두는 편이 낫다고 봅니다.

명세 없이 결과물만 받아 드는 방식을 블랙박스 테스트에서 이름을 빌려 ’블랙박스 코딩’이라고 부르고 싶습니다. 내부 설계를 모르는 채로 결과만 확인하는 코딩이라는 뜻입니다. 빠르게 만들어 보는 게 목적이라면 충분히 쓸 만한 방식이지만, 소프트웨어 개발을 업으로 삼고 코드를 오래 유지보수해야 하는 입장이라면 권하고 싶지 않습니다. 이유는 네 가지입니다.

1. 코드 이해도와 통제력이 떨어집니다.

구현 후에 꼼꼼히 검수한다면 얘기가 다를 수 있습니다. 하지만 계획 단계를 건너뛰는 이유가 대개 시간 단축과 번거로움 때문이라면, 검수도 함께 느슨해질 가능성이 크다고 봅니다. 모델이 아무리 좋은 코드를 작성했더라도 구현된 코드의 아키텍처와 컨벤션을 이해하지 못하면 장기적으로 기술 부채가 됩니다. 이해하지 못하는 코드 조각이 늘어날수록 AI 의존도가 높아지고, 결국 작은 변경까지 전적으로 AI에 맡기게 될 수 있습니다.

“모르면 에이전트에게 설명해 달라고 하면 된다”는 반론도 있을 텐데요. 이미 만들어진 코드를 설명으로 이해하는 것과, 설계 결정 단계에 직접 참여하며 이해하는 것은 깊이가 다르다고 생각합니다. 계획 단계는 AI가 어떤 가정을 세우는지, 제가 미처 지시하지 못한 부분을 어떻게 채우려 하는지 구현 전에 확인할 수 있는 거의 유일한 지점입니다.

2. 병렬 작업에서는 이 문제가 더 커집니다.

명확한 하네스 없이 여러 에이전트를 병렬로 돌리면 기술 부채가 훨씬 빠르게 쌓이고, 이를 갚느라 유지보수에 많은 시간을 쓰게 됩니다. 저는 병렬 작업을 하더라도 코드 구현은 한 세션에서만 진행하고, 남는 시간은 코드 검수와 계획 검수에 썼습니다. 여러 작업을 동시에 진행해 보니 능률이 떨어져 전체 작업 시간이 오히려 늘었기 때문입니다. 과제 전환(task switching) 연구에서도 작업을 번갈아 할 때마다 전환 비용이 생긴다는 결과가 반복해서 나오는데(Rubinstein, Meyer & Evans, 2001; Monsell, 2003), 제 경험도 이와 비슷했습니다. 특히 브랜치 분리가 명확하지 않을 때는 변경 사항이 한데 섞여 검수하기가 매우 어려웠습니다.

원문 저자도 여러 에이전트를 병렬로 돌리는 앱에서는 작업에 집중하고 결과를 검증하기가 더 어려웠다고 적고 있습니다. 문제 인식은 같은 셈입니다.

3. 시간을 아끼려다 오히려 더 쓰게 될 수 있습니다.

모델에게 전적으로 위임하려면 탐색부터 구현까지 전 과정에 높은 사고 수준의 모델을 쓰게 되는데, 이는 실행 한 번에 드는 추론과 구현 시간을 늘립니다. 반면 계획을 먼저 세워 두면 무거운 모델은 계획 단계에만 쓰고, 구현은 더 빠른 설정으로 돌릴 수 있습니다. 또 결과물이 마음에 들지 않으면 다시 수정을 지시하게 되는데, 잘못된 가정 위에서 구현이 끝까지 진행됐다면 이를 되돌리는 비용은 구현 전에 계획을 검토하는 비용보다 큽니다. 1번에서 말한 것처럼 코드 이해도가 낮다면 작은 수정조차 AI를 거쳐야 하고요. 제 경험상 모델을 온전히 믿지 못하는 경우에도 결국 검수 시간이 늘어나 전체 작업 시간이 길어지는 경향이 있었습니다.

4. 계획 문서는 인수인계 자료가 됩니다.

원문은 방대한 계획 문서가 이해를 높이는 데 도움이 되지 않았다고 말합니다. 길고 읽기 힘든 AI 생성 문서라는 지적에는 공감하지만, 계획 문서의 가치가 그것만은 아니라고 봅니다. 정리된 문서가 없으면 에이전트나 세션이 바뀔 때 컨텍스트를 넘기기 어렵고, 사람 사이의 인수인계에서도 말로만 전달하면 빠지는 내용이 생기기 마련입니다. 잘 정리된 문서나 코드로 소통할 수 있다면 큰 힘이 됩니다. 문서가 길 필요는 없습니다. 무엇을 왜 그렇게 결정했는지만 남아 있어도 다음 사람, 다음 에이전트가 같은 출발점에서 시작할 수 있습니다.

결론

결론은 “모델이 발전했어도, 구현 전에 계획하고 명세하는 과정은 대부분의 경우 여전히 필요하다”입니다.

핵심은 계획 문서를 만드는 것 자체가 아니라, 사람이 미처 지시하지 못한 부분에서 AI가 어떤 판단을 내리는지 구현 전에 살펴보고, 그 과정에서 코드 이해도와 장기적인 유지보수 가능성을 지키는 것이라고 생각합니다. 이 점에서 원문 저자와 제가 바라보는 목표는 크게 다르지 않고, 그 목표에 이르는 방법에서 생각이 갈린다고 봅니다.

이 과정을 도와주는 도구로는 Matt Pocock의 /grill-me 스킬을 추천합니다. 구현에 들어가기 전에 에이전트가 계획을 한 번에 하나씩 질문으로 캐묻고, 합의가 될 때까지 코드를 쓰지 않도록 해 줍니다.

마지막으로 큰 작업은 검수하기 쉬운 작은 단위로 쪼개는 것도 중요합니다.