새로운 MCP 로드맵
오늘 Model Context Protocol(MCP)의 다음 사양 릴리스와 그 이후 계획을 담은 새 로드맵을 공개합니다.
우선순위 영역
로드맵은 다섯 가지 우선순위 영역으로 구성됩니다. 이 가운데 여러 영역은 이전 로드맵에서 향후 과제로 제시했던 작업을 이어받았습니다. 서버가 시작하는 이벤트, 결과 타입 개선, 에이전트 ID 등이 여기에 해당하며, 이제는 각각 독립적인 우선순위로 삼을 만큼 구체화됐습니다. 각 영역은 담당 핵심 유지보수자들과 하나 이상의 Working Group이 맡습니다.
에이전트형 메시징 기본 요소
현대적인 에이전트 워크로드는 더 이상 일반적인 요청·응답 패턴에 들어맞지 않습니다.
루프가 장시간 실행될 수 있고, 서버가 스트리밍 결과를 보낼 수 있으며, 작업이 진행되는 도중 방향을 조정할 필요도 분명해졌습니다.
MCP는 이런 요구에 대응하기 위해 Tasks, subscriptions/listen, 진행 상황 알림을 도입하며 발전해 왔습니다. 작업에 알맞은 기본 요소를 제공하는 데 그치지 않고, 이 요소들이 서로 원활하게 작동하도록 만들고자 합니다.
여기에는 클라이언트가 결과를 확인하려고 계속 폴링하지 않아도 되게 하는 웹훅과 채널 등 서버 시작 이벤트, Agents·Transports·Triggers & Events Working Group 전반의 조합 방식 검토, Tasks 확장 기능(SEP-2663)을 사양에 포함할 수 있을 만큼 발전시키는 작업이 포함됩니다.
HTTP 네이티브 전송 방식의 통합과 강화
2026-07-28 릴리스부터 원격 MCP 서버는 다른 HTTP 워크로드와 동일하게 다룰 수 있습니다. 개발자와 조직이 기존 API와 서비스에 사용하는 어떤 인프라에서도 MCP 서버를 손쉽게 호스팅하고 운영할 수 있게 된 것입니다. 이 접근 방식은 규모가 커져도 안정적으로 작동한다는 점이 입증됐습니다. 이제 stdio를 통해 Streamable HTTP로 통신하는 로컬 서버를 비롯한 다른 배포 방식까지 지원 범위를 넓히려 합니다. 전송 방식을 하나로 통합하면 MCP 서버와 클라이언트 개발을 한층 더 단순화할 수 있습니다.
에이전트 ID와 엔터프라이즈 수준의 보안
현재 MCP 인증·인가는 사용자가 브라우저에서 접근을 승인하는 방식을 중심으로 설계돼 있습니다. 대화형 클라이언트에는 적합하지만, 이제는 자체 ID를 지닌 클라우드 워크로드로 실행되거나, 자리에 없는 사용자를 대신해 행동하거나, 하위 에이전트에 더 제한된 권한을 위임하는 에이전트가 호출 주체가 되는 사례가 늘고 있습니다. MCP 서버가 복사해 붙여 넣은 API 키나 장기 토큰 대신 기존 표준을 기반으로 이런 에이전트 ID를 인식하고 신뢰할 수 있도록 표준화된 방법을 마련하려 합니다.
여기에는 Demonstrating Proof of Possession(DPoP)을 확정하고 도입을 촉진하는 작업이 포함됩니다. 또한 Workload Identity Federation, Enterprise-Managed Authorization의 기반인 ID-JAG grant, 표준 토큰 교환을 통해 에이전트 ID와 권한 위임에 관한 명확한 권장 경로를 정의할 예정입니다. IETF OAuth와 WIMSE Working Group을 비롯한 OAuth 표준화 기구와의 협력도 계속 확대해, 기반 표준이 에이전트 ID에 필요한 구성 요소를 갖추며 발전하도록 돕겠습니다.
기본 요소 개선
도구 호출은 대부분의 개발자가 MCP를 처음 접하는 부분이며, 프로토콜이 운영되는 동안 안정적으로 제 역할을 해왔습니다. 다만 결과 처리에는 다소 부족한 점이 있습니다. tools/call 응답은 같은 출력을 여러 형식으로 전달할 수 있지만, 현재 서버 개발자는 특정 클라이언트가 이 가운데 어떤 형식을 모델에 제공할지 알 방법이 없습니다. 하나의 명확한 계약을 표준으로 정해 이 문제를 해결하려 합니다.
기본 요소와 관련해 해결해야 할 또 다른 과제는 계속 커지는 규모입니다. 도구가 100개인 서버에 연결하면 사용자가 질문 하나를 하기도 전에 모델이 전체 도구 목록을 처리해야 하며, 목록이 길어질수록 도구 선택의 정확도도 떨어지는 경향이 있습니다. 이를 해결하기 위해 서버가 작은 진입점만 먼저 제공하고, 대화 범위가 좁아질수록 카탈로그를 더 많이 공개할 수 있도록 점진적 탐색 기능 개발을 시작합니다.
SDK 개발자 경험 개선
개발자는 SDK를 통해 MCP를 경험합니다. SDK의 사용 편의성과 사양 준수를 개선하고, 지원하는 모든 플랫폼과 언어에서 직관적으로 사용할 수 있도록 충실한 문서를 제공하는 데 투자하고 있습니다. 많은 개발자가 에이전트에 라이브러리를 지정해 MCP 클라이언트와 서버를 만드는 지금은 이 작업이 더욱 중요합니다. API가 명확하고 문서가 정확해야 최소한의 시행착오로 제대로 작동하는 코드를 만들 수 있기 때문입니다.
제안 우선순위
이러한 우선순위 영역에 속하는 Specification Enhancement Proposal(SEP)은 신속하게 검토되며 채택될 가능성도 가장 높습니다. 영역 밖의 제안이 자동으로 거절되는 것은 아니지만, 유지보수자가 검토에 쓸 수 있는 시간은 한정돼 있으므로 이 영역들을 먼저 살핍니다.
SEP를 준비하고 있다면 어느 우선순위 영역에 속하는지 확인하고, 관련 Working Group에 제안한 뒤 구성원들과 함께 내용을 구체화해 주세요. 로드맵의 각 영역에는 담당 핵심 유지보수자가 명시돼 있으며, 기여하려는 사람은 누구나 Discord에서 이들에게 연락할 수 있습니다. 이 로드맵을 뒷받침하는 제안을 커뮤니티와 함께 검토하고 발전시켜 나가기를 기대합니다.
참여 방법
위의 모든 우선순위 영역에는 이미 Working Group이 있거나 새로 구성되고 있으며, 어느 그룹이든 더 많은 기여자를 기다리고 있습니다. 다음과 같은 방법으로 참여할 수 있습니다.
Working Group 또는 Interest Group 참여: Working and Interest Groups 페이지와 커뮤니티 채널을 확인하세요.
SEP 제안 또는 의견 남기기: SEP 가이드라인을 읽은 뒤 새 제안을 작성하거나 기존 제안에 의견을 남기세요.
실험적 확장 기능 시작: SEP-2133에 따라 모든 WG와 IG는 정식 SEP를 제출하기 전에
experimental-ext-저장소에서 실험할 수 있습니다.직접 기여: 기여 가이드에서 사양, SDK, 도구에 기여하는 방법을 확인할 수 있습니다.
여러분과 함께 MCP를 성장시키고 발전시켜 나가기를 기대합니다!
source https://blog.modelcontextprotocol.io/posts/mcp-roadmap/
HN에서는 MCP가 독립된 프로토콜로 얼마나 많은 문제를 맡아야 하는지를 두고 판단이 갈렸다. HTTP 중심으로 전송 방식을 통합하는 방향은 환영받았지만, 초기에는 stdio와 스트리밍, 인증, 상태 관리의 조합을 구현체마다 다르게 지원했다. 기존 연동을 사양에 맞춰 거듭 손본 개발자들은 기능 확대보다 단순성과 호환성을 먼저 요구했다.
여러 개발자는 REST API와 OpenAPI 명세, skills.md나 코드 실행만으로도 충분하다고 봤다. OpenAPI를 단일 원천으로 두고 MCP 도구를 생성하거나, 에이전트가 명세에서 필요한 API만 찾아 호출하도록 만든 사례도 나왔다. 반면 MCP의 가치는 호출 형식보다 운영에 있다는 설명도 힘을 얻었다. 사용자에게 허용된 도구만 노출하고, 도구 설명과 구현을 함께 갱신하며, 비개발자도 마켓플레이스에서 연결할 수 있다는 점이다.
인증과 권한 관리는 단순화하기 어려운 영역이었다. 개인 자동화에는 비밀 저장소에 둔 장기 토큰으로 충분할 수 있다. 그러나 기업에서는 에이전트와 하위 에이전트의 권한을 나누고 승인, 철회, 갱신, 감사 주체까지 관리해야 한다. 이런 조건에서는 복잡한 표준이 필요하다는 반론이 설득력을 얻었다. 다만 서버와 클라이언트가 고급 인증 기능을 얼마나 일관되게 지원할지는 여전히 불확실하다.
결국 도입 여부는 기능 수가 아니라 운영 조건으로 판단해야 한다. 제한된 자동화나 정기 작업에는 기존 API와 코드 실행이 더 단순하다. 반대로 도구의 자동 배포와 갱신, 세밀한 권한 통제, 비개발자용 연결 경험이 중요하다면 MCP가 비용을 상쇄할 수 있다. 생산 환경에 적용하기 전에는 필요한 사양 범위와 클라이언트 호환성, 컨텍스트 사용량, 변경 대응 책임부터 확인해야 한다.
