MCP 2026-07-28 사양 개정: OAuth 2.1을 통한 완전 스테이트리스(Stateless)화를 정리해 보았다

서론

MCP(Model Context Protocol)의 2026-07-28 사양에서 프로토콜이 완전 스테이트리스(Stateless)화되었다. 이와 함께 OAuth 2.1 준수가 사실상 필수 사항이 되었다. 이 두 가지가 세트로 언급되는 이유를 나름대로 정리해 둔다.

2026년 5월 21일에 릴리스 후보(RC)로 확정되었고, 2026년 7월 28일에 정식 버전으로 공개되었다. 이로써 현재의 정식 사양은 「2025-11-25」 버전에서 「2026-07-28」 버전으로 전환되었다. Tier 1 SDK(TypeScript, Python 등 주요 언어)는 이미 대응을 완료했다. 이하 내용은 이 정식 버전을 기반으로 한다.

1. 애초에 무엇이 바뀌었는가

한마디로 말하면, "서버가 대화의 문맥(세션)을 기억한다"라는 전제가 사라진다.

지금까지의 MCP는 클라이언트(Claude 등)와 서버가 처음에 initialize라는 악수를 하고, Mcp-Session-Id라는 "번호표"를 발급받은 뒤, 이후의 상호작용은 모두 그 번호표를 사용하여 진행하는 구조였다.

새로운 사양에서는 이 악수 자체가 폐지되어, 모든 요청이 단독으로 완결되도록 한다. 프로토콜 버전이나 클라이언트 정보는 매 요청마다 포함되는 _meta라는 필드에 실어서 보낸다.

2. 비유하자면: 같은 호텔에서 체크인 방식이 바뀐 것

Before (세션 기반) = 프런트가 방 번호를 기억하는 방식

기존의 MCP는 프런트가 고객의 방 번호를 기억하고 있는 호텔과 같았다.

• 클라이언트가 프런트에 가서 "체크인하고 싶습니다"라고 initialize 한다.
• 프런트가 "303호실이시네요, 이 카드키를 받으세요"라며 Mcp-Session-Id를 발급한다.
• 이후 엘리베이터에서도 레스토랑에서도 그 카드키를 보여주면 "303호실 고객님이시군요"라며 대응해 준다.

여기서 문제가 되는 점은 "303호실"이라는 정보를 누가 기억하고 있는가 하는 점이다. 프런트 직원(=서버 인스턴스)이 자신의 머릿속(메모리)에 기억하고 있는 경우, 다른 프런트 직원(다른 서버 레플리카)에게 말을 걸면 "누구십니까?"라는 상황이 발생한다.

이것이 이른바 세션 어피니티(Session Affinity, Sticky Session) 문제다. 운영 환경에서 서버를 여러 대로 늘리려 해도, "동일한 고객은 반드시 동일한 직원에게 연결한다"라는 라우팅을 로드 밸런서(Load Balancer)에 강제해야 한다. 이는 운영상 상당히 번거로우며, 다중 서버 구성 시 사고의 온상이 되어 왔다.

After (스테이트리스화) = 체크인 공정 자체가 없어지는 방식

새로운 사양에서는 애초에 "프런트에서 절차를 밟아 방 번호를 할당받는" 공정 자체가 없어진다.

고객은 처음부터 "예약 확인증"(=토큰이나 _meta 정보)을 가지고 있으며, 엘리베이터를 탈 때도, 레스토랑에 들어갈 때도, 방 문을 열 때도 그때마다 확인증을 그 자리에서 보여주고, 그 자리의 직원이나 문이 "통과시켜도 되는지"를 매번 판단한다.

아무도 "303호실 고객"이라는 정보를 기억할 필요가 없다. 확인증만 보여준다면 어떤 직원이 대응하더라도, 어떤 지점(=어떤 서버 인스턴스)이라도 동일하게 취급받을 수 있다. 따라서 호텔이 지점을 아무리 늘려도(=서버를 아무리 늘려도) 운영이 파탄 나지 않는다.

