MCP Apps는 채팅창을 앱 런타임으로 바꾼다: UI over MCP의 의미

에이전트 제품을 만들다 보면 곧 같은 벽에 부딪힌다. 모델은 도구를 잘 호출하지만, 도구가 돌려주는 결과는 여전히 긴 텍스트와 JSON 덩어리인 경우가 많다. 사용자는 차트, 폼, 지도, 캘린더, 결제 UI, 분석 대시보드를 원하지만 채팅창은 자주 “설명문”으로 모든 것을 환원한다.

AI Engineer의 MCP UI: Extending the frontier 발표는 이 병목을 정면으로 다룬다. Liad Yosef와 Ido Salomon은 MCP Apps를 “MCP 서버가 UI를 채팅 호스트 안으로 전달하는 표준”으로 설명한다. 핵심은 단순하다. tool result가 텍스트만 반환하는 대신, 서버가 ui:// resource와 HTML app을 제공하고, 호스트가 이를 sandboxed iframe으로 렌더링한다.

이 변화는 작은 UI 편의 기능이 아니다. 채팅창이 검색창이나 콘솔이 아니라 앱이 실행되는 배포 표면이 되는 변화다.

무엇을 다루는 영상인가

이 영상은 AI Engineer 채널에 2026-05-06 업로드된 약 22분 길이의 컨퍼런스 발표다. YouTube 제목은 **MCP UI: Extending the frontier — Liad Yosef and Ido Salomon, MCP Apps**이고, 설명란은 ChatGPT, Claude, VS Code, Cursor, Copilot 같은 host 안에서 tool이 branded, functional app experience를 보낼 수 있다는 점을 강조한다.

공식 chapter가 잘 정리되어 있어 흐름도 명확하다. 발표는 텍스트 기반 tool response의 한계에서 시작해, MCP-UI와 MCP Apps 표준화 배경, PostHog/Claude 데모, host/server architecture, interaction message spectrum, reusable views, generative UI와 “write once, run everywhere” 주장으로 이어진다.

이 글은 YouTube metadata와 transcript, 영상에서 추출한 주요 프레임, 그리고 modelcontextprotocol/ext-apps 공식 repo와 specification, MCP-UI-Org/mcp-ui SDK README, 관련 ecosystem 자료를 함께 확인해 정리했다.

핵심 아이디어: 텍스트 응답이 아니라 앱 조각을 돌려준다

발표의 출발점은 “우리는 지금까지 text에 익숙했다”는 문제 제기다. MCP tool은 어떤 일을 실행하고, 호스트는 그 결과를 채팅창에 보여준다. 그런데 많은 회사 입장에서 이것은 너무 손실이 큰 표현 방식이다. Shopify, Booking, Expedia, Hugging Face 같은 서비스가 갖고 있는 정체성, 인터랙션, 시각적 구조가 모두 한 덩어리 텍스트로 줄어든다.

MCP Apps의 제안은 이 손실을 줄이는 것이다. tool이 text만 돌려주는 대신, UI resource를 함께 제공한다. 호스트는 해당 resource를 읽고, chat transcript 안에 interactive app으로 렌더링한다. 사용자는 결과를 읽는 것이 아니라 조작한다.

공식 ext-apps README도 같은 방향으로 MCP Apps를 정의한다. MCP tool이 charts, forms, dashboards 같은 interactive UI를 Claude, ChatGPT, 그리고 compliant chat client 안에 inline으로 렌더링할 수 있게 하는 extension이라는 설명이다.

따라서 여기서 중요한 단어는 “UI”보다 “standard”다. 각 host가 제각각 widget protocol을 만들면 개발자는 ChatGPT용, Claude용, VS Code용 UI를 따로 관리해야 한다. MCP Apps는 이 단편화를 줄이고, 서버가 한 번 선언한 UI resource를 여러 host가 같은 방식으로 이해하도록 만들려는 시도다.

UI over MCP는 어떻게 동작하나

발표의 core concept 구간은 구조가 비교적 단순하다.

먼저 사용자가 host에서 intent를 말한다. host의 모델은 MCP server의 tool을 호출한다. 예전 방식이라면 server는 text나 structured data를 돌려준다. MCP Apps에서는 tool metadata가 UI resource를 가리키고, host는 resources/read로 해당 resource를 가져와 sandboxed iframe 안에 렌더링한다.

