이 기사에 대하여

2026년 7월 28일, Model Context Protocol (MCP)의 5번째 사양 개정인 MCP 2026-07-28이 공개되었습니다. Anthropic의 발표 기사인 Bringing MCP 2026-07-28 to Claude와 사양 본체의 변경 이력을 바탕으로,

애초에 MCP는 무엇을 해결하기 위해 태어났는가 (기존의 의미)
이번 개정으로 무엇이 근본적으로 변하는가 (스테이트리스 (Stateless)화 · 확장 기능 · 인증)
입장에 따라 내일부터 무엇을 해야 하는가 (미래)

를 전문 용어를 최대한 쉽게 풀어서 정리합니다.

먼저 결론부터 말씀드리면 다음과 같습니다.

MCP는 'AI와 도구를 연결하는 규격'에서,

'운영 인프라에 배치할 수 있는 배관'이 되었습니다. 이를 위해 지금까지 전제되어 왔던 '연결을 유지한다'는 사고방식 자체를 버렸습니다.

제1부 — MCP는 애초에 무엇이었는가

진짜 과제는 'AI가 도구를 사용할 수 없다'는 것이 아니었다

2024년 11월에 MCP가 등장하기 전에도, AI에게 도구를 사용하게 하는 것 자체는 이미 가능했습니다. 함수를 정의하고 모델이 호출하게 하면 됩니다. 문제는 그것이 아니라, 조합의 수였습니다.

AI 애플리케이션이 N개, 연결하고 싶은 도구나 데이터가 M개 있다면, 필요한 연결 코드는 N × M 개가 됩니다. Slack용 연결 코드를 Claude용으로 작성하고, 똑같은 것을 다른 앱용으로 다시 작성하고, GitHub에서도 똑같은 일을 반복하는... 그런 세상입니다.

MCP가 한 일은 이 중간에 **공통의 소켓 (Socket)**을 하나 놓은 것입니다. 도구 측은 'MCP 서버'를 하나만 작성하면 되고, AI 측은 'MCP 클라이언트'를 하나만 구현하면 됩니다. 조합은 N × M에서 N + M으로 줄어듭니다.

'AI와 도구 사이의 USB-C'라고 자주 설명되는 것이 바로 이 구조를 말합니다.

形の違う差込口に手作りのプラグを合わせ続けるすみと、ひとつの丸い穴に差すだけのすみ

MCP의 기본 부품은 3개뿐

사양의 세부 사항은 매년 늘어나고 있지만, 초기부터 이어져 온 생각의 중심은 지금도 이 3가지입니다.

이 중 실무에서 가장 많이 사용되는 것은 Tools입니다. 'MCP 서버를 작성한다'라고 말할 때, 대부분의 경우는 Tools를 몇 개 만드는 것을 의미합니다.

규모의 문제

Anthropic의 발표에 따르면, MCP의 SDK 다운로드 수는 월간 4억 회를 돌파했으며, 올해 들어 4배 증가했습니다. 이제 더 이상 Anthropic 전용 메커니즘이 아니라, AI 에이전트와 애플리케이션을 연결하는 업계 표준으로 취급되고 있습니다.

이 '표준이 되어버렸다'는 사실이 이번 개정의 배경 그 자체입니다.

제2부 — 5번의 개정을 통해 MCP는 어디로 향하고 있었는가

MCP의 버전은 YYYY-MM-DD 형식을 따르며, 하위 호환성 (Backward Compatibility)을 깨뜨리는 변경이 들어간 날짜가 이름이 됩니다. 호환성을 유지하는 개선에서는 번호가 올라가지 않습니다. 즉, 버전이 늘어났다는 것은 매번 '깨뜨려서라도 고칠 가치가 있다'고 판단되었다는 뜻입니다.

나열해 보면 방향이 명확해집니다. "데모에서 동작하는" 단계에서 "본番에서 운용할 수 있는" 단계로의 5년 치 이동입니다. 그리고 2026-07-28은 그 이동의 마지막에 남아있던 가장 큰 장애물 —— "연결을 유지한다"는 전제 —— 에 손을 댄 버전입니다.

제3부 — 2026-07-28의 본질은 3가지

(1) 상태 비저장화 (Stateless): 전화를 그만두고, 편지로 바꾸다

이번에 가장 큰 변경 사항입니다.

지금까지의 MCP는 먼저 연결을 확립한 다음 대화하는 프로토콜이었습니다.

