TL;DR

  • Pi는 변화한 MCP와 코드모드(Codemode)의 결합이 도구 조합과 발견을 개선한다고 판단해 MCP를 핵심 기능으로 편입함.
  • MCP를 핵심에 넣은 배경에는 MCP 자체의 변화뿐 아니라, 이를 지원하는 데 필요한 변경이 Jev 등 다른 기능에도 유용하다는 판단이 있음.
  • MCP의 주요 한계는 도구 조합의 어려움이며, 서버들이 여전히 도구를 컨텍스트에 나열하고 텍스트를 반환하는 방식에 치우쳐 있음.
  • Pi의 코드모드는 JavaScript 샌드박스에서 도구 호출을 조율하며, 호출 순서를 유연하게 정하고 여러 도구를 결합하도록 함.
  • Linear 이슈 167건을 Jev로 분석한 예시에서 156건은 중립, 11건은 약한 불만, 강한 불만은 0건으로 분류됨.

상황의 변화

  • 과거 pi.dev에는 Pi가 MCP를 지원하지 않는다는 선언이 있었고, 팟캐스트와 Mario의 게시물에서도 MCP에 대해 부정적인 발언을 했음.
  • 현재 Pi를 업그레이드하면 MCP가 지원 기능으로 포함되어 있으며, 그 배경에는 지난 1년간 달라진 MCP와 Pi 팀의 재검토가 있음.
  • MCP는 확장 기능으로도 제공된 적이 있으며, 핵심 기능으로 편입한 것은 단순히 MCP가 달라졌기 때문만이 아니라 관련 변경을 함께 검토한 결과임.

무엇이 달라졌나

  • MCP를 Pi 핵심에 편입한 이유는 MCP의 변화뿐 아니라, MCP 지원에 필요한 변경이 일반적으로도 유용하다고 판단했기 때문임.
  • MCP를 위해 만든 변경 사항은 Pi에서 Jev를 더 쉽게 사용하는 데도 도움이 됨.
  • Pi와 MCP에 필요한 것은 모두 인터프리터 형태의 샌드박스임.
  • MCP의 여러 부분은 개선됐지만, 도구를 조합하기 어렵다는 가장 큰 문제는 여전히 남아 있음.
  • 도구 호출을 조합할 수 있도록 샌드박스를 제공하는 코드모드도 이 문제를 완전히 해결하지는 못함.
  • 현재 남은 문제는 MCP 자체보다는 MCP 서버와 각 서버를 다루는 하네스의 접근 방식에 더 가까움.
  • 많은 MCP 서버는 도구를 컨텍스트에 그대로 나열하는 하네스를 대상으로 만들어졌으며, 토큰 효율성을 높이려 텍스트를 반환하는 방식에 초점을 둠.
  • Pi가 지향하는 MCP는 지능형 도구 탐색 기능을 갖춘 OpenAPI에 더 가까운 형태임.
  • 도구는 구조화된 데이터를 반환하고, 문서와 설명을 통해 발견 가능해야 함.
  • 명령줄 인터페이스(CLI)가 유용한 이유는 에이전트와 모델이 효율적인 셸 명령으로 기능을 연결하기 때문이며, MCP에서도 이를 구현하지 못할 본질적인 이유는 없음.
  • Pi의 MCP는 Codex 같은 다른 하네스와 마찬가지로 도구를 JavaScript 샌드박스에 노출하는 방식으로 구성됨.

