MCP Apps - Extending the Frontier - Ido Salomon & Liad Yosef

📺 원본 영상: MCP Apps: Extending the Frontier — Ido Salomon & Liad Yosef
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-08-05
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 코드, 슬라이드, 데모 UI 등은 포함되지 않을 수 있습니다.


개요

이 강연은 MCP Apps가 왜 필요한지, 그리고 그것이 기존 채팅형 AI 인터페이스를 어떻게 애플리케이션 실행 환경으로 확장하는지를 설명한다. Ido Salomon과 Liad Yosef는 MCP UI에서 출발한 아이디어가 Anthropic, OpenAI 등과 함께 공식 MCP 확장인 MCP Apps로 발전했으며, 이제 ChatGPT, Claude, VS Code, Slack 같은 환경에서 앱 배포와 사용자 상호작용의 새로운 표준이 되고 있다고 주장한다.

핵심 메시지는 단순하다. AI 채팅창이 더 이상 텍스트 응답을 출력하는 공간에 머물지 않고, 각 서비스의 UI 조각을 안전하게 렌더링하고, 사용자의 클릭과 모델의 도구 호출을 연결하며, 브랜드 정체성과 사용자 맥락을 동시에 보존하는 새로운 웹 런타임이 된다는 것이다.


텍스트만으로는 부족한 이유

강연자들은 MCP Apps의 출발점을 “텍스트는 많은 정보를 전달하기에 최악의 방식”이라는 문제의식에서 찾는다. 기존 MCP 서버는 모델에게 데이터를 제공할 수 있었지만, 그 결과는 대개 긴 텍스트 블록으로 환원되었다. 이는 사용자가 읽기 어렵다는 문제를 넘어, 서비스 제공자 입장에서도 자신들이 공들여 만든 UX, 브랜드, 시각적 구조가 모두 사라진다는 의미였다.

이 문제는 단순한 미관의 문제가 아니다. 예를 들어 Shopify, Hugging Face, Monday.com 같은 서비스는 데이터 자체만으로 존재하지 않는다. 사용자는 로고, 색상, 배치, 상호작용 방식, 도메인별 정보 구조를 통해 해당 서비스가 무엇을 의미하는지 이해한다. 그런데 AI 채팅 환경에서 이 모든 것이 텍스트로 평탄화되면, 기업은 자신들의 제품 경험을 잃고 사용자는 맥락을 빠르게 파악하기 어렵다.

MCP Apps는 이 지점에서 “앱이 자기 UI를 채팅으로 보낼 수 있다면 어떨까”라는 질문을 제기한다. 단순히 HTML 조각을 보여주는 것을 넘어, 사용자가 그 UI 안에서 클릭하고 선택하고 다음 행동을 유도할 수 있다면, 채팅창은 사실상 여러 서비스의 UI 조각이 조립되는 작업 공간으로 바뀐다. 강연자들이 말하는 MCP Apps의 본질은 바로 이 전환, 즉 텍스트 응답에서 상호작용 가능한 앱 경험으로의 이동이다.


MCP UI에서 MCP Apps로 이어진 표준화

Ido Salomon은 자신이 MCP UI를 만들었고, 이후 MCP Apps 스펙의 공동 창작자이자 메인테이너로 활동하고 있다고 소개한다. Liad Yosef 역시 MCP UI와 MCP Apps 스펙을 함께 만들고 유지하고 있으며, 에이전틱 웹을 연구하는 Aura라는 연구소를 공동 창업했다고 설명한다. STT에서 “cloud”로 반복 인식된 부분은 문맥상 대부분 Anthropic의 Claude를 의미하는 것으로 보인다.

강연에 따르면 MCP UI는 MCP 위에서 대화형 애플리케이션을 전달하기 위한 공개 프로토콜로 시작했다. 여기서 중요한 점은 UI를 전송하는 방식만 정의하는 것이 아니라, 그 UI가 호스트와 어떻게 통신하는지도 함께 다룬다는 것이다. 이후 이 흐름은 Anthropic과 OpenAI 등과의 협력을 통해 MCP의 공식 확장인 MCP Apps로 발전했다.

MCP UI가 MCP Apps 공식 확장으로 발전한 배경과 Anthropic, OpenAI와의 협력 관계를 설명하는 구간

02:44 - MCP UI가 MCP Apps 공식 확장으로 발전한 배경과 Anthropic, OpenAI와의 협력 관계를 설명하는 구간

