모델 컨텍스트 프로토콜(MCP) 코어 메인테이너들이 커뮤니티 메인테이너 및 워킹그룹과 함께 다음 사양(스펙) 릴리스와 그 이후를 아우르는 갱신된 로드맵을 공개했다. 이번 로드맵은 향후 몇 달간의 프로토콜 작업 방향을 다섯 개 우선순위 영역으로 정리했으며, 각 영역마다 책임을 지는 코어 메인테이너와 하나 이상의 워킹그룹이 배정돼 있다. 주목할 점은 이전 로드맵에서 '먼 과제'로만 언급됐던 서버 발신 이벤트, 결과 타입 개선, 에이전트 정체성 같은 항목이 이제 충분히 성숙해 정식 우선순위로 올라왔다는 사실이다. 즉 이번 문서는 새 아이디어의 나열이라기보다, 실제 구현 논의가 무르익은 과제들을 사양 편입 단계로 끌어올리는 성격이 강하다.
요청-응답을 넘어서는 에이전트 워크로드
첫 번째 축은 오늘날의 에이전트 작업이 더 이상 단순한 요청-응답 패턴에 들어맞지 않는다는 문제의식에서 출발한다. 루프가 길게 돌고, 서버가 스트리밍 결과를 밀어내며, 작업 도중에 방향을 바꿀 필요가 생긴다. MCP는 이에 대응해 Tasks, 구독(subscriptions/listen), 진행 알림(progress notifications) 같은 프리미티브를 이미 도입해 왔다. 이번 작업의 초점은 개별 기능을 추가하는 데 그치지 않고 이들이 서로 잘 맞물려 작동하도록 만드는 데 있다. 구체적으로는 클라이언트가 결과를 얻기 위해 폴링에 매달리지 않도록 하는 웹훅·채널 기반의 서버 발신 이벤트, Agents·Transports·Triggers & Events 워킹그룹을 가로지르는 조합(composition) 검토, 그리고 Tasks 확장(SEP-2663)을 사양 본문으로 편입할 만큼 성숙시키는 일이 포함된다.
두 번째 축인 전송 계층은 2026-07-28 릴리스가 가져온 변화 위에 서 있다. 이 릴리스로 원격 MCP 서버는 여느 HTTP 워크로드와 다를 바 없는 존재가 됐고, 개발자와 조직이 기존 API·서비스를 굴리던 인프라 위에 그대로 얹어 운영할 수 있게 됐다. 로드맵은 이 접근이 확장성을 입증했다고 보고, stdio 위에서 Streamable HTTP를 말하는 로컬 서버를 비롯한 다른 배포 형태까지 같은 전송 방식으로 통일하려 한다. 전송을 하나로 모으면 서버와 클라이언트 개발 모두를 한층 단순하게 만들 수 있다는 계산이다.
사람 승인에서 에이전트 정체성으로
세 번째 축은 실무자에게 특히 무게가 큰 인가(authorization) 영역이다. 현재 MCP 인가는 브라우저에서 사람이 접근을 승인하는 방식을 전제로 설계돼 있는데, 이는 대화형 클라이언트에는 잘 맞지만 점점 늘어나는 호출자가 자체 정체성을 가진 클라우드 워크로드형 에이전트라는 현실과 어긋난다. 자리에 없는 사용자를 대신하거나, 하위 에이전트에게 더 좁은 권한을 위임하는 경우가 대표적이다. 로드맵은 붙여넣은 API 키나 수명이 긴 토큰 대신 기존 표준 위에서 서버가 에이전트 정체성을 표준적으로 인식하고 신뢰할 방법을 목표로 삼는다. 이를 위해 소유 증명(DPoP)을 확정·확산하고, 워크로드 아이덴티티 페더레이션, 엔터프라이즈 관리형 인가의 기반이 되는 ID-JAG 그랜트, 표준 토큰 교환을 통해 에이전트 정체성과 위임의 정형화된 경로를 정의한다. 동시에 IETF OAuth·WIMSE 워킹그룹 등 표준화 기구와의 협력도 이어간다.
네 번째 축은 개발자가 가장 먼저 마주하는 도구 호출(tool calling)이다. 프로토콜의 수명 내내 잘 버텨온 부분이지만, 결과 처리에서 빈틈이 드러난다. tools/call 응답이 같은 출력을 둘 이상의 형태로 담을 수 있는데도, 서버 개발자는 특정 클라이언트가 어느 형태를 모델에게 보여줄지 알 방법이 없다. 로드맵은 이를 하나의 명확한 계약으로 표준화해 해소하려 한다. 또 다른 과제는 규모다. 도구가 100개인 서버에 연결하면 사용자가 질문을 던지기도 전에 모델이 그 표면 전체를 비용으로 치르고, 목록이 길어질수록 도구 선택 품질도 떨어진다. 이에 서버가 작은 진입점만 먼저 제시하고 대화가 좁혀질수록 카탈로그를 점진적으로 드러내는 '점진적 발견(progressive discovery)' 작업이 시작된다.
다섯 번째 축은 개발자가 MCP를 실제로 체험하는 통로인 SDK다. 로드맵은 지원하는 모든 플랫폼과 언어에서 SDK의 사용성, 사양 적합성, 직관성과 문서 품질에 투자하겠다고 밝힌다. 많은 개발자가 라이브러리를 에이전트에게 가리키는 방식으로 MCP 클라이언트와 서버를 만드는 지금, 명확한 API와 정확한 문서가 코드의 동작 여부를 좌우한다는 점에서 이 투자의 비중은 오히려 커졌다.
실무 관점에서 이 로드맵은 우선순위 신호로 읽는 편이 유용하다. 다섯 영역 안에 드는 사양 개선 제안(SEP)은 신속 검토 대상이 되고 채택 가능성도 가장 높은 반면, 벗어난 제안은 자동 반려되진 않아도 희소한 메인테이너 검토 시간에서 뒤로 밀린다. 따라서 기여를 염두에 둔 팀이라면 자신의 제안이 어느 영역에 속하는지부터 가르고 해당 워킹그룹과 Discord에서 함께 다듬는 편이 현실적이다. 다만 로드맵 자체는 방향과 책임 구조를 제시할 뿐 구체적 릴리스 일정이나 최종 사양 문구를 확정하지 않는다는 한계도 분명하다. DPoP나 Tasks처럼 사양 편입을 앞둔 항목이라도 실제 클라이언트·서버 구현이 뒤따라야 효력이 생기는 만큼, 당장 아키텍처를 갈아엎기보다 전송 통일과 에이전트 인가라는 두 흐름이 자사 배포·인증 설계에 어떻게 닿을지 지켜보며 준비하는 접근이 합리적이다.