MCP 2026-07-28 스펙 개정, 외주 개발사가 지금 알아야 할 것들

한줄 요약

MCP 스펙이 세션 기반에서 스테이트리스 구조로 전환됐다. 외주 개발 단계별 대응 포인트를 정리한다.

본문

MCP(Model Context Protocol)의 대규모 스펙 개정이 2026년 7월 28일자로 확정됐다. 이번 개정은 프로토콜 공개 이후 가장 큰 변화로, 핵심 구조 자체를 바꾸는 내용이 다수 포함됐다. AI 에이전트 기반 기능을 앱이나 서비스에 붙이는 외주 개발 프로젝트라면, 이번 변화가 설계와 운영 방식에 직접 영향을 준다.

왜 세션 구조가 사라졌는가

기존 MCP는 클라이언트와 서버가 첫 연결 시 핸드셰이크를 거쳐 세션 ID를 발급하고, 이후 모든 요청에 그 ID를 포함시키는 방식이었다. 로컬 단일 서버 환경에서는 문제가 없지만, 서버를 여러 대로 분산 운영하는 순간 골치가 커진다.

세션이 특정 서버 인스턴스에 묶이기 때문에, 일반적인 라운드로빈 로드밸런싱이 작동하지 않는다. 같은 클라이언트의 요청은 반드시 세션을 들고 있는 그 인스턴스로만 보내야 한다. 그 인스턴스가 죽으면 세션도 함께 사라진다. 게다가 세션 생성과 관리, 만료 처리까지 서버 개발자가 직접 구현해야 했다. 실제 사용 사례의 대부분이 이 기능을 쓰지도 않았다는 게 개정의 가장 큰 근거였다.

신 스펙은 요청 하나에 처리에 필요한 모든 정보를 담는 방식으로 전환했다. 어떤 서버 인스턴스가 받아도 독립적으로 처리 가능하다. 서버가 제공하는 기능이 궁금하면 별도 요청으로 물어보는 구조로 바뀌었고, 이 요청은 모든 서버가 반드시 지원해야 한다.

외주 개발 프로젝트에서 설계가 바뀌는 부분

세션이 사라졌다는 것이 '상태를 저장할 수 없다'는 뜻은 아니다. 장바구니처럼 여러 호출에 걸쳐 상태가 필요한 기능은, 서버가 핸들(식별자)을 반환하고 이후 요청마다 그 핸들을 인자로 받는 방식으로 구현한다. 이전에는 세션 계층 안에 숨어 있던 상태가 이제는 명시적인 데이터로 오고 가게 된다.

도구 실행 중 사용자 입력이 필요한 상황도 달라진다. 기존에는 서버가 직접 클라이언트를 호출할 수 있었다. 이제는 서버가 "추가 입력이 필요하다"는 중간 응답을 보내고, 클라이언트가 입력을 채워 원래 요청을 다시 보내는 방식으로 바뀐다. 이 흐름에서 서버가 내보내는 진행 상태 값은 클라이언트를 경유해서 돌아오기 때문에, 외부에서 온 입력처럼 검증하는 로직이 필요하다. SDK가 관련 도구를 제공한다.

오래 걸리는 작업은 Tasks 확장이 담당하게 됐다. 서버가 작업 핸들을 반환하고, 클라이언트가 주기적으로 상태를 확인하며, 연결이 끊겼다 돌아와도 결과를 받아갈 수 있다. 스트림이 끊겼을 때 이어받는 기능이 이번 개정에서 제거됐기 때문에, 장기 작업이 있는 서버는 이 확장으로 대체해야 한다.

운영 인프라 측면에서 달라지는 것

스테이트리스 전환의 직접적인 수혜는 인프라 운영이다. 스티키 세션 설정이 필요 없어지고, 세션 공유를 위한 별도 저장소도 사라진다. 쿠버네티스 환경이라면 그냥 평범한 라운드로빈으로 레플리카를 늘리면 된다. 프로토콜 차원에서 이 구성이 보장된다.

HTTP 헤더에 메서드명과 도구 이름이 필수로 포함되도록 표준화됐다. 요청 본문을 뜯어보지 않아도 게이트웨이나 로드밸런서에서 특정 도구 호출을 골라 다른 경로로 보내거나 차단할 수 있다. 도구 목록 같은 조회 결과에는 캐시 유효 시간과 공유 캐시 허용 여부가 필수로 붙고, 분산 추적도 OpenTelemetry 기준으로 문서화됐다.

---

보안과 인증, 그리고 SDK 버전 대응

원격 MCP 서버의 인증 방식도 손이 많이 갔다. 기존의 동적 클라이언트 등록 방식은 더 이상 권장하지 않는 상태로 지정됐다. 당장 지원이 끊기는 건 아니지만 새 구현에는 쓰지 않는 게 원칙이다. 대신 HTTPS URL 자체가 클라이언트 ID가 되는 방식이 권장 기준이 됐다. 클라이언트가 메타데이터를 URL로 공개하면 어떤 인가 서버에서든 별도 등록 없이 통하는 구조다.

이 인증 관련 변화는 원격 HTTP 서버를 만들거나 운영하는 쪽에 해당한다. 로컬에서 stdio 방식으로 쓰는 환경에는 적용되지 않는다.

SDK 버전 관리도 확인이 필요하다. 파이썬 기준으로 2.x 버전이 신 스펙을 따른다. 기존 프로젝트에서 버전 제한을 명시하지 않으면 2.x가 자동 설치되어 호환 문제가 생길 수 있다. 새로 시작하는 프로젝트라면 처음부터 2.x로 시작하면 된다.

신 스펙 클라이언트와 구 스펙 서버, 또는 그 반대 조합만 실패한다. 한쪽이라도 양쪽을 지원하면 동작한다. 당분간은 두 버전을 모두 지원하는 구성이 가장 안전하다.