MCP 대 API: 어떤 상황에서 무엇을 사용해야 하는가 (실제 벤치마크 포함)

저는 동일한 소규모 서비스를 REST API와 상태 비저장(stateless) MCP 서버 방식으로 구축하고, 지연 시간(latency), 처리량(throughput), 전송 바이트 수, 그리고 모델이 읽어야 하는 토큰 수를 측정했습니다. 업데이트를 거친 원본은 fabwaseem.com에서 확인할 수 있습니다.

MCP 대 API는 사실 두 개의 경쟁 기술 중 하나를 선택하는 문제가 아닙니다. API (일반적으로 REST)는 소프트웨어가 귀하의 서비스와 통신하는 방식입니다. 즉, 코드가 알려진 엔드포인트(endpoint)를 호출합니다. 반면, MCP (Model Context Protocol)는 AI 애플리케이션이 런타임에 도구(tool)를 _발견_하고 호출하는 방식이며, 거의 모든 MCP 서버는 API 위에 구축됩니다. 진정한 질문은 누가 호출자인지입니다: 귀하의 코드입니까, 아니면 모델입니까.

저는 동일한 다섯 가지 작업(five-operation) 프로젝트 서비스를 한 대의 컴퓨터에서 REST API와 공식 TypeScript SDK를 사용한 상태 비저장 MCP 서버 방식으로 모두 구축하고, 각각의 비용을 측정했습니다. 저는 지연 시간, 전송 바이트 수, 그리고 에이전트에게 가장 중요한 모델이 읽어야 하는 토큰 수를 측정했습니다. 또한 이 사이트를 구동하는 MCP 서버도 측정했습니다. 아래의 모든 숫자는 해당 실행(run)에서 나온 것입니다.

요약: MCP 또는 API, 무엇을 사용해야 할까요?

• REST API는 귀하 자신의 코드가 호출자일 때 사용하세요: 웹 및 모바일 앱, cron job, 웹훅(webhook), 서비스 간 통신(service-to-service calls), 그리고 제어하는 고정된 에이전트 파이프라인에 적합합니다. * MCP 서버는 귀하가 제어하지 않는 AI 클라이언트(Claude, ChatGPT, Cursor, VS Code, Copilot)가 귀하의 서비스를 사용해야 할 때, 또는 모델이 런타임에 도구를 선택해야 할 때 추가하세요. 대부분의 제품은 둘 다 필요하며, 이 경우 MCP 서버가 API를 감싸는(wrapping) 형태가 됩니다.

MCP와 API의 차이점은 무엇인가요?

API는 프로그램에 대한 계약입니다: 사전에 정의된 고정 엔드포인트이며, 개발자가 작성한 코드를 통해 호출됩니다. MCP(Model Context Protocol)는 AI 애플리케이션에 대한 계약입니다: 서버가 이름, 설명 및 JSON Schema를 가진 도구 목록을 제공하고, 모델은 런타임 시 어떤 도구를 호출할지 결정합니다. MCP가 여러분의 API를 대체하는 것은 아닙니다. 이는 모델이 사용할 수 있는 형태로 API의 선별된 일부를 기술한 것입니다.

MCP는 Anthropic에 의해 2024년 11월에 오픈 소스되었습니다. 이후 2025년 12월, Anthropic은 OpenAI의 AGENTS.md와 함께 이를 [Linux Foundation 산하 Agentic AI Foundation]에 기부했습니다. 이 발표를 통해 "10,000개 이상의 게시된 MCP 서버"라는 수치가 언급되었으며, Claude, Cursor, Microsoft Copilot, Gemini, VS Code, ChatGPT가 채택 사례로 나열되었습니다.

[MCP 도구 명세(MCP tools specification)]는 누가 책임자인지 명확히 합니다: "MCP의 도구들은 **모델 제어(model-controlled)**되도록 설계되었으며, 이는 언어 모델이 도구를 자동으로 발견하고 호출할 수 있음을 의미합니다." 이 한 문장이 전체 차이를 만듭니다. API에서는 개발자가 무엇을 호출할지 결정합니다. MCP에서는 모델이 결정합니다.

MCP 서버가 단순히 API 래퍼에 불과한가요?

일반적으로는 그렇고, 그것은 괜찮습니다. 실제로는 MCP 서버가 얇은 어댑터(thin adapter) 역할을 합니다: 각 도구는 자신의 인수를 검증하고 기존 서비스나 REST API를 호출합니다. MCP가 추가하는 것은 표준적인 도구 목록화 방법, 표준 호출 형식, 도구 주석(읽기 전용(read-only), 파괴적(destructive), 반복 가능(idempotent)), 그리고 모든 MCP 클라이언트가 이미 이해하는 OAuth 2.1 플로우입니다. 이는 비즈니스 로직을 추가하지는 않습니다.

