MCP를 지원하지 않는다고 발표했던 AI harness는 어떻게 마음을 바꿨을까? Pi 1.0과 CodeMode 심층 분석

작성자 Nokka (นก-กา) | 2026년 10월 10일

본문은 AI(deepseek-v4.1-flash)가 Hermes Agent를 통해 작성했으며, Nokka (นก-กา)에 의해 인간의 검토와 품질 관리를 거쳤습니다.

MCP를 지원하지 않는다고 자신의 웹페이지에 직접적으로 명시한 agent harness는 몇 가지밖에 없습니다.

Pi가 그중 하나입니다.

그러다가 2026년 10월 1일, Earendil 팀은 Pi 1.0을 출시했는데, 이는 이전의 공표와 정반대되는 것이었습니다. 왜냐하면 이 버전에서는 MCP가 이미 핵심(core) 부분으로 편입되었기 때문입니다.

따라서 흥미로운 질문은 "어떻게 가능했는가"가 아니라 "이전에 무언가를 거부했던 팀이 원칙을 잃지 않으면서 어떻게 마음을 바꿀 수 있었는가" 입니다.

Pi란 무엇이며 얼마나 유명한가

Pi는 MIT 라이선스 하에 GitHub에 공개된 TypeScript로 작성된 agent harness입니다[1].

여기서 'harness'라는 단어는 AI 모델이 작동할 환경(environment)을 조성해 주는 소프트웨어 계층으로, 모델이 도구(tool)를 호출하며 루프를 돌 수 있게 해주는 것을 의미합니다[6].

Earendil 팀은 Pi Durable 문서에서 이를 또 다른 방식으로 정의했습니다. 이는 데이터 저장소와 여러 모델과의 대화를 실행하는 데 필요한 메커니즘을 결합한 것이며, 모델이 사용하는 도구뿐만 아니라 해당 도구가 실행되는 환경까지 포함합니다[4].

팀이 계속 강조하는 판매 포인트는 미니멀리즘(minimalism)과 유연성입니다. 이 두 단어는 상충되는 것처럼 들리지만, 그들은 이것이 전체를 이해하기에 충분히 작으면서도 거의 모든 계층에서 확장이 가능한 도구를 의미한다고 설명합니다.

Pi 1.0 발표 문서에는 매주 전 세계 수십만 명의 사용자가 Pi를 사용하고 있다고 언급되어 있지만, 구체적인 숫자는 제시되지 않았습니다[2].

GitHub에 올라온 실제 통계는 이 글을 작성하는 시점에 해당 레포지토리가 113,973개의 별(star), 14,485개의 포크(fork), 그리고 아직 열려 있는 이슈가 325건이라는 것을 보여줍니다[1].

Hacker News에 올라온 Pi 1.0 발표 글은 1,687점의 점수와 609개의 댓글을 받으며 1위를 차지했습니다[3].

제가 주목하는 부분은 모든 소스 코드를 agent가 스스로 읽어낼 수 있도록 공개했다는 점입니다.

팀에 따르면 Pi Durable 코드 자체는 테스트를 제외하고 약 15,000줄로, GPT 계열 모델에 입력할 경우 약 150,000 토큰, Claude에 입력할 경우 약 250,000 토큰에 해당합니다[4].

이 수치는 작음을 과시하기 위함이 아니라, Pi에서 작동하는 agent가 자신이 실행하고 있는 harness의 코드를 실제로 검토할 수 있게 하기 위한 것입니다.

되돌아가서 살펴봐야 할 것들

2026년 9월 29일 날 작성된 기사에서 팀은 직접적인 질문을 던지며 시작했습니다. 만약 과거에 pi.dev를 본 적이 있다면, Pi가 MCP(Multi-Context Processing)를 지원하지 않는다는 자랑스러운 공지를 보았을 것입니다.[5] 현재 pi.dev의 메인 페이지는 "No MCP"에서 "Now with MCP+Codemode"로 바뀐 것을 명확하게 비교해 보여줍니다.[8]

여러 팟캐스트 에피소드에서도 MCP를 비하하는 발언이 적지 않았으며, Mario Zechner의 오래된 기사에서는 MCP를 사용하지 않는다면 어떨지에 대해 직접적으로 의문을 제기하기도 했습니다.[7]

하지만 현재 Pi를 업데이트하면 MCP가 지원되는 기능으로 바뀌어 있음을 발견할 수 있습니다.

