MCP vs 직접 API 호출 측정: 아무도 알려주지 않는 토큰 계산법

MCP가 주목받고 있습니다. 모든 에이전트 프레임워크가 이를 통해 도구(tools)를 연결하고 있으며, 여기에는 타당한 이유가 있습니다. 표준화된 도구 등록, 조합 가능한 서버, 그리고 프로젝트마다 플러그인 시스템을 새로 만들 필요가 없는 프로토콜 덕분입니다. 그 매력은 충분히 이해합니다.

하지만 제가 예상하지 못했던 것은 토큰 비용이었습니다.

저를 멈칫하게 만든 수치는 다음과 같습니다. 단순한 SerpApi 검색을 수행할 때, MCP 에이전트는 호출당 6,047개의 토큰을 사용했습니다. 정확히 동일한 작업을 수행하는 CLI 스크립트는 351개의 토큰을 사용했습니다. 동일한 검색 결과에 대해 17배의 오버헤드(overhead)가 발생한 것입니다.

그 이후로 다른 데이터 포인트들을 찾아보았습니다. 그 범위는 제가 생각했던 것보다 더 넓었습니다.

이 모든 것의 시작이 된 수치: 호출당 17배의 토큰

이 벤치마크는 필드 프로젝션(field projection)을 사용하는 CLI 에이전트와 SerpApi MCP를 측정한 포스트에서 가져왔습니다. 두 방식 모두 웹을 검색하고 결과를 반환하는 동일한 작업을 수행합니다. 차이점은 다음과 같습니다:

방식	호출당 토큰 수
MCP 에이전트	6,047
...

대화형 인터페이스에서 하루에 10번 검색한다면 호출당 6,047개의 토큰은 괜찮습니다. 하지만 자동화된 파이프라인(pipeline)에서 하루에 1,000번 검색한다면, 351,000개면 충분할 상황에서 600만 개의 토큰을 태우게 됩니다.

이것은 단순한 반올림 오차가 아닙니다. 청구서에 찍히는 항목입니다.

발생하는 이유: 매 메시지마다 발생하는 스키마 주입 (schema injection)

오버헤드는 API 호출 자체에서 발생하는 것이 아닙니다. 호출이 일어나기 전, AI 호스트가 매 메시지에 주입해야 하는 내용에서 발생합니다.

MCP 서버를 등록하면, 모든 도구 정의(이름, 설명, 입력 스키마, 파라미터 타입)가 직렬화되어 대화의 모든 시스템 프롬프트(system prompt)나 어시스턴트 메시지에 주입됩니다. LLM은 자신이 무엇을 호출할 수 있는지 알기 위해 매 턴마다 사용 가능한 모든 도구를 "보아야" 합니다.

구체적인 예시: 간단한 리포지토리 언어 체크입니다. 작업 자체는 사소합니다. 하지만 토큰 수는 사소하지 않습니다.

접근 방식 (Approach)	토큰 수 (Tokens)
CLI 에이전트 (직접 API 호출)	1,365
MCP 에이전트 (동일 작업)	44,026

추가된 42,661개의 토큰은 모든 메시지에 주입된 43개의 도구 정의 (tool definitions) 때문입니다. 이 도구들은 리포지토리 언어 체크와 아무런 관련이 없는 것들이었습니다. 에이전트가 해당 MCP 서버에 43개의 도구를 등록해 두었을 뿐이며, 그중 모든 도구가 여정에 함께 올라탄 것입니다.

전체 벤치마크 상세 분석 (4배에서 32배 범위)

"17배"가 헤드라인이지만, 실제 범위는 다음 요소에 따라 4배에서 32배 사이입니다:

• 서버에 등록된 도구의 개수
• 해당 도구 스키마 (tool schemas)의 복잡도
• 대화가 진행되는 턴 (turns) 수
• 배치 작업 (batch jobs)을 실행하는지 또는 대화형 쿼리 (interactive queries)를 실행하는지 여부

4배의 하한선은 단순한 스키마를 가진 작은 서버와 짧은 세션의 경우입니다. 32배의 상한선은 수십 개의 복잡한 도구를 가진 대형 서버에서 다단계 파이프라인 (multistep pipeline)을 실행할 때이며, 이때 스키마 주입 (schema injection)이 모든 메시지에 걸쳐 복리로 작용합니다.

중요한 점은 최소한의 오버헤드(overhead)가 4배라는 것입니다. 아주 최소한의 MCP 설정이라 할지라도 직접 API 호출에는 없는 오버헤드가 발생합니다.

하루 $270의 놀라운 결과: 대규모 환경에서의 미사용 도구 정의

