Generative UI란 무엇인가? (그리고 왜 텍스트 출력만으로는 충분하지 않은가)

대부분의 AI 앱은 여전히 모델의 응답을 텍스트로 취급합니다.

그것은 이해할 수 있는 일입니다. 텍스트는 LLM (Large Language Model)의 기본 출력 형식입니다. 스트리밍하기 쉽고, 로그를 남기기 쉬우며, 복사하기 쉽고, 채팅 버블에 표시하기 쉽습니다. 사용자가 설명, 요약, 초안 또는 코드 조각을 요청한다면 텍스트는 종종 적절한 인터페이스가 됩니다.

하지만 많은 실제 소프트웨어 작업은 단순히 답변을 읽는 것에 그치지 않습니다. 옵션을 비교하고, 필드를 편집하며, 변경 사항을 승인하고, 데이터를 검사하며, 작업 간에 선택하고, 워크플로 (Workflow)를 따라 이동하는 과정입니다. 이러한 작업들은 LLM이 그것들을 한 단락의 글로 설명할 수 있다고 해서 단순해지지 않습니다.

그것이 바로 Generative UI가 메우려고 노력하는 간극입니다.

Generative UI는 AI 시스템이 사용자가 완료하려는 작업에 대해 단순한 텍스트 응답뿐만 아니라 인터페이스를 생성하도록 하는 관행입니다. 모델은 여전히 언어로 추론하지만, 제품의 출력물은 표, 양식, 차트, 카드 레이아웃, 확인 단계 또는 애플리케이션이 렌더링(Rendering)할 줄 아는 컴포넌트(Component)들로 조립된 다단계 워크플로가 될 수 있습니다.

요약하자면:

Generative UI는 AI의 출력을 일반 텍스트 대신 상호작용 가능한 제품 UI로 제공하는 것입니다.

단순하게 들릴 수 있습니다. 중요한 점은 이것이 '무엇이 아닌가'입니다.

Generative UI는 "모델이 임의의 React 코드를 작성하게 하는 것"이 아닙니다. 무작위 레이아웃 생성기도 아닙니다. 제품 디자인이나 프론트엔드 엔지니어링 (Frontend Engineering)을 대체하는 것도 아닙니다. 훌륭한 Generative UI 시스템은 모델에게 제어된 인터페이스 프리미티브 (Interface Primitives) 어휘를 제공하고, 사용자의 의도, 사용 가능한 데이터 및 애플리케이션 컨텍스트 (Context)를 기반으로 모델이 이러한 프리미티브를 구성할 수 있도록 합니다.

왜 텍스트가 기본값이었는가

AI 제품의 첫 번째 물결은 채팅 인터페이스를 모방했습니다. 채팅이 LLM이 작동하는 방식과 일치하기 때문입니다. 프롬프트 (Prompt)가 입력되면, 토큰 (Token)이 출력됩니다. UI는 해당 토큰이 도착하는 대로 스트리밍할 수 있습니다.

사용자의 목표가 정보 제공(Informational)인 경우에는 해당 모델이 잘 작동합니다:

"이 오류를 설명해줘."
"이 회의 내용을 요약해줘."
"후속 이메일을 작성해줘."
"SQL 쿼리를 생성해줘."

답변은 단락, 목록, 또는 코드 블록 (Code block) 형태가 될 수 있습니다. 사용자는 이를 읽고, 복사하거나, 후속 질문을 던집니다.

문제는 사용자의 목표가 운영(Operational)인 경우에 시작됩니다:

"이 업체들을 비교해줘."
"환불 요청을 생성해줘."
"주의가 필요한 계정들을 보여줘."
"배포 승인을 준비해줘."
"이 대시보드에서 이상 징후를 찾아줘."

이러한 작업들의 경우, 텍스트의 벽 (Wall of text)은 실제 작업에 대한 손실이 있는 표현 (Lossy representation)인 경우가 많습니다. 올바른 정보를 포함하고 있을 수는 있지만, 사용자에게 적절한 제어권 (Controls)을 제공하지는 못합니다.

