MCP Apps란 무엇인가: 대화창에 대시보드가 뜨는 이유 (2026 최종 스펙)

Claude나 ChatGPT한테 "이번 달 매출 데이터 보여줘" 했는데 텍스트 요약 대신 진짜 대시보드가 화면에 떴다면, 그게 바로 MCP Apps입니다. 저도 처음 이 화면을 봤을 때 "이게 챗봇 창 맞나" 싶었어요. MCP Apps는 Model Context Protocol의 첫 번째 공식 확장(extension)으로, 도구 실행 결과를 텍스트가 아니라 대화형 HTML UI로 돌려줄 수 있게 해주는 규격입니다. 이 구조가 실제로 어떻게 돌아가는지, 얼마나 안전한지, 지금 당장 어디서 써볼 수 있는지 하나씩 짚어보겠습니다.

채팅 대화창 안에 대시보드형 UI가 인라인으로 렌더링되는 모습을 보여주는 개념 일러스트

 

MCP Apps가 나온 이유

MCP Apps(SEP-1865)는 2025년 11월 21일 처음 제안됐고, 2026년 1월 26일 Model Context Protocol 공식 블로그를 통해 "첫 번째 공식 MCP 확장"으로 발표되면서 바로 프로덕션에 쓸 수 있는 상태가 됐습니다. MCP-UI 프로젝트와 OpenAI Apps SDK가 먼저 "UI 리소스가 MCP 생태계에 자연스럽게 들어맞는다"는 걸 증명했고, 그 뒤 Anthropic과 OpenAI가 손잡고 어떤 MCP 클라이언트에서도 쓸 수 있는 공유 오픈 표준으로 다듬었습니다.

문제의식은 단순합니다. 도구가 수백 개 행짜리 데이터베이스 쿼리 결과를 돌려줘도, 지금까지는 모델이 그걸 텍스트로 요약하는 수밖에 없었어요. 근데 사용자는 요약이 아니라 직접 들여다보고 필터링하고 싶을 때가 많잖아요. MCP Apps 공식 블로그도 정확히 이 지점을 짚습니다. 텍스트만으로는 실시간 업데이트도, 미디어 뷰어도, 상태를 유지하는 다단계 워크플로우도 만들기 어려웠던 겁니다.

 

도구와 UI 리소스는 어떻게 연결되나

구조 자체는 생각보다 단순해요. 도구(tool) 하나가 UI 리소스 하나를 참조하는 방식입니다. UI 리소스는 ui:// 스킴으로 식별되고, 도구는 _meta.ui.resourceUri 필드로 이 리소스를 가리킵니다.

{
  "name": "get_weather",
  "_meta": {
    "ui": {
      "resourceUri": "ui://weather-server/dashboard-template",
      "visibility": ["model", "app"]
    }
  }
}

visibility 필드가 재밌는데, model이면 에이전트가 이 UI를 표시·호출할 수 있고 app이면 같은 서버 안의 다른 앱에서만 불러쓸 수 있습니다. 기본값은 둘 다 포함이에요. 호스트는 도구 설명에서 이 메타데이터를 읽고 UI를 미리 가져와서(prefetch) 캐싱해두고, 렌더링 전에 보안 검토까지 끝내둘 수 있습니다. 즉 사용자가 도구를 호출하는 순간엔 이미 검증이 끝난 UI가 나오는 구조예요.

도구(tool)의 _meta.ui.resourceUri가 ui:// 스킴 리소스를 참조하고 호스트가 이를 prefetch·캐싱하는 흐름을 보여주는 다이어그램

렌더링된 iframe이 호스트와 주고받는 통신은 postMessage 위에 JSON-RPC 2.0을 얹은 방식입니다. MCP 전체가 쓰는 것과 같은 기반 프로토콜이라, UI 안에서 시작된 액션(도구 호출 같은)도 전부 기존 MCP의 감사·동의 절차를 그대로 통과해요. View에서 Host로 ui/open-link, ui/message, tools/call 같은 요청을 보내고, Host는 ui/notifications/tool-result, ui/notifications/size-changed 같은 알림으로 응답합니다. 콘텐츠 타입은 text/html;profile=mcp-app이 필수고, 유효한 HTML5 문서여야 합니다.

 

MCP Apps 보안은 괜찮을까

솔직히 이 부분이 제일 궁금했어요. 채팅창에 임의의 HTML을 띄운다니, 뭔가 불안하지 않나 싶었거든요. 스펙을 보니 3계층으로 방어하고 있더라고요.

