MCP Apps Extension으로 보는 인터랙티브 MCP UI 개념 정리

핵심 요약

MCP Apps Extension은 MCP 서버가 직접 인터랙티브 UI를 제공할 수 있게 표준을 만드는 제안이다. HTML 기반 UI를 ui:// 리소스로 선언하고, MCP 프로토콜(JSON-RPC)을 통해 호스트와 양방향 통신하며, 보안·호환성을 고려해 점진적으로 도입할 수 있게 설계됐다.

MCP Apps Extension이란 무엇인가

MCP Apps Extension은 모델 컨텍스트 프로토콜(MCP)에 "앱 수준의 인터랙티브 UI"를 공식적으로 추가하기 위한 확장 사양이다.

지금까지 MCP는 텍스트와 구조화된 데이터(예: JSON)만 주고받을 수 있었지만, 이 확장은 MCP 서버가 화면 구성까지 포함한 UI를 리소스로 제공하고, 호스트(예: ChatGPT, MCP 클라이언트)가 이를 렌더링하도록 표준을 제시한다.

이 덕분에 MCP 서버는 단순 도구 모음이 아니라, 대화 안에서 동작하는 작은 웹 앱처럼 작동하는 "에이전틱 앱 런타임"에 가까운 역할을 할 수 있게 된다.

왜 MCP에 표준화된 UI가 필요한가

현재 MCP 서버는 시각화 같은 복잡한 결과를 표현할 때 JSON이나 텍스트로만 결과를 돌려준다.

예를 들어 차트 서버가 막대그래프 데이터를 JSON으로 반환하면, 각 클라이언트는 이 JSON을 해석해 직접 차트를 그리는 UI를 구현해야 한다. 서버마다, 도메인마다 포맷과 요구사항이 달라지면 클라이언트 개발자는 다양한 UI 처리 로직을 중복해서 만들어야 한다.

UI가 없으면 사용자와의 상호작용도 어색해진다. 여러 옵션을 설정해야 하는 도구를 생각해 보면, 자연스러운 폼 UI 대신 "옵션을 한 줄로 입력해 주세요" 같은 채팅 방식만 사용해야 하기 때문이다.

커뮤니티는 MCP-UI처럼 각자 해결책을 만들었지만, 표준이 없으면 서버와 클라이언트가 서로 다른 방식으로 UI를 붙이게 되고, 결과적으로 생태계가 쪼개질 위험이 커진다. MCP Apps Extension은 이런 분산된 시도를 하나의 공통 패턴으로 모으려는 시도다.

MCP-UI, OpenAI Apps SDK와의 관계

이번 확장은 완전히 새로운 아이디어가 아니라, 이미 검증된 두 축 위에서 만들어지고 있다.

첫째, MCP-UI 프로젝트는 MCP 서버가 UI를 "리소스"로 제공하는 패턴을 먼저 실험했다. 이 프로젝트를 통해 MCP 안에서 UI를 1급 객체로 다루는 모델이 충분히 유용하다는 것이 실무에서 확인됐다.

둘째, OpenAI Apps SDK는 ChatGPT 안에서 돌아가는 리치 앱을 만드는 도구로, 내부적으로 MCP 개념을 활용하고 있다. 이를 통해 "대화형 AI 환경 안에서 UI가 얼마나 중요한지"와 "어떤 보안, 사용 패턴이 필요한지"가 정리되었다.

이번 MCP Apps Extension은 Anthropic, OpenAI, MCP-UI 커뮤니티가 함께 이 경험을 통합해, 어느 호스트에서나 동일하게 동작할 수 있는 공식 확장으로 승격시키는 작업이다.

UI 리소스를 미리 선언하는 구조

MCP Apps Extension의 핵심 개념 중 하나는 UI를 ui:// 스킴을 가진 리소스로 정의하고, 이를 도구 메타데이터에서 참조하는 방식이다.

