MCP 2026 로드맵, 60일에 CVE 30개 난 이유 있습니다

2026년 3월 9일, MCP 공식 블로그가 2026 로드맵을 발표했습니다. 눈에 띄는 건 새 기능 목록이 아닙니다. 릴리스 일정을 없애고 “워킹그룹” 중심으로 구조를 통째로 바꿨습니다. 이 변화가 왜 나왔는지, 60일 만에 CVE 30개가 터진 숫자가 그 이유를 말해줍니다.

로드맵이 릴리스 일정을 버린 진짜 이유

MCP 공식 블로그가 2026년 3월 9일 올린 로드맵 포스트에는 출시 날짜가 없습니다. 버전 번호도 없습니다. 이전까지 로드맵은 “다음 스펙 버전에 뭐가 들어간다”는 식의 릴리스 기반 문서였는데, 이번엔 구조 자체를 바꿨습니다. (출처: MCP 공식 블로그, 2026.03.09)

공식 로드맵 문서는 이렇게 적시합니다. “이전 방식은 소수 인원에게 작업이 몰렸을 때 말이 됐다. 지금은 워킹그룹이 프로토콜 개발의 주요 수단이며, 로드맵도 그걸 반영해야 한다.” (출처: MCP 공식 로드맵 문서, modelcontextprotocol.io/development/roadmap) 릴리스 일정 대신 “우선순위 영역”을 제시하고, 각 영역에 워킹그룹이 타임라인을 정하는 구조입니다. 일정 예측 가능성은 낮아졌지만, 빠르게 성장하는 오픈 스탠다드가 가진 불확실성에 더 솔직하게 맞춘 방식입니다.

실제로 MCP는 2025년 11월 마지막 스펙 버전 이후 새 버전을 내지 않았습니다. 그 기간 동안 워킹그룹과 SEP(스펙 개선 제안) 절차가 작동했고, Linux Foundation 아래 공식 거버넌스 체계가 자리를 잡았습니다. 날짜 없는 로드맵은 뒤처진 게 아니라 오픈 스탠다드가 성숙해지는 신호입니다.

4대 우선순위: 핵심만 뽑아서 보면

공식 로드맵은 2026년 핵심 우선순위를 네 가지로 명시했습니다. 각 영역 SEP은 우선 검토 대상이 됩니다. 이 네 가지 밖의 SEP는 자동 기각은 아니지만 검토 기간이 훨씬 길어진다고 문서에 직접 나옵니다. (출처: MCP 공식 로드맵 문서, 2026.03.09)

눈에 띄는 건 ④번입니다. 엔터프라이즈 워킹그룹은 아직 결성되지 않았습니다. 공식 문서 표현 그대로, “이 문제를 겪는 사람들이 직접 작업을 정의해줬으면 한다”고 적혀 있습니다. 엔터프라이즈 인프라를 다뤄본 경험이 있다면 누구든 합류할 수 있습니다. 가장 필요하지만 가장 덜 만들어진 영역이 지금 열려 있는 겁니다.

MCP Server Card — 연결 없이 서버를 파악하는 방법

①번 트랜스포트 영역에서 특히 실용적인 항목이 “MCP Server Card”입니다. .well-known URL에 서버 메타데이터를 표준 형식으로 노출하면, 브라우저·크롤러·레지스트리가 실제로 연결하지 않아도 서버 기능을 파악할 수 있습니다. (출처: MCP 공식 로드맵, 2026.03.09) 지금은 서버를 알아보려면 직접 연결해야 한다는 뜻이고, 이게 얼마나 비효율인지는 쓰다 보면 바로 느끼게 됩니다.

연결할수록 느려지는 구조적 함정

MCP 서버를 많이 연결할수록 에이전트가 더 강해진다는 건 직관적으로 맞는 말 같습니다. 막상 프로덕션에서 경험해보면 다릅니다. 서버를 연결하는 순간 두 가지 비용이 쌓이기 시작합니다.

더블 홉 세금: 도구 호출마다 왕복이 두 번

