Model Context Protocol(MCP)은 2024년 11월 25일 Anthropic이 발표·제안한 개방형 표준으로, 대규모 언어 모델(LLM) 기반 애플리케이션이 외부 데이터 소스와 도구(tool)에 안전하고 표준화된 방식으로 연결되도록 설계되었다. MCP의 핵심 목표는 각 데이터 소스·도구마다 별도의 맞춤 통합을 반복하는 문제를 줄이고, “MCP 서버”와 “MCP 클라이언트”라는 공통 구조로 상호운용 가능한 생태계를 만드는 데 있다.
목차
- 개요와 등장 배경
- 아키텍처와 통신 방식
- 주요 구성 요소: Resources·Prompts·Tools와 클라이언트 기능
- 채택(Adoption)과 생태계 확장, 반응(Reception)
- MCP가 가능하게 하는 것과 구축 시작(Start Building)
1. 개요와 등장 배경
생성형 인공지능 애플리케이션은 모델 자체의 추론 성능뿐 아니라 “필요한 맥락(context)을 얼마나 정확히, 적시에 가져오느냐”에 의해 품질이 크게 좌우된다. 그러나 실무 환경에서 맥락은 파일 시스템, 사내 위키, 업무용 SaaS, 데이터베이스, 코드 저장소, 설계 도구 등 다양한 시스템에 분산되어 있으며, 각 시스템을 AI에 연결하기 위해서는 개별 통합을 개발해야 하는 경우가 많다.
MCP는 이러한 파편화된 통합을 단일 표준으로 정리하려는 시도다. MCP 서버가 데이터·도구를 “표준 인터페이스로 노출”하고, MCP 클라이언트(대개 LLM이 내장된 호스트 애플리케이션 내부 구성요소)가 서버에 접속하여 리소스 조회 및 도구 실행을 수행하는 방식으로, 확장 가능한 연결 구조를 지향한다. 공식 문서에서는 MCP를 AI 애플리케이션을 외부 시스템에 연결하는 “범용 포트”에 비유하기도 한다.
2. 아키텍처와 통신 방식
MCP는 JSON-RPC 2.0 메시지 형식을 기반으로 호스트(Host), 클라이언트(Client), 서버(Server) 간 통신을 정의한다. 표준 메시지 포맷과 상태 기반 세션, 그리고 상호 기능 협상(capability negotiation)을 통해 다양한 서버 기능을 같은 방식으로 다루도록 한다.
2.1 역할 분리: Host·Client·Server
- Host: LLM이 내장된 애플리케이션(예: 데스크톱 AI 앱, IDE, 챗 인터페이스)으로, MCP 연결을 시작하고 사용자 경험(UI/권한/동의)을 책임진다.
- Client: Host 내부에서 MCP 서버와 실제로 통신하는 커넥터 계층이다. 서버 기능을 발견하고 호출하며, 결과를 Host가 LLM에 제공할 수 있도록 정리한다.
- Server: 데이터 소스 또는 실행 가능한 기능(도구)을 MCP 규격으로 제공하는 서비스다. 파일·DB·SaaS API·사내 시스템 등을 “표준화된 리소스/도구”로 노출한다.
2.2 전송(Transport): 로컬과 원격을 모두 고려
MCP는 JSON-RPC 메시지를 어떤 경로로 주고받을지에 대한 전송 계층을 정의하며, 프로토콜 개정에 따라 권장 방식이 발전해 왔다. 초기 규격에서는 stdio(표준입출력)와 HTTP+SSE(Server-Sent Events)가 표준 전송 방식으로 제시되었고, 이후 개정에서는 원격 서버 운영에 더 적합한 Streamable HTTP가 표준 전송 방식에 포함되었다.
- stdio: 로컬 환경에서 Host가 서버 프로세스를 실행하고 표준입출력으로 JSON-RPC 메시지를 교환한다. 개발 및 로컬 통합에 적합하다.
- HTTP 기반 전송: 원격 서버 운영과 다중 클라이언트 접속을 고려한다. 개정 스펙에서는 Streamable HTTP가 표준 전송 방식으로 다루어진다.
3. 주요 구성 요소: Resources·Prompts·Tools와 클라이언트 기능
MCP는 서버가 제공할 수 있는 핵심 기능을 Resources, Prompts, Tools로 정리한다. 또한 서버가 더 능동적으로 동작할 수 있도록, 클라이언트가 제공할 수 있는 기능(예: Sampling, Roots, Elicitation)도 별도로 정의한다.
3.1 서버 기능(Server Features)
- Resources: 문서, 레코드, 파일, 검색 결과 등 “맥락과 데이터”를 표준화된 형태로 제공한다. LLM이 답변을 구성할 때 필요한 근거 정보로 활용될 수 있다.
- Prompts: 사용자가 반복적으로 수행하는 작업을 템플릿화하거나, 특정 워크플로를 유도하기 위한 메시지·절차를 제공한다.
- Tools: 서버가 제공하는 실행 가능한 함수(예: 티켓 생성, 데이터 조회 쿼리 실행, 파일 변환, 배포 트리거 등)로, LLM이 “행동”을 수행하기 위한 인터페이스가 된다.
3.2 클라이언트 기능(Client Features)
- Roots: 서버가 작업 범위(예: 허용된 파일 경로, URI 범위)를 질의하여 안전한 경계 안에서만 동작하도록 돕는다.
- Sampling: 서버가 Host/클라이언트에 LLM 상호작용을 요청하는 형태로, 에이전트적(재귀적) 동작을 지원한다.
- Elicitation: 서버가 추가 정보가 필요할 때 사용자에게 질의하도록 요청하는 메커니즘이다.
3.3 보안과 신뢰(Trust & Safety) 고려
MCP는 외부 데이터 접근과 도구 실행을 표준화하기 때문에 강력하지만, 그만큼 권한·동의·데이터 보호가 핵심 전제가 된다. 최신 스펙은 사용자 동의 및 통제, 데이터 프라이버시, 도구 실행 안전성, 샘플링 승인 통제 등 구현자가 따라야 할 보안 원칙을 명시한다. 즉, MCP 자체가 모든 위험을 자동으로 제거하는 것이 아니라, Host와 서버 구현이 “사용자 승인 흐름과 접근 제어”를 설계해야 한다는 관점이 강하다.
4. 채택(Adoption)과 생태계 확장, 반응(Reception)
4.1 초기 공개와 레퍼런스 서버
Anthropic은 MCP 공개와 함께 스펙·SDK, Claude Desktop의 로컬 MCP 서버 지원, 그리고 레퍼런스 MCP 서버 모음을 제시했다. 공식 발표에서는 Google Drive, Slack, GitHub, Git, Postgres, Puppeteer 등 실무에서 자주 쓰이는 시스템을 연결하는 예시 서버를 제공하여 “표준의 실용성”을 강조했다. 또한 Block, Apollo 등의 초기 도입 사례와 개발 도구 기업들의 관심이 언급되었다.
4.2 도구·프레임워크와의 결합
MCP는 특정 벤더에 종속되지 않는 개방형 프로토콜을 지향하므로, 다양한 프레임워크가 MCP 서버의 도구를 에이전트가 사용할 수 있도록 연결 계층을 제공하는 흐름이 나타났다. 예를 들어 LangChain은 MCP 서버의 도구를 에이전트가 활용할 수 있도록 어댑터를 안내하며, Spring AI는 자바 진영에서 MCP 클라이언트/서버 구현을 지원하는 방향으로 문서화하고 있다.
4.3 업계 반응과 사례 중심 확산
기술 매체들은 MCP를 “AI 에이전트가 다양한 시스템에서 맥락을 가져오고 작업을 수행하기 위한 표준화”라는 관점에서 다뤄 왔다. 또한 디자인·개발 워크플로처럼 맥락의 품질이 결과물을 좌우하는 분야에서 MCP 서버를 활용하려는 움직임도 보도되었다(예: 디자인 데이터를 개발 도구/AI 코드 생성에 연결하는 사례 등).
5. MCP가 가능하게 하는 것과 구축 시작(Start Building)
5.1 What can MCP enable?
MCP는 “모델이 외부 시스템을 이해하고 조작할 수 있는 통로”를 표준화한다. 대표적으로 다음과 같은 방향의 구현이 가능하다.
- 개인 비서형 에이전트: 캘린더·노트·문서 저장소 등 개인/팀 도구를 연결하여 일정 조회, 문서 요약, 작업 생성 같은 흐름을 자동화한다.
- 개발 생산성: 코드 저장소, 이슈 트래커, 문서, CI/CD 도구를 MCP 서버로 노출해 IDE 또는 코드 에이전트가 더 정확한 맥락에서 변경을 제안하도록 한다.
- 엔터프라이즈 데이터 분석: 여러 데이터베이스·BI 자산을 통합하여 자연어 기반 분석 및 리포팅 자동화를 구현한다.
- 도메인 특화 워크플로: 사내 규정, 템플릿, 승인 절차를 Prompts/Tools로 구조화하여 반복 업무를 표준화한다.
5.2 Why does MCP matter?
MCP의 의미는 단순한 “또 하나의 도구 연동 방식”이 아니라, AI 애플리케이션과 외부 시스템 사이의 연결을 프로토콜 수준에서 규격화한다는 데 있다. 이는 (1) 통합 비용을 낮추고, (2) 도구·데이터 제공자와 소비자의 결합도를 줄이며, (3) 보안·권한·감사(로그) 같은 운영 요구사항을 Host 중심으로 설계하기 쉽게 만든다. 결과적으로 여러 모델/클라이언트가 같은 서버를 재사용하거나, 같은 클라이언트가 여러 서버를 조합하는 구성이 현실적인 선택지가 된다.
5.3 Start Building: 시작 방법
- 공식 문서에서 아키텍처와 개념 확인: 서버 기능(Resources/Prompts/Tools)과 클라이언트 기능(Roots/Sampling/Elicitation)을 먼저 구분하는 것이 설계의 출발점이다.
- 레퍼런스 서버 활용: 공식 레퍼런스 서버 저장소와 레지스트리를 참고하면, 인증·권한·데이터 접근 범위를 어떻게 설계하는지 패턴을 빠르게 파악할 수 있다.
- 전송 방식 선택: 로컬 통합은 stdio, 원격 운영은 HTTP 기반 전송을 중심으로 고려한다. 조직 환경에서는 인증·권한 부여가 필수이므로 보안 문서와 권장사항을 함께 검토한다.
- 프레임워크 연계: LangChain, Spring AI 등 사용 중인 프레임워크에서 MCP 연계 지원 수준과 구현 방식을 확인하고, 필요 시 전용 어댑터를 사용한다.
5.4 Learn more
MCP는 스펙이 개정되며 전송 방식 등 세부 사항이 변화할 수 있으므로, 구현 시점의 공식 스펙 버전과 변경 로그를 확인하는 것이 중요하다. 또한 보안 모범 사례(사용자 동의, 데이터 최소화, 도구 실행 승인, 로그 및 접근 제어)를 Host/서버 설계에 반영해야 한다.
출처
- https://www.anthropic.com/news/model-context-protocol
- https://modelcontextprotocol.io/docs/getting-started/intro
- https://modelcontextprotocol.io/specification/2025-11-25
- https://modelcontextprotocol.io/specification/2024-11-05/basic/transports
- https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
- https://github.com/modelcontextprotocol/modelcontextprotocol
- https://github.com/modelcontextprotocol/servers
- https://docs.langchain.com/oss/python/langchain/mcp
- https://docs.spring.io/spring-ai/reference/api/mcp/mcp-overview.html
- https://techcrunch.com/2024/11/25/anthropic-proposes-a-way-to-connect-data-to-ai-chatbots/
- https://www.theverge.com/news/679439/figma-dev-mode-mcp-server-beta-release
© 2026 TechMore. All rights reserved. 무단 전재 및 재배포 금지.
기사 제보
제보하실 내용이 있으시면 techmore.main@gmail.com으로 연락주세요.


