MCP Apps: Extending the Frontier — Ido Salomon & Liad Yosef

1. 개요

이 발표는 MCP(Model Context Protocol) 생태계에서 최근 표준화된 MCP Apps 확장 스펙을 소개한다. 발표자인 Ido Salomon과 Liad Yosef는 각각 MCP-UI(2025년 5월 출시된 오픈 프로토콜)의 창시자이자 MCP Apps 스펙의 공동 제작·유지관리자로, Anthropic·OpenAI와 함께 MCP 공식 확장으로 만든 당사자들이다.

핵심 주장은 단순하다 — 챗봇/에이전트가 텍스트 벽(wall of text)으로 응답하는 대신, MCP 서버가 실제 인터랙티브 UI(브랜드가 살아있는 위젯, 차트, 버튼 등)를 직접 반환할 수 있어야 한다는 것. 이 UI는 리소스(HTML)로 등록되고, 호스트(Claude, ChatGPT, VS Code 등)가 웹 컴포넌트로 렌더링하며, 사용자의 클릭 등 상호작용이 다시 에이전트 루프로 흘러들어간다. 한 번 만들면 MCP Apps를 지원하는 모든 호스트에서 동작하는 "write once, run anywhere" 모델이며, ChatGPT(주간 8억 사용자)·Claude·VS Code·Cursor·GitHub Copilot 등이 이미 이를 채택했다.

2. 핵심내용 상세

2.1 왜 MCP Apps가 필요한가

• 채팅 클라이언트와 상호작용할 때 텍스트는 가장 자연스러운 인터페이스지만, 많은 정보를 전달하기엔 최악의 방식이다. 텍스트 벽은 정보 전달력이 떨어진다.
• 기업들이 MCP 서버 구축을 꺼리는 가장 큰 이유 중 하나는 자사 서비스가 "텍스트 데이터베이스"로 전락하고, 공들여 만든 UX와 브랜드 아이덴티티를 잃는 것에 대한 두려움이다.
• 해법: 앱이 자신의 UI를 채팅창으로 직접 전송하게 하자. 사용자는 그 UI 조각을 보고 "이건 Shopify구나", "이건 Hugging Face구나"라고 즉시 인지할 수 있고, 단순 시각화를 넘어 실제로 상호작용(예: Hugging Face 위젯에서 직접 액션 실행)할 수 있어야 한다.

2.2 MCP-UI에서 MCP Apps로

• MCP-UI는 Ido Salomon이 2025년 5월 만든 오픈 프로토콜로, MCP를 통한 인터랙티브 애플리케이션을 위한 것이다. UI를 어떻게 전송하는지뿐 아니라, 그 UI 애플리케이션이 호스트와 어떻게 통신하는지까지 정의한다.
• 몇 달 전, Anthropic·OpenAI와 파트너십을 맺어 MCP-UI, MCP SDK 등을 기반으로 한 MCP의 공식 확장 "MCP Apps"를 만들었다.
• 초기 채택자: 11 Labs, Shopify, Postman, Goose(약 1년 전부터 MCP-UI를 지원한 첫 클라이언트) — 흥미로운 일화로, Block(구 Square)이 최근 출시한 에이전틱 커머스 솔루션이 MCP Apps 기반인데, 정작 Goose가 Block의 제품 일부가 되었다.
• 현재 채택 호스트/클라이언트: Cursor, GitHub Copilot, ChatGPT(OpenAI가 MCP Apps를 ChatGPT Apps 구축 표준 프로토콜로 공식 권장), Claude, Postman 등.
• 커뮤니티도 빠르게 성장 중 — 플러그인, 에이전트 통합, 학습 코스 등이 생기고 있다. 공식 저장소는 "x apps"(MCP Apps repo, 공식 Model Context Protocol 조직 산하)이며, 누구나 PR과 아이디어를 제안할 수 있다. Anthropic·OpenAI 등 파트너들과 함께 3주마다(tri-weekly) 열리는 오픈 워킹그룹에서 스펙의 미래를 논의한다.

2.3 핵심 아키텍처 개념

(1) UI 전송 방식

