코딩 에이전트가 코드를 무한정 만들어내는 세상이 왔는데, 왜 소프트웨어를 만드는 일은 여전히 어려울까요?

pandas 창시자이자 현재 Posit에서 일하는 Wes McKinney가 직접 경험한 에이전트 개발의 한계와 가능성을 정리한 에세이를 발표했습니다. 그는 매달 Claude, Codex, Gemini를 합쳐 100억 토큰 이상을 사용하는 헤비유저이기도 합니다. 에이전트 덕분에 Go 같은 낯선 언어로도 코드를 척척 만들어내지만, 정작 소프트웨어의 핵심적인 어려움은 달라진 게 없다는 게 그의 결론입니다.

출처: The Mythical Agent-Month – Wes McKinney

에이전트가 잘 하는 것과 못 하는 것

McKinney는 1986년 Fred Brooks의 에세이 “No Silver Bullet”에서 제시한 두 가지 복잡성 개념을 빌려옵니다. 우발적 복잡성(accidental complexity)은 도구나 언어, 설정 같은 부수적인 어려움이고, 본질적 복잡성(essential complexity)은 문제 자체가 갖는 근본적인 어려움입니다.

코딩 에이전트는 우발적 복잡성을 처리하는 데 탁월합니다. 코드 리팩토링, 테스트 작성, 반복 구현처럼 패턴이 있는 작업은 에이전트가 사람보다 훨씬 빠르게 해냅니다. 문제는 에이전트가 이 둘을 구분하지 못한다는 겁니다. 본질적으로 어려운 설계 문제 앞에서도 에이전트는 자신 있게 코드를 쏟아냅니다. 그리고 그 과정에서 불필요한 방어 코드와 과도한 추상화를 덧붙이며 새로운 우발적 복잡성을 만들어냅니다.

McKinney가 직접 만들고 있는 프로젝트들은 이미 10만 줄을 넘어서고 있는데, 그 시점부터 에이전트가 자신이 만든 코드에 스스로 막히는 현상이 나타나기 시작했다고 합니다. 코드베이스가 커질수록 에이전트가 전체 맥락을 파악하지 못하고, 이전 에이전트 세션이 만든 코드를 헤쳐나가며 새 기능을 추가하는 일이 점점 어려워집니다.

‘에이전트 스코프 크리프’라는 새 문제

코드 생성 비용이 사실상 0에 가까워지면서, 이전에는 시간이나 비용 때문에 포기했던 기능도 쉽게 만들 수 있게 됐습니다. 에이전트에게 “이것도 추가해줘”를 반복하는 유혹은 압도적입니다. 하지만 만드는 건 쉬워도, 그 기능을 유지하고 테스트하고 디버깅하는 비용은 여전히 남습니다. 오히려 에이전트가 만든 코드는 누가 그 설계 결정을 책임지는지 불명확하다는 문제까지 더해집니다.

오픈소스 생태계에서도 같은 현상이 나타나고 있습니다. 직접 코드를 작성하거나 완전히 읽지 않은 수천 줄짜리 PR이 쏟아지면서, 프로젝트 관리자들이 과부하에 시달리고 있습니다.

설계 감각이 희소 자원이 되다

McKinney의 결론은 역설적입니다. 코딩 에이전트 시대에 가장 중요해진 것은 코딩 실력이 아니라 무엇을 만들지 결정하는 능력이라는 겁니다. 1975년에 나온 The Mythical Man-Month에서 Fred Brooks가 말한 것처럼, 뛰어난 소프트웨어는 결국 “한 사람이 설계한 것처럼 느껴지는” 개념적 일관성에서 나옵니다. 에이전트는 그 일관성을 유지하는 역할을 하지 못합니다.

에이전트 시대에 두각을 나타낼 개발자는 가장 많은 토큰을 쓰는 사람이 아니라, 프로젝트의 전체 구조를 머릿속에 담아두고, 기능을 추가할 때와 거절할 때를 아는 사람이라는 게 그의 주장입니다.

50년 전의 소프트웨어 공학 원칙이 AI 에이전트 시대에도 그대로 적용된다는 주장의 구체적인 근거와, 에이전트 오케스트레이션의 n(n-1)/2 조율 문제에 대해서는 원문에서 더 깊이 다루고 있습니다.