MCP Stateless Core로 HTTP 인프라에서 확장하는 원격 도구 서버

세션 없는 MCP 서버가 HTTP 확장 패턴을 만날 때

2026년 7월 28일 최종 확정되는 Model Context Protocol(MCP) 신규 사양은 출시 이후 최대 규모의 개편으로, 세션과 초기화 핸드셰이크를 제거한 Stateless Core를 중심에 둔다. 요청을 특정 서버 인스턴스에 붙잡아 둘 필요가 없어지면서 로드밸런서, CDN, 서버리스 같은 일반 HTTP 인프라 위에서 MCP 서버를 확장·운영할 수 있다.

대상 사양은 MCP 2026-07-28이다. 릴리스 후보(RC)는 2026년 5월 21일에 락(lock)되며, 최종 사양은 7월 28일 공개된다. SDK 메인테이너와 클라이언트 구현자를 위한 유효성 검증 기간은 10주이고, Tier 1 SDK는 이 기간 내 지원될 예정이다.

이번 변경에는 Stateless Core 외에도 Extensions 프레임워크, Tasks, MCP Apps, authorization hardening, 공식 deprecation policy가 포함된다. 여기서는 Apps나 Tasks보다 HTTP 인프라 확장성과 마이그레이션에 집중한다.

요청마다 컨텍스트를 전달하는 프로토콜

기존 MCP는 연결 시점의 핸드셰이크에서 프로토콜 버전, 클라이언트 정보, capabilities를 교환하고 세션을 유지했다. 신규 모델에서는 이 정보가 요청별 _meta에 실린다. 서버 인스턴스에 상태를 묶지 않으므로 어떤 요청이 어느 인스턴스에 도달하더라도 처리할 수 있다.

이 변화로 initialize/initialized 핸드셰이크(SEP-2575)와 Mcp-Session-Id 헤더(SEP-2567)가 제거된다. 세션 고정, 공유 세션 스토어, 게이트웨이의 심층 패킷 검사(DPI)에 의존하던 구성이 줄어들고, 라운드로빈 로드밸런서만으로 수평 확장할 수 있는 요청 모델이 만들어진다.

Streamable HTTP POST에는 SEP-2243의 Mcp-Method, Mcp-Name 표준 헤더가 필수다. 로드밸런서, 게이트웨이, 레이트리미터는 본문을 파싱하지 않고도 오퍼레이션 단위로 라우팅과 제한을 수행할 수 있다. 헤더와 본문이 일치하지 않으면 서버가 요청을 거부하며, MCP-Protocol-Version 헤더에는 2026-07-28처럼 프로토콜 버전을 명시한다.

다중 왕복 요청은 SEP-2322에서 다룬다. 영속 SSE 스트림 대신 InputRequiredResult 페이로드에 요청 상태를 담아 전달한다. 재시도 요청은 다른 인스턴스가 이어받을 수 있고, 서버 개시 요청(SEP-2260)은 클라이언트 요청을 처리하는 중에만 발생한다.

⤢✕

캐시와 추적, 인가를 요청 경로에 붙이는 방식

list/read 응답은 SEP-2549의 ttlMs, cacheScope를 포함할 수 있다. 이는 클라이언트 측 캐싱과 CDN 활용을 위한 정보이며, 원본 호출 부하를 낮추는 캐시 정책의 기반이 된다.

분산 추적은 SEP-414를 통해 W3C Trace Context의 traceparent, tracestate, baggage를 _meta로 전파한다. MCP 요청을 기존 관측성 체계에 연결할 때 구현별 방식 대신 표준 형식을 사용할 수 있다.

인가 측면에서는 OAuth 2.0/OIDC 정렬을 강화한다. iss 파라미터 검증은 SEP-2468과 RFC 9207에 따르고, DCR에서는 SEP-837의 application_type 선언을 다룬다. SEP-2352는 발급자(issuer) 바인딩과 서버 이전 시 재등록을, SEP-2207은 리프레시 토큰 흐름 문서화를 포함한다.

서버 구현과 전환 작업에서 바뀌는 지점

새 MCP 서버는 요청 간 인메모리 상태에 의존하지 않아야 한다. 필요한 컨텍스트는 _meta 또는 외부 저장소에서 다시 구성하도록 설계한다. Mcp-Method, Mcp-Name을 파싱하고 본문과의 일치 여부를 검증하는 로직도 필요하다. list/read 응답에는 상황에 맞는 ttlMs, cacheScope를 부여해 캐시 정책을 설계한다.