최신 대형 언어 모델에서의 MCP

  • 코드모드만 MCP 없이 구현하지 않은 이유는 Pi의 도구 표현 방식과 관련이 있음.
  • 최근 몇 달 동안 Pi는 도구 지연 로딩, 대화 중 시스템 메시지 삽입, 추론 수준 변경을 지원하는 최신 모델에 맞춰 많은 부분을 개선했지만, 이러한 기능에 맞게 도구 구성을 확장하는 작업은 아직 진행하지 않았음.
  • 코드모드 환경에서는 도구가 대형 언어 모델(LLM)에 직접 제공되는지, 코드모드에서만 제공되는지 결정해야 함.
  • 일반 MCP 확장 기능에는 이 경험을 원활하게 만들 만큼의 도구 메타데이터가 Pi의 도구 구성에 제공되지 않음.
  • 이에 따라 도구를 지연 로딩만 하도록 설정하거나 코드모드 전용으로 지정할 수 있어야 했음.
  • 메타데이터를 연결해 MCP 확장 기능을 개선하는 방식도 가능했지만, MCP와 코드모드를 결합하면 MCP가 기존에 지닌 여러 문제도 해결할 수 있다고 판단함.
  • 현대의 MCP는 과거보다 나은 상태지만 서버와 사용 패턴에는 여전히 개선의 여지가 있음.
  • 이를 지켜보는 데 그치지 않고, 소규모 하네스에서도 잘 작동하도록 논의에 참여하고 발전 방향을 만드는 것이 바람직하다고 봄.

코드모드란

  • 하네스가 도구를 실행하는 위치는 대체로 셸이 실행되는 환경과 하네스 에이전트 루프가 실행되는 환경으로 나뉘며, 두 환경의 신뢰 수준은 다름.
  • 하네스 루프는 신뢰할 수 있는 환경에서 실행되는 경우가 많고, 실행되는 도구는 신뢰도가 낮은 샌드박스 안에 있는 경우가 많음.
  • 코드모드는 하네스가 실행되는 쪽에서 동작하며, 도구 호출을 조율하고 구성하는 메커니즘임.
  • 에이전트가 도구 호출 순서를 유연하게 정하고 JavaScript로 여러 호출을 결합하도록 하는 샌드박스임.
  • 하네스 쪽에서 실행되므로 상태는 파일 시스템이 아니라 세션 기록에 보존됨.
  • 이론상 어떤 언어든 사용할 수 있지만, 작은 JavaScript 런타임을 웹어셈블리(WASM) 바이너리로 제공할 수 있어 JavaScript가 적합함.
  • Pi에서는 MCP를 설정하면 코드모드가 자동으로 로드되며, 기본 도구로 설정에 추가할 수도 있음.
  • Pi에 재구성을 요청해 코드모드를 활성화할 수 있음.
  • 코드모드는 MCP 외의 작업에도 활용 가능함. 예를 들어 Jev를 제공하는 프로바이더에 로그인한 상태에서 Linear MCP와 Jev를 함께 사용해 이슈 트래커에서 불만이 큰 댓글 작성자 20명을 찾도록 요청할 수 있음.
  • 예시 분석은 Linear에서 열린 이슈를 최대 250건 가져오고, 각 이슈의 댓글을 Jev 분류 모델로 평가하는 방식임.
  • 평가 기준은 버그의 심각성이 아니라 작성자의 감정적 어조이며, 중립·약한 불만·강한 불만으로 분류함.
  • 작업자는 네 개의 동시 실행 루프로 이슈를 처리하고 결과를 frustration이라는 이름으로 코드모드에 저장함.
  • 분류 결과에서 약한 불만에는 0.5, 강한 불만에는 1의 가중치를 적용해 점수를 계산하고, 중립이 아닌 이슈를 점수순으로 정렬함.
  • 167건 가운데 156건은 중립, 11건은 약한 불만으로 분류됐으며 강한 불만은 없었음.
  • 명확한 사례는 README 설치 안내가 없다는 불만(PI-6907), 생각 중 Esc를 누른 뒤 Pi가 ‘Working...’ 상태에 멈추는 문제(PI-10031), /update 명령 요청(PI-4714), 긴 세션에서 macOS CPU 사용량이 높은 문제(PI-7730)임.
  • 이슈별 판정 결과는 코드모드의 frustration에 저장되므로, 이슈를 다시 가져오지 않고도 내용을 더 살펴볼 수 있음.

앞으로의 방향

  • Jev와 코드모드 같은 주제는 앞으로 더 다룰 예정이며, 이번 사례는 변화하는 환경에 맞춰 Pi를 신중하게 조정하고 업데이트하는 방식의 예시임.