MCP가 연결을 끊고 다시 짰습니다 — 월 4억 다운로드와 무상태 대개정

AI가 바깥 도구를 불러 쓰는 방식에는 공용 규격이 있습니다. 이름은 MCP, 모델 컨텍스트 프로토콜입니다.

이 규격의 SDK 내려받기가 월 4억 회에 가까워졌습니다. 2년 전 출시 때는 월 200만 회였습니다. 타입스크립트와 파이썬 SDK는 누적 10억 회를 넘었습니다.

그리고 이 규격이 출시 이후 가장 크게 바뀌었습니다. 핵심은 하나입니다. 연결을 계속 붙들고 있던 방식을 버리고, 요청 하나하나가 스스로를 설명하는 방식으로 갈아탔습니다.

AI 도구 연결 규격이 통째로 바뀌었습니다

2026-07-28 판 규격이 공개됐습니다. MCP가 나온 이래 가장 큰 개정입니다.

바뀐 것은 기능 몇 개가 아니라 통신 방식 자체입니다. 프로토콜의 뼈대가 달라졌습니다.

쓰던 코드가 깨지는 변경도 포함돼 있습니다. 그래서 미리 알아둘 필요가 있습니다.

MCP가 무엇인지 30초 설명

MCP는 AI 모델이 외부 도구와 데이터에 접근하는 방법을 정해 놓은 공용 약속입니다.

이 약속이 없으면 모델마다, 도구마다 연결 코드를 따로 만들어야 합니다. 조합이 늘어날수록 감당이 안 됩니다.

규격을 하나로 맞추면 도구를 한 번 만들어 여러 모델에 붙일 수 있습니다. USB 규격이 기기와 주변장치 사이에서 한 일과 비슷합니다.

월 4억 다운로드라는 숫자

주요 SDK를 합친 월간 내려받기가 5억 회에 근접하는 수준으로 보고됐습니다.

이 숫자는 사람 수가 아니라 설치 횟수입니다. 자동화된 빌드가 반복해 내려받는 것도 포함됩니다.

그래도 방향은 분명합니다. 이 규격을 전제로 만들어지는 소프트웨어가 그만큼 많다는 뜻입니다.

2년 전에는 월 200만이었습니다

MCP가 처음 공개된 것은 2024년 11월입니다. 그때 월간 SDK 내려받기는 약 200만 회였습니다.

2025년 4월 오픈AI가 이 규격을 채택하면서 2,200만 회로 뛰었습니다.

2026년 3월에는 9,700만 회가 됐고, 지금은 그보다 몇 배 위에 있습니다. 계단식으로 올라온 곡선입니다.

타입스크립트와 파이썬 SDK 누적 10억

두 SDK는 각각 누적 내려받기 10억 회를 넘겼습니다.

이 둘이 앞서는 이유는 단순합니다. 웹과 데이터 분야에서 가장 많이 쓰이는 언어이기 때문입니다.

다른 언어 SDK도 함께 유지되고 있어서 특정 언어에 갇히지는 않습니다.

쿠버네티스보다 빠른 확산 곡선

비교 대상으로 자주 언급되는 것이 쿠버네티스입니다. 인프라 표준이 자리 잡는 데 보통 몇 년이 걸립니다.

쿠버네티스는 비슷한 규모에 이르는 데 4년 가까이 걸렸습니다. MCP는 그보다 훨씬 짧은 기간에 도달했습니다.

AI 도구 생태계가 그만큼 빠르게 커졌고, 그 안에 표준이 비어 있었다는 뜻이기도 합니다.

2026-07-28 규격, 출시 이후 최대 개정

새 규격의 날짜 이름은 2026-07-28입니다. MCP는 버전 번호 대신 날짜로 규격을 구분합니다.

이번 판의 핵심 변경은 네 가지입니다. 무상태 전환, 다중 왕복 요청, 헤더 라우팅, 캐시 가능한 응답입니다.

하나씩 보면 왜 이것이 큰 변화인지 드러납니다.

핵심은 무상태입니다

무상태는 서버가 이전 대화를 기억하지 않는 방식을 말합니다. 영어로는 스테이트리스입니다.

이전 MCP는 클라이언트와 서버가 연결을 열어두고 그 안에서 주고받는 구조였습니다. 서버가 세션을 기억해야 했습니다.

새 규격은 그 전제를 없앴습니다. 각 요청이 독립적으로 처리됩니다.

핸드셰이크가 사라졌습니다

예전에는 통신을 시작하기 전에 서로 인사를 나누는 절차가 있었습니다. 버전과 기능을 맞추는 과정입니다.

새 규격에서는 이 절차가 없어졌습니다. 처음부터 바로 요청을 보낼 수 있습니다.

연결을 세우는 비용이 사라졌기 때문에 짧은 작업일수록 이득이 큽니다.