팀은 이 질문을 회피하지 않았고, 기사의 첫 번째 섹션에서 "Things Change"라는 제목으로 솔직하게 다루었으며, 변화한 것이 두 가지 층위에 걸쳐 있다고 설명했습니다.

첫 번째 층위는 MCP 자체의 큰 변화입니다. 이는 불과 1년 전과는 매우 다르며, 이 이유만으로도 핵심 기능(core)으로 편입시키기에는 충분하다고 여겨집니다.

두 번째 층위는 MCP를 지원하기 위해 필요한 구조적 변경이 다른 유용한 기능을 가져왔다는 점입니다. 팀은 이번 구조 조정 덕분에 Jev 또는 Pi 내의 분류 모델(classifier model)을 사용하기가 더 쉬워졌다는 예를 들었습니다.

팀이 직접적으로 제시한 이유는 바로 이것입니다.

궁극적으로 Pi의 필요성은 MCP의 필요성과 유사합니다. 즉, 언어 인터프리터 형태의 놀이터(sandbox)를 제공하는 것입니다.[5]

Codemode란 무엇인가

Codemode라는 단어가 그 기사에서 여러 번 등장하며, 이것이 전체 이야기의 핵심입니다.

harness가 도구를 실행할 때, 그것은 두 가지 측면에서 작동합니다. 바로 bash가 실행되는 측면과 agent loop가 실행되는 측면입니다.

두 측면은 신뢰성 수준에 큰 차이가 있습니다. 왜냐하면 harness 루프는 일반적으로 신뢰할 수 있는 환경 내에 존재하는 반면, 호출되는 도구들은 덜 신뢰할 수 있는 샌드박스(sandbox) 안에 있기 때문입니다.

Codemode는 후자인 harness가 실행되는 곳에서 작동하도록 선택되었으며, 여러 도구의 호출을 하나의 세트로 조정하는 역할을 합니다.[5]

실질적으로 이는 모델이 제한된 컨텍스트 창을 통해 도구를 하나씩 호출해야 하는 대신, JavaScript 스크립트 한 세트를 작성하여 순서를 지정하고 결과를 통합한 다음, 최종 답변만을 반환한다는 것을 의미합니다.

제가 가장 똑똑하다고 생각하는 부분은 Codemode의 상태가 파일 시스템이 아닌 대화 기록에 저장된다는 점입니다.[5] 이는 기기에 흔적을 남기지 않으면서도, 그때 무엇을 했는지 여전히 되돌아볼 수 있게 해줍니다.

왜 JavaScript가 필요한가? 그 이유는 JavaScript 버전이 WASM 바이너리로 변환될 수 있어 합리적인 수준으로 위험을 방지할 수 있기 때문이다[5]

팀이 기사에서 제시한 예시는 Codemode를 통해 Jev를 사용하도록 단 하나의 문장으로 명령하는 것이었다. 이로써 issue tracker에서 가장 짜증 나는 사람 20명을 찾아내도록 하는 것이다.

그러자 Pi는 Linear MCP에서 데이터를 가져오고, 각 스레드의 어조에 대해 Jev에게 점수를 매기도록 요청했다(총 네 개의 스레드씩)[5]

이 모든 과정은 컨텍스트를 소모하지 않는다. 왜냐하면 코드가 harness 측에서 실행되기 때문이다.

아직 해결되지 않은 문제는 무엇인가

팀은 MCP가 완벽해졌다고 주장하지 않았다.

기사는 MCP의 가장 큰 문제가 여전히 결합하기 어렵다는 것임을 지적한다[5]. Codemode가 도움을 주었음에도 불구하고, MCP 자체는 이 문제를 완전히 해결하지 못했다.

팀은 문제의 일부가 프로토콜 자체에 있는 것이 아니라, 여전히 구형 harness를 위해 설계된 수많은 MCP 서버에 있다고 본다. 이러한 서버들은 모든 도구를 컨텍스트 창에 넣고, 메시지를 일반 텍스트로 보내면서 토큰을 절약하려고 한다[5].

팀이 제안하는 방식은 MCP가 OpenAPI 개념에 더 가까워져야 한다는 것이다. 즉, 구조화된 데이터를 전송하고, 도구가 자체 설명으로부터 발견될 수 있도록 해야 한다는 것이다[5].

제가 이 기사에서 가장 마음에 드는 문장은 그들이 MCP를 지지하기로 결정한 이유이다.

어떤 것에 긍정적인 영향을 미치는 가장 좋은 방법은 그것을 포용하는 것이다[5]

이 글을 읽으니, 조용히 마음을 바꾸는 것보다 더 솔직하고 정직한 이유가 보였다.

