MCP 무상태 코어로 바뀌는 원격 서버 운영

MCP 2026-07-28 사양의 무상태 코어가 세션 어피니티, 세션 스토어, 게이트웨이 운영 구조에 미치는 변화를 정리한다.

2026-08-31 · 최초 발행 2026-07-26

세션을 전제로 하던 원격 MCP 서버가 달라진다

MCP 2026-07-28 사양은 프로토콜 출시 이후 최대 규모의 개정으로, 릴리스 후보가 앞서 확정됐고 최종 사양은 7월 28일 공개될 예정이다. Extensions 프레임워크, Tasks, MCP Apps, 인가 강화, 공식 폐기 정책도 함께 포함되지만 운영 구조에 가장 직접적인 변화는 stateless 코어다.

기존 원격 MCP 서버는 연결을 맺을 때 initialize/initialized 핸드셰이크를 수행하고, 프로토콜 버전·클라이언트 정보·capabilities를 세션에 보관했다. 그 구조에서는 Mcp-Session-Id 헤더, 세션 어피니티, 공유 세션 스토어, 게이트웨이의 심층 패킷 검사(DPI)가 따라왔다.

새 사양에서는 이 정보가 요청별 _meta로 전달된다. 서버 인스턴스가 연결 상태를 붙잡아 둘 이유가 사라지므로, 일반 라운드로빈 로드밸런서 뒤의 어떤 인스턴스도 요청을 처리할 수 있다. 서버리스와 CDN을 포함한 표준 HTTP 인프라로 확장하는 길도 열린다.

요청마다 전달되는 메타데이터와 라우팅 헤더

무상태화는 세션을 없애는 데서 그치지 않는다. Mcp-Method, Mcp-Name 같은 라우팅 가능 헤더를 통해 로드밸런서, 게이트웨이, 레이트리미터가 본문을 파싱하지 않고도 오퍼레이션 단위로 요청을 다룰 수 있다. 헤더와 본문이 일치하지 않으면 서버가 요청을 거부하므로, 이 헤더는 처리 편의와 무결성 검증을 함께 담당한다.

추가 입력이 필요한 흐름도 영속 SSE(Server-Sent Events) 스트림에 계속 묶일 필요가 없다. 서버는 InputRequiredResult 페이로드에 요청 상태를 담아 돌려주고, 재시도 요청은 다른 인스턴스가 이어받을 수 있다. 여러 번 왕복하는 대화에서도 무상태 특성을 유지하는 방식이다.

listread 응답에는 ttlMs, cacheScope를 활용할 수 있다. CDN 및 클라이언트 캐싱으로 원본 호출량을 줄일 수 있으며, 인증에서는 OAuth 2.0/OIDC 정렬이 강화된다. 발급자(iss) 검증, 동적 클라이언트 등록의 클라이언트 유형 선언, 발급자 바인딩, 서버 이전 시 재등록, 리프레시 토큰 흐름이 여기에 포함된다. MCP-Protocol-Version 헤더는 사양 버전을 명시하고 하위 호환 협상의 경로를 제공한다.

Mcp-Method / Mcp-Name헤더MCP 클라이언트 (_meta에버전·capabilities 탑재)라운드로빈 로드밸런서MCP 서버 인스턴스 AMCP 서버 인스턴스 B서버리스 함수 인스턴스OAuth 2.0 / OIDC 인가 (iss검증)CDN·클라이언트 캐시 (ttlMs,cacheScope)외부 상태 저장소 (필요명시적 조회)

기존 stateful 구현을 옮길 때 확인할 지점

마이그레이션은 먼저 인메모리 캐시, 세션 스코프 변수, 연결 단위 초기화 로직처럼 세션에 기대는 지점을 찾는 데서 시작한다. initialize 시점에 받던 정보는 요청별 _meta 파싱으로 바꿔야 하며, Mcp-Method·Mcp-Name 헤더 처리와 본문 일치 검증도 구현 대상이다.

영속 SSE 스트림은 다중 왕복 패턴으로 다시 설계한다. 요청 간에 꼭 유지해야 하는 상태가 있다면 외부 저장소로 옮기고, 서버가 세션을 추론하는 대신 클라이언트가 상태 키를 전달하도록 구성한다. 이렇게 해야 어느 인스턴스가 요청을 받더라도 독립적으로 처리할 수 있다.

인증과 권한은 발급자 바인딩, 서버 이전 시 재등록 자동화, 각 인스턴스의 독립적인 토큰 검증을 중심으로 다시 설계한다. 키 배포와 캐싱도 이 전제를 따라야 한다.

