MCP 확장(Extensions) 개요

MCP 확장(Extensions) 개요

MCP 확장은 핵심 프로토콜을 넘어서는 기능을 정의하는 스펙의 선택적 추가 항목이에요. 모듈형이거나(예: 인증 같은 독립 기능) 특화됐거나(예: 산업별 로직) 실험적(잠재적으로 핵심에 포함되도록 배양 중인 기능)일 수 있어요. 확장은 io.modelcontextprotocol/oauth-client-credentials처럼 {벤더-프리픽스}/{확장-이름} 형식의 고유 식별자로 구분되며, 공식 확장은 io.modelcontextprotocol 프리픽스를 사용해요.

출처: 공식문서 — Extensions Overview

확장이란

MCP 확장은 선택적으로 추가하는 기능이라 기본적으로 비활성화돼 있고 개발자가 명시적으로 동의(opt-in)해야만 동작해요. 확장은 핵심 프로토콜과 별개로 독립적으로 발전하며, 호환성을 지키기 위해 기존 확장을 바꿔야 한다면 새 식별자를 만들기보다 기능 플래그나 설정 객체 내 버전ing을 쓰는 게 좋아요.

호환성을 깨는 변경(breaking change) 은 기존 구현이 실패하거나 잘못 동작하게 만드는 모든 수정이에요. 필드 삭제·이름 변경, 필드 타입 변경, 기존 동작의 의미 변경, 새 필수 필드 추가가 여기 해당돼요.

공식 확장 저장소

공식 확장은 Model Context Protocol GitHub 조직 안에서 ext- 프리픽스가 붙은 저장소에 살아요.

  • MCP 인증 확장: 핵심 스펙을 넘어서는 추가 인증 메커니즘. OAuth Client Credentials(머신 간 인증)와 Enterprise-Managed Authorization(중앙 집중식 접근 제어)을 포함.
  • MCP Apps: 대화형 MCP 클라이언트에서 대화 안에 차트·폼·비디오 플레이어 같은 상호작용 UI를 표시하게 해주는 확장.
  • MCP Tasks: 폴링·진행 중 입력·내구성 있는 핸들을 갖춘 장기 실행 작업의 비동기 실행.

실험적 확장은 공식 SEP 제출 전에 워킹 그룹·관심 그룹이 개념을 프로토타입 할 수 있는 배양 경로예요. experimental-ext- 프리픽스 저장소에 있으며, 공식 승격은 표준 SEP 과정(Extensions Track)을 거쳐요.

확장 만들기

공식 확장의 수명주기는 SEP 기반 프로세스를 따라요. 제안(Propose, Extensions Track 타입의 SEP 생성) → 구현(공식 SDK에 참조 구현 1개 이상 — SEP 검토 전 필수) → 검토(Core Maintainers가 최종 권한) → 게시(승인 후 확장 저장소에 PR) → 채택(다른 클라이언트·서버·SDK가 구현) 순서예요.

확장 스펙은 RFC 2119 언어(MUST, SHOULD, MAY)를 써야 하고, 관련 워킹 그룹이나 관심 그룹이 있어야 해요. SDK는 확장을 구현할 수도 있지만 프로토콜 준수에 필수는 아니며, SDK 유지보수자가 지원 범위를 정해요.

협상(Negotiation)

클라이언트와 서버는 각자의 capability 선언에서 extensions 필드로 확장 지원을 광고해요. 클라이언트는 각 요청의 _meta 안 io.modelcontextprotocol/clientCapabilities에, 서버는 server/discover 응답의 capabilities에 확장을 선언해요. 각 확장은 자신의 설정 객체 스키마를 정의하며, 빈 객체는 설정이 없음을 뜻해요.

한쪽만 확장을 지원하면 확장을 지원하는 쪽은 핵심 프로토콜 동작으로 폴백하거나(필수 확장이라면) 적절한 오류로 요청을 거부해야 해요. 예를 들어 UI 강화 도구를 제공하는 서버는 UI 확장을 지원하지 않는 클라이언트에도 의미 있는 텍스트 콘텐츠를 돌려줘야 하죠.

더 알아보기