• 클라이언트가 initialize를 보냄 - 서버가 "나는 이 버전이며, 이런 기능이 있습니다"라고 응답
• 클라이언트가 notifications/initialized를 응답 - 여기서부터 비로소 tools/list나 tools/call을 사용할 수 있음 - HTTP의 경우 이 일련의 과정을 Mcp-Session-Id 헤더로 동일 세션으로서 묶음

즉 전화입니다. 먼저 상대와 회선을 연결하고, 서로 통성명을 한 뒤에 본론으로 들어갑니다. 편리하지만, 회선이 끊기면 처음부터 다시 시작해야 하며, 그동안 서버 측은 계속 "누구와 이야기하고 있는지"를 기억하고 있어야 합니다.

2026-07-28은 이것을 전부 그만두었습니다.

• initialize / notifications/initialized 핸드셰이크(Handshake)를 삭제
• Streamable HTTP에서 Mcp-Session-Id 헤더를 삭제
• 대신, 모든 요청이 스스로 모든 것을 가짐. _meta 필드에 프로토콜 버전(io.modelcontextprotocol/protocolVersion)과 클라이언트의 기능(io.modelcontextprotocol/clientCapabilities)을 매번 포함함. 클라이언트는 매번 자신의 이름도 포함해야 하며(clientInfo), 서버도 각 응답의 _meta에서 자신을 밝혀야 함(serverInfo) - 버전이 맞지 않으면 해당 요청 단위로 UnsupportedProtocolVersionError가 반환됨

편지가 된 것입니다. 봉투 하나에 "발신인·사용하는 버전·이쪽의 능력"까지 전부 적혀 있으므로, 받는 쪽은 앞뒤 문맥을 기억하고 있을 필요가 없습니다.

受話器を肩に挟んで作業するすみと、必要事項を全部書いた封筒をポストに入れるすみ

대신 추가된 것이 server/discover입니다. 서버는 반드시 구현할 의무가 있으며, 대응 버전·기능·자신의 정보를 단 한 번의 요청으로 반환합니다. 클라이언트는 "먼저 버전을 확인하고 싶을 때"만 호출하면 되고, 호출하지 않고 직접 tools/call을 하여 에러가 반환되면 그때 대응해도 상관없습니다. 필수적인 악수가 선택적인 사전 조사로 바뀌었다는 표현이 적절합니다.

(2) 상태 비저장화(Stateless)를 하면 무엇이 좋은가

이 부분이 실무적인 핵심입니다.

세션을 갖지 않는다는 것은, 서버가 요청들 사이에 아무것도 기억하지 않아도 된다는 뜻입니다. 그러면 동일한 서버를 여러 대 배치하더라도, 어느 서버에 접속하든 동일한 답이 돌아옵니다. 한 대가 다운되더라도 다음 요청은 다른 서버가 받을 수 있습니다.

이것은 곧 서버리스(Serverless)와 에지(Edge)에 올라갈 수 있다는 의미입니다. AWS Lambda나 Cloudflare Workers와 같이 "호출되었을 때만 실행되고 종료되면 사라지는" 환경은 상태를 유지할 수 없다는 점이 가장 큰 제약이었습니다. MCP가 스테이트리스(Stateless)하게 변함에 따라, 이러한 제약과 충돌하지 않게 되었습니다.

Anthropic의 발표에서도 Figma의 VP of Engineering은 다음과 같이 언급했습니다.

"이용이 늘어남에 따라, 우리의 스테이트리스 아키텍처(Architecture)는 함께 스케일(Scale)할 수 있습니다."

MCP 서버의 운영 비용이 낮아진다는 것이 사용자 측면에서 보는 효과입니다. "항시 가동되는 서버를 준비하고 유지할" 필요가 없어지므로, 개인이나 작은 팀이 MCP 서버를 계속 공개하는 장벽이 낮아집니다.

手回し機械から折りたたみ式の同じ窓口を量産して並べるすみ、記憶付きの大きな窓口は赤で消されている

물론 "호출을 넘나들며 상태를 유지하고 싶은" 케이스는 남아 있습니다. 그 해답은 프로토콜의 기능이 아니라, 단순한 도구 인자(Tool Argument)로 만드는 것입니다. 서버가 발행한 핸들(Handle, 식별자)을 반환하고, 다음 호출 시 이를 일반적인 인자로 전달받는 방식입니다. 프로토콜이 복잡한 관리를 맡는 대신, 애플리케이션 설계 단계로 책임을 넘긴 것입니다.

이와 함께 알림(Notification) 메커니즘도 정리되었습니다.

"연결을 유지한다"는 전제에 의존했던 기능들이 여기서 일제히 정리된 구조입니다.

