MCP의 새 로드맵: 그 위에 만드는 사람들에게 무엇이 달라지나

8월 22일 Model Context Protocol 유지관리자들은 앞으로 6-12개월의 프로토콜 작업을 다룬 새 로드맵을 공개했다. 우선순위 다섯 개와 각 영역을 맡는 Core Maintainer가 적혀 있고, 어떤 제안을 먼저 검토할지에 관한 조용하지만 중요한 규칙도 하나 들어 있다. 지난 3월 로드맵은 네 가지를 약속했고 대부분이 7월 사양 릴리스에 실제로 들어갔다. 그러니 이번 로드맵은 진지하게 읽을 만한 신뢰를 어느 정도 벌었다. 내 해석은 이렇다. MCP는 의도적으로 평범한 웹 인프라가 되어가고 있다. 빌더에게 유용한 질문은 그것이 스택의 어느 부분을 먼저 바꾸느냐다.

핵심 요점 - 로드맵의 다섯 우선순위는 에이전트 메시징, 하나로 통합된 HTTP 네이티브 전송, 에이전트 신원과 엔터프라이즈 보안, 더 깔끔한 도구 프리미티브, 사양에서 생성하는 SDK다. - 이 영역에 들어가는 사양 제안(SEP)은 신속 검토를 받는다. 밖에 있는 제안은 대기열이 길고 기준도 높을 가능성이 크다. - 3월 로드맵의 약속은 대부분 2026년 7월 28일 사양에 들어갔다. 상태 비저장 코어, 캐시 가능한 목록 결과, 다중 왕복 요청이 포함됐다. - 실제 코드에 가장 먼저 영향을 줄 가능성이 큰 둘은 에이전트 신원(DPoP와 워크로드 신원 연합)과 대규모 카탈로그를 위한 점진적 도구 검색이다. - 로드맵은 방향이지 약속이 아니다. 유지관리자들도 직접 그렇게 말한다. 이걸 기다리느라 개발을 멈출 이유는 없다.

MCP 유지관리자들은 실제로 무엇을 발표했나?

사실부터 보자. 2026년 8월 22일 자 업데이트된 MCP 로드맵은 다음 사양 주기를 다섯 우선순위 영역으로 나눈다. 각각 담당 Core Maintainer와 하나 이상의 Working Group이 붙어 있다.

1. 에이전트 메시징 프리미티브: 클라이언트가 폴링을 멈출 수 있도록 서버가 먼저 보내는 이벤트(채널, 구독, 웹훅)를 만들고, Tasks·트리거·진행 알림이 하나의 수명주기를 공유하도록 구성 방식을 검토한다.

2. HTTP 네이티브 전송 통합과 강화: Streamable HTTP를 단일 바인딩으로 만들고, 장기적으로 로컬 서버에서도 stdio 위에서 같은 방식을 말하게 한다. 캐싱은 ETag까지 확장한다.

3. 에이전트 신원과 엔터프라이즈 보안: DPoP(소유 증명)를 마무리하고, 기존 IETF 표준을 기반으로 에이전트 신원과 위임에 대한 명확한 표준 경로를 정의한다.

4. 개선된 프리미티브: tools/call 결과 형태를 다시 설계하고, 클라이언트가 필요한 만큼만 서버 카탈로그를 알아가는 점진적 검색을 새로 추진한다.

5. 더 나은 SDK 개발자 경험: 확장 계약을 만들고, 1등급 SDK와 퀵스타트를 사양에서 직접 생성하는 실험을 진행한다.

다섯 영역 옆에는 나머지 작업의 속도를 결정할 규칙이 하나 있다. 우선순위 영역 안에 들어가는 SEP는 신속 검토를 받고, Working Group이 뒷받침하는 제안은 가장 빨리 움직인다. 유지관리자들의 표현 그대로 옮기면 “유지관리자의 검토 시간은 희소하다. 우리는 여기부터 쓴다.” 로드맵은 또 이것이 확정 약속이 아니라 현재 생각을 반영한 것이라고 분명히 말한다. 개별 항목은 늦어질 수 있고 다른 형태로 나올 수도 있다.

