MCP 새 로드맵, 서버 상태 없이 수평 확장 지원

지난 3월 공개된 로드맵은 전송 진화와 확장성, 에이전트 통신, 거버넌스 성숙, 엔터프라이즈 준비라는 4개 우선순위를 제시했어요. 메인테이너들은 이 네 영역 모두에서 지난 5개월간 상당한 진전을 이뤘다고 밝혔는데요, 대부분의 변화가 2026-07-28 스펙 릴리스에 담겼고 개발자들은 이미 SDK와 문서에서 이를 접했을 가능성이 커요.

세션 제거 외에도 클라이언트가 서버에 연결하기 전에 server/discover를 호출해 지원 버전과 기능을 먼저 파악할 수 있게 됐고, 목록 조회 결과도 캐싱이 가능해졌어요(SEP-2549). 에이전트 통신 쪽에서는 초기 도입자들의 피드백을 반영해 Tasks 기능을 공식 확장(SEP-2663)으로 옮겼고, 서버가 먼저 요청을 보내던 방식 대신 상태 없는 서버에서도 작동하는 Multi Round-Trip Requests 패턴(SEP-2322)이 새로 들어왔어요.

거버넌스와 보안도 손봤어요

거버넌스 쪽에서는 Contributor Ladder(기여자 등급 체계)를 공식 채택했고, 각 워킹그룹이 자기 영역의 SEP(스펙 개선 제안)를 직접 심사하도록 바뀌었어요. 스펙에도 정식 기능 수명주기와 폐기 정책이 생겼고, 2026-07-28의 기능 폐기가 이 정책을 처음 따른 사례라고 해요.

엔터프라이즈 준비 작업은 지난 주기 동안 보안에 집중됐어요. 발급자 검증, 발급자에 묶인 클라이언트 자격 증명, 그리고 클라이언트 등록 방식으로 Client ID Metadata Documents(CIMD)를 선호 경로로 도입했고요. 확장 형태로 제공되던 Enterprise-Managed Authorization도 이번에 안정 버전이 됐어요.

새 로드맵은 5개 우선순위로 다시 짜였어요

우선순위	핵심 내용
에이전트 통신	서버가 먼저 알리는 이벤트(웹훅·채널) 도입, Tasks 확장을 정식 스펙으로 승격
전송 방식 통일	원격 MCP 서버를 일반 HTTP 워크로드처럼 다루는 방식을 로컬 서버(stdio 위 Streamable HTTP)까지 확장
에이전트 정체성	브라우저 승인 대신 DPoP·Workload Identity Federation·표준 토큰 교환으로 에이전트를 인증
툴 콜링·결과 처리	도구 호출 응답 형식을 하나의 계약으로 표준화, 도구 목록이 많을 때의 점진적 발견 방식 도입
SDK	여러 플랫폼·언어에서 SDK의 사용성과 스펙 준수도, 문서 품질을 개선

특히 에이전트 정체성 항목이 눈에 띄는데요, 지금 MCP 인증은 사람이 브라우저에서 직접 접근을 승인하는 방식에 기대고 있어요. 하지만 클라우드에서 자체 정체성을 가지고 돌아가는 에이전트나, 사용자가 자리에 없는 상태에서 대신 작업하는 에이전트, 하위 에이전트에 좁은 권한을 위임하는 경우가 늘면서 이 방식만으로는 부족해졌다고 해요. 이를 위해 Demonstrating Proof of Possession 표준의 도입을 마무리하고, Workload Identity Federation 관련 논의를 바탕으로 에이전트 신원과 권한 위임 경로를 정의할 계획이라고 밝혔어요. IETF OAuth와 WIMSE 워킹그룹과의 협업도 계속 넓혀갈 예정이고요.

SEP를 제안하려면 이렇게 하면 돼요

이 다섯 우선순위 안에 들어가는 SEP는 심사가 빨라지고 채택 가능성도 높아져요. 범위 밖 제안이 자동으로 거절되는 건 아니지만, 메인테이너들의 검토 시간이 한정된 만큼 우선순위 영역에 먼저 배정된다고 해요. SEP를 준비 중이라면 어느 우선순위 영역에 속하는지 먼저 파악하고, 해당 워킹그룹에 제안을 올려 함께 다듬는 과정을 거치면 돼요. 각 영역을 맡은 코어 메인테이너 이름이 로드맵 페이지에 명시돼 있고, 참여를 원하는 사람은 Discord로 연락할 수 있다고 안내하고 있어요.

에디터의 시선

MCP가 3월 로드맵에서 "전송 확장성"이라는 다소 막연한 목표를 내걸었던 걸 생각하면, 이번에 세션과 핸드셰이크를 아예 없애버린 건 꽤 과감한 결정이에요. 상태를 유지하는 서버는 로드밸런서 뒤에 여러 대를 놓기가 까다롭고, 연결이 끊기면 진행 중이던 작업 맥락도 함께 날아가는 문제가 있었거든요. 이걸 프로토콜 차원에서 걷어내고 일반 HTTP 워크로드처럼 다룰 수 있게 만든 건, MCP 서버를 운영하는 회사 입장에서 인프라 비용과 복잡도를 동시에 낮추는 선택이에요.

지난 8월 초 오픈AI가 AWS·Cursor·GitHub와 함께 내놓은 Agent Plugins 표준도 MCP 서버 설정을 패키징하는 걸 지원했는데, MCP가 이렇게 계속 무상태·경량화 방향으로 스펙을 다듬는 건 그 표준들이 딛고 설 바닥을 더 단단하게 만드는 작업이라고 볼 수 있어요. 프로토콜 하나가 안정되면 그 위에 올라가는 도구와 표준의 숫자가 늘어나는 흐름을 여러 차례 봐왔으니까요.

국내에서 MCP 서버를 직접 운영하거나 SDK를 붙여 쓰는 팀이라면, 지금 당장 할 일은 두 가지예요. 하나는 07-28 릴리스에 포함된 세션 제거와 server/discover 변경이 기존 서버 코드에 미치는 영향을 점검하는 것이고, 다른 하나는 에이전트 정체성 쪽 작업을 미리 눈여겨보는 거예요. API 키를 그대로 붙여넣는 지금 방식은 조만간 DPoP나 토큰 교환 기반 인증으로 대체될 가능성이 높은데, 인증 체계를 바꾸는 작업은 항상 늦게 시작할수록 마이그레이션 비용이 커지거든요.

앞으로 몇 달 안에는 서버가 먼저 이벤트를 밀어주는 웹훅·채널 방식과, 도구가 많은 서버에서 필요한 부분만 점진적으로 드러내는 발견 방식이 스펙 초안 형태로 먼저 나올 것 같아요. 두 작업 모두 지금의 요청-응답 패턴만으로는 감당이 안 되는 장시간 에이전트 루프를 겨냥하고 있어서, MCP를 실제 프로덕션에 쓰는 팀이라면 이 부분의 SEP 논의를 따라가 볼 만해요.