MCP 없이 에이전트가 도구를 부르면 왕복이 1번입니다. MCP를 거치면 에이전트 → MCP 서버 → 도구, 도구 → MCP 서버 → 에이전트로 왕복이 2번이 됩니다. 단순 도구 1개 호출엔 20~50ms 차이지만, 실제 에이전트 워크플로우에서 20~30개 도구를 순차 호출하면 네트워크 왕복이 40~60회로 늘어납니다. 레이턴시 민감한 파이프라인에서는 이게 응답시간에 직접 나타납니다. (출처: andrewbaker.ninja MCP 분석, 2026.03.22) 레이턴시가 쌓인다는 건, 비용도 같이 쌓인다는 뜻입니다.

컨텍스트 창 낭비: 도구 3개 서버만 연결해도 7만 토큰

MCP 클라이언트는 서버에 연결할 때 해당 서버가 노출하는 모든 도구의 이름·설명·파라미터 스키마를 컨텍스트 창에 로드합니다. 도구 하나 스키마가 약 200토큰입니다. GitHub·Notion급 서버 하나에 도구가 40개면 8,000토큰이 소진됩니다. 서버 2~3개를 연결하면 20,000~30,000토큰이 에이전트가 아무 작업도 시작하기 전에 스키마에 잠깁니다. (출처: andrewbaker.ninja MCP 분석, 2026.03.22) 컨텍스트가 줄면 추론 품질도 같이 줄어듭니다.

※ 도구당 약 200토큰 기준 추정치. 실제 서버·도구 구성에 따라 달라집니다.

2026 로드맵이 트랜스포트 진화를 1순위로 잡은 건 바로 이 지점입니다. 무상태(stateless) 수평 확장과 세션 마이그레이션을 정의해서 프로덕션 규모에서 구조적 낭비를 줄이는 게 핵심 목표입니다.

60일 CVE 30개, 보안은 왜 아직도 구멍인가

표준화된 프로토콜을 쓰면 보안이 좋아진다고 생각하기 쉽습니다. MCP가 2026년 초에 보여준 숫자는 그 반대입니다. 2026년 1~2월 단 60일 동안 MCP 생태계에서 CVE 30개가 공개됐습니다. 2025년 한 해 전체 CVE의 두 배가 한 분기 만에 나왔습니다. (출처: gtc.noqta.tn MCP 보안 가이드, 2026.03.14) 표준화가 보안을 보장하지 않는다는 걸 수치로 보여줍니다.

왜 빠르게 보안이 따라잡히지 못했나

근본 원인은 세 가지입니다. 첫째, MCP 서버는 호스트 시스템이 부여하는 권한 그대로 실행됩니다. 최소 권한 원칙이 스펙에 내장되지 않았습니다. 둘째, LLM은 MCP 서버 응답을 컨텍스트로 처리하므로, 악성 서버가 사용자가 입력하지 않은 명령을 에이전트에 주입할 수 있습니다(프롬프트 인젝션). 셋째, MCP 서버가 npm·PyPI로 배포되다 보니, 검증 없이 설치하면 공급망 공격에 바로 노출됩니다.

2026 로드맵의 엔터프라이즈 우선순위가 “감사 추적·SSO 통합 인증·게이트웨이 패턴”을 명시한 건 이 맥락에서 읽어야 합니다. 기능 요청이 아니라 프로덕션 배포 후 계속 터지는 사고를 막기 위한 방어 라인입니다. 다만 Enterprise WG는 아직 결성 전이라, 이 부분은 2026년 내내 진행 중인 과제입니다.

UTCP·네이티브 함수 호출과 비교해보면

MCP가 유일한 선택지는 아닙니다. 2025년 하반기부터 프로덕션 현장에서 UTCP(Universal Tool Calling Protocol)와 네이티브 함수 호출이 함께 쓰이기 시작했습니다. 각각 어떤 상황에서 MCP보다 유리한지를 수치로 비교해보겠습니다.

※ UTCP 실행 속도 수치는 UTCP 팀 인용 벤치마크 기준입니다. 독립 재현 결과는 환경마다 다를 수 있습니다. (출처: andrewbaker.ninja, 2026.03.22)

UTCP가 88% 적은 왕복으로 더 빠른 결과를 낸다는 수치는 인상적이지만, 기존 MCP 서버 생태계가 이미 수만 개 존재한다는 사실이 현실적 선택을 제한합니다. 잘 설계된 REST API를 이미 보유한 팀, 레이턴시 민감한 파이프라인을 운영하는 팀이라면 UTCP가 실질적인 대안이 됩니다. 기존 MCP 서버를 활용하거나 대규모 팀에서 표준화가 필요한 경우엔 MCP가 여전히 선택지입니다.

