대부분의 AI 제품은 채팅창(Chatbox)에서 시작합니다.

그것은 타당합니다. 채팅은 유연하고, 친숙하며, 빠르게 출시할 수 있기 때문입니다.

하지만 저는 채팅이 AI 제품의 최종 인터페이스(Interface)라고 생각하지 않습니다.

그것은 시작점일 뿐입니다.

사용자가 단순히 답변만을 필요로 할 때는 텍스트로도 충분합니다. 하지만 옵션을 비교하거나, 데이터를 검토하거나, 워크플로(Workflow)를 구성하거나, 작업을 승인하거나, 출력을 검사해야 할 때, 문단 형태의 텍스트는 종종 적절하지 않은 표면(Surface)이 됩니다.

그 지점에서 Generative UI (생성형 UI)가 흥미로워집니다.

나의 실질적인 정의

Generative UI란 AI 시스템이 사용자의 의도(Intent), 사용 가능한 데이터, 그리고 도구(Tool)의 결과에 기반하여 인터페이스를 렌더링(Render)하도록 돕는 것을 말합니다.

때로는 적절한 인터페이스가 여전히 텍스트일 수도 있습니다.

때로는 다음과 같을 수도 있습니다:

• 표 (Table)
• 양식 (Form)
• 체크리스트 (Checklist)
• 타임라인 (Timeline)
• 승인 패널 (Approval panel)
• 대시보드 (Dashboard)
• 카드 레이아웃 (Card layout)
• 워크플로 맵 (Workflow map)

중요한 점은 UI를 챗봇보다 더 인상적으로 보이게 만드는 것이 아닙니다.

중요한 점은 사용자에게 검사, 편집, 승인 또는 실행할 수 있는 표면(Surface)을 제공하는 것입니다.

간단한 예시

사용자가 다음과 같이 질문한다고 가정해 봅시다:

이번 주에 가장 위험한 판매 거래(Sales deals)는 무엇인가요?

일반적인 챗봇은 긴 설명을 반환할 수 있습니다.

Generative UI 워크플로는 더 유용한 작업을 수행할 수 있습니다:

1. 사용자의 의도(Intent)를 감지합니다.
2. CRM 또는 데이터베이스 도구를 호출합니다.
3. 실제 거래 데이터를 가져옵니다.
4. 위험한 거래의 순위를 매깁니다.
5. 위험 카드, 이유, 담당자, 다음 조치 및 승인 버튼을 렌더링합니다.

이제 답변은 더 이상 단순한 텍스트가 아닙니다.

답변은 하나의 인터페이스가 됩니다.

위험한 멘탈 모델 (Mental Model)

Generative UI의 위험한 버전은 다음과 같습니다:

프롬프트(Prompt) -> AI가 임의의 UI를 작성함 -> 앱이 이를 렌더링함

이 방식은 프로토타입(Prototype)에는 유용할 수 있지만, 프로덕션(Production) 비즈니스 소프트웨어의 기본 패턴으로 사용하고 싶지는 않습니다.

만약 모델이 런타임(Runtime)에 어떤 UI든 만들어낼 수 있다면, 제품은 다음과 같은 요소들에 대한 통제력을 잃을 수 있습니다:

• 어떤 컴포넌트(Component)가 허용되는가
• 어떤 작업이 안전한가
• 어떤 데이터가 보이는가
• 어떤 단계에 승인이 필요한가
• 출력이 유효하지 않을 때 어떤 폴백(Fallback)이 나타나는가
• 결과가 어떻게 기록되거나 검토되는가

Dynamic UI (동적 UI)는 시스템이 여전히 명확한 경계(Boundaries)를 가지고 있을 때만 유용합니다.

더 안전한 프로덕션 패턴

더 안전한 멘탈 모델 (Mental Model)은 다음과 같습니다:

사용자 의도 (user intent)
-> 도구/데이터 접근 (tool/data access)
-> 구조화된 UI 명세 (structured UI spec)
...

다시 말해:

AI는 구성(Compose)합니다.

제품(Product)은 규칙을 소유합니다.

이는 제가 현재 Generative UI 시스템에서 보고 있는 방향과 일치합니다:

• Vercel AI SDK는 도구 결과(tool results)가 UI 컴포넌트로 전달되는 모습을 보여줍니다.
• OpenAI Apps SDK는 ChatGPT 앱을 위해 구조화된 도구 결과와 컴포넌트 템플릿을 사용합니다.
• LangChain의 프론트엔드 문서는 컴포넌트 카탈로그와 JSON으로 렌더링되는 UI 명세를 설명합니다.
• A2UI는 임의의 코드 실행 대신 선언적 UI 기술(declarative UI descriptions)에 집중합니다.

세부 사항은 스택(Stack)마다 다르지만, 근본적인 아이디어는 유사합니다:

AI가 인터페이스에 영향을 미치게 하되, 렌더링은 제품이 정의한 제약 조건(Constraints) 내에서 유지하십시오.

UI 명세(UI spec)의 모습

모델에게 임의의 마크업(Markup)을 생성하도록 요청하는 대신, 앱은 제약이 있는 UI 객체(UI object)를 요청할 수 있습니다.

예를 들어:

