9월 29일 뒤집힌 "MCP는 안 쓴다" — 표 635개가 몰린 도구 호출 재설계, 코드 모드의 실체

발행 2026-10-01 · 분류 에이전트 도구 · 난이도 중급 · 읽는 시간 6분

Pi의 MCP 노선 전환 히어로 — 도구 호출 JSON이 JavaScript 샌드박스로 옮겨 가는 다크 네온 일러스트, 테크한잔

결론부터. 도구 연동 표준 논쟁의 전선은 'MCP를 쓰느냐'에서 'MCP를 코드로 감싸느냐'로 옮겨 갔다.

'MCP 미지원'을 내세우던 터미널 코딩 에이전트 Pi가 최근 버전에서 노선을 틀었다. MCP가 코어 기능으로 들어갔다. 제작팀이 9월 29일 올린 경위 글은 하루 뒤 HackerNews에 올라 표 635개, 댓글 350개를 모았다(HN Algolia API로 2026-10-01 실측).

다만 이 사건의 값어치는 입장 변화 자체보다 뒤에 깔린 설계에 있다. 이들은 MCP를 그냥 켠 게 아니다. 9월 30일 HackerNews에 올라 표 635개, 댓글 350개를 모은 글(HN Algolia API로 2026-10-01 실측)이 그 경위다. MCP 호출을 JavaScript 샌드박스 안으로 집어넣는 방식, 이른바 코드 모드를 코어에 함께 넣었다. 이 방식이 실제로 어떻게 돌아가는지는 공개된 패키지 문서에서 직접 확인할 수 있다.

30초 요약

항목내용
무슨 사건'MCP는 확장으로도 안 쓴다'던 Pi가 MCP를 코어 내장으로 전환. 경위 글 → HackerNews 표 635·댓글 350 (2026-10-01 API 실측)
전환 방식MCP 도구들을 JavaScript 샌드박스에 노출하는 구조(코드 모드). 순차·병렬 호출과 중간 값 처리를 모델 왕복이 아니라 코드 쪽에 맡긴다
제작팀 유보합성(도구 결과를 이어 붙이기)의 어려움은 여전히 남는다고 스스로 인정. 원인은 프로토콜보다 서버들과 하네스들의 제각긴 처리 방식
직접 확인 가능Pi 생태계 공개 코드 모드 패키지의 기본값: 실행 타임아웃 30초·업스트림 호출 상한 50개·모델에게 돌아가는 데이터 16KiB·렌더 출력 50KiB
경쟁 표준ACP(Agent Client Protocol). 스레드에서 "차라리 ACP를 넣지" 댓글이 상위 노출 — 단, 층위가 다른 문제라는 반론도 붙었다
반대 논리"셸 스크립트로 이미 조합 가능한데 뭘 코어에 넣나" — 미니멀리즘 자기부정 지적. 스레드 주요 쟁점 6개로 정리했다

1. 무엇이 터졌나

