본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 03. 13:05

에이전트 도구 사용을 위한 MCP vs CLI 측정 결과 — MCP가 호출당 17배 더 많은 토큰을 사용함

요약

AI 에이전트 도구 제공 방식인 MCP와 직접적인 CLI 호출의 토큰 소비량을 비교 분석했습니다. MCP는 표준화와 보안 측면에서 유리하지만, 매 요청마다 포함되는 스키마와 구조화된 응답으로 인해 CLI 대비 약 17배 많은 토큰을 소모하는 오버헤드가 발생합니다.

핵심 포인트

  • MCP는 매 요청마다 전체 JSON 스키마를 포함하여 토큰 소모가 큼
  • 구조화된 응답 래핑과 프로토콜 오버헤드가 비용 상승의 원인
  • 단순 작업은 CLI, 복잡하고 구조화된 작업은 MCP 권장
  • MCP는 도구의 동적 탐색과 보안 샌드박싱에 강점

설정 (The Setup)

저는 파일을 읽고, 명령어를 실행하고, API를 호출하는 등의 도구를 사용하는 AI 에이전트(AI agents)를 구축해 왔습니다. 에이전트에게 이러한 도구를 제공하는 데에는 두 가지 주요 방법이 있습니다:

  1. MCP (Model Context Protocol) — 모두가 채택하고 있는 새로운 표준
  2. 직접적인 CLI 호출 (Direct CLI calls) — 전통적인 커맨드 라인 실행 방식

모두가 MCP가 미래라고 말합니다. 하지만 아무도 **토큰 비용 (token cost)**에 대해서는 이야기하지 않습니다. 그래서 제가 직접 측정해 보았습니다.

테스트 (The Test)

저는 간단한 파일 읽기 도구를 만들고 각 방식에 따른 정확한 토큰 소비량을 측정했습니다:

방식호출당 토큰 (Tokens per Call)지연 시간 (평균)
MCP (구조화됨)~3,400 토큰280ms
...

MCP가 왜 그렇게 많은 토큰을 사용하는가

오버헤드 (overhead)는 세 가지 지점에서 발생합니다:

1. 매 요청마다 포함되는 도구 스키마 (Tool Schema in Every Request)

MCP는 LLM(Large Language Model)에 보내는 매 요청마다 사용 가능한 모든 도구의 **전체 JSON 스키마 (full JSON Schema)**를 함께 보냅니다. 제가 만든 간단한 파일 읽기 스키마만 해도 약 800 토큰입니다. 도구가 10개 이상이라면, 매 호출마다 8,000개 이상의 스키마 토큰이 소모됩니다.

{
  "name": "read_file",
  "description": "Read contents of a file at given path",
...

2. 구조화된 응답 래핑 (Structured Response Wrapping)

MCP는 모든 응답을 메타데이터, 상태 코드, 타입화된 콘텐츠 블록이 포함된 구조화된 봉투(envelope)로 감쌉니다. 단순한 "파일을 찾을 수 없음" 오류조차 200 토큰짜리 JSON 객체가 됩니다.

3. 왕복 프로토콜 오버헤드 (Round-Trip Protocol Overhead)

각 MCP 호출은 다음 과정을 포함합니다: 요청(request) → 서버 파싱(server parse) → 실행(execute) → 응답 포맷팅(format response) → 반환(return) → 클라이언트 파싱(client parse) → 추출(extract). 각 단계마다 프로토콜 프레이밍(protocol framing)을 위한 토큰이 추가됩니다.

CLI 대안 (The CLI Alternative)

직접적인 CLI 실행의 경우:

$ cat /path/to/file.txt
[raw file content]

이것이 전부입니다. 가공되지 않은 입력(raw input)과 가공되지 않은 출력(raw output). 스키마도, 봉투도, 메타데이터도 없습니다.

MCP가 가치 있는 경우

토큰 비용에도 불구하고, MCP는 다음과 같은 상황에서 빛을 발합니다:

  • 표준화된 탐색(standardized discovery)이 필요한 경우 — 에이전트가 사용 가능한 도구를 동적으로 찾는 경우
  • 재사용 가능한 도구 서버를 구축하는 경우 — 하나의 MCP 서버가 여러 에이전트에게 서비스를 제공하는 경우
  • 보안 샌드박싱(Security sandboxing)이 중요한 경우 — MCP의 권한 모델이 더 세밀한 경우
  • 팀 협업 — 프로젝트 전반에 걸쳐 도구 정의를 공유하는 경우

하이브리드 접근 방식 (현재 제가 사용하는 방식)

저의 실질적인 설정은 다음과 같습니다:

  1. 단순하고 빈번한 작업 → CLI (파일 읽기, 기본적인 셸 명령)
  2. 복잡하고 구조화된 작업 → MCP (데이터베이스 쿼리, 스키마가 포함된 API 호출)
  3. 공격적인 캐싱 (Cache aggressively) — 방식에 관계없이, 한 번으로 충분할 때 두 번 호출하지 마세요.

이 하이브리드 방식을 통해 MCP의 이점은 필요한 곳에 유지하면서도 토큰 사용량을 60% 절감했습니다.

에이전트 작업 하루 동안의 수치

지표MCP 전용하이브리드
총 도구 호출 (Total tool calls)847847
...

시사점 (Takeaways)

  1. 자신의 비용을 측정하세요 — 토큰 사용량은 도구의 복잡도에 따라 크게 달라집니다.
  2. 모든 도구에 MCP가 필요한 것은 아닙 — 단순한 작업은 직접 호출하는 것이 더 저렴합니다.
  3. 스키마 (Schema) 크기가 중요합니다 — MCP 도구의 파라미터 정의를 최소화하세요.
  4. 하이브리드 방식이 실용적입니다 — 가치를 더하는 곳에는 MCP를, 그렇지 않은 곳에는 CLI를 사용하세요.
  5. 17배라는 비율은 고정된 것이 아닙 — 도구가 단순할수록 격차는 작아지고, 도구가 복잡할수록 격차는 커집니다.

여러분의 에이전트 토큰 효율성을 측정해 보셨나요? 어떤 결과를 얻으셨나요? 댓글로 알려주세요.

ai #llm #agents #mcp #productivity

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0