MCP의 Stateless 전환, 무엇이 바뀌었나
MCP(Model Context Protocol) 2026-07-28 스펙이 공개되면서 프로토콜의 근본적인 구조 변화가 이루어졌다. 핵심은 두 가지다. 첫째, 기존에 필수였던 initialize 핸드셰이크와 세션 헤더가 제거됐다. 둘째, 게이트웨이가 JSON 바디를 파싱하지 않고도 라우팅 결정을 내릴 수 있도록, 메서드명과 툴 이름을 담은 필수 HTTP 헤더가 새롭게 추가됐다.
이전 스펙에서는 에이전트가 서버와 통신하기 전에 반드시 initialize 요청을 통해 세션을 수립해야 했다. 이 세션 식별자는 이후 모든 요청에 헤더로 포함되어 서버가 상태를 유지하는 근거가 됐다. 변경된 스펙에서는 이 과정이 사라지고, 각 요청이 독립적으로 처리될 수 있는 구조로 전환된다.
# 변경 전 (세션 기반)
POST /mcp
Session-Id: abc-123
Content-Type: application/json
# 변경 후 (Stateless)
POST /mcp
MCP-Method: tools/call
MCP-Tool-Name: get_weather
Content-Type: application/json
게이트웨이·로드밸런서 설계에서의 실무 의미
이 변화가 백엔드 아키텍처에 미치는 가장 직접적인 영향은 게이트웨이와 로드밸런서 레이어에 있다. 기존 세션 기반 구조에서는 특정 세션 요청이 반드시 동일한 서버 인스턴스로 라우팅되어야 했다. 이른바 Sticky Session 문제다. 이 제약이 수평 확장(Scale-out)을 복잡하게 만드는 주요 원인이었다.
Stateless 전환 이후에는 Nginx, Envoy, AWS ALB와 같은 일반적인 HTTP 로드밸런서가 별도의 세션 친화성(Session Affinity) 설정 없이도 MCP 트래픽을 라우팅할 수 있다. 또한 메서드명과 툴 이름이 HTTP 헤더에 노출되므로, 게이트웨이에서 JSON 바디를 파싱하지 않고도 헤더 기반 라우팅 규칙을 적용할 수 있다. 예를 들어 MCP-Tool-Name: image_generate인 요청만 GPU 특화 인스턴스로 보내는 라우팅이 가능해진다.
# Envoy 헤더 기반 라우팅 예시
routes:
- match:
headers:
- name: MCP-Tool-Name
exact_match: image_generate
route:
cluster: gpu_cluster
- match:
prefix: "/"
route:
cluster: general_cluster
이는 마이크로서비스 환경에서 에이전트 트래픽을 툴 유형별로 분리 배포하고 독립적으로 스케일링할 수 있는 토대가 된다.
"결국 REST인가"라는 개발자 커뮤니티의 반응
이번 스펙 변경에 대해 개발자 커뮤니티의 반응은 엇갈린다. 비판적인 시각에서는 "핸드셰이크를 제거하고 헤더로 메타데이터를 전달하는 것은 REST가 수십 년 전에 정착시킨 개념의 재발견"이라고 지적한다. Stateless 요청, 헤더 기반 메타데이터, 독립적인 요청 처리 — 이 모든 것이 RESTful API의 기본 원칙과 겹친다는 것이다.
반면 옹호 측에서는 "표준화 자체가 목적"이라는 논리를 편다. 다양한 AI 에이전트 프레임워크와 툴 생태계가 난립하는 상황에서, 설령 REST와 유사하더라도 통일된 프로토콜이 존재함으로써 상호운용성이 확보된다는 점에서 의미가 있다는 입장이다. HTTP 표준을 그대로 쓰지 않고 MCP라는 레이어를 유지하는 이유는, 툴 호출 시맨틱과 에이전트 컨텍스트에 특화된 의미론적 규약을 명시하기 위해서라고 볼 수 있다.
실무 관점에서 중요한 것은 이 논쟁의 결론보다, 변화의 방향성이다. MCP가 Stateless로 수렴하고 있다는 사실은, 기존 HTTP 인프라 위에서 에이전트 시스템을 운영하려는 팀에게 진입 장벽이 낮아진다는 신호로 읽힌다.
정리
initialize핸드셰이크와 세션 헤더 제거로 MCP가 Stateless 구조로 전환되어 Sticky Session 없이 수평 확장이 용이해졌다.- 메서드명·툴 이름이 HTTP 헤더에 노출되어, 게이트웨이에서 JSON 파싱 없이 헤더 기반 라우팅 규칙을 적용할 수 있다.
- "REST의 재발명"이라는 비판도 있지만, 에이전트 툴 호출에 특화된 표준화는 이기종 시스템 간 상호운용성 확보 측면에서 실질적 가치를 가진다.