이 부분이 실제 프로덕션 파이프라인 (production pipelines)에서 진정으로 경각심을 불러일으키는 지점입니다.

Claude Sonnet 가격 기준으로, 사용되지 않는 스키마 오버헤드 90,000토큰은 요청당 약 $0.27의 비용이 발생합니다. 만약 파이프라인이 하루에 1,000번 실행된다면, 에이전트가 전혀 사용하지 않는 도구 정의만으로 하루에 $270를 지불하게 됩니다.

유용한 연산에 쓰는 비용이 아닙니다. 모든 것을 사전에 등록했기 때문에 컨텍스트 윈도우 (context window)에 함께 실려 오는 스키마에 지불하는 비용입니다.

대부분의 MCP 서버는 유연성을 위해 구축됩니다. 에이전트가 무엇을 필요로 할지 모르기 때문에 모든 것을 등록합니다. 사용자가 무엇이든 물어볼 수 있는 대화형 인터페이스에서는 이것이 합리적입니다. 하지만 작업이 결정론적 (deterministic)인 배치 파이프라인에서는, 등록된 40개의 도구 중 단 2개만 필요하더라도 유연성에 대한 비용을 전액 지불하게 됩니다.

수치는 빠르게 불어납니다. 그리고 이는 사용량 대시보드에서는 보이지 않습니다. 그저 "입력 토큰 (input tokens)"으로 표시될 뿐입니다.

오버헤드가 충분히 가치 있는 경우

MCP는 확실한 강점을 가지고 있습니다. 오버헤드는 유연성을 얻기 위한 비용이며, 다음과 같은 경우에는 그 비용을 지불할 가치가 있습니다.

대화형 에이전트 (Conversational agents). 사용자는 예측 불가능한 질문을 던집니다. 다음에 무엇이 올지 진정으로 알 수 없기 때문에 매 턴마다 사용 가능한 모든 도구가 필요합니다. 스키마 주입 (Schema injection)은 그러한 유연성을 위한 대가입니다.

서버 수준의 거버넌스 및 인증 (Governance and auth). MCP 서버는 자신과 통신하는 모든 클라이언트에 대해 액세스 제어 (access control), 속도 제한 (rate limiting), 감사 로깅 (audit logging)을 한 곳에서 강제할 수 있습니다. 각 도구마다 맞춤형 스크립트로 이를 수행하는 것은 언제 터질지 모르는 위험한 행동 (footgun)입니다. 오버헤드는 정확성을 보장해 줍니다.

팀 간의 조합 가능한 툴링 (Composable tooling). 5개의 팀이 에이전트를 구축하고 있고 모두 동일한 데이터 소스가 필요하다면, 하나의 MCP 서버가 5개의 개별 통합보다 낫습니다. 오버헤드는 공유되며, 유지보수 비용 절감 효과는 실질적입니다.

신속한 프로토타이핑 (Rapid prototyping). MCP를 사용하면 아무것도 없는 상태에서 작동하는 에이전트 도구까지 구축하는 데 몇 분밖에 걸리지 않습니다. 프로덕션에 배포하기 전 반복적인 개선 (iteration) 단계에서는 토큰 오버헤드가 중요하지 않습니다.

MCP를 루프에서 제외해야 할 때

재고해 보아야 할 사례들은 다음과 같습니다:

결정론적 배치 파이프라인 (Deterministic batch pipelines). 에이전트가 무엇을 해야 하는지 정확히 알고 있는 경우입니다. 여기에서 스키마 주입은 대화 측면의 이득이 전혀 없습니다. 순수한 비용일 뿐입니다. 50개의 항목이 있는 작업의 경우, 직접 API 호출을 통하면 약 50초가 걸리는 반면, MCP를 통하면 단계당 10배에서 20배의 토큰 오버헤드가 발생하여 약 25분이 소요됩니다. 그 정도 규모에서는 파이프라인 자체가 스스로를 갉아먹게 됩니다.

대량의 단일 목적 에이전트 (High volume single purpose agents). 에이전트가 하루에 한 가지 일을 10,000번 수행한다면, 하드코딩된 스키마를 사용하는 직접 API 호출이 더 빠르고, 저렴하며, 디버깅하기 쉽습니다. 이 경우 MCP의 유연성은 오히려 부담 (liability)이 됩니다.

지연 시간에 민감한 경로 (Latency sensitive paths). 더 많은 토큰은 LLM으로부터 첫 번째 토큰이 생성되는 시간 (time to first token)이 느려짐을 의미합니다. 응답 지연 시간이 중요한 실시간 애플리케이션에서는 불필요한 모든 토큰이 손해입니다.

