MCP 2026-07-28 스펙 확정 — 내 MCP 서버, 무엇을 고쳐야 하나요

핵심 요약 (TL;DR)

Model Context Protocol의 2026-07-28 스펙이 확정됐습니다. 트랜스포트가 완전 스테이트리스로 바뀌어 일반 로드밸런서나 쿠버네티스 뒤에 MCP 서버를 그대로 둘 수 있게 됐고, 인증은 DCR 대신 CIMD(Client ID Metadata Documents) 체제로 이동하며, 최소 12개월의 폐기 유예 정책이 도입됐습니다. MCP 서버를 만들거나 붙여 쓰는 개발자라면 점검할 항목이 생긴 겁니다.

MCP 서버를 잘 만들어 쓰다가, 사용자가 늘어 인스턴스를 두 대로 늘리는 순간 세션이 꼬여본 적 있으신가요. 지금까지 MCP를 프로덕션에 올릴 때 최대 골칫거리는 세션 상태 관리였습니다. 이번 스펙은 그 문제를 프로토콜 차원에서 지웠습니다.

무엇이 바뀌었나요?

2024년 11월 출시 이후 리눅스재단 산하 Agentic AI Foundation(AAIF) 관리 체제에서 나온 첫 대형 릴리즈입니다. 후보안(RC)이 5월 21일 공개돼 10주 검증을 거쳐 확정됐고, VentureBeat는 "MCP 역사상 최대 업데이트"라고 표현했습니다. 공식 발표 기준 변화는 네 갈래입니다.

1. 트랜스포트 완전 스테이트리스화 — 스티키 라우팅 없이 일반 로드밸런서 뒤에 서버를 배치할 수 있습니다.
2. 인증 개편 — CIMD가 DCR(동적 클라이언트 등록)을 대체하고, iss 파라미터 검증이 의무화돼 mix-up 공격을 차단합니다.
3. 최소 12개월 폐기 정책 — 스펙 변경 시 1년의 유예가 보장됩니다.
4. Tasks 공식 확장 승격 — 장기 실행 작업용 MCP Tasks가 공식 확장이 됐습니다(서버 렌더링 UI인 Apps는 기존부터 확장으로 있던 것입니다).

내 MCP 서버는 뭘 고쳐야 하나요?

체크리스트로 정리하면 이렇습니다.

1단계 — 세션 상태 점검. 서버가 요청 사이에 인메모리 상태를 들고 있는지 확인해보세요. 있다면 요청 단위로 완결되게 바꾸거나 외부 저장소로 빼는 게 신스펙 방향과 맞습니다.

2단계 — 인증 플로우 확인. DCR 기반으로 인증을 구현했다면 CIMD 마이그레이션 대상입니다. iss 파라미터 검증도 의무 사항이 됐으니 인증 코드 경로를 점검해야 합니다.

3단계 — 배포 구조 단순화. 스테이트리스 전환이 끝나면 스티키 세션 설정을 제거할 수 있습니다. 개념적으로는 이런 변화입니다.

# 이전: 세션 유지를 위해 스티키 라우팅 강제
upstream mcp { ip_hash; server mcp-1; server mcp-2; }

# 이후: 일반 라운드로빈으로 충분
upstream mcp { server mcp-1; server mcp-2; }

4단계 — 장기 실행 작업. 오래 걸리는 작업을 자체 폴링으로 처리하고 있었다면, 공식 확장이 된 Tasks로 옮기는 것을 검토해보세요.

FAQ

Q. 기존 서버가 당장 깨지나요?
최소 12개월 폐기 정책이 함께 도입돼 급하게 깨질 일은 없습니다. 다만 인증(DCR→CIMD)은 실제 마이그레이션이 필요한 변화라 미리 계획하는 편이 안전합니다.

Q. Claude Code 같은 클라이언트는 언제 지원하나요?
주요 클라이언트의 신스펙 지원 시점은 아직 확인되지 않았습니다. 사용하는 클라이언트의 공식 문서를 확인하는 게 정확합니다.

Q. 스테이트리스면 대화 맥락은 어디로 가나요?
프로토콜이 트랜스포트 계층의 세션 의존을 없앤 것이지, 애플리케이션이 맥락을 저장하지 못하게 된 게 아닙니다. 맥락은 요청에 실어 보내거나 서버 바깥 저장소에 두면 됩니다.

정리하면, 이번 스펙은 MCP가 실험용 배관에서 하중을 견디는 인프라로 바뀌었다는 선언입니다. 12개월 유예 보장은 "이 위에 사업을 지어도 된다"는 신호이기도 합니다. 오늘 할 일은 둘입니다. 스펙 원문을 읽고, 내 서버의 세션 상태와 인증 경로 두 곳을 점검하는 것. 배관이 바뀔 때 먼저 움직인 집이 물난리를 피하는 법입니다.