주체는 Earendil의 Pi다. 터미널에서 도는 '하네스(에이전트 뼈대)'를 자처하는 도구로, 한때 사이트 첫 화면에 MCP 미지원을 자랑처럼 걸어 뒀다. 이런 일도 있었다. 저장소 초기(GitHub 이슈 #563)에 MCP 통합 예제 요청이 올라왔고, 제작자는 "커뮤니티 패키지가 이미 있다"며 닫았다. 그 패키지가 pi-mcp-adapter다. 지금 Pi 문서에는 MCP 연동 경로가 여럿 나열돼 있다. 확장으로 시작해 코어로 올라온 경로다.

경위 글의 논리는 세 겹. 첫째, "1년 지켜본 MCP는 예전 MCP가 아니다" — 이것만으론 코어에 넣을 이유가 안 된다. 둘째, 진짜 이유는 하네스 쪽이다. 도구 정의를 통째로 컨텍스트에 깔아 놓는 방식이 저물면서, Pi는 지연 도구 로딩(필요할 때 꺼내는 구조)이나 대화 중 시스템 메시지 같은 최신 모델 기능에 맞춰 도구 계층을 다시 짜야 했다. 그 재작업이 MCP 요구 사항과 겹쳤고, 김에 코어로 들었다. 셋째, "지켜만 볼 바엔 안에 들어가 방향을 흔드는 편이 낫다"는 생태계 참여 논리다.

그리고 글은 스스로 한계를 적는다. 코드 모드를 얹어도 MCP의 최대 약점인 '합성의 어려움'은 완전히 풀리지 않는다고. 그 책임을 프로토콜이 아니라 서버 생태계와 하네스마다 다른 처리 방식에서 찾는다. 이들이 제시한 방향은 "지능형 도구 검색을 얹은 OpenAPI에 가까워져야 한다"는 것 — 도구는 구조화된 데이터를 반환하고, 문서와 설명으로 발견돼야 한다는 기준이다.

2. 왜 대단한가

① 반대자가 이동할 때 표준이 결정된다

표준 전쟁에서 가장 값진 신호는 반대자의 이동이다. MCP는 등장 이후 "무겁고, 도구 목록이 컨텍스트를 태우고, 출력이 텍스트 덩어리"라는 비판을 받아 왔고, Pi 제작팀은 그 비판을 문서와 팟캐스트로 직접 제기한 측이었다. 그쪽이 코어 내장으로 방향을 트는 순간, 바깥 진영은 '왜 우리만 밖에 있나'를 설명해야 한다. 표준의 최종 문구는 대개 마지막까지 버틴 쪽의 불만을 반영하는 쪽으로 정해진다.

② 도구 호출을 프롬프트가 아니라 프로그램으로

기존 호출은 모델이 JSON 한 장을 내는 식이었다. 도구 세 개를 순서대로, 앞 결과의 id를 뒤 호출에 넣으려면 왕복 세 번이고 중간 JSON이 전부 대화에 남는다. 코드 모드는 반대다. 모델이 샌드박스에서 스크립트 한 편을 실행하고 변수·반복문·Promise로 호출을 잇는다. 중간 데이터는 대화에 안 올라가고 최종 반환값만 모델에 돌아간다.

'샌드박스'는 과장이 아니다. 공개된 코드 모드 패키지 문서를 열면 기본값이 박혀 있다: 실행 타임아웃 30초, 서버 호출 상한 50개, 모델에 돌아가는 데이터 16KiB, 렌더 출력 50KiB. 실행 엔진에는 "호스트의 파일시스템·환경변수·네트워크·서브프로세스 접근이 없고, 바깥은 노출된 MCP 호출로만 나간다"고 못 박혀 있다. "아이디어는 Cloudflare 쪽에서 왔다"는 표기까지 있다.

③ 신뢰 경계에 제3의 구획을 낸 것

경위 글이 설명하는 코드 모드의 위치가 미묘하다. 통상 하네스는 두 곳에서 돈다. 신뢰되는 에이전트 루프, 신뢰가 분리된 도구 실행부. 코드 모드는 "하네스 쪽에서 실행되되 호출을 조율하는" 중간 지대를 만들었고, 상태는 파일시스템이 아니라 대화 기록에 남는다. JavaScript를 고른 이유도 적혀 있다 — WASM으로 작게 배포하고 보호 수준도 확보할 수 있다는 것. 신뢰 경계를 새로 긋는 설계라서, 운영자 눈에는 이 문단이 본체다.

④ 자기 철학에 대한 반박을 문서에 미리 심어 둔 구조

Pi는 "남들이 구워 넣는 기능을 네가 직접 만든다"는 최소주의를 파는 도구다. 그래서 이번 전환은 기능 추가가 아니라 포지셔닝의 수정이다. 경위 글은 "확장으로 충분하지 않았나"라는 반문을 미리 꺼내 "팀이 앉아 다시 생각한 결과"라고 답한다. 입장을 바꾸는 글의 양식으로도 읽어 둘 만하다.

3. 바로 써먹기

값이 어디 있는지, 여러 API를 순서대로 잇는 상황으로 견주면 된다. 아래는 이 글에 맞게 축약한 의사 코드다(도구 이름은 실제 문서의 검색·실행 계열을 줄였다).

// 코드 모드: 모델은 이 스크립트 한 편만 짠다.
// 중간 결과는 샌드박스에 남는다
const bugs = await mcp.tracker.search({ q: "crash", limit: 50 });
const ids  = bugs.items.map(b => b.id);
const ops  = await Promise.all(
  ids.map(id => mcp.repo.getIssue({ ref: id }))
);
return summarize(bugs, ops);   // 이 반환값만 모델로 올라간다
기준전통 MCP(도구 직접 노출)코드 모드 경유
컨텍스트 비용도구 스키마 전량 상주 + 호출마다 왕복도구 검색은 필요 시, 반환은 1건 (공개 구현 기준 16KiB 상한)
순차·병렬 조합모델이 왕복으로 강제스크립트 안에서 Promise.all
중간 데이터대화에 전부 노출샌드박스 안에 잔존
실패 처리재질문으로 재시도try/catch·재시도 루프를 코드로 작성
재사용대화 로그를 다시 설명잘 쓴 스크립트를 재사용 도구(체인)로 승격

오늘 할 일 셋. ① 팀 MCP 서버가 있으면 출력부터 텍스트 덩어리에서 구조화된 데이터로 바꾼다 — 병폐의 절반은 서버 쪽이다. ② 컨텍스트 비용 계측. 도구 목록을 통째로 올리는 하네스라면 스키마 토큰 수를 재고 지연 로딩 지원 하네스로의 전환 시점과 비교한다. ③ 잘 나가는 호출 흐름 하나를 스크립트화해 재사용 도구로 굳힌다 — '체인 저장'이 1급 기능으로 있다.

4. 해외 반응 쟁점

HackerNews 스레드(댓글 350개)에서 반복해 튀어 오른 줄기를 추렸다.

① "부실한 표준이어도 없는 것보단 낫다"는 실용론. USB-C·NVMe·HDMI가 빈틈 많은 표준임에도 호환성 하나로 이긴 예를 들며, MCP도 성능보다 상호운용성으로 이기는 경로라는 주장이 상위 댓글에 올랐다.

② "이미 셸이 있지 않나" 반론. bash로 뭐든 조합 가능한데 왜 하네스 안에서 코드가 도구를 호출하게 만드느냐는 질문. "코드 모드는 하네스 도구를 하네스 안에서 돌리는 스크립트일 뿐, 코어에 올 이유가 없다"는 댓글이 지지를 받았다.

③ 미니멀리즘 이탈 지적. "확장으로 충분했다", "미니멀을 자처하더니 결국 기능 팽창"이라는 댓글들. 반대로 "원래 애용되던 어댑터 패키지를 흡수한 것일 뿐, 원하면 다시 패키지로 빼면 된다"는 두둔도 붙었다.

④ "차라리 ACP를". 경쟁 표준인 Agent Client Protocol을 밀는 댓글이 여럿 달렸다. 다만 스레드 안에서 "Pi의 정체성은 터미널이고, Pi의 RPC를 ACP로 잇는 브리지는 이미 따로 존재한다"는 반론이 붙었다.

⑤ "MCP는 그냥 'API를 기계가 읽게 문서화한 것'인데 OpenAPI를 확장하면 되지 않았나"라는 근본 질문. 경위 글의 "지능형 도구 검색을 얹은 OpenAPI에 가까워져야 한다"와 같은 방향이라, 스레드에서는 "사실상 인정한 발언"이라는 인용이 나왔다.

⑥ "MCP로 파일 업로드는 어떻게 하나" — 도구 반환을 텍스트 위주로 규정한 표준의 빈 구멍을 찌르는 실전 질문이다.

5. 마시기 전 주의

바로 가기

같이 마시면 좋은 잔
NVIDIA OpenShell — "하지 마" 대신 "못 해"를 커널에 심는 법 — 도구 실행부의 신뢰 경계를 아예 다른 층(커널)에서 강제하는 대비 사례.
폭주하는 에이전트는 없다 — 단어 하나가 책임 구조를 바꾼 2주 — 에이전트 도구 권한 논쟁의 다른 전선.
AI·오픈소스 시리즈 — 해외에서 먼저 검증된 흐름만 골라 해부한다.
도구 코너 — 로컬 개발 워크플로 체크리스트 (준비 중).