(3) 확장 기능: 본체는 가볍게, 기능은 삽입하기

또 다른 큰 변화는 코어(Core)와 확장(Extension)의 분리입니다.

지금까지 새로운 기능은 사양(Specification) 본체에 추가되어 왔습니다. 편리하긴 하지만, 본체가 비대해지면 "모두 구현해야만 준수를 주장할 수 있는" 상태가 되어 서버를 작성하는 부담이 커집니다.

2026-07-28 버전에서는 ClientCapabilities / ServerCapabilities에 extensions 필드가 추가되어, 공식 확장을 버전별로 독립적으로 배포할 수 있게 되었습니다. 그리고 대표적인 두 가지 기능이 그곳으로 이동했습니다.

Tasks의 재설계 또한 실용적인 방향입니다. 결과가 반환될 때까지 계속 기다리는 tasks/result를 없애고, tasks/get을 통해 **폴링(Polling)**하는 방식으로 바뀌었습니다. 스테이트리스한 세계에서는 "계속 기다리는 것" 자체가 비용이므로 타당한 결정입니다. 나아가 tasks/update를 통해 클라이언트 측에서 중간에 입력을 전달할 수 있게 되었고, tasks/list는 삭제되었으며, 서버는 요청받지 않아도 태스크 핸들(Task Handle)을 반환할 수 있게 되었습니다.

薄い板に版番号のついた部品をカチッと差し込むすみ、全部入りで膨らんだ古い板は赤で消されている

코어는 가볍게 유지하고, 기능은 버전별로 나중에 삽입한다. 오래 지속되는 프로토콜이 반드시 거쳐야 하는 정리 단계에 MCP가 진입했다는 뜻입니다.

(4) 인증: 자체 배지를 버리고, 기업의 접수처가 발행한 것을 사용하기

세 번째는 인가(Authorization)의 본격적인 사양화입니다. 목적은 명확합니다. Entra나 Okta와 같은 기업의 기존 ID 기반(Identity Infrastructure)에 우회책 없이 연결되도록 하는 것입니다.

가장 상징적인 것이 Dynamic Client Registration (DCR, RFC 7591)의 비권장(Deprecation) 처리입니다. DCR은 "클라이언트가 그 자리에서 자신을 등록하는" 메커니즘으로, MCP 초기에는 편리했습니다. 하지만 기업의 인가 서버(Authorization Server)는 대개 정체를 알 수 없는 클라이언트의 자기 등록을 허용하지 않습니다. 대신 권장되는 방식은 Client ID Metadata Documents로, 이는 "자신의 정보를 공개된 URL에 두고, 인가 서버가 이를 확인하러 오게 하는" 방식입니다. DCR은 호환성을 위해 남겠지만, 신규 구현에서 선택하는 방식은 아니게 되었습니다.

세부적인 사항들도 실제 운영(Production)에 효과적인 방향으로 확정되고 있습니다.

• 인가 응답(Authorization Response)에 iss (발행자)를 포함해야 하며, 클라이언트는 이를 검증해야 합니다 (RFC 9207).
• 클라이언트의 자격 증명(Credentials)은 발행한 인가 서버에 종속됩니다. issuer를 키(Key)로 저장해야 하며, 이를 다른 인가 서버에서 재사용해서는 안 됩니다. 인가 서버가 바뀌면 재등록이 필요합니다.

요컨대 "돌아가기만 하면 된다"에서 "타인의 환경에서도 안전하게 동작한다"로 기준을 강화하는 것입니다.

自作の紙バッジは通らず、受付から渡された本物のバッジで扉が開く

(5) 사라지는 것 · 비권장되는 것

이번에 가장 놓치기 쉬운 부분이 바로 여기입니다. 3가지 기존 기능이 비권장(Deprecated)되었습니다.

이에 더해, HTTP+SSE 전송(2025-03-26부터 비권장)이 정식으로 Deprecated로 분류되었으며, Streamable HTTP로의 이행이 명시되었습니다.

그리고 사소하지만 중요한 점은, 기능 폐지 규칙 자체가 제정되었다는 것입니다.

• 기능의 상태는 Active / Deprecated / Removed의 3가지로 구분됩니다.
• 비권장(Deprecated) 상태가 된 후 삭제되기까지는 최소 12개월이 소요됩니다 (예외적인 신속 삭제의 경우에도 최소 90일).
• 비권장 기능은 이행 방법과 함께 전용 레지스트리에서 목록으로 관리됩니다.

