
MCP가 스테이트리스(Stateless)화되어 AI 에이전트 기반의 수평 확장(Horizontal Scaling)이 가능해지다
요약
Model Context Protocol(MCP)이 스테이트리스(Stateless) 구조로 업데이트되어 AI 에이전트 인프라의 수평 확장이 가능해졌습니다. 이를 통해 서버리스 배포와 표준 부하 분산이 용이해지며, MRTR 도입으로 장시간 태스크 처리의 제약도 해소되었습니다.
핵심 포인트
- MCP 코어의 스테이트리스화로 수평 확장 및 서버리스 배포 지원
- MRTR(Multi Round-Trip Requests) 도입으로 타임아웃 제약 극복
- 기존 스테이트풀 기반 구현체는 새로운 사양에 맞춘 이행 작업 필요
- Python, TypeScript, Go, C# 등 다양한 SDK 지원
2026년 7월 28일, Model Context Protocol (MCP)의 새로운 사양이 공개되었습니다. Google Developers Blog의 기사 「Scaling AI Agent Infrastructure with the MCP Stateless updates」에 따르면, 이번 변경의 가장 큰 핵심은 MCP의 코어가 완전히 스테이트리스(Stateless)화되었다는 점입니다.
지금까지 MCP 서버 / 클라이언트 구현은 세션 상태를 서버 측에 유지하는 「스테이트풀(Stateful)」을 전제로 만들어지는 경우가 많았으며, 이것이 클라우드 네이티브(Cloud-native) 환경에서의 스케일링(Scaling)을 어렵게 만들었습니다. 이번 사양 업데이트를 통해 수평 확장(Horizontal Scaling), 서버리스 배포(Serverless Deployment), 표준적인 라운드 로빈(Round-robin) 부하 분산이 가능해져, AI 에이전트 기반을 본업 환경에서 운영할 때의 큰 장벽이 제거됩니다.
📌 영향을 받는 사람
- 자체적으로 MCP 서버 / 클라이언트를 구현하고 있는 개발자
- MCP를 사용한 에이전트 기반을 클라우드 상에서 스케일링(Scale)하고 싶은 분
- Python / TypeScript / Go / C#으로 MCP SDK를 이용하고 있는 프로젝트 담당자
이번 변경은 MCP의 아키텍처(Architecture) 자체를 「스테이트풀(Stateful)」에서 「스테이트리스(Stateless)」로 전환하는 것입니다. 전체적인 모습은 다음과 같습니다.
기존의 스테이트풀 코어에서는 특정 세션을 특정 서버 인스턴스에 고정해야 했기에, 스케일 아웃(Scale-out)이나 서버리스 전개와의 궁합이 좋지 않다는 과제가 있었습니다. 스테이트리스 코어화에 의해 어떤 요청을 어떤 인스턴스가 처리해도 상관없게 되었으며, 일반적인 Web 백엔드와 동일한 스케일링(Scaling) 기법을 그대로 적용할 수 있게 됩니다.
이번 업데이트로 도입된 주요 변경점은 다음 5가지입니다.
| # | 변경점 | 개요 |
|---|---|---|
| 1 | 스테이트리스 코어화 | 세션 상태를 서버 측에 가지지 않는 설계로 변경. 수평 확장(Horizontal Scaling)・서버리스 전개・라운드 로빈 부하 분산 가능 |
| ... |
특히 주목해야 할 점은 **MRTR (Multi Round-Trip Requests)**입니다. 기존에는 커넥션(Connection)을 유지한 채 장시간 태스크(Task)의 완료를 기다리는 구현이 되기 쉬웠으나, MRTR을 통해 「요청을 분할하여 여러 번의 주고받음으로 완결시키는 것」이 표준화되었습니다. 이를 통해 로드 밸런서(Load Balancer)나 서버리스 환경의 타임아웃(Timeout) 제약에 얽매이지 않고, 대화형 에이전트 처리나 장시간 실행 태스크를 구현하기 쉬워집니다.
⚠️ Breaking Change
기존의 스테이트풀을 전제로 구축된 MCP 서버 / 클라이언트 구현은 그대로는 새로운 사양과 호환되지 않습니다. 세션 상태를 서버의 메모리 내에 유지하고 있는 듯한 코드는 이행 작업이 필요합니다.
자체적으로 MCP 서버를 구현하고 있는 경우: 세션 상태 유지 방법을 재검토하고, 스테이트리스 설계(외부 스토어 이용 또는 요청마다 필요한 정보를 명시적으로 주고받는 방식)로 이행해야 합니다.
MCP 클라이언트를 구현하고 있는 경우: 새로운 표준 HTTP 헤더 및 MRTR에 대응한 요청/응답 처리에 대한 추종이 요구됩니다.
서드 파티(Third-party) MCP 서버를 이용하고 있는 경우: 직접적인 구현 변경은 필요 없는 경우가 많지만, 이용 중인 서버가 새로운 사양에 대응하고 있는지, 가동 상황에 변화가 없는지 확인해 두면 안심할 수 있습니다.
💡 Tips
이행은 한 번에 모두 수행할 필요는 없습니다. 우선 Python / TypeScript / Go / C# 중 하나의 beta SDK를 도입하여 개발 환경에서 스테이트리스 동작을 검증한 후, 단계적으로 본업의 로드 밸런싱(Load Balancing) 구성에 적용하는 것이 안전합니다.
스테이트풀 구현과 스테이트리스 구현의 사고방식 차이를 간이 TypeScript 의사 코드(Pseudo code)로 비교합니다 (beta SDK의 실제 API 명칭은 향후 변경될 가능성이 있으므로, 개념적인 예시로 참조해 주세요).
// 세션 상태를 서버의 메모리 내에 유지
const sessions = new Map<string, SessionState>();
server.on("request", (req) => {
...
이러한 구현에서는 동일한 세션의 요청은 반드시 동일한 서버 인스턴스에 도달해야 하며, 단순한 라운드 로빈 부하 분산을 도입하면 상태가 유실되어 버립니다.
server.on("request", (req) => {
// 상태는 요청에 포함된 정보나 외부 스토어로부터 매번 취득
const context = resolveContextFromRequest(req);
...
스테이트리스(Stateless)화로 인해 어떤 인스턴스가 요청을 받더라도 처리를 계속할 수 있으므로, 표준적인 라운드 로빈 (Round Robin) 부하 분산이나 서버리스 (Serverless) 환경(요청마다 인스턴스가 시작·종료되는 환경)에서도 문제없이 동작합니다.
- MCP의 2026-07-28 사양에서 코어 아키텍처가 스테이트풀 (Stateful)에서 스테이트리스 (Stateless)로 전환됨 - 이를 통해 수평 확장 (Horizontal Scaling) · 서버리스 배포 · 라운드 로빈 부하 분산이 가능해짐 - 표준화된 HTTP 헤더를 통한 라우팅, 캐시 제어 메커니즘, **MRTR (장시간 태스크를 위한 다중 라운드 트립, Multi-Round-Trip)**이 새롭게 도입됨 - **Python / TypeScript / Go / C#**용 beta SDK가 제공되며, 기존의 스테이트풀 구현은 마이그레이션 대응이 필요함 - 자체적으로 MCP 서버 / 클라이언트를 구축하고 있는 경우, 조기에 beta SDK를 테스트하고 스테이트리스 설계로의 마이그레이션 계획을 세울 것을 권장합니다.
AI 에이전트 기반을 프로덕션 환경에서 확장(Scale)하고자 하는 팀에게 이번 MCP의 스테이트리스화는 놓칠 수 없는 업데이트입니다. 기존 구현에 미치는 영향 범위를 파악하고 계획적으로 마이그레이션을 진행하십시오.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기