모든 것을 바꾸는 MCP 리셋

MCP의 초기 프로토콜은 본질적인 상태 유지(statefulness)라는 중대한 아키텍처적 제약을 가했습니다. 이전에는 클라이언트가 MCP 엔드포인트에 initialize 요청을 보내 상호작용을 시작했습니다. 그러면 서버는 이후 모든 클라이언트-서버 통신에 필수적인 토큰인 고유한 session ID를 생성하여 반환했습니다. 모든 후속 요청은 반드시 이 식별자를 포함해야 했습니다.

이러한 설계는 확장 가능한 배포에 근본적인 결함을 만들었습니다. 필수적인 session ID는 클라이언트를 처음에 initialize 호출을 처리한 특정 서버 인스턴스에 고정시켰습니다. 이는 표준 로드 밸런싱 패러다임을 깨뜨렸습니다. 예를 들어 라운드 로빈 라우터와 같은 로드 밸런서가 후속 요청을 다른 인스턴스로 전달하면, 해당 서버는 세션 기록이 없었습니다. 그 결과 400 "session not found" 오류가 발생하여 클라이언트 작업이 중단되었습니다. 마찬가지로 인스턴스가 충돌하면 활성 세션 상태가 즉시 손실되어 클라이언트 요청이 즉시 실패했습니다.

개발자들은 이러한 문제를 완화하기 위해 복잡하고 비효율적인 우회 방법을 사용해야 했습니다. 일반적인 해결책으로는 클라이언트가 항상 동일한 서버 인스턴스에 연결되도록 하는 sticky sessions 구현이 있었습니다. 또 다른 접근 방식은 Redis 인스턴스와 같은 공유 상태 저장소를 배포하여 모든 서버 간에 세션 데이터를 중앙 집중화하고 동기화하는 것이었습니다. 두 방법 모두 불필요한 운영 오버헤드를 초래하고 네트워크 지연 시간을 증가시키며 인프라 비용을 크게 상승시켰습니다. 이는 선택이 아닌 프로토콜로 인한 부담이었습니다.

MCP의 새로운 사양인 '2026-07-28'은 급격한 변화를 도입합니다. 두 가지 핵심 제안인 SEP-2575와 SEP-2567은 프로토콜의 핵심을 재정의합니다. SEP-2575는 initialize 및 initialized 핸드셰이크를 제거하고, SEP-2567은 MCP-Session-Id 헤더와 관련된 프로토콜 수준의 session을 제거합니다.

이러한 변경 사항은 다단계 도구 호출을 단일 독립형 HTTP 요청으로 변환합니다. 이전에는 컨텍스트가 파편화되어 있었지만, 이제는 필요한 모든 정보가 JSON 본문 내의 meta 필드에 포함됩니다. 이 설계는 모든 요청을 독립적으로 만들어 상태 비저장 HTTP 원칙을 반영합니다.

표준 HTTP 인프라와의 정렬이 완료되었습니다. 새로운 헤더인 MCP-Method 및 MCP-Name은 이제 중요한 라우팅 정보를 전달합니다. 이를 통해 게이트웨이, 방화벽, 속도 제한 장치와 같은 네트워크 구성 요소가 JSON 페이로드를 구문 분석하지 않고도 결정을 내릴 수 있습니다. 이러한 효율성은 특히 Cloudflare에서 성능을 위해 매우 중요합니다.

이제 프로토콜은 MCP를 지원하기 위해 Durable Objects를 요구하지 않으므로 배포가 단순화됩니다. 서비스는 유휴 상태일 때 0으로 확장(scale down to zero)할 수 있어 운영 비용을 크게 절감하고 배포 옵션을 확장합니다. 이러한 변화는 sticky sessions이나 공유 Redis 인스턴스의 문제점을 제거하여 MCP를 기본적으로 진정한 상태 비저장 방식으로 만듭니다.

상태 비저장(Statelessness)은 엄청난 배포 이점을 제공합니다. Cloudflare Workers 및 Google Cloud Run과 같은 서버리스 플랫폼은 이제 유휴 상태일 때 0으로 확장되어 운영 비용을 획기적으로 절감합니다. 서버는 더 이상 지속적인 연결을 유지할 필요가 없으므로 세션 상태를 유지하기 위해 항상 켜져 있는 인스턴스가 필요하지 않습니다. 이는 인프라 프로비저닝 방식을 근본적으로 변화시킵니다.

