엔지니어링Mar 28, 2026

MCP가 AI 통합의 USB-C가 된 과정 — 기술적 딥다이브

Engineering Team

N x M 통합 문제

Model Context Protocol이 존재하기 전, AI 모델을 외부 도구에 연결하는 것은 조합 폭발의 작업이었습니다. 모든 AI 애플리케이션(Claude, GPT, Gemini, Copilot)은 모든 도구(Slack, Jira, GitHub, 데이터베이스, API)에 대해 커스텀 통합이 필요했습니다. M개의 AI 애플리케이션과 N개의 도구가 있으면 업계는 M x N개의 커스텀 어댑터가 필요했으며, 각각 고유한 인증 흐름, 데이터 형식, 오류 처리, 유지보수 부담이 있었습니다.

규모를 생각해 보세요. 2025년까지 약 20개의 주요 AI 애플리케이션 플랫폼과 수백 개의 엔터프라이즈 도구가 존재했습니다. 이 수학은 지속 불가능했습니다. 모든 새로운 AI 플랫폼은 통합을 처음부터 다시 구축해야 했습니다. 모든 새로운 도구는 모든 AI 플랫폼에 대해 어댑터를 작성해야 했습니다. 이것은 USB 이전에 하드웨어 업계가 직면한 것과 같은 문제였습니다. 모든 장치가 고유한 커넥터를 가지고 있었고, 모든 컴퓨터가 다른 포트를 필요로 했습니다.

MCP는 USB-C가 커넥터 문제를 해결한 것과 같은 방식으로 이를 해결합니다: 인터페이스의 표준화. MCP에서는 모든 AI 애플리케이션이 하나의 MCP client를 구현하고, 모든 도구가 하나의 MCP server를 구현합니다. M x N 문제가 M + N이 됩니다. 하나의 프로토콜, 유니버설 호환성.

프로토콜 아키텍처: JSON-RPC, Capabilities, 세 가지 프리미티브

MCP는 JSON-RPC 2.0 위에 구축되어 있습니다. 이것은 모든 최신 코드 에디터를 구동하는 Language Server Protocol(LSP)과 같은 경량 RPC 프로토콜입니다. 이것은 의도적인 설계 선택이었습니다. JSON-RPC는 간단하고, 잘 이해되며, 언어에 구애받지 않고, 실전에서 검증되었습니다.

기능 협상

MCP 연결은 initialize 핸드셰이크로 시작되며, client와 server가 서로 기능을 선언합니다. 이를 통해 프로토콜의 우아한 진화가 가능합니다. 새로운 기능은 새로운 capability 플래그로 추가되며, 이전 client나 server는 알 수 없는 capability를 무시할 수 있습니다.

세 가지 프리미티브

MCP는 세 가지 핵심 프리미티브를 정의합니다:

Tools: AI 모델이 호출하는 함수. tools/list로 발견하고 tools/call로 실행합니다. 각 도구에는 JSON Schema로 정의된 이름, 설명, 입력 스키마가 있습니다.
Resources: AI 모델이 읽는 데이터. URI로 식별되며 resources/read로 가져옵니다. 파일, 데이터베이스 레코드, API 응답 등을 포함합니다.
Prompts: 서버가 제공하는 재사용 가능한 프롬프트 템플릿. prompts/list로 발견하고 prompts/get으로 가져옵니다. AI가 서버의 도메인 특화 작업에 효과적으로 접근하는 방법을 표준화합니다.

Function Calling 및 OpenAPI와의 비교

MCP의 위치를 이해하기 위해 두 가지 주요 대안과 비교해 봅시다.

MCP vs Function Calling

Function calling(OpenAI, Anthropic 등이 사용)은 각 API 요청에 인라인으로 도구 정의를 포함합니다. 개발자가 JSON Schema로 도구를 설명하고, LLM이 호출할 도구와 매개변수를 선택합니다.

측면	Function Calling	MCP
도구 정의	API 요청에 인라인	외부 서버에서 정의
발견	없음(개발자 제공)	동적(tools/list로 발견)
상태	스테이트리스(요청별)	스테이트풀(세션 기반)
트랜스포트	HTTPS API 호출	stdio, SSE, Streamable HTTP
표준화	벤더 특화	오픈 스탠다드
복수 도구	수동 오케스트레이션	프로토콜 네이티브

