지난 1년 동안 LLM이 사용자 인터페이스(UI)를 어떻게 재작성했는지에 대한 6부작 시리즈 중 Day 4입니다. Day 3에서는 A2UI를 활용한 선언적 명세 (declarative specs)를 다루었으며, 에이전트가 사용자의 프리미티브 (primitives)를 조합할 수는 있지만 사용자가 직접 구축하지 않은 것은 전달할 수 없다는 한계점에 도달했습니다.

자유 축의 끝단

Gen 1은 에이전트가 컴포넌트(components)를 _선택_하게 했습니다. Gen 2는 이를 _조합(compose)_하게 했습니다. Gen 3는 보조 바퀴를 떼어냅니다. 도구가 전체 상호작용형 UI 서피스 (entire interactive UI surface) — 실제 HTML, CSS, JavaScript — 를 전달하면, 호스트(host)가 이를 대화창 내에 렌더링합니다.

데이터 도구는 자체적인 상호작용형 차트를 렌더링할 수 있습니다. 예약 도구는 자체적인 좌석 배치도를 전달할 수 있습니다. 3D 모델링 도구는 실제 뷰포트 (viewport)를 임베드할 수 있습니다. 이 중 그 어떤 것도 채팅 클라이언트에 의해 미리 구축된 것이 아니며, 카드 및 리스트 프리미티브 (card-and-list primitives)로 표현할 수 있는 것도 아닙니다.

이것이 바로 MCP Apps가 표준화하는 것입니다. 그리고 이 기술만큼이나 흥미로운 것은 그 정치적 배경입니다. 해당 확장 기능 (SEP-1865)은 MCP-UI 제작자들과 OpenAI, 그리고 Anthropic이 공동으로 작성했습니다. AI 분야의 가장 큰 두 라이벌이 대화 내에 인터페이스를 배치하는 하나의 방식에 합의한 것입니다. ChatGPT, Claude, Goose, 그리고 VS Code 모두 지원 기능을 출시했습니다.

작동 방식

세 가지 요소:

1. 도구가 UI 리소스를 선언합니다. 일반적인 스키마 (schema)와 함께, 도구는 ui:// 스킴 (scheme)을 통해 HTML 리소스를 참조합니다:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"

const server = new McpServer({ name: "flight-server", version: "1.0.0" })
...

2. 호스트가 샌드박스 처리된 iframe 내에서 이를 렌더링합니다. 도구가 실행되면 클라이언트는 HTML 리소스를 가져와 제한된 권한(쿠키 사용 불가, 부모 DOM 접근 불가, 임의의 네트워크 접근 불가)으로 렌더링합니다.

3. iframe은 postMessage를 통해 JSON-RPC로 다시 통신합니다. 임베드된 UI는 도구의 결과를 읽고, 새로운 데이터가 도착함에 따라 업데이트하며, 심지어 후속 도구 호출 (tool calls)을 요청할 수도 있습니다. 모든 메시지는 호스트에 의해 로그가 기록되며, 모든 도구 호출은 호스트의 승인을 거쳐야 합니다.

