AI 코딩 에이전트, '더 큰 도구'보다 미니멀리즘이 이기는 이유

AI가 코드 작성 비용을 크게 낮추면서, 많은 기업이 더 나은 성능을 좇아 도구를 점점 키우는 방향으로 움직이고 있다. 프롬프트를 늘리고, 오케스트레이션 계층을 더하고, 추상화를 쌓는 식이다. 그러나 이런 접근은 도구 자체를 본질적으로 더 비싸게 만든다. 코딩 하네스(harness) 'Pi'는 정반대 노선을 택했다. 기본 제공 도구는 단 4개, 시스템 프롬프트와 도구 정의를 합쳐 1,000토큰 미만이다. 대부분의 작업은 기본기만으로 처리할 수 있고, 그 이상이 필요하면 직접 만들어 붙이라는 설계 철학이다.

흥미로운 점은 이 미니멀리즘이 단지 깔끔함에 그치지 않고 비용과 성능 양쪽에서 유리하게 작동한다는 정황이 쌓이고 있다는 것이다. 별도 확장을 얹기 전의 '기본 Pi'만으로도 업계 최상위권 결과가 나온다는 사용자 보고가 이어진다. 그 근거로 자주 인용되는 것이 Databricks와 Shopify 사례다.

하네스가 비용과 품질을 가른다

Databricks는 '수백만 줄 규모 코드베이스에서의 코딩 에이전트 벤치마킹'이라는 연구를 공개했다. 외부 벤치마크가 이미 포화 상태라 편향이 우려된다는 이유로, 자사 엔지니어들이 실제로 반복 수행하는 작업을 기반으로 자체 벤치마크를 만들었다. 결론은 이렇다. "모델을 호출하는 하네스가 비용과 품질에 극적인 영향을 미친다"는 것, 그리고 "많은 경우 Pi 같은 단순한 하네스가 자사 워크로드에서 가장 좋은 성능을 냈다"는 것이다. 특히 Opus 4.8을 xhigh 설정으로 결합했을 때 Pi는 전체 통과율에서 가장 높았고, 비용은 Claude Code와 Codex보다 크게 낮았다.

이 연구가 실무자에게 유용한 이유는 모델과 하네스를 분리해서 봤다는 데 있다. 같은 모델을 같은 사고 강도로 돌려도 어떤 하네스를 거치느냐에 따라 작업당 비용이 경우에 따라 2배 이상 벌어졌는데, 품질은 동일했다. Databricks는 Pi가 턴당 약 3배 적은 컨텍스트를 보냈고, 더 좁은 작업 집합을 유지하며 더 적은 실행 횟수로 과제를 끝냈다고 설명한다. Pi 진영은 이를 '컨텍스트 규율(context discipline)'이라 부른다.

토큰 단가가 아니라 엔지니어링 경제성

여기서 얻을 실무적 시사점은 토큰 단가만 보고 판단해서는 안 된다는 것이다. 비용은 단가가 아니라 과제를 끝내기까지의 전체 왕복 비용으로 결정된다. 실제로 복잡한 워크플로를 값싼 모델에 돌렸을 때 오히려 더 비싸지는 역전이 관찰된다. 예컨대 코드 실행이 얽힌 작업에서 Haiku 4.5는 성공까지 더 많은 턴을 요구해, Sonnet 4.6보다 총비용이 높아지는 경우가 있었다. 이제 같은 현상이 하네스 층위에서도 나타난다. 더 강력하고 단가가 비싼 모델이라도 효율적인 하네스와 결합하면 그 반대 조합보다 저렴해질 수 있다.

미니멀리즘이 곧 경직성을 뜻하지는 않는다. Pi는 확장성과 자기 편집을 전제로 설계됐다는 점을 강조한다. Shopify 엔지니어링의 David Cortés는 "Pi, Autoresearch용 확장을 만들어줘"라고 요청하는 것만으로 pi-autoresearch를 확장 형태로 구축한 과정을 소개했다. Pi가 자신의 확장 문서를 읽고 거기서부터 새 워크플로를 만들어 나가는 방식이다.

도구를 파는 대신, 만들 능력을 준다

Autoresearch는 코딩 에이전트를 이용한 최적화용 자율 루프다. 변경을 요청하면 실험을 돌려 무엇이 효과가 있고 무엇이 회귀를 유발하는지 찾아내며, 목표가 측정 가능한 한 회귀를 걸러내고 스스로 개선을 이어간다. Shopify는 이 확장으로 단위 테스트가 300배 빨라지거나, React 컴포넌트 마운트가 20% 빨라지고, 여러 프로젝트의 빌드 시간이 단축되며, pnpm 성능까지 개선된 사례를 보고했다. 핵심은 Pi가 이런 도구들을 기본 탑재하지 않는다는 점이다. 벤더가 모든 워크플로를 미리 안다고 가정해 온갖 도구를 얹는 대신, 사용자가 자기 워크플로를 가장 잘 안다고 보고 그것을 손수 만들 수 있는 확장성을 넘긴다.

약 1년 전만 해도 모델이 특정 하네스를 중심으로 만들어졌다는 점에서 네이티브 하네스가 구조적 우위를 가진다는 주장이 가능했다. 그러나 이 논리는 약해지고 있다. 프런티어 모델은 이제 터미널형 코딩 환경을 이해하고 그 안에서 행동하는 데 대체로 능숙하다. Anthropic이 최근 Claude Code의 시스템 프롬프트를 80% 줄인 것도 같은 흐름을 보여준다. 결국 질문의 초점은 '얼마나 네이티브한가'에서 '얼마나 중복 없이 컨텍스트를 다루고 깔끔한 원시 도구로 동작하는가'로 옮겨가고 있다.

이 관점은 빠르게 발전 중인 로컬 모델에서 특히 중요해진다. 로컬 모델은 대개 컨텍스트 창이 작고 프리필에 시간이 오래 걸리므로, 안정적인 프롬프트 접두부를 유지하는 것이 성능에 직결된다. 사용자가 명시적으로 요청하지 않는 한 컨텍스트를 바꾸지 않는 컨텍스트 규율은, 최소한의 기본 시스템 프롬프트·도구 집합과 맞물려 재프리필로 인한 지연을 줄인다. 다만 이 글의 근거는 Databricks와 Shopify 두 사례에 크게 기대고 있고 Pi를 옹호하는 서술이라는 점은 감안할 필요가 있다. 그럼에도 '복잡성은 값어치를 증명할 때만 더한다'는 원칙, 그리고 하네스 층위의 컨텍스트 낭비를 비용 문제로 바라보는 시각은 자체 에이전트 인프라를 고민하는 팀이 참고할 만하다.