“MCP를 지원하지 않는다니!”

과거에 pi.dev에 방문했다면, Pi가 MCP를 지원하지 않는다는 자랑스러운 선언을 보았을 것입니다. 저희가 Pi에 대해 이야기한 팟캐스트를 들어보셨다면, MCP에 대한 여러 번의 무시하는 듯한 발언들을 접했을 것입니다. 마리오가 작성한 게시글도 포함해서 말이죠. 그런데도 불구하고, 만약 Pi를 업그레이드한다면 MCP가 이제 지원되는 기능임을 발견하게 될 것입니다. 무슨 일이 일어난 걸까요?

변화하는 것들

우선 기억해야 할 첫 번째 사실은 세상이 정적이지 않다는 것입니다. 저희는 지난 1년 동안 MCP에 주목해 왔으며, 오늘날의 MCP는 어제의 MCP와 같지 않습니다. 이것만으로는 핵심 기능으로 포함시키기에 충분한 이유는 아닐 것입니다. 하지만 아시다시피 Pi는 훌륭한 확장 생태계를 가지고 있으며, 당연히 MCP도 하나의 확장 기능이었을 수 있습니다? 심지어 Earendil이 보증하는 확장 기능일 수도 있었죠. 그리고 네, MCP가 확장 기능일 수 있었다는 점은 당신의 말이 맞습니다. 실제로 그랬기도 했습니다. 그런데 이 MCP가 이제 핵심 기능의 일부가 된 것은 저희가 머리를 맞대고 재고한 결과입니다.

정확히 무엇이 바뀌었을까요?

저희가 MCP를 핵심 기능으로 가져온 이유는 단순히 MCP 자체가 어떻게 변했는지 때문만은 아닙니다. 또한 그 변화가 요구하는 것들이 일반적으로 유용하다는 것을 발견했기 때문이기도 합니다. 예를 들어, 저희가 MCP에 적용한 변경 사항들은 Pi 내에서 Jev 사용을 더 쉽게 가능하게 합니다. 궁극적으로 Pi가 필요로 하는 것은 MCP가 필요로 하는 것과 매우 유사합니다. 즉, 인터프리터의 형태로 가지고 놀 수 있는 샌드박스입니다.

MCP에 대해 많은 것이 개선되었지만, 여전히 해결되지 않은 문제들도 많습니다. 가장 큰 문제는 MCP가 조합하기 어렵다는 점이 계속 남아 있습니다. 도구 호출(tool calls)을 조합할 수 있게 해주는 깔끔한 작은 샌드박스인 codemode를 사용하더라도, MCP는 이 부분을 완전히 충족시키지 못합니다. 하지만 지금 시점에서는 그것이 MCP의 문제가 아니라, 존재하는 MCP 서버들과 그 서버들을 다루기 위한 다양한 접근 방식(harnesses)의 문제입니다.

많은 MCP 서버들은 여전히 컨텍스트에 도구들을 단순히 덤프(dump)하는 하네스(harnesses)를 위해 구축되었으며, 텍스트를 반환함으로써 자체적으로 토큰 효율성을 최적화하려고 합니다. 현재 시점에서 우리가 생각하기에 MCP는 지능형 도구 발견(intelligent tool discovery)을 가진 OpenAPI와 훨씬 가까워야 합니다. 이는 도구들이 구조화된 데이터(structured data)를 반환해야 하며, 도구들은 그 문서와 설명에 의해 발견 가능해야 함을 의미합니다.

CLI가 매우 기능적인 이유는 에이전트와 모델이 효율적인 bashism으로 것들을 연결하기 때문입니다. 하지만 MCP로도 그렇게 할 수 없다는 근본적인 이유가 없습니다. Pi의 MCP는 다른 하네스들(예: Codex)처럼 도구들을 JavaScript 샌드박스에 노출하는 것에 기반하여 구축되었습니다.

최신 LLM에서의 MCP

이것은 왜 우리가 MCP 없이 Codemode를 구현하지 않았는지라는 질문을 제기할 것입니다. 이에 대한 답변의 일부는 오늘날 Pi에서 도구들이 표현되는 방식과 관련이 있습니다. 우리는 최근 몇 달 동안 Pi가 지연된 도구 로딩(deferred tool loading), 대화 중간 시스템 메시지, 추론 수준 변경을 허용하는 새로운 모델들과 의미 있게 작동하도록 많은 작업을 수행했습니다. 하지만 아직 우리의 도구 구성(tool loadout)을 이러한 새로운 기능들에 더 잘 확장할 수 있도록 업그레이드하지는 못했습니다.

Codemode 세계에서는 해당 도구가 LLM에 사용 가능한지 아니면 Codemode 부분의 LLM에만 사용 가능한지를 결정해야 합니다. 일반적인 MCP 확장은 Pi의 도구 구성에서 충분한 메타데이터를 가지고 있지 않아 그 경험을 잘 작동시키기 어렵습니다. 그래서 우리는 도구들이 지연되도록(deferred) 설정되거나 Codemode 전용으로 설정될 수 있도록 보장할 필요가 있었습니다.

그리고 메타데이터를 연결하여 더 나은 MCP 확장을 가능하게 할 수도 있었지만, 우리는 Codemode와 함께하는 MCP가 전통적으로 가지고 있던 여러 문제들을 해결한다고 생각합니다. 무언가에 긍정적인 영향을 미칠 수 있는 가장 좋은 방법은 그것을 포용하는 것이라고 믿습니다. 현대의 MCP가 과거보다 훨씬 나아진 위치에 있다고 생각하지만, 서버와 패턴에는 여전히 개선할 여지가 남아 있습니다. 따라서 우리는 그 대화에 참여하여 옆에서 지켜보는 대신 잘 작동하도록 만드는 데 도움을 주고 싶습니다.

