에이전트가 '발견'을 위해 치르는 비용 — MCP 도구 정의의 토큰 비용을 측정하다

본문

MCP(Model Context Protocol)와 API의 비교를 다룬 이전 글에서 독자가 던진 질문에, 저자가 이번에는 실측 숫자로 답하는 후속 글입니다. 질문의 핵심은 '라이브 MCP discovery 왕복의 토큰 비용과, 미리 큐레이션된 도구 매니페스트를 모델에 건네는 방식을 비교해 손익분기점이 어디인가'였습니다.

문제의 재정의 — 비용은 discovery가 아니라 상주 컨텍스트

저자는 먼저 질문을 답할 수 있게 프레이밍을 교정합니다. 라이브 discovery 왕복은 사실상 무료입니다. MCP 클라이언트는 턴이 아니라 세션당 한 번 tools/list를 호출하고, 돌아오는 페이로드는 수작업으로 큐레이션할 매니페스트와 본질적으로 같습니다. 진짜 비용은 다른 곳에 있습니다. 클라이언트가 어떤 도구를 갖게 되든, 그 정의들이 매 모델 호출마다 컨텍스트에 주입됩니다. 큐레이션된 매니페스트도 이 비용을 똑같이 치릅니다. 따라서 축은 'discovery 대 매니페스트'가 아니라, 컨텍스트에 도구 정의가 몇 개 있고, 얼마나 장황하며, 작업이 몇 번의 모델 호출을 쓰느냐입니다.

측정 방법

하니스는 도구 배열이 모델에 도달하는 형태(JSON: 이름, 설명, 파라미터별 설명을 포함한 입력 스키마)로 직렬화하고 cl100k 토큰을 셉니다. 기준점은 실제 것으로, restaurant 샘플의 세 도구를 Functions MCP 확장이 제공하는 그대로 사용합니다. 그 주위에 search_invoice, approve_claim 같은 합성 엔터프라이즈 도구(파라미터 2~4개)를 세 가지 설명 수준으로 생성합니다. terse(문장 조각), realistic(샘플의 실제 설명을 본뜬 목적·파라미터 안내), verbose(모든 항목에 사용법·예시·엣지 케이스 주석)입니다. 저자는 하니스마다 정의를 약간 다르게 포맷하므로 절대값은 근사치로, 상대 차이는 확실한 것으로 보라는 주의를 덧붙입니다.

숫자

실제 restaurant 서버의 세 도구는 모델 호출당 277토큰입니다. 이 규모에서는 절감할 것이 없어 손익분기가 즉시입니다. 규모가 커지면 그림이 달라집니다. 3개 도구는 terse 209 / realistic 362 / verbose 668토큰, 10개는 596 / 1,040 / 1,972, 30개는 1,856 / 3,233 / 6,089, 100개는 6,370 / 11,132 / 20,814토큰입니다. 성장은 도구 수에 선형이며 절벽 없이 기울기만 있습니다 — 도구당 대략 terse 64, realistic 111, verbose 208토큰입니다. 설명 스타일은 별도의 승수로, 모든 크기에서 verbose는 realistic의 약 1.9배, terse의 약 3.3배입니다.

이 기울기는 세션당이 아니라 작업당으로 복리처럼 쌓입니다. realistic한 도구 100개는 매 호출 11,132토큰이므로, 20회 호출 에이전트 작업은 대화 한 마디와 도구 출력 한 바이트 전에 정의만으로 약 223,000토큰을 지불합니다. 독자가 물었던 큐레이션 비교는 이렇습니다. 그 100개 중 관련 도구 5개를 골라내면 호출당 542토큰, 95% 절감입니다.

손익분기점과 네 가지 선택지

저자의 해석은 이렇습니다. 대략 10개 이하에서는 아무것도 하지 않아도 됩니다. realistic한 도구 30개쯤 되면 호출당 3,200토큰, 작업당 약 65,000토큰으로 fleet 규모에서는 실제 돈이지만 아키텍처 수술을 할 만큼은 아닙니다. 100개에서는 반드시 조치가 필요하고, 이때 큐레이션 매니페스트는 네 가지 선택지 중 가장 거친 방법일 뿐입니다. 큐레이션 매니페스트는 정적 도구 선택으로, 어떤 다섯 도구가 중요한지 설계 시점에 결정해 컨텍스트의 95%를 절약하는 방식인데, 이는 MCP가 피하려던 설계 시점 지식의 가정 그 자체입니다. 나머지 대안은 discovery를 유지하면서 비용을 줄입니다. 서버를 도메인별로 쪼개 에이전트가 '만능 서버'가 아니라 invoice 서버나 shipment 서버에 접속하게 하는 방법, 정의를 지연 로딩하고 필요할 때 검색하는 클라이언트를 쓰는 방법(점점 더 많은 에이전트 런타임이 채택), 그리고 100개의 리소스 단위 연산을 15개의 태스크 단위 도구로 묶는 거친 입도의 intent-sized 도구 설계가 있습니다.

이전 글과의 긴장 관계

첫 글은 도구 설명이 구조적으로 중요하다, 모호한 텍스트는 모호한 에이전트를 만든다고 주장했고, 이번 글은 단어가 돈이라고 말합니다. 둘 다 참이며 숫자가 균형점을 보여줍니다. 도구당 약 25단어의 realistic 설명은 111토큰으로, 올바른 도구를 고르고 오류에서 회복하는 에이전트의 대가로 지불할 가치가 있습니다. verbose 단계는 모델이 어차피 추론할 산문으로 청구서를 두 배로 만듭니다. 저자가 얻은 예산 규칙은, 설명 토큰은 도구 간 구분과 식별자의 출처 안내에 쓰고 의례적 문장에는 쓰지 말라는 것입니다.

측정하지 않은 것

도구 100개에서 모델이 10개일 때보다 올바른 도구를 덜 고르는지, 즉 선택 정확도는 측정하지 않았습니다. 이는 실제 모델, 다수 실행, 정답 도구 시퀀스가 있는 스크립트 작업이 필요해 별도 글의 주제입니다. 하니스와 데이터는 저장소의 measure/에 있으며 python token_cost.py로 직접 검증할 수 있습니다.

원문: dev.to / 번역·요약: Trawling