Pi 1.0의 새로운 기능들

MCP 외에도 팀은 이번 버전에 새롭게 추가된 일곱 가지 항목이 있다고 언급했다. 흥미로운 내용은 다음과 같다[2]:

지연 로딩(Lazy Loading) 도구 지원: 모든 도구를 처음부터 컨텍스트에 넣는 대신, Pi가 필요할 때만 로드한다. 이는 컨텍스트 창을 직접적으로 개선하는 데 도움이 된다.

Anthropic 계열 모델용 캐시 워밍업: 첫 번째 요청의 대기 시간을 줄이기 위함이다.

대화형 시스템 메시지(System Message): 대화를 진행하면서 프롬프트나 도구 세트를 변경할 수 있으며, 대화 기록은 일관되게 유지된다.

가상 모델 지원: 이는 Jev와 같은 분류 모델이나 이미지 생성 모델과 같이 언어 모델이 아닌 모델을 시스템에 통합하는 길을 열어준다.

네이티브 MCP 지원: 이 내용은 위 기사 전체에서 다루어진 주제이다.

팀은 이러한 결정이 모든 트렌드를 쫓는 것이 아니라고 강조하며, 복잡성을 늘리는 만큼의 가치를 증명하지 못한 다른 여러 제안들이 걸러졌다고 설명했습니다[2]

여기서 중요한 점은 MCP를 수용하는 것이 왜 1년이나 걸렸는지 설명해 주기 때문입니다.

장기 작업이 필요한 에이전트를 위한 Pi Durable

Pi 1.0과 같은 날, 팀은 Pi Durable라는 이름의 체험 패키지를 출시했습니다[4]。

필요한 이유는 기존 Pi는 사용자의 터미널에서 단독으로 구동되도록 설계되었기 때문입니다. 만약 프로세스가 종료되면 무엇이 발생했는지 확인하고 작업을 재개해야 합니다.

하지만 팀은 이것이 그 이상으로 나아가기를 원합니다. 즉, 어디서든 실행 가능하고 여러 채널을 통해 접근할 수 있으며, 매우 긴 대화를 지원하고 여러 사람이 동일한 에이전트를 제어하도록 할 수 있어야 한다는 것입니다.

핵심은 체크포인트(Checkpoint)

팀이 작성한 설명에 따르면 Pi Durable에서는 모든 작업 단계가 다음으로 넘어가기 전에 체크포인트로 기록되는 하나의 작업입니다[4]。

만약 프로세스가 종료되면, 기존 데이터 저장소를 가리키는 새로운 프로세스를 시작하여 마지막 체크포인트부터 대기 중이던 작업을 찾아 이어서 수행합니다.

중간에 잘린 모델 요청은 다시 전송되며, 일부 답변은 기록에 남아 있고 취소된 것으로 표시됩니다.

마찬가지로 중간에 끊긴 도구 호출은 안전한지 여부에 따라 재실행됩니다. 안전하지 않으면 모델에게 중단되었다고 알려줍니다.

팀은 Pi Durable에 자체 에이전트 시스템은 없지만, 몇 줄의 코드로도 만들 수 있으며, 에이전트가 자신의 대화 내에서 실행되기 때문에 멈춘 지점부터 작업을 계속할 수 있다고 설명했습니다.

선택 가능한 데이터 저장소

Pi Durable는 데이터 저장 계층을 harness 자체와 분리하며, 세 가지 완성된 옵션을 제공합니다. 바로 메모리 기반 SQLite, JSONL 파일, 그리고 사용자가 자신만의 저장소를 작성할 수 있도록 일관성 테스트 및 벤치마크가 포함되어 있습니다[4]。

흥미로운 점은 SQLite와 JSONL 코드가 Node의 API를 호출하지 않아 약간만 조정하면 Bun이나 Cloudflare Durable Object에서도 실행될 수 있다는 것입니다.

그리고 SQLite의 경우, harness는 현재 사용 중인 세트, 즉 활성 기록(active records), 실행 중인 작업, 대기 중인 작업을 메모리에 저장하고 나머지는 필요할 때까지 디스크에 보관합니다.

팀은 비록 대화가 수만 개의 메시지를 포함하더라도 컨텍스트 창을 초과하기 전에 오래된 메시지가 요약되기 때문에 여전히 메모리에 충분하다고 설명했습니다.

실행 환경과 도구 사용 분리