• 기존에는 툴 콜(tool call)이 MCP 서버로 나가면 텍스트 응답만 돌아왔다(최선의 경우에도).
• MCP Apps에서는 기존 MCP 프리미티브인 "리소스(resource)"를 활용해 HTML을 반환한다. 호스트(예: Claude)가 MCP Apps를 지원하면 이 HTML을 인터랙티브 애플리케이션으로 렌더링한다.

(2) 상호작용 표준화 — 콜백 흐름

• 예시: Spotify 위젯에서 곡에 "즐겨찾기" 버튼을 누르면, 앱이 Spotify 백엔드로 직접 메시지를 보내는 게 아니라 호스트에게 "사용자가 버튼을 눌렀다, 이에 대해 처리해달라(Spotify MCP 서버의 툴을 호출하는 걸 추천한다)"는 메시지를 보낸다.
• 호스트가 플로우의 통제권을 계속 쥐고 있으며, 실제로 어떤 툴을 호출할지 최종 결정한다. 이 흐름 자체를 MCP Apps가 표준화했다.

(3) 실제 데모 — Claude + PostHog

• 제품 매니저가 퍼널(funnel) 현황을 물으면, 예전에는 PostHog MCP 서버가 텍스트 응답만 반환해 사실은 맞지만 쓸모없는 정보였다.
• 지금은 PostHog 서버와 Claude가 둘 다 MCP Apps를 지원하므로 "보여줘(Show me)"라고 하면 브랜드가 살아있는 인터랙티브 PostHog 위젯이 뜬다. 한눈에 상황 파악이 가능하다.
• 여기서 그치지 않고, "퍼널이 뭔지 설명해줘"라고 물으면 다시 텍스트 벽 대신 제너레이티브 UI 답변(HTML을 스트리밍)으로 인터랙티브한 학습 경험을 준다.
• 위젯의 특정 단계를 클릭하면, 그 클릭이 콜백을 통해 호스트로 전달되고, "이 특정 단계를 설명해줘"라는 프롬프트가 다시 모델로 전송되어 대화 흐름이 이어진다.

(4) 아키텍처 상세 흐름

1. 사용자가 프롬프트 입력 → 툴 콜 발생
2. 서버가 MCP Apps를 지원하면 그 툴 콜은 리소스(간단한 prefix가 붙은 HTML 리소스)에 연결됨
3. 리소스는 호스트가 소비(실무에서는 보통 사전 로드/preload됨)
4. 호스트도 MCP Apps를 지원하면, 그 HTML은 MCP-UI SDK의 React/웹 컴포넌트에 전달됨 — 이 컴포넌트는 리소스와 콜백(통신 프로토콜 구현체)을 받아 샌드박스 안에 렌더링
5. 사용자가 클릭하면 콜백을 통해 이벤트가 위로 전달되고, 모델이 그 이벤트를 받아 툴 콜이나 리소스 호출 등으로 에이전틱 플로우를 완결

2.4 새로운 웹 철학 — 아토믹 UI와 에이전틱 웹

• 지금까지 웹은 브라우저로 소비하는 "탭/서비스"의 집합이었다. 이제는 개인 비서(에이전트)를 통해 소비하는 방식으로 바뀐다.
• 예: 기념일을 계획하려면 지금까지는 브라우저 탭 20개(Google Calendar, Amazon, Booking.com 등)를 열고 각 서비스의 UI/대시보드에 일일이 의도를 전달해야 했다. 그런데 사용자에게 필요한 건 그 UI의 99%가 아니라, 나를 위한 "원자(atom)" 단위 정보뿐이다.
• 이 UI들을 원자 단위로 쪼개서 개인 비서(Claude, ChatGPT 등)가 MCP-UI를 통해 조합할 수 있다면? 비서가 "기념일이 다가온다"는 걸 감지하고 Google Calendar 데이터를 텍스트로 보여주는 대신 Google Calendar UI 조각을 직접 보여준다.
  • 사용자 입장: Google Calendar를 신뢰하므로 좋다
  • Google 입장: 브랜드/아이덴티티 유지가 되므로 좋다
  • 호스트 입장: 이런 기능을 직접 개발할 필요가 없으므로 좋다
• Amazon과의 상호작용도 마찬가지로, 텍스트 목록이 아니라 실제 Amazon UI로 표시되어, 비서를 벗어나지 않고 전체 플로우를 완결할 수 있다. 이것이 "에이전틱 웹(agentic web)"이다 — 웹사이트가 개인 비서 안의 작은 UI 조각들로 쪼개져 들어가는 방향으로 전환될 것.