마크다운 표 (Markdown table)는 데이터 그리드 (Data grid)가 아닙니다. 글머리 기호 목록 (Bullet list)은 워크플로 (Workflow)가 아닙니다. 행동을 권장하는 단락은 권한, 컨텍스트 (Context), 그리고 감사 가능성 (Auditability)을 갖춘 확인 UI (Confirmation UI)와 동일하지 않습니다.

핵심 아이디어 (The Core Idea)

Generative UI는 다른 가정에서 시작합니다. 모델이 항상 산문 (Prose)으로 답변해서는 안 된다는 것입니다. 모델은 작업에 가장 적합한 인터페이스 형태 (Interface shape)로 답변해야 합니다.

사용자가 비교를 요청하면, 비교 표를 생성합니다.

사용자가 무언가를 제출하기를 요청하면, 양식 (Form)을 생성합니다.

사용자가 무엇이 변경되었는지 묻는다면, 보조 지표 (Metrics)가 포함된 요약을 생성합니다.

사용자가 위험한 행동을 취하려 한다면, 명시적인 확인 절차가 포함된 검토 화면 (Review screen)을 생성합니다.

모델은 여전히 LLM이 잘하는 일을 수행하고 있습니다. 즉, 의도 (Intent)를 해석하고, 관련 정보를 선택하며, 다음에 무엇이 올지 결정하는 것입니다. 차이점은 최종 응답이 단일한 텍스트 형태의 파이프 (Text-shaped pipe)를 통해 강제로 출력되지 않는다는 점입니다.

실제로 Generative UI 시스템은 보통 다섯 가지 부분으로 구성됩니다:

모델이 사용할 수 있도록 허용된 컴포넌트 라이브러리 (Component library),
해당 컴포넌트들을 설명하는 프롬프트 (Prompt) 또는 스키마 (Schema),
구조화된 UI 기술 (Structured UI description)을 방출하는 모델,
해당 기술을 실제 UI로 변환하는 파서 (Parser) 또는 렌더러 (Renderer),
데이터, 상태 (State), 권한 (Permissions), 그리고 액션 (Actions)을 위한 애플리케이션 핸들러 (Application handlers).

그러한 아키텍처(Architecture)가 중요한 이유는 모델을 제품 경계(Product boundaries) 내에 유지하기 때문입니다. 모델은 테이블(Table)이나 폼(Form)을 선택할 수 있지만, 무엇이 유효한 테이블이나 폼인지는 여전히 애플리케이션이 제어합니다.

동일한 프롬프트, 두 가지 출력

지원 에이전트(Support agent)가 다음과 같이 요청한다고 가정해 봅시다:

주문 ORD-18392에 대한 환불 요청을 생성해줘.

동일한 입력 프롬프트(Input prompt)가 매우 다른 두 가지 제품 경험으로 이어질 수 있습니다.

텍스트 전용(Text-only) 어시스턴트는 다음과 같이 응답할 수 있습니다:

읽을 수는 있지만, 인터페이스(Interface)라고 하기에는 부족합니다. 에이전트는 여전히 요약 내용을 신뢰해야 하고, 다른 시스템으로 이동하여 금액을 확인하고, 필요한 경우 사유를 변경하며, 실제 승인 액션(Approval action)을 다른 곳에서 수행해야 합니다.

생성형 UI (Generative UI) 응답은 동일한 프롬프트에 대해 대화형 폼(Interactive form)으로 답할 수 있습니다:

root = Stack([header, orderInfo, sep1, formCard, callout])
header = Card([cardHeader], "clear")
cardHeader = CardHeader("Refund Request", "Submit a refund request for your order")
...

입력 프롬프트는 바뀌지 않았습니다. 출력 계약(Output contract)이 바뀐 것입니다.

텍스트 전용 버전에서 모델은 환불 요청을 설명합니다. 생성형 UI 버전에서 모델은 승인된 컴포넌트(Components)들, 즉 제목, 폼, 편집 가능한 필드(Editable fields), 선택 메뉴(Select menu), 그리고 액션 버튼(Action buttons)을 사용하여 검토 가능한 표면(Surface)을 구성합니다. submit:refund-request 또는 action:cancel이 실제로 무엇을 수행할지는 여전히 애플리케이션이 결정합니다.

OpenUI를 통해 렌더링(Rendered)되면, 동일한 구조화된 응답이 제품 네이티브 폼(Product-native form)이 됩니다:

