MCP: 에이전트 통신의 표준 · leejk

TL;DR. MCP는 에이전트 통신의 표준이 됐다. 2025년 12월 Linux Foundation 산하 Agentic AI Foundation(AAIF)으로 이관, 2026년 3월까지 Anthropic·OpenAI·Google·Microsoft가 전부 채택, 공개 서버 1만 개 돌파. M×N 통합 폭증을 JSON-RPC 위 Tools·Resources·Prompts 3개 프리미티브로 해결하지만, 운영에서 깨지는 지점은 프로토콜이 아니라 연결 서버가 늘어날 때 생긴다.

MCP

MCP(Model Context Protocol)는 에이전트와 외부 도구·데이터 소스 사이의 통신을 표준화한 오픈 프로토콜이다. 2024년 11월 Anthropic이 발표했고, 2025년 12월 Linux Foundation 산하 Agentic AI Foundation(AAIF)으로 이관됐다. AAIF는 Anthropic·Block·OpenAI 공동 설립, Google·Microsoft·AWS·Cloudflare가 후원한다. 2026년 3월까지 주요 4대 프로바이더(Anthropic·OpenAI·Google·Microsoft) 전부가 채택했고, 공개 MCP 서버는 1만 개를 넘었다.

MCP가 해결하고자 하는 문제

MCP 이전, 에이전트와 외부 도구·데이터의 통합은 M×N 폭증에 빠져 있었다. M개의 에이전트(Claude Code·ChatGPT·Cursor·Cline·…)가 각각 N개의 도구·데이터 소스(GitHub·Slack·DB·파일시스템·…)에 닿으려면, 매번 둘 사이의 글루 코드를 새로 짜야 했다. 구체적으로 네 가지가 표준화되어 있지 않았다.

도구 정의 포맷 — Claude의 함수 호출 스펙, OpenAI의 tools, Cursor 플러그인 API, Cline 도구 인터페이스가 전부 달랐다. 한쪽에서 짠 도구를 다른 쪽에서 쓰려면 다시 짜야 했다.
도구 발견 메커니즘 — 모델이 어떤 도구가 가용한가를 일관된 방식으로 질의하는 수단이 없었다. 에이전트마다 자체 플러그인 시스템에 등록을 따로 해야 했다.
권한·신뢰 경계 — 어디까지가 모델이 자율로 부르는 것, 어디까지가 사용자 명령으로만 부르는 것, 어디까지가 읽기 전용인지가 프로토콜 수준에서 분리되지 않았다.
데이터 소스 접근 — 도구 호출과 별도로 문서·스키마·파일 같은 컨텍스트 데이터를 모델 쪽으로 끌어오는 표준 채널이 없었다.

구성 요소

MCP는 네 가지로 이루어진다.

1. 전송 계층. JSON-RPC 2.0 메시지 위에서 작동한다. 로컬은 stdio(자식 프로세스 표준입출력), 원격은 Streamable HTTP(이전 SSE의 후속). 양쪽 모두 같은 메시지 셋을 쓴다.

2. 클라이언트-서버 모델. 클라이언트(에이전트 해네스: Claude Code·ChatGPT·Cursor 등)가 하나 이상의 서버(도구·데이터 제공자)에 접속한다. 서버는 외부 프로세스로 실행되며 정의된 capabilities를 노출한다.

3. 3개 프리미티브. 서버가 노출하는 자원의 세 가지 타입.

프리미티브	누가 트리거	무엇
Tools	모델	부작용 있는 액션 — DB 쿼리, 파일 쓰기, API 호출
Resources	클라이언트	읽기 전용 데이터 — 파일, 문서, 스키마
Prompts	사용자	템플릿화된 프롬프트 — 슬래시 명령처럼 호출

4. 표준 메시지 셋. initialize(핸드셰이크), tools/list·resources/list·prompts/list(발견), tools/call·resources/read·prompts/get(실행). 양방향이며, 서버가 클라이언트에 sampling을 요청하는 reverse RPC도 가능하다.

구성 요소가 어떻게 문제를 해결하는가

§1.1의 네 문제가 각각 §1.2의 구성 요소에 의해 해소된다. 핵심은 MCP 서버가 어댑터 레이어로 자리 잡고, 양쪽 인터페이스를 분리·표준화한다는 점이다.

flowchart LR
    AI["AI / 에이전트<br/>(Claude · ChatGPT · Cursor)"]
    MCP["MCP 서버<br/>(어댑터)"]
    EXT["외부 채널<br/>(GitHub · DB · 파일 · …)"]

    AI <-->|"JSON-RPC 2.0<br/>(표준 wire)"| MCP
    MCP <-->|"외부 채널의 통신 규격<br/>(HTTP · SQL · 파일 · gRPC · …)"| EXT

    classDef box fill:#161821,stroke:#2a2d38,color:#e7e9ec;
    class AI,MCP,EXT box;

왼쪽은 모든 클라이언트에 공통인 JSON-RPC, 오른쪽은 각 외부 채널의 고유 통신 규격이다. MCP 서버는 한쪽을 받아 다른 쪽으로 번역한다.