2026년 MCP, 어떤 상황에서 써야 하나

MCP가 유효한 선택인 조건과 재고해야 할 조건을 정리해봤습니다. 공식 로드맵이 자인한 한계와 보안 수치를 바탕으로, 프로덕션 환경에서 실제로 쓰기 전에 먼저 확인해야 할 체크리스트입니다.

✅ MCP가 여전히 유효한 상황

• 기존 MCP 서버 생태계(수만 개 이상)를 그대로 활용해야 할 때
• 여러 팀에 걸쳐 도구 표준화가 필요할 때 (Block: 2개월 만에 60개 이상 MCP 서버 구축)
• 멀티에이전트 오케스트레이션이 핵심인 복잡한 워크플로우
• 엔터프라이즈 거버넌스·감사 추적이 필요할 때 (단, Enterprise WG 성숙 후 기준)

⚠️ 다시 생각해봐야 할 상황

• 레이턴시가 곧 비용인 실시간 파이프라인 (더블 홉 세금이 누적됨)
• 이미 잘 설계된 REST API가 있는데 래퍼 서버를 따로 운영하기 부담스러울 때
• 서드파티 MCP 서버를 검증 없이 설치할 예정이라면 (공급망 공격 위험)
• 한 AI 제공사에만 묶일 단순 내부 도구를 빠르게 만들 때

Bloomberg는 약 10,000명의 엔지니어를 보유한 상태에서 MCP를 도입해 팀 전체에 걸친 도구 표준화에 성공했다고 MCP 개발자 서밋에서 발표했습니다. Block은 2개월 만에 60개 이상의 MCP 서버를 여러 직무에 배포했습니다. 이 두 사례 모두 MCP가 최소한 팀 간 표준화 문제를 풀기 위해 유효하다는 걸 보여줍니다. 다만 두 기업 모두 내부 인증·거버넌스 체계를 별도로 구축한 대형 조직이라는 점은 참고해야 합니다.

Q&A 5가지

마치며

MCP 2026 로드맵을 한 줄로 요약하면 “기능 추가에서 프로덕션 신뢰성으로 방향이 바뀌었다”입니다. 출시 날짜가 없는 로드맵, 워킹그룹 중심의 구조, 4대 우선순위 모두 이 방향을 가리킵니다.

솔직히 말하면, 60일에 CVE 30개가 터진 숫자는 충격적입니다. 표준 프로토콜이 보안을 자동으로 해결해준다는 기대가 얼마나 위험한지 실측 데이터로 보여줬습니다. 그리고 MCP 자체가 그 한계를 로드맵에서 정면으로 인정했다는 점이 오히려 신뢰가 갑니다.

2026년 현재 MCP는 AI 에이전트 통합의 사실상 기준입니다. 그러나 “쓰면 무조건 좋다”는 시기는 끝났습니다. 연결하는 서버마다 인증이 있는지, 컨텍스트 창 낭비가 어느 수준인지, 서드파티 패키지를 검증했는지를 확인하고 쓰는 게 지금의 기준입니다. 로드맵이 완성돼 가는 동안, 현장에서 먼저 이 부분을 챙겨야 합니다.

Enterprise WG가 결성되고, MCP Server Card가 나오고, 세션 무상태 확장이 구현되면 MCP는 지금보다 훨씬 쓸 만해질 겁니다. 그 전까지는 공식 로드맵 문서를 직접 읽으면서 어느 부분이 아직 진행 중인지 파악하는 게 가장 정확한 현황 파악 방법입니다.

본 포스팅 참고 자료

1. MCP 공식 블로그 — 2026 로드맵 발표 (blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/)
2. MCP 공식 로드맵 문서 (modelcontextprotocol.io/development/roadmap)
3. MCP 보안: CVE 30개 60일 분석 — GTC Noqta (gtc.noqta.tn, 2026.03.14)
4. MCP 부상과 구조적 한계 분석 — Andrew Baker (andrewbaker.ninja, 2026.03.22)
5. MCP 현황 분석 — Elastic Korea (elastic.co, 2025.06.12)