MCP 무상태 전환 이후의 확장 아키텍처 설계

핸드셰이크가 사라진 뒤 남는 설계 문제

MCP 2026-07-28 스펙에서는 initialize와 initialized 핸드셰이크가 제거됐다. 프로토콜 코어가 완전 무상태가 되면서 요청 사이에 서버 측 상태를 유지할 필요도 없어졌다.

이 변화는 서버리스와 엣지 배포에서 특히 직접적이다. 세션을 특정 인스턴스에 묶어 둘 이유가 없어지고, 요청량에 맞춰 인스턴스를 늘리거나 줄이는 구조를 만들기 쉬워진다. 반대로 서버가 들고 있던 대화 맥락, 인증 상태, 진행 중 작업의 위치는 새로 정해야 한다. 서버에서 상태를 없앤다고 상태 자체가 사라지는 것은 아니다.

운영의 초점도 상태 유지 서버 관리에서 요청의 완결성으로 이동한다. 요청마다 인증을 확인하고, 필요한 맥락을 확보하며, 도구 목록과 프로토콜 버전을 확인할 수 있어야 한다. Gemini Managed Agents가 백그라운드 실행과 원격 MCP를 운영 기능으로 편입한 흐름도 이 전환과 맞닿아 있다.

요청이 어느 인스턴스에 도착해도 처리되게 만들기

무상태 서버의 요청에는 처리에 필요한 정보가 모두 들어 있어야 한다. 이전 요청의 결과를 전제로 하면 인스턴스가 바뀌는 순간 문제가 생긴다. 먼저 도구 목록, 인증 상태, 진행 중 작업처럼 요청 완결성을 깨뜨리는 의존 지점을 찾아야 한다.

대화 맥락과 작업 진행 상태는 클라이언트가 직접 보유하거나 공유 저장소에 둘 수 있다. 공유 저장소를 선택하면 요청마다 조회 지연이 더해진다. 맥락의 크기와 조회 빈도를 기준으로 저장 위치를 정해야 한다.

인증도 세션 최초 1회 확인 방식으로는 충분하지 않다. 각 요청에서 토큰의 유효 기간과 권한을 검증해야 한다. 검증 결과를 짧게 캐시하면 부하를 줄일 수 있지만, 캐시 수명이 길수록 권한 회수 반영은 늦어진다.

핸드셰이크가 맡았던 도구 목록 동기화와 버전 협상 역시 요청 경로로 옮겨야 한다. 도구 목록의 버전 또는 해시를 응답에 포함해 변경을 알리고, 클라이언트가 사라진 도구를 호출하지 않도록 한다. 프로토콜 버전은 요청 헤더나 별도 조회로 확인하며, 지원하지 않는 버전에는 원인을 알 수 있는 응답 형식을 제공해야 한다.

⤢✕

기존 상태 기반 클라이언트도 전환 기간에는 고려 대상이다. 이전 스펙의 핸드셰이크 요청을 무시하거나 성공 응답으로 처리하는 호환 경로를 두고, 종료 시점은 미리 알려야 한다. 호환을 무기한 유지하면 두 벌의 구현이 영구적으로 남는다.

세션 고정을 제거한 뒤에는 단순 부하 분산으로 전환할 수 있다. 인스턴스 수는 요청량에 맞춰 조절하되, 축소 과정에서 진행 중인 요청이 보장되는지 확인해야 한다. 서버리스 배포에서는 첫 요청의 지연을 줄이도록 초기화 작업을 최소화하고, 무거운 초기화가 필요하다면 그 부분만 상시 인스턴스로 분리한다.

상태를 옮기기 전에 확인할 운영 항목

전환은 현행 서버가 어떤 상태에 의존하는지 조사하는 일에서 시작한다. 세션 변수, 메모리 캐시, 진행 중 작업 핸들을 코드에서 찾아 목록화하지 않으면, 부하 분산 이후에 간헐적 실패로 드러날 가능성이 크다.

찾아낸 상태는 요청에 포함할 것, 공유 저장소에 보관할 것, 버릴 것으로 나눈다. 옮기는 비용보다 없애는 편이 나은 상태도 있다. 외부 저장소는 조회 지연, 일관성 수준, 만료 지원을 기준으로 선택하고, 저장소가 새로운 단일 장애점이 되지 않도록 이중화도 함께 계획한다.

무상태 인스턴스와 기존 인스턴스를 병행 운영하면서 트래픽을 점진적으로 옮기는 방식이 필요하다. 이전 비율마다 관측 지표를 두면 문제가 생겼을 때 원인 구간을 좁힐 수 있다. 구 스펙 클라이언트의 종료일과 지원 동작을 명시하고, 호환 경로로 들어오는 요청 비율을 종료 판단의 근거로 사용한다.

요청별 인증 검증과 맥락 조회가 추가하는 지연도 따로 측정해야 한다. 콜드스타트 발생률은 평균 지연에 묻히기 쉬우므로 별도 지표로 관리한다. 맥락 저장 위치 변경, 호환 기간 연장, 토큰 검증 캐시 수명과 권한 회수 반영 지연은 거버넌스와 보안 검토의 대상이다.

선택지별 비용이 달라지는 지점

구분	무상태 코어	세션 유지 프로토콜
수평 확장 비용	낮음	높음
인스턴스 장애 영향	요청 단위	세션 전체
요청당 처리 부하	높음	낮음
맥락 전송량	많음	적음
구현 단순성	높음	낮음
콜드스타트 노출	있음	적음

무상태 코어에서는 어느 인스턴스가 요청을 받아도 처리할 수 있으므로 세션 고정 없이 분산할 수 있다. 인스턴스 증설과 축소가 자유롭고, 인스턴스 장애의 영향도 해당 요청으로 제한된다. 대신 인증 검증과 맥락 확보가 매 요청마다 필요하며, 맥락을 요청에 담으면 전송량이 커진다. 서버리스 환경에서는 콜드스타트도 지연 요인이 된다.

세션 유지 프로토콜은 초기 협상 뒤 서버가 상태를 보유하므로 이후 요청이 가볍고 맥락 전송이 필요 없다. 연결 단위 최적화도 가능하다. 하지만 세션이 특정 인스턴스에 묶여 확장과 축소가 어려우며, 인스턴스 장애가 해당 세션의 진행 중 작업 전체에 영향을 준다. 세션 고정을 위한 부하 분산 설정도 계속 관리해야 한다.

요청 빈도는 낮지만 맥락이 큰 워크로드라면 무상태화에 따른 전송 비용이 부담이 될 수 있다. 이 경우 맥락은 공유 저장소에 보관하고 요청에는 참조만 넣는 절충이 필요하다.

요청별 인증 검증은 권한 회수와 토큰 폐기를 즉시 반영할 수 있고, 탈취된 세션이 장기간 유효한 상태로 남는 문제를 줄인다. 인스턴스 간 인증 상태 공유가 필요 없다는 점도 확장 구조에 맞는다. 반면 검증 호출이 요청마다 발생하므로 지연과 인증 서버 부하가 함께 늘어난다. 검증 결과를 캐시하면 부하는 낮아지지만 권한 회수 반영은 늦어진다. 검증 결과를 수십 초 수준으로만 캐시하는 구성은 이 두 요소를 함께 통제하는 균형점이다.

외부 저장소에 맥락을 두면 요청에는 참조만 담으므로 전송량이 작고, 여러 클라이언트가 같은 작업을 이어받을 수 있다. 서버가 맥락의 일관성을 통제할 수 있는 장점도 있다. 다만 저장소 조회가 요청마다 추가되고, 저장소가 확장 병목이나 단일 장애점이 될 수 있으며 만료와 정리 작업도 필요하다.

클라이언트가 상태를 보유하면 서버에 별도 저장소가 필요 없고 조회 지연도 없다. 서버는 완전한 무상태로 유지된다. 그러나 맥락이 커질수록 전송량, 대역폭, 처리 시간이 함께 늘며 클라이언트의 맥락 조작에 대한 신뢰 경계도 생긴다. 여러 클라이언트 사이에서 작업을 넘기기도 어렵다. 맥락이 작고 신뢰할 수 있는 클라이언트라면 클라이언트 보유가 가능하고, 그 외에는 참조 기반 외부 저장이 기본 선택이 된다.

분산 환경의 설계 원칙으로 보는 전환

세션 고정 제거와 무상태 설계는 수평 확장성을 확보하는 분산 시스템의 접근이다. 요청 자체의 완결성을 보장하면 노드 간 상태 공유 요구를 줄일 수 있다.

버전 협상 대체 경로와 이전 스펙 호환 처리는 인터페이스 버전 관리에서 후방 호환을 다루는 문제다. 도구 목록 캐시와 버전 알림은 통합 지점의 메타데이터 동기화 문제로 볼 수 있다.

성능 측면에서는 요청별 인증 검증이 추가하는 지연을 측정해야 하며, 서버리스 환경에서는 콜드스타트 발생률을 응답시간 분포 관리 항목으로 분리해야 한다.

2026년에 이어질 운영 변화

MCP 서버의 서버리스·엣지 배포가 일반화되면서 세션 고정을 전제로 한 운영 구성은 정리되는 방향이다. 맥락을 참조로 다루는 외부 저장 패턴은 무상태 전환의 표준 구성으로 자리 잡는 흐름이다.

요청별 인증 검증의 부하를 줄이기 위한 짧은 수명 토큰 방식도 확산되는 방향이며, 원격 MCP와 백그라운드 실행은 관리형 에이전트 제품의 기본 기능으로 편입되는 흐름이다.

세션을 유지하는 서버는 확장과 축소가 어렵고, 인스턴스 장애가 세션의 작업 전체로 번질 수 있다. MCP 코어의 무상태 전환은 이 제약을 프로토콜 층에서 걷어냈지만, 맥락을 어디에 둘지는 여전히 설계해야 한다. 요청 완결성을 규격으로 고정하고, 맥락은 참조로 다루며, 인증은 요청마다 검증하되 캐시 수명으로 부하와 권한 회수 반영 지연을 조율하는 구성이 필요하다. 서버리스 배포에서는 무거운 초기화를 분리하지 않으면 콜드스타트가 확장 이득을 잠식할 수 있다.