2.5 새로운 상호작용 패러다임과 3단계 사용자 여정 통제

• Shopify MCP 앱에서 뭔가를 클릭해도 이제 Shopify가 사용자의 여정을 통제하지 않는다 — 호스트가 통제한다. 어떤 애플리케이션도 더 이상 사용자 여정을 독점 통제할 수 없다 (예: Amazon이 내 플로우를 알 수 없게 됨). 모든 것이 감사 가능성(auditability)을 위해 채팅을 거친다.
• MCP Apps는 사용자 여정에 대한 통제를 3단계로 표준화한다:
  1. 앱이 채팅에게 "이런 일이 일어났다"고 알림(notify)
  2. 앱이 채팅에게 프롬프트를 실행해달라고 요청하며 책임을 완전히 넘김
  3. (그 사이의 단계들 — 발표에서 명시적으로 세 번째를 상술하진 않았으나 통제권의 스펙트럼이 존재함을 강조)
• 2026년은 MCP-UI를 표준화한 놀라운 해였고, 발표자들은 2026년이 UI를 위한 글로벌 표준의 해가 될 것이라고 전망한다.

2.6 스펙은 아직 진화 중 — 앞으로의 방향

1. 재사용 가능한 뷰(Reusable views): Autodesk 같이 무거운 3D 렌더링 앱을 가진 회사들은 매번 뷰를 다시 렌더링하고 싶어하지 않는다(비효율적). 현재 MVP 방식은 매번 재렌더링이지만, 서버에서 식별자(identifier)를 전달해 모델이 같은 뷰를 계속 업데이트할 수 있게 하는 방향을 검토 중.
2. 앱 툴(App tools): Google의 Web MCP 표준(에이전트가 웹뷰와 상호작용하는 방식)에서 영감을 받아, MCP Apps에서는 이를 "view tools"로 표준화했다. 지금까지는 사용자가 앱에서 뭔가를 하면 앱이 호스트에게 말하는 흐름이었지만, 반대로 호스트/채팅이 앱에게 말을 걸어야 하는 경우(예: "이 양식을 채워줘"라고 하면 채팅이 사용자를 대신해 폼을 채움)를 위한 표준. 스펙에 이미 포함되어 있고 곧 출시 예정.
3. 제너레이티브 UI 스펙트럼과 상호운용성: 한쪽 끝에는 MCP Apps 같은 사전 정의된(predefined) UI(블랙박스 iframe)가 있고, 중간에는 JSON 렌더나 A2UI 같은 선언적(declarative) UI(앱이 UI를 만드는 방법에 대한 지시만 반환하고 채팅이 실제로 UI를 빌드), 다른 한쪽 끝에는 완전한 제너레이티브 UI가 있다. MCP Apps는 UI가 어떻게 생성되는지에 대해 애그노스틱(agnostic)하다 — Claude Apps의 "UI를 생성해줘" 기능도 내부적으로는 MCP 앱 기반이면서 제너레이티브 UI를 지원하는 구조.

• 며칠 전, A2UI(제너레이티브 UI 표준, Gemini 진영)와 MCP Apps 간 상호운용성 가이드를 공개했다. 서버가 A2UI로 작성해 Gemini에 보내면서 동시에 MCP 앱으로 감싸 ChatGPT에도 보낼 수 있고 그 반대도 가능하다.
• MCP 앱은 어디서나 지원되므로 어디서나 실행 가능하다 — 예: LibreChat(오픈소스, MCP 앱 지원)에서 만든 것과 동일한 코드베이스가 ChatGPT에서도 동일하게 실행된다.

2.7 배포(distribution) 관점에서의 임팩트

• 몇 달 전 기준 ChatGPT는 주간 사용자 8억 명(전 세계 인구의 10%)에 달했다. 웹 전체가 그 정도 사용자 규모에 도달하기까지 약 13년이 걸렸는데, 최근 몇 달 사이 10억 명 이상 성장했다.
• 이는 Apple App Store가 출시됐을 때의 전체 타겟 시장(TAM) 대비 약 170배에 달하는 규모다.
• MCP Apps를 지원하는 호스트는 이미 어디에나 있다: Claude, OpenAI(ChatGPT) 등. 표준이기 때문에 서버가 한 번 MCP Apps로 UI를 만들면, 수백만~수억 주간 사용자를 가진 모든 호스트에 동시에 도달한다 — 이것이 이 표준의 진짜 배팅(bet)이다: 기술적 우아함이 아니라 배포 지렛대.

