요약 (TL;DR)

• 생성형 UI (Generative UI)는 AI 모델이 모든 화면을 하드코딩하는 대신 런타임 (runtime)에 인터페이스를 조립할 수 있게 합니다.
• 웹은 이미 이를 지원합니다 (Vercel AI SDK, Tambo, Google의 A2UI). 모바일은 네이티브 환경에서 지원하는 것이 거의 없습니다.
• React Native는 세 가지 방식으로 이를 가로막습니다: 깨진 스트리밍 (streaming), 비용이 많이 드는 중첩된 트리 (nested trees), 네이티브 에이전트 렌더러 (agent renderers)의 부재.
• 그래서 저는 iOS와 Android를 위한 오픈 소스 생성형 UI SDK인 Wire RN을 구축하고 있습니다.

먼저 짧은 버전부터 말씀드리자면: 웹에는 이미 생성형 UI를 위한 좋은 도구들이 있지만, 모바일에는 거의 없으며, 저는 기다리는 것에 지쳤습니다. 그래서 직접 만들고 있습니다. 더 긴 버전이 더 흥미로운 부분이며, 인터페이스가 어떻게 항상 변화해 왔는지에 대한 이야기부터 시작합니다.

인터페이스의 모든 시대는 동일한 방향으로 움직였습니다. 자세히 들여다보면 보일 것입니다.

명령줄 (Command lines)은 당신이 기계를 배우도록 만들었습니다. 정확한 구문이 필요했고, 관용이 없었습니다. 그래픽 UI (Graphical UI)는 그중 일부를 뒤집었습니다: 창 (windows), 마우스, 암기하는 대신 볼 수 있는 것들 말이죠. 터치 (Touch)는 더 나아갔고, 화면은 당신이 직접 조작하는 대상이 되었습니다. 그다음 채팅 (chat)이 등장했고, 당신은 원하는 것을 평이한 언어로 입력하기만 하면 되었습니다. 각 단계는 사용자의 부담을 소프트웨어로 조금씩 더 옮겨왔습니다.

생성형 UI (Generative UI)는 그 동일한 선상에 있는 다음 단계입니다. 그리고 지금까지 중 가장 큰 변화입니다.