공식 specification은 이 resource가 ui:// URI scheme을 쓰고, 초기 HTML content type으로 text/html;profile=mcp-app을 사용한다고 설명한다. tool과 UI는 _meta.ui.resourceUri로 연결된다. 즉 “이 tool의 결과는 이 UI resource로 보여 달라”는 계약이 tool definition 안에 들어가는 셈이다.

중요한 점은 이 UI가 서버가 보낸 static screenshot이 아니라는 것이다. 발표자는 “interactive means interactive”라고 강조한다. 사용자가 버튼을 누르거나 form을 채우면, 그 action은 host로 전달된다. host는 그 action을 user intent나 instruction으로 해석하고, 필요하면 다시 tool을 호출한다.

이 설계는 앱의 권한 모델도 바꾼다. 전통적인 웹 앱에서는 클릭이 서비스 backend로 바로 간다. MCP Apps에서는 interaction이 우선 host를 거친다. 즉 host, model, tool server, embedded UI 사이의 통제권 분배가 제품 설계의 핵심 문제가 된다.

PostHog 데모: “show me”가 텍스트를 대시보드로 바꾼다

발표에서 가장 직관적인 장면은 PostHog와 Claude 데모다. 사용자가 Claude에게 funnel 분석을 요청하면, 예전 방식에서는 textual response가 나온다. 정확한 설명일 수는 있지만, funnel drop-off를 이해하려면 사용자가 긴 문장을 읽고 머릿속에서 구조를 다시 만들어야 한다.

MCP Apps 방식에서는 사용자가 “show me”라고 말했을 때 PostHog가 만든 funnel visualization이 Claude 안에 나타난다. 발표자는 이 UI가 PostHog가 제어하는 component이며, PostHog 웹사이트에서 보던 경험과 정체성을 chat host 안으로 가져온다고 설명한다.

이 데모가 보여 주는 변화는 “예쁜 차트”보다 크다. 에이전트가 앱 데이터를 가져와 설명하는 수준에서 멈추지 않고, 해당 앱이 정의한 domain-specific interaction을 그대로 host 안에 가져온다. 분석 도구라면 chart, 커머스라면 cart, 여행 서비스라면 itinerary, 디자인 도구라면 canvas가 들어올 수 있다.

물론 이때 좋은 UX는 자동으로 생기지 않는다. 어떤 interaction을 host로 넘기고, 어떤 interaction은 embedded UI 내부에서 처리할지 정해야 한다. 예를 들어 장바구니 수량 변경은 UI가 직접 처리하고 host에는 notification만 보낼 수 있다. 반대로 “예약 확정”처럼 모델과 사용자의 추가 확인이 필요한 action은 host를 거쳐야 할 수 있다.

아키텍처: host, sandbox, MCP server 사이의 새 계약

기술적으로 MCP Apps는 host와 server 사이에 UI delivery contract를 추가한다. 영상의 architecture slide는 사용자, host sandbox, model, client SDK, MCP server, server SDK를 한 장에 배치한다.

서버 쪽은 UI resource를 만들고 tool metadata에 연결한다. 호스트 쪽은 이 resource를 fetch하고 sandbox 안에서 렌더링한다. @mcp-ui/client의 AppRenderer 같은 client component는 host가 받은 UI resource를 실제 React host 안에 붙이는 역할을 한다.

여기서 sandbox는 부가 기능이 아니라 핵심 안전 장치다. 공식 specification은 host가 iframe sandboxing과 CSP를 강제해야 한다고 설명한다. UI resource는 필요한 connectDomains, resourceDomains, frameDomains, permissions 등을 선언하고, host는 선언되지 않은 domain을 허용하지 않아야 한다.

이 말은 MCP Apps가 “임의 웹사이트를 채팅창에 마음대로 꽂는다”는 뜻이 아니라는 점을 분명히 한다. 오히려 agent host 안에 앱을 넣기 위해 필요한 audit trail, CSP, permission boundary, fallback behavior를 표준화하려는 시도에 가깝다.

타임라인으로 보는 핵심 구간

영상과 연결 자료에서 확인되는 점

확인 가능한 사실을 나누면 다음과 같다.

주의할 점도 있다. 영상의 “웹사이트가 필요 없어질 수 있다”는 표현은 강한 제품적 비유다. 모든 웹사이트가 곧 사라진다는 뜻으로 읽기보다는, 사용자의 intent가 agent host에서 시작될 때 기존 웹 앱의 기능이 더 작은 UI chunk로 분해되어 호출될 수 있다는 뜻으로 보는 편이 안전하다.

