MCP는 Model Context Protocol의 약자로, 대부분의 사람들이 이를 단순히 또 다른 API 표준처럼 취급하지만, 사실 그 이상의 의미를 가지고 있습니다. MCP의 핵심은 AI 애플리케이션과 서버 간의 컨텍스트 교환을 위한 표준화된 프로토콜이며, 내장된 탐색(discovery) 및 전송 계층 인증(transport-layer authentication) 기능을 갖추고 있습니다. 아키텍처를 어떻게 설계하느냐에 따라 컴플라이언스(compliance) 및 거버넌스(governance) 계층으로 확장될 수 있지만, 진정한 힘은 탐색 메커니즘과 그것이 가져오는 표준화에 있습니다. 만약 여러분이 에이전트를 사용 중인 API에 연결하는 용도로만 MCP를 사용한다면, MCP가 할 수 있는 능력의 10%만을 사용하는 것입니다. 이 글은 여러분이 프로토콜 전문가가 아니더라도, 가장 단순한 개념부터 가장 깊은 개념에 이르기까지 나머지 90%를 이해할 수 있도록 돕기 위한 것이며, 글을 다 읽을 때쯤이면 여러분은 조금 더 전문가에 가까워질 것입니다.

왜 MCP가 다른지 이해하려면 오늘날 REST API가 어떻게 작동하는지 생각해 보십시오. 여러분은 문서를 읽어야 하고, 엔드포인트(endpoints)를 이해해야 하며, 호출을 구축하고, 인증을 처리하고, 모든 통합(integration)을 위한 코드를 작성해야 합니다. 만약 API가 변경되면 여러분의 코드는 깨집니다. 반면 MCP를 사용하면 에이전트가 모든 것을 실시간으로 탐색합니다. MCP 서버가 스스로를 설명하기 때문에 외부 문서가 필요하지 않으며, 서버가 자신의 위치를 알려주기 때문에 URL을 하드코딩할 필요가 없습니다. 또한 프로토콜이 토큰을 대신 주입해주기 때문에 인증을 수동으로 처리할 필요도 없습니다. 이는 누군가에게 지도를 주는 것과 스스로 업데이트되는 GPS를 주는 것의 차이와 같습니다. 이를 이해하면 MCP가 REST와 경쟁하는 것이 아니라, 모든 통합을 새로운 프로젝트로 만드는 '표준화의 부재'와 경쟁한다는 사실을 깨닫게 될 것입니다.

이 프로토콜은 원격 호출을 위한 경량 표준인 JSON-RPC 2.0 위에서 실행되며, 각 MCP 서버는 세 가지를 노출합니다: 에이전트가 호출할 수 있는 도구 (tools), 에이전트가 읽을 수 있는 리소스 (resources), 그리고 에이전트가 템플릿으로 사용할 수 있는 프롬프트 (prompts)입니다. 하지만 흥미로운 점은 무엇을 노출하느냐가 아니라 어떻게 노출하느냐에 있습니다. MCP 서버는 에이전트에게 단순히 "이러한 기능들을 가지고 있습니다"라고 말하는 데 그치지 않고, 단일 JSON 메시지 내에서 "각 기능이 기대하는 매개변수는 이것이며, 이것은 검증 스키마(validation schemas)이고, 인증 방식은 다음과 같습니다"라고 함께 전달하기 때문입니다. 만약 서버의 API를 업데이트해야 한다면, 단순히 설명(description)을 변경하기만 하면 됩니다. 그러면 에이전트는 코드 업데이트, 릴리스, 다운타임 없이 자동으로 적응합니다.

