에이전트가 기본적으로 모든 도구 스키마를 로드합니다. 어떤 것을 보여줄지 결정하세요.

에이전트 설정을 변경하기 전에 두 가지 질문에 답하십시오.

# 1. 콜드 스타트 시 하네스가 몇 개의 프롬프트 토큰을 전송합니까?
# 2. 그 토큰 중 도구 스키마는 몇 개입니까?
# 문자 수를 세지 말고, 제공업체의 토크나이저로 측정하십시오.

대부분의 팀은 이 두 질문에 답할 수 없습니다.
그 이유는 정보가 얻기 어렵기 때문이 아닙니다. 누가 소유할지 아무도 결정하지 않았기 때문입니다.

2026년 10월 1일, Earendil이 Pi 1.0을 출시했습니다. 릴리스 노트에는 일곱 가지 추가 사항이 나열되어 있습니다. 그중 두 가지는 여러분이 이미 정해졌다고 생각했을지 모르는 결정을 변경합니다.

• 지연 도구 로딩 (Deferred tool loading)
• 모델이 도구 호출을 구성하는 JavaScript 샌드박스인 Codemode

둘 다 도구 가시성을 도구별 설정으로 바꿉니다. 이것이 이 게시물의 핵심이며, 보이는 것보다 더 큰 변화입니다.

무엇이 바뀌었고, 무엇이 바뀌지 않았는가

Pi는 MCP가 필요하지 않다고 말하는 데 1년을 보냈습니다. 랜딩 페이지에서도 명확히 했고, 제작자는 해당 프로토콜이 불필요하다고 주장하는 게시물을 작성했습니다. 그러다가 1.0 버전에서 네이티브 MCP 지원이 출시되었고, Earendil은

그 비용은 세 가지 측면에서 나타납니다.

금전적 비용(Money). 모든 요청마다 토큰에 대한 비용을 지불해야 합니다.

주의력(Attention). 긴 도구 목록은 모델이 매 턴마다 지나쳐 읽어야 하는 노이즈입니다. 도구가 많다는 것은 잘못된 것을 선택할 가능성이 더 높다는 의미입니다.

재현성(Reproducibility). 결과가 실행 간에 변경될 때, 가장 먼저 의심하는 것은 종종 모델 자체가 아니라 도구 세트입니다.

Pi는 자체 codemode 변경에 대한 수치를 보고합니다. 변경 로그에는 요청이 약 5,300 토큰에서 3,300 토큰으로, 즉 약 40% 감소한 예시가 있습니다. 이것은 벤치마크가 아니라 단일 구성에서의 공급업체(vendor) 예시입니다. 숫자가 아닌 형태(shape)로 이해하십시오.

세 가지 노출 방식과 각 방식이 적절한 경우

Pi의 메타데이터는 도구를 세 가지 중 하나로 만듭니다. 선택은 도구별로 사용자의 몫입니다.

직접(Direct). 모델이 스키마를 보고 스스로 호출합니다. 가장 많은 턴에 사용되는 도구에 이 방식을 사용하십시오.

지연(Deferred). 작업이 요구할 때만 도구가 선언됩니다. 가끔 사용하는 전문 API와 같은 긴 꼬리(long tail) 영역에 이 방식을 사용하십시오.

codemode 전용(Codemode only). 모델은 스키마를 절대 보지 못합니다. 대신 샌드박스 내부에서 도구를 호출하는 코드를 작성합니다. 출력물이 모델이 읽기 전에 필터링되어야 하거나, 도구가 다른 것들과 조합될 때만 유용한 경우에 이 방식을 사용하십시오.

세 번째 방식은 컨텍스트에 도달하는 내용 자체를 변화시키기 때문에 흥미롭습니다. Earendil의 데모에서는 스크립트가 Linear MCP 서버에서 이슈를 가져와 댓글에 대해 분류기(classifier)를 실행하고 순위가 매겨진 목록을 반환합니다. 수백 개의 도구 호출이 발생하며, 컨텍스트 창은 그 요약본을 보게 됩니다.

무언가를 조정하기 전에 감사(audit)하십시오

도구를 재배열하는 것부터 시작하지 마십시오. 측정하는 것부터 시작하십시오.

하네스(harness)가 도구가 로드된 상태와 로드되지 않은 상태에서 콜드 스타트 시 보내는 프롬프트 토큰 수를 세어보십시오. 그 차이가 세금입니다. 문자 수로 추정하여 하는 것이 아니라, 실제 요청을 통해 공급업체의 토크나이저(tokenizer)를 사용하여 측정하십시오. 왜냐하면 스키마는 대부분 구두점(punctuation)으로 이루어져 있어 사용자의 추정치는 자신에게 유리한 방향으로 틀릴 가능성이 높기 때문입니다.

그런 다음 모든 도구를 세 개의 버킷 중 하나로 분류하고 목록을 작성하세요. 아무것도 바꾸지 않더라도 이 연습은 가치가 있습니다. 왜냐하면 아무도 분류할 수 없는 도구들이 프롬프트를 조용히 부풀리고 있기 때문입니다.

가장 많은 경우를 해결하는 두 가지 질문이 있습니다:

