MCP 새 스펙, 전송 계층이 무상태(stateless)로 바뀝니다 — 서버리스 배포가 쉬워져요

AI 모델과 외부 도구를 연결하는 표준 프로토콜인 MCP(Model Context Protocol)의 새 스펙(2026-07-28 버전)이 공개됐는데요, 이번 개정의 핵심은 전송 계층이 무상태(stateless)로 바뀐다는 거예요. 겉보기엔 지루한 프로토콜 얘기 같지만, MCP 서버를 만들어봤거나 배포하다가 "이거 왜 이렇게 서버리스에 못 올리지?" 하고 고생해본 분이라면 무릎을 칠 소식이거든요.

MCP가 뭐였는지부터

MCP는 앤트로픽이 2024년 말에 공개한 오픈 프로토콜이에요. 이게 뭐냐면, AI 모델이 데이터베이스, 파일 시스템, 사내 API 같은 외부 도구를 쓸 수 있게 연결해주는 표준 규격이에요. 흔히 'AI용 USB-C'라고 비유하는데요, 도구마다 제각각 연동 코드를 짜는 대신 MCP 서버 하나만 만들면 클로드든 챗GPT든 MCP를 지원하는 어떤 클라이언트에서도 꽂아 쓸 수 있게 되죠. 이후 OpenAI와 구글까지 채택하면서 사실상의 업계 표준이 됐어요.

뭐가 문제였냐면: 상태를 들고 있는 서버

초기 MCP는 로컬에서 stdio(표준 입출력)로 통신하는 게 기본이었고, 원격 연결에는 HTTP와 SSE(서버가 클라이언트로 데이터를 계속 흘려보내는 스트리밍 방식이에요)를 썼어요. 2025년 3월 스펙에서 Streamable HTTP로 정리되긴 했지만, 여전히 세션 개념이 남아 있었거든요. 클라이언트가 접속하면 서버가 세션 ID를 발급하고, 이후 요청들은 그 세션에 묶여서 처리되는 구조였죠.

이게 뭐가 문제냐면, 전화 통화와 문자 메시지의 차이로 생각하면 쉬워요. 상태 유지(stateful) 방식은 전화 통화예요. 연결이 살아 있는 동안 서로의 맥락을 기억하니까 편하지만, 통화 상대가 계속 붙어 있어야 하죠. 무상태(stateless) 방식은 문자예요. 매번 필요한 맥락을 담아 보내야 하지만, 누가 받아도 처리할 수 있어요. 서버가 세션 상태를 메모리에 들고 있으면 AWS Lambda나 Cloud Run처럼 요청마다 인스턴스가 생겼다 사라지는 서버리스 환경에서는 세션이 증발해버리고, 로드밸런서 뒤에 서버를 여러 대 두려면 같은 클라이언트를 같은 서버로만 보내는 스티키 세션 같은 우회책이 필요했어요. 스케일아웃이 프로토콜 차원에서 발목 잡혔던 거예요.

새 스펙: 각 요청이 자기완결적으로

이번 개정으로 전송 계층은 각 요청이 스스로 완결되는 방향으로 바뀌어요. 어떤 인스턴스가 받아도 처리할 수 있으니 평범한 HTTP 서비스처럼 배포하고, 로드밸런서로 트래픽을 나누고, 요청이 없을 땐 0대로 줄였다가 필요할 때 늘리면 되는 거죠. 사실 웹이 REST로 거대해질 수 있었던 것도 정확히 이 무상태 원칙 덕분이었잖아요. MCP가 그 검증된 길을 따라가는 셈이에요. 물론 공짜는 아니에요. 서버가 먼저 클라이언트에게 말을 거는 기능들, 그러니까 진행 상황 알림이나 서버 주도 요청 같은 양방향 패턴은 무상태 세계에 맞게 다시 설계돼야 하고, 기존 스펙 기반으로 만든 서버들은 마이그레이션을 고민해야 해요.

한국 개발자에게 주는 시사점

이미 MCP 서버를 운영 중인 팀이라면 각 언어 SDK의 업데이트와 마이그레이션 가이드를 챙겨보셔야 해요. 반대로 이제 막 만들기 시작하는 분들에게는 희소식인데요, 무상태 전제로 설계하면 Lambda나 Cloud Functions 같은 서버리스에 올려서 쓴 만큼만 과금되는 초저비용 운영이 가능해지거든요. 사내 도구를 MCP로 노출하는 프로젝트의 인프라 허들이 확 낮아지는 거예요. 상태가 꼭 필요한 경우엔 Redis나 DB로 외부화하면 되고요. 네, 우리가 일반 웹 백엔드에서 늘 하던 그대로예요. 결국 MCP 서버 개발이 '특수한 무언가'에서 '평범한 웹 서비스 만들기'에 가까워진다는 게 이번 변화의 본질이에요.