스테이트리스(Stateless) 코어는 세션 어피니티를 불필요하게 만들고, 수평 확장(Horizontal Scaling)과 로드 밸런싱(Load Balancing)을 단순화한다. 바로 이 "프런트 불필요화"의 혜택이다.

3. 애초에 왜 프런트 기억 방식(스테이트풀)이었는가

"그럼 처음부터 체크인 없는 방식으로 만들면 좋았을 텐데"라고 생각되어, 이 점도 조사하여 정리해 보았다.

MCP는 에디터와 언어 서버가 대화하는 LSP(Language Server Protocol)라는 메커니즘에서 착안하여 만들어졌다. LSP는 "에디터를 실행하는 동안 계속 백그라운드에서 하나의 언어 서버와 연결을 유지한다"라는 설계다. MCP가 등장했을 당시에도 로컬 PC 상에서 하나의 클라이언트와 하나의 도구를 1대 1로 연결하는 용도가 메인이었다.

비유하자면, 처음에는 '단골손님이 한 명뿐인 작은 민박집'을 상정하여 설계되었다는 뜻이다. 주인(Owner)이 유일한 손님의 얼굴과 취향을 모두 기억하고 있기 때문에, 매번 체크인할 때 자기소개를 할 필요가 없다. 이는 그 자체로 합리적이다.

• 매번 "이 숙소에서 무엇을 할 수 있는지"를 다시 묻는 것은 낭비이므로, 처음에 한 번만 initialize로 서로 자기소개를 하면 효율적임
• 체류 중의 문맥(대화의 연속, 진행 중인 처리)을 자연스럽게 유지할 수 있음
• 민박집 한 곳뿐이라는 전제라면, 지점을 늘리는 것(서버를 스케일링(Scaling)하는 것)에 대한 걱정 자체가 애초에 없음

즉, "1대 1 민박집"을 전제로 한 설계를 그대로 "전 세계에 수백 개의 매장을 전개하는 대형 호텔 체인"(다수의 사용자가 동시에 동일한 서버군에 접속하는 세계)에 그대로 가져온 것이 이번 문제의 근본 원인이다. 한 명의 주인이 단골손님의 얼굴을 기억할 수 있는 것은 민박집 한 곳이기 때문에 가능한 이야기이며, 지점이 100개 있는 호텔 체인에서 같은 일을 하려고 하면 어느 지점의 어떤 직원에게 물어도 "처음 뵙겠습니다" 상태가 될 수밖에 없다. 개발 팀 스스로도 "에이전트형 앱은 스테이트풀(Stateful)해야 하지만, 프로토콜 자체가 그럴 필요는 없다"라고 방침을 전환하며 이번 개정에 이르게 되었다.

4. 왜 OAuth 2.1이 세트로 언급되는가

이 부분이 이번에 가장 중요한 포인트다. "프론트엔드가 손님을 기억하지 못한다"는 것은, 매번 상호작용할 때마다 "당신은 누구이며, 무엇을 할 수 있는 권한이 있는가"를 그 자리에서 증명받아야 한다는 의미다.

MCP 2026-07-28 사양에서는 스테이트풀(Stateful)한 초기화나 서버 주도형 프롬프트와 같은 구버전의 프로토콜 레벨 보안 리스크를 제거하고, OAuth 2.1을 필수화함으로써 인증 보안을 강화했다.

이것도 비유하자면, "예약 확인증을 누가 발행하는가"의 문제다.

• MCP 서버 = 호텔 그 자체 (OAuth 2.1의 Resource Server): 예약 확인증(토큰)을 확인하기만 할 뿐, 확인증을 발행할 권한은 없음
• Authorization Server (인가 서버) = 예약 사이트: Auth0나 Keycloak, 사내 IdP 등 별도의 서비스가 담당. MCP 서버는 스스로 예약 확인증을 발행해서는 안 되며, 어디까지나 확인증을 검증할 뿐임