2026년 8월 22일 공개된 MCP 로드맵은 향후 6-12개월의 다섯 우선순위를 제시한다. 에이전트 메시징, HTTP 네이티브 전송, 에이전트 신원, 개선된 도구 프리미티브, 사양에서 생성하는 SDK다. 이 영역 안의 제안은 신속 검토를 받고, 밖의 제안은 더 긴 대기열을 거친다.

이 로드맵이 왜 중요한가?

지난 로드맵이 실제로 납품됐기 때문이다. 젊은 오픈 소스 프로젝트의 로드맵은 좋은 뜻만 남긴 채 조용히 낡아가는 경우가 많다. 이번에는 이전 실적이 있다. 2026년 3월 로드맵은 네 우선순위를 정했고, 그 대부분이 5개월 뒤 2026년 7월 28일 사양 릴리스에 들어갔다.

채택 규모가 이 로드맵에 무게를 더한다. 2026년 7월 기준 프로토콜의 1등급 SDK는 한 달에 거의 5억 회 다운로드되고 있었고, TypeScript와 Python SDK는 각각 누적 다운로드 10억 회를 넘겼다. 이 정도 규모의 프로토콜이 다음 방향을 알려주면 지도는 한 번 읽어볼 가치가 있다.

출처: MCP 로드맵(2026년 3월·8월)과 2026년 7월 28일 사양 발표.

2026년 3월 MCP 로드맵은 전송 발전, 에이전트 통신, 거버넌스 성숙, 엔터프라이즈 준비를 약속했다. 5개월 뒤 2026년 7월 28일 사양에는 상태 비저장 프로토콜 코어, Tasks 확장, 다중 왕복 요청, 최소 12개월 유예를 둔 공식 폐기 정책이 실제로 들어갔다.

MCP 위에 만들고 있다면 무엇이 달라지나?

빌더에게 당장의 영향은 고르게 오지 않는다. 다섯 영역 가운데 둘은 1년 안에 코드 자체를 바꿀 가능성이 높다. 나머지 셋은 프로토콜이 주변에서 관리되고 유지되는 방식을 바꾼다. 각 항목을 실제 의미로 풀어보자.

에이전트 메시징: 폴링의 끝

실제 에이전트 작업은 요청과 응답 한 번으로 끝나지 않는다. 작업은 몇 분씩 돌고, 클라이언트가 보고 있지 않을 때 서버가 끝내기도 한다. 지금 클라이언트가 할 수 있는 답은 폴링뿐인데 비싸고 보기에도 좋지 않다. 로드맵은 서버 시작 이벤트를 우선순위로 둔다. 채널, 구독, 웹훅을 통해 작업이 끝났을 때 서버가 클라이언트에 알려줄 수 있게 한다. 구성 검토도 그만큼 중요하다. 지금은 Tasks, subscriptions/listen, 진행 알림이 “서버가 아직 안 끝났다”에 대한 서로 다른 세 답이 될 위험이 있다. 유지관리자들은 이들이 하나의 수명주기, 취소 모델, 오류 표면을 공유하게 만들고 싶어 한다. 오래 실행되는 도구를 만든다면 Discord에서 이 영역을 지켜볼 만하다.

어디서나 같은 하나의 전송

2026년 7월 28일 릴리스는 원격 MCP 서버를 평범한 HTTP 워크로드로 만들었다. 이제 로드맵은 원격과 로컬의 차이까지 지우려 한다. Streamable HTTP를 단일 바인딩으로 만들고 로컬 서버에서는 stdin과 stdout을 통해 같은 프로토콜을 말하게 하며, HTTP/2가 멀티플렉싱을 맡는 동안 하위 프로세스의 보안·수명주기 보장은 유지한다. 지금은 HTTP 네이티브 기능마다 stdio용 설계를 따로 만들거나 로컬에서 포기해야 하고, SDK도 전송 파이프라인 두 개를 관리한다. 전송 모델이 하나면 그 중복이 줄어든다. 캐싱도 확장된다. 7월에 들어온 ttlMs와 cacheScope 힌트 위에 ETag를 얹어 도구 호출 결과를 매번 다시 가져오는 대신 버전으로 관리할 수 있게 한다.

에이전트 신원: 가장 먼저 체감할 변화