즉, "내일 당장 사라지는" 일은 없습니다. 비권장된 기능은 계속 작동합니다. 다만 **"새로 만드는 것에는 사용하지 않는다"**라고 이해하는 것이 정확합니다.

砂時計付きの棚に、札のついた古い道具を置くすみ。道具からはまだ橙の糸が伸びている

이러한 "그만두는 법에 대한 예법"이 갖춰진다는 것은, 사양이 취미의 영역에서 표준(Standard)의 영역으로 넘어갔다는 신호입니다.

(6) 눈에 띄지는 않지만 효과적인 변경 사항

헤드라인에 오를 정도는 아니지만, 실제 운영에서 유용한 것들을 나열해 보겠습니다.

• 캐시 힌트(Cache Hint)가 필수화됨: tools/list 등의 결과에 ttlMs (얼마나 밀리초 동안 신선한 것으로 간주할지)와 cacheScope (public / private)를 반드시 포함해야 합니다. 클라이언트가 결과를 캐싱할 수 있게 되어 불필요한 폴링(Polling)이 줄어듭니다.
• 정렬 순서 고정: 순서가 매번 바뀌면 클라이언트의 캐시도, LLM의 프롬프트 캐시(Prompt Cache)도 적중하지 않습니다. 정렬 순서를 고정하는 것만으로도 비용을 낮출 수 있습니다. tools/list는 결정적인 순서로 반환되어야 합니다.
• OpenTelemetry의 트레이스 전파(Trace Propagation) 규약화: _meta의 traceparent / tracestate / baggage. MCP를 거치는 호출을 기존의 분산 트레이싱(Distributed Tracing)에 태울 수 있습니다.
• 요청 헤더(Request Header)의 표준화: Streamable HTTP의 POST에 Mcp-Method / Mcp-Name이 필수입니다. 중간의 프록시(Proxy)나 게이트웨이(Gateway)가 본문을 열어보지 않고도 라우팅할 수 있습니다.
• 스키마 제약 완화: inputSchema / outputSchema에서 JSON Schema 2020-12의 키워드를 자유롭게 사용할 수 있으며, $ref도 해결됩니다.

캐시, 트레이스, 헤더를 통한 라우팅. 이 모든 것은 "대량으로 구동하기" 위한 기능들입니다. 이 목록만 보더라도 이번 버전이 누구를 위해 작성되었는지 알 수 있습니다.

제4부 — 입장에 따라, 무엇을 해야 하는가

MCP 서버를 만들고 있는 사람

해야 할 일은 3가지입니다.

• 서버 측의 새로운 의무 사항이 된 server/discover를 구현한다.
• Roots / Sampling / Logging을 사용 중인지 점검한다. 사용 중이라면 이관 대상을 확인한다. 서두를 필요는 없지만, 신규 기능을 이 기능들 위에 쌓는 것은 중단한다.
• 세션에 의존하는 설계를 파악한다. "최초의 initialize에서 받은 정보를 기억해 두는" 구현이 있다면, 이를 요청(request) 단위의 _meta 또는 서버가 발행한 핸들(handle)을 도구 인자(tool argument)로 받는 형태로 변경한다.

이관 자체를 재촉하지는 않습니다. 버전은 요청 단위로 협상되며, 클라이언트와 서버 모두 여러 버전을 동시에 지원할 수 있는 설계입니다. STDIO에서는 server/discover를 하위 호환성 탐색 도구로 사용할 수 있습니다. SDK가 이를 따를 것이므로, 대부분의 구현은 SDK 업데이트로 상당 부분 해결될 것입니다.

사용하는 사람 (Claude Desktop / Claude Code 사용자)

지금 당장 해야 할 일은 없습니다. 다만 발표에서는 "Claude 제품에 대한 대응이 순차적으로 롤아웃(rollout) 중"이라고 명시되어 있으며, 아직 전면 대응이 완료된 상태는 아닙니다.

중기적으로 기대할 수 있는 것은 다음 두 가지입니다.

• 사용 가능한 MCP 서버가 늘어난다. 서버리스(serverless) 환경에 올라가는 만큼 공개 및 유지 관리 비용이 낮아지므로, 커넥터의 수와 수명이 늘어나는 방향으로 작용합니다.
• 대화 속에서 완결되는 조작이 늘어난다. MCP Apps를 통해 커넥터가 대화 내에 UI를 그릴 수 있습니다. 별도의 탭으로 이동하지 않고 그 자리에서 조작할 수 있다는 경험의 변화입니다.

기업의 IT 관리자