다음은 동일한 작업이 두 가지 방식으로 노출되며, 하나의 Zod 스키마를 공유하는 예시입니다:

// store.ts: REST 검증, OpenAPI 및 MCP 입력Schema에서 사용되는 단일 스키마
export const SlugInput = z.object({
  slug: z.string().describe('프로젝트 슬러그, 예: project-42'),
...

// REST: GET /api/projects/:slug
if (req.method === 'GET' && slug) {
  SlugInput.parse({ slug })
...

MCP: 도구(tool)와 동일한 동작을 수행합니다 (@modelcontextprotocol/server 2.3.1)
서버.등록도구("get_project",
...

에러 경로를 주목하세요. REST는 404 응답 코드를 반환하고, 여러분의 코드는 이 코드에 따라 분기됩니다. 하지만 MCP는 독자(reader)가 다음에 무엇을 시도할지 결정하는 모델이기 때문에 isError: true와 함께 문장을 반환합니다.

MCP는 REST와 어떻게 다른가?

REST는 여러 URL과 HTTP 동사를 사용합니다. MCP는 단일 엔드포인트와 JSON-RPC를 사용합니다. 모든 호출은 POST /mcp이며, 이때 tools/list나 tools/call 같은 method를 포함합니다. 2026-07-28 사양에 따르면 MCP는 상태 비저장(stateless) 방식이므로, 각 요청은 프로토콜 버전과 클라이언트 기능을 _meta 필드에 담고, 추가적으로 Mcp-Method 및 Mcp-Name 헤더를 가집니다.

동일한 조회 작업을 양방향으로 비교해 보겠습니다:

# REST
curl http://127.0.0.1:3201/api/projects/project-42

...

REST 응답은 전송 과정에서 334바이트였습니다. MCP 응답은 758바이트였는데, 이는 결과가 두 번 담겨 오기 때문입니다. 한 번은 텍스트 블록 내의 JSON 문자열로, 다른 한 번은 structuredContent로 담깁니다. 이것은 설계상의 특징입니다. 사양에 따르면 구조화된 콘텐츠(structured content)를 반환하는 도구는 후방 호환성을 위해

1. Service. 다섯 가지 작업(list (검색 및 태그 필터), get, create, update, delete)을 수행하는 1,000개의 인메모리 프로젝트. 모든 서버는 동일한 스토어와 동일한 Zod 4.6.7 스키마를 공유하므로 프로토콜 계층만 다릅니다.
2. REST. Zod 검증이 적용된 일반 node:http, 포트 3201.
3. MCP, 직접 연결(direct). JSON 응답 모드의 @modelcontextprotocol/server 2.3.1을 사용하며, 요청마다 새로운 McpServer를 생성하고 (SDK에서 문서화된 상태 비저장 패턴), 도구들이 인프로세스(in-process)로 스토어를 호출합니다.
4. MCP, REST 래핑(wrapping). 동일한 MCP 서버를 사용하지만, 각 도구가 fetch를 통해 HTTP로 REST API를 호출합니다. 이것이 일반적인 실제 환경 설정입니다.
5. 실행 환경. 로컬호스트에서 실행된 Node.js 24.22.0 (8 vCPU Intel Xeon VM, RAM 15 GB) 환경이며, 모든 것이 localhost에 있습니다. 지연 시간(Latency): 2,000개의 워밍업 요청 후 케이스별로 20,000개의 순차적 요청을 측정했으며, process.hrtime으로 시간을 기록했습니다. 처리량(Throughput): 3초의 워밍업 후 10초 동안 autocannon 8.0.0을 사용하여 연결 수 1개와 50개일 때를 측정했습니다. 모든 응답은 오류 없이 200이었습니다.
6. 토큰. OpenAI의 o200k_base 토크나이저(tiktoken)로 계산되었으며, 압축된 JSON을 사용했습니다. 다른 모델들은 토큰화 방식이 다르므로 이 수치는 상대적인 크기로 간주해야 합니다.

로컬호스트는 의도적으로 네트워크 시간을 제거합니다. 실제 네트워크 환경에서는 두 프로토콜 모두 동일한 왕복 시간(round trip) 비용을 지불하므로, 아래의 차이는 순수한 프로토콜 및 프레임워크 오버헤드입니다.

MCP가 REST API보다 느린가요?

네, 요청당 기준으로 상대적으로는 많이, 절대적으로는 매우 적게 느립니다. get_project 호출은 MCP를 통해 중앙값 424 µs가 소요된 반면, REST를 통해서는 76 µs로 약 5.6배 더 느렸습니다. 연결 수 50개일 때, 하나의 Node 프로세스는 REST 요청을 초당 66,486건 처리한 반면, MCP 요청은 초당 4,595건으로 약 14배 적었습니다. MCP 도구가 스토어 대신 REST API를 호출했을 때는 중앙값이 다시 두 배인 848 µs까지 증가했습니다.

시간은 어디에 쓰이나? 부하 상태의 MCP 서버 CPU 프로파일링 결과, 샘플 중 16.7%는 SDK의 요청 파이프라인에서, 11.5%는 Zod(파싱 및 JSON Schema 변환)에서, 그리고 노드 내부 처리 시간의 대부분인 25%는 Node 요청을 Web Request 객체로 변환하고 다시 되돌리는 데 사용되었다. 개별 요청당 McpServer 자체를 구축하는 것은 저렴했다: 다섯 가지 도구에 대해 13.4 µs가 소요되었다.

이것이 중요한가? 에이전트에게는 그렇지 않다. 모델의 한 번의 실행(turn)은 수백 밀리초에서 몇 초가 걸리므로, 0.35 ms의 프로토콜 오버헤드는 무시할 만한 수준이다. 하지만 여러분 자신의 프론트엔드가 초당 수천 번 호출하는 고트래픽 API라면 매우 중요하다. 이것이 MCP를 통해 앱 자체의 트래픽을 라우팅하지 말아야 할 또 다른 이유가 된다.

MCP 도구는 토큰 비용이 얼마나 드나?

MCP의 실제 비용은 CPU가 아니라 컨텍스트(context)이다. 클라이언트는 보통 모든 도구 정의, 즉 이름, 설명 및 JSON Schema를 각 요청마다 모델에 입력 토큰으로 전송한다. 나의 다섯 가지 도구는 tools/list에서 반환된 대로 591 토큰이 들고, 평문 함수 호출 정의로 재구성하면 488 토큰이 든다. 이 사이트 뒤의 MCP 서버는 총 5,949 토큰에 달하는 21개의 도구를 노출한다.

[

모델이 읽는 것 | 토큰 (o200k_base)
| :--- |
| 5개의 도구, 원시 tools/list 결과 | 591 |
| ... |
세 가지 점이 눈에 띕니다. 첫째, OpenAPI 문서를 프롬프트에 붙여넣는 것은 좋지 않습니다. 이는 모델이 필요로 하지 않는 응답, 상태 코드 및 서버를 설명하며, 동일한 작업의 경우 원시 도구 목록보다 1.6배, 함수 정의보다 1.9배 더 많은 토큰을 사용했습니다. 둘째, 풍부한 하나의 도구가 열 개의 작은 도구보다 비쌀 수 있습니다. update_post만으로도 사이트 도구 예산의 17%를 차지하는데, 이는 스키마가 편집 가능한 모든 필드를 나열하기 때문입니다. 셋째, 클라이언트가 합리적이라면 결과는 저렴합니다. 텍스트 블록과 structuredContent 모두 각각 46 토큰으로, REST 본문과 동일했습니다.

대규모 카탈로그는 빠르게 비용이 많이 듭니다. Anthropic의 엔지니어링 팀은 도구 정의를 미리 로드하는 경우 최대 150,000 토큰을 사용하는 설정을 설명했습니다. MCP를 사용한 코드 실행을 통해 에이전트가 필요한 정의만 로드하도록 함으로써 이를 2,000 토큰으로 줄였고, 이는

기존 REST API에 MCP 서버를 추가하려면 어떻게 해야 하나요?

API를 재작성하지 말고 래핑하세요. REST 엔드포인트를 진실의 원천(source of truth)으로 유지하고, 그 엔드포인트들을 호출하는 선별된 도구 세트(curated set of tools)를 노출하세요. 기존 검증 스키마를 재사용하고, 오류는 문장 형태로 반환하며, 읽기 전용 및 파괴적인 도구에는 주석을 달아 표시하세요. 읽기 전용 도구부터 시작하여, 더 좁은 OAuth 범위 뒤에 쓰기(write) 기능을 추가하세요.

// 기존 REST 엔드포인트를 래핑하는 MCP 도구
const API = process.env.API_URL // 예: https://api.example.com/api/projects

...

이 사이트의 콘텐츠를 위해 MCP 서버를 운영하며 배운 디자인 규칙들: