MCP Stateless 업데이트: 에이전트 서버가 세션 고정 없이 확장되는 방식

검색 의도: MCP Stateless 업데이트, MCP 서버 확장, 에이전트 인프라 설계 핵심 요약: 2026-07-28 MCP 사양 후보는 transport-level session 관리를 제거하고, 각 요청이 독립적으로 처리되는 구조를 제안한다. 에이전트 도구 서버를 Kubernetes, Cloud Run, 일반 HTTP 로드밸런서 뒤에 올리는 팀이라면 세션 저장소와 sticky routing을 다시 설계할 시점이다.

왜 이 업데이트가 개발팀에 중요한가

MCP(Model Context Protocol)는 에이전트가 외부 도구, 파일, 데이터베이스, 사내 API를 호출할 때 쓰는 연결 규격으로 자리 잡고 있다. 처음에는 로컬 개발 환경에서 stdio 기반으로 단일 클라이언트와 단일 서버가 대화하는 구조가 많았다. 이때는 세션을 유지해도 큰 문제가 없었다.

문제는 MCP 서버를 원격 서비스로 배포하는 순간 나온다. 팀이 여러 에이전트를 운영하고, 사용자가 늘고, MCP 서버를 컨테이너 여러 개로 띄우면 기존 세션 모델은 병목이 된다. 요청 1은 A pod로 갔는데 요청 2가 B pod로 가면 B pod는 세션을 모른다. 결과는 Session Not Found 같은 장애다.

Google Developers Blog가 2026년 8월 5일 공개한 글에 따르면, 2026-07-28 MCP specification release candidate는 이런 문제를 해결하기 위해 protocol core에서 transport-level session management를 제거한다. 핵심은 간단하다. 연결 초기화로 상태를 만들고 모든 후속 요청이 그 상태를 참조하는 대신, 각 요청이 필요한 메타 정보를 직접 들고 간다.

기존 MCP 세션 모델의 운영 비용

기존 HTTP 기반 MCP 연결은 초기 initialize 요청 뒤 서버가 Mcp-Session-Id를 발급하고, 이후 요청이 이 값을 계속 들고 다니는 방식이었다. 로컬에서는 자연스럽지만 클라우드에서는 세 가지 비용이 붙는다.

첫째, 로드밸런서가 세션을 이해해야 한다. 일반 round-robin은 요청을 고르게 분산할 뿐, 어느 컨테이너가 어떤 세션을 들고 있는지 모른다. 그래서 sticky session을 켜거나, 게이트웨이에 별도 라우팅 로직을 넣거나, Redis 같은 공유 세션 저장소를 붙이게 된다.

둘째, 장애 복구가 약해진다. 세션을 들고 있던 pod가 재시작되면 해당 대화의 도구 호출 흐름이 끊긴다. LLM 응답은 자연어라 사용자가 다시 시도할 수도 있지만, 에이전트가 여러 도구 호출을 이어 가는 작업에서는 중간 상태 손실이 곧 실패가 된다.

셋째, 서버리스 배포가 애매해진다. Cloud Run, Cloud Functions, Lambda류 환경은 요청 단위 확장과 scale-to-zero가 장점이다. 그런데 프로토콜이 지속 세션을 전제로 하면 이 장점을 제대로 쓰기 어렵다.

Stateless MCP는 무엇을 바꾸나

새 사양 후보의 방향은 요청을 self-describing하게 만드는 것이다. 기존 초기 handshake와 logical Mcp-Session-Id 헤더를 제거하고, protocol version, client info, client capabilities 같은 정보를 요청의 _meta 필드와 헤더에 넣는다.

실무적으로 보면 MCP 서버는 더 이상 “이 사용자의 이전 세션을 내가 갖고 있나?”를 먼저 확인하지 않아도 된다. 대신 “이 요청 하나를 처리하는 데 필요한 입력이 모두 들어 있나?”를 확인하면 된다. 이 차이는 인프라 단순화로 이어진다.

예를 들어 검색 MCP 서버가 있다면 기존에는 세션 생성, capability negotiation, session id 저장, 세션 만료, pod 간 공유 상태를 고민해야 했다. stateless 모델에서는 각 tools/call 요청이 protocol version, tool name, arguments, client capabilities를 같이 전달한다. 서버는 요청을 처리하고 응답하면 끝이다.

바로 얻는 이점과 새로 생기는 주의점

가장 큰 이점은 평범한 HTTP 인프라를 쓸 수 있다는 점이다. round-robin 로드밸런서, autoscaling group, 서버리스 런타임과 궁합이 좋아진다. 특정 pod에 사용자를 붙여 두지 않아도 되므로 트래픽 분산도 예측 가능해진다.

운영팀 입장에서는 장애 격리도 쉬워진다. pod 하나가 죽어도 다음 요청은 다른 pod가 처리할 수 있다. 물론 LLM 대화 맥락 자체는 클라이언트나 상위 orchestration layer가 관리해야 한다. MCP 서버는 도구 호출을 stateless하게 처리하고, 장기 상태는 명시적인 데이터 저장소에 둬야 한다.

주의할 점도 있다. 요청마다 메타 정보가 들어가므로 검증 로직이 더 중요해진다. 서버는 clientInfo를 신뢰 정보로 쓰면 안 된다. capability도 “클라이언트가 주장한 값”일 뿐이다. 인증, 권한, rate limit, audit log는 별도 보안 경계에서 처리해야 한다.

마이그레이션 때 확인할 설계 포인트

이미 원격 MCP 서버를 운영 중이라면 먼저 세션 의존도를 분해해야 한다. 코드에서 session id를 key로 들고 있는 데이터가 무엇인지 나눠보면 된다.

• 인증 토큰: 세션 저장소가 아니라 표준 인증 계층으로 이동
• 대화 상태: MCP 서버가 아니라 에이전트 런타임 또는 애플리케이션 DB로 이동
• 도구 실행 중간 결과: idempotency key와 작업 테이블로 관리
• capability negotiation 결과: 요청별 _meta 검증으로 대체
• rate limit 카운터: 사용자/조직/API key 기준 외부 저장소로 관리

특히 tool call이 외부 시스템을 변경한다면 idempotency가 중요하다. stateless 서버는 재시도에 강하지만, 같은 요청이 두 번 실행될 수도 있다. 결제, 배포, 삭제, 알림 발송 같은 작업은 request id를 받아 중복 실행을 막아야 한다.

개발팀이 지금 해볼 수 있는 실험

첫 실험은 간단하다. 현재 MCP 서버 앞에 sticky session을 끄고 round-robin을 켠 테스트 환경을 만든다. 그런 다음 동일한 에이전트 작업을 20~50회 반복 실행한다. 실패가 난다면 대부분 서버 내부 어딘가에 세션 상태 의존성이 있다는 뜻이다.

두 번째는 메타 필드 검증이다. protocol version이 없거나, 지원하지 않는 version이 오거나, client capabilities가 비어 있을 때 서버가 어떻게 반응하는지 테스트한다. “대충 처리”보다 “명확한 4xx와 로그”가 운영에 유리하다.

세 번째는 장애 주입이다. 도구 호출 중 pod를 재시작해도 다음 요청이 이어지는지 본다. 이 테스트를 통과하면 에이전트 도구 서버가 클라우드 네이티브 서비스에 가까워진다.

실행 체크리스트

• 원격 MCP 서버에서 Mcp-Session-Id 의존 코드가 있는지 찾는다.
• sticky session, Redis session store, gateway session inspection 사용 여부를 문서화한다.
• 대화 상태와 도구 서버 상태를 분리한다.
• tool call마다 idempotency key를 받을 수 있게 만든다.
• protocol version과 _meta 검증 실패를 명확히 로깅한다.
• round-robin 환경에서 반복 호출 테스트를 돌린다.
• 서버리스 배포 후보라면 cold start와 재시도 정책을 같이 측정한다.

출처: Google Developers Blog, “Scaling AI Agent Infrastructure with the MCP Stateless updates”, 2026-08-05.