MCP의 차세대 기술 (새 탭에서 열림)
지난 1년 반 동안 MCP는 에이전트와 외부 서비스를 연결하는 표준이 되었지만, 기존에는 세션과 연결 상태를 유지해야 해 원격 서버 운영이 복잡했다. 2026-07-28 사양부터 MCP는 완전한 무상태 프로토콜로 바뀌어, 서버가 세션을 저장하거나 sticky session·장기 스트림을 관리하지 않아도 된다. 그 결과 MCP 서버는 Cloudflare Workers 같은 요청 단위 인프라에서 더 저렴하고 간단하게 운영할 수 있다.
MCP의 무상태 전환
- 기존 MCP는
initialize와initialized교환으로 세션을 만들고, 서버가Mcp-Session-Id를 발급했다. - 이후 모든 요청은 해당 세션의 상태를 찾아야 했기 때문에 다음과 같은 운영 부담이 발생했다.
- 오토스케일링 환경에서 세션 보존
- sticky session을 통한 요청 라우팅
- 배포 시 세션 drain 또는 migration
- 인스턴스 장애 시 재연결 및 세션 복구
- 새 사양에서는 필수 handshake와
Mcp-Session-Id, 프로토콜 세션이 제거됐다. - 각 요청이 MCP 버전, 클라이언트 식별 정보, 클라이언트 capability를 직접 포함한다.
- 서버 정보를 미리 확인해야 하는 경우에만 선택적으로
server/discover를 호출한다. - MCP 자체에 상태가 필요하지 않으므로 기존
McpAgent없이도 서버를 구현할 수 있다. - 애플리케이션 자체에 상태가 필요할 때는 Durable Objects를 사용할 수 있지만, MCP 프로토콜만 제공하는 서버는 Cloudflare Workers처럼 요청 단위 인프라에서 실행할 수 있다.
- Cloudflare SDK에서는 기존
McpAgent대신createMcpHandler로 새 무상태 사양을 지원한다.
장기 연결이 필요 없는 Elicitation
- Elicitation은 서버가 작업을 완료하기 전에 사용자 입력이나 승인을 요청하는 기능이다.
- 운영 배포 승인
- 디자인 색상 선택
- 환불 확인
- 기존에는
elicitation/create가 열린 스트림에 의존했다. - 이 방식은 스트림 유지, 타임아웃, 비용, 로드 밸런싱을 복잡하게 만들었다.
- 새 사양은 Multi Round-Trip Requests(MRTR)를 사용한다.
- 서버가
input_required결과를 반환한다. - 클라이언트가 사용자 입력을 수집한다.
- 클라이언트가 입력값과 함께 작업을 재시도한다.
- 서버가 작업을 완료한다.
- 서버가
- 요청 사이에 연결이나 transport session을 보존할 필요가 없다.
- 기존 Elicitation 방식과 호환되지 않는 breaking change이지만, 구현과 운영은 훨씬 단순해진다.
HTTP 인프라가 MCP 요청을 직접 이해
- 기존에는 MCP 요청의 메서드와 대상이 JSON-RPC 본문 안에만 있어, 게이트웨이가 내용을 파싱해야 했다.
- 새 Streamable HTTP 요청에는 다음 헤더가 필수로 추가된다.
Mcp-Protocol-VersionMcp-MethodMcp-Name
- 예를 들어 도구 호출은
Mcp-Method: tools/call,Mcp-Name: search로 표현할 수 있다. - 게이트웨이, rate limiter, WAF가 JSON 본문을 해석하지 않고도 요청 종류별 정책을 적용할 수 있다.
- 도구별 metrics 수집, 메서드별 rate limit, 보안 규칙 적용도 기존 HTTP 인프라 방식으로 처리할 수 있다.
캐시와 도구 목록 개선
tools/list,prompts/list,resources/list,resources/read결과에 다음 힌트가 추가된다.ttlMs: 결과를 얼마나 오래 캐시할 수 있는지 나타냄cacheScope: 캐시 적용 범위를 나타냄
- 도구 카탈로그는 결정론적으로 정렬된다.
- 클라이언트가 연결이 끊겼다가 다시 연결되어도 카탈로그를 재사용하기 쉬워진다.
- upstream prompt cache가 불필요하게 무효화되는 문제도 줄일 수 있다.
인증 체계의 변화
- 새 사양은 MCP 인증 방식의 우선순위를 정비한다.
- 서버와 클라이언트 사이에 사전 관계가 있다면 사전 등록된 클라이언트를 우선 사용한다.
- 동적 등록이 필요하면 Client ID Metadata Documents(CIMD)를 사용한다.
- Dynamic Client Registration(DCR)은 최후의 수단으로 남지만, 신규 구현에서는 deprecated되었다.
실용적인 결론
새 MCP 서버는 세션 저장소나 장기 연결을 기본 전제로 설계할 필요가 없다. 단순한 도구·프롬프트·리소스 서버라면 createMcpHandler와 요청 단위 실행 환경을 사용하고, 애플리케이션 자체에 지속 상태나 실시간 협업이 필요할 때만 Durable Objects 같은 상태ful 인프라를 선택하는 것이 권장된다.