// iframe 내부: 호스트가 전달하는 도구 결과(tool result)에 반응합니다
window.addEventListener("message", (event) => {
  const msg = event.data
...

만약 ChatGPT Apps를 사용해 보셨다면, 이는 동일한 아키텍처입니다. OpenAI의 Apps SDK(Skybridge 샌드박스 런타임 포함)는 커뮤니티의 MCP-UI 프로젝트와 함께 이 표준이 구축된 두 가지 토대 중 하나였습니다. 이제 ChatGPT는 호환성을 위해 MCP Apps를 지원합니다.

이번 세대가 본질적으로 다른 이유

Gen 1과 Gen 2는 중요한 속성을 유지했습니다: 화면의 모든 것이 사용자의 코드에서 나왔다는 점입니다. Gen 3는 이를 깨뜨립니다. 이제 픽셀은 사용자의 제품 내부에서 실행되는 **도구 개발자(tool developer)**의 코드에서 나옵니다.

이로 인해 MCP Apps는 컴포넌트 모델이라기보다 **대화 내부의 앱 스토어 (app store inside the conversation)**에 더 가깝게 됩니다. 채팅 클라이언트는 운영체제(OS)가 됩니다: 창(iframes)을 관리하고, IPC(postMessage를 통한 JSON-RPC)를 중개하며, 권한(샌드박스 플래그, 도구 호출 승인)을 강제합니다. 대화가 새로운 데스크톱이 되는 것입니다.

이러한 프레임워크는 처음에는 보수적으로 보이는 설계 선택들을 설명해 줍니다:

• 제한된 권한을 가진 샌드박스형 iframe (Sandboxed iframes) — 타인의 코드를 실행하기 때문입니다.
• 렌더링 전 선언된 리소스 및 사전 페치 (Declared resources, fetched ahead of render) — 호스트가 HTML을 보여주기 전에 검토할 수 있도록 하기 위함입니다.
• 로그 기록이 가능한 JSON-RPC를 통한 모든 통신 — 보이지 않는 사이드 채널(side channels)을 허용하지 않습니다.
• UI를 통한 호스트 제어형 도구 호출 (Host-gated tool calls from the UI) — 버튼 클릭 한 번으로 사용자의 돈이 몰래 소비될 수 없도록 합니다.

솔직한 트레이드오프 (The trade-offs, honestly)

	Gen 2 (A2UI)	Gen 3 (MCP Apps)
표현력 (Expressiveness)	당신의 프리미티브 (primitives), 어떤 배치든 가능	웹뷰 (webview)가 할 수 있는 모든 것
...

계획 단계에서 고려해야 할 두 가지 실질적인 고충(pain points)이 있습니다. 디자인 일관성 (Design consistency): 10개의 벤더로부터 온 10개의 도구는 하나의 대화 내에서 10개의 서로 다른 시각적 스타일을 의미합니다. 모바일 OS가 디자인 언어를 밀어붙였던 것처럼, 호스트(host)가 스타일링 가이드라인과 CSS 변수를 강제할 것을 예상해야 합니다. 보안 검토 (Security review): 샌드박스 (sandbox)가 피해 범위 (blast radius)를 제한하긴 하지만, 악의적이거나 침해된 도구 UI는 여전히 사용자를 오도할 수 있습니다. 예를 들어, 버튼에는 "취소"라고 적혀 있지만 실제로는 "승인"을 보내는 식입니다. 호스트는 모든 JSON-RPC 메시지를 기록할 수 있지만, 기록(logging)이 곧 방지(preventing)를 의미하지는 않습니다. 이제 신뢰의 대상은 모델뿐만 아니라 도구 개발자에게까지 확장됩니다.

야망이 아닌 신뢰 경계 (trust boundary)를 기준으로 세대를 선택하십시오. 본인의 앱 내에서 작동하는 인하우스 에이전트(in-house agent)라면 → Gen 1 또는 2를 사용하여 디자인 시스템을 온전하게 유지하십시오. 서드파티 도구를 호스팅하는 플랫폼이라면 → Gen 3가 유일한 현실적 선택지이며, 그에 따라 OS와 유사한 모든 책임이 뒤따릅니다.

다음 단계 (What's next)

내일은 버블(bubble)이나 iframe에 담기지 않는 모든 것을 다루며 시리즈를 마무리합니다. 캔버스 (canvas) 및 분기형 인터페이스 (branching interfaces), 사용자별로 형태를 바꾸는 적응형 UX (adaptive UX), 그리고 인터페이스가 런타임 (runtime)에 생성될 때 치러야 할 보안 비용에 대해 알아봅니다.

• Day 5: 채팅을 넘어 — 캔버스 인터페이스, 적응형 UX, 그리고 치러야 할 보안 비용

내일 뵙겠습니다.