MCP vs OpenAPI

OpenAPI(구 Swagger)는 REST API를 설명하는 사양입니다. AI가 직접 OpenAPI 사양을 읽고 API 호출을 생성할 수도 있지만, 몇 가지 중요한 차이점이 있습니다.

측면	OpenAPI	MCP
목적	REST API 문서화	AI-도구 통신
AI 최적화	없음(범용)	AI 상호작용용 설계
세션 관리	없음	내장
타입 안전성	JSON Schema	JSON Schema + 런타임 검증
리소스 모델	URL + HTTP 메서드	URI + 리소스 타입

채택 타임라인

MCP의 진화를 추적해 봅시다:

2024년 11월: Anthropic이 MCP를 오픈 소스로 릴리스. 초기 버전은 stdio 트랜스포트만 지원.
2025년 Q1: Claude Desktop, Cursor, Windsurf가 MCP 지원 통합. 개발자 커뮤니티 급속 확대.
2025년 Q2: SSE 트랜스포트 추가. 원격 MCP 서버 실용화.
2025년 Q3: OpenAI가 MCP 지원 발표. Google DeepMind가 Gemini에 MCP client 통합.
2025년 Q4: Streamable HTTP 트랜스포트 릴리스. 엔터프라이즈 채택 가속.
2026년 Q1: Microsoft가 Copilot 플랫폼에 MCP 채택. MCP Registry(공식 서버 카탈로그) 출시.
2026년 Q2: MCP가 사실상의 AI 도구 통신 표준으로 자리매김. 1,000개 이상의 공식 서버가 Registry에 등록.

에이전트 간 통신의 미래

MCP의 다음 진화는 에이전트 간(A2A) 통신입니다. 현재 MCP는 AI 애플리케이션(host)과 외부 도구(server) 간의 통신을 정의하지만, AI 에이전트 간의 직접 통신 기능은 아직 초기 단계입니다.

미래 비전:

에이전트가 MCP 서버를 노출: 각 AI 에이전트가 자체 MCP 서버를 가지고, 다른 에이전트가 사용 가능한 도구로 발견 및 호출 가능
멀티 에이전트 오케스트레이션: MCP 게이트웨이가 여러 에이전트 간의 작업 위임 및 데이터 흐름 관리
표준화된 위임 프로토콜: 에이전트가 복잡한 작업을 하위 작업으로 분해하고 전문화된 에이전트에 위임하는 표준 방법

FAQ

Q: MCP는 LSP(Language Server Protocol)와 관련이 있나요? A: 네. MCP는 LSP에서 영감을 받았습니다. 둘 다 JSON-RPC 2.0을 사용하고, capability negotiation 패턴을 사용하며, client-server 아키텍처를 따릅니다. LSP가 코드 에디터를 프로그래밍 언어 지원에서 분리한 것처럼, MCP는 AI 애플리케이션을 도구 통합에서 분리합니다.

Q: MCP 서버를 공개할 때의 보안 위험은? A: 주요 위험에는 인증 우회, 도구 남용, 데이터 유출, 서비스 거부가 있습니다. OAuth 2.0 인증, 입력 검증, 속도 제한, 도구 수준 권한 부여, 모든 도구 호출의 감사 로깅이 대책으로 필수적입니다.

Q: 기존 REST API를 MCP 서버로 변환할 수 있나요? A: 네. 각 API 엔드포인트를 MCP 도구로 래핑하는 것이 일반적인 패턴입니다. OpenAPI 사양에서 MCP 서버를 자동 생성하는 도구도 사용 가능합니다.

Q: MCP의 성능 오버헤드는 얼마나 되나요? A: JSON-RPC 프로토콜의 오버헤드는 최소한입니다. stdio 트랜스포트에서는 마이크로초, HTTP 트랜스포트에서는 일반적인 HTTP 요청과 동등합니다. 병목은 보통 도구 실행 자체(데이터베이스 쿼리, API 호출)에 있습니다.

Q: MCP 메시지에 크기 제한이 있나요? A: 프로토콜 자체에는 크기 제한이 없습니다. 실제 제한은 트랜스포트와 인프라에 따라 다릅니다. 프로덕션 배포에서는 개별 도구 응답을 10 MB 이하로 유지하고, 큰 데이터 세트에는 페이지네이션이나 스트리밍을 사용하세요.

태그

AI Rust