첫째, 모든 UI 콘텐츠는 권한이 제한된 샌드박스 iframe에서만 실행됩니다. 기본 샌드박스 속성은 allow-scripts, allow-same-origin 정도로 좁혀져 있어요. 둘째, 호스트가 렌더링하기 전에 HTML 템플릿을 미리 검토할 수 있도록 도구가 UI를 사전 선언합니다. 셋째, UI와 호스트 사이의 모든 통신이 로깅 가능한 JSON-RPC를 통해 오가서 감사가 가능합니다.

여기에 도메인 단위 CSP(Content Security Policy)도 자동으로 걸립니다. connectDomains, resourceDomains, frameDomains 같은 걸 선언하면 각각 connect-src, frame-src 같은 지시어로 매핑되고, 선언이 없으면 기본값이 default-src 'none'으로 아주 빡빡하게 잡힙니다. 카메라·마이크·클립보드 같은 권한도 iframe의 allow 속성으로 별도 요청해야 하고요. 공식 블로그도 "MCP 서버 연결 전 철저히 검증할 것"을 명시적으로 권고하고 있는데, 이건 자동으로 다 막아주는 마법 같은 게 아니라 여전히 신뢰할 수 있는 서버만 연결해야 한다는 뜻이에요.

 

MCP Apps는 지금 어디서 써볼 수 있나

2026년 1월 26일 발표 시점 기준으로 Claude(웹·데스크톱), Goose, VS Code Insiders에서 이미 사용 가능했고 ChatGPT는 그 주 안에 지원 예정이었습니다. JetBrains, AWS, Google DeepMind도 관심을 표명했고요.

VS Code 쪽 활용 사례가 특히 구체적입니다. AI 코딩 에이전트가 드래그앤드롭으로 항목을 재정렬하는 인터페이스를 보여주거나, CPU 프로필 데이터를 텍스트 요약 대신 대화형 플레임 그래프로 띄워서 콜 스택을 바로 탐색하게 해주는 식이에요. 기능 플래그를 환경별(prod/staging/dev)로 보여주고 그 자리에서 전환하는 UI도 예시로 나와 있습니다. 세일즈 분석 도구가 지역별 필터와 계정 드릴다운이 되는 대시보드를 반환하는 시나리오, "production" 선택 시 보안 옵션이 추가로 나타나는 설정 마법사 시나리오도 있고요.

 

2026-07-28 최종 스펙에서 MCP Apps의 위치

MCP Apps는 단독 기능이 아니라 더 큰 스펙 개편의 일부입니다. 릴리스 후보는 2026년 5월 21일 나왔고, 최종 스펙은 2026년 7월 28일 출시됐어요. 이 릴리스에서 눈에 띄는 변화가 몇 가지 있습니다.

가장 큰 건 Stateless Protocol Core예요. 기존 initialize/initialized 핸드셰이크와 Mcp-Session-Id 헤더가 사라지고, 어떤 요청이든 아무 서버 인스턴스에나 도착해도 처리되는 구조로 바뀌었습니다. 원격 MCP 서버를 일반 라운드로빈 로드밸런서 뒤에 그냥 둘 수 있게 된 거죠. Extensions Framework도 새로 생겼는데, 확장을 역-DNS ID로 식별하고 클라이언트·서버 capabilities의 extensions 맵으로 협상하는 공식 체계입니다. MCP Apps는 이 프레임워크 아래 확장 중 하나로 편입됐고요.

그 외에 Tasks가 실험 기능에서 정식 확장으로 승격됐고, authorization은 OAuth 2.0·OIDC 배포 방식과 더 맞도록 강화됐습니다. 기능 폐기(deprecation) 정책도 공식화돼서 Roots, Sampling, Logging이 폐기 예정으로 표시됐어요. 하나씩 보면 개별 변경이지만, 전체적으로는 MCP가 "실험적 프로토콜"에서 "운영 가능한 표준"으로 넘어가는 신호로 읽힙니다.

MCP Apps, Stateless Protocol Core, Extensions Framework, Tasks, Authorization 강화, Deprecation 정책이 2026-07-28 최종 스펙에 포함된 구성을 정리한 다이어그램

 

직접 확인해보고 싶다면

MCP Apps는 이미 스펙 문서와 예제 서버가 공개돼 있어서, 지금 쓰고 있는 MCP 클라이언트가 뭔지에 따라 바로 체감할 수 있습니다. Claude나 VS Code Insiders를 쓰고 있다면 UI를 반환하는 MCP 서버 하나만 연결해봐도 감이 옵니다. 도구를 직접 만들어보는 쪽이라면 _meta.ui.resourceUri 필드부터 붙여보는 게 제일 빠른 시작점이고요. 관련해서 더 궁금한 부분이 있으면 다음 글에서 실제 서버 구현 예제로 이어가 볼게요.