MCP 역대급 업데이트…뭐가 달라졌을까

리눅스 재단(Linux Foundation) 산하 에이전틱 AI 파운데이션(Agentic AI Foundation)이 개발 중인 MCP(Model Context Protocol) 새 사양 2026-07-28이 7월 28일 공개됐다. MCP를 세션에 의존하지 않는 스테이트리스(Stateless) 설계로 전환한 걸 비롯해 장시간 처리, 사용자 확인, 캐시, 인증 등의 구조가 전면 개편됐으며 MCP 등장 이래 최대 규모 업데이트로 자리매김하고 있다.

MCP는 AI 에이전트나 대규모 언어 모델을 활용하는 앱과 외부 데이터·도구·웹 서비스 등을 접속하기 위한 오픈 공통 규격. 앤트로픽이 2024년 11월 공개한 것으로 AI 서비스마다 서로 다른 접속 방식을 개발하는 대신 MCP에 대응해 다양한 AI에서 동일한 도구를 이용할 수 있도록 하는 게 목적이다.

MCP는 이후 다수 AI 서비스와 개발 도구에서 채택됐으며 현재는 에이전틱 AI 파운데이션 프로젝트로 개발되고 있다. 이번에 공개된 2026-07-28에서는 실험적 AI 연계 규격으로 설계됐던 초기 구조를 재검토해 대규모 서비스에서도 운용하기 쉬운 구성으로 개편됐다.

이번 업데이트 최대 변경점은 MCP 통신 방식이 스테이트풀(Stateful)에서 스테이트리스로 전환된 것이다. 기존 MCP에서는 클라이언트와 서버가 처음에 initialize와 initialized라는 교환을 수행하고 이후 Mcp-Session-Id를 사용해 동일한 접속 상태를 유지했다.

하지만 이 방식으로 다수 MCP 서버를 운용할 경우 동일 사용자 통신을 같은 서버로 계속 보내는 스티키 세션이나 복수 서버 간 세션 정보를 공유하는 데이터베이스가 필요하다. 서버를 증감시키거나 장애가 발생한 서버에서 다른 서버로 처리를 이전하기 어려워 대규모 운용의 걸림돌이 되어 왔다.

새 사양에서는 initialize에 의한 초기화 처리와 Mcp-Session-Id가 폐지됐으며 각 요청이 프로토콜 버전, 클라이언트 정보, 이용 가능한 기능 등을 개별적으로 전달하도록 변경됐다. 서버가 제공하는 기능을 사전에 확인하고 싶을 경우 새로 신설된 server/discover를 이용할 수 있지만 이 처리는 필수가 아니다.

각 요청이 단독으로 완결되기 때문에 통신을 같은 서버로 계속 보낼 필요가 없어졌으며 일반적인 로드 밸런서를 사용해 여유 있는 서버로 처리를 분배할 수 있다. 이를 통해 MCP 서버를 일반 HTTP 서비스와 마찬가지로 쿠버네티스(Kubernetes), 서버리스 환경, 엣지 환경 등에 배포하고 접속 수에 따라 증감시키기 쉬워졌다.

다음은 앱 상태는 식별자로 관리한다는 것. 스테이트리스화로 인해 장바구니 내용이나 브라우저 조작 상황 등 앱이 보유한 상태 자체를 저장할 수 없게 되는 건 아니다. 복수 호출에 걸쳐 정보를 유지해야 할 경우 서버가 상태를 나타내는 식별자를 발급하고 AI 에이전트가 다음 도구 호출 시 이를 명시적으로 전달한다.

기존에는 통신 세션 내부에 숨겨져 있던 정보가 도구 인수로 명시적으로 다뤄지게 된다. 이를 통해 어떤 상태를 사용하여 처리하고 있는지를 AI 에이전트나 개발자가 파악하기 쉬워지며 서버 측에서도 특정 접속을 유지할 필요가 없어진다.

다음은 사용자 확인을 여러 차례 수행할 수 있는 MRTR. 스테이트리스화에 맞춰 처리 도중 사용자로부터 추가 정보를 받기 위한 MRTR(Multi Round-Trip Requests)도 도입됐다. 예를 들어 AI 에이전트가 데이터를 삭제하려 할 때 확인이 필요한 경우 서버는 input_required라는 결과와 질문 내용을 반환한다.

클라이언트는 사용자로부터 응답을 받아 해당 정보를 추가한 뒤 원래 요청을 재전송한다. 서버 측에서 접속 중인 클라이언트에 질문을 다시 보낼 필요가 없어졌으며 사용자 확인이나 누락 항목 입력을 스테이트리스 통신으로 처리할 수 있다.

다음은 HTTP 헤더와 캐시도 전면 개편. 통신 분배와 모니터링을 용이하게 하기 위해 HTTP 헤더에는 호출하는 기능을 나타내는 Mcp-Method와 도구명 등을 나타내는 Mcp-Name을 포함하는 게 의무화됐다. 게이트웨이, 레이트 제한 시스템, 웹 애플리케이션 방화벽 등은 요청 본문의 JSON을 파싱하지 않아도 헤더만 보고 통신을 분배하거나 접근을 제어할 수 있다.