infographic — the evolution of the interface (command line to graphical UI to touch to conversational to generative

저는 9년 차 React Native 엔지니어입니다. 지난 6개월 동안 매일 이 패턴을 사용하여 구축해 왔습니다. 제가 만들고 있는 SDK가 무엇인지, 그리고 왜 만드는지를 보여드리고 싶습니다. 살짝 맛보기로 보여드리겠습니다.

GIF — onboarding screen changing component type turn to turn, rendered live by the model

이 글 전체에서 다루는 패턴을 기반으로 구축한 제 앱의 흐름입니다. 모델이 다음에 무엇을 렌더링할지 결정하기 때문에, 턴(turn) 사이에 화면의 형태가 바뀝니다.

생성형 UI (Generative UI)란 실제로 무엇인가

생성형 UI (Generative UI)란 개발자가 모든 화면을 사전에 하드코딩(hard-coding)하는 대신, 모델이 런타임(runtime)에 인터페이스를 결정하는 것을 의미합니다. 모델은 컨텍스트(사용자의 마지막 답변, 히스토리, 작업 내용)를 읽고, "이 컴포넌트를 이러한 프롭스(props)와 함께 렌더링하라"고 말하는 구조화된 데이터(structured data)를 방출합니다. 여러분의 앱은 이를 실제 컴포넌트로 매핑합니다. 사용자는 구조화된 데이터를 절대 보지 못합니다. 그들은 옆 사람이 받은 화면과는 우연히 다른 화면을 보게 될 뿐입니다.

중요한 차이점은 이것이 챗봇(chatbot)이 아니라는 점입니다. 챗봇은 텍스트를 반환하고 사용자는 그것을 읽습니다. 생성형 UI는 인터페이스를 반환합니다. 사용자가 탭하고 타이핑하는 대상 말입니다. 모델은 화면 뒤에 존재합니다.

Google은 이제 거의 정확히 이러한 용어로 이를 정의합니다: 개발자에 의해 하드코딩되는 대신 AI에 의해 실시간으로 인터페이스가 구축되는 프론트엔드 아키텍처(front-end architecture). Google은 기존 방식을 "텍스트의 벽(wall of text)" 문제로 규정합니다. 모델은 추론하고 계획할 수 있었지만, 그 모든 것을 마크다운(markdown) 한 단락으로 압축해 버렸고, 생성형 UI는 바로 이 점을 해결합니다. 유능한 모델의 자연스러운 출력이 실제 인터페이스가 되도록 하는 것입니다.

왜 빅테크 기업들이 갑자기 관심을 갖는가

데이터가 이를 뒷받침하기 때문입니다. Google 자체 평가에 따르면, 사람들은 단순한 텍스트 답변보다 생성된 대화형 경험을 강력하게 선호합니다. 그리고 Google은 이 작업을 인터페이스가 고정된 앱 카탈로그에서 가져오는 대신 사용자에게 맞춤화되는, 완전히 AI가 생성하는 사용자 경험(user experiences)을 향한 첫 번째 단계라고 공개적으로 부르고 있습니다.

방금 그 부분을 다시 읽어보세요. 그들이 설명하는 최종 목표는 단순히 "더 나은 채팅 답변"이 아닙니다. 그것은 사용자별, 순간별로 스스로 조립되는 인터페이스이며, 사용자의 필요에 따라 개인화되고, 고정된 앱 카탈로그가 온디맨드(on-demand)로 생성되는 무언가로 해체되는 것입니다. Android와 Chrome을 소유한 회사가 이를 방향성으로 명시했다면, 모바일 팀들은 주목해야 합니다.

이 분야를 선도하는 웹 라이브러리 중 하나인 Tambo는 동일한 개념을 더 쉬운 언어로 표현합니다: 과거에는 우리가 소프트웨어에 적응했다면, 이제는 소프트웨어가 우리에게 적응합니다.

웹 기업들이 이미 배포하고 있는 것들

이 부분은 모바일 개발자들에게 불편한 지점입니다. 웹에서 생성형 UI (Generative UI)는 이미 이론을 넘어섰습니다. npm으로 설치가 가능합니다. 알아둘 만한 주요 플레이어들은 다음과 같습니다:

• **Vercel의 AI SDK**는 모델의 도구 호출 (tool calls)을 React 컴포넌트에 직접 연결합니다. 모델이 도구를 호출하면 도구가 데이터를 반환하고, 그 결과가 텍스트 문자열 대신 컴포넌트에 연결됩니다.
• **Tambo**는 이 패턴의 가장 명확한 템플릿입니다. React 컴포넌트를 Zod 스키마 (schemas)로 등록하면, 에이전트 (agent)가 자연어로부터 어떤 컴포넌트를 렌더링할지 선택합니다. Zod는 런타임 (runtime)에 props를 검증하므로, 잘못된 형식이 출력되더라도 렌더링에 도달하기 전에 포착됩니다. 프로덕션 환경에서 "undefined is not a function" 오류를 겪을 일이 없습니다. 다만 주의할 점은, 이것이 React 전용이며 "기타 프레임워크"에는 여러분의 휴대폰이 실행하는 프레임워크가 포함된다는 것입니다.
• **CopilotKit의 AG-UI**는 선언적 (declarative) 중간 지점을 향해 나아갑니다. 에이전트가 자유 형식의 코드를 내보내는 대신 카드, 리스트, 폼, 위젯의 구조화된 명세 (spec)를 내보내므로, 하나의 명세로 React, 모바일, 데스크톱 전체에서 렌더링할 수 있습니다.
• Google의 A2UI (a2ui.org)는 해당 아이디어의 오픈 프로토콜 버전입니다. 에이전트가 선언적인 컴포넌트 설명을 보내면, 클라이언트가 자체적인 네이티브 위젯 (native widgets)으로 이를 렌더링합니다.

지금까지 출시된 참조 렌더러 (reference renderers)로는 Angular, Flutter, Lit, 그리고 웹 컴포넌트 (web components)가 있습니다. React Native는 이 목록에 포함되어 있지 않습니다.

레지스트리-플러스-스키마 (registry-plus-schema) 패턴은 이들 모두를 관통하는 핵심 요소이며, 이것이 바로 이 방식을 안전하게 출시할 수 있게 만드는 핵심입니다. 모델은 런타임 (runtime)에 UI 코드를 작성하는 것이 아닙니다. 모델은 여러분의 컴포넌트가 이미 정의해 놓은 양식 (forms)을 채우는 것입니다. 흐름 (flow)에 대해서는 창의적인 자유를 갖지만, 컴포넌트가 무엇인지에 대해서는 자유가 전혀 없습니다.

infographic — how generative UI stays safe (user context to model to schema gate to native render, with a fallback branch

Gemini 모먼트 (The Gemini moment)

그다음은 이제 모두가 실제로 목격한 사례입니다.

Gemini는 두 가지 실험으로서 자체 앱에 생성형 UI (generative UI)를 출시했습니다. Dynamic View는 에이전트 기반 코딩 (agentic coding)을 사용하여 프롬프트당 완전히 맞춤화된 대화형 응답을 설계하고 코딩합니다. Visual Layout은 사진과 대화형 모듈이 포함된 잡지 스타일의 멀티모달 (multimodal) 응답을 생성합니다. 로마로의 3일 여행 계획을 요청하면, 여러 차례의 대화를 통해 실제로 탐색하고 조정할 수 있는 시각적인 여정 (itinerary)을 받게 됩니다. 텍스트의 벽이 아니라, 구축된 결과물입니다.

Gemini가 답변이 아닌 인터페이스를 생성하고 있습니다. 이미지와 대화형 단계들이 채팅 자체에 구축됩니다. 이것이 대부분의 사람들이 처음 접하게 될 버전이며, 이것이 정확히 어떻게 작동하는지 아는 것은 가치가 있습니다.

여기서 우리에게 중요한 부분이 있습니다. Gemini의 모바일 경험조차도 모델이 HTML, CSS, JavaScript를 작성하고 이를 앱 셸 (app shell) 내에서 렌더링하는 방식입니다. 실시간으로 웹 코드를 생성하여 앱 내부에서 보여줍니다. 인상적입니다. 하지만 그것은 앱 내에 표시되는 '생성된 웹'일 뿐입니다. 그것은 네이티브 컴포넌트 (native components), 여러분의 디자인 시스템 (design system), 또는 오프라인 동작 (offline behavior)이 아닙니다. 그리고 바로 그 지점이 모바일의 진짜 문제가 존재하는 곳입니다.

그렇다면 왜 모바일은 여전히 뒤처져 있는가?

왜냐하면 제대로 작동하는 모든 생성형 UI (Generative UI) 라이브러리는 웹 형태(web-shaped)로 설계되어 있으며, 모바일은 이러한 웹 중심의 가정을 엄격하게 제한하기 때문입니다. 여러분이 마주하게 될 세 가지 장벽은 다음과 같습니다.

• 스트리밍 (Streaming)이 작동하지 않습니다. React Native의 Hermes 엔진은 fetch에서 ReadableStream을 구현하지 않습니다. response.body.getReader()를 통해 토큰을 스트리밍하는 모든 LLM SDK는 실제 기기에서 작동이 중단됩니다. OpenAI, Anthropic, Google 모두 마찬가지입니다. 모든 모바일 AI 개발자가 가장 먼저 배우는 사실은, 모델 제공업체의 자체 퀵스타트(quickstart) 코드가 자신의 휴대폰에서는 돌아가지 않는다는 점입니다.
• 재귀적 컴포넌트 트리 (Recursive component trees)는 비용(tax)입니다. 웹 생성형 UI는 중첩된 트리를 생성합니다. 예를 들어, Button을 포함하는 Row를 포함하는 Card와 같은 구조입니다. 모바일에서는 이러한 재귀 구조가 검증(validation) 작업을 배가시키고, 스트리밍 도중 JS 스레드(JS thread)에 과부하를 주며, 모델이 새로운 프롭(prop)을 만들어낼 수 있는 지점을 더 많이 제공합니다. 모델은 평면적인 구조보다 깊게 중첩된 구조에서 성능이 눈에 띄게 저하됩니다. 토큰 비용은 상승하고, 잘못된 형식의 출력(malformed output)도 함께 증가합니다.
• 에이전트 레일 (Agent rails)이 없습니다. 에이전트 프로토콜(A2A, AG-UI, Google의 A2UI)은 웹 우선(web-first)으로 설계되었습니다. A2UI는 Angular, Flutter, Lit 및 웹을 위한 네이티브 렌더러를 제공합니다. 만약 오늘 당장 에이전트가 네이티브 React Native 화면을 제어하게 만들고 싶다면, 어댑터(adapter)를 직접 작성해야 합니다.

그리고 2026년 현재 모바일이 실제로 무엇을 가지고 있는지 보십시오. "최고의 React Native UI 라이브러리" 목록은 모두 Tamagui, NativeWind, gluestack, Restyle와 같은 정적 키트(static kits)뿐입니다. 훌륭한 컴포넌트 라이브러리들이지만, 그중 생성형(generative)인 것은 단 하나도 없습니다. 모바일에는 웹에서처럼 이 카테고리가 아직 존재하지 않습니다.

그래서 모바일 팀들은 항상 그렇듯 행동합니다. 폴리필(polyfill)을 패치하고, 스트리밍을 포기하며, JSON-to-component 매퍼를 직접 구현하다가, 의도치 않게 1,200줄의 글루 코드(glue code)를 작성하게 됩니다. 제가 이 수치를 정확히 아는 이유는 2024년에 클라이언트를 위해 그 글루 코드를 직접 작성했기 때문이며, 모델이 프롭(prop) 이름을 새로 만들어낼 때마다 코드가 깨졌기 때문입니다.

이 문제가 얼마나 심각할까요?

구축 단계로 넘어가기 전에 시야를 넓혀볼 가치가 있습니다. 디자이너 Andy Budd는 최근 자율주행 자동차에 사용하는 자율성 단계(autonomy levels)의 비유를 빌려와 "적응형 소프트웨어 (adaptive software)"의 사다리를 스케치했습니다. 맨 아래 단계에서는 인간이 모든 화면을 작성합니다. 꼭대기에 가까워질수록 제품은 단 하나의 최적의 버전을 배포하는 것을 멈추고, 사용자 클러스터별로, 나아가 결국 개인별, 세션별, 작업별로 서로 다른 경험을 조립하기 시작합니다. 저에게 깊은 인상을 남긴 재정의는 그의 관점입니다. 질문은 "이 플로우(flow)의 가장 좋은 버전은 무엇인가?"에서 "누구에게 가장 좋은가?"로 바뀝니다. 그 끝단에 이르면, 각각의 상호작용(interaction) 자체가 하나의 독립적인 디자인 문제가 됩니다.

그는 또한 그 함정(catch)에 대해서도 언급했는데, 이는 매우 실질적인 문제입니다. 당신의 요구에 적응할 수 있는 제품은 당신의 약점에도 똑같이 쉽게 적응할 수 있습니다. 개인화(Personalization)와 조작(manipulation)은 동일한 엔진으로 작동합니다. 사용자 요구에 따라 인터페이스를 조립하는 모든 것은 무엇을 최적화할 수 있는지, 그리고 누구의 이익을 위해 최적화해야 하는지에 대한 규칙이 필요합니다. 이것은 모바일의 문제나 웹의 문제가 아닙니다. 이것은 "우리가 갑자기 이것을 할 수 있게 되었다"는 문제이며, 누군가 먼저 규칙을 작성하든 그렇지 않든 나타나게 됩니다.

여기서 다시 제가 다루는 영역으로 연결됩니다. 하드코딩된 화면으로는 그 사다리의 꼭대기에 도달할 수 없습니다. 사용자별, 세션별 인터페이스는 검증된 컴포넌트(component)로부터 런타임(runtime)에 UI를 구축하는 시스템이 필요하며, 그 메커니즘이 바로 생성형 UI (generative UI)의 본질입니다. 웹에는 그것이 있습니다. 하지만 우리가 다루었듯이, 모바일에는 대부분 없습니다. 이것이 제가 메우고자 하는 간극입니다.

그래서 저는 이것을 구축하고 있습니다

저는 제가 계속 필요로 했던 것을 만들고 있습니다. React Native를 기반으로 구축된 iOS 및 Android용 오픈 소스 생성형 UI SDK입니다. Wire RN입니다.

웹 라이브러리들이 증명한 것과 동일한 핵심 패턴을 따릅니다. 컴포넌트의 고정된 레지스트리(registry), 모델과 화면 사이의 엄격한 스키마 검증(schema validation), 모델이 플로우를 선택하되 컴포넌트를 새로 만들어내지는 않는 방식입니다. 하지만 이를 둘러싼 환경이 아닌, 위에서 언급한 제약 조건(walls)에 맞춰 구축되었습니다.

• Hermes에서도 생존하는 스트리밍 (Streaming that survives Hermes): 실제 기기에서 토큰 스트리밍 (token streaming)이 실제로 작동합니다.
• 재귀적 트리 (recursive trees) 대신 평면적 컴포넌트 (Flat components): 모바일 화면은 어차피 순차적이며, 평면적인 구조에서 모델의 오류가 더 적게 발생하기 때문입니다.
• 당신이 소유하는 레지스트리 (registry): 브랜드, 디자인 시스템 (design system), 그리고 접근성 (accessibility)이 결코 당신의 통제를 벗어나지 않습니다.

저는 먼저 제 앱의 온보딩 (onboarding) 과정을 이를 통해 다시 구축했습니다.