• 모델이 이름으로 이 도구를 선택해야 합니까? 그렇지 않다면, 코드를 모드(codemode) 또는 지연(deferred)에 속합니다.
• 얼마나 자주 호출됩니까? 빈번하다는 것은 직접적(direct)을 의미하고, 드물다는 것은 지연적(deferred)을 의미합니다.

codemode가 해결하지 못하는 것들

Earendil은 이 부분에 대해 매우 솔직하니, 설정을 재작성하기 전에 주의 사항을 읽어보아야 합니다.

문제는 주로 서버 측에 있습니다. 많은 MCP(Multi-Cloud Platform) 서버들은 모든 도구 스키마를 컨텍스트에 덤프하는 하네스(harnesses)를 위해 구축되었기 때문에, 구조화된 데이터보다는 토큰 수에 최적화된 텍스트 블롭을 반환합니다. 하네스 측의 샌드박스는 구성(composition)이 실행되는 곳을 바꿀 뿐입니다. 이는 하네스가 도구를 요청할 때 서버가 컨텍스트에 무엇을 넣는지 바꾸지 못합니다.

Earendil 자신의 관점은 MCP가 지능형 도구 발견 기능을 갖춘 OpenAPI와 더 가깝게 보여야 한다는 것입니다: 구조화된 반환값, 문서화를 통해 발견 가능한 도구들입니다. 이것이 구현될 때까지는 사용자가 직접 서버를 측정하고 있는 것입니다.

따라서 실질적인 순서는 다음과 같습니다: 노출을 줄이고, 서버를 제어할 수 있는 곳에서는 산문(prose) 대신 구조를 반환하세요.

제가 확신하지 못하는 부분들

저는 이 벤치마크들을 실행해 보지 않았습니다. 40%라는 수치는 Pi의 자체 변경 로그 예시이며, 데모 숫자는 공급업체의 게시물에서 가져온 것입니다. 제가 한 것은 세 가지 노출 모델을 질문할 가치가 있는 설계 문제로 다루는 것이었습니다. 왜냐하면 불필요한 스키마의 비용은 모든 요청마다 지불되고, 누락된 도구의 비용은 단 한 번만 지불되기 때문입니다.

프로덕션 환경에서 이 내용을 신뢰하기 전에 제가 원하는 두 가지가 있습니다: 저 자신의 하네스에서 가져온 첫 번째 요청의 토큰 수, 그리고 모델을 고정(pinned)한 상태에서 고정된 작업에 대한 전후 비교입니다.

출처

출처

• Pi 1.0 release post, Earendil, 2026년 10월 1일. [https://earendil.com/posts/pi-1-0/]
• You Said No, MCP!, Earendil engineering blog, 2026년 9월 말. [https://earendil.com/posts/you-said-no-mcp/]
• Pi 1.0 release guide, Developers Digest, 2026년 10월 2일. 보조적인 내용입니다. 설치 명령어와 서버별 자격 증명(credential) 세부 사항에 사용되었습니다.
• The Register, MCP 역전(reversal) 관련 보도, 2026년 10월 2일.

본 게시물은 AI의 도움을 받아 작성되었습니다. 저자가 내용에 대한 책임을 집니다.

동일한 결정의 권한 측면

가시성(Visibility)과 권한(Authority)은 같지 않으며, 릴리스는 이 두 가지를 동시에 변경할 수 있습니다.

Pi 1.0은 또한 MCP에 대한 OAuth 기능을 강화했습니다: 자격 증명은 서버 이름 및 URL별로 저장되며, 발급자 확인(issuer checks)은 RFC 9207을 따르고, 단계적 로그인(step-up sign-in)은 서버가 이미 부여받았던 스코프를 유지합니다. 이것들은 실제적인 개선 사항이며 인증 조치입니다. 하지만 특정 커넥터가 신뢰할 만한지 여부를 알려주지는 않으며, 도구 결과 내부로 도착하는 적대적인 지침에 따라 모델이 행동하는 것을 막아주지도 않습니다.

개별 검토 시 이 두 가지를 분리하여 다루십시오. 서버별로 다음을 질문하십시오: 이것은 무엇에 접근하도록 허용되었는가, 그리고 누가 이를 설치하는 것을 승인했는가? 좁은 읽기(read) 전용으로 활성화한 커넥터라도 여전히 모델이 호출할 수 있는 커넥터입니다.

이는 또한 '노출을 줄여라(expose less)'가 비용 문제일 뿐만 아니라 안전 조치인 이유이기도 합니다.

기록해 둘 만한 또 다른 점: 감사(audit)에는 두 번째 출력이 있습니다. 도구들이 정리되면, 사용 방식의 형태가 가시화되며, 이는 어떤 단일 도구를 먼저 수정해야 하는지 알려줍니다. 대부분의 팀에게 문제는 모델 자체가 아닙니다. 마감 기한 때문에 추가되었고, 여전히 활성화되어 있으며, 스키마를 로드하고 있지만 거의 사용되지 않는 그 커넥터입니다.

모델이 볼 수 없는 도구는 실수로 호출할 수도 없는 도구입니다.