MCP 명세(specification)에 정의된 두 가지 전송 방식(transports)이 있으며, 각각 용도가 다릅니다. MCP 서버가 에이전트의 하위 프로세스(subprocess)로 실행되는 로컬 개발을 위한 Stdio 방식, 그리고 네트워크 지연 시간(latency)이 중요한 원격 서버를 사용하는 프로덕션 환경을 위한 Streamable HTTP 방식이 있습니다. 프로덕션 환경의 대부분의 서버는 기존의 부하 분산(load balancing) 및 TLS 인프라와 가장 호환성이 높은 Streamable HTTP를 사용하지만, 탐색(discovery) 과정에서는 전송 방식을 구분하지 않습니다. 에이전트는 URL을 수신하고 스키마를 기반으로 어떻게 연결할지 결정합니다.

이 지점이 MCP가 정말 흥미로워지는 부분입니다. 에이전트가 도구를 찾기 위해 설정 파일(configuration file)을 필요로 해서는 안 되며, 자동으로 이를 발견해야 하기 때문입니다. MCP 명세는 기능 협상(capability negotiation)을 포함한 초기화와 tools/list와 같은 표준 탐색 방법을 정의하지만, 이를 넘어 다단계 탐색 아키텍처(multi-phase discovery architecture)를 구축할 수 있습니다. 다음은 저의 연구와 경험을 바탕으로 제안하는 6단계 시스템입니다:

첫 번째 단계는 로컬 캐시(local cache)입니다. 이전에 발견한 서버가 있다면 메모리에 저장되어 네트워크 호출 없이 즉시 사용됩니다. 두 번째 단계는 OAuth 2.0 Protected Resource Metadata (RFC 9728)를 따릅니다. 여기서 에이전트(agent)는 well-known 구성 엔드포인트를 요청하고, 서버는 자신의 기능(capabilities), 인증 요구 사항(auth requirements), 그리고 도구 정의(tool definitions)를 표준화된 JSON 형식으로 응답합니다. 세 번째 단계는 알려진 호스트가 RFC 8615를 따르는 /.well-known/mcp/server.json 파일을 보유하고 있는지 확인하는 것입니다. 이는 모든 서버가 가질 수 있는 명함과 같습니다. 네 번째 단계는 MCP 서버의 공개 디렉토리인 registry.modelcontextprotocol.io/v0.1/servers에 있는 Anthropic Registry API를 쿼리합니다. 이는 에이전트 도구용 앱 스토어와 같습니다. 다섯 번째 단계는 신뢰할 수 있는 노드 간의 P2P 가십(P2P gossip)을 사용하며, 여기서 에이전트들은 친구가 식당을 추천해 주는 것처럼 발견된 정보를 공유합니다. 여섯 번째 단계는 GitHub Topics 및 crates.io의 커뮤니티 인덱스를 확인합니다. 이 모든 과정은 핫 캐시(hot cache) 모드에서는 2초 미만, 콜드 모드(cold mode)에서는 10초 미만으로 수행될 수 있으며, 그 결과로 기능, 인증 및 신뢰 수준(trust level)이 포함된 검증된 서버 목록이 생성됩니다.

하지만 서버를 발견하는 것은 첫 번째 단계일 뿐입니다. 목록을 확보한 후에는 각 서버를 신뢰할 수 있는지 알아야 하기 때문입니다. 바로 이 지점에서 MCP는 대부분의 사람들이 너무 늦을 때까지 간과하는 보안 모델을 가지고 있습니다. 과장이 아니라, Invariant Labs의 MCP 보안 연구에 따르면 공개 MCP 서버에서 도구 오염(tool poisoning) 취약점이 발견되었습니다. 또한 OWASP MCP Top 10 (2025)에는 도구 오염(Tool Poisoning), 커맨드 인젝션(Command Injection), 공급망 공격(Supply Chain Attacks)과 같은 서버 측 리스크가 포함되어 있으므로, 신뢰 점수(trust scoring) 산정은 선택이 아닌 필수입니다.

