MCP 새 로드맵, 장기 작업과 권한 위임에 집중해요

MCP 새 로드맵, 장기 작업과 권한 위임에 집중해요

AI 뉴스 썸네일

MCP가 다음 명세 릴리스와 이후 수개월 동안 다룰 개발 방향을 공개했어요. 오래 걸리는 작업을 제어하는 메시징 구조, 에이전트 신원과 권한 위임, 많은 도구를 효율적으로 찾는 방식이 우선 과제에 들어갔어요. 1

핵심 요약

구분	내용
메시징	서버가 결과를 먼저 보내고 실행 중인 작업을 제어할 수 있도록 Tasks, 구독, 진행 알림을 정리해요.
전송 방식	원격 서버에서 쓰는 Streamable HTTP 모델을 로컬 실행 환경까지 넓혀요.
신원과 권한	클라우드에서 동작하는 에이전트와 하위 에이전트의 신원·권한 위임 방식을 표준화해요.
도구 탐색	처음부터 모든 도구 정의를 읽지 않고 필요한 목록을 점차 공개하는 방식을 추진해요.
SDK	언어별 API와 문서를 다듬고 명세 적합성 검사를 강화해요.

1. MCP가 요청과 응답을 넘어 장기 작업을 다뤄요

MCP 유지 관리자들은 새 로드맵을 5개 우선 영역으로 나눴어요. 에이전트 메시징, HTTP 중심 전송 통합, 에이전트 신원과 기업 보안, MCP 기본 기능 개선, SDK 개발 경험이 그 대상이에요. 각 영역은 담당 유지 관리자와 워킹 그룹이 맡아요. 2

실행 중인 작업에 개입할 수 있어요

오래 걸리는 작업은 한 번 요청하고 한 번 응답받는 구조만으로 다루기 어려워요. 서버가 중간 결과를 보내거나 사용자가 실행 방향을 바꿔야 할 수 있어요. MCP는 이미 Tasks, `subscriptions/listen`, 진행 알림을 도입했어요. 새 로드맵에서는 이 기능들이 서로 일관되게 작동하도록 정리해요.

728x90

클라이언트가 결과를 반복 조회하지 않아도 되도록 Webhook과 Channel을 이용한 서버 주도 이벤트도 검토해요. Tasks 확장안인 SEP-2663을 다듬어 정식 명세에 넣는 작업도 이어가요. 이 구조가 자리 잡으면 긴 데이터 처리나 여러 단계의 코딩 작업에서 상태 확인과 중간 제어를 같은 규칙으로 구현할 수 있어요. 2

로컬과 원격 전송 방식을 HTTP 중심으로 맞춰요

2026년 7월 28일 릴리스부터 원격 MCP 서버는 일반 HTTP 서비스와 비슷한 인프라에서 운영할 수 있게 됐어요. 유지 관리자들은 Streamable HTTP 방식을 로컬 서버까지 넓힐 계획이에요. 로컬 프로세스가 stdio를 쓰더라도 전송 모델은 HTTP 중심 구조로 맞추려 해요.

서버와 클라이언트가 배포 형태마다 다른 처리 방식을 유지하면 구현과 시험 범위가 늘어요. 하나의 전송 모델을 공유하면 로컬 개발과 원격 운영 사이의 차이를 줄일 수 있어요. 다만 로드맵은 방향을 설명한 문서예요. 구체적인 전환 시기와 호환 방식은 이후 명세와 제안서에서 확인해야 해요.

사람 없는 실행 환경에도 신원과 권한이 필요해요

현재 MCP 인증은 사용자가 브라우저에서 접근을 승인하는 대화형 흐름에 맞춰져 있어요. 클라우드 워크로드로 실행되는 에이전트는 사용자가 자리에 없을 때 대신 작업할 수 있어요. 하위 에이전트에는 더 좁은 권한만 넘겨야 할 수도 있어요.

새 로드맵은 API 키나 장기 토큰을 복사하는 방식보다 표준화된 신원 확인과 권한 위임을 선호해요. DPoP 도입을 마무리하고 Workload Identity Federation, ID-JAG 권한 부여, 표준 Token Exchange를 조합하는 경로를 다뤄요. IETF OAuth와 WIMSE 워킹 그룹과의 협력도 이어가요. 기업에서 MCP를 운영한다면 도구 연결 개수보다 누가 어떤 권한으로 호출했는지 기록하는 설계가 먼저 필요해져요. 2

도구가 많아질수록 필요한 목록만 보여 줘요

한 서버가 100개 도구를 제공하면 모델은 사용자의 질문을 받기 전부터 전체 정의를 읽어야 해요. 입력 토큰 비용이 늘고 비슷한 도구 중 하나를 고르는 일도 어려워질 수 있어요. MCP는 작은 진입점만 먼저 공개하고 대화 범위가 좁아질 때 관련 도구 목록을 추가하는 Progressive Discovery를 추진해요.

`tools/call` 결과 계약도 손봐요. 현재는 같은 결과를 여러 형태로 담을 수 있어서 서버 개발자가 어떤 값이 모델에 전달될지 예측하기 어려울 수 있어요. 유지 관리자들은 하나의 명확한 결과 계약으로 모호함을 줄이려 해요. SDK 쪽에서는 언어별 API와 문서를 다듬고 명세 적합성 검사를 강화할 계획이에요. 2

왜 중요한가요

이번 로드맵은 MCP 구현자가 곧바로 사용할 새 기능 목록이 아니에요. 앞으로 어떤 제안이 먼저 검토되고 유지 관리자의 시간이 어디에 배정될지를 보여 줘요. 해당 5개 영역에 속한 Specification Enhancement Proposal은 우선 검토를 받아 채택될 여지가 커져요. 2

개발팀에는 설계 기준이 더 구체적으로 보이기 시작했어요. 오래 실행되는 작업은 상태 조회와 취소·개입 방식을 함께 설계해야 해요. 기업용 연결에서는 사람의 브라우저 승인만 가정하기 어렵고, 실행 주체의 신원과 위임 범위를 분리해야 해요. 도구가 많다면 전체 목록을 고정으로 넣는 대신 발견 단계와 결과 형식을 점검할 필요가 있어요.

아직 명세로 확정되지 않은 항목도 많아요. 기존 stdio 서버를 언제 어떻게 옮길지, Progressive Discovery가 어떤 API로 제공될지, 각 SDK가 같은 시점에 지원할지는 후속 문서가 나와야 알 수 있어요. 지금은 제품 코드를 서둘러 바꾸기보다 Tasks, 인증, 도구 목록을 어디에서 가정하고 있는지 확인해 두는 편이 현실적이에요.

참고 자료

1. 새로운 MCP 로드맵 - 앞으로 집중할 5가지 영역 — GeekNews
2. The New MCP Roadmap — Model Context Protocol Blog