Pi.dev: MCP를 거부했던 이유, 이제 지원하는 이유

AI 요약

Pi는 한동안 MCP(Model Context Protocol)를 지원하지 않는다고 밝혀 왔습니다. 하지만 최신 버전에서는 MCP가 코어 기능으로 들어갔습니다. 개발팀은 지난 1년간 MCP가 달라졌고, Pi에 필요한 도구 실행 환경을 다시 검토한 결과 MCP와 Codemode에 필요한 개선 사항이 서로 맞닿아 있었다고 설명합니다. MCP 지원은 별도 확장 기능으로도 만들 수 있었지만, 코어에 포함하면 Pi의 도구 로딩 방식도 개선할 수 있다고 판단했습니다.

MCP가 여전히 안고 있는 문제

개발팀은 MCP가 과거보다 나아졌지만 도구를 조합하기 어렵다는 문제는 남아 있다고 봅니다. Codemode를 도입해 도구 호출을 조합하더라도, 실제 사용 경험은 MCP 서버의 설계와 각 실행 환경(harness)에 따라 달라집니다. 많은 서버가 도구 설명과 호출 결과를 문맥에 그대로 넣는 방식을 전제로 만들어져 있습니다. 토큰 사용량을 줄이려 결과를 텍스트로 반환하는 경우도 많습니다.

Pi 개발팀은 MCP가 지능적인 도구 검색 기능을 갖춘 OpenAPI에 가까워져야 한다고 말합니다. 도구 설명을 바탕으로 필요한 도구를 찾고, 호출 결과는 구조화된 데이터로 받아야 한다는 방향입니다. 명령줄 인터페이스(CLI)가 유용한 까닭은 모델이 bash 명령을 조합해 작업을 연결하기 때문입니다. 개발팀은 MCP도 도구를 JavaScript 샌드박스에 노출하면 비슷한 방식으로 조합할 수 있다고 설명합니다.

Codemode는 도구 호출을 조합하는 샌드박스

도구 실행에는 신뢰 수준이 서로 다른 두 영역이 있습니다. 하나는 harness의 에이전트 루프가 돌아가는 영역이고, 다른 하나는 bash 등을 실행하는 영역입니다. Codemode는 harness 쪽에서 실행하는 도구 조정 수단입니다. 에이전트가 JavaScript로 여러 도구를 원하는 순서대로 호출하고 결과를 결합하도록 합니다. 실행 상태는 파일 시스템이 아니라 세션 기록에 남습니다.

JavaScript를 택한 이유로는 작은 실행 환경을 WebAssembly(WASM) 바이너리로 배포할 수 있고, 적절한 보호 장치를 마련할 수 있다는 점을 들었습니다. Pi에서는 MCP를 설정하면 Codemode가 자동으로 로드됩니다. 기본 도구로 직접 설정할 수도 있습니다. Codemode는 MCP 외의 도구에도 쓸 수 있습니다. 글에서는 Linear MCP와 Jev를 함께 호출해 이슈 추적기에서 불만이 큰 댓글 작성자 20명을 찾는 사례를 들었습니다.

최신 모델을 위한 도구 로딩

최근 모델은 도구를 필요할 때 불러오는 지연 로딩(deferred tool loading), 대화 중 시스템 메시지 추가, 추론 수준 변경 같은 기능을 지원합니다. Pi는 이런 모델에 맞춰 동작을 개선했지만, 도구를 제공하는 방식은 아직 충분히 바꾸지 않았다고 합니다. Codemode를 쓰려면 특정 도구를 모델이 직접 호출할지, Codemode 안에서만 사용할지 정할 수 있어야 합니다. 기존 도구 메타데이터만으로는 이 구분을 제대로 구성하기 어려웠습니다.

따라서 Pi는 도구를 지연 로딩하거나 Codemode 전용으로 설정할 수 있도록 손봤습니다. 개발팀은 Codemode와 MCP를 결합하면 기존 MCP 사용 방식의 문제도 줄일 수 있다고 봅니다. MCP 서버와 사용 관행은 여전히 개선이 필요하며, Pi 개발팀은 소규모 harness에서도 잘 작동하는 방향을 함께 만들어 가겠다고 밝혔습니다.

Hacker News 반응

• @uwagar — FTA에 MCP가 이렇게 많이 나오는데, 정작 MCP가 뭔지는 한 줄도 설명하지 않네요.
  • @ramblurr — 1. 첫 문단에 회고와 링크가 있습니다. 2. 아마 이 글의 대상 독자가 아닐 겁니다.
  • @otabdeveloper4 — MCP는 NIH가 만든 비표준 OpenAPI입니다.
  • @seanhunter — Pi를 쓰는 사람 대부분은 알 겁니다. MCP는 ‘Model Context Protocol’입니다. 모델이 API와 서비스에 연결되는 프로토콜이자, API와 서비스를 LLM과 에이전트가 사용할 수 있게 노출하는 방식입니다.
