Pi.dev MCP 통합 및 Codemode 도입

Pi.dev는 모델 컨텍스트 프로토콜(MCP)을 핵심 기능으로 공식 통합하며, 이전에 프로토콜에 반대했던 공개 입장을 전환했다. 이 전환은 MCP의 진화와 도구 호출을 더 견고하게 조율할 수 있는 메커니즘의 필요성에 기인하며, Pi는 이를 해결하기 위해 도구 조율을 위한 자바스크립트 기반 사전 환경인 "Codemode"를 도입했다.

핵심 기능으로의 MCP 통합

Pi는 MCP를 선택적 확장에서 핵심 기능으로 이동시켰다. MCP를 지원하기 위해 필요한 아키텍처적 변경이 전체 시스템에 일반적으로 유용하다는 점이 확인되었기 때문이다. 특히, 통합은 Pi 내에서 Jev 사용을 더 쉽게 만들며, MCP와 Pi 모두가 필요로 하는 인터프리터 사전 환경을 제공한다.

Pi는 MCP가 여전히 조합(composition) 측면에서 도전 과제를 겪고 있음을 인정하지만, 팀은 현재 프로토콜의 상태가 이전 버전보다 상당히 개선되었다고 본다. Pi의 MCP 접근 방식은 OpenAPI와 유사하게, 도구가 구조화된 데이터를 반환하고 문서화 및 설명을 통해 탐색 가능한 지능적인 도구 탐색을 강조한다.

Codemode: 새로운 조율 계층

Codemode는 도구 측(바시나 기타 외부 프로세스가 실행되는 곳)이 아닌 하네스 측(에이전트 루프가 존재하는 곳)에서 실행되는 자바스크립트 사전 환경이다. 이는 도구 호출을 조율하고 조정하는 메커니즘으로, 에이전트가 자바스크립트를 사용해 여러 도구를 더 유연한 순서와 실행 방식으로 결합할 수 있도록 한다.

Codemode의 주요 기술적 특성

  • 실행 환경: 하네스가 실행되는 곳에서 실행되며, 세션 전사본의 일부로 상태가 유지되며 로컬 파일 시스템에 저장되지 않는다.
  • 구현: WASM 바이너리로 제공되는 작은 자바스크립트 버전을 사용하여 보호성과 성능 사이의 균형을 맞춘다.
  • 자동 로딩: MCP가 구성되면 Codemode가 자동으로 로드되지만, Pi의 구성을 통해 기본 도구로도 활성화할 수 있다.
  • 목적: 직접적인 JSON/XML 도구 호출(안전하지만 제한적)과 바시 실행(강력하지만 내재된 보안 및 타입 체크가 부족) 사이의 중간 지점 역할을 한다.

조합 문제 해결

MCP와 함께 Codemode를 도입한 주요 이유 중 하나는 MCP와 관련된 전통적인 조합 문제를 해결하는 것이다. 자바스크립트 사전 환경을 사용함으로써 Pi는 모델이 도구를 더 효과적으로 연결할 수 있도록 한다. 예를 들어, 사용자가 "Codemode를 통해 typesafe/jev를 사용하여 이슈 트래커에서 가장 좌절한 20명의 사용자를 찾아줘"라고 요청하면, 시스템은 Linear MCP와 Jev를 결합해 분석을 수행하면서 컨텍스트를 낭비하지 않는다.

커뮤니티의 시각과 기술적 논쟁

이 발표는 개발자 커뮤니티 내에서 MCP와 전통적인 CLI 기반 도구 사용의 장단점에 대한 기술적 논쟁을 촉발했다.

MCP 및 Codemode에 대한 지지 주장

  • 상호 운용성: 일부 개발자는 MCP가 USB-C와 유사한 광범위한 호환성 생태계를 제공하며, 몇몇 최적화된 고유 솔루션보다 넓은 채택이 더 가치 있다고 주장한다.
  • 반복적 개발: 에이전트는 하드코딩된 스크립트보다 인터페이스 변경에 더 관용적이므로, 개발자는 도구 인터페이스를 더 빠르게 반복 개발할 수 있다.
  • MCP를 구성 도구로 사용: 사용자들은 자연어를 통해 기존 앱 로직을 활용해 복잡한 macOS 애플리케이션을 구성하는 데 MCP를 사용했다고 보고하며, 모델이 복잡한 코드를 처음부터 작성할 필요 없이 기존 로직을 활용할 수 있다고 강조한다.

반대 및 대안 제안

  • Codemode의 불필요성: 일부 비평가들은 LLM이 이미 바시나 파이썬 스크립트를 사용해 도구를 효과적으로 연결할 수 있으므로 Codemode가 불필요하다고 주장한다.
  • 프로토콜 비판: 일부 사용자는 MCP가 REST API나 OpenAPI의 대체물에 불과하며, 왜 처음부터 표준 HTTP 프로토콜로 시작하지 않았는지 묻는다.
  • 복잡성: 핵심 통합으로의 전환은 이전에 간단하고 확장 가능한 하네스에 "부담"을 추가한다는 우려가 있다.

"사람들이 저지른 주요 실수는 자신의 워크플로우와 로컬 스택을 고려하는 것이 아니라, 팀의 워크플로우와 팀의 운영 스택을 고려하지 않았다는 점이다." — @CharlieDigital

Sources

관련