MCP 도구 정의의 토큰 오버헤드 측정 및 CLI를 통한 최적화 방법

핵심 요약

MCP의 과도한 JSON 스키마 토큰 오버헤드를 해결하기 위해 CLI 기반의 지연 로딩 방식을 도입하여 토큰 사용량을 최대 98% 절감한 사례이다.

배경

MCP 서버를 다수 운영할 때 발생하는 수만 개의 토큰 오버헤드 문제를 해결하기 위해, 모든 스키마를 미리 로드하는 대신 CLI를 통해 필요할 때만 도구 정보를 가져오는 방식을 제안했다.

의미 / 영향

이 토큰 최적화 사례는 MCP 표준의 한계를 실무적인 관점에서 해결하는 방법을 제시한다. 특히 에이전트의 도구 사용량이 늘어날수록 CLI 기반의 지연 로딩 방식이 비용 절감과 추론 정확도 향상에 기여할 것임이 확인됐다.

커뮤니티 반응

작성자가 직접 측정한 구체적인 수치와 해결책을 제시하여 실무적인 도움을 주는 게시물이다.

주요 논점

01찬성다수

MCP의 정적 스키마 로딩은 비효율적이며 CLI를 통한 동적 조회가 비용과 성능 면에서 우월하다.

합의점 vs 논쟁점

합의점

대규모 도구 환경에서 JSON 스키마 덤프는 컨텍스트 오염과 비용 상승의 주범이다.

실용적 조언

MCP 서버가 많아질 경우 모든 스키마를 프롬프트에 넣지 말고 도구 목록만 먼저 제공하라.
clihub를 사용하여 MCP 도구를 CLI로 변환하여 토큰을 절약하라.

전문가 의견

대규모 도구 환경에서 JSON 스키마 덤프는 컨텍스트 오염과 비용 상승의 주범이므로 지연 로딩이 필수적이다.

언급된 도구

MCP (Model Context Protocol)중립

모델과 외부 도구 간의 통신 규격

clihub추천링크

MCP를 CLI로 변환해주는 오픈소스 도구

섹션별 상세

MCP의 구조적 문제로 인한 토큰 낭비가 심각한 수준이다. 일반적인 MCP 설정인 6개 서버와 84개 도구를 사용할 경우, 에이전트가 첫 번째 도구를 호출하기도 전에 약 15,500토큰의 JSON 스키마가 컨텍스트에 주입된다. 이는 모델의 컨텍스트 윈도우를 불필요하게 점유하며, 특히 긴 대화 세션에서 비용 효율성을 급격히 떨어뜨리는 주요 원인이다.

CLI 기반 지연 로딩(Lazy Loading) 방식은 효율적인 대안이다. 모든 도구의 상세 스키마를 미리 로드하는 기존 방식 대신, 약 300토큰 분량의 가벼운 도구 이름 목록만 에이전트에게 먼저 제공한다. 에이전트는 특정 도구의 상세 기능이 필요할 때만 --help 명령어를 실행하여 약 600토큰 분량의 상세 레퍼런스를 동적으로 확인하는 구조이다.

다양한 사용 패턴에 따른 성능 및 비용 비교 수치가 이를 증명했다. 세션 시작 시 MCP는 15,540토큰을 소모하는 반면 CLI 방식은 300토큰만 사용하여 약 98%의 절감 효과를 기록했다. 100번의 도구 호출이 발생하는 상황에서도 CLI 방식은 1,504토큰만 사용하여 MCP(18,540토큰) 대비 92% 이상의 높은 효율성을 유지했다.

Anthropic의 Tool Search 기능과 비교하여 CLI 방식의 범용성이 우수하다. Anthropic의 지연 로딩 방식인 Tool Search도 원본 MCP보다는 낫지만, 데이터를 가져올 때마다 여전히 전체 JSON 스키마를 끌어오는 한계가 존재한다. 반면 CLI 방식은 토큰 소모가 더 적을 뿐만 아니라 특정 클라우드 제공자의 API에 종속되지 않고 로컬이나 다양한 환경에서 범용적으로 사용 가능하다.

실무 Takeaway

MCP 도구 정의 방식은 대규모 도구 세트 운영 시 심각한 토큰 오버헤드를 유발한다.
CLI 기반의 지연 로딩 전략을 통해 초기 컨텍스트 비용을 98%까지 절감할 수 있다.
도구 이름 목록만 먼저 제공하고 상세 정보는 필요 시점에 조회하는 방식이 효율적이다.
오픈소스 도구 clihub를 통해 기존 MCP 서버를 CLI 형태로 변환하여 토큰을 최적화할 수 있다.

언급된 리소스

GitHubclihub GitHub Repository