M×N → M+N. JSON-RPC + 표준 메시지 셋이 곧 공통 wire format이다. 서버를 한 번 짜두면 모든 MCP 클라이언트가 동일한 메시지로 호출한다. GitHub MCP 서버 하나가 Claude·ChatGPT·Cursor에서 동시에 작동한다.
통합 도구 정의 스키마. Tools는 JSON Schema 기반 입력 정의를 갖는다. 모델은 이름·description·입력 스키마만 보고 호출을 결정하고, 구현은 서버 내부에 캡슐화된다. 동일한 도구 정의가 모든 클라이언트에서 그대로 통한다.
결정론적 발견(discovery). 클라이언트가 세션 시작 시 tools/list 등을 발행하면 서버가 가용한 모든 자원을 메타데이터로 반환한다. 별도 등록 없이 자동으로 발견되고, 그 카탈로그가 곧 컨텍스트로 들어간다. 메타데이터/본문 분리(메타는 세션 시작 시, 실행은 호출 시) 덕에 컨텍스트 비용도 통제된다.
프로토콜 수준의 권한 경계. 3개 프리미티브가 트리거 주체를 박아둔다. Tools는 모델이 자율 호출(부작용 가능), Resources는 클라이언트가 컨텍스트로 로드(읽기 전용), Prompts는 사용자만 호출(템플릿). 이 분리가 prompt injection 방어와 권한 모델의 출발점이다.

핵심은 tool description이 곧 라우팅 신호라는 점이다. 모델은 본문(서버 내부 구현)을 모른다 — 이름·설명·입력 스키마만 보고 어떤 도구를 부를지 결정한다. 그래서 description 품질이 곧 호출 정확도다. 이 메커니즘이 §2의 운영 충돌 패턴 다수를 직접 설명한다.

스킬과의 차이

agent-skill 글을 읽었다면 떠오를 질문 — 스킬과 MCP는 같은 것 아닌가? 메커니즘은 닮았다. 둘 다 메타데이터를 세션 시작 시 로드하고 본문·실행은 lazy다. description 품질이 호출 정확도를 좌우한다는 점도 같다. 그러나 단위가 다르다.

측면	스킬	MCP
단위	절차·정책	도구·데이터
구현	마크다운 절차 (텍스트)	서버 코드 (외부 프로세스)
호출 시 컨텍스트 진입	본문 전체	도구 실행 결과(JSON)
트리거	모델(자가)·사용자(슬래시)	모델(Tools)·클라이언트(Resources)·사용자(Prompts)
결정론	자유 텍스트 절차	JSON 스키마 기반 호출
합성	다른 스킬 호출 가능	다른 MCP 서버 직접 호출 불가

운영 분담은 한 줄로 정리된다.

MCP가 결정: 어떤 도구가 가용한가
스킬·정책이 결정: 언제·어떻게 부를 것인가

함께 운영할 때 우선순위는 다음 순서다.

사용자 명시 지시(CLAUDE.md·AGENTS.md) — 최우선
스킬 본문 규칙 — 절차 결정
MCP 도구 카탈로그 — 어떤 도구가 가용한가
기본 시스템 프롬프트 — 최하위

여기서 핵심 안티패턴 하나 — 자작 MCP 서버에 절차를 박지 말 것. 서버는 stateless·결정론적 도구의 묶음이어야 하고, 절차·정책은 스킬 쪽에 둔다. 한쪽만으로는 운영이 안 된다 — 절차 없는 도구는 모델이 잘못 부르고, 도구 없는 절차는 외부 세계에 닿지 못한다.

설계상 어디서 부딪치는가

직접 운영해 본 관찰이 아니라, 스펙과 구성 요소를 읽고 구조적으로 필연인 마찰만 짚는다.

도구 이름 충돌 — 두 서버가 같은 이름의 tool을 노출하면 모델이 잘못 라우팅한다. 일부 클라이언트는 prefix를 붙여 회피.
컨텍스트 폭증 — 서버가 10개를 넘어가면 tool list만으로 수천 토큰을 소비한다. 사용하지 않는 서버는 비활성화하는 게 비용·정확도 모두에 유리.
권한·신뢰 경계 — 서드파티 MCP가 OS 권한이나 토큰을 요구할 때, 그 서버의 응답이 곧 모델 컨텍스트로 흘러간다. prompt injection을 통한 도구 호출 유도가 실제 공격 벡터.
description 노이즈 — 너무 일반적인 description("처리합니다")은 호출 정확도를 떨어뜨린다. description은 언제 부를지를 모델이 판단할 수 있도록 구체적이어야 한다.
버전·프로토콜 드리프트 — 서버가 새 프로토콜 버전을 채택했는데 클라이언트가 못 따라가는 경우. initialize 응답을 봐야 디버깅 가능.

종합

MCP는 프로토콜 자체로는 단순하다. Linux Foundation 이관 + 주요 4대 프로바이더 전 채택으로 프로토콜이 흔들릴 가능성은 사실상 제거됐다. 깨지는 곳은 항상 연결 서버가 늘어난 뒤고, 거기서 description 품질과 도구 선택을 좁히는 정책, 두 축이 운영의 전부다.

MCP

MCP가 해결하고자 하는 문제

구성 요소

구성 요소가 어떻게 문제를 해결하는가

스킬과의 차이

설계상 어디서 부딪치는가

종합

참고