각 MCP 서버는 SHA-256을 사용하여 암호학적으로 서명된 카드(cryptographically signed card)를 보유해야 하며, 만약 Sigstore를 사용한다면 서명된 이메일이 실제로 발신자가 주장하는 사람으로부터 온 것인지 확인하는 것과 마찬가지로 중앙 기관 없이도 서명을 검증할 수 있습니다. 또한, 서버가 어떻게 빌드되었는지, 통제된 환경에서 빌드되었는지, 종속성(dependencies)이 안전한지, 바이너리가 비트 단위로 재현 가능한지(bit-for-bit reproducible)를 알려주는 OpenSSF 인증 레벨인 SLSA provenance가 있습니다. 프로덕션급(production-grade) MCP 서버에는 SLSA L2-L3 증명(attestations)이 권장됩니다.

신뢰 점수(Trust scoring)는 이 모든 요소를 사용자의 필요에 맞게 조정할 수 있는 공식으로 결합합니다. 간단한 버전은 다음과 같습니다: Score = w1 × LatencyNorm + w2 × TrustScore + w3 × ComplianceMatch + w4 × Freshness. 여기서 TrustScore는 SLSA 레벨, Sigstore 보유 여부, 마지막 감사(audit)의 최신성, 커뮤니티 지지(endorsements) 수 등을 살펴보며, 이 모든 항목은 지역(region)과 섹터(sector)에 따라 가중치가 부여됩니다. 예를 들어, 유럽에 있다면 아시아에서 오는 지연 시간(latency)이 높은 서버는 유용하지 않으며, 금융 분야에 있다면 SOC2 준수(compliance)가 되지 않은 서버 역시 유용하지 않기 때문입니다. 참고로 이 공식은 저의 경험을 바탕으로 한 제안일 뿐입니다. MCP 사양(spec)은 신뢰 점수 시스템을 정의하지 않으므로, 이는 각 팀이 자체적인 필요에 따라 구축해야 하는 영역입니다.

이 지점에서 MCP는 진정으로 복잡해지면서 동시에 매우 흥미로워집니다. 왜냐하면 세상에 단 하나의 MCP만 존재하는 것이 아니라, 서로 다른 수준의 성숙도를 가지고 다르게 진화하는 7개의 지역적 생태계가 존재하기 때문입니다. 미국에서는 Anthropic의 주요 레지스트리(registry)가 중심이며, OAuth 동적 클라이언트 등록(Dynamic Client Registration) 기능을 갖춘 AWS Bedrock Gateway의 지원을 받습니다. 하지만 흔한 과제는 많은 서버가 여전히 OAuth 2.1 대신 정적 API 키(static API keys)에 의존하고 있다는 점인데, 이는 유출된 API 키를 선택적으로 취소할 수 없기 때문에 보안상의 우려가 됩니다. 중국의 경우 MCP 생태계는 여전히 형성 단계에 있으며, 국내 제공업체들이 커뮤니티 주도의 어댑터(adapters)와 브리지(bridges)를 통해 MCP 호환성을 탐색하고 있으나, 데이터 주권 규제로 인해 통합된 레지스트리는 존재하지 않습니다.

유럽에는 중앙 레지스트리가 없습니다. 유럽의 디지털 전략이 연합형(federated) 구조를 취하고 있기 때문입니다. 각 MCP 서버는 이상적으로 OAuth 2.1 인증 지원, 입력 스키마(input schemas)를 포함한 도구 설명, 그리고 데이터 처리 위치에 대한 투명성을 포함한 공개된 보안 태세(security posture)를 갖추어야 합니다. 또한 EU AI Act(유럽 AI 법)는 제13조에서 투명성 요구 사항을, 제12조에서 기록 보관(record-keeping)을 규정하고 있으며, 이는 MCP 서버가 감사 추적(audit trails)을 유지하는 방식에 직접적인 영향을 미칩니다.