Protocol은 더 이상 상태 관리에 부담을 주지 않습니다. 대신 상태는 애플리케이션 수준의 관심사가 됩니다. 도구는 basket_id나 browser_id와 같은 명시적 핸들을 생성할 수 있습니다. 모델은 이후 도구 호출 시 이 식별자를 일반 인수로 다시 전달합니다. 이는 개발자에게 더 큰 유연성을 제공하여, 프로토콜이 강제하는 패턴에 따르는 대신 필요에 따라 정확하게 상태를 관리할 수 있게 합니다.

MCP는 향상된 클라이언트 측 효율성을 위해 HTTP 방식의 캐싱을 채택했습니다. 새로운 time to live 및 cache scope 힌트는 클라이언트에게 도구, 프롬프트 및 리소스 목록의 신선도에 대한 정보를 제공합니다. 이를 통해 클라이언트는 응답을 자신 있게 캐싱하여 업데이트를 위해 지속적인 연결을 유지할 필요가 없습니다. 강력한 상태 비저장(Stateless) API 설계에 대한 자세한 내용은 Statelessness in API Design: Understanding & Examples - Unkey를 참조하십시오. 이러한 힌트는 클라이언트가 데이터가 사용자 전반에 걸쳐 얼마나 오랫동안 유효한지 정확히 파악할 수 있도록 합니다.

복잡한 상호작용은 이제 명확한 클라이언트 주도 패턴을 따릅니다. 이전에는 서버가 요청하지 않은 후속 질문을 보내는 보안상 위험한 방식이 있었으나, 새로운 사양은 이를 방지합니다. 다중 턴 상호작용의 경우, 서버는 input_required 결과를 반환합니다.

이 결과에는 보류 중인 작업에 대한 모든 컨텍스트를 캡슐화하는 직렬화된 request_state 페이로드가 포함됩니다. 클라이언트는 input_required를 수신하면 사용자에게 프롬프트(예: "확실합니까?")를 표시한 다음 원래 요청을 다시 시작합니다. 클라이언트는 사용자의 응답을 첨부하고 request_state를 에코합니다. 이를 통해 클라이언트는 항상 상호작용을 주도하게 됩니다. 어떤 서버 인스턴스든 재개된 요청을 처리할 수 있어 상태 비저장성이 강화됩니다.

장기 실행 작업은 이제 공식화된 'tasks' 확장을 활용합니다. 이 기능은 실험적 상태에서 정식 기능으로 승격되었습니다. 환불 처리와 같은 작업의 경우, 서버는 즉시 요청을 승인합니다. 서버는 작업이 실행 중임을 나타내는 응답을 반환하여 연결 차단을 방지합니다.

클라이언트는 비동기적으로 진행 상황을 추적합니다. tasks/get을 사용하여 폴링하거나 subscriptions/listen을 통해 구독할 수 있습니다. 이를 통해 장기 실행 작업이 완료되면 최종 결과를 검색할 수 있습니다. 이 설계는 긴 계산 중에 지속적인 연결이 필요 없게 하여 프로토콜 효율성과 복원력을 향상시킵니다.

기존 상태 저장(Stateful) MCP의 주요 문제점은 무엇이었나요?

기존 프로토콜은 클라이언트를 특정 서버 인스턴스에 고정하는 세션 ID를 요구했습니다. 이로 인해 로드 밸런싱이 어려워졌고, 고정 세션(Sticky sessions)이나 Redis와 같은 복잡한 우회 방법이 필요했으며, 서버 재시작 시 세션 상태가 손실될 수 있어 시스템이 취약했습니다.

새로운 상태 비저장(Stateless) MCP는 이러한 문제를 어떻게 해결하나요?

세션 핸드셰이크와 ID를 완전히 제거했습니다(사양 2026-07-28). 모든 요청은 독립적이므로 표준 라운드 로빈 로드 밸런싱이 가능하고, 복원력이 향상되며, 서버를 0으로 확장(Scale down to zero)하여 비용을 절감할 수 있습니다.

프로토콜이 상태 비저장(Stateless)이라면 새로운 MCP에서 상태는 어떻게 관리되나요?

상태는 이제 프로토콜 수준이 아닌 애플리케이션 수준에서 관리됩니다. 개발자는 도구가 명시적 핸들(예: 'browser_id')을 생성하게 하고, 모델이 후속 호출에서 이를 다시 전달하도록 할 수 있습니다. 이는 표준 HTTP API에서 흔히 사용되는 유연한 패턴입니다.

지속적인 연결 없이 장기 실행 도구 호출이 발생하면 어떻게 되나요?

새로운 사양은 'tasks' 확장을 공식 기능으로 승격시킵니다. 장기 실행 작업의 경우, 서버는 즉시 작업 ID를 반환할 수 있으며, 클라이언트는 해당 작업을 폴링하거나 구독하여 진행 상황 업데이트와 최종 결과를 비동기적으로 얻을 수 있습니다.