다음은 동일한 OpenUI 응답이 채팅 인터페이스에서 생성되고 렌더링되는 모습입니다:

이 예제는 OpenUI Lang을 사용하지만, 이 개념은 하나의 문법보다 더 광범위합니다. 중요한 변화는 모델이 구조화된 인터페이스 설명(structured interface description)을 반환한다는 점입니다. 애플리케이션은 알려진 컴포넌트(components)를 사용하여 해당 설명을 렌더링하며, 각 액션(actions)이 실제로 무엇을 수행할지 결정합니다.

Dynamic UI와의 차이점

개발자들은 수십 년 동안 다이내믹 UI (Dynamic UI)를 구축해 왔습니다. 피처 플래그 (Feature flags), 조건부 렌더링 (conditional rendering), CMS 기반 페이지, 대시보드, 그리고 폼 빌더 (form builders) 모두 데이터로부터 인터페이스를 생성합니다.

Generative UI는 사용자 의도(user intent)에 따라 런타임(runtime)에 인터페이스가 선택된다는 점에서 다릅니다.

전통적인 다이내믹 UI는 다음과 같이 말할 수 있습니다:

사용자가 관리자라면, 관리자 패널을 보여줘라.

Generative UI 시스템은 다음과 같이 말할 수 있습니다:

사용자가 분기별 파이프라인 리스크를 비교해 달라고 요청하고 있습니다. 이 제품이 허용하는 컴포넌트들을 사용하여 테이블, 몇 개의 메트릭 카드 (metric cards), 그리고 후속 액션 (follow-up actions)을 생성하세요.

차이점은 Generative UI가

도구 호출 (tool calling)이 AI와 백엔드 시스템 사이의 가교라면, Generative UI는 AI와 제품 경험 (product experience) 사이의 가교입니다.

이것이 AI 제품에 중요한 이유

AI 시스템의 역량이 커질수록, UI 문제는 더욱 명확해집니다.

어시스턴트가 단순한 질문에만 답할 수 있을 때는 채팅 버블 (chat bubble)만으로 충분합니다. 하지만 어시스턴트가 비즈니스 데이터를 조사하고, 옵션을 비교하며, 워크플로우 (workflow)를 준비하고, 변경 사항을 권장할 수 있게 되면, 출력값은 더 많은 구조를 갖춰야 합니다.

텍스트는 몇 가지 반복적인 문제를 일으킵니다:

산문 (prose) 속에 구조를 숨깁니다.
비교를 필요 이상으로 어렵게 만듭니다.
워크플로우를 제어 수단 (controls)이 아닌 지침 (instructions)으로 변질시킵니다.
위험한 액션 (actions)을 검토하기 어렵게 만듭니다.
사용자가 시스템 간에 정보를 복사하도록 강제합니다.

Generative UI가 채팅의 필요성을 없애는 것은 아닙니다. 많은 제품에서 채팅은 여전히 최고의 입력 방식입니다. 사용자는 자연어로 의도를 설명할 수 있습니다. 차이점은 출력값이 제품 네이티브 (product-native)가 될 수 있다는 점입니다.

미래의 형태는 "모든 것에 텍스트로 답하는 챗봇"이라기보다 "텍스트만으로는 부족할 때 적절한 작업 공간 (working surface)을 생성하는 어시스턴트"에 더 가깝습니다.

OpenUI의 위치

OpenUI는 이 아이디어를 구체적으로 구현한 사례입니다.

OpenUI GitHub 저장소는 이를 OpenUI Lang(컴팩트한 스트리밍 우선 언어), React 런타임 (runtime), 내장된 컴포넌트 라이브러리 (component libraries), 그리고 채팅/앱 인터페이스를 중심으로 구축된 풀스택 Generative UI 프레임워크로 설명합니다. 문서에는 다음과 같은 기본 흐름이 설명되어 있습니다:

컴포넌트 라이브러리를 정의하거나 재사용합니다.
해당 라이브러리로부터 모델 지침 (model instructions)을 생성합니다.
해당 지침을 모델로 전송합니다.
OpenUI Lang을 클라이언트로 다시 스트리밍합니다.
React 렌더러 (renderer)를 통해 점진적으로 렌더링합니다.