일본의 접근 방식은 기업용 SSO(Single Sign-On)와 쓰기 작업(write operations)을 위한 물리적 하드웨어 토큰을 사용하는 제로 트러스트(zero trust) 모델입니다. 이는 경제산업성(METI)이 자율적인 의사결정에는 명시적인 인간의 개입이 필요하다고 규정하고 있기 때문입니다. 또한 IPA(정보처리추진기구)는 외부 도구로부터 유입된 오염된 데이터가 LLM(대규모 언어 모델)을 손상시키는 독성 에이전트 흐름 공격(toxic agent flow attacks)을 방지하기 위해 마이크로샌드박스(microsandboxes) 내에서의 격리를 권장합니다. 일본 연구진들은 이러한 패턴을 광범위하게 문서화했으며, 측면 이동(lateral movement)을 방지하기 위해 강화된 컨테이너(hardened containers) 사용을 권고하고 있습니다.

한국에서는 Naver Cloud가 HyperCLOVA X 모델에 MCP 호환성을 통합하고 있으며, Naver 검색, 지도, 뉴스 및 Kakao API를 MCP 도구로 매핑하는 kimcp와 같은 커뮤니티 브리지(bridge)들이 존재합니다. Samsung은 각 도구 실행의 잠재적 영향에 따라 Green, Amber, Red로 구분되는 위험 구역(risk zone) 시스템을 사용하며, PIPA는 국경 간 데이터 전송에 엄격한 제한을 두어 한국 국내 데이터는 반드시 한국 내 로컬 인프라에 머물러야 함을 의미합니다.

중동 지역의 경우, 2026년 UAE AI 법(UAE AI Act)은 AI 시스템을 네 가지 위험 계층으로 분류하며, 규제 대상 섹터에서 MCP 서버를 배포하는 조직은 도구 거버넌스(tool governance)를 이러한 요구 사항에 맞춰야 합니다. 사우디아라비아에서는 SDAIA가 AI 윤리 원칙(AI Ethics Principles)과 절대적인 데이터 현지화를 명령하는 PDPL을 시행하고 있으며, 인증은 국가 전자 신원 시스템인 UAE Pass를 통해 이루어집니다.

인도에서는 MeitY가 7가지 수트라(sutras)를 포함한 AI 거버넌스 가이드라인(AI Governance Guidelines)을 발표하였으며, 이에 따라 MCP 서버는 광범위한 도구 설명, 투명한 데이터 계보(data lineage), 그리고 영향 평가를 위한 상세한 텔레메트리(telemetry)를 갖추어야 합니다. 싱가포르는 레지스트리(registry)라기보다는 테스트 프레임워크인 IMDA AI Verify Toolkit v2.0을 보유하고 있으나, 금융 섹터의 MCP 서버는 자율 실행 승인을 받기 전 공정성과 견고함을 입증하기 위해 AIVT Veritas 통합 플러그인을 통과해야 합니다.

Google은 2026년에 MCP의 직접적인 경쟁자로 A2A(Agent-to-Agent)를 출시했으나, 근본적인 차이점은 MCP가 에이전트가 도구를 발견하는 클라이언트-서버(client-to-server) 프로토콜인 반면, A2A는 에이전트들이 서로 통신하여 작업을 조정하고 위임하는 에이전트-에이전트(agent-to-agent) 프로토콜이라는 점입니다. 비록 일부 측면에서 경쟁 관계에 있지만, 이들은 실제로 상호 보완적입니다. 즉, MCP는 도구의 발견 및 실행을 위한 것이고, A2A는 에이전트 간의 협업을 위한 것입니다.

