MCP 2026-07-28 릴리스와 새 로드맵은 세션 제거(stateless), 에이전트 ID 보안, 서버 발신 이벤트로 도구 연결을 넘어 에이전트 운영 표준으로 확장된다.
핵심 요약
- MCP(Model Context Protocol)는 Anthropic이 2024년 11월 만든 에이전트-도구 연결 표준입니다. GitHub servers 저장소만 89,000+ ★로, 사실상 업계 표준으로 자리 잡았습니다.
- 2026-07-28 스펙 릴리스와 새 로드맵은 MCP가 "도구 연결"에서 "에이전트 운영 표준"으로 진화하는 방향을 제시합니다.
- 가장 큰 변화는 세션 제거(stateless) 입니다. 기존에는 서버가 상태를 유지하고 초기화 핸드셰이크가 필요했는데, 이제 서버가 상태 없이 수평 확장됩니다.
- 둘째는 에이전트 신원(identity) 보안입니다. 브라우저에서 사람이 승인하던 인증이, "사람이 없는 클라우드 에이전트"도 인증받는 방향으로 바뀝니다.
- 셋째는 서버 발신 이벤트입니다. 폴링 없이 서버가 작업 완료를 알리는 비동기 메시징이 추가됩니다.
- 경쟁 프로토콜인 A2A(25,000+ ★, 구글 주도)는 에이전트 간 통신에 집중하는 반면, MCP는 에이전트-도구에 집중합니다. 두 표준은 경쟁이 아니라 서로 다른 계층을 다룹니다.
MCP: 도구 연결의 USB-C가 되다
MCP는 AI 에이전트가 외부 도구·데이터 소스에 연결하는 방식을 표준화한 프로토콜입니다. 에이전트가 파일 시스템, 데이터베이스, 브라우저, SaaS 서비스를 다룰 때 매번 다른 API를 배우지 않아도 되게 합니다. Anthropic이 2024년 11월에 발표했고, 이후 OpenAI·Microsoft·Google이 채택하면서 사실상 표준으로 굳었습니다.
숫자로 보면 그 확산이 확인 가능한 수치로 드러납니다.
- MCP servers 저장소: 89,827★ / 11,500 포크
- MCP TypeScript SDK: 13,241★
- 대안인 A2A 프로토콜: 25,477★
이제 MCP의 진화가 가속화되고 있습니다. 2026-07-28 스펙 릴리스는 프로토콜을 크게 재설계했고, 새 로드맵이 다음 단계를 명시했습니다. 기존 MCP와 무엇이 달라지는지가 핵심입니다.
달라지는 점 1: 세션 제거 — 서버가 상태 없이 확장된다
가장 근본적인 변화는 프로토콜 레벨의 세션과 초기화 핸드셰이크가 사라진 것입니다.
| 기존 MCP | 새 MCP (2026-07-28) |
|---|---|
| 서버가 세션 상태 유지 | 무상태(stateless) (SEP-2575) |
| 초기화 핸드셰이크 필요 | 핸드셰이크 제거 (SEP-2567) |
| 수평 확장 어려움 | 어떤 인프라에서든 수평 확장 |
| 연결 후 기능 파악 | server/discover로 연결 전 버전·기능 조회 |
| 리스트 결과 매번 조회 | TTL 캐시 가능 (SEP-2549) |
이전에는 MCP 서버가 "하나의 세션"을 유지해야 해서, 요청이 많아지면 상태를 공유하기 어려웠습니다. 이제 서버가 상태를 갖지 않으므로, 로드밸런서 뒤에서 자유롭게 늘렸다 줄였다 할 수 있습니다. MCP 서버를 "평범한 HTTP API"처럼 운영할 수 있게 된 것입니다. 로드맵의 "HTTP-native transport unification"은 이 방향을 한 걸음 더 밀어, stdio에서도 Streamable HTTP로 통일하려 합니다.
달라지는 점 2: 에이전트 신원 보안 — 사람 없는 에이전트의 인증
두 번째 변화는 인증입니다. 기존 MCP 인증은 브라우저에서 사람이 승인하는 방식입니다. 사용자가 OAuth 화면에서 "이 접근 허용?"을 눌러야 합니다.
하지만 에이전트의 현실은 다릅니다. 클라우드에서 돌아가는 에이전트는 사람이 옆에 없고, 사용자를 대신해 행동하며, 하위 에이전트에게 권한을 위임하기도 합니다. 브라우저 승인 방식은 이런 시나리오에서 맞지 않습니다.
새 로드맵의 "Agent identity and enterprise-ready security"가 이 문제를 다룹니다.
- DPoP (Demonstrating Proof of Possession) — 토큰이 도난당해도 재사용 불가하게
- Workload Identity Federation — 클라우드 워크로드에 신원 부여
- ID-JAG grant + 표준 토큰 교환 — Enterprise-Managed Auth (이미 안정화)
즉, "사람이 승인"에서 "에이전트가 스스로 신원을 증명" 하는 방향으로 바뀝니다. 과거의 paste된 API 키·장기 토큰 대신 표준 기반 인증을 씁니다.
달라지는 점 3: 서버 발신 이벤트 — 폴링에서 알림으로
세 번째는 통신 패턴입니다. 기존 MCP는 요청-응답(request-response) 모델입니다. 클라이언트가 요청하고 서버가 응답합니다. 하지만 현대 에이전트 워크로드는 더 깁니다. 작업이 몇 분~몇 시간 돌 수 있고, 서버가 중간 결과를 스트리밍하거나, 도중에 방향을 바꿔야 할 수도 있습니다.
새 로드맵은 이를 위해 서버 발신 이벤트(webhooks, channels) 를 추가합니다. 클라이언트가 결과를 폴링하지 않아도, 서버가 완료나 진행 상황을 능동적으로 알립니다.
또한 프리미티브도 개선됩니다.
- tools/call 결과 형식 단일화 — 같은 출력을 여러 형태로 담던 것을 하나로 통일
- progressive discovery — 100개 도구를 처음부터 전부 로드하지 않고, 대화가 좁혀지면 점진적으로 노출. 모델이 불필요한 도구 표면을 미리 계산하지 않게 함
USB-C 논쟁의 실체: MCP vs A2A
"MCP가 USB-C인가" 논쟁의 핵심은 경쟁 프로토콜과의 관계입니다. 대표적인 대안이 Google 주도의 A2A (Agent2Agent) 입니다.
| 항목 | MCP | A2A |
|---|---|---|
| 계층 | 에이전트 → 도구 | 에이전트 ↔ 에이전트 |
| 초점 | 도구·데이터 연결 | 에이전트 간 통신·상호운용 |
| 스타 | 89,827★ (servers) | 25,477★ |
| 주도 | Anthropic |
이 둘은 사실 경쟁이 아니라 다른 계층입니다. MCP는 "에이전트가 도구를 쓰는 법", A2A는 "에이전트가 다른 에이전트와 말하는 법"을 다룹니다. 진짜 USB-C 논쟁은 "하나의 표준이 모든 걸 지배하나"가 아니라, "도구 계층(MCP)과 에이전트 계층(A2A)이 어떻게 겹치지 않고 공존하나"입니다. 새 MCP 로드맵이 에이전트 간 작업(Tasks)까지 흡수하려는 것은, 이 경계가 흐려지는 지점이기도 합니다.
판단 — MCP의 진화 방향
MCP 로드맵이 시사하는 바를 정리합니다.
- 무상태가 곧 운영성 — 세션 제거로 MCP 서버가 일반 HTTP API처럼 확장된다. 기업 채택의 걸림돌이 줄어든다.
- 사람 없는 인증이 다음 과제 — 에이전트 ID(DPoP, Workload Identity)는 에이전트가 클라우드에서 자율적으로 돌아가는 시대의 필수 보안이다.
- 비동기가 에이전트를 완성한다 — 폴링 대신 서버 발신 이벤트로, 장시간 작업을 효율적으로 처리한다.
- 프리미티브 스케일링 — 도구가 100개 이상일 때 progressive discovery로 모델 부담을 줄인다.
- MCP vs A2A는 계층 문제 — 도구 계층과 에이전트 계층이 어떻게 공존할지가 진짜 질문이다.
한계도 짚어야 합니다. 이 분석은 MCP 공식 블로그의 로드맵 발표를 기준으로 한 것이며, 아직 채택·검증이 진행 중인 방향성입니다. 실제 프로토콜 동작은 이후 스펙 릴리스에서 검증이 필요합니다. 결론은 이렇습니다. MCP는 더 이상 "도구 연결 표준"에 머무르지 않고, "에이전트 운영 표준"으로 진화하고 있습니다. 무상태 확장, 에이전트 신원 보안, 서버 발신 이벤트까지 — 이는 에이전트가 단순한 도구 호출러에서 실제 워크로드를 도맡는 운영 주체로 성장한다는 신호입니다. 기존 MCP를 알던 개발자라면, 이 변화가 "연결"을 넘어 "운영"으로 확장되는 지점을 눈여겨봐야 합니다.
개발자에게 의미하는 것
이 변화를 실제 개발 워크플로에 어떻게 적용할 수 있는지 정리합니다.
- MCP 서버를 만들 때 세션에 의존하지 마십시오. 이제 서버는 무상태로 설계하는 것이 기본입니다. 상태가 필요하면 별도 저장소(DB·캐시)로 빼고, 서버는 언제든 늘리고 줄일 수 있게 해야 합니다.
- 인증은 '사람 승인'이 아니라 '에이전트 ID'로 설계하십시오. 사용자에게 매번 브라우저 승인을 요구하는 대신, DPoP·Workload Identity Federation 같은 표준으로 에이전트가 스스로 신원을 증명하게 합니다. 클라우드에서 자율적으로 도는 에이전트라면 이 방식이 필수입니다.
- 장시간 작업은 폴링 대신 이벤트로 설계하십시오. 서버 발신 이벤트(webhook)가 지원되므로, 클라이언트가 주기적으로 결과를 물어보는 대신 완료 알림을 받도록 구성합니다.
- 도구가 많으면 progressive discovery를 활용하십시오. 100개가 넘는 도구를 매 요청마다 전부 로드하면 모델 비용이 커집니다. 대화가 좁혀질 때 점진적으로 도구를 노출하는 방식을 채택합니다.
이 지점들이 바로 기존 MCP에서 새 MCP로 넘어갈 때 실제로 바뀌는 운영 방식입니다.