기존 stateful 구현을 옮길 때는 스티키 세션과 공유 세션 DB에 의존한 코드를 분리·폐기한다. 영속 SSE는 InputRequiredResult 기반 다중 왕복 패턴으로 재설계한다.

Roots, Sampling, Logging은 SEP-2577에 따라 폐기 대상이지만 최소 12개월 유지된다. 전환 경로는 다음과 같다.

Roots는 도구 파라미터 또는 리소스 URI로 대체한다.
Sampling은 직접 LLM 통합으로 옮긴다.
Logging은 stderr 또는 OpenTelemetry를 사용한다.

버전 호환을 위해서는 MCP-Protocol-Version 협상 경로를 준비하고, 발급자 바인딩과 서버 이전 시 재등록 자동화를 적용해야 한다. 운영 비용을 검토할 때는 Redis 등의 세션 스토어, 게이트웨이 DPI, 스티키 라우팅 인프라가 제거 대상이다. 반대로 헤더 기반 라우팅 규칙, 캐시 TTL 정책, 추적 파이프라인은 새로 관리해야 할 영역이다. SEP 기반 변경 추적, 폐기 정책 준수, SDK Tier별 지원 로드맵도 거버넌스 범위에 포함된다.

기존 세션 모델과 달라지는 운영 조건

구분	Stateless Core (2026-07-28)	기존 Stateful 프로토콜
세션 관리	세션·핸드셰이크 제거, 무상태 요청	`Mcp-Session-Id` 기반 세션 고정
로드밸런싱	라운드로빈만으로 충분	스티키 세션·session affinity 필요
라우팅	`Mcp-Method`/`Mcp-Name` 헤더(본문 미검사)	게이트웨이 DPI로 본문 파싱
확장 인프라	일반 HTTP·CDN·서버리스	전용 세션 서버·공유 세션 스토어
운영 비용	세션 스토어 불요 → 절감	세션 저장·동기화 상시 비용
하위 호환	폐기 기능 12개월+ 유지, SEP 이행	사양 변경 시 재연결 부담
관측성	W3C Trace Context 표준 전파	구현별 상이

무상태 코어는 상태 동기화 오버헤드를 없애 수평 확장의 한계를 완화하고 세션 인프라 비용을 줄인다. 일반 HTTP 스택을 재사용하므로 벤더와 플랫폼 종속도 완화하며, 서버리스 콜드스타트 부담도 감소한다. 다만 대규모 사양 변경인 만큼, 12개월+의 폐기 유예와 SEP 이행 경로가 파괴적 전환의 위험을 완충하는 역할을 한다.

표준 거버넌스와 배포 생태계의 변화

상태를 프로토콜에서 분리하면 애플리케이션 계층과 인프라 계층의 관심사 분리(SoC)가 가능해진다. 무상태 REST, CDN 캐싱, 오토스케일링처럼 검증된 웹 확장 패턴을 AI 도구 연동에도 재사용할 수 있다.

SEP 번호를 기준으로 변경을 추적하면 표준 변경에 대한 감사 추적성(auditability)을 확보할 수 있다. 12개월 유예와 별도 SEP 요구를 포함하는 공식 폐기 정책은 표준 안정성과 이해관계자의 예측 가능성을 뒷받침한다. OAuth/OIDC 및 RFC 9207에 맞춘 인가 강화는 엔터프라이즈 보안 컴플라이언스와 ISMS 정합성 측면에서도 도입 근거가 된다.

7월 28일 최종 사양이 확정되고 Tier 1 SDK 지원이 확산되면 원격 MCP 서버의 서버리스·엣지 배포가 가속될 전망이다. 세션 인프라를 제거하면서 MCP 서버 운영의 진입장벽은 낮아지고, 중소 조직의 도구 서버 자체 호스팅도 증가할 것으로 예상된다. 헤더 기반 라우팅과 레이트리밋은 API 게이트웨이의 표준 기능으로 편입되고, 관측성·거버넌스 도구 생태계도 확장될 수 있다. Roots·Sampling·Logging의 대체 경로가 정착하면 2026년 말까지 무상태 아키텍처가 사실상 기본값이 될 전망이다.