MCP 무상태 코어 전환과 요청 단위 협상 설계
SEP-2575의 initialize 핸드셰이크 제거가 MCP 서버 구조에 미치는 영향과 요청 단위 협상, 상태 외부화, 재시도 안전성 설계를 정리한다.
2026-09-01 · 최초 발행 2026-07-28
핸드셰이크 없이 시작하는 MCP 서버
MCP 신규 사양의 SEP-2575는 initialize / initialized 교환을 제거하고 프로토콜을 무상태 코어로 바꾼다. 클라이언트는 연결을 준비하는 별도 단계 없이 첫 요청부터 작업을 보낼 수 있다.
기존 핸드셰이크가 맡던 역할은 요청 단위 메타데이터로 이동한다. 프로토콜 버전, 클라이언트 신원, 클라이언트 능력은 각 요청의 _meta 필드로 전달된다. 서버의 능력을 미리 확인해야 한다면 server/discover를 필요한 시점에 호출한다.
SEP-2567의 Mcp-Session-Id 제거까지 결합되면서 프로토콜 수준의 세션은 사라진다. 연결 수립 비용이 없어 서버리스와 함수형 배포에는 잘 맞지만, 세션과 인메모리 상태를 전제로 구현한 서버는 구조를 다시 잡아야 한다.
요청 경로에서 판단해야 하는 것들
핸드셰이크에서 한 번 검증하던 버전, 능력, 권한은 이제 매 요청마다 판정해야 한다. 메타 정보 파싱이 핫패스에 들어오므로 클라이언트 식별자 기준 캐싱이 필요할 수 있다. 다만 캐시는 다시 상태를 들이는 일이므로, 캐시 미스가 정상 처리에 영향을 주지 않는 순수한 최적화로 한정해야 한다.
요청마다 전달되는 메타 정보는 그대로 오버헤드가 된다. 필수 항목의 범위를 좁히고, 나머지 정보는 조회 경로로 넘기는 편이 낫다. 민감 정보가 메타데이터에 포함되면 반복 전송과 로그 기록으로 노출 면적도 커진다.
무상태 서버는 재시도를 안전하게 받아들일 수 있어야 한다. 같은 요청이 서로 다른 인스턴스에서 다시 실행되어도 결과가 일관돼야 하며, 부작용이 있는 도구 호출에는 멱등성 키와 서버 측 중복 실행 차단이 필요하다. 클라이언트가 실패 후 다시 요청할 수 있는 반면 서버는 세션으로 중복을 판별할 수 없기 때문이다.
상태는 사라지지 않고 외부로 이동한다
대화 맥락, 인증 컨텍스트, 진행 중인 작업 상태는 캐시나 DB 같은 외부 저장소로 옮겨야 한다. 접근 빈도가 높은 상태는 인메모리 캐시 계층에, 영속성이 필요한 상태는 데이터베이스에 두는 이원화가 가능하다.
외부 저장소 조회는 요청 지연에 그대로 더해진다. 상태 조회를 요청당 1회로 묶는 설계가 유리한 이유다. 저장소가 병목 또는 단일 장애점이 될 수 있으므로, 이중화와 축퇴 운전 정책도 함께 정해야 한다.
반면 요청과 외부 상태 스냅샷이 남으면 장애 재현은 쉬워진다. 특정 인스턴스에 묶이지 않으므로 어느 인스턴스에서도 같은 조건을 재현할 수 있다.
콜드스타트도 설계 대상이 된다. 서버리스 배포에서는 부팅 비용이 사용자 지연으로 드러난다. 도구 카탈로그와 스키마를 부팅 시점이 아니라 최초 사용 시점에 불러오는 지연 로딩이 이를 줄이는 방법이다.
전환 전에 확인할 서버의 상태 의존성
먼저 도구 호출이 순수 함수에 가깝고 상태 의존이 적은 서버부터 전환하는 편이 좋다. 이런 서버는 어댑터 수준의 변경으로 대응할 수 있다. 장시간 작업, 스트리밍 진행 상황, 대화 맥락 누적을 세션에 보관하던 서버는 후순위로 두고 구조 재설계를 준비해야 한다.
전환 대상에서는 세션 ID를 키로 사용하는 자료구조, 연결 시점에 초기화하는 전역 상태, 클라이언트별 인메모리 캐시를 전수 조사한다. 발견한 항목을 제거·외부화·요청 내 전달로 나누면 작업 규모를 파악할 수 있다.
전환 전후에는 동일 부하로 지연을 비교해야 한다. 무상태 구조는 요청당 메타 파싱과 상태 조회를 더한다. 콜드스타트 지연과 외부 저장소 장애 시 동작도 검증 항목에 포함해야 한다.
세션 기반 경로와 무상태 경로를 함께 운영하는 기간에는 계약 테스트로 동작 일치를 강제할 필요가 있다. 새 저장소에 상태 데이터가 쌓이는 만큼 보존 기간, 암호화, 접근 권한 정책도 전환 범위에 포함된다.
배포 모델에 따라 달라지는 선택
| 구분 | 무상태 코어 | 세션 기반 프로토콜 |
|---|---|---|
| 확장성 | 임의 인스턴스 라우팅 | 어피니티 필요 |
| 요청 오버헤드 | 메타 반복 전송 | 최초 1회 |
| 구현 복잡도 | 상태 외부화 필요 | 인메모리로 단순 |
| 장애 복원력 | 인스턴스 교체 무영향 | 세션 유실 발생 |
| 재현성 | 요청 단독 재현 가능 | 세션 이력 필요 |
| 적합 상황 | 수평 확장·서버리스 | 장시간 상태 유지 |
무상태 코어는 인스턴스 교체나 롤링 배포 중 연결 유실 문제를 줄이고, 수평 확장과 장애 복원력에 유리하다. 세션 기반 방식은 처음 구현하기 쉽고 요청당 오버헤드가 작지만, 규모가 커질수록 어피니티, 공유 저장소, 게이트웨이 설정이 따라온다. 트래픽이 커질수록 세션 유지 비용은 요청 단위 메타 전송 비용을 크게 넘어선다.
서버리스는 트래픽이 불규칙하고 유휴 시간이 길며 콜드스타트를 감내할 수 있는 워크로드에 맞는다. 유휴 비용이 없고 스케일 제로가 가능하지만, 콜드스타트와 대형 아티팩트 적재에는 취약하다. 대형 모델이나 인덱스를 적재해야 하거나 지연 SLO가 엄격하다면 워밍 상태를 유지하는 상주 프로세스가 더 적합하다.
운영의 중심은 저장소와 재시도 규약이 된다
무상태 전환은 상태를 없애는 일이 아니라 위치를 바꾸는 일이다. 어피니티를 제거하면 인스턴스를 늘리는 것만으로 처리량을 늘릴 수 있는 구조가 가능해지고, 무중단 배포와 오토스케일, 장애 인스턴스 교체도 프로토콜 수준에서 안전해진다.
그 대가로 외부 상태 저장소의 지연과 가용성이 서버 설계의 제약이 된다. 요청당 메타 정보의 크기 역시 최적화 대상이 된다. 특히 부작용이 있는 도구는 멱등성 키와 재시도 규약을 분리해서 다룰 수 없다. 재시도 자유도가 중복 실행 위험으로 이어지지 않도록 둘을 함께 설계해야 한다.
요청 단위 협상이 도구 연결 프로토콜의 표준 패턴으로 자리 잡으면 세션 기반 설계는 레거시로 분류되는 흐름이 이어질 수 있다. 서버리스 MCP 서버 배포가 일반화되면서 지연 로딩과 프리워밍 같은 콜드스타트 최적화도 구현 관행으로 확산할 전망이다. SDK 역시 상태 외부화 계층을 기본 제공하는 방향으로 진화해 재작성 부담을 낮출 수 있다.
Sources
- The 2026-07-28 MCP Specification Release Candidate | Model Context Protocol Blog
- MCP 2026-07-28 goes stateless: the initialize handshake and session id are gone | AGORÀ Intelligence
- MCP Goes Session-less — What the 2026-07-28 Release Candidate Actually Changes | Medium
- MCP Just Went Stateless — What the 2026 Spec Changes About Scaling on App Service | Microsoft Community Hub
- MCP Goes Stateless: 2026-07-28 RC Breaks and Fixes | byteiota
- MCP 2026-07-28: The Stateless Release Candidate, Explained | MCP.Directory