Pi의 미니멀리즘이 곧 경쟁력입니다
TMTAI 덕분에 코드를 만드는 비용이 저렴해지면서, 많은 회사가 더 나은 성능을 좇아 점점 더 큰 도구를 만들고 있습니다. 프롬프트는 더 길어지고, 오케스트레이션과 레이어가 늘어나고, 복잡도도 커집니다. 그만큼 이런 도구는 쓰는 데 드는 비용도 본질적으로 비싸질 수밖에 없습니다. Pi는 정반대의 길을 택했습니다.
Pi는 의도적으로 미니멀리즘을 선택한 코딩 하네스입니다. 기본 제공 도구는 단 4개뿐이고, 시스템 프롬프트와 도구 정의를 다 합쳐도 1,000토큰이 되지 않습니다. 대부분의 작업은 기본기만으로 해낼 수 있고, 더 필요한 것이 있으면 직접 만들면 된다는 발상입니다.
Pi의 설계가 단지 더 깔끔하기만 한 것이 아니라 더 저렴하고 성능도 더 좋다는 증거가 점점 쌓이고 있습니다. 사용자들은 각자의 워크플로와 필요에 맞춘 확장을 붙이기도 전에, 순정 상태의 Pi만으로 업계 최고 수준의 결과가 나온다는 사실을 확인하고 있습니다. Databricks와 Shopify의 사례 연구에서 보듯, Pi는 두 회사 모두에서 이상적인 결과를 만들어냈습니다.
사례 연구
Databricks 연구: 과제당 비용
Databricks는 최근 "Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase"라는 연구 결과를 공개했습니다. 실제 코딩 과제에서 어떤 코딩 에이전트가 가장 좋은 성능을 내는지, 그리고 과제 성능이 가격에 따라 어떻게 달라지는지를 알아보는 것이 연구의 목표였습니다.
이미 포화 상태에 이른 외부 벤치마크의 편향을 피하기 위해, Databricks는 소속 엔지니어들이 일상적으로 수행하는 과제를 바탕으로 자체 벤치마크를 만들었습니다. 결과는 우리가 예상한 그대로였지만, 업계의 많은 이들에게는 뜻밖이었을지도 모릅니다. Databricks의 표현을 빌리면 "…모델을 어떤 하네스에서 호출하느냐가 비용과 품질에 극적인 영향을 미친다"고 했고, "많은 경우 Pi처럼 단순한 하네스가 우리 워크로드에서 가장 좋은 성능을 냈다"고 밝혔습니다.
그림 출처: Databricks.
Opus 4.8, xhigh와 조합했을 때 Pi는 전체 통과율이 가장 높았고, 비용은 Claude Code와 Codex 어느 쪽보다도 훨씬 낮았습니다.
미니멀한 하네스, 측정 가능한 효과
Pi가 돋보이는 것은, 지시 계층(instruction hierarchy) 속에 묻혀 버리는 온갖 기본값과 지시문으로 모델을 감싸려 들지 않기 때문입니다. Pi는 모델의 앞길을 막지 않고 비켜서 있고, 팀은 각자의 워크플로에 실제로 필요한 것만 얹으면 됩니다.
Databricks 연구가 통찰력 있는 지점은 모델과 하네스를 분리해서 봤다는 데 있습니다.
같은 모델을 같은 사고 강도(thinking effort)로 서로 다른 하네스에서 돌렸더니 "품질은 그대로인데 과제당 비용은 크게 달랐다(어떤 경우에는 2배 이상)"고 보고했습니다. 우리는 이것을 Pi의 "컨텍스트 절제(context discipline)"라고 부릅니다. "Pi는 턴마다 보내는 컨텍스트가 3분의 1 수준이었다. 컨텍스트를 더 잘 관리해 작업 셋을 더 좁게 유지했고, 더 적은 실행 횟수로 과제를 끝냈다."
토큰당 가격만이 아니라 엔드투엔드 엔지니어링 경제성을 함께 따져야 한다는 데 우리도 동의합니다. 이것은 모델 수준에서도 마찬가지입니다. 예를 들어 복잡한 워크플로를 Haiku 4.5로 돌리면 Sonnet 4.6보다 오히려 비싸지는 경우가 많았는데, 특히 코드 실행이 끼어 있을 때 그랬습니다. 에이전트가 과제를 성공적으로 끝내기까지 더 많은 턴이 필요했기 때문입니다.
이제 같은 현상이 하네스 수준에서도 보입니다. 더 강력하고 비싼 모델이라도 성능 좋은 하네스와 함께라면, 그 반대 조합보다 오히려 저렴할 수 있습니다.
Shopify가 만든 Pi Autoresearch: 비대함을 이기는 확장성
미니멀리즘은 Pi의 핵심 철학 중 하나입니다. 이 철학이 통하는 것은 미니멀하다고 해서 유연성이 없는 것이 아니기 때문입니다. 오히려 Pi는 확장성과 자기 수정 가능성(self-editability)을 위해 만들어진, 널리 쓰이는 최초의 에이전트 인프라입니다.
Pi의 설계를 외부에서 입증해 준 또 하나의 인상적인 사례는 Shopify입니다. Shopify Engineering의 이 글에서 David Cortés는 pi-autoresearch를 Pi 확장으로 직접 만든 과정을 소개하는데, 그저 "Pi, Autoresearch용 확장을 만들어 줘…"라고 요청한 것이 전부였습니다. Pi는 자신의 확장 문서를 읽고 거기서부터 새 워크플로를 만들어 나갑니다.
Autoresearch는 코딩 에이전트로 최적화를 수행하는 자율 루프입니다. 변경을 요청하면 실험을 돌려서 무엇이 효과가 있고 무엇이 회귀(regression)를 일으키는지 알아냅니다. 목표를 측정할 수만 있다면, 회귀를 일으키는 변경은 버리고 계속 스스로 개선해 나갈 수 있습니다.
Shopify를 비롯한 여러 곳에서 Autoresearch 확장은 금세 만만치 않은 사내 생산성 도구로 자리 잡았습니다. Shopify가 보고한 사례를 보면 단위 테스트가 "300배 빨라지고", React 컴포넌트 마운트가 "20% 빨라졌으며", 여러 프로젝트에서 빌드 시간이 줄었고, 심지어 pnpm 성능까지 개선됐습니다.
이미지 출처: Shopify의 pi-autoresearch GitHub 저장소.
여기서 중요한 점은, Pi가 이런 도구를 하나도 기본으로 제공하지 않는다는 것입니다. 대신 이런 도구를 직접 만드는 일을 어이없을 만큼 간단하게 만들어 줍니다. 벤더가 사용자의 워크플로를 다 안다고 전제하고 세상의 온갖 도구를 몽땅 담아 내놓는 대신, Pi는 사용자 자신이 가장 잘 안다고 전제하고, 자기만의 워크플로를 빚어낼 수 있는 확장성을 선물합니다.
왜 지금은 미니멀이 이기는가
1년쯤 전만 해도, 모델 자체가 네이티브 하네스를 중심으로 만들어졌으니 네이티브 하네스가 다른 모든 하네스보다 구조적으로 유리하다는 주장이 성립할 수 있었습니다. 하지만 이 주장은 점점 힘을 잃고 있습니다.
프런티어 모델들은 이제 터미널(또는 터미널 스타일) 코딩 환경을 이해하고 그 안에서 행동하는 데 대체로 매우 능숙합니다. Anthropic이 최근 Claude Code의 시스템 프롬프트를 80% 줄인 것이 이를 분명하게 보여 줍니다. 그래서 이제 관건은 하네스가 얼마나 네이티브인가가 아니라, 중복을 피하고 깔끔한 기본 요소(primitive)로 동작하도록 컨텍스트를 얼마나 잘 다루는가로 옮겨 가고 있습니다. 모델에게 필요한 것은 환경과 맞닿는 깔끔한 인터페이스, 그리고 컨텍스트를 낭비하지 않는 하네스입니다.
Pi가 제공하는 것이 바로 이것입니다. 프롬프트 오버헤드와 반복되는 컨텍스트는 줄고, 실행 비용은 싸지고, 불필요한 추상화는 적어집니다. 확장이 가능하기 때문에 힘을 잃는 것이 아니라 선택권을 얻습니다. 복잡성은 "밥값을 할 때"에만 더하면 됩니다.
로컬 모델도 빠르게 발전하고 있는데, Earendil에서는 로컬 모델의 가능성을 매우 크게 보고 있습니다. 여기서 Pi의 컨텍스트 절제가 특히 큰 자산이 됩니다. 로컬 모델은 대개 컨텍스트 윈도가 작고 프리필(prefill)에 오랜 시간이 걸릴 수 있어서, 프롬프트 앞부분(prefix)을 안정적으로 유지하는 것이 중요합니다. 컨텍스트 절제란 사용자가 명시적으로 요청하지 않는 한 컨텍스트를 바꾸지 않는다는 뜻이고, 그 덕분에 몇 분씩 걸리는 재프리필을 피할 수 있습니다. 미니멀한 기본 시스템 프롬프트와 도구 셋이 여기에 더해지면, Pi는 로컬 모델에 이상적인 하네스가 됩니다.
Pi는 이 모든 것을 해낼 수 있음을 증명해 가고 있습니다. 더 저렴하면서, 미니멀하면서, 더 뛰어난 성능을 내는 것 말입니다.