요청이 스스로를 설명한다는 뜻

핸드셰이크를 없애려면 그 정보가 어딘가에 들어가야 합니다. 새 규격은 요청 안에 넣었습니다.

프로토콜 버전, 클라이언트 신원, 지원 기능이 요청의 메타데이터로 함께 갑니다.

그래서 서버는 앞의 대화를 몰라도 그 요청 하나만 보고 처리할 수 있습니다.

로드밸런서 뒤 아무 서버나 받을 수 있습니다

이 변화의 실질적 효과가 여기서 나옵니다. 요청을 어느 서버가 받아도 상관없어집니다.

예전에는 같은 세션의 요청이 같은 서버로 가야 했습니다. 그러려면 별도의 공유 저장소나 고정 라우팅이 필요했습니다.

이제는 평범한 로드밸런서 하나면 됩니다. 운영 난이도가 크게 내려갑니다.

서버리스와 엣지가 열렸습니다

서버리스 환경은 요청이 올 때만 잠깐 실행됩니다. 상태를 붙들고 있을 수가 없는 구조입니다.

예전 MCP는 그래서 서버리스와 잘 맞지 않았습니다. 엣지도 마찬가지였습니다.

무상태로 바뀌면서 이 환경들이 자연스럽게 후보가 됐습니다. 비용과 확장 면에서 선택지가 넓어졌습니다.

MRTR, 통화 중에 되묻기

무상태로 가면 잃는 것이 하나 있습니다. 서버가 먼저 말을 거는 능력입니다.

도구를 실행하다 사용자에게 물어봐야 할 때가 있습니다. 예전에는 열려 있는 양방향 통로로 물었습니다.

새 규격은 이것을 다중 왕복 요청, 줄여서 MRTR로 바꿨습니다. 통로 대신 여러 번의 요청으로 처리합니다.

input_required 라는 응답 유형

MRTR의 동작은 간단합니다. 서버가 입력이 더 필요하면 결과 대신 입력 필요라는 응답을 돌려줍니다.

응답 형식에 resultType 값으로 input_required가 들어갑니다.

클라이언트는 사용자에게 물어보고, 답을 담아 같은 요청을 다시 보냅니다. 통로를 열어둘 필요가 없어집니다.

헤더 라우팅, Mcp-Method와 Mcp-Name

새 규격은 무엇을 호출하는지를 HTTP 헤더에 넣습니다. Mcp-Method와 Mcp-Name입니다.

예전에는 이 정보가 요청 본문 안에 있었습니다. 본문을 열어야만 무슨 요청인지 알 수 있었습니다.

헤더로 나오면 중간 장비가 본문을 건드리지 않고도 판단할 수 있습니다.

게이트웨이가 본문을 안 열어도 되는 이유

기업 환경에는 요청을 검사하고 분배하는 장비가 있습니다. 게이트웨이나 방화벽 같은 것들입니다.

이 장비들이 본문을 파싱하려면 비용이 들고, 규격이 바뀔 때마다 같이 손봐야 합니다.

헤더만 읽으면 되는 구조는 이 부담을 없앱니다. 사용량 집계와 접근 제어도 훨씬 단순해집니다.

캐시 가능한 목록 응답, ttlMs와 cacheScope

도구 목록처럼 자주 바뀌지 않는 응답이 있습니다. 매번 새로 물어보는 것은 낭비입니다.

새 규격은 이런 응답에 ttlMs와 cacheScope를 붙였습니다. 얼마나 오래, 어느 범위에서 재사용해도 되는지를 서버가 알려줍니다.

클라이언트는 이 값을 보고 캐시 전략을 세울 수 있습니다. 왕복 횟수가 줄어듭니다.

깨지는 것들 — 세션 식별자를 쓰던 코드

이번 개정에는 호환이 깨지는 변경이 들어 있습니다. 가장 크게 영향받는 것은 세션 식별자를 쓰던 코드입니다.

세션이라는 개념 자체가 없어졌기 때문에, 그 값을 붙들고 있던 로직은 다시 짜야 합니다.

규격 팀은 사전 테스트 피드백을 반영해 이전 부담을 줄였다고 밝혔지만, 손을 대야 하는 것은 사실입니다.

12개월 폐기 예고 창이 생겼습니다

이번 판에서 새로 들어온 운영 규칙이 하나 있습니다. 기능을 없앨 때 최소 12개월 전에 예고한다는 것입니다.

표준을 쓰는 쪽에서는 이 약속이 실제 개정 내용만큼 중요합니다. 언제 갑자기 깨질지 모르면 도입 자체를 망설이게 됩니다.

1년이라는 시간이 보장되면 계획을 세워 옮길 수 있습니다.

Tier 1 SDK 네 개와 러스트 베타

새 규격은 공개 시점에 이미 네 개의 주요 SDK가 지원합니다. 타입스크립트, 파이썬, 고, 씨샵입니다.

