1.1 MCP(Model Context Protocol)란 무엇인가
AI 모델과 외부 데이터·도구를 표준화된 방식으로 연결하는 오픈 프로토콜이다. USB-C가 모든 기기를 하나의 포트로 연결하듯, MCP는 모든 AI와 모든 도구를 하나의 규약으로 연결한다. 업데이트: 2026-03-08
핵심 요약
| 구분 | 내용 |
|---|---|
| 📖 정의 | AI 앱과 외부 도구·데이터 소스가 통신하는 방식을 규정하는 JSON-RPC 2.0 기반 오픈 프로토콜 |
| 🚀 출시 | 2024년 11월 Anthropic 공개 → 2025년 12월 Linux Foundation(AAIF) 기증으로 업계 표준 확립 |
| 💡 핵심 | N개 AI × M개 도구 = N×M 통합 코드 문제를 → N+M으로 해결 |
| 🎯 대상 | AI 에이전트의 기능을 외부 데이터·도구로 확장하려는 개발자 및 기업 |
| ⚠️ 주의 | 단순한 API 래퍼가 아니다. 동적 도구 발견·양방향 통신·기능 협상이 포함된 상태 유지 프로토콜이다 |
문서 탐색
목차
- MCP가 필요한 이유 — 등장 배경
- MCP를 이해하는 비유
- 핵심 아키텍처 — Host / Client / Server
- 실제 통신 흐름 — 초기화부터 도구 호출까지
- 세 가지 기본 요소 (Primitives)
- 전송 방식 비교 — stdio vs HTTP
- 흔한 오해 바로잡기
- 생태계 현황과 플랫폼 지원
1. MCP가 필요한 이유 — 등장 배경
MCP 이전의 상황
AI 앱이 외부 도구(GitHub, Slack, DB 등)를 사용하려면, 개발자가 각 조합마다 직접 통합 코드를 작성해야 했다.
graph TD C[Claude] -->|커스텀 코드| GA[GitHub API] C -->|커스텀 코드| SA[Slack API] C -->|커스텀 코드| PG[PostgreSQL] G[GPT] -->|커스텀 코드| GA G -->|커스텀 코드| SA G -->|커스텀 코드| PG GE[Gemini] -->|커스텀 코드| GA GE -->|커스텀 코드| SA GE -->|커스텀 코드| PG
3개 AI × 3개 도구 = 9개의 별도 통합 코드. 실제 기업 환경에서는 수십 개 AI 앱과 수백 개 도구가 존재하므로 조합이 기하급수적으로 늘어났다.
N×M → N+M 문제 해결
MCP는 AI 앱과 도구 사이에 공통 언어를 제공하여 이 문제를 구조적으로 해결한다.
graph TD C[Claude] --> MC[MCP 클라이언트] G[GPT] --> MC GE[Gemini] --> MC MC --> S1[MCP 서버: GitHub] MC --> S2[MCP 서버: Slack] MC --> S3[MCP 서버: PostgreSQL]
- 도구 개발자 → MCP 서버를 한 번만 만들면 모든 MCP 호환 AI에서 즉시 사용 가능
- AI 앱 개발자 → MCP 클라이언트를 한 번만 구현하면 모든 MCP 서버에 연결 가능
- 결과: N개 AI + M개 도구 = N+M개의 구현으로 해결
MCP의 탄생
MCP는 2024년 11월 Anthropic이 오픈소스로 공개했다. 설계 철학은 **Language Server Protocol(LSP)**에서 빌려왔다. LSP가 “수십 개 IDE × 수십 개 프로그래밍 언어” 문제를 해결한 것처럼, MCP는 “수백 개 AI × 수천 개 도구” 문제를 동일한 방식으로 해결한다.
2. MCP를 이해하는 비유
추상적인 개념인 MCP를 이해하는 데 도움이 되는 비유들이다.
비유 1: USB-C 포트 (가장 널리 쓰이는 비유)
MCP 이전에는 각 AI 앱마다 도구 연동 방식이 달랐다. 마치 각 기기마다 다른 충전 포트(마이크로 USB, 라이트닝, 독자 규격)를 가진 것처럼. MCP는 USB-C처럼 하나의 표준 포트를 제공한다. 어떤 플러그(MCP 서버)든 같은 포트(MCP 클라이언트)에 꽂으면 동작한다.
단, USB-C보다 더 능동적이다. MCP는 연결 시 “나는 어떤 기능을 지원한다”고 상호 협상하는 과정이 포함된다.
비유 2: 레스토랑 (역할 분담 이해용)
| 역할 | MCP 대응 |
|---|---|
| 셰프 (요리 담당) | AI 모델 (추론·판단) |
| 웨이터 (주문 전달) | MCP Client |
| 주방 시스템 (메뉴·재료 관리) | MCP Server |
| 메뉴판 | tools/list 응답 (사용 가능한 도구 목록) |
| 주문서 | tools/call 요청 (특정 도구 호출) |
| 완성된 요리 | 도구 실행 결과 |
셰프(AI)는 메뉴판(도구 목록)을 보고 원하는 것을 주문(도구 호출)한다. 주방 내부가 어떻게 돌아가는지 셰프가 알 필요 없다.
비유 3: Unix 파이프 (stdio 방식 이해용)
cat file.txt | grep "error" | sort | uniq각 명령어는 stdin으로 받아 stdout으로 내보낸다. 내부 구현은 서로 모른다. stdio 방식 MCP 서버는 이와 동일하게 동작한다. 표준 입출력 파이프로 통신하며, 내부 로직은 완전히 독립적이다.
3. 핵심 아키텍처 — Host / Client / Server
MCP는 세 가지 역할로 구성된다. 통신은 JSON-RPC 2.0 메시지 형식을 사용한다.
graph TB subgraph Host["Host (Claude Code / Claude Desktop / Cursor)"] C1[MCP Client 1] C2[MCP Client 2] C3[MCP Client 3] end C1 <-->|stdio| SA["Server A (파일시스템)"] C2 <-->|HTTP| SB["Server B (GitHub)"] C3 <-->|stdio| SC["Server C (PostgreSQL)"]
각 역할의 책임
| 구성 요소 | 역할 |
|---|---|
| Host | 사용자와 직접 대면하는 AI 앱 전체. 여러 MCP 클라이언트를 생성·관리하고 보안 정책과 사용자 동의를 처리한다 |
| Client | Host 내부에 내장된 통신 모듈. 하나의 Client는 하나의 Server와 1:1 상태 유지 세션을 맺는다 |
| Server | 실제 도구와 데이터를 제공하는 경량 프로세스. 로컬(stdio) 또는 원격(HTTP)으로 운영된다 |
중요: MCP 서버는 전체 대화 히스토리나 다른 서버의 내용을 볼 수 없다. 각 서버는 자신에게 요청된 것만 처리하는 독립적인 프로세스다.
4. 실제 통신 흐름 — 초기화부터 도구 호출까지
4.1 초기화 핸드셰이크 (3단계)
모든 MCP 세션은 이 3단계 핸드셰이크로 시작한다. 이 과정이 완료된 후에야 정상적인 요청이 허용된다.
1단계: Client → Server (initialize 요청)
Client가 자신이 지원하는 기능을 Server에게 알린다.
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {
"roots": { "listChanged": true },
"sampling": {}
},
"clientInfo": { "name": "Claude Code", "version": "1.0.0" }
}
}2단계: Server → Client (initialize 응답 — 기능 목록 공개)
Server가 자신이 제공할 수 있는 기능(도구, 리소스, 프롬프트)을 응답으로 돌려준다.
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2025-11-25",
"capabilities": {
"tools": { "listChanged": true },
"resources": { "subscribe": true, "listChanged": true },
"prompts": { "listChanged": true }
},
"serverInfo": { "name": "filesystem-server", "version": "1.0.0" }
}
}3단계: Client → Server (initialized 알림)
Client가 “준비 완료”를 Server에게 통보한다. 이후부터 정상 요청이 허용된다.
{
"jsonrpc": "2.0",
"method": "notifications/initialized"
}4.2 실제 도구 호출 흐름 (예: 날씨 조회)
sequenceDiagram participant U as 사용자 participant AI as AI 모델 participant C as MCP Client participant S as MCP Server participant API as 외부 날씨 API U->>AI: 서울 날씨가 어때? AI->>C: tools/list 요청 C->>S: tools/list S-->>C: 도구 목록 반환 (get_weather 등) C-->>AI: 도구 목록 전달 AI->>C: tools/call (get_weather, Seoul) C->>S: tools/call 요청 S->>API: 날씨 API 호출 API-->>S: 날씨 데이터 S-->>C: 결과 반환 C-->>AI: 결과 전달 AI-->>U: 서울은 현재 15°C, 맑음입니다
도구 호출 요청:
{
"jsonrpc": "2.0",
"id": 5,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": { "location": "Seoul", "unit": "celsius" }
}
}도구 호출 응답:
{
"jsonrpc": "2.0",
"id": 5,
"result": {
"content": [
{ "type": "text", "text": "서울 현재 날씨: 15°C, 맑음, 습도 45%" }
],
"isError": false
}
}5. 세 가지 기본 요소 (Primitives)
MCP 서버가 제공할 수 있는 기본 요소는 세 가지다. 각각 제어 주체와 목적이 다르다.
| Primitive | 제어 주체 | 성격 | 부작용 | 쉬운 설명 |
|---|---|---|---|---|
| Tools | AI 모델 자율 결정 | 능동 액션 | 있을 수 있음 | AI가 “이 도구를 쓰겠다”고 스스로 판단 |
| Resources | 앱(호스트) 제공 | 읽기 전용 컨텍스트 | 없음 | 앱이 “이 데이터를 보여주겠다”고 결정 |
| Prompts | 사용자 선택 | 워크플로우 템플릿 | 없음 | 사용자가 “이 템플릿을 쓰겠다”고 선택 |
Tools — AI가 직접 호출하는 함수
AI 모델이 목표 달성을 위해 자율적으로 호출을 결정한다. 파일 쓰기, API 호출, 코드 실행처럼 부작용이 있는 액션을 수행한다.
예시: 파일 작성 도구
// AI가 도구 목록 조회
{ "method": "tools/list" }
// 응답: 사용 가능한 도구들
{
"result": {
"tools": [
{
"name": "write_file",
"description": "지정한 경로에 파일을 생성하거나 수정한다",
"inputSchema": {
"type": "object",
"properties": {
"path": { "type": "string" },
"content": { "type": "string" }
},
"required": ["path", "content"]
}
}
]
}
}AI는 이 스키마를 읽고 적절한 인자를 구성하여 tools/call을 호출한다.
Resources — 앱이 제공하는 읽기 전용 데이터
파일, DB 레코드, API 응답 같은 정적 데이터를 AI에게 컨텍스트로 제공한다. 쓰기 권한이 없다.
// 파일 읽기 요청
{
"method": "resources/read",
"params": { "uri": "file:///project/src/app.py" }
}
// 응답: 파일 내용
{
"result": {
"contents": [
{
"uri": "file:///project/src/app.py",
"mimeType": "text/x-python",
"text": "def main():\n print('Hello, World!')\n"
}
]
}
}Prompts — 사용자가 트리거하는 템플릿
반복적인 작업 패턴을 재사용 가능한 워크플로우 템플릿으로 저장한다. 사용자가 명시적으로 선택해야 활성화된다.
// 코드 리뷰 템플릿 조회
{
"method": "prompts/get",
"params": {
"name": "code_review",
"arguments": { "code": "def add(a, b):\n return a + b" }
}
}
// 응답: 완성된 프롬프트 (즉시 AI에게 주입 가능)
{
"result": {
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "다음 코드를 리뷰하고 개선점을 제안해줘:\n\ndef add(a, b):\n return a + b"
}
}
]
}
}6. 전송 방식 비교 — stdio vs HTTP
MCP 서버는 두 가지 방식으로 통신한다. 어디서 서버를 실행하는가에 따라 선택이 결정된다.
| 항목 | stdio | HTTP Streamable |
|---|---|---|
| 실행 위치 | 사용자 머신의 자식 프로세스 | 어디서나 (로컬·클라우드) |
| 통신 방법 | stdin/stdout 파이프 | HTTP POST + 선택적 SSE |
| 인증 | 불필요 (로컬 프로세스) | OAuth 2.1 |
| 다중 사용자 | 불가 | 가능 |
| 설정 난이도 | 낮음 | 중간 |
| 주요 용도 | 개발 환경, IDE 플러그인, 로컬 DB | SaaS API, 팀 공유 서버, 엔터프라이즈 |
| 예시 | filesystem, git, sqlite | GitHub, Sentry, Notion, Stripe |
선택 기준
flowchart TD A([MCP 서버 전송 방식 선택]) --> B{사용자 머신에서\n직접 실행하는가?} B -->|Yes| C[stdio\n파일시스템·git·로컬 DB] B -->|No| D{원격 서버이거나\n인증이 필요한가?} D -->|Yes| E[HTTP Streamable\nGitHub·Sentry·Notion·Stripe] D -->|No| F{여러 사용자가\n공유해야 하는가?} F -->|Yes| E F -->|No| C
SSE(Server-Sent Events) 방식은 구 스펙에서 사용했으나, 현재는 deprecated 상태다. 신규 서버는 HTTP Streamable을 권장한다.
7. 흔한 오해 바로잡기
MCP를 처음 접할 때 흔히 생기는 오해들을 정리한다.
| 오해 | 실제 |
|---|---|
| ”MCP는 단순한 API 래퍼다” | API 래퍼는 특정 API를 감싸는 코드다. MCP는 동적 도구 발견·기능 협상·상태 유지 세션·양방향 통신을 포함한 프로토콜이다 |
| ”MCP가 RAG를 대체한다” | 다른 레이어다. MCP는 도구·데이터 연결 방법을 표준화하고, RAG는 검색 기반 응답 생성 기법이다. MCP 서버 안에 RAG 로직을 구현할 수 있어 조합 관계다 |
| ”MCP 쓰면 모든 AI가 같게 동작한다” | 프로토콜만 통일된다. 도구를 언제 호출할지, 어떻게 결과를 해석할지는 여전히 모델마다 다르다 |
| ”MCP 서버 = AI 에이전트” | MCP 서버는 도구를 제공하는 역할이다. 에이전트는 목표 달성까지 루프를 돌며 판단하는 주체다. 에이전트가 MCP 서버를 사용하는 것이지, 서버 자체가 에이전트는 아니다 |
| ”Resources와 Tools는 같다” | Resources는 부작용 없는 읽기 전용 데이터다. Tools는 실행 시 부작용(파일 수정, 이메일 전송 등)이 있을 수 있는 액션이다. 목적이 근본적으로 다르다 |
| ”MCP는 아직 실험적이다” | Claude, GPT, Gemini, Cursor, VS Code가 내장 지원하고, 2026년 기준 10,000개 이상의 서버가 존재하는 사실상 업계 표준이다 |
8. 생태계 현황과 플랫폼 지원
주요 이정표
| 시기 | 사건 |
|---|---|
| 2024년 11월 | Anthropic, MCP를 오픈소스로 공개 |
| 2025년 3월 | OpenAI가 ChatGPT에 MCP 채택 |
| 2025년 4월 | Google이 Gemini에 MCP 지원 확인 |
| 2025년 상반기 | Block, Apollo, Zed, Replit, Codeium, Sourcegraph 등 구현 |
| 2025년 12월 | Linux Foundation 산하 **Agentic AI Foundation(AAIF)**에 기증 (Anthropic·Block·OpenAI 공동 창립) |
| 2026년 현재 | 수천 개 MCP 서버, 사실상 AI 도구 연동의 업계 표준 확립 |
플랫폼 지원 현황
| 플랫폼 | 채택 시기 | 지원 형태 |
|---|---|---|
| Anthropic (Claude) | 2024년 11월 | Claude Desktop, Claude Code CLI에서 네이티브 지원 |
| OpenAI (GPT) | 2025년 3월 | Agents SDK를 통해 MCP 서버 연동 공식 지원 |
| Google (Gemini) | 2025년 4월 | Gemini CLI 및 Vertex AI 환경에서 채택 |
| Cursor / Zed | 2025년 초 | 로컬 파일·도구 접근의 기본 인터페이스로 사용 |
| VS Code (GitHub Copilot) | 2025년 중반 | 에디터 내 MCP 서버 연동 지원 |
생태계 규모 (2026년 기준)
| 지표 | 수치 |
|---|---|
| 공식·검증 MCP 서버 | 200개 이상 |
| 커뮤니티 MCP 서버 | 10,000개 이상 |
| 공식 SDK 지원 언어 | Python, TypeScript, Go, Java, Kotlin, Ruby 등 |
| awesome-mcp-servers GitHub stars | 66,000+ |
문서 탐색
참고 자료
- MCP 공식 스펙 (2025-11-25)
- MCP 라이프사이클 공식 문서
- Anthropic MCP 공식 발표
- Wikipedia - Model Context Protocol
- IBM Think - MCP 해설
- MCP JSON-RPC 메시지 완전 레퍼런스
- MCP 전송 방식 비교 (DEV Community)
- MCP 흔한 오해 3가지 (Docker 블로그)