3. 인용

"Text is really the worst way to convey a lot of information... this is the main blocker from companies to build an MCP server. They don't want to be reduced to a textual database. They don't want to lose their brand identity in the process." — 텍스트는 정보 전달에 최악의 수단이며, 기업들이 MCP 서버 구축을 꺼리는 핵심 이유가 바로 브랜드 아이덴티티 상실에 대한 두려움이라는 지적.

"When the user clicks on the favorite button, MCP apps actually standardizes this flow. So, instead of the app sending a message to the backend... it's actually sending a message to the host... The host keeps this control of the flow." — 앱과 백엔드가 아니라 앱과 호스트 사이의 통신을 표준화함으로써, 사용자 여정의 통제권이 개별 서비스가 아닌 호스트(에이전트)에게 이동한다는 아키텍처의 핵심.

"This is going to be the shift that we're going to see very soon where websites are going to shift into small chunks of UIs inside personal assistants." — 웹사이트가 통째로 소비되는 대상에서, 개인 비서 안의 작은 UI 조각(atom)으로 쪼개져 소비되는 방향으로 패러다임이 전환된다는 비전.

"No application will control the user journey anymore... everything will go through the chat for auditability." — 개별 앱이 아닌 채팅(호스트)이 사용자 여정을 통제하며, 모든 상호작용이 감사 가능성을 위해 채팅을 거치게 된다는 새로운 신뢰/통제 모델.

"MCP apps are everywhere... write once and run it everywhere." — 표준이기 때문에 한 번 구현하면 MCP Apps를 지원하는 모든 호스트(Claude, ChatGPT, Cursor, GitHub Copilot 등)에서 그대로 동작한다는 핵심 가치 제안.

4. 시사점

1. MCP 서버를 만드는 팀이라면 텍스트 응답만으로 그치지 말고 리소스 기반 HTML UI를 고려해야 한다. 브랜드 아이덴티티를 잃지 않으면서도 사용자 경험을 극적으로 개선할 수 있는 표준 경로가 이미 Anthropic·OpenAI 공동 지원으로 마련되어 있다.

2. "한 번 만들면 어디서나 실행된다"는 배포 레버리지가 실제로 크다. ChatGPT 주간 8억 사용자 등 초거대 배포망에 동시 진입할 수 있다는 점에서, 개별 호스트별 통합 비용을 아낄 수 있는 전략적 이유가 명확하다. 프로덕트/스타트업 입장에서 MCP Apps 지원은 "가입 폭 확장" 관점에서 우선순위로 검토할 가치가 있다.

3. 사용자 여정 통제권이 개별 서비스에서 호스트(에이전트)로 이동한다는 구조적 변화는, 향후 브랜드-플랫폼 관계와 경쟁 구도에 큰 영향을 줄 수 있다. 서비스는 "원자화된 UI 제공자"로 위치가 재정의되며, 이는 장기적으로 플랫폼(호스트) 파워가 커지는 방향으로 힘의 균형이 이동함을 시사한다. 제품/사업 전략을 짤 때 이 구조적 리스크를 고려해야 한다.

4. 스펙이 아직 진화 중(reusable views, app tools/view tools, generative UI 상호운용성 등)이므로, 지금 참여하면 표준 형성에 영향을 미칠 여지가 크다. 공식 저장소(MCP 조직 산하 "apps" repo)와 3주 단위 오픈 워킹그룹이 존재하므로, 프로덕트에 깊이 관여하는 팀이라면 지금 스펙 논의에 참여하는 것이 이후 대규모 마이그레이션 리스크를 줄이는 방법이 될 수 있다.

5. A2UI(Gemini 계열)와의 상호운용성 가이드가 이미 나왔다는 것은, 제너레이티브 UI 표준 경쟁이 벤더 록인이 아니라 상호운용 방향으로 수렴할 가능성을 보여준다. 특정 벤더 표준에만 베팅하기보다, 스펙트럼(predefined → declarative → generative) 전반을 이해하고 유연하게 대응하는 게 안전하다.