초기 채택 사례로는 ElevenLabs, Shopify, Postman, Goose 등이 언급된다. 특히 Postman은 초기에 이 비전을 지지한 회사로 소개되며, Goose는 Block의 오픈소스 AI 에이전트로서 MCP UI를 지원한 초기 클라이언트였다고 설명된다. 현재는 Cursor, GitHub Copilot, GitHub, ChatGPT, Claude, Postman 등 다양한 클라이언트가 MCP Apps 또는 MCP UI를 지원하고 있으며, OpenAI 역시 ChatGPT Apps를 만들기 위한 프로토콜로 MCP Apps 사용을 권장한다고 강연자들은 말한다.

이 표준화의 중요한 특징은 대형 AI 연구소만을 위한 폐쇄적 스펙이 아니라는 점이다. 강연자들은 MCP Apps 관련 저장소와 워킹그룹이 열려 있으며, Anthropic, OpenAI, 여러 파트너와 커뮤니티가 약 3주마다 모여 프로토콜의 미래를 논의한다고 설명한다. 따라서 MCP Apps는 단순한 제품 기능이라기보다, AI 클라이언트와 외부 서비스가 UI와 액션을 교환하는 공개 인터페이스로 자리 잡으려는 시도에 가깝다.


UI는 어떻게 MCP를 통해 전달되는가

MCP Apps의 첫 번째 핵심 개념은 UI 전송이다. 강연자들은 기존 MCP 환경에서는 사용자가 질문하면 MCP 서버가 텍스트 응답을 반환하는 것이 최선이었다고 설명한다. 하지만 MCP의 기존 primitive인 resource를 활용하면 서버는 HTML을 반환할 수 있고, MCP Apps를 지원하는 호스트는 이 HTML을 샌드박스 안에서 상호작용 가능한 애플리케이션으로 렌더링할 수 있다.

MCP resource를 통해 HTML UI를 반환하고 호스트가 이를 인터랙티브 앱으로 렌더링하는 예시를 보여주는 구간

05:40 - MCP resource를 통해 HTML UI를 반환하고 호스트가 이를 인터랙티브 앱으로 렌더링하는 예시를 보여주는 구간

이 구조에서 앱은 단순한 이미지나 정적 카드가 아니다. 예를 들어 Spotify와 유사한 음악 목록 UI가 렌더링되었다고 할 때, 사용자는 특정 곡을 즐겨찾기에 추가하고 싶을 수 있다. 이때 앱이 직접 Spotify 백엔드로 요청을 보내는 것이 아니라, MCP Apps 표준에 따라 호스트에게 “사용자가 버튼을 눌렀으니 관련 도구를 호출하는 것이 좋다”는 이벤트를 전달한다. 최종적으로 어떤 도구를 호출할지, 어떤 흐름으로 이어갈지는 호스트가 결정한다.

이 설계는 보안과 통제 측면에서 중요하다. 앱이 사용자의 전체 여정을 직접 장악하지 않고, 호스트가 상호작용 흐름을 감사 가능하게 관리하기 때문이다. 사용자의 클릭은 앱 내부에 갇힌 이벤트가 아니라 모델과 도구 호출로 이어질 수 있는 표준화된 신호가 된다. 따라서 MCP Apps는 UI 렌더링 프로토콜이면서 동시에 에이전트 흐름을 제어하는 통신 프로토콜이다.


PostHog 데모가 보여주는 실용성

강연 중 가장 구체적인 예시는 PostHog의 퍼널 분석 데모다. 강연자는 제품 관리자가 Claude에 “퍼널 상태가 어떤가”라고 묻는 상황을 가정한다. 기존 방식이라면 PostHog MCP 서버가 사실적으로 맞는 텍스트 응답을 반환할 수는 있지만, 사용자는 그 긴 설명을 읽고 다시 PostHog 화면으로 돌아가 맥락을 해석해야 한다.

MCP Apps가 개입하면 경험은 달라진다. 사용자가 “보여줘”라고 요청하면, Claude 같은 호스트는 PostHog 서버에서 전달된 UI resource를 받아 채팅 안에 PostHog 스타일의 인터랙티브 위젯을 렌더링한다. 사용자는 긴 텍스트를 해독하지 않고도 퍼널의 어느 단계에서 문제가 발생하는지 한눈에 볼 수 있으며, 동시에 PostHog의 브랜드와 분석 경험도 유지된다.

PostHog 퍼널 분석 결과가 텍스트 대신 브랜드가 적용된 인터랙티브 위젯으로 표시되는 데모 구간

07:25 - PostHog 퍼널 분석 결과가 텍스트 대신 브랜드가 적용된 인터랙티브 위젯으로 표시되는 데모 구간

