9월 29일 뒤집힌 "MCP는 안 쓴다" — 표 635개가 몰린 도구 호출 재설계, 코드 모드의 실체
결론부터. 도구 연동 표준 논쟁의 전선은 '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. 마시기 전 주의
- 코드 모드는 '모든 도구'를 자유롭게 잇는 기능이 아니라 명시적으로 노출된 호출만 통하는 샌드박스다. 공개 구현 기준 파일시스템·환경변수·네트워크·서브프로세스는 기본 차단이며, 반대로 말하면 노출된 호출의 권한 범위를 먼저 읽어 봐야 한다.
- 타임아웃 30초·호출 50개·반환 16KiB 같은 기본값은 보호장치이자 상한이다. 큰 데이터를 다루는 서버를 붙이면 조용히 잘린 값이 돌아온다 — "결과가 왜 절반이냐"는 항의성 댓글이 스레드에도 있다.
- 경위 글은 프로토콜 비판을 일부 인정한다. '코어에 들어갔으니 다 해결'로 읽으면 안 된다. 합성 문제는 서버 생태계 과제로 남는다.
- Pi 자체는 터미널 도구다. 팀에 터미널 미사용자가 많다면 도입 비용이 문서보다 크다는 논점도 스레드에 있다.
- ACP는 층위가 다른 문제다. 도구 연동과 에이전트-클라이언트 통신을 한 축만 바꿨다고 다른 축까지 해결됐다고 착각하지 말 것.
바로 가기
- 경위 글 "You said no MCP!" — 입장 전환의 1차 문서
- HackerNews 스레드 — 표 635·댓글 350의 현장을 직접
- pi.dev 코드 모드 패키지 문서 — 샌드박스 기본값이 명시된 페이지
NVIDIA OpenShell — "하지 마" 대신 "못 해"를 커널에 심는 법 — 도구 실행부의 신뢰 경계를 아예 다른 층(커널)에서 강제하는 대비 사례.
폭주하는 에이전트는 없다 — 단어 하나가 책임 구조를 바꾼 2주 — 에이전트 도구 권한 논쟁의 다른 전선.
AI·오픈소스 시리즈 — 해외에서 먼저 검증된 흐름만 골라 해부한다.
도구 코너 — 로컬 개발 워크플로 체크리스트 (준비 중).