이번 권한 부여(authorization) 관련 정비는 실질적으로 관리자를 위한 변경입니다. Anthropic 측에서는 Enterprise-managed auth로서, 관리자가 ID 프로바이더(IdP)를 통해 커넥터를 조직 전체에 배포할 수 있는 메커니즘을 제공합니다. 관리자가 한 번 승인하면 사용자는 기존 IdP 그룹을 통해 액세스 권한을 승계하며, 최초 로그인 시 이미 연결된 상태가 됩니다. 즉, 엔드 유저 측의 설정 작업이 제로(zero)가 됩니다.

사내 네트워크 내부의 서버를 공개하지 않고 연결하고 싶은 경우에는 MCP tunnels(리서치 프리뷰)가 있습니다. 인바운드 방화벽 규칙, 공개 엔드포인트, 오리진(origin) IP 허용 목록 등이 필요 없는 위치에 있습니다.

제5부 — 앞으로 어떻게 될 것인가

여기서부터는 사양(specification)과 발표 내용을 바탕으로 한 분석입니다.

MCP는 '기능'이 아니라 '배관'이 된다

이번 변경을 한마디로 요약하면, MCP가 의식되는 대상에서 벗어나는 방향입니다. 스테이트리스(stateless)하고, 서버리스에 올라가며, 캐시 힌트를 가지고, 기존의 분산 트레이싱(distributed tracing)에 올라타며, 기업의 ID 기반에 그대로 연결됩니다. 이는 '화제의 신기술'의 성질이 아니라, 인프라의 성질입니다.

수도관은 평소에 의식되지 않습니다. MCP는 그 지점을 목표로 하고 있습니다.

core는 앞으로 크게 움직이지 않을 것이다

extensions 프레임워크가 만들어짐에 따라, 신규 기능의 추가 대상은 core가 아닌 확장(extension)이 됩니다. 이는 곧 다음의 파괴적 변경(새로운 날짜 버전)은 한동안 오기 어려울 것임을 의미합니다. 이번에 크게 변경을 가한 이유 중 하나도 "파괴적인 변경은 이번으로 끝내기 위해서"일 것입니다.

역설적으로 말하면, 2026-07-28은 이관해 둘 가치가 높은 버전입니다.

'그만두는 방법'이 정립되었다는 의미

기능 라이프사이클(lifecycle) 정책과 권장되지 않음(deprecated) 레지스트리가 만들어진 것은 기능 추가보다 더 중요할 수 있습니다. 표준이 오래 지속될지 여부는 기능을 늘리는 방식이 아니라 줄이는 방식에 달려 있습니다. 12개월의 유예 기간과 이관 대상의 명시가 규칙화되었다는 것은, MCP를 전제로 장기적인 시스템을 구축해도 괜찮다는 선언에 가깝습니다.

주의할 점

• Claude 제품 측의 대응은 롤아웃 중이다. 사양이 나온 날과 실제 도구에서 사용할 수 있는 날은 다릅니다.
• 권장되지 않음(deprecated)이 '지금 당장 작동하지 않음'을 의미하는 것은 아니다. 서둘러 코드를 고칠 필요는 없습니다. 다만 신규 구현 시에는 선택하지 마십시오.
• 스테이트리스화는 설계의 숙제를 넘겼다. 프로토콜이 상태를 가지지 않게 된 만큼, 상태가 필요한 유스케이스는 직접 설계해야 합니다. 핸들(handle) 발행, 유효 기간, 권한 체크는 이제 서버 구현자의 책임 범위입니다.

요약

MCP의 첫 5년은 "AI와 도구를 어떻게 연결할 것인가"에 대한 답을 찾는 과정이었습니다. 2026-07-28이 답하고 있는 것은 그 다음 질문 —— "연결된 것들을 어떻게 프로덕션 (production) 환경에서 견디게 할 것인가" 입니다.

시작하려면 사양 (specification)과 SDK를 살펴보는 것이 빠릅니다. 직접 만든 MCP 서버를 Claude의 커넥터 디렉토리 (connector directory)에 올릴 계획이라면, 제출 절차 (submission procedure)도 함께 확인하십시오.

참고

• Bringing MCP 2026-07-28 to Claude — Anthropic, 2026년 7월 28일
• MCP 2026-07-28 Key Changes — 사양 변경 이력
• MCP Versioning — 버전 협상 메커니즘
• MCP 2025-11-25 Key Changes — 이전 버전의 변경 이력
• Feature lifecycle — 기능의 비권장(deprecation) 및 삭제 정책

Discussion