이 데모가 흥미로운 이유는 시각화에서 끝나지 않기 때문이다. 사용자가 퍼널의 특정 단계를 클릭하면 MCP App은 호스트에 이벤트를 보내고, 모델은 이를 바탕으로 “이 단계를 설명해 달라”는 후속 프롬프트나 도구 호출을 이어갈 수 있다. 즉 사용자는 대시보드를 보는 동시에 모델과 대화하고, 모델은 UI에서 발생한 상호작용을 다음 추론 단계의 입력으로 사용할 수 있다.

이 접근은 기업용 분석 도구에서 특히 강력하다. 데이터는 텍스트로도 설명할 수 있지만, 퍼널, 차트, 단계별 전환율 같은 정보는 시각 구조 안에서 훨씬 빠르게 이해된다. MCP Apps는 기존 SaaS 제품의 분석 UI를 채팅 안으로 가져오면서도, 그것을 단순한 iframe 복사본이 아니라 모델과 연결된 상호작용 단위로 바꾼다.


아키텍처 - resource, sandbox, callback, tool call

강연자들은 MCP Apps의 작동 방식을 비교적 단순한 아키텍처로 설명한다. 사용자가 호스트에 프롬프트를 입력하면 모델은 MCP 서버에 tool call을 보낸다. MCP Apps를 지원하는 서버라면 이 tool call은 UI resource와 연결될 수 있고, 이 resource는 HTML과 메타데이터를 포함해 호스트로 전달된다.

호스트 쪽에서는 MCP SDK의 React component 또는 web component가 이 resource를 받아 샌드박스 안에 렌더링한다. 여기서 샌드박스는 중요한 경계다. 외부 앱 UI를 채팅 클라이언트 안에 표시하되, 앱이 호스트 전체를 마음대로 제어하지 못하도록 격리해야 하기 때문이다. 렌더러는 resource와 함께 callback을 받아 앱에서 발생한 이벤트를 호스트로 다시 전달한다.

tool call, resource, HTML, host, sandbox, callback으로 이어지는 MCP Apps 아키텍처를 코드와 함께 설명하는 구간

09:15 - tool call, resource, HTML, host, sandbox, callback으로 이어지는 MCP Apps 아키텍처를 코드와 함께 설명하는 구간

사용자가 UI를 클릭하면 이벤트는 callback을 통해 호스트로 올라간다. 이후 모델은 그 이벤트를 해석해 추가 tool call을 실행하거나, 다른 resource를 호출하거나, 사용자에게 설명을 생성할 수 있다. 강연자들이 강조하는 점은 이 흐름이 앱 중심이 아니라 호스트 중심이라는 것이다. 앱은 이벤트와 의도를 전달하지만, 실제 사용자 여정의 통제권은 Claude, ChatGPT 같은 호스트와 그 안의 에이전트 흐름에 남는다.

이 구조는 기존 웹 애플리케이션 모델과 다르다. 전통적인 웹에서는 사용자가 브라우저 탭을 열고 각 서비스의 UI 안에서 직접 행동했다. MCP Apps 환경에서는 사용자가 개인 비서형 호스트 안에서 행동하고, 각 서비스는 필요한 순간에 자신들의 UI 조각과 도구를 제공한다. 따라서 웹은 “방문하는 사이트들의 집합”에서 “에이전트가 조립하는 서비스 조각들의 네트워크”로 재해석된다.


에이전틱 웹 - 탭을 여는 웹에서 조립되는 웹으로

강연자들은 MCP Apps를 단순한 기술 기능이 아니라 에이전틱 웹(agentic web)의 기반으로 설명한다. 지금까지 사용자가 기념일을 계획하려면 Google Calendar, Amazon, Booking.com 등 여러 사이트를 직접 열어야 했다. 각 사이트에서 사용자는 자신의 의도를 검색창, 필터, 메뉴, 폼을 통해 반복적으로 전달해야 했고, 각 서비스는 사용자의 전체 맥락을 거의 알지 못한 채 범용 UI를 보여주었다.

MCP Apps가 제안하는 미래는 다르다. 개인 비서형 AI는 사용자의 일정과 선호, 현재 목표를 알고 있으며, 필요한 순간에 Google Calendar의 일정 조각, Amazon의 상품 조각, Booking.com의 지도 조각을 가져와 하나의 흐름으로 구성할 수 있다. 사용자는 더 이상 20개의 탭을 옮겨 다니며 의도를 반복 설명하지 않고, 하나의 대화형 환경 안에서 목적을 달성한다.

Google Calendar, Amazon, Booking.com 같은 서비스 UI 조각이 개인 AI 비서 안에서 조립되는 에이전틱 웹 비전을 설명하는 구간

