MCP 2026 H2 로드맵과 에이전트 인프라의 변화

MCP가 운영 프로토콜로 확장되는 시점

MCP 공식 블로그가 공개한 2026년 H2 로드맵은 프로토콜의 관심 범위가 도구 연결에서 실제 운영 환경으로 넓어지고 있음을 보여준다. 핵심 방향은 상태 비저장(Stateless) 서버를 통한 클라우드 네이티브 배포, Server Cards를 이용한 서버 자동 발견, Agent-to-Agent(A2A) 협업의 상호운용성 확보다. 엔터프라이즈 운영에 필요한 SSO 연동 인증, 감사 추적(Audit Trail), 게이트웨이 레이트 리미팅도 로드맵에 명시됐다.

세션을 서버 프로세스 밖으로 옮긴다

기존 MCP 서버는 클라이언트 세션 상태를 서버 프로세스의 메모리에 보관하는 상태 저장(Stateful) 구조로 설계됐다. 개발 단계에서는 단순하지만, 요청을 여러 인스턴스로 분산하는 수평 확장(Horizontal Scaling)이 어렵고 서버 장애가 세션 유실로 이어질 수 있다.

2026 H2 로드맵의 Stateless 서버 지원은 이 제약을 줄이는 방향이다. 세션과 실행 상태를 외부 저장소에 맡기면 개별 서버는 요청 처리에 집중할 수 있으며, 쿠버네티스 오토스케일링과 서버리스 배포도 가능해진다.

⤢✕

각 HTTP 요청은 독립적으로 처리되고, 어느 인스턴스가 받아도 같은 결과를 내야 한다. 이를 위해 서버 인스턴스는 공유 메모리나 파일 시스템에 의존하지 않는 Shared-Nothing 구조로 동작한다. 인스턴스 사이의 결합이 사라지면 장애 격리와 롤링 업데이트도 수월해진다.

클라이언트는 첫 연결에서 발급받은 세션 토큰을 이후 요청의 헤더에 실어 보낸다. 서버는 토큰을 기준으로 외부 저장소에서 세션 컨텍스트를 복원한다. 같은 세션의 요청이 서로 다른 인스턴스에 도착하더라도 상태 일관성을 유지해야 하므로, 읽기와 쓰기의 충돌을 막기 위한 낙관적 잠금(Optimistic Locking)이 필요하다.

스케일 다운 과정에서는 처리 중인 요청을 끊지 않는 Graceful Drain 절차가 요구된다. 인스턴스는 진행 중인 요청이 끝날 때까지 유지된 뒤 종료되며, 쿠버네티스의 preStop Hook과 연동해 구현할 수 있다.

외부 저장소와 캐시를 어떻게 나눌 것인가

세션 컨텍스트는 Redis에 JSON으로 직렬화해 저장하고 TTL로 만료를 관리한다. Redis Cluster를 구성하면 세션 저장소 자체의 고가용성도 확보할 수 있다. 다만 Stateless 전환이 모든 상태를 무조건 외부에 쌓는다는 뜻은 아니다. 재계산할 수 있는 데이터는 제외하고, 현재 도구 실행 진행 상황·권한 캐시·멱등성 키처럼 요청을 이어가는 데 필요한 상태만 남겨야 한다.

접근 빈도가 높은 세션 데이터는 인스턴스 로컬 메모리의 L1 캐시에 짧은 TTL로 보관하고, 로컬 캐시에서 찾지 못했을 때 Redis 기반 L2를 조회할 수 있다. 이 2계층 구조는 외부 저장소 접근을 줄이면서도 서버 상태를 최소화하는 절충안이다.

SSE 스트리밍 연결처럼 완전한 Stateless 전환이 어려운 경우에는 세션 친화성(Session Affinity)을 함께 사용할 수 있다. 로드 밸런서가 같은 연결을 동일 인스턴스로 보내도록 유지하는 하이브리드 방식이다.

재시도에도 도구가 중복 실행되지 않게 한다

네트워크 재시도가 도구의 이중 실행으로 이어지지 않으려면 요청의 멱등성을 보장해야 한다. 클라이언트는 각 도구 호출에 UUID를 생성하고 X-Idempotency-Key 헤더에 담는다. 서버는 이미 처리한 키가 다시 들어오면 도구를 재실행하지 않고 이전 결과를 반환한다.