범위가 고정되고 비용이 최적화된 파이프라인 (Fixed scope, cost optimized pipelines). 도구가 3개 이상 필요하지 않을 것이라는 점을 알고 있고 작업이 잘 정의되어 있다면, 범용 (general purpose) 방식보다는 맞춤형 (bespoke) 방식이 언제나 승리합니다.

실질적인 최적화: 필드 투영 (Field projection), 선택적 로딩 (Selective loading), 지연 등록 (Lazy registration)

MCP를 사용하기로 결정했지만 오버헤드(overhead)를 줄이고 싶다면, 다음 세 가지 패턴이 도움이 됩니다.

필드 투영 (Field projection)

전체 API 응답을 전달하는 대신, 에이전트가 실제로 필요로 하는 필드만 반환하세요. SerpApi CLI 예제는 이 방식 덕분에 대부분의 효율성을 얻습니다. 이 예제는 LLM에 전달하기 전에 원본 응답에서 제목(title), 스니펫(snippet), URL만 남기고 나머지는 제거합니다. 에이전트는 토큰 비용을 아주 적게 쓰면서도 동일한 정보를 얻을 수 있습니다.

// 전체 응답 객체를 전달하는 대신:
const raw = await serpapi.search(query);

...

선택적 도구 로딩 (Selective tool loading)

모든 에이전트가 매 세션마다 모든 도구를 필요로 하는 것은 아닙니다. 작업에 어떤 도구가 필요한지 사전에 결정할 수 있다면, 해당 도구들만 등록하세요. MCP 서버는 동적 도구 목록(dynamic tool lists)을 지원하므로, 모든 요청에 모든 것을 노출할 필요가 없습니다.

지연 등록 (Lazy registration)

트래픽의 90%를 처리하는 핵심 도구들만 등록하세요. 특화된 도구들은 명시적인 사용자 의도, 특정 작업 유형, 또는 시스템 프롬프트(system prompt)의 플래그를 통해 대화 흐름상 필요하다는 신호가 올 때만 추가하세요. 이렇게 하면 기본 스키마(schema)를 작게 유지할 수 있으며, 실제로 관련이 있는 경우에만 특화된 도구 비용을 지불하게 됩니다.

FAQ

MCP가 직접 API 호출보다 더 많은 토큰을 사용하나요?

네, 항상 그렇습니다. 스키마 주입(Schema injection)은 최소 4배의 오버헤드를 추가하며, 복잡한 멀티 도구(multitool) 서버의 경우 32배까지 늘어날 수 있습니다. 문제는 귀하의 사용 사례에서 이러한 유연성이 비용을 정당화할 수 있느냐 하는 것입니다.

요청당 MCP가 추가하는 토큰은 얼마나 되나요?

등록된 도구의 개수와 스키마의 복잡도에 따라 다릅니다. 최소한의 서버는 메시지당 수백 개의 토큰을 추가할 수 있습니다. 수십 개의 도구를 가진 대규모 서버는 메시지당, 턴(turn)당 수만 개의 토큰을 추가할 수 있습니다.

언제 MCP를 사용하고, 언제 직접 API 호출을 사용해야 하나요?

대화형, 개방형, 거버넌스(governance) 중심, 또는 다수 팀이 참여하는 시나리오에는 MCP를 사용하세요. 배치 작업(batch jobs), 대량의 단일 목적 에이전트, 지연 시간(latency)에 민감한 경로, 그리고 작업 범위가 고정되어 있고 잘 정의된 모든 파이프라인에는 직접 API 호출을 사용하세요.

MCP 서버의 토큰 오버헤드(token overhead)를 어떻게 줄일 수 있을까요?

응답에 대한 필드 투영(Field projection), 선택적 도구 등록(selective tool registration), 그리고 특화된 도구의 지연 로딩(lazy loading)을 활용하세요. 극단적인 경우에는 하이브리드 접근 방식이 효과적입니다. 오케스트레이션 계층(orchestration layer)에는 MCP를 사용하고, 각 도구 내부의 핫 패스(hot path)에는 직접 API를 사용하는 방식입니다.

이것이 실제 프로덕션 에이전트 아키텍처(production agent architecture)에 어떻게 적용되는지 알고 싶다면, production architecture에 관한 제 포스트에서 전체 의사결정 프레임워크를 다루고 있습니다.

토큰 비용(token tax)이 예산을 갉아먹지 않도록 자신만의 MCP 설정 구축에 도움이 필요하시다면, 제가 바로 그런 작업을 수행합니다.

직접 수치를 계산해 보셨다면 댓글을 남겨주세요. 여러분의 프로덕션 환경에서는 4배에서 32배 사이의 범위가 어떻게 나타나는지 궁금합니다.