MCP 2026-07-28 스펙 업데이트: 무상태 프로토콜 전환과 마이그레이션 체크리스트

MCP 서버를 운영하다 보면 클라이언트 연결이 끊기거나 서버 인스턴스를 여러 대로 늘려야 할 때 세션 상태를 어떻게 다뤄야 할지 애매한 경우가 많았다. 연결을 계속 열어둔 채로 세션 식별자를 주고받는 기존 방식은 구현은 단순하지만, 로드밸런서 뒤에 여러 서버를 두고 트래픽을 분산하려는 순간 세션을 어느 서버가 갖고 있는지 추적해야 하는 문제로 이어졌다. MCP의 2026-07-28 스펙은 이 구조 자체를 바꾸면서 등장했고, 기존 서버를 운영 중이라면 마이그레이션이 필요한 부분이 적지 않다.

무엇이 달라졌나

무상태 프로토콜로의 전환

가장 큰 변화는 초기 핸드셰이크 절차와 세션 식별 헤더가 사라졌다는 점이다. 이제 각 요청은 프로토콜 버전과 클라이언트 정보를 스스로 포함하는 독립적인 단위로 취급된다. 서버가 이전 요청의 상태를 기억하고 있을 필요가 없어지므로, 여러 서버 인스턴스를 단순한 로드밸런서 뒤에 두고 트래픽을 자유롭게 분산할 수 있게 됐다.

다중 왕복 요청과 헤더 기반 라우팅

도구 실행 중 사용자 확인이나 추가 입력이 필요한 경우, 서버는 입력이 더 필요하다는 응답을 돌려주고 클라이언트가 답변을 담아 다시 요청하는 방식으로 상호작용이 이뤄진다. 연결을 계속 열어두지 않아도 여러 차례 주고받는 대화형 흐름을 구현할 수 있게 된 셈이다. 여기에 더해 요청 헤더에 메서드와 도구 이름을 함께 담는 방식이 도입되면서, 게이트웨이나 방화벽 같은 중간 장비가 본문을 열어보지 않고도 헤더만으로 라우팅이나 속도 제한을 적용할 수 있게 됐다.

캐싱과 인증 강화

도구·프롬프트·리소스 목록을 조회하는 응답에는 캐시 유효 시간과 범위 정보가 함께 담겨, 클라이언트가 불필요하게 같은 목록을 반복 조회하지 않도록 돕는다. 인증 쪽에서는 발급자 정보를 표준에 맞게 검증하도록 강화됐고, 데스크톱이나 CLI 애플리케이션을 위한 로컬 리다이렉트 방식도 함께 지원된다. 기존의 동적 클라이언트 등록 방식은 점차 클라이언트 메타데이터 문서 기반 방식으로 옮겨가는 흐름이다.

기존 서버를 옮길 때 확인할 것

세션 식별자에 의존하는 코드부터 찾기

가장 먼저 할 일은 코드베이스에서 세션 식별자를 저장하거나 조회하는 부분을 찾아내는 것이다. 무상태 구조에서는 이런 코드가 더 이상 필요 없어지거나, 요청마다 포함되는 클라이언트 정보로 대체해야 한다. 세션에 의존해 상태를 유지하던 도구가 있다면, 명시적인 핸들 값을 응답에 담아 클라이언트가 다음 요청에 함께 실어 보내도록 구조를 바꾸는 편이 안전하다.

SDK 버전과 호환성 기간 확인하기

TypeScript, Python, Go, C# 등 주요 SDK는 새 스펙을 곧바로 지원하지만, 프로젝트에서 쓰고 있는 SDK 버전이 실제로 새 방식을 지원하는지는 별도로 확인해야 한다. 기존 기능은 상당 기간 하위 호환을 유지하는 것으로 알려져 있어 당장 전면 교체가 강제되지는 않지만, 신규 기능을 활용하려면 결국 새 방식으로 옮겨가야 한다.

인증 흐름 재점검하기

OAuth 기반 인증을 쓰고 있다면 발급자 검증 로직이 새 요구사항에 맞게 동작하는지 별도로 테스트해야 한다. 특히 여러 인증 서버를 두고 운영하는 경우, 자격 증명이 의도한 발급 기관에만 묶여 있는지 확인하지 않으면 마이그레이션 이후 인증 오류를 뒤늦게 발견하게 될 수 있다.

주의할 점

스펙 문서만 보고 바로 전체 인프라를 교체하려 하기보다는, 트래픽이 적은 서버 하나에 먼저 적용해보고 문제가 없는지 확인하는 편이 안전하다. 특히 세션 기반으로 짜여 있던 내부 로직이 많을수록 예상보다 손볼 코드가 많을 수 있으므로, 마이그레이션 범위를 과소평가하지 않는 것이 중요하다. 또한 헤더 기반 라우팅을 도입한 게이트웨이나 프록시가 있다면, 기존 본문 기반 라우팅 규칙과 충돌하지 않는지 별도로 점검해야 한다.

정리

이번 스펙 변경은 MCP 서버를 더 단순하고 확장하기 쉬운 구조로 바꾸는 방향이지만, 그만큼 세션에 의존하던 기존 코드는 손을 봐야 한다. 코드베이스에서 세션 관련 로직을 먼저 찾아내고, SDK 호환성과 인증 흐름을 단계적으로 검증한 뒤 트래픽이 적은 서버부터 순차적으로 옮기는 방식이 현실적인 접근이 된다.