MCP 로드맵 2026.03.09 발표 기준
MCP 프로토콜, 서버 1만 개인데
53%가 이 문제입니다
MCP 프로토콜의 월간 SDK 다운로드가 9,700만 건을 넘었습니다. 그런데 공식 보안 연구 결과를 보면 커뮤니티 서버 절반 이상이 회전조차 안 되는 정적 API 키 하나에 의존하고 있습니다. 숫자가 크다고 생태계가 건강하다는 뜻은 아닙니다.
MCP 프로토콜이 뭔지, 짧게 정리합니다
MCP(Model Context Protocol)는 2024년 11월 25일 Anthropic이 오픈소스로 공개한 표준 통신 프로토콜입니다. 한 마디로 정의하면 “AI 모델이 외부 도구·데이터·시스템과 대화하는 방법을 통일한 표준”입니다. 공식 스펙 기준(2025-03-26)으로 JSON-RPC 2.0을 메시지 형식으로 사용하고, 호스트·클라이언트·서버 세 계층이 서로 기능 협상을 한 뒤 리소스·도구·프롬프트를 주고받습니다. (출처: MCP 공식 스펙 문서)
이전까지 AI를 외부 도구에 연결하려면 서비스마다 따로 코드를 짜야 했습니다. 슬랙과 연결하면 슬랙 SDK, 노션과 연결하면 노션 SDK — 매번 새로운 배선 작업이었죠. MCP는 이 반복 작업을 없애주는 공통 소켓입니다. 플러그 모양이 같아지면 어떤 AI 모델이든, 어떤 도구든 같은 방식으로 붙을 수 있게 됩니다.
공개 14개월 만에 OpenAI, Google DeepMind, Microsoft Copilot Studio, Cursor, Replit이 모두 지원을 추가했고, 2025년 12월에는 Anthropic이 프로토콜 자체를 리눅스 재단 산하 Agentic AI Foundation(AAIF)에 기증했습니다. AWS, Google, Microsoft, Salesforce, Snowflake가 공동 창립자로 이름을 올린 점이 중요합니다 — 특정 회사의 표준이 아닌 업계 공용 표준이 됐다는 의미입니다. (출처: Anthropic 공식 발표, 2025.12)
서버가 1만 개? 그런데 절반은 열쇠 하나로 잠겨 있습니다
2026년 초 기준으로 공개 레지스트리에 인덱싱된 MCP 서버는 1만 개를 넘었습니다. (출처: Zuplo MCP 리포트) 이 숫자를 보고 “생태계가 활발하다”고 판단하면 절반만 맞는 얘기입니다. 실제 내용을 들여다보면 구조가 꽤 다릅니다.
💡 공식 수치와 실제 서버 품질을 같이 놓고 보니 이런 차이가 보였습니다
Astrix Security가 2025년 발표한 연구에 따르면 커뮤니티 서버의 53%가 정적 API 키 또는 PAT(Personal Access Token)만으로 인증을 처리하고 있었습니다. 이 토큰들은 수명이 길고 주기적으로 교체되지 않는 경우가 대부분입니다. 더 심각한 건 인증 자체가 없는 서버가 공개 인터넷에 1,800개 이상 노출돼 있다는 점입니다. (출처: Astrix Security, 2025) — 숫자만 보면 1만 개 생태계지만, 인증 기준으로 보면 상당 부분이 잠금장치 없이 열려 있는 셈입니다.
생태계가 세 종류로 나뉘어 있는 것도 이 현상을 설명합니다. AWS, GitHub, Stripe처럼 상업적 이해관계가 있는 벤더가 만든 서버는 인증·유지보수·업데이트 주기가 잘 관리됩니다. 반면 자원봉사 기반의 커뮤니티 서버는 비즈니스 모델이 없기 때문에 보안과 유지보수에 투자할 동기 자체가 부족합니다. “무료이고 오픈소스니까 믿을 수 있다”는 생각이 여기서 위험해집니다. 신뢰와 검증 메커니즘은 별개의 문제입니다.
실제로 사고가 났습니다 — Postmark 사례
이론적 위험이 아닌 실제 사고도 있었습니다. 2025년 9월, 주당 1,500건 다운로드를 기록하던 비공식 Postmark MCP 서버가 조용히 수정됐습니다. 이메일 발송 함수에 BCC(숨은 참조) 필드가 몰래 추가된 것인데, 이 서버를 통해 발송된 모든 이메일이 공격자 주소로 사본이 전송됐습니다. (출처: Astrix Security, 2025)
⚠️ 이 사고가 중요한 이유
사용자가 보는 화면에서는 이메일이 정상 발송된 것처럼 보였습니다. AI 에이전트도 마찬가지였죠. 변조는 도구의 코드가 아닌 서버 레지스트리의 도구 정의 레벨에서 이루어졌고, 배포 후 보안 검토 없이 실행됐습니다. OWASP GenAI Security Project가 이를 “동적 도구 불안정성(러그 풀 공격)”으로 분류한 이유가 여기 있습니다. (출처: OWASP GenAI 가이드 분석, FlowHunt, 2026.02)
MCP 서버가 일반 API와 다른 결정적인 차이도 여기서 드러납니다. 전통적인 API 보안은 사람이나 결정론적 시스템이 요청한다고 가정합니다. MCP는 AI 모델이 자연어 명령을 기반으로 런타임에 도구를 동적으로 선택합니다. 즉 AI 모델 자체가 공격 표면의 일부가 됩니다. 악의적인 도구 설명이 있으면 AI가 그것을 읽고 의도대로 따라 실행할 수 있습니다. 보안 검토가 기존 API 방식보다 한 레이어 더 복잡해지는 구조입니다.
2026 로드맵이 기술 확장 대신 이것에 집중한 이유
2026년 3월 9일 공개된 MCP 공식 로드맵을 보면 흥미로운 점이 있습니다. 새로운 기능 추가나 모델 지원 확대가 아니라, 지금 있는 것을 제대로 작동하게 하는 데 우선순위가 몰려 있습니다. (출처: MCP 공식 블로그, 2026.03.09)
💡 로드맵 구성 방식이 바뀐 것 자체가 신호입니다
이전 로드맵은 “다음 스펙 버전에 무엇이 들어가는가”를 중심으로 날짜별 릴리스로 구성됐습니다. 2026년 로드맵은 릴리스 마일스톤 대신 우선순위 영역(Priority Areas)으로 재편됐고, 워킹그룹(WG)이 타임라인을 주도하는 방식으로 바뀌었습니다. 빠르게 성장하는 오픈 표준에서 릴리스 기반 로드맵이 가정하는 예측 가능성은 현실과 맞지 않다는 것을 공식적으로 인정한 것입니다.
핵심 유지관리자들이 우선순위 영역을 직접 순위 매긴 결과, 상위 4개가 도출됐습니다. 흥미로운 것은 이 4개 중 “새 기능을 추가하겠다”는 항목이 하나도 없다는 점입니다. 스케일링 문제 해결, 세션 처리, 거버넌스 구조화, 엔터프라이즈 도입 장벽 제거 — 모두 지금 배포된 MCP가 실제 운영 환경에서 겪는 문제들입니다. 새 기능보다 운영 부채를 먼저 갚겠다는 선언입니다.
로드맵 4가지, 실제로 무슨 뜻인지
① 수평 확장 — 지금 서버는 로드밸런서 뒤에서 버틸 수 없습니다
현재 Streamable HTTP 트랜스포트는 상태 보존(Stateful) 세션을 유지합니다. 서버가 한 대일 때는 문제없지만, 로드밸런서 뒤에 여러 서버 인스턴스를 두면 세션이 꼬입니다. 어느 서버로 요청이 들어오느냐에 따라 같은 클라이언트가 다른 서버를 만날 수 있기 때문입니다. 2026 로드맵은 세션을 무상태(Stateless)로 전환해 어느 인스턴스로 요청이 가도 정상 작동하도록 개선하는 것을 1순위로 올렸습니다. (출처: MCP 공식 로드맵)
또 하나 추가되는 것이 MCP Server Cards입니다. 지금은 클라이언트가 서버에 직접 연결해야만 그 서버가 무엇을 할 수 있는지 알 수 있습니다. Server Cards는 .well-known/mcp.json 형태의 URL로 서버 메타데이터를 노출해, 연결 없이도 크롤러나 레지스트리가 서버 기능을 발견할 수 있게 합니다. 이 URL 하나가 생기면 AI 에이전트가 어떤 MCP 서버가 있는지 검색하는 방식이 완전히 달라집니다.
② 에이전트 통신 — Tasks 프리미티브의 빈 곳을 채웁니다
SEP-1686으로 출시된 Tasks 프리미티브는 “지금 호출하고 나중에 결과를 가져오는” 패턴을 지원합니다. 그런데 실제 운영에서 빠진 게 드러났습니다. 작업이 일시적으로 실패했을 때 재시도 규칙이 없고, 결과를 얼마나 보관할지 정책도 없습니다. 2026년 Agents WG가 이 두 가지 — 재시도 규칙과 만료 정책 — 를 채우는 작업을 맡았습니다.
③ 거버넌스 성숙화 — 병목은 사람이었습니다
지금은 MCP에 변경을 제안하는 SEP(Spec Enhancement Proposal)가 전부 코어 메인테이너 전체 검토를 거쳐야 합니다. 도메인 전문 WG가 이미 판단할 능력이 있어도 코어 검토를 기다려야 합니다. 2026 로드맵은 기여자 사다리(contributor ladder)를 정의하고, 검증된 WG는 해당 도메인 SEP를 코어 검토 없이 수용할 수 있도록 위임 모델을 도입합니다. 결론적으로 프로토콜 개발 속도가 빨라지고, 특정 소수에게 의존하는 구조가 줄어듭니다.
④ 엔터프라이즈 준비 — WG가 아직 없습니다
감사 추적, SSO 연동 인증, 게이트웨이 동작, 설정 이식성 — 기업이 MCP를 도입하면서 반드시 해결해야 하는 문제들입니다. 그런데 로드맵 발표 기준으로 이를 담당할 Enterprise WG가 아직 결성되지 않았습니다. 로드맵은 명시적으로 “이 분야 전문가가 직접 문제 정의에 참여해달라”고 요청하고 있습니다. 엔터프라이즈 기능 대부분은 코어 스펙이 아닌 확장(extension) 형태로 제공될 예정입니다.
MCP Apps와 UCP, 그냥 기능 추가가 아닙니다
2026년 1월, MCP 생태계에 두 가지 큰 변화가 있었습니다. 첫 번째는 MCP Apps(2026.01.26 발표)입니다. 이전까지 MCP 도구의 응답은 텍스트였습니다. MCP Apps는 도구가 대화창 안에서 직접 렌더링되는 대시보드·폼·차트 같은 인터랙티브 UI 컴포넌트를 반환할 수 있게 합니다. Claude가 처음 지원했고, VS Code·Microsoft 365 Copilot·OpenAI가 뒤따랐습니다. (출처: MCP 공식 블로그, 2026.01.26)
두 번째는 구글의 UCP(Universal Commerce Protocol)입니다. Shopify·Walmart·Target·주요 결제 네트워크가 파트너로 참여한 이 표준은 AI 에이전트가 사용자 대신 상품을 검색·비교·결제까지 완료할 수 있는 구조를 정의합니다. 중요한 것은 UCP가 MCP의 하위 프로토콜이 아니라는 점입니다. UCP는 독자적인 상거래 표준이고, MCP는 그 데이터가 이동하는 채널 중 하나입니다. MCP 서버가 상품·서비스·데이터를 노출하면 AI 에이전트가 UCP를 통해 해당 노드에서 자율 거래를 할 수 있게 됩니다. (출처: Google Developers Blog, UCP)
MCP가 도구 연결 표준으로 시작했다면, 이 두 개가 더해지면서 “AI가 보고 말하고 사는” 세 가지를 모두 다루는 인프라로 확장되고 있는 셈입니다. 솔직히 말하면, 이 두 변화가 의미하는 바를 지금 당장 체감하기는 어렵습니다. 하지만 AI 에이전트가 사람 대신 구매 결정을 내리는 시대가 온다면, MCP 서버가 그 거래의 출입구가 된다는 것은 꽤 구체적인 이야기입니다.
지금 MCP를 도입하려 한다면, 이 순서로 보세요
MCP를 처음 도입하거나 기존 환경에 추가하려 할 때, 커뮤니티 서버를 무조건 가져다 쓰는 건 지금 시점에서 위험할 수 있습니다. 먼저 확인해야 할 것이 있습니다.
🔍 서버 선택 전 확인 체크
| 확인 항목 | 벤더 공식 서버 | 커뮤니티 서버 |
|---|---|---|
| 인증 방식 | OAuth / SSO | 정적 API 키 53% |
| 도구 정의 서명 | 암호화 서명 있음 | 대부분 없음 |
| 업데이트 주기 | 예측 가능 | 불규칙 |
| 공개 인터넷 노출 | 게이트웨이 통제 | 1,800+ 무인증 노출 |
출처: Astrix Security 2025, MCP 공식 로드맵 2026.03.09
엔터프라이즈 환경이라면 지금 당장 “Enterprise WG가 없다”는 점을 감안해야 합니다. 감사 추적·SSO 연동·게이트웨이 동작에 대한 공식 스펙이 아직 없습니다. 2026 로드맵이 이것을 4번째 우선순위로 올렸으니 올해 안에 방향이 잡힐 가능성이 높지만, 지금 당장 엔터프라이즈 수준의 완성된 표준을 기대하고 도입을 서두르는 것은 리스크가 있습니다. Kong이나 Moesif 같은 API 게이트웨이 기반으로 MCP 트래픽을 관리하는 방식이 현재로선 현실적인 대안입니다.
자주 나오는 질문
MCP와 A2A(Agent2Agent)는 다른 건가요, 같은 건가요?
역할이 다릅니다. MCP는 단일 AI 에이전트가 외부 도구·데이터에 수직으로 연결하는 방법을 표준화합니다. A2A는 여러 AI 에이전트가 서로 수평으로 협력하는 방법을 표준화합니다. 비유하면 MCP는 에이전트가 손에 도구를 쥐는 방법, A2A는 에이전트끼리 대화하는 방법입니다. 복잡한 워크플로우에서는 둘 다 필요합니다.
MCP 서버를 직접 만들어 쓰는 게 커뮤니티 서버보다 안전한가요?
직접 만들면 코드와 도구 정의를 완전히 통제할 수 있어 도구 포이즈닝·러그 풀 위험은 줄어듭니다. 하지만 OWASP GenAI 가이드가 지적하는 코드 인젝션·과도한 권한·세션 격리 문제는 직접 만든 서버에서도 동일하게 발생합니다. “직접 만들었으니 안전하다”는 가정은 위험합니다. 빌드 여부와 무관하게 최소 권한 원칙과 입력 검증은 필수입니다.
2026 로드맵에서 새 트랜스포트는 추가되지 않는다고 했는데, WebSocket은요?
공식 로드맵에서 명시적으로 “이 사이클에 공식 트랜스포트를 추가하지 않는다”고 밝혔습니다. 생태계 호환성 보호를 위한 의도적 결정입니다. WebSocket 같은 실험적 트랜스포트는 커뮤니티가 커스텀 방식으로 실험할 수는 있지만, 공식 스펙에 편입되는 건 이번 사이클 범위 밖입니다. (출처: MCP 공식 로드맵, 2026.03.09)
MCP Server Cards는 언제 쓸 수 있게 되나요?
SEP-2127로 초안이 제출된 상태이며(2026.01.28), 아직 구현 완료 상태가 아닙니다. Transports WG와 Server Card WG가 현재 작업 중입니다. 로드맵상 2026년 내 완성이 목표이지만 구체적인 날짜는 공식적으로 확정되지 않았습니다. 확인 필요.
MCP를 쓰면 어느 AI 모델이든 다 연결되나요?
MCP를 지원하는 모델과 플랫폼에서만 작동합니다. 현재 Claude, GPT 계열(OpenAI), Gemini(Google DeepMind), GitHub Copilot(Microsoft), Cursor, Replit이 지원합니다. LangChain, LlamaIndex, AutoGen, CrewAI 같은 에이전트 프레임워크도 MCP를 de facto 도구 호출 표준으로 채택했습니다. 단, 지원 여부와 지원 버전은 각 플랫폼의 업데이트 상황에 따라 다를 수 있으므로 사용 전 개별 확인이 필요합니다.
마치며
MCP 프로토콜은 출시 14개월 만에 업계 표준이 됐습니다. 속도는 인상적입니다. 그런데 솔직히 말하면, 지금 상태의 MCP 생태계는 “공식 스펙이 있다”는 것과 “프로덕션에서 믿고 쓸 수 있다”는 것이 다른 영역에 걸쳐 있습니다.
서버 숫자와 생태계 건강도는 다른 지표입니다. 커뮤니티 서버 53%의 정적 API 키 문제, 1,800개 이상의 무인증 공개 서버, 그리고 실제 Postmark 사고는 “빠르게 자랐지만 보안 부채가 쌓였다”는 것을 보여줍니다. 2026 로드맵이 기술 확장보다 운영 안정화에 집중한 것은, 이 부채를 이제 갚겠다는 신호입니다.
MCP Apps와 UCP의 등장은 이 기술이 텍스트 도구 연결을 넘어 UI와 상거래까지 확장하고 있음을 보여줍니다. 지금은 그 확장의 중간 지점입니다. 기대할 게 많지만, 그만큼 지금 당장 쓸 때는 출처와 인증 방식을 반드시 확인해야 하는 시점이기도 합니다.
📚 본 포스팅 참고 자료
- MCP 공식 블로그 — The 2026 MCP Roadmap (2026.03.09)
- MCP 공식 로드맵 문서 (modelcontextprotocol.io)
- MCP 공식 스펙 문서 2025-03-26 (modelcontextprotocol.io)
- Astrix Security — State of MCP Server Security 2025
- Anthropic — MCP AAIF 기증 발표 (2025.12)
- MCP 공식 블로그 — MCP Apps 발표 (2026.01.26)
- Google Developers Blog — UCP 아키텍처
- FlowHunt — OWASP GenAI MCP 보안 취약점 분석 (2026.02)
본 포스팅은 2026년 3월 19일 기준으로 작성됐습니다. 본 포스팅 작성 이후 MCP 서비스 정책·UI·기능·보안 스펙이 변경될 수 있습니다. 본문 내 수치 및 기술 사항은 각 출처 공식 문서 기준이며, 개인 투자·도입 결정에 앞서 최신 공식 문서를 반드시 재확인하시기 바랍니다.
댓글 남기기