이러한 설계는 두 가지 흔한 극단적인 상황을 피할 수 있기 때문에 중요합니다.

한쪽에서는, 일반 텍스트가 너무 제한적입니다. 사용자가 수동으로 작업을 수행하게 만들지 않고서는 풍부한 상호작용 (interaction)을 표현할 수 없습니다.

다른 한쪽에서는, 모델에게 임의의 프론트엔드 코드 (frontend code)를 생성하도록 요청하는 것은 대부분의 프로덕션 애플리케이션 (production applications)에 있어 너무 느슨합니다.

OpenUI는 그 중간에 위치합니다. 모델은 개발자가 정의하거나 허용한 컴포넌트(components)에 의해 제약되는 압축된 UI 언어를 방출(emit)합니다. 렌더러(renderer)는 해당 출력을 실제 React 컴포넌트로 매핑합니다. 데이터 액세스(data access), 상태(state), 권한(permissions), 그리고 액션 동작(action behavior)에 대한 책임은 여전히 애플리케이션에 있습니다.

이것이 AI 네이티브 인터페이스(AI-native interfaces)를 위한 더 건강한 계약(contract)입니다. 제품에 유연성이 필요한 곳에서는 생성적(generative)이고, 제품에 안전성이 필요한 곳에서는 통제된(controlled) 방식입니다.

OpenUI는 또한 스트리밍(streaming)에 집중합니다. 이는 모델이 생성한 인터페이스가 무언가 나타나기 전에 전체 JSON 블롭(JSON blob)이 완료될 때까지 기다려야 하는 것처럼 느껴져서는 안 되기 때문에 중요합니다. 행 지향 형식(line-oriented format)을 사용하면 모델이 출력을 방출함에 따라 점진적으로 파싱(parse)하고 렌더링(render)할 수 있습니다.

개발자가 설계해야 할 것

만약 여러분이 생성적 UI(generative UI)를 사용하여 구축하고 있다면, 주요 설계 질문이 바뀝니다.

단순히 "어떤 화면을 만들어야 하는가?"라고 묻는 대신, 다음과 같이 질문해야 합니다:

모델이 조합할 수 있도록 허용된 인터페이스 어휘(interface vocabulary)는 무엇인가?

그 어휘에는 다음과 같은 것들이 포함될 수 있습니다:

지표 카드 (metric cards)
테이블 (tables)
양식 (forms)
차트 (charts)
추천 카드 (recommendation cards)
확인 패널 (confirmation panels)
탭 (tabs)
단계별 워크플로 (step-by-step workflows)
그리고 액션 버튼 (action buttons)

목표는 모델이 여러분의 제품 UI를 처음부터 스스로 발명하게 두는 것이 아닙니다. 목표는 제품의 실제 워크플로(workflows)와 일치하는 안전한 프리미티브(primitives) 세트를 모델에게 제공하는 것입니다.

이는 프론트엔드(frontend) 작업을 덜 중요하게 만드는 것이 아니라, 오히려 더 중요하게 만듭니다. 누군가는 여전히 좋은 컴포넌트를 설계하고, 프롭 계약(prop contracts)을 정의하며, 빈 상태(empty states)와 에러 상태(error states)를 처리하고, 액션을 연결하며, 권한을 강제하고, 생성된 UI가 어디에 적절할지 결정해야 합니다.

생성적 UI는 일부 조합(composition) 결정을 런타임(runtime)으로 이동시킵니다. 그것이 엔지니어링적 판단(engineering judgment)을 제거하는 것은 아닙니다.

실질적인 정의

제가 팀과 함께 사용할 정의는 다음과 같습니다:

생성적 UI(Generative UI)란, AI 시스템이 사용자의 의도(intent)와 현재 컨텍스트(context)를 기반으로, 통제된 컴포넌트 어휘(component vocabulary)로부터 구조화되고 상호작용 가능한 인터페이스를 생성하는 패턴이다.

그 정의는 가공되지 않은 텍스트(raw text), 임의의 코드 생성(arbitrary code generation), 그리고 정적 템플릿(static templates)을 제외합니다. 대신 실제 적용 시 중요한 요소들인 구조(structure), 상호작용(interaction), 제약 조건(constraints), 문맥(context), 그리고 렌더링(rendering)을 포함합니다.