이용 가능한 도구, 프롬프트, 리소스 등의 목록에는 유효 기간을 나타내는 ttlMs와 캐시 범위를 나타내는 cacheScope도 추가됐다. 클라이언트는 변경되지 않은 도구 목록을 매번 가져올 필요가 없어져 서버로의 통신량을 줄일 수 있다.

도구 목록 정렬 순서도 일정해지기 때문에 AI에 전달하는 프롬프트 내용이 접속할 때마다 변화해 캐시가 무효화되는 문제를 억제할 수 있다. MCP 서버가 다수 도구를 제공하는 경우나 다수 사용자가 동시에 접속하는 경우 효과가 기대된다.

다음은 장시간 처리와 화면 표시는 확장 기능으로 도입했다는 것. 새로운 기능을 MCP 본체와 분리해 추가할 수 있는 정식 확장 기능 구조도 도입됐다. 모든 기능을 핵심 사양에 넣는 대신 필요한 클라이언트나 서버만 확장 기능을 선택해 대응할 수 있다.

장시간 처리를 다루는 MCP 태스크(MCP Tasks)는 실험적 기능에서 정식 확장 기능으로 전환됐다. 서버는 처리를 계속하면서 태스크 식별자를 반환하고 클라이언트는 해당 식별자를 사용해 진행 상황이나 결과를 나중에 가져올 수 있다.

채팅 내에 폼, 표, 대시보드 등 조작 가능한 화면을 표시하는 MCP 앱스(MCP Apps)도 이 확장 기능 구조로 제공된다. MCP는 단순히 AI에서 외부 도구를 호출하는 데 그치지 않고 사용자가 조작하는 화면을 포함하는 AI 앱 기반으로도 확장되고 있다.

다음은 OAuth 인증 안전성 강화. 인증에 대해서는 OAuth 2.0이나 오픈ID 커넥트(OpenID Connect)를 기업 시스템에서 활용하는 방식에 맞춘 강화가 이뤄졌다. 인증 서버를 나타내는 iss 정보 검증이 필수화됐으며 클라이언트의 인증 정보는 발급원의 인증 서버와 명확히 연결된다.

이를 통해 특정 인증 서버용으로 발급된 정보가 다른 인증 서버에서 잘못 사용되는 걸 방지하기 쉬워진다. 클라이언트를 즉석에서 등록하는 다이내믹 클라이언트 레지스트레이션(Dynamic Client Registration)은 비권장으로 전환됐으며 클라이언트 정보를 문서로서 공개하는 클라이언트 ID 메타데이터 도큐먼트(Client ID Metadata Documents)로의 이행도 추진된다.

다음으로는 폐지되는 기능에는 12개월 이행 기간이 있다. 사양 변경으로 인해 기존 구현이 갑자기 사용할 수 없게 되는 것을 방지하기 위해 정식 폐지 방침도 정해졌다. 기능이 비권장으로 지정된 뒤 삭제되기까지 최소 12개월 이행 기간이 부여된다.

이번 업데이트에서는 루츠(Roots), 샘플링(Sampling), 로깅(Logging)과 기존 HTTP와 서버 센트 이벤트(Server-Sent Events)를 조합한 통신 방식이 비권장으로 전환됐다. 다만 이들 기능은 즉시 삭제되는 게 아니며 최소 향후 12개월간은 이용할 수 있다.

클로드와 깃허브도 새 사양에 대응한다. 타입스크립트(TypeScript), 파이썬(Python), 고(Go), C#의 주요 SDK는 새 사양 공개와 동시에 2026-07-28 대응을 완료했으며 러스트(Rust)판 SDK도 베타 버전으로 대응하고 있다. 주요 SDK는 기존 사양과의 하위 호환성을 유지하고 있기 때문에 기존 MCP 접속을 그대로 사용하기만 한다면 즉시 이행할 필요는 없다.

깃허브 MCP 서버(GitHub MCP Server)는 정식 공개에 앞서 새 사양에 대응했으며 세션 정보를 저장하던 레디스(Redis)로의 읽기·쓰기와 요청 본문에서 처리 내용을 판별하는 구조를 삭제했다. 깃허브 측은 스테이트리스화로 서버 구성이 간소해져 일반 클라우드 인프라 위에서 운용하기 쉬워졌다고 설명했다.

앤트로픽도 클로드(Claude) 각 제품에 새 사양 대응을 순차 도입할 것이라고 발표했다. 클로드 커넥터 디렉터리에는 950건을 넘는 MCP 서버가 등록되어 있으며 새 사양을 통해 운용 부담을 줄이면서 MCP 서버를 대규모로 전개할 수 있게 된다고 밝혔다.

이번 업데이트에는 세션 폐지 등 호환성을 깨뜨리는 변경이 포함되어 있어 세션 ID에 의존하는 MCP 서버나 클라이언트에서는 이행 작업이 필요하다. 반면 MCP를 일반적인 HTTP 인프라 위에서 안전하고 대규모로 운용하기 위한 구조가 갖춰졌으며 기업 프로덕션 환경에서도 도입하기 쉬운 설계가 됐다. 관련 내용은 이곳에서 확인할 수 있다.