멱등성 키와 결과는 Redis에 저장하며 TTL은 24시간으로 설정한다. 중복 요청이 들어왔을 때 데이터베이스까지 조회하지 않고 캐시에서 결과를 바로 돌려줄 수 있다.

리소스 구독에서는 ETag와 If-None-Match 헤더를 이용한 조건부 GET 캐싱을 적용한다. 리소스가 바뀌지 않았다면 서버가 304 Not Modified로 응답해 전송 비용을 줄인다. 외부 데이터 소스가 변경됐을 때는 관련 캐시를 즉시 지우고, Redis Pub/Sub으로 무효화 이벤트를 모든 인스턴스에 전달한다.

Server Cards가 수동 등록을 대체한다

현재 MCP 서버를 연결하려면 클라이언트 설정 파일에 서버 URL을 직접 등록해야 한다. Server Cards는 서버가 제공하는 기능과 보안 요구사항, 성능 정보, 사용 조건을 표준 메타데이터로 공개하고 클라이언트가 이를 찾아 자동으로 구성하도록 만드는 프레임워크다.

Server Card는 MCP 서버의 /.well-known/mcp-server-card.json 경로에 게시되는 JSON 문서다. 클라이언트는 서버 도메인에서 이 경로를 조회해 연결 전에 서버의 성격과 요구 조건을 파악한다.

⤢✕

Server Card의 identity에는 서버 이름·버전·제공자·설명·아이콘 URL이 들어간다. protocol은 지원하는 MCP 프로토콜 버전과 stdio·SSE·WebSocket 전송 방식을 알린다. capabilities에는 도구·리소스·프롬프트의 요약과 카테고리 태그를 담고, auth에는 OIDC·API Key·OAuth 2.1과 IdP 엔드포인트 URL을 기록한다.

운영 정보도 같은 문서에 포함된다. performance는 평균 응답 지연·처리량 한도·가용성 SLA·지역(Region)을 설명하고, terms는 사용 약관 URL·데이터 처리 정책·요금 체계 링크를 제공한다.

기능과 권한을 메타데이터로 맞춘다

각 도구에는 data:read·code:execute·web:browse와 같은 표준 의미 태그를 붙인다. 클라이언트는 이 의미 태깅(Semantic Tagging)을 이용해 필요한 기능 유형으로 서버를 검색할 수 있다.

에이전트가 요구 기능 목록을 선언하면 자동 매칭 엔진은 Server Card 레지스트리에서 조건을 충족하는 서버를 찾고 연결한다. 도구별 필요 권한도 Card에 명시하므로, 클라이언트는 실제 작업에 필요한 권한만 요청할 수 있다. 과도한 권한 요청에서 생기는 보안 위험을 줄이는 방식이다.

서버 상태는 /.well-known/mcp-health에서 공개한다. 서버 가용성·지연·오류율을 실시간으로 게시하면 클라이언트가 장애가 발생한 서버를 자동으로 피할 수 있다.

프로토콜 버전을 연결 시점에 협상한다

지원 버전은 Server Card에 protocolVersions: ["2024-11-05", "2025-03-26", "2026-01-01"] 형식으로 명시한다. 클라이언트와 서버는 Semantic Versioning을 따르며 양쪽이 지원하는 최신 공통 버전을 선택한다.

실험적 기능은 experimental: {"streaming": true}처럼 별도로 표시해 안정 기능과 구분한다. 클라이언트는 이 정보를 보고 실험 기능을 사용할지 명시적으로 결정한다. 이전 버전의 지원 종료 일정도 Card에 기록해 클라이언트 개발자가 마이그레이션 계획을 세울 수 있게 한다.

서버가 새로운 Server Card를 게시하면 현재 연결된 클라이언트에는 프로토콜 업그레이드 가능 여부를 알린다. 자동 발견이 최초 연결뿐 아니라 버전 전환까지 이어지는 구조다.

A2A 협업에서 태스크와 상태를 전달하는 법

