지난 7월 28일, MCP(Model Context Protocol) 운영진이 공식 블로그와 스펙 체인지로그를 통해 새 버전(2026-07-28)을 확정 발표했습니다. 헤드라인은 하나입니다. MCP가 처음 등장한 이후 유지해온 “세션” 개념 자체가 프로토콜 레벨에서 사라졌다는 것입니다.
구체적으로는 Streamable HTTP 전송에서 Mcp-Session-Id 헤더가 완전히 제거됐고, 연결을 맺을 때 주고받던 initialize/notifications/initialized 핸드셰이크도 함께 폐기됐습니다. 해외 IT 매체 더레지스터(The Register)는 지난 7월 23일 기사에서 이번 개정을 “MCP가 상태 저장(stateful) 방식이던 과거와 결별할 준비를 하고 있다”고 표현하며 이 변화의 무게를 짚었습니다.
배경: 왜 지금까지 세션 방식이 발목을 잡았나
MCP는 원래 개인 컴퓨터에서 AI 모델이 로컬 도구 하나를 붙여 쓰는 데모 수준의 용도로 출발했습니다. 이런 환경에서는 연결 하나가 세션 하나를 유지하는 방식이 전혀 문제가 되지 않았습니다.
하지만 MCP가 클라우드에 배포되는 다중 클라이언트 엔터프라이즈 서버로 확장되면서 사정이 달라졌습니다. 세션 아이디를 발급한 서버 인스턴스가 이후 요청도 계속 처리해야 했기 때문에, 로드밸런서에는 스티키 세션(sticky session) 설정이 필수가 됐습니다. 여러 인스턴스가 세션 상태를 함께 참조하려면 예를 들어 Redis 같은 별도의 공유 세션 스토어까지 구축해야 하는 경우도 많았습니다.
이 구조는 쿠버네티스 기반의 수평 확장·서버리스 배포 같은 클라우드 네이티브 운영 방식과 정면으로 부딪혔습니다. 스펙 체인지로그는 이 문제의 해법으로 세션 자체를 없애고, 요청마다 필요한 정보(프로토콜 버전, 클라이언트 기능)를 _meta 필드에 담아 매번 독립적으로 보내는 방식을 택했습니다. 서버가 통신 상대를 미리 파악할 수 있도록 지원 버전과 기능을 알리는 server/discover RPC도 새로 추가됐습니다.
왜 중요한가: 로드밸런서와 폐기 예정 기능이 뜻하는 것
가장 직접적인 실무 효과는 인프라 단순화입니다. 공식 블로그는 이번 변경으로 “어떤 요청이든 공유 스토리지 없이 평범한 라운드로빈 로드밸런서 뒤의 어떤 서버 인스턴스로도 갈 수 있게 됐다”고 설명합니다. 스티키 라우팅과 공유 세션 스토어라는, 그동안 사실상 MCP 운영 비용으로 여겨지던 두 요소가 프로토콜 레벨에서는 더 이상 필요 없어진 셈입니다.
라우팅도 함께 개선됐습니다. 이번 개정으로 Mcp-Method·Mcp-Name 헤더가 모든 요청에 필수로 실리게 됐습니다. 게이트웨이는 이제 JSON 본문을 열어 파싱하지 않고도 헤더만 보고 요청을 라우팅·과금·인가할 수 있습니다.
목록형 응답의 캐싱 규칙도 새로 생겼습니다. tools/list·prompts/list·resources/list·resources/read 응답에 ttlMs(캐시 유효시간)와 cacheScope(공개/비공개 캐시 여부) 필드가 추가됐습니다. 덕분에 클라이언트나 중간 게이트웨이가 도구 목록 같은 결과를 매번 새로 요청하지 않고 캐싱할 근거를 갖게 됐습니다.
인증 쪽도 더 엄격해졌습니다. 인가 서버는 RFC 9207에 따라 응답에 발급자(iss) 값을 포함해야 하고, 클라이언트는 인가 코드를 교환하기 전에 이 값을 반드시 검증해야 합니다. 여기에 더해 클라이언트 자격 증명은 발급한 인가 서버에만 묶이도록 규정이 명확해져, 한 서버에서 받은 인증 정보를 다른 인가 서버에 재사용하는 경로가 원천적으로 막혔습니다.
폐기(deprecated) 예정으로 분류된 항목도 눈여겨볼 만합니다. 클라이언트 등록 방식이던 DCR(Dynamic Client Registration)은 CIMD(Client ID Metadata Documents)로 대체되는 수순을 밟게 됐고, Roots·Sampling·Logging 세 기능도 함께 폐기 목록에 올랐습니다. 다만 새로 채택된 기능 수명주기 정책에 따라 최소 12개월의 폐기 유예 기간이 보장되므로, 지금 당장 동작을 멈추는 기능은 하나도 없습니다.
대신 스펙 체인지로그는 대체 경로도 함께 제시합니다. Roots 대신 도구 매개변수나 리소스 URI로 디렉터리·파일을 전달하고, Sampling 대신 LLM 제공사 API에 직접 연동하며, Logging 대신 표준에러 출력이나 오픈텔레메트리(OpenTelemetry)를 쓰라는 식입니다. 즉 “지금 당장 고쳐야 한다”가 아니라 “새로 만드는 서버라면 이 방향으로 설계하라”는 신호에 가깝습니다.
MCP와 A2A, 헷갈리기 쉬운 두 표준의 차이
MCP 얘기가 나오면 자주 같이 언급되는 게 A2A(Agent-to-Agent) 프로토콜입니다. 어제 이 블로그에서 다룬 멀티 에이전트 오케스트레이션 글에서 소개했듯, A2A는 서로 다른 플랫폼에서 만든 에이전트끼리 대화하는 방법을 표준화합니다.
반면 MCP는 에이전트 하나가 도구·데이터 소스에 연결하는 방법을 표준화하는 프로토콜입니다. 쉽게 정리하면 MCP는 “에이전트와 도구 사이의 규격”, A2A는 “에이전트와 에이전트 사이의 규격”으로, 둘은 경쟁 관계가 아니라 같은 아키텍처 안에서 각자 다른 층을 맡는 보완 관계에 가깝습니다.
전망과 실무 시사점: 지금 MCP 서버를 만들거나 쓰고 있다면
공식 블로그는 “세션 식별자에 의존해온 개발자에게는 어느 정도 마이그레이션 비용이 발생할 것”이라고 솔직하게 인정합니다. 서버가 요청 사이의 상태를 계속 유지해야 하는 경우, 이제는 프로토콜이 대신 관리해주던 세션 대신 개발자가 직접 발급한 핸들(예: 장바구니 ID)을 도구 인자로 주고받는 방식으로 바꿔야 합니다.
다행히 SDK 쪽 준비는 이미 끝나 있습니다. TypeScript·Python·Go·C# 4개 Tier 1 SDK가 오늘부터 2026-07-28 스펙을 지원하고, Rust SDK도 베타로 뒤따르고 있어 대부분의 개발 환경에서 별도 구현 없이 업그레이드가 가능합니다. Anthropic도 자사 블로그에서 클로드 커넥터 디렉터리에 등록된 950개 이상의 MCP 서버에 걸쳐 이 stateless 코어를 순차 반영해 배포 속도와 확장성을 끌어올리겠다고 밝혔습니다.
일반 사용자 입장에서 당장 뭔가 바뀌는 건 아닙니다. 앞서 소개했던 챗GPT 에이전트 모드나 클로드 Agent Skills, 제미나이 에이전트처럼 이미 MCP 서버에 연결해 외부 도구를 쓰는 기능을 활용 중이라면, 이번 개정이 뒷단에서 그 연결을 더 가볍고 안정적으로 만들어주는 변화라고 이해하면 됩니다. 지금 쓰고 있는 MCP 커넥터가 있다면 별도로 설정을 바꾸거나 다시 연결할 필요 없이 자동으로 반영되니, 이 부분은 신경 쓰지 않아도 됩니다.
반면 MCP 서버를 직접 운영하거나 만들 계획이 있는 개발자라면 얘기가 다릅니다. 세션 의존 코드가 있는지부터 점검하고, 12개월의 유예 기간 안에 Roots·Sampling·Logging·DCR을 대체할 경로를 미리 검토해두는 편이 안전합니다.
핵심 요약
- MCP가 2026-07-28 스펙에서
Mcp-Session-Id헤더와 초기화 핸드셰이크를 완전히 제거해 프로토콜 레벨에서 stateless로 전환됐고, 어떤 요청이든 공유 스토리지 없이 평범한 라운드로빈 로드밸런서 뒤에서 처리할 수 있게 됐습니다. - 헤더 기반 라우팅(
Mcp-Method/Mcp-Name), 목록 결과 캐싱(ttlMs/cacheScope), RFC 9207 기반 인증 강화가 함께 도입됐고, DCR·Roots·Sampling·Logging은 최소 12개월 유예 기간을 두고 폐기 절차에 들어갔습니다. - TypeScript·Python·Go·C# SDK가 이미 새 스펙을 지원하며, MCP(도구 연결 표준)와 어제 다룬 A2A(에이전트 간 통신 표준)는 서로 대체재가 아니라 같은 에이전트 아키텍처의 다른 층을 맡는 보완 관계입니다.
AI 리서치와 검수 과정을 거쳐 콘텐츠를 제작합니다. 오류나 개선할 점을 발견하시면 연락처로 알려주세요.