에이전트 도구 Pi를 만드는 Earendil이 그동안의 공언을 뒤집었다. 한때 pi.dev에는 "Pi는 MCP를 지원하지 않는다"는 선언이 자랑스럽게 걸려 있었고, 팟캐스트나 공동창업자 마리오의 글에서도 MCP(Model Context Protocol)를 향한 냉소적인 언급이 여러 차례 나왔다. 그런데 최신 버전으로 올리면 MCP가 정식 기능으로 들어와 있다. 무엇이 바뀐 것인지, 그리고 그들이 함께 강조하는 '코드모드(Codemode)'가 무엇인지 정리해 볼 만하다.
왜 입장을 바꿨나
Earendil이 내세우는 첫 번째 이유는 세상이 고정돼 있지 않다는 것이다. 지난 1년간 MCP를 지켜봤고, 오늘의 MCP는 예전의 MCP가 아니라는 설명이다. 다만 이것만으로 코어에 넣을 이유가 되지는 않는다. Pi는 확장(extension) 생태계가 탄탄하고, 실제로 MCP도 한동안 확장 형태로 존재했기 때문이다. 결국 MCP를 코어로 끌어들인 결정은 단순히 MCP가 좋아져서가 아니라, MCP를 제대로 품기 위해 필요한 변경들이 Pi 전반에 두루 쓸모가 있었기 때문이라고 한다. 예컨대 같은 변경이 Pi 안에서 'Jev'를 더 쉽게 쓰도록 만들어 줬다. 이들의 표현대로라면 Pi가 필요로 하는 것과 MCP가 필요로 하는 것은 닮아 있다. 바로 인터프리터 형태의 '놀이터', 즉 샌드박스다.
여전히 남은 MCP의 한계
많은 것이 개선됐지만 그대로인 부분도 있다. Earendil이 지목하는 가장 큰 문제는 MCP가 여전히 조합(compose)하기 어렵다는 점이다. 도구 호출을 엮어 주는 샌드박스인 코드모드를 붙여도 이 문제가 완전히 해결되지는 않는다. 다만 이제 이것은 MCP 프로토콜 자체보다는, 바깥에 나와 있는 MCP 서버들과 이를 다루는 각 하네스(harness)의 접근 방식 문제에 가깝다는 진단이다. 상당수 MCP 서버는 도구를 그냥 컨텍스트에 쏟아붓는 하네스를 전제로 만들어졌고, 텍스트를 반환해 토큰 효율을 자기 쪽에서만 최적화하려 한다.
Earendil이 제시하는 바람직한 방향은 MCP를 '지능적인 도구 발견 기능을 갖춘 OpenAPI'에 가깝게 보는 것이다. 즉 도구는 구조화된 데이터를 반환해야 하고, 문서와 설명을 통해 발견 가능해야 한다. CLI가 강력한 이유는 에이전트와 모델이 효율적인 bash 문법으로 이것저것을 엮어 내기 때문인데, MCP라고 그렇게 못할 근본적인 이유는 없다는 것이다. 실제로 Pi의 MCP는 Codex 같은 다른 하네스처럼 도구를 자바스크립트 샌드박스에 노출하는 방식으로 구현됐다.
코드모드란 무엇인가
그렇다면 MCP 없이 코드모드만 붙이면 되지 않았느냐는 의문이 남는다. 여기에는 Pi가 도구를 표현하는 현재 방식이 얽혀 있다. Pi는 최근 지연 도구 로딩(deferred tool loading), 대화 중간의 시스템 메시지, 추론 수준 변경을 지원하는 새 모델들에 맞추는 작업을 많이 했지만, 도구 구성 자체는 아직 그 역량에 맞게 확장하지 못했다. 코드모드 환경에서는 어떤 도구를 LLM에 열어 줄지, 아니면 LLM의 코드모드 부분에만 열어 줄지 결정해야 한다. 일반 MCP 확장으로는 Pi의 도구 구성에서 이 경험을 잘 만들 만한 메타데이터가 부족했다. 그래서 도구를 지연 로딩하거나 코드모드 전용으로 지정할 수 있도록 손봐야 했다.
코드모드의 핵심은 실행 위치에 있다. 하네스가 도구를 실행할 때는 보통 bash가 도는 쪽과 에이전트 루프가 도는 쪽으로 나뉘고, 둘의 신뢰 수준은 다르다. 하네스 루프는 대개 신뢰된 환경에서 돌지만, 도구는 그다지 신뢰되지 않는 샌드박스에서 실행되는 경우가 많다. 코드모드는 특이하게도 하네스가 도는 쪽에서 실행된다. 도구 호출을 자바스크립트로 조율하고 조합하는 장치로, 호출 순서에 더 많은 유연성을 준다. 하네스 쪽에서 돌기 때문에 그 상태는 파일시스템이 아니라 세션 트랜스크립트의 일부로 유지된다. 언어는 이론상 무엇이든 가능하지만, 작은 자바스크립트를 WASM 바이너리로 실어 적절한 수준의 보호를 걸 수 있다는 점에서 매력적이라는 설명이다.
실무자에게 주는 의미
Pi에서 코드모드는 MCP가 설정되면 자동으로 로드되며, 기본 도구로 추가하도록 설정할 수도 있다. Pi에게 스스로 재설정해 코드모드를 켜 달라고 요청하면 된다는 것이다. 활용 예로는 'Jev'를 제공하는 프로바이더에 로그인한 상태에서 typesafe/jev를 코드모드로 써서 이슈 트래커에서 가장 불만이 많은 댓글 작성자 20명을 찾는 식의 작업이 제시된다. 이때 Pi는 Linear MCP와 Jev를 영리하게 조합해 컨텍스트 낭비 없이 분석을 수행한다고 한다.
정리하면 이번 변화는 단순한 기능 추가라기보다 입장의 재정립에 가깝다. 무언가에 긍정적 영향을 주는 가장 좋은 방법은 그것을 끌어안는 것이라는 판단 아래, 방관자로 남기보다 작은 하네스에서도 잘 동작하도록 MCP 논의에 직접 참여하겠다는 것이다. 다만 Earendil 스스로도 현대 MCP가 과거보다 나아졌을 뿐, 서버와 패턴에는 여전히 개선 여지가 남아 있다고 인정한다. Jev와 코드모드의 구체적인 활용 범위나 성능 수치는 이번 글에서 충분히 공개되지 않은 만큼, 도입을 검토하는 실무자라면 조합 가능성이라는 방향성과 아직 남은 서버 생태계의 한계를 함께 염두에 둘 필요가 있다.