또한 host support는 여전히 중요하다. 공식 README도 MCP Apps가 core MCP specification의 optional extension이며 host support가 다를 수 있다고 설명한다. 따라서 “write once, run everywhere”는 방향성으로는 강하지만, 실제 도입에서는 각 host의 rendering, permission, OAuth, domain, CSP, fallback 차이를 점검해야 한다.

실무 관점에서의 해석

MCP Apps의 가장 큰 의미는 에이전트 앱의 프론트엔드를 다시 생각하게 만든다는 데 있다. 지금까지 많은 agent workflow는 “chat + tool call + text answer” 조합으로 설계되었다. 하지만 실제 업무는 텍스트만으로 끝나지 않는다. 사용자는 결과를 확인하고, 필터를 바꾸고, form을 제출하고, chart를 drill down하고, 특정 action을 승인한다.

이 interaction을 모두 자연어 turn으로만 처리하면 UX가 느려지고 모호해진다. 반대로 domain UI를 host 안으로 가져오면 사용자는 익숙한 app interaction을 유지하면서, 모델은 그 interaction을 context로 받아 다음 action을 이어갈 수 있다.

둘째, 앱 배포 전략이 바뀐다. 지금까지 회사는 사용자를 자기 웹사이트나 모바일 앱으로 데려오려 했다. MCP Apps식 세계에서는 ChatGPT, Claude, VS Code, Cursor 같은 host가 사용자의 작업 시작점이 되고, 서비스는 그 안에 필요한 UI fragment를 공급한다. 이는 SEO나 app store와는 다른 형태의 distribution channel이다.

셋째, agent product 팀은 backend tool만이 아니라 interaction contract를 설계해야 한다. tool schema, UI resource, action message, host callback, app-only tool, model-visible tool, permission, CSP가 함께 제품 표면이 된다. 단순히 “API를 MCP server로 감싼다”로는 충분하지 않다.

넷째, 디버깅과 평가도 바뀐다. UI가 host 안에서 렌더링되고 action이 host를 거쳐 다시 tool로 이어진다면, 테스트는 tool response만 검증해서는 부족하다. iframe rendering, message passing, OAuth, CSP, fallback text, host별 차이를 함께 봐야 한다. MCPJam 같은 inspector류 도구가 중요해지는 이유도 여기에 있다.

남는 질문

첫 번째 질문은 보안과 권한이다. 채팅 host 안에 third-party UI가 들어오면 사용자는 그것을 host의 일부로 느낄 수 있다. 따라서 시각적 boundary, provider identity, permission prompt, data flow transparency가 중요하다. MCP Apps spec이 CSP와 sandbox를 강조하는 것은 이 문제를 피할 수 없기 때문이다.

두 번째 질문은 UX 일관성이다. 발표는 predefined UI, declarative UI, fully generative UI를 spectrum으로 설명한다. 서비스가 완전히 자기 UI를 가져오면 브랜드와 기능은 보존되지만, 한 대화 안에 Booking, Airbnb, Expedia UI가 모두 섞일 수 있다. 반대로 host가 declarative UI를 재렌더링하면 일관성은 좋아지지만 provider의 identity와 세밀한 UX는 줄어든다.

세 번째 질문은 모델과 UI의 관계다. 지금의 많은 UI는 사람 click을 전제로 설계되어 있다. 그러나 발표 후반에서 말하듯, 앞으로는 모델이 view를 읽고, 버튼을 누르고, form을 채우는 방식도 중요해진다. 이 경우 UI는 사람을 위한 화면이면서 동시에 모델이 조작 가능한 action surface가 된다.

그래서 MCP Apps는 “채팅창에 예쁜 위젯을 넣는 기술”보다 넓다. 에이전트 시대의 애플리케이션이 어디에 배포되고, 누가 interaction을 소유하며, 어떤 권한 경계 안에서 UI와 모델이 협업할 것인가를 묻는 표준화 시도다.

아직 Jarvis는 아니지만, 방향은 분명하다. 앱은 더 이상 독립된 웹사이트 하나로만 존재하지 않는다. 에이전트 host 안에서 호출되고, 렌더링되고, 조작되고, 다시 tool call로 이어지는 작은 실행 가능한 UI 조각으로 재구성되고 있다.