11:39 - Google Calendar, Amazon, Booking.com 같은 서비스 UI 조각이 개인 AI 비서 안에서 조립되는 에이전틱 웹 비전을 설명하는 구간

이 전환은 사용자에게만 유리한 것이 아니다. Google Calendar 입장에서는 자신들의 UI와 브랜드 신뢰를 유지할 수 있고, Amazon 역시 단순한 텍스트 상품 목록으로 환원되지 않을 수 있다. 호스트 입장에서는 모든 기능을 직접 구현하지 않고도 외부 서비스의 검증된 UI 조각을 활용할 수 있다. 이 때문에 MCP Apps는 앱 배포 방식, 브랜드 노출 방식, 사용자 여정의 소유권을 동시에 바꾸는 기술로 제시된다.

다만 이 변화는 기존 서비스들이 사용자 여정을 완전히 통제하던 방식과 충돌한다. 강연자들은 Shopify의 MCP App에서 사용자가 무언가를 클릭하더라도 Shopify가 더 이상 전체 여정을 장악하지 않는다고 설명한다. 모든 흐름은 채팅 호스트를 통해 지나가며, 이는 감사 가능성과 사용자 중심 통제를 강화한다. MCP Apps는 이 새로운 상호작용 질서를 notification, prompt 실행 요청, 호스트 제어 흐름 같은 단계로 표준화하려 한다.


다음 단계 - 재사용 가능한 뷰와 App Tools

강연 후반부에서는 MCP Apps의 향후 발전 방향이 제시된다. 첫 번째는 재사용 가능한 뷰(reusable views)다. Autodesk처럼 무거운 3D 렌더러를 포함한 앱은 매번 전체 UI를 다시 렌더링하는 방식이 비효율적이다. 강연자들은 서버가 어떤 식별자를 전달하고, 모델 또는 호스트가 같은 뷰를 계속 업데이트할 수 있는 구조를 고민하고 있다고 설명한다.

두 번째는 App Tools 또는 View Tool로 언급되는 흐름이다. 지금까지의 설명은 사용자가 앱 안에서 행동하고, 앱이 호스트에게 이벤트를 보내는 방향이었다. 하지만 반대로 사용자가 채팅에 “이 폼을 채워줘”라고 요청했을 때, 호스트가 앱 내부의 폼을 조작해야 하는 상황도 있다. MCP Apps는 이러한 호스트에서 앱으로의 상호작용을 표준화하려 하며, 강연자들은 이 기능이 스펙에 들어가 있고 곧 공개될 예정이라고 말한다.

이 기능이 중요해지는 이유는 AI 에이전트가 단순히 정보를 읽는 수준을 넘어 실제 UI를 조작하는 방향으로 발전하고 있기 때문이다. 사용자가 클릭하지 않아도 모델이 사용자의 의도를 이해해 적절한 입력란을 채우고, 선택지를 고르고, 필요한 작업을 진행할 수 있다면 웹 앱은 에이전트가 다룰 수 있는 실행 표면이 된다. MCP Apps는 이 실행 표면을 무작위 브라우저 자동화가 아니라 표준화된 앱-호스트 계약으로 만들려 한다.


Generative UI와의 관계

강연자들은 MCP Apps가 UI 생성 방식에 대해 중립적이라고 설명한다. 한쪽 끝에는 미리 정의된 UI가 있다. 이 경우 앱은 완성된 HTML이나 iframe에 가까운 블랙박스 UI를 제공하고, 호스트는 이를 샌드박스에 렌더링한다. PostHog나 Autodesk 같은 제품형 UI는 이 방식과 잘 맞는다.

반대쪽 끝에는 완전한 Generative UI가 있다. 여기서는 앱이 구체적인 UI를 직접 보내기보다, 호스트나 모델이 상황에 맞는 UI를 생성한다. 중간에는 JSON Render, AG-UI 같은 선언형 UI(declarative UI) 접근이 존재한다. 이런 방식에서는 서버가 “어떤 UI를 만들라”는 구조적 지시를 반환하고, 실제 렌더링은 호스트가 담당한다.

MCP Apps의 전략은 이 스펙들과 경쟁하기보다 상호운용성을 확보하는 데 있다. 강연자들은 AG-UI로 작성된 서버가 Gemini에 UI를 전달하면서도, MCP App으로 감싸 ChatGPT에 제공할 수 있는 방식을 안내하는 가이드를 최근 공개했다고 말한다. 또한 MCP App은 LibreChat 같은 오픈소스 클라이언트와 ChatGPT 같은 대형 호스트에서 같은 코드베이스로 실행될 수 있다고 설명한다. 이 “write once, run everywhere”라는 구호는 MCP Apps가 단순한 UI 포맷이 아니라 앱 배포 계층을 목표로 하고 있음을 보여준다.