Codemode란 무엇인가?

지금까지 Codemode에 대해 너무 많이 이야기했기 때문에, 그것이 정확히 무엇인지 설명할 가치가 있을 수 있습니다. 하네스(harness)가 도구를 실행할 때, 대부분 두 가지 측면을 가지고 있습니다. bash가 실행되는 곳에서 할 수도 있고, 하네스 에이전트 루프(agent loop)가 실행되는 곳에서 할 수도 있습니다. 양쪽의 신뢰 수준은 매우 다릅니다. 하네스 루프는 종종 신뢰할 수 있는 환경에서 실행되는 반면, 실행하는 도구들은 실제로 그다지 신뢰할 수 없는 샌드박스 내에서 실행되는 경우가 많습니다.

Codemode가 특별한 점은 하네스가 실행되는 곳에서 실행된다는 것입니다. 이는 도구 호출을 오케스트레이션(orchestrate)하고 조정(coordinate)하는 메커니즘으로 이해하는 것이 가장 좋습니다. 이는 에이전트가 어떤 순서로 도구 호출을 수행할지에 대해 더 많은 유연성을 제공하는 방식으로 해당 호출을 발행할 수 있게 해주는 샌드박스이며, 이를 통해 JavaScript를 사용하여 이들을 결합할 수 있습니다. Codemode 역시 하네스 측에서 실행되기 때문에, 그 상태는 파일 시스템이 아닌 세션 트랜스크립트(session transcript)의 일부로 유지됩니다.

이론적으로는 어떤 언어든 할 수 있지만, JavaScript가 매우 매력적인 이유는 JavaScript의 작은 버전들을 WASM 바이너리(binary)로 배포할 수 있고 합리적인 수준의 보호를 허용하기 때문입니다.

Pi에서 Codemode는 MCP가 구성되면 자동으로 로드되거나, 설정에 기본 도구로 추가할 수 있습니다. pi에게 스스로 재구성하도록 요청하여 codemode를 활성화하세요! 그러면 MCP뿐만 아니라 상당히 흥미로운 일에도 사용할 수 있습니다. 예를 들어 “Jev”를 제공하는 프로바이더로 로그인한 경우 다음과 같은 작업을 수행할 수 있습니다:

우리 이슈 트래커에서 가장 좌절감을 느끼는 댓글 작성자 20명을 찾기 위해 typesafe/jev를 codemode로 사용합니다.

그러면 Linear MCP와 Jev 같은 것들을 결합하여, 컨텍스트를 전혀 낭비하지 않고 Pi 내부에서 바로 분석을 수행합니다.

우리 이슈 트래커에서 가장 좌절감을 느끼는 사람들을 찾기 위해 typesafe/jev를 codemode로 사용하겠습니다. Linear에서 오픈된 이슈들을 가져와서 Jev가 각 스레드의 어조를 4개씩 평가하게 합니다. codemode const { issues } = await tools.mcp__linear__list_issues({ team: "Pi", state: "open", limit: 250, }); const jev = await models.getModelOfType( "classifier", "cloudflare-workers-ai", "typesafe/jev", ); const questions = { frustration: { type: "choice", instructions: "작성한 사람의 감정적인 어조만 판단하세요. 버그가 얼마나 심각한지는 무시하세요.", criteria: { none: "중립적, 사실적이거나 친근함, 심각한 버그에 대한 것일지라도", mild: "명백한 짜증, 성급함 또는 실망감", high: "분명히 화나거나, 지치거나, 비꼬는 등", }, }, }; const results = []; let next = 0; async function worker() { while (next < issues.length) { const issue = issues[next++]; const { comments } = await tools.mcp__linear__list_comments({ issueId: issue.identifier, }); const c = await models.classify(jev, { state: { ...issue, comments }, questions }); results.push({ id: issue.identifier, title: issue.title, ...c.answers.frustration }); } } await Promise.all([worker(), worker(), worker(), worker()]); store("frustration", results); const score = (r) => r.probabilities.mild * 0.5 + r.probabilities.high; const counts = {}; for (const r of results) counts[r.choice] = (counts[r.choice] ??

가장 많은 이슈 추적기(tracker)는 평온합니다. Jev는 167개의 열린 이슈 중 156개를 '중립(neutral)'으로, 11개를 '약간 좌절함(mildly frustrated)'으로 평가했으며, '매우 좌절함(highly frustrated)'은 없었습니다. 가장 명확한 사례들은 다음과 같습니다:

• PI-6907 README에 설치 섹션 없음 (“짜증남”)
• PI-10031 생각하는 도중 Esc를 누른 후 Pi가 “Working...” 상태에서 멈춤
• PI-4714 /update 명령어 요청 (“귀찮음”)
• PI-7730 긴 세션 동안 macOS에서 높은 CPU 사용률
  이러한 이슈별 평가는 frustration라는 이름으로 codemode에 저장되어 있어, 다시 이슈를 가져오지 않고도 언제든지 깊이 파고들 수 있습니다.

나중에 Jev와 Codemode 같은 것들에 대해 더 이야기할 예정이지만, 이 게시물이 세상이 계속 진화함에 따라 우리가 어떻게 Pi를 사려 깊게 적응하고 업데이트하는지에 대한 예시가 되기를 바랍니다.