Model Context Protocol(MCP)은 AI 모델에게 외부 도구, 데이터 소스, 서비스에 연결할 수 있는 보편적인 방법을 제공하는 개방형 표준입니다. 모든 모델-도구 조합마다 맞춤형 통합 코드를 작성하는 대신, 하나의 MCP 서버를 만들면 호환되는 모든 모델이 이를 사용할 수 있습니다. Anthropic이 2024년 말에 MCP를 만들었고, 현재 Linux Foundation이 관리하며, OpenAI, Google 및 에이전트 AI 생태계의 나머지 기업들이 모두 이를 채택했습니다. 여기 MCP를 이해하고, 구축하고, 배포하는 데 필요한 모든 것이 있습니다.
MCP 한눈에 보기
6,000단어의 상세한 내용을 들어가기 전에 빠른 버전이 필요하다면 여기 있습니다.
이제 각 항목을 풀어서 설명하겠습니다. MCP가 실제로 무엇인지, 그리고 그것이 필요하게 된 문제부터 시작하겠습니다.
Model Context Protocol이란 무엇인가?
Model Context Protocol은 AI 모델이 외부 도구 및 데이터를 발견하고 상호작용하는 방식을 표준화하는 개방형 JSON-RPC 기반 프로토콜입니다. AI 통합을 위한 HTTP라고 생각하면 되며, 모든 모델과 모든 도구가 사용할 수 있는 공통 언어입니다.
USB-C 비유를 들어본 적이 있을 겁니다. 어느 정도까지는 유용한 비유입니다. USB-C 이전에는 모든 기기가 자신만의 케이블이 필요했습니다. MCP는 AI에 같은 일을 하지만, 이 비유는 실제보다 부족합니다. USB-C는 데이터와 전력만 전달합니다. MCP는 도구 정의, 데이터 접근 패턴, 재사용 가능한 프롬프트 템플릿을 전달하며, 서버가 모델에 완성(completion)을 요청할 수도 있게 합니다. 케이블 은유보다 훨씬 풍부한 프로토콜입니다.
MCP가 해결하는 M × N 문제
MCP 없이 M개의 모델을 N개의 도구에 연결하려면 M × N개의 맞춤형 통합이 필요합니다. 예를 들어 5개의 LLM(Claude, GPT-4, Gemini, Llama, Mistral)을 지원하고 10개의 도구(GitHub, Postgres, Slack, Jira 등)에 접근해야 한다고 하겠습니다. 그러면 각각 자체의 인증, 에러 처리, 데이터 포맷팅을 가진 50개의 개별 통합 계층이 필요합니다.
MCP를 사용하면 각 모델이 MCP 클라이언트 프로토콜을 한 번 구현하고, 각 도구가 MCP 서버를 한 번 구현합니다. 이제 50개 대신 5 + 10 = 15개의 구현이 필요합니다. 새로운 모델을 추가하면? 즉시 모든 10개의 도구와 작동합니다. 새로운 도구를 추가하면? 모든 5개 모델이 이를 사용할 수 있습니다.
MCP의 간략한 역사
Anthropic은 2024년 11월에 Python과 TypeScript SDK, Claude Desktop용 커넥터와 함께 MCP를 오픈소스로 공개했습니다. 채택 속도는 빠른 편이었습니다. OpenAI는 2025년 3월에 ChatGPT에 MCP 지원을 추가했습니다. Google은 2025년 4월에 Gemini에 추가했습니다. 2025년 12월까지 Anthropic은 MCP를 Linux Foundation의 새로운 Agentic AI Foundation(AAIF)에 기부했습니다. AAIF는 Block과 OpenAI와 함께 공동 설립했으며, MCP는 업체 중립적인 표준으로서 업계 전반의 거버넌스를 갖추게 되었습니다.
MCP가 아닌 것:
- 모델이나 AI 프레임워크가 아닙니다(HTTP처럼 프로토콜입니다)
- LangChain이나 LlamaIndex의 대체재가 아닙니다(이들은 오케스트레이션 계층이고, MCP는 그 아래에 있습니다)
- Anthropic이나 Claude에만 한정되지 않습니다(설계상 모델에 구애받지 않습니다)
- 함수 호출(function calling)과 같지 않습니다(비교 섹션에서 자세히 다룹니다)
MCP는 어떻게 작동하는가? 아키텍처 깊이 있는 분석
MCP는 3가지 역할을 하며, 이를 헷갈리는 것이 초보자가 가장 흔히 하는 실수입니다. 차이점을 명확히 하겠습니다.
Host, Client, Server의 차이는 무엇인가?
구체적인 예를 들겠습니다. 당신이 Claude Desktop에 열려 있는 GitHub 풀 요청을 확인해달라고 요청합니다. Claude Desktop이 host입니다. 내장된 MCP 클라이언트가 GitHub MCP 서버에 대한 연결을 엽니다. 서버는 GitHub API를 호출하고, 당신의 PR을 가져오며, 결과를 클라이언트에게 반환하고, 클라이언트는 이를 모델에게 전달합니다.
단일 host는 여러 클라이언트를 실행할 수 있으며, 각각 다른 서버에 연결됩니다. 이것이 Claude Desktop이 동시에 GitHub, Postgres 데이터베이스, Slack(3개의 별도 MCP 서버)에 접근하고, 3개의 별도 클라이언트 연결을 가질 수 있는 방식입니다. 하나의 host입니다.
메시지 흐름 방식 (JSON-RPC 2.0)
모든 MCP 통신은 JSON-RPC 2.0(가벼운 요청/응답 프로토콜)을 사용합니다. 다음은 tools/list 교환이 네트워크 상에서 어떻게 보이는지입니다:
모델은 이러한 도구 정의를 읽고, 사용자의 요청을 바탕으로 언제 이들을 호출할지 결정하며, 클라이언트는 적절한 인자를 가진 tools/call 요청을 서버에 다시 보냅니다.
연결 생명주기
모든 MCP 세션은 동일한 생명주기를 따릅니다:
- Initialize, 클라이언트가 기능을 보내고 서버가 자신의 기능으로 응답
- Capability negotiation, 양쪽이 지원하는 기능(tools, resources, prompts, sampling)에 동의
- Ready, 연결이 활성화되고 양방향으로 요청이 흐름
- Requests/responses, tools/call, resources/read 등
- Shutdown, 깔끔한 연결 종료
이 핸드셰이크는 전방 호환성을 보장합니다. 서버가 새로운 기본 요소를 추가하면, 더 오래된 클라이언트는 충돌하는 대신 우아하게 이를 무시합니다.
MCP 기본 요소: Tools, Resources, Prompts, Sampling
MCP는 4가지 기본 요소를 정의하며, 각각을 누가 제어하는지 이해하는 것이 좋은 MCP 서버를 설계하는 핵심입니다.
Tools (모델 제어)
Tools는 모델이 호출할 수 있는 함수입니다. 서버는 이들을 이름, 설명, JSON Schema 입력 정의와 함께 선언합니다. 모델은 이러한 정의를 읽고, 사용자의 요청에 필요할 때, 모델은 도구를 호출하기로 결정합니다.
OpenAI 함수 호출을 사용해본 적이 있다면, tools는 익숙할 것입니다. 다만 이들은 모든 MCP 호환 모델 전체에서 표준화되어 있습니다.
Resources (애플리케이션 제어)
Resources는 읽기 전용 데이터 엔드포인트입니다. Tools와 달리, 모델은 자체적으로 resource를 가져오기로 결정하지 않습니다. Host 애플리케이션이나 사용자가 명시적으로 resource를 대화 맥락에 첨부합니다. GET 엔드포인트처럼 생각하면 됩니다: postgres://mydb/users/schema, file://docs/api-reference.md
Resources는 resources/subscribe를 통해 구독을 지원하므로, 클라이언트는 데이터 변경 시 알림을 받을 수 있습니다.
Prompts (사용자 제어)
Prompts는 MCP 서버가 노출하는 재사용 가능한 템플릿입니다. code_review prompt는 파일 경로를 받아 구조화된 리뷰 요청을 생성할 수 있습니다. 사용자(또는 host UI)가 prompts를 명시적으로 트리거하며, 모델이 자동으로 호출하지 않습니다.
Sampling (서버 시작), 고급
대부분의 가이드에서 건너뛰는 기본 요소입니다. Sampling을 통해 서버는 클라이언트에 LLM을 사용해 완성을 생성해달라고 요청할 수 있습니다. 이것은 통상적인 흐름을 역으로 바꿉니다: 모델이 도구를 호출하는 대신, 도구가 모델을 호출합니다.
왜 그럴까요? 에이전트 루프입니다. 지원 티켓을 처리하는 MCP 서버를 생각해보세요. 티켓을 읽고(resource), sampling/createMessage를 사용해 모델에 요약을 요청한 다음, 그 요약을 사용해 도구를 통해 티켓을 라우팅합니다. 서버는 모델의 지능을 사용해 다단계 워크플로우를 오케스트레이션합니다.
Sampling은 host 애플리케이션에 의해 게이트됩니다. 사용자가 승인해야 하며, host가 서버가 요청할 수 있는 것을 제어합니다. 이는 무한 루프를 방지하고 인간의 감시를 유지합니다.
첫 번째 MCP 서버 구축: Python과 TypeScript 나란히 비교
이론은 충분합니다. get_weather tool을 노출하는 작동하는 MCP 서버를 만들어봅시다. Python과 TypeScript를 모두 보여드리겠으므로 개발자 경험을 비교하고 프로젝트에 맞는 스택을 선택할 수 있습니다.
FastMCP를 사용한 Python
FastMCP는 공식 고수준 Python SDK입니다. 모든 프로토콜 세부사항을 처리하므로 당신은 도구 로직에 집중할 수 있습니다.
그게 다입니다 -- 15줄입니다. FastMCP는 Python 타입 힌트와 docstring에서 도구의 입력 스키마를 추론합니다. JSON Schema 보일러플레이트가 없습니다.
TypeScript와 공식 SDK
TypeScript SDK( @modelcontextprotocol/sdk )는 조금 더 명시적이지만 스키마 정의를 완전히 제어할 수 있습니다.
TypeScript 버전은 타입 힌트 대신 Zod 스키마를 사용하고 구조화된 콘텐츠 블록을 반환합니다. 더 자세하지만, 타입 안전성이 뛰어납니다.
Claude Desktop에 연결
어느 서버든 Claude Desktop에 연결하려면 claude_desktop_config.json에 추가하십시오:
Claude Desktop을 다시 시작하면 두 weather 서버가 도구 목록에 나타납니다. "베를린의 날씨는 어떻게 되나요?"라고 질문하면 모델이 자동으로 get_weather 도구를 호출합니다.
MCP Inspector로 테스트
서버를 host에 연결하기 전에, MCP Inspector로 격리된 상태에서 테스트하십시오:
...