재사용 가능한 뷰, App Tools, Generative UI 스펙과 MCP Apps의 상호운용성을 설명하는 구간

15:32 - 재사용 가능한 뷰, App Tools, Generative UI 스펙과 MCP Apps의 상호운용성을 설명하는 구간


앱 배포 채널로서의 ChatGPT와 MCP Apps

강연자들은 ChatGPT의 주간 사용자가 수억 명 규모에 도달했다는 수치를 언급하며, MCP Apps가 새로운 앱 배포 채널이 될 수 있다고 주장한다. STT상 “800 million weekly users”와 “over 1 billion” 같은 표현이 등장하지만, 구체적인 최신 수치는 영상 발언 기준으로만 이해하는 것이 안전하다. 강연자의 의도는 정확한 시장 규모 산정이라기보다, AI 채팅 호스트가 이미 거대한 사용자 접점을 확보했고 그 안에서 앱이 배포될 수 있다는 점을 강조하는 데 있다.

기존 모바일 앱 생태계에서는 Apple App Store나 Google Play가 배포의 중심이었다. 그러나 사용자가 매일 ChatGPT, Claude, Slack, VS Code 같은 AI 기반 작업 환경에 머문다면, 앱은 별도 설치 대상이 아니라 대화 중 호출되는 기능 단위가 된다. MCP Apps는 바로 그 호출 가능한 앱 단위를 표준화하려는 시도다.

ChatGPT, Slack, VS Code, Claude 등 대형 호스트를 통한 MCP Apps 배포 가능성과 write once run everywhere 메시지를 정리하는 구간

17:39 - ChatGPT, Slack, VS Code, Claude 등 대형 호스트를 통한 MCP Apps 배포 가능성과 write once run everywhere 메시지를 정리하는 구간

이 변화는 개발자와 기업에게 새로운 전략을 요구한다. 웹사이트를 만들고 검색 유입을 기다리거나, 앱스토어에 앱을 올려 설치를 유도하는 것만으로는 충분하지 않을 수 있다. 사용자의 의도가 AI 호스트 안에서 먼저 표현된다면, 서비스는 그 호스트가 이해하고 렌더링하고 조작할 수 있는 MCP App 형태로 자신을 제공해야 한다. 강연자들이 “새로운 웹을 받아들이라”고 말하는 이유도 여기에 있다.


마무리 / 핵심 정리

이 강연의 핵심은 MCP Apps가 AI 채팅창을 새로운 애플리케이션 런타임으로 바꾸고 있다는 주장이다. 기존 MCP가 도구와 데이터를 모델에 연결했다면, MCP Apps는 여기에 브랜드가 살아 있는 UI, 사용자 클릭, 호스트 중심의 제어 흐름, 에이전트의 앱 조작 가능성까지 더한다. 그 결과 채팅창은 단순 응답 화면이 아니라 여러 서비스의 UI 조각이 사용자의 맥락에 맞게 조립되는 작업 공간이 된다.

기술적으로 MCP Apps는 resource로 전달되는 HTML, 샌드박스 렌더링, callback 기반 이벤트 전달, tool call과의 연결이라는 비교적 명확한 구조를 가진다. 그러나 그 함의는 훨씬 크다. 웹은 사용자가 직접 방문하는 탭의 묶음에서, 개인 AI 비서가 필요한 UI 조각과 도구를 호출해 목적 중심으로 조립하는 환경으로 이동하고 있다. 강연자들이 말하는 “에이전틱 웹”은 바로 이 새로운 소비 방식의 이름이다.

MCP Apps가 표준으로 자리 잡을지는 아직 진행 중인 문제다. 하지만 Anthropic, OpenAI, Postman, Shopify, GitHub, Cursor, Slack, VS Code 등 다양한 생태계 참여자가 이미 관련 흐름에 참여하고 있다는 점은 이 변화가 단순한 실험에 머물지 않을 가능성을 보여준다. 개발자와 제품 팀에게 중요한 질문은 이제 “우리 서비스가 AI에게 텍스트로 설명될 것인가”가 아니라, “우리 서비스의 어떤 UI와 액션을 에이전트 환경 안에서 제공할 것인가”가 된다.


📚 출처 및 참고

구분내용
원본 영상MCP Apps: Extending the Frontier — Ido Salomon & Liad Yosef
채널AI Engineer
리포트 작성2026-08-05
작성 방식YouTube 영상 STT 변환 후 에디팅

💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.