나 자신도 무심코 "인증 기능도 MCP 서버에 전부 만들어 넣어야지" 하는 방향으로 생각하기 쉽지만, 이는 사양 위반이다. 인가(Authorization) 구현은 예약 사이트(외부 IdP)에 맡기고, 호텔 측은 확인증 검증에 전념한다는 역할 분리가 철저히 이루어져 있다.

5. 구체적으로 무엇이 엄격해졌는가 (6가지 SEP)

"왜 OAuth가 필요한가"를 파악한 상태에서, 이번에 무엇이 새롭게 요구되는지 정리한다.

SEP-2468에서는 혼동 공격(Mix-up attack)을 방지하기 위해, 인가 응답의 iss 파라미터를 RFC 9207에 기반하여 검증하는 것이 클라이언트에 의무화된다.

이것도 비유하자면, 여러 예약 사이트를 나누어 사용하고 있는 상황(=여러 인가 서버를 사용하는 환경)에서 "어느 예약 사이트를 경유한 확인증인가"를 반드시 확인하는 이미지다. 악의적인 제삼자가 가짜 예약 사이트의 확인증을 진짜 호텔에 가져오는 식의 "사칭 예약 사이트" 공격을 방지하기 위한 것이다.

그 외 주요 변경 사항은 다음과 같다.

또한, 토큰의 오디언스 (Audience, 대상) 검증, 수명이 짧은 액세스 토큰 (Access Token) 발행, 클라이언트의 베어러 토큰 (Bearer Token)을 상류 서비스 (Upstream Service)로 전달하지 않는 것, PKCE는 S256 방식만 사용할 것과 같은 기본 원칙 자체는 이번 개정에서 새롭게 추가된 것이 아니라, 기존의 MCP 인가 사양 (RFC 8707의 Resource Indicators 등)을 기반으로 하고 있다.

6. 서버 구현자로서 의식해야 할 3가지 포인트

서버 측에서 중요한 것은, 안정적인 authServerUrls를 가진 정확한 RFC 9728의 Protected Resource Metadata를 공개하는 것, issuer를 안정시켜 두는 것 (issuer가 바뀌면 모든 클라이언트의 재등록이 발생하기 때문), 그리고 자신의 인가 서버가 발행한 것이라면 무엇이든 받아들이는 것이 아니라, 오디언스 (Audience, 대상)가 연결된 토큰을 검증하는 것이다.

이를 호텔 비유로 되돌려 보면:

• "이 호텔 (서버)은 여기입니다"라는 안내판을 정확하게 내놓기 (Protected Resource Metadata)
• 제휴하는 예약 사이트 (issuer)를 마음대로 바꾸지 않기 (바꾸면 모든 고객이 예약을 다시 해야 함)
• "다른 예약 사이트를 경유한 확인증"을 조건 없이 자신의 호텔에서 받아들이지 않기 (오디언스 검증)

7. 요약

• "서버는 아무것도 기억하지 않는다"가 대전제가 된다. 세션 ID를 통한 상태 관리 (State Management)를 작성하려 한다면, 그것은 이미 2026-07-28 사양에 맞지 않는다.
• 인증·인가를 직접 만들지 않는다. MCP 서버는 "호텔"이지 "예약 사이트"가 아니다. 토큰 발행은 OAuth 2.1을 준수하는 외부 Authorization Server에 맡긴다.
• 매 요청마다 검증하는 것이 기본 동작이 된다. 스테이트리스 (Stateless)의 이면으로서, iss 검증·오디언스 검증·수명이 짧은 토큰과 같이 "의심하고 접근하는" 설계가 기본값이 된다.

참고: 본 기사는 MCP 2026-07-28 사양의 정식 공개 (2026년 7월 28일, RC 락은 같은 해 5월 21일)를 바탕으로 정리한 것이다. 자세한 내용은 MCP 공식 블로그의 정식 릴리스 기사를 참조할 것.

Discussion