폐기 예정 기능도 대체 경로를 적용해야 한다. Roots는 도구 파라미터·리소스 URI로, Sampling은 직접 LLM 통합으로, Logging은 stderr 또는 OpenTelemetry로 전환한다.

전환 구간에서는 신구 사양을 동시에 지원하고 MCP-Protocol-Version으로 요청을 분기할 수 있다. 카나리 배포로 무상태 경로의 비중을 점차 늘리며, 실패율과 지연을 기준으로 롤백 지점을 미리 정한다. 사양 변경은 제안 번호(SEP) 단위로 추적하고, 폐기 정책 준수 일정과 SDK Tier별 지원 시점을 이행 계획에 반영한다.

운영 모델별 차이

구분 Stateless 코어(2026-07-28) Sticky Session 기반 운영
세션 관리 없음(요청별 _meta) 세션 ID 발급·보관·만료 관리
로드밸런서 라운드로빈으로 충분 세션 어피니티 설정 필수
라우팅 판단 표준 헤더(본문 미검사) 게이트웨이 심층 검사
상태 저장소 불필요(필요 시 명시적 외부 조회) 공유 세션 스토어 상시 운영
확장 방식 서버리스·CDN 포함 표준 HTTP 전용 세션 서버 중심
장애 영향 인스턴스 손실 시 재시도로 흡수 세션 보유 인스턴스 손실 시 대화 단절
운영 복잡도 낮음 높음

세션 어피니티는 스케일아웃 시 트래픽 편중을 만들고, 인스턴스 교체 때 세션 유실을 동반한다. 무상태 코어는 이 문제를 구조적으로 제거한다. 대신 요청마다 메타데이터를 보내야 하고, 서버도 매 요청 검증 비용을 부담한다.

세션 어피니티 게이트웨이는 세션 테이블과 본문 검사에 CPU·메모리를 지속적으로 사용한다. 라운드로빈과 헤더 기반 라우팅은 같은 처리 목적을 표준 계층에 옮기므로 게이트웨이 사양을 낮출 수 있고, 관리형 로드밸런서의 선택 폭도 넓어진다.

즉시 새 표준을 채택하면 운영 단순화 효과를 빠르게 얻을 수 있지만 클라이언트 SDK 지원 시점에 영향을 받는다. 하위 호환을 병행하면 안전하지만 이중 코드 경로의 유지 비용이 생긴다. 폐기 기능에는 12개월 이상 유예가 부여되므로, 신규 서버는 무상태로 설계하고 기존 서버는 병행 운영 뒤 전환하는 접근이 적합하다.

상태 분리가 바꾸는 거버넌스와 인프라 범위

상태를 프로토콜 계층에서 분리하면 애플리케이션과 인프라의 관심사 분리(SoC)가 분명해진다. 무상태 REST, CDN 캐싱, 오토스케일링처럼 웹 시스템에서 쓰던 확장 패턴을 AI 도구 연동에도 재사용할 수 있다. 서버리스 선택지가 생기면서 도구 서버의 가용성 설계는 애플리케이션 내부 문제보다 인프라 구성 문제에 가까워진다.

제안 번호 기반 변경 추적과 공식 폐기 정책은 표준 변경의 감사 추적성과 이해관계자 예측가능성을 제공한다. 조달·계약 문서에서 지원 사양 버전을 명시할 근거가 되며, OAuth 2.0/OIDC 정렬 강화는 엔터프라이즈 접근통제 요건 및 정보보호 관리체계와의 정합성을 높인다.

세션 스토어를 제거하면 상태 보유 구성요소가 줄어든다. 장애 지점과 백업·복구 범위가 함께 축소되고, 구성 관리 대상 감소는 운영 리스크 감소로 이어진다.

사양 확정 이후의 변화

7월 28일 최종 사양 확정 후 Tier 1 SDK 지원이 확산되면 원격 MCP 서버의 서버리스·엣지 배포가 본격화할 전망이다. 세션 인프라 요구가 사라지면서 중소 조직의 자체 도구 서버 호스팅이 늘고, 사내 MCP 서버 수가 급증할 전망이다.

헤더 기반 라우팅과 레이트리밋은 API 게이트웨이의 표준 기능으로 편입되고, 관측성·거버넌스 도구 생태계도 확장될 수 있다. 폐기 기능의 대체 경로가 정착하면서 2026년 말까지 무상태 구성이 원격 MCP 서버의 사실상 기본값으로 자리할 전망이다.

Sources

MCP무상태 아키텍처서버리스로드밸런싱OAuth