러스트 SDK는 베타로 함께 나왔습니다.

규격만 먼저 나오고 구현이 몇 달 뒤에 따라오는 경우가 흔한데, 이번에는 그 간격이 없습니다.

실제 사례 — 로컬 워크스테이션의 MCP 서버들

저희 작업 환경에도 MCP 서버가 여러 개 붙어 있습니다. 이미지 생성, 문서 저장소, 블로그 발행이 각각 하나씩입니다.

이 서버들은 지금까지 상시 연결을 전제로 떠 있었습니다. 쓰지 않는 시간에도 프로세스가 자리를 차지합니다.

무상태로 옮기면 요청이 올 때만 처리하는 구조가 가능해집니다. 작업이 없을 때 자원을 붙들고 있지 않아도 됩니다.

다만 옮기는 일이 공짜는 아닙니다. 세션을 전제로 짜인 부분을 찾아 하나씩 바꿔야 하고, 그 작업량이 서버마다 다릅니다.

마이그레이션을 언제 해야 하나

당장 급한 것은 아닙니다. 12개월 예고 규칙이 생겼고, 이전 방식이 즉시 막히는 것도 아닙니다.

다만 새로 만드는 서버는 처음부터 새 규격으로 짜는 편이 낫습니다. 나중에 옮기는 비용이 더 큽니다.

기존 서버는 세션 식별자를 쓰는 지점부터 찾아 목록으로 만들어 두시면 됩니다. 그게 작업량의 실체입니다.

표준이 인프라가 되면 생기는 일

내려받기 수치가 억 단위로 올라가면 그 규격은 더 이상 선택지가 아니라 바닥이 됩니다.

바닥이 되면 개정 하나가 수많은 곳에 동시에 영향을 줍니다. 그래서 폐기 예고 같은 운영 규칙이 기능만큼 중요해집니다.

MCP가 리눅스 재단 산하 재단으로 이관된 것도 같은 맥락에서 읽힙니다. 한 회사의 결정으로 흔들리지 않게 하려는 장치입니다.

저시력 개발 환경에서의 의미

연결 설정이 줄어드는 변화는 접근성 면에서도 이득이 있습니다. 설정 화면을 오가는 단계가 줄기 때문입니다.

화면 확대를 크게 쓰면 여러 창을 오가는 일 자체가 부담입니다. 왕복이 줄면 그 부담이 함께 줄어듭니다.

반대로 오류가 났을 때 어디서 끊겼는지 파악하기는 조금 더 어려워질 수 있습니다. 오류 메시지를 명확하게 남기는 일이 더 중요해집니다.

핵심 정리

MCP의 월간 SDK 내려받기가 4억 회 수준에 이르렀습니다. 출시 시점 월 200만 회에서 올라온 값이고, 타입스크립트와 파이썬 SDK는 누적 10억 회를 넘겼습니다.

2026-07-28 규격은 출시 이후 최대 개정입니다. 핵심은 무상태 전환으로, 핸드셰이크가 없어지고 각 요청이 버전과 기능을 스스로 담고 갑니다.

이 변화로 평범한 로드밸런서 뒤에서 동작하고 서버리스와 엣지 환경도 쓸 수 있게 됐습니다. 서버가 되묻는 일은 MRTR과 input_required 응답으로 처리합니다.

세션 식별자를 쓰던 코드는 손봐야 합니다. 다만 12개월 폐기 예고 규칙이 새로 생겼고, 주요 SDK 네 개와 러스트 베타가 공개 시점부터 지원합니다.

참고하실 만한 것

MCP 서버를 직접 만들어 쓰고 계시다면, 세션 식별자를 쓰는 지점을 먼저 찾아 목록으로 만들어 두시길 권해 드립니다. 그것이 이전 작업량의 실체입니다.

새로 만드시는 것이라면 처음부터 2026-07-28 규격으로 시작하시는 편이 낫습니다. 나중에 옮기는 비용이 더 큽니다.

SVIL은 로컬 AI 작업 환경과 도구 연결 규격의 변화를 계속 큰 글씨와 쉬운 설명으로 정리해 전해 드리겠습니다.

출처

• The 2026-07-28 Specification (Model Context Protocol Blog)
• Model Context Protocol Blog
• Model Context Protocol (Wikipedia)
• MCP Hits 97M Downloads: Model Context Protocol Guide (Digital Applied)
• The MCP Ecosystem in 2026: How the Model Context Protocol Became the Universal Standard (ChatForest)
• What is MCP (Model Context Protocol)? The 2026 Guide for SaaS PMs (Truto)
• A Year of MCP: From Internal Experiment to Industry Standard (Pento)
• Model Context Protocol (MCP): Enterprise Adoption Guide (guptadeepak.com)

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://svil.dev/