MCP 인가는 동의 시점에 브라우저 앞에 사람이 있다고 가정한다. 그런데 호출자는 점점 에이전트가 된다. 자체 신원을 가진 클라우드 워크로드가 자리에 없는 사용자를 대신해 행동하거나, 부모보다 더 좁은 권한을 받아야 하는 서브에이전트를 생성한다. 7월 릴리스 발표에 인용된 Honeycomb은 이미 월간 대화형 쿼리의 거의 20%가 에이전트에서 온다고 말한다. 그런데도 많은 프로덕션 MCP 서버는 복사해 붙인 API 키와 장기 리프레시 토큰에 기대고 있다. 이 작업이 정확히 없애려는 관행이다. 계획은 DPoP를 완성하고 채택하는 것, 그리고 워크로드 신원 연합(SEP-1933), 엔터프라이즈 관리형 인가의 기반인 ID-JAG 권한 부여, RFC 8693 토큰 교환을 통해 표준 위임 경로를 만드는 것이다. IETF OAuth와 WIMSE 워킹 그룹과도 조율한다.

MCP의 인가 모델은 사람이 브라우저에서 접근을 승인하는 상황을 전제로 만들어졌지만, 호출자는 점점 에이전트가 되고 있다. 로드맵은 DPoP와 워크로드 신원 연합·RFC 8693 토큰 교환을 기반으로 한 표준 위임 경로를 우선순위에 두고 있다. 서버가 붙여넣은 API 키나 장기 토큰 없이 에이전트 신원을 알아볼 수 있게 하려는 작업이다.

도구 결과와 점진적 검색

여기서는 두 가지 혼란을 고친다. 첫째, tools/call이 content와 structuredContent를 동시에 반환하는 문제다. 서버 작성자는 클라이언트가 둘 중 무엇을 모델에 보여줄지 알 수 없어 구현이 갈라졌다. 이 계약을 다시 설계한다. 둘째는 규모다. 도구 100개가 있는 서버에 연결하면 사용자가 질문 하나 하기도 전에 모델이 전체 표면 비용을 지불하고, 목록이 길어질수록 도구 선택도 나빠진다. 토큰 비용은 이론이 아니다. Cloudflare의 2026년 2월 실험에서는 엔드포인트 2,500개짜리 API를 MCP 도구 정의로 노출했을 때 약 117만 토큰이 들었고, 코드 호출 방식은 약 1,000토큰이었다. 제안된 답이 점진적 검색이다. 작은 진입점에서 시작해 대화가 좁혀질수록 카탈로그를 더 보여주고, 위의 캐싱 작업과 연결한다. 나는 언제 그 오버헤드 때문에 일반 API가 더 나은 선택인지 이미 썼다. 점진적 검색은 MCP가 그 격차를 줄이려는 시도다.

사양에서 생성하는 SDK

가장 조용한 항목이 오히려 가장 의미심장할 수 있다. 지금은 SDK, 참조 서버, 퀵스타트를 사람이 직접 관리한다. 로드맵은 실험을 하나 한다. 후보 1등급 SDK와 동반 퀵스타트를 사양에서 직접 생성하고, 둘을 적합성 테스트 모음으로 검증한 뒤, 어느 계층은 결정론적 코드 생성이 적합하고 어느 계층은 모델 보조가 적합했는지까지 결과를 공개한다. 잘되면 사양의 모호함은 생성 실패로 드러나고, SDK가 구현해야 할 문서에서 서서히 어긋나는 문제도 줄어든다.

지금 무엇을 해야 하나?

급한 순서대로 네 가지다.

1. 이번 주: 폐기된 표면에 새 작업을 만들지 말자. Roots, Sampling, Logging, 기존 HTTP+SSE 전송은 2026년 7월 28일 사양에서 최소 12개월 유예와 함께 폐기 예정으로 지정됐다. 지금은 작동하지만 새 구현이 선택할 이유는 없다.

2. 이번 달: 서버를 캐시 친화적으로 만들자. 목록 결과에는 이미 ttlMs와 cacheScope가 들어가고 ETag도 온다. 지금 합리적인 캐시 힌트를 내보내는 서버는 마이그레이션 하나를 미리 끝낸 셈이다.