앞으로 몇 달 동안은 강제적인 OAuth 2.1 표준화가 진행될 것입니다. 현재 서버의 단 8.5%만이 동적 인증 (dynamic authentication)을 사용하고 있으며, 이는 매우 큰 보안 문제입니다. 또한, 프로덕션급 MCP 서버를 위해서는 SLSA L2-L3 증명 (attestations)이 권장됩니다. 또한, MCP 서버가 정확한 위치를 드러내지 않고도 자신의 출처를 증명할 수 있게 해주는 유럽의 검증 가능한 자격 증명 (verifiable credentials) 시스템과의 통합, 그리고 MCP 서버가 호출 간에 추론 캐시 (inference cache)를 공유할 수 있는 KV 캐시 공유 (KV cache sharing)가 도입될 것입니다. 이는 두 에이전트가 동일한 서버에 동일한 질문을 던질 경우, 두 번째 에이전트가 응답을 초 단위가 아닌 밀리초 단위로 받게 됨을 의미하며, 이는 에이전트 메시 (agent meshes) 내의 공유 캐시 패턴에서 10배(an order of magnitude) 이상의 개선을 가져옵니다.

만약 당신이 에이전트를 구축하고 있다면, 다음 단계는 API를 만드는 것이 아니라 MCP 서버를 노출하는 것입니다. 왜냐하면 API와 MCP 서버의 차이는 에이전트에게 물고기를 주는 것과 물고기 잡는 법을 가르치는 것의 차이이기 때문입니다. API가 하드코딩된 에이전트는 오직 한 가지 일만 할 줄 알지만, MCP 발견 (discovery) 기능이 있는 에이전트는 당신이 코드 한 줄 건드리지 않고도 새로운 도구를 찾아내고, 사용법을 익히며, 새로운 컨텍스트에 적응할 수 있습니다. 언어 모델의 능력은 점점 향상되는 반면 통합 프로토콜은 점점 더 복잡해지는 세상에서, 승자는 가장 똑똑한 에이전트를 만드는 사람이 아니라 가장 잘 연결된 생태계를 구축하는 사람이 될 것입니다.

용어 사전 (Glossary)

A2A — 에이전트 간의 통신을 위한 Google의 프로토콜로, MCP와 유사하지만 피어 투 피어 (peer-to-peer) 방식입니다.

CAC — 중국 사이버 공간 관리국 (Cyberspace Administration of China)으로, 중국의 데이터 주권을 규제합니다.

DNS-SD — 네트워크에서 프린터를 찾는 것과 같이 이름으로 서비스를 발견하기 위한 인터넷 표준입니다.

Gaia-X — 데이터 주권을 위한 유럽의 이니셔티브로, 연합형 데이터 인터넷을 지향합니다.

HITL — Human In The Loop (인간 참여형), 실행 전 사람이 특정 작업을 승인해야 함을 의미합니다.

JSON-RPC 2.0 — 원격 호출을 위한 경량 프로토콜로, MCP 서버가 사용하는 언어입니다.

KV Cache — 이전 모델 계산을 반복하지 않기 위한 임시 저장소입니다.

MCP — Model Context Protocol (모델 컨텍스트 프로토콜), 에이전트가 도구를 발견하고 사용할 수 있도록 하는 프로토콜입니다.

OAuth 2.1 — 위임 인증 (Delegated authentication) 표준으로, 앱에 비밀번호를 제공하지 않고도 데이터에 접근할 수 있도록 허용하는 방식입니다.

PIPA — 개인정보 보호법 (Personal Information Protection Act), 한국의 법률로 GDPR과 유사합니다.

SHA-256 — 파일의 고유한 디지털 지문(digital fingerprint)을 생성하는 해시 함수 (Hash function)입니다.

Sigstore — 중앙 기관의 필요 없이 암호화 서명을 수행하는 시스템입니다.

SLSA — 소프트웨어 공급망 보안 프레임워크 (Software supply chain security framework)로, 레벨 1부터 3까지의 단계를 가집니다.

Streamable HTTP — 원격 서버를 위한 HTTP 기반의 MCP 전송 (transport) 방식입니다.

UAE AI Act — 아랍에미리트 AI 법 (United Arab Emirates AI Law) 2026으로, AI 시스템을 4가지 위험 수준으로 분류합니다.

Verifiable Credential — 중앙 기관에 문의하지 않고도 검증 가능한 디지털 인증서입니다.