Model Context Protocol(MCP) 관리팀은 2026년 8월 22일 다음 명세 릴리스와 그 이후에 집중할 다섯 영역을 공개했다. 장시간 실행되는 작업의 메시지 방식, HTTP 전송 통합, 에이전트 신원과 보안, 도구 결과·탐색 방식, SDK 사용성이 대상이다. 이 목록은 새 도구를 더 붙이는 계획처럼 보이지만, 실제 도입팀에는 먼저 운영 경계를 정하라는 신호에 가깝다.
에이전트가 도구를 호출한다는 사실만으로 업무 책임이 이동하지는 않는다. 고객 데이터 조회, 결제 요청, 계약 변경처럼 결과가 남는 일은 누가 승인하고, 어느 권한으로 실행하며, 실패하면 누가 중단·재시도할지를 호출 이전에 정해야 한다. MCP는 그 경계 안에서 외부 시스템을 연결하는 통로로 쓰는 편이 안전하다.
긴 작업에서는 누가 상태를 관리해야 하나
로드맵은 요청과 응답 한 번으로 끝나지 않는 에이전트 작업을 첫 우선순위로 둔다. Tasks, subscriptions/listen, 진행 알림을 함께 다루고, 서버가 웹훅과 채널로 완료를 알리는 서버 주도 이벤트도 추진한다. 클라이언트가 결과를 계속 조회하는 폴링만으로는 긴 작업의 상태, 취소, 오류를 다루기 어렵기 때문이다.
이 변화가 곧 서버에 업무 통제권을 넘긴다는 뜻은 아니다. 서비스는 요청 목적과 사용자 승인, 작업 ID, 재시도 한도를 기록하고, MCP 서버는 주어진 범위에서 실행 상태를 전달하는 식으로 나누는 편이 낫다. 실패한 배송 주소 변경을 자동으로 다시 실행할지, 사람에게 돌릴지는 도구 서버가 아니라 업무 서비스를 운영하는 쪽의 판단이다.
사람의 브라우저 승인을 에이전트 권한으로 바꾸면 무엇이 달라지나
현재 MCP 인가는 사람이 브라우저에서 접근을 승인하는 흐름을 중심으로 한다. 로드맵은 클라우드에서 실행되는 에이전트, 부재중인 사용자를 대신하는 작업, 하위 에이전트에 더 좁은 권한을 위임하는 경우까지 다룬다. 장기 API 키를 붙여 두는 대신 기존 표준을 바탕으로 에이전트 신원을 인식하고 신뢰하는 방식이 목표다.
여기에는 DPoP(Demonstrating Proof of Possession)의 마무리와 확산, Workload Identity Federation, Enterprise-Managed Authorization의 ID-JAG grant, 표준 토큰 교환이 포함된다. 도입팀의 설계 질문은 단순하다. 이 에이전트가 누구를 대신하는지, 어떤 도구와 데이터까지 접근하는지, 하위 작업에 넘길 권한은 어디까지인지다. 답을 도구 설명문에만 넣지 말고 서비스의 권한 정책과 감사 기록에 남겨야 한다.
도구 목록이 커질수록 먼저 줄여야 할 것은 노출 범위다
MCP는 tools/call 결과를 하나의 명확한 계약으로 정리하려 한다. 더 큰 문제는 도구 수다. 서버에 도구가 100개 있으면 사용자가 질문하기 전부터 모델은 그 전체 표면의 비용을 치르고, 선택 품질도 목록이 길수록 나빠진다고 로드맵은 짚는다. 이를 위해 작은 진입점을 먼저 내고, 대화가 구체화될 때 카탈로그를 더 보여 주는 점진적 탐색을 시작한다.
운영에서는 이 구조를 권한 필터와 함께 봐야 한다. 예를 들어 고객 지원 에이전트에는 조회·초안 작성 도구만 첫 목록으로 열고, 환불·계약 변경 도구는 해당 업무의 승인과 역할 검사를 통과한 뒤에만 발견되게 하는 식이다. 이 방식은 모델의 선택 부담을 줄이는 동시에 처음부터 호출할 수 있는 행동의 범위도 줄인다.
전송 통합과 SDK 개선은 운영 비용을 어떻게 바꾸나
2026년 7월 28일 릴리스 뒤 원격 MCP 서버는 일반 HTTP 작업처럼 호스팅하고 운영할 수 있게 됐다. 로드맵은 로컬 서버도 stdio 위에서 Streamable HTTP를 쓰도록 넓혀 하나의 전송 모델로 통합하려 한다. 서버와 클라이언트가 전송 경로마다 별도 구현을 유지하는 비용을 낮추려는 방향이다.
SDK는 명세 적합성, 문서, 언어별 사용성을 개선한다. 에이전트에게 라이브러리를 맡겨 코드를 만드는 경우가 늘면서, 모호한 API나 오래된 문서는 실행 실패로 바로 이어진다. 프로토콜이 통일되더라도 실제 운영에서 필요한 권한 검사, 감사 로그, 재시도 정책, 결과 보관 정책은 각 서비스가 계속 책임져야 한다.
공식 로드맵은 향후 6~12개월의 방향을 설명하며, 우선순위와 산출물은 바뀌거나 미뤄질 수 있다고 명시한다. 따라서 지금은 확정되지 않은 확장을 기다리기보다, 현재 도구로도 필요한 업무 경계를 먼저 좁게 정의해 두는 편이 낫다. 새 메시지·신원·탐색 기능이 명세에 들어오면 그 경계 안에서 교체하거나 보강할 수 있다.
출처: Model Context Protocol Blog, “The New MCP Roadmap” (2026-08-22); Model Context Protocol, “Roadmap” (2026-08-22 확인).