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-Version` - `Mcp-Method` - `Mcp-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 인프라를 선택하는 것이 권장된다.