• @_fw — MCP를 꺼리는 태도는 이해하지만, 없는 것보다는 뭐라도 있는 편이 낫습니다. 글에서 저자가 설명한 이유로 차선책이긴 하지만 USB-C도, NVMe도, HDMI도 그렇습니다. 결함이 있어도 호환성이 넓고 최종 사용자가 쓰기 쉬워서 널리 쓰입니다. 그래서 MCP가 어디에나 있는 겁니다. 성능과 견고함, 일관성이 부족해도 시간이 지나며 나아질 겁니다. LLM을 유용한 도구에 연결하는 최적의 방법이 일곱, 여덟 개로 갈라지는 것보다 지금의 넓은 MCP 생태계가 낫습니다.
• @mi_lk — 이 글은 Codemode와 MCP를 섞어 설명하지만, 제 생각엔 설명이 이상합니다. 둘 다 최신 릴리스에 새로 들어간 기능인 것 같고요. Pi 사용자라면 에이전트에게 설명해 달라고 하는 편이 나을 수도 있습니다.
  • @the_mitsuhiko — 글쓴이입니다. 에이전트에게 PR을 넣은 다음 설명을 시키는 건 좋은 생각이 아니라고 봅니다. 파생된 작업물의 파생본을 읽게 되기 때문입니다. 설명이 부족하다면 더 잘 설명해야 합니다.
  • @mi_lk — 네, 사람마다 다르겠죠. 참고로 오늘 일찍 그렇게 해 봤는데, 변경 기록과 이 글을 읽는 것보다 Codemode를 더 잘 이해하게 됐습니다.
  • @the_mitsuhiko — 글에서도 말했듯 Codemode는 앞으로 더 설명할 예정입니다. 여러 면에서 이 글은 피할 수 없는 질문에 답하기 위해 필요했습니다.
• @ppsreejith — MCP에서 파일을 업로드할 좋은 방법을 찾은 분 있나요? MCP 바깥에서 HTTP로 파일을 올리는 게 권장 방식인가요?
  • @hobofan — 여러 방법을 정리한 MCP SEP가 있고, 언젠가는 채택되길 바랍니다. 안정화될 때까지 기다리는 동안 저희 도구에서는 요청·응답 스키마의 개별 필드를 파일 페이로드로 표시하는 방식을 구현했습니다. 그러면 harness가 파일 교환을 조정하고 문맥을 오염시키지 않습니다. 필요한 페이로드를 인라인 base64로 올리는데, 실제로는 약 100MB까지 잘 작동했습니다. 안정화되지 않은 점은 불편하지만, 큰 고객사 대부분은 연결하는 MCP 서버의 80%를 직접 구현합니다. 예상보다 도구 표면과 메타데이터를 조정하기가 덜 부담스러웠습니다.
  • @rcarmo — 업로드를 위해 몇 가지 우회 방법을 구현했고 초안도 돌고 있습니다. 기업용 MCP에서는 대체로 MCP 바깥에서 파일을 처리하고, MCP 도구가 저장소 핸들이나 URL을 넘겨 서버가 안전하게 가져오도록 하는 것 같습니다.
• @wren6991 — LLM이 여러 작업을 조합하고 싶을 때는 bash나 다른 운영체제 셸이라는 완벽한 도구가 있습니다. 직접 도구 호출을 연결하는 Codemode류가 늘 헷갈렸습니다. 모델은 복잡한 파일 편집에서 sed나 Python을 쓰기도 합니다. Codemode를 MCP 조합에 알맞은 도구라고 내세우는 건 거꾸로 아닐까요? 모델에게 이미 그런 도구가 있는데, MCP가 그 도구에 노출되지 않는 게 문제입니다.
  • @hobofan — 서버 측에서 harness를 실행하는 채팅 인터페이스 같은 경우에는 운영체제 셸 접근을 열고 싶지 않은 상황이 많습니다. 공격 표면이 크게 넓어지기 때문입니다.
  • @lelanthran — 맞습니다. 하지만 제한된 사용자 계정으로 대부분의 문제를 완화할 수 있고, 샌드박스를 쓰면 더 줄일 수 있습니다. 남는 취약점 수는 harness 자체의 취약점 수와 비슷할 겁니다. 실제로는 인간의 검토를 거치지 않는 경우가 많으니 더 많을 수도 있습니다.
  • @pjmlp — 클라우드 제품의 오케스트레이션은 보안 장치를 제대로 구성하고 셸 접근 없이 이뤄집니다. 셸 없는 루트리스 불변 컨테이너를 쓰거나, 여러 업체의 SaaS 제품처럼 Web API만 접점으로 두면 됩니다.
• @OleksandrC — 제시한 근거는 약합니다. 결국 Codemode는 harness 안에서 스크립트를 실행해 harness 자체의 도구를 호출하는 방법입니다. 코딩 에이전트는 이미 셸이나 Python, Node 스크립트로 임의의 로직을 조합할 수 있습니다. 제가 보기엔 코어에 넣을 필요가 전혀 없습니다. Pi가 원래 방향에서 벗어난다고 느낀다면 hax를 써 보세요.
• @blamestross — 제가 보기엔 MCP는 “API를 기계가 읽을 수 있게 문서화했다”는 뜻일 뿐입니다. 필요할 때 MCP 서버에서 문서가 붙은 CLI 도구를 생성하면 됩니다.
• @carlsborg — 모델이 도구 호출마다 JSON을 내놓는 대신 도구를 호출하는 코드를 작성한다는 점에서 HuggingFace smolagents와 비슷합니다. 여기서는 모델이 여러 도구, 특히 MCP 도구를 조합할 때 Codemode라는 도구 하나를 호출합니다. 제가 이해한 바로는 그렇습니다.

원문: Earendil / 번역·요약: Trawling