MCP (Model Context Protocol)는 AI 에이전트가 외부 도구나 데이터 소스에 액세스하기 위한 표준 프로토콜입니다. REST API에서의 HTTP와 같은 위치에서, 모델이나 프레임워크가 달라도 동일한 형식으로 도구를 호출할 수 있도록 하는 메커니즘으로서 지난 몇 년간 급속히 보급되었습니다.

그 MCP의 사양이 2026년 7월 28일에 크게 개정되었습니다. 이는 공개 이후 최대 규모의 변경이며, 실제로 접해보면 설계 사상이 상당히 바뀌었음을 알 수 있습니다. 이 기사에서는 무엇이 어떻게 바뀌었는지 정리합니다.

지금까지의 MCP는 클라이언트와 서버 사이에서 initialize 핸드셰이크 (Handshake)를 수행하고, Mcp-Session-Id라는 세션 ID를 발행하여 해당 세션에 묶인 형태로 통신했습니다. 로드 밸런서 (Load Balancer) 뒤에 여러 서버 인스턴스를 두는 경우, 동일한 세션의 요청은 동일한 인스턴스에 도달하도록 '세션 어피니티 (Session Affinity)'를 유지해야 했습니다.

새로운 사양에서는 이 핸드셰이크와 세션 ID가 프로토콜의 코어에서 완전히 삭제되었습니다. 어떤 MCP 요청이라도 어떤 서버 인스턴스에 도달해도 처리할 수 있도록 되어 있습니다. 구체적으로는:

• 클라이언트는 프로토콜 버전이나 대응 기능을 _meta 필드를 통해 전달
• 서버는 server/discover 엔드포인트 (Endpoint)를 구현
• 요청에는 Mcp-Method와 Mcp-Name 헤더가 붙어, 로드 밸런서는 바디 (Body)를 보지 않고도 라우팅 가능

이를 통해 MCP 서버를 수평 확장 (Horizontal Scale)할 때 세션 어피니티를 고려할 필요가 없어집니다. 단순히 여러 인스턴스를 나열하여 라운드 로빈 (Round Robin)하는 것만으로 동작한다는 설계입니다.

한 가지 주의할 점은, '프로토콜이 스테이트리스 (Stateless)가 되었다'는 것과 '애플리케이션이 스테이트리스여야 한다'는 것은 별개의 문제입니다. 만약 서버 측에서 호출을 가로질러 상태를 유지하고 싶다면, 명시적인 핸들 (Handle, ID)을 발행하고 이를 모델이 일반적인 인자 (Argument)로서 다음 호출에 전달하는 방식으로 직접 관리해야 합니다. 프로토콜은 더 이상 이를 관리해주지 않습니다.

이번 개정에서는 인가 (Authorization) 관련 부분도 크게 손질되었습니다. OAuth 2.0 / OpenID Connect의 실제 운용 실태에 맞춰 사양을 정합시키기 위한 6개의 SEP (Spec Enhancement Proposal)가 도입되었습니다.

대표적인 예로, 클라이언트가 iss 파라미터를 RFC 9207에 따라 검증하게 되었습니다. 이는 MCP의 '1클라이언트 · 다수 서버' 구성 특유의 이른바 믹스업 공격 (Mix-up Attack, 어떤 서버의 응답인지 혼동하게 만드는 공격)을 방지하기 위한 것입니다.

다만 실제로 접하며 느낀 점은, 이 6개의 SEP는 모두 **로그인 시 (핸드셰이크 시)**의 이야기라는 점입니다. 어떤 토큰을 누구에게 발행할 것인가 하는 부분은 엄격해진 반면, '개별 도구 호출마다 이 역할(Role)이 이 작업을 수행해도 되는가'를 서버 측에서 체크하는 메커니즘은 사양으로서 정의되어 있지 않습니다. 스텝업 동의 (Step-up Consent, 추가 동의 확인)는 로그인 시 무엇을 승인할지를 결정하는 것이지, 1시간 후 500번째 도구 호출에서 무슨 일이 일어나고 있는지는 관여하지 않는다는 것이 현상황입니다.

이 격차에 대해서는 실제로 손을 움직여 MCP 서버를 만들어 본 이야기를 다음 이후의 기사에서 쓸 예정입니다.

또 다른 변경점으로, list나 read 계열의 응답에 ttlMs (유효 기간)와 cacheScope (캐시 공유 범위)가 부여되도록 되었습니다. HTTP의 Cache-Control과 유사한 발상으로, 클라이언트 측은 '이 응답을 앞으로 몇 밀리초 동안 재사용해도 되는가', '다른 사용자와 공유해도 되는 캐시인가'를 명시적으로 판단할 수 있습니다.

지금까지 캐시 전략은 각 구현이 독자적으로 생각해야 했으나, 프로토콜 레벨에서 힌트가 제공되게 된 것은 실용상 고마운 변경입니다.

Python SDK는 이미 v2 베타 (mcp==2.0.0b1, pip install --pre 필요)가 공개되어 있으며, 안정판은 7월 27일에 출시될 예정이었습니다 (기사 집필 시점에는 이미 출시되었을 것입니다). 다만 베타 버전이라 문서가 아직 상당히 부족하여, 실제로 구동하면서 help()나 dir()을...

API를 확인해야 하는 상황이 빈번했습니다.

클라이언트 측의 대응도 제각각입니다. 제가 직접 사용해 본 범위 내에서는 Pydantic AI 등 몇몇 프레임워크가 아직 구버전(mcp 1.x)에 의존하고 있어, 새로운 사양에 대한 추종은 이제부터 시작이라는 상황이었습니다. 구현 방식에 따라 과도기에 있는 프로토콜을 다루는 것은 문서를 읽는 것보다 직접 손을 움직여 확인해야 하는 상황이 많아 꽤 고된 작업이지만, 그만큼 배우는 점도 많습니다.

• 세션/핸드셰이크 (Session/Handshake)가 프로토콜의 핵심에서 삭제되어, 진정한 스테이트리스 (Stateless) 서버를 구축할 수 있게 됨
• 인가 (Authorization)는 로그인 시의 하드닝 (Hardening)이 중심이며, 호출 단위의 인가는 사양의 스코프 (Scope) 외부에 있음
• 캐시 힌트 (ttlMs / cacheScope)가 프로토콜 레벨에서 제공되게 됨
• SDK는 아직 베타 버전이며, 문서보다 구현부를 읽어야 하는 상황이 많음

다음 회차에서는 이 새로운 사양 위에 '호출 단위의 가드레일 (Guardrails)'을 직접 어떻게 구축했는지, 실제로 만든 프로젝트에 대한 이야기를 쓰겠습니다.

• 사양 변경점 (Changelog): https://modelcontextprotocol.io/specification/2026-07-28/changelog
• 릴리스 공식 공지: https://blog.modelcontextprotocol.io/posts/2026-07-28/
• Release Candidate 해설 (6가지 SEP의 배경): https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
• GitHub 리포지토리: https://github.com/modelcontextprotocol/modelcontextprotocol