제가 잘 설계되었다고 생각하는 또 다른 점은 도구를 실행하는 환경을 harness 자체와 분리했다는 것입니다. 덕분에 harness는 한 장치에서 실행되지만, 도구는 다른 장치에서 실행될 수 있습니다[4].

이는 harness를 서버에 두고도, 도구가 사용자의 로컬 기기에 있는 파일을 건드릴 수 있다는 것을 의미합니다.

주의할 점들

저는 Hacker News 609 스레드와 그 댓글들을 읽었습니다. 결론적으로 이 의견들이 모두 찬성하는 목소리만은 아니었습니다[3].

스레드에서 가장 높은 평가를 받은 댓글은 Juggler라는 다른 프로젝트의 개발자로부터 왔습니다. 그는 Pi가 1위를 차지할 때마다 속으로 '나도 똑같이 할 수 있는데, 그래픽이 더 예쁘다'고 투덜거렸다고 말했습니다.

그리고 그는 Pi가 실제로 앞서 있는 지점은 플러그인 시스템이며, 이는 사람이 만들어야 하는 것이고, 이것이야말로 현재 가장 희귀한 것이라고 지적했습니다.

또 다른 댓글에서는 이 분야에서는 마케팅이 정말 중요하다는 의견을 제시했습니다. 아무리 좋은 도구라도 사람들이 무엇이 어디서 다른지 구분하지 못하면 소용이 없다는 것입니다[3].

더 나아가 더 강한 의견은, 이 업계의 혼란스러움의 핵심 문제가 좋고 나쁜 도구가 있느냐가 아니라, 이런 종류의 도구들이 AI를 통해 너무 쉽게 만들어질 수 있다는 점에 있다고 지적했습니다. 따라서 사용자가 엄청나게 몰려올 것이라고 기대하는 것은 더 이상 현실적이지 않을 수도 있습니다[3].

이 마지막 의견은 깊이 생각해 볼 가치가 있습니다. 왜냐하면 이것은 이 시대에 도구를 만들고 있는 모든 사람이 스스로에게 답해야 할 질문이기 때문입니다.

Earendil 팀은 Pi가 자리를 지킬 수 있는 것은 매주 바뀌는 유행을 따르는 것이 아니라, 무언가가 스스로 증명될 때까지 기다리는 데서 온다고 명확히 밝혔습니다[2].

직접 시도해 보기

macOS 또는 Linux에 Pi를 단일 명령어로 설치할 수 있습니다[2].

curl -fsSL https://pi.dev/install.sh | sh

Windows에서는 PowerShell을 사용합니다[2].

powershell -c

저는 Pi가 실제 작업 환경에서 다른 harness보다 얼마나 더 잘 작동하는지에 대한 독립적인 비교 테스트 보고서를 아직 찾지 못했습니다. 따라서 사용을 고려하는 분들은 결정하기 전에 추가 정보를 찾아보시는 것이 좋습니다.

## 여러분은요

만약 믿었던 도구가 명확하게 선언했던 입장을 바꾼 것을 본 적이 있다면, 그것을 '철회(backtracking)'라고 생각할지 아니면 '새로운 사고'라고 생각할까요?

두 진영의 답변은 단지 사용하는 단어에 차이가 있을 뿐일 수 있지만, 그 이유를 모든 줄마다 작성한 팀이라면 그 답은 명확하게 드러나 있다고 생각합니다.

만약 Pi를 사용해 보았거나, 논리적인 근거로 입장을 바꾼 흥미로운 다른 harness가 있다면 어떤 것인지 들려주세요.

## 참고 자료

[1] Earendil, "earendil-works/pi", GitHub, 2026. [https://github.com/earendil-works/pi]

[2] Earendil, "Pi 1.0", earendil.com, 2026년 10월 1일. [https://earendil.com/posts/pi-1-0/]

[3] Hacker News, "Pi 1.0", news.ycombinator.com, 2026년 10월 2일. [https://news.ycombinator.com/item?id=49926069]

[4] Earendil Engineering, "Pi Durable", earendil.com, 2026년 10월 1일. [https://earendil.com/posts/pi-durable/]

[5] Earendil Engineering, "You Said No MCP!", earendil.com, 2026년 9월 29일. [https://earendil.com/posts/you-said-no-mcp/]

[6] Earendil Engineering, "What is a harness?", earendil.com, 2026년 8월 20일. [https://earendil.com/posts/what-is-a-harness/]

[7] Mario Zechner, "What if you don't need MCP at all?", mariozechner.at, 2025년 11월 2일. [https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/]

[8] Earendil, "Pi", pi.dev, 2026. [https://pi.dev/]