Pi의 MCP 전환, 도구 나열에서 코드 조합으로

MCP를 지원하지 않는다고 강조하던 Pi가 방향을 바꿨다. Earendil은 9월 29일 공개한 “You Said No MCP!”에서 MCP를 확장이 아닌 코어 기능으로 넣은 이유를 설명했다. 이 글은 9월 30일 Hacker News에서도 소개됐다. 단순한 표준 합류보다 중요한 대목은 도구를 모델의 문맥에 모두 나열하는 방식에서, 필요한 도구를 찾고 코드로 조합하는 방식으로 중심을 옮겼다는 점이다.

발표는 MCP가 모든 문제를 해결했다고 말하지 않는다. 오히려 서버들이 여전히 텍스트 반환에 치중하고 도구 조합을 어렵게 만든다고 지적한다. 표준을 지지할지 거부할지의 논쟁보다 서버와 하네스의 역할을 어떻게 나눌지가 실무에 더 가까운 질문이다.

왜 확장이 아니라 코어인가

Earendil에 따르면 Pi는 최근 모델의 지연 도구 로딩, 대화 도중 시스템 메시지, 추론 수준 변경 같은 기능에 맞춰 작업해 왔다. 하지만 기존 도구 구성에는 도구가 모델에 직접 노출되는지, Codemode에서만 쓰이는지, 필요할 때 지연 로딩되는지를 충분히 표현할 정보가 부족했다.

MCP 확장만으로는 이 구분을 매끄럽게 지원하기 어려웠다는 설명이다. 코어에서 메타데이터를 정비하면 MCP뿐 아니라 다른 종류의 도구와 모델도 같은 조합 환경에서 사용할 수 있다. 이는 연결 규격의 지원 목록을 늘리는 작업이라기보다 실행 인터페이스를 바꾸는 작업에 가깝다.

Pi 공식 사이트는 현재 제품과 문서를 확인할 출발점이다. 다만 이번 글이 설명하는 설계 방향을 모든 확장의 자동 호환 보장으로 해석해서는 안 된다. 팀이 사용하는 서버와 도구별로 실제 동작을 확인해야 한다.

Codemode가 바꾸는 호출 방식

글에서 설명하는 Codemode는 하네스 쪽에서 동작하는 자바스크립트 샌드박스다. 도구 호출의 순서를 정하고 결과를 결합하며, 상태를 파일시스템 대신 세션 기록의 일부로 유지한다. 셸이 실행되는 영역과 하네스 루프가 실행되는 영역은 신뢰 수준이 다르다는 설명도 포함된다.

이 구분은 중요하다. 코드 조합을 지원한다고 해서 에이전트에게 무제한 시스템 권한을 주어야 하는 것은 아니다. 샌드박스 내부의 계산과 실제 외부 시스템의 변경은 별도 권한 경계로 다뤄야 한다. 서버가 반환한 텍스트 역시 실행 명령이 아니라 외부 데이터로 취급해야 한다.

이 표는 제품별 성능 비교가 아니라 설계 관점의 비교다. 실제 절감 토큰이나 처리 시간은 서버의 출력과 작업 형태에 따라 달라진다. MCP 공식 명세에서 규약을 확인하되, 규약을 준수했다는 사실만으로 좋은 도구 설명이나 안전한 업무 흐름까지 완성되는 것은 아니다.

예시의 핵심은 분류보다 데이터 흐름

Earendil은 Linear의 열린 이슈를 가져와 Jev로 댓글의 감정적 불만을 분류하는 예시를 제시한다. 예시 코드에는 네 개의 작업자가 병렬로 처리하는 구조가 있고, 출력에는 이슈 167개 중 중립 156개와 약한 불만 11개가 나타난다. 이 숫자는 공개된 세션 예시의 결과이지, 분류 정확도 벤치마크가 아니다.

중요한 것은 이슈 조회, 댓글 조회, 분류, 정렬을 하나의 프로그램 흐름으로 구성한다는 점이다. 도구가 서술형 텍스트만 돌려주면 중간 결과를 다시 해석해야 한다. 반대로 안정적인 식별자와 필드를 제공하면 필요한 항목만 추려 다음 도구에 전달할 수 있다.

글은 이를 지능적인 도구 발견을 갖춘 OpenAPI에 가까운 방향으로 설명한다. OpenAPI Initiative는 API를 기계가 다룰 수 있게 설명한다는 배경을 이해하는 참고 자료다. MCP와 OpenAPI가 같은 규격이라는 뜻은 아니며, 기존 REST API를 MCP로 감쌌다고 업무 의미가 자동으로 명확해지는 것도 아니다.

국내 기업의 MCP 서버가 준비할 것

사내 문서 검색이나 이슈 조회 서버를 만든 팀이라면 반환 스키마부터 점검할 만하다. 문서 제목과 요약만이 아니라 원본 식별자, 접근 가능한 링크, 갱신 시점, 다음 페이지 정보가 있어야 결과를 이어서 처리하기 쉽다. 데이터가 없다는 응답과 권한이 없다는 응답도 구별해야 한다.

쓰기를 지원한다면 더 중요하다. 결제, 게시, 고객 정보 변경은 네트워크가 끊긴 뒤 같은 요청을 다시 보냈을 때 어떤 결과가 되는지 정의해야 한다. 병렬 실행은 읽기 작업에서는 이득이지만, 서로 의존하는 수정 요청을 무조건 병렬화하면 순서 오류가 생긴다. Codemode는 이런 판단을 표현할 수 있는 수단이지 업무 규칙을 대신 정해 주는 장치가 아니다.

Google AX의 선언형 오케스트레이션 분석이 업무 구조를 다룬다면, 이번 Pi 변화는 호출을 조합하는 실행 인터페이스에 가깝다. AGENTS.md 지침 표준화와도 층위가 다르다. 지침의 공유와 실행 권한의 표준화는 따로 설계해야 한다.

최종적으로 Shopify WebMCP 결제의 위임 설계에서 보았듯, 도구를 발견할 수 있다는 것과 그 행동을 승인받았다는 것은 다르다. 한국 기업의 경쟁력은 MCP 서버 개수보다 정확한 업무 의미, 접근 제어, 변경 이력을 갖춘 연결에서 나올 가능성이 크다.

자주 묻는 질문

Pi는 이제 MCP를 지원하나?

Earendil의 발표에 따르면 코어 기능으로 지원한다. 기존 입장을 바꾼 이유는 Codemode와 도구 메타데이터를 함께 정비할 필요가 있었기 때문이다.

Codemode는 셸 명령 실행과 같은가?

글에서는 하네스 쪽에서 도구를 조합하는 자바스크립트 샌드박스로 설명한다. 셸 실행 영역과 신뢰 경계가 다르다.

구조화된 결과가 왜 중요한가?

다음 호출에 전달할 필드를 프로그램이 안정적으로 선택할 수 있기 때문이다. 텍스트 설명은 보완 자료가 될 수 있지만 유일한 데이터 형식일 필요는 없다.

병렬 호출은 항상 빠르고 안전한가?

아니다. 의존성이 없는 작업에 적합하며, 변경 순서가 중요한 업무나 속도 제한이 있는 서버에는 별도 제어가 필요하다.

기존 MCP 서버를 전부 다시 만들어야 하나?

그럴 필요는 없다. 설명의 검색 가능성, 결과 스키마, 페이지 처리, 오류 구분, 쓰기 작업의 재시도 의미부터 점검하는 것이 현실적이다.