A2A(Agent-to-Agent) 협업은 오케스트레이터 에이전트가 전문 서브 에이전트에 태스크를 맡기고 결과를 모으는 멀티에이전트 패턴이다. MCP A2A 표준은 이 과정의 태스크 위임과 상태 공유를 프로토콜 수준에서 정의한다.

⤢✕

위임 요청은 agent/delegate 메서드로 표준화된다. 메시지에는 태스크 설명·입력 데이터·기대 출력 형식·실행 기한·우선순위가 구조화된 형태로 들어간다.

협업 과정의 중간 결과는 공유 작업 공간(Shared Workspace)에 게시된다. 각 에이전트는 자신의 결과를 이 컨텍스트 저장소에 기록하고 다른 에이전트가 만든 결과를 구독한다. 서브 태스크의 의존 관계는 DAG(Directed Acyclic Graph)로 관리해 독립적인 작업은 병렬로 실행하고, 의존성이 있는 작업은 선행 태스크가 끝날 때까지 기다린다.

일부 서브 에이전트가 실패해도 전체 실행을 곧바로 중단할 필요는 없다. 오케스트레이터는 정책에 따라 재시도하거나 대체 에이전트를 고르고, 확보한 부분 결과만으로 작업을 계속할 수 있다.

권한은 에이전트 체인을 따라 제한적으로 이동한다

에이전트 A가 에이전트 B를 대신해 MCP 서버를 호출한다면 원본 사용자의 권한이 위임 체인 전체에서 검증돼야 한다. 오케스트레이터는 태스크를 넘길 때 사용자의 원본 OIDC 토큰에서 파생된 범위 제한 위임 토큰(Delegation Token)을 서브 에이전트에 전달한다. 서브 에이전트는 이 토큰으로 MCP 서버에 접근한다.

MCP 서버는 사용자 → 오케스트레이터 → 서브 에이전트로 이어지는 토큰 발급자 체인을 확인한다. 각 위임 단계의 서명과 권한 범위도 함께 검증한다.

오케스트레이터가 넘길 수 있는 권한은 태스크 수행에 필요한 최소 범위로 제한된다. 사용자 권한 전체를 서브 에이전트에 그대로 전달하는 행위는 표준에서 명시적으로 금지한다. 누가 누구에게 어떤 권한을 언제 위임했는지는 불변 감사 로그에 기록해 에이전트 체인의 행동을 사후에 추적할 수 있게 한다.

2026 H2 구현 일정과 의존 관계

기능	예정 분기	상태	주요 의존성
Stateless 서버 지원	Q3 2026	사양 초안	Redis 세션 저장소 표준화
Server Cards v1.0	Q3 2026	RFC 검토 중	DNS-SD 통합
A2A 위임 프로토콜	Q4 2026	설계 단계	OIDC 위임 토큰 표준
엔터프라이즈 SSO 통합	Q3 2026	PoC 완료	Entra ID·Okta 파트너십
감사 추적 표준화	Q4 2026	요구사항 수집	OpenTelemetry 통합
게이트웨이 레이트 리미팅	Q3 2026	구현 중	토큰 버킷 알고리즘 표준화

로드맵에는 기존 Stateful 서버를 Stateless 구조로 옮기기 위한 공식 가이드와 자동화 도구가 포함된다. 기존 구현체의 하위 호환성은 최소 2년간 보장한다.

Stateless 서버·Server Cards·A2A 위임에는 각각 Python과 TypeScript 레퍼런스 구현이 제공되며 Apache 2.0 라이선스로 공개된다. Linux Foundation 산하 Agentic AI Foundation은 H2 신규 기능의 구현 준수도를 확인하는 공식 인증 테스트 스위트 출시를 계획하고 있다.

이 로드맵이 가리키는 방향은 서버 확장성, 자동 발견, 에이전트 간 신뢰를 하나의 운영 기반으로 묶는 것이다. Stateless 서버는 클라우드 네이티브 환경에서의 확장 문제를 다루고, Server Cards는 수동 설정에 의존하던 서버 연결을 자동화한다. A2A 표준은 멀티에이전트 협업에서 권한 위임과 감사 가능한 신뢰 체인을 프로토콜의 책임으로 가져온다.