Pi가 MCP를 코어에 받아들이고 Codemode로 도구 호출을 묶는다

Pi가 자사 도구에서 MCP(Model Context Protocol)를 코어 기능으로 받아들였다. pi.dev를 찾은 사람이라면 MCP를 지원하지 않는다는 선언을 봤을 것이고, Pi를 다룬 팟캐스트에서도 MCP에 대한 부정적인 언급이 여러 번 나왔다. 그런 Pi를 업그레이드하면 이제 MCP가 지원되는 구성 요소로 들어가 있다.

MCP 지원과 함께 눈에 띄는 것이 Codemode다. Codemode는 하네스가 도는 쪽에서 실행되는 자바스크립트 샌드박스로, 에이전트가 도구 호출의 순서를 스스로 정하고 여러 호출을 자바스크립트로 엮을 수 있게 해준다. 상태가 별도 저장소가 아니라 세션 트랜스크립트의 일부로 유지되는 점도 특징이다. Pi에서는 MCP를 설정하면 Codemode가 자동으로 로드되고, 기본 도구로 구성에 넣을 수도 있다. Pi에게 스스로 재구성해 codemode를 켜라고 요청하면 된다. 이론상 어떤 언어든 가능하지만, 작은 자바스크립트 런타임을 WASM 바이너리로 배포할 수 있다는 점이 자바스크립트를 매력적으로 만든다.

코어 편입은 MCP 자체가 달라졌기 때문만은 아니다. 지난 1년간 MCP를 지켜봤고 지금의 MCP는 예전과 다르다고 본다. 확장으로 붙일 수도 있었지만 실제로 그렇게 했었고, 코어에 넣으면서 필요했던 변경들이 다른 곳에도 쓸모가 있었다. 그 변경 덕분에 Pi 안에서 Jev를 더 쉽게 쓸 수 있게 됐다는 설명이다. 결국 Pi가 필요로 하는 것과 MCP가 필요로 하는 것이 비슷하다. 인터프리터 형태의 샌드박스다.

도구를 어떻게 표현할지도 중요한 이유였다. Pi는 최근 몇 달간 지연된 도구 로딩, 대화 중간의 시스템 메시지, 추론 수준 변경 같은 새 모델 기능을 Pi가 이해하도록 작업했다. 다만 도구 로드아웃 자체를 더 잘 확장하도록 올리지는 못한 상태였다. Codemode 환경에서는 어떤 도구를 LLM에 노출하고 어떤 도구를 codemode 쪽에만 둘지 정해야 하는데, 일반적인 MCP 확장은 Pi의 도구 로드아웃에서 얻을 수 있는 메타데이터가 부족하다. 그래서 도구를 지연시키거나 특정 방식으로 구성할 수 있게 만드는 작업이 필요했다.

Pi가 그리는 MCP의 모습은 OpenAPI에 지능형 도구 탐색을 얹은 것에 가깝다. 도구는 구조화된 데이터를 반환하고, 설명을 통해 발견 가능해야 한다는 것이다. CLI가 강력한 이유는 에이전트와 모델이 효율적인 bash 조합으로 필요한 것을 엮어내기 때문인데, MCP라고 해서 그렇게 못 할 이유는 없다. Pi의 MCP는 Codex 같은 다른 하네스처럼 도구를 자바스크립트 샌드박스에 노출하는 방식 위에 세워져 있다.

실제 활용 예로 이슈 트래커 분석이 소개됐다. Linear MCP와 Jev를 codemode로 묶어 열린 이슈에서 불만이 큰 사람을 찾아내는 식이다. 열린 이슈 167건 가운데 156건은 중립, 11건은 가벼운 불만으로 분류됐고 강한 불만은 없었다. README에 설치 섹션이 없는 점, 사고 중 Esc를 누르면 'Working...'에 멈추는 문제, /update 명령 요청, macOS에서의 높은 CPU 사용량 같은 항목이 눈에 띄었다. 이슈별 판정 결과는 codemode의 frustration 항목에 남아 있어 이슈를 다시 불러오지 않고도 들여다볼 수 있다. 이런 분석을 Pi 안에서 컨텍스트를 거의 쓰지 않고 처리한다는 점이 강조됐다.

한계도 분명하다. MCP의 가장 큰 문제는 여전히 조합하기 어렵다는 점이고, 도구 호출 조합을 위한 codemode가 있어도 완전히 해결되지는 않는다. 다만 이는 MCP 자체보다 세상에 나와 있는 MCP 서버들과 이를 다루는 하네스들의 접근법 문제에 가깝다. 많은 MCP 서버가 도구를 컨텍스트에 그대로 쏟아붓는 하네스를 전제로 만들어져 있고, 텍스트를 반환해 토큰 효율을 높이는 쪽에 최적화되어 있다.

Pi 쪽은 앞으로 Jev와 Codemode에 대해 더 다룰 예정이라고 밝혔다.