서버는 UI 템플릿을 하나의 리소스로 등록한다. 예를 들어 막대그래프를 보여주는 뷰는 다음처럼 정의될 수 있다.

// Server registers UI resource
{
  uri: "ui://charts/bar-chart",
  name: "Bar Chart Viewer",
  mimeType: "text/html+mcp"
}

그리고 데이터를 시각화하는 도구 정의에 이 리소스를 연결한다.

// Tool references it in metadata
{
  name: "visualize_data_as_bar_chart",
  description: "Plots some data as a bar chart",
  inputSchema: {
    type: "object",
    properties: {
      series: { type: "array", items: .... }
    }
  },
  _meta: {
    "ui/resourceUri": "ui://charts/bar-chart",
  }
}

이 패턴 덕분에 호스트는 도구를 실행하기 전에 관련 UI 템플릿을 미리 받아 검토하거나 캐싱할 수 있다. UI는 주로 정적인 HTML 구조를 담고, 실제 데이터는 도구 실행 결과로 따로 전달되므로, "표현"과 "데이터"를 분리해 재사용성과 성능을 높일 수 있다.

MCP 프로토콜을 그대로 쓰는 양방향 통신

UI와 호스트 사이의 통신은 새로운 프로토콜을 만드는 대신, 기존 MCP JSON-RPC를 그대로 재활용한다. 다만 물리적인 전달 매체로는 브라우저의 postMessage를 사용한다.

이 말은 곧, UI 개발자가 MCP 서버를 만들 때 쓰는 것과 같은 @modelcontextprotocol/sdk를 UI 코드에서도 그대로 사용할 수 있다는 뜻이다. UI에서 호스트로 "도구 실행 요청, 상태 요청, 로그 전송" 등을 MCP 방식으로 보내고, 호스트는 이를 통제하며 기록할 수 있다.

이 접근은 두 가지 이점이 크다. 첫째, 새로운 메시지 규격을 배우지 않아도 되므로 개발 학습 비용이 낮다. 둘째, MCP에 추가되는 미래의 기능(예: 새로운 RPC, 권한 체계)이 자연스럽게 UI까지 확장된다.

HTML·iframe을 기본 단위로 택한 이유

초기 버전의 확장은 UI 콘텐츠 타입을 text/html로 한정하고, 이를 샌드박스된 iframe으로 렌더링하는 것을 기본값으로 삼는다.

브라우저 환경에서 HTML과 iframe은 가장 널리 검증된 조합이다. 모든 주요 브라우저가 지원하고, 보안 모델과 제한 방법(예: sandbox 속성)이 명확하다. 또한 HTML 기반이면 스크린샷·미리보기 생성도 비교적 간단하다.

외부 URL을 바로 로드하거나, 원격 DOM을 주입하거나, 네이티브 위젯을 다루는 등의 고급 기능은 의도적으로 뒤로 미뤄 두었다. 먼저 "작동이 검증된 최소한의 공통분모"를 표준으로 정하고, 그 위에서 점차 확장하는 전략이다.

이처럼 채팅 영역 안에서 작은 UI를 띄워, 권한 요청/승인 같은 복잡한 상호작용을 훨씬 자연스럽게 처리할 수 있다.

보안을 위해 쌓아 올린 방어층

MCP 서버가 임의의 HTML을 제공하고, 그 HTML이 사용자 환경에서 실행된다는 것은 곧 보안 리스크가 있다는 뜻이다. MCP Apps Extension은 여러 층의 방어 전략을 결합해 이를 줄이려 한다.

첫째, 모든 UI는 권한이 제한된 iframe 안에서 돌아간다. iframe sandbox 설정을 통해 스크립트 권한, 네트워크 접근, 상위 문서 접근 등을 세밀하게 제어해, 악의적인 콘텐츠가 호스트나 사용자 환경을 침범하기 어렵게 한다.

둘째, UI 템플릿을 사전에 선언하는 구조 덕분에 호스트는 HTML을 렌더링하기 전에 검사·필터링·승인 절차를 거칠 수 있다.

셋째, UI와 호스트 간의 모든 통신은 JSON-RPC 형태로 남으므로, 로깅과 모니터링을 통해 이상 행동을 탐지할 수 있다.

넷째, UI에서 도구 실행 같은 민감한 요청을 보낼 때 호스트는 "사용자 승인 필요" 규칙을 적용할 수 있다. 이를 통해 UI가 마음대로 서버 자원을 호출하거나 사용자 데이터를 다루지 못하게 제어할 수 있다.

기존 MCP와의 호환성과 점진적 도입

MCP Apps Extension은 "선택적 확장"이다. 즉, 이를 지원하지 않는 기존 MCP 호스트와 서버는 그대로 잘 동작한다.

호스트 입장에서는 UI 확장을 이해하지 못하면, 단순히 ui:// 리소스를 무시하고 텍스트·JSON 기반 도구만 사용하면 된다.

서버 입장에서는 UI를 제공하더라도, 항상 텍스트만으로도 쓸 수 있는 결과를 함께 제공해야 한다. 예를 들어 "데이터를 막대그래프로 시각화"하는 도구라면, 그래프를 보여주는 UI를 제공하면서 동시에 "요약 통계나 표 형식"의 텍스트 결과도 반환하도록 설계하는 식이다.

이런 설계 덕분에, 생태계는 한 번에 전환할 필요 없이 "UI 지원 호스트는 리치 UI를, 그렇지 않은 호스트는 텍스트 경험을" 제공하는 식으로 자연스럽게 공존할 수 있다.

앞으로의 방향과 참여 방법

현재 MCP Apps Extension은 제안 단계지만, 이미 타입과 패턴을 검증할 수 있는 초기 SDK가 준비되어 있다. MCP-UI 클라이언트/서버 SDK도 이 패턴을 지원하기 시작했다.

관심 있는 개발자는 세 가지 정도 경로로 참여할 수 있다. 먼저, SEP-1865 사양 초안을 꼼꼼히 읽고 설계 상의 빈틈이나 개선점을 제안하는 것. 다음으로, MCP-UI나 ext-apps SDK를 이용해 실제 프로토타입을 만들어 보고 사용 경험을 공유하는 것. 마지막으로, UI Working Group이나 Discord 채널에 참여해 다양한 사용 사례와 우려 사항을 논의하는 것이다.

이 과정에서 나온 피드백이 향후 HTML 이외의 UI 타입, 더 정교한 권한 모델, 고급 상호작용 패턴 설계에 직접 영향을 줄 가능성이 크다.

인사이트

MCP Apps Extension은 "AI 도구가 단순히 텍스트를 주고받는 수준"에서 "대화 속에 내장된 앱 경험"으로 진화하는 핵심 발판이다.

MCP 기반 도구를 설계할 때는, 앞으로 UI 리소스를 어떻게 함께 설계할 수 있을지 미리 생각해 두는 것이 좋다. 예를 들어, 도구의 입력·출력을 JSON으로만 설계하는 것이 아니라, "어떤 HTML 뷰로 보여주면 좋을지", "사용자가 어떤 단계에서 직접 조작해야 할지", "어떤 호출은 반드시 사용자 승인이 필요할지"까지 함께 정의하는 관점이다.

반대로 호스트를 만드는 쪽에서는, 모든 UI를 직접 구현하려 하기보다, 서버가 제공하는 UI 리소스를 안전하게 렌더링하고 감시·제한하는 인프라에 집중하는 것이 효율적이다. 이렇게 역할을 나누면, 도메인 전문가는 자신만의 인터랙티브 앱을 MCP 서버로 배포하고, 호스트는 이를 통합하는 허브로서 성장할 수 있다.

출처 및 참고 : MCP Apps: Extending servers with interactive user interfaces | Model Context Protocol Blog