type UIBlock =
  | {
      type: "risk_card";
...

그러면 모델이나 에이전트(Agent)는 다음과 같은 것을 반환할 수 있습니다:

{
  "type": "risk_card",
  "props": {
...

프론트엔드는 임의의 코드를 렌더링하지 않습니다.

객체를 검증(Validate)하고, 제품이 이미 제어하고 있는 컴포넌트로 이를 렌더링합니다.

스키마 검증(Schema validation)은 필요하지만, 그것만으로는 충분하지 않습니다

유효한 UI 스키마가 있다고 해서 UI가 자동으로 안전하다는 의미는 아닙니다.

스키마 검증은 다음 질문에 답할 수 있습니다:

• 컴포넌트 유형이 허용되는가?
• Props(속성)의 형태가 올바른가?
• 필수 필드가 존재하는가?

하지만 프로덕션 시스템은 다음과 같은 질문도 던져야 합니다:

• 이 사용자가 이 데이터를 볼 권한이 있는가?
• 이 동작을 자동으로 실행하는 것이 안전한가?
• 이 워크플로우에 사람의 승인이 필요한가?
• 이 권장 사항이 실제 도구 데이터에 근거(Grounded)하고 있는가?
• 신뢰 수준(Confidence level)이 정직하게 표현되었는가?
• 출력이 검증에 실패할 경우 폴백(Fallback)이 있는가?
• 나중에 발생한 일을 감사(Audit)할 수 있는가?

형태 검증(Shape validation)은 첫 번째 관문입니다.

그것이 안전 시스템의 전부는 아닙니다.

컴포넌트 카탈로그 (Component catalogs)의 중요성

AI가 유용한 UI를 생성하기를 원한다면, 좋은 시작 질문은 다음과 같지 않습니다:

AI가 어떻게 모든 화면을 디자인할 수 있을까?

더 나은 질문은 다음과 같습니다:

AI가 어떤 컴포넌트 (Components)를 사용할 수 있도록 허용할 것인가?

예를 들어, 내부 워크플로 (Workflow) 도구는 다음과 같은 것들을 허용할 수 있습니다:

• RiskCard
• DataTable
• Timeline
• ApprovalPanel
• WorkflowStepList
• ActionSummary

각 컴포넌트는 다음을 갖추어야 합니다:

• 프롭 스키마 (prop schema)
• 허용된 액션 (allowed actions)
• 권한 규칙 (permission rules)
• 로딩 및 에러 상태 (loading and error states)
• 폴백 동작 (fallback behavior)
• 로깅 요구사항 (logging requirements)

이것이 바로 모델에게 무제한의 권한을 부여하지 않으면서도 시스템이 유연성을 얻는 방법입니다.

Generative UI가 유용한 곳

저는 Generative UI가 사용자가 단순히 읽는 것 이상의 작업을 수행해야 하는 워크플로 (Workflows)에서 특히 유용하다고 생각합니다:

• 영업 파이프라인 검토 (sales pipeline review)
• 지원 티켓 분류 (support ticket triage)
• 내부 운영 대시보드 (internal operations dashboards)
• 재무 승인 흐름 (finance approval flows)
• AI 자동화 빌더 (AI automation builders)
• 문서 검토 시스템 (document review systems)
• 관리 도구 (admin tools)
• 보고 워크플로 (reporting workflows)

이러한 워크플로들은 종종 테이블 (tables), 양식 (forms), 카드 (cards), 타임라인 (timelines), 승인 게이트 (approval gates), 그리고 로그 (logs)를 필요로 합니다.

긴 텍스트 답변만으로는 충분하지 않습니다.

사용자에게는 의사 결정과 행동을 위한 인터페이스가 필요합니다.

현재 나의 견해

AI 제품의 미래는 모든 앱이 챗봇 (chatbot)이 되는 것이 아닙니다.

채팅은 여전히 중요할 것입니다.

하지만 많은 워크플로 (Workflows)에는 AI 주변에 더 풍부한 표면 (surfaces)이 필요합니다:

• 구조화된 출력 (structured output)
• 도구 호출 (tool calls)
• 컴포넌트 카탈로그 (component catalogs)
• 검증 (validation)
• 권한 (permissions)
• 가드레일 (guardrails)
• 평가 (evaluation)
• 인간의 승인 (human approval)

Generative UI는 AI의 출력을 더 멋지게 보이게 만드는 것이 아닙니다.

그것은 소프트웨어가 작업에 적합한 인터페이스를 렌더링 (render)하도록 돕는 것에 관한 것입니다.

유용한 AI 시스템은 단순히 답변만 해서는 안 됩니다.

사용자가 맥락 (context)을 가지고 행동할 수 있도록 도와야 합니다.

추가 읽을거리

추가 읽을거리

• Vercel AI SDK: Generative User Interfaces: [https://ai-sdk.dev/docs/ai-sdk-ui/generative-user-interfaces]
• OpenAI Apps SDK: Build your ChatGPT UI: [https://developers.openai.com/apps-sdk/build/chatgpt-ui]
• LangChain Generative UI docs: [https://docs.langchain.com/oss/python/langchain/frontend/generative-ui]
• A2UI: Agent-to-User-Interface: [https://a2ui.org/]