3. 이번 분기: 에이전트의 인증 방식을 감사하자. 운영 중인 MCP 서버가 무인 호출자에게 붙여넣은 API 키나 장기 리프레시 토큰을 신뢰한다면, 에이전트 신원 워킹 그룹이 바로 그 패턴을 대체하려고 존재한다. 자체 위임 체계를 급히 만들기보다 그룹을 따라가는 편이 낫다. 거버넌스 측면은 내가 AI 에이전트 거버넌스에서 다룬 내용과 연결된다.

4. 프로토콜에 영향을 주고 싶다면: 우선순위 영역 안에서 SEP를 쓰자. 관련 Working Group에 먼저 제기하고 그 그룹의 지지를 받아오자. 로드맵과 정렬된 제안은 신속 검토되고, 밖의 제안은 줄을 선다.

하지 말아야 할 것도 두 가지다. 다음 사양을 기다리며 개발을 멈추지 말자. 현재 사양이 안정적인 기반이고, 폐기 정책 덕분에 깨지는 변경은 이제 최소 12개월 전에 알려준다. 그리고 로드맵을 약속처럼 취급하지도 말자. 첫 섹션부터 우선순위가 바뀔 수 있고 목록 밖 작업도 출시될 수 있다고 적혀 있다. 아직 더 초기 단계라면 내가 쓴 첫 MCP 서버 실전 안내와 연결해볼 만한 서버 목록이 실용적인 출발점이다.

2026년 7월 28일 MCP 사양은 Roots, Sampling, Logging, 기존 HTTP+SSE 전송을 최소 12개월 유예와 함께 폐기 예정으로 지정했다. 릴리스 발표는 그 기간 동안 계속 작동한다고 확인하지만, 새 구현이 채택해서는 안 된다.

더 큰 그림

한 발 물러서 보면 공개된 자리에서 성장하는 프로토콜의 모습이다. MCP는 2025년 12월 OpenAI와 Block을 공동 창립자로 두고 Linux Foundation 산하 벤더 중립 Agentic AI Foundation에 기증됐다. 이후 기여자 단계 체계, 기능 수명주기, 폐기 정책이 생겼고 이제 유지관리자의 관심이 어디로 가는지도 공개한다. 확장 프레임워크도 조용하지만 실제 역할을 한다. SEP-2133은 모든 Working Group이 정식 제안 전에 experimental-ext- 저장소에서 실험할 수 있게 해, 코어를 흔들지 않고 아이디어를 시험하게 한다.

앞으로 두 분기 동안 내가 볼 것은 stdio 위의 HTTP가 실제로 들어오는지다. 로컬과 원격 서버가 진짜 하나의 전송으로 수렴하면 “MCP 서버”는 특별한 소프트웨어 종류가 아니라 표준 인터페이스를 가진 웹 서비스가 된다. 프로토콜이 배관 속으로 사라지는 순간이다. 좋은 인프라는 원래 그래야 한다.

자주 묻는 질문

지금 MCP 위에 만들어도 충분히 안정적인가?

그렇다. 다만 마이그레이션 규율은 필요하다. 2026년 7월 28일 사양은 최소 12개월 유예를 둔 공식 폐기 정책을 도입했고, SDK는 호환성을 깨는 변경에 마이그레이션 안내를 함께 제공한다. 프로토콜은 계속 움직이겠지만, 이제 의존하는 기능이 사라지기 1년 전에 알려준다.

MCP 세션은 어떻게 됐나?

2026년 7월 28일 사양에서 폐기됐다. initialize 핸드셰이크와 Mcp-Session-Id 헤더가 사라졌다(SEP-2575, SEP-2567). 이제 모든 요청은 자기 설명적이며 _meta 안에 프로토콜 버전과 클라이언트 기능을 싣는다. 기능을 미리 알고 싶은 클라이언트에는 선택적 server/discover 호출이 핸드셰이크를 대신한다. 어떤 요청이든 라운드 로빈 로드 밸런서 뒤의 어느 인스턴스로 들어가도 된다.

다음 사양이 나올 때까지 기다렸다가 만들어야 하나?

아니다. 로드맵은 향후 6-12개월의 방향을 설명할 뿐 확정 기능 목록이 아니고, 유지관리자도 그렇게 명시한다. 현재 사양은 안정적이고 캐시 가능하며 상태 비저장이다. 그 위에 만들고, 폐기 예정 표면을 피하고, 실제로 당신에게 영향을 줄 두 Working Group을 추적하면 된다.