{"title":"생성형 UI의 세 가지 길 — 통제형·선언형·개방형 인터페이스","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/generative-ui-three-approaches/","section":"posts","date":"2026-08-12T14:12:24+09:00","lastmod":"2026-08-12T14:12:24+09:00","description":"boda.sh의 Generative UI 글을 바탕으로, AI가 의도에 맞춰 인터페이스를 생성하는 세 가지 방식과 실제 제품에서 이를 조합하는 방법을 정리한다.","summary":"boda.sh의 Generative UI 글은 AI가 인터페이스를 만든다는 말을 세부적인 설계 선택으로 풀어낸다. 단순히 HTML을 생성하는 기술을 소개하는 데 그치지 않고, 사용자의 의도에 맞춰 화면을 얼마나 자유롭게 바꿀 것인지, 그 자유를 어떤 규칙과 안전장치로 제한할 것인지 설명한다.\n원문: Generative UI\nGenUI 핵심 정리 문제의식: AI 응답의 긴 텍스트 벽을 목적에 맞는 카드, 지도, 플래시카드 같은 일시적 UI로 바꾼다. 세 가지 방식: 기존 컴포넌트를 연결하는 Static/Controlled, 허용된 컴포넌트와 레이아웃을 조합하는 Declarative, raw UI 코드를 생성하는 Open-ended로 나눈다. 안전한 경계: 선언형 방식에서는 컴포넌트 카탈로그와 스키마가 AI가 실행할 수 있는 범위를 결정한다. 개방형 방식은 샌드박스가 필요하다. 프로토콜의 역할 분리: AG-UI는 에이전트와 클라이언트 사이의 이벤트를 전달하고, A2UI는 화면을 구성하는 컴포넌트와 속성을 표현한다. 실무 결론: 세 방식 중 하나를 고르는 것이 아니라, 제품의 위험도와 가변성에 따라 세 방식을 조합한다. 생성형 UI의 핵심은 화면 생성이 아니다 “AI가 생성한 사용자 인터페이스”라는 정의는 생각보다 넓다. Figma나 Claude Design으로 시안을 만드는 일, ChatGPT에 UI 코드를 작성하게 해 웹 앱으로 제공하는 일, AI로 발표 자료를 만들고 애니메이션을 넣는 일도 모두 생성형 UI라고 부를 수 있다.\n","content":"boda.sh의 Generative UI 글은 AI가 인터페이스를 만든다는 말을 세부적인 설계 선택으로 풀어낸다. 단순히 HTML을 생성하는 기술을 소개하는 데 그치지 않고, 사용자의 의도에 맞춰 화면을 얼마나 자유롭게 바꿀 것인지, 그 자유를 어떤 규칙과 안전장치로 제한할 것인지 설명한다.\n원문: Generative UI\nGenUI 핵심 정리 문제의식: AI 응답의 긴 텍스트 벽을 목적에 맞는 카드, 지도, 플래시카드 같은 일시적 UI로 바꾼다. 세 가지 방식: 기존 컴포넌트를 연결하는 Static/Controlled, 허용된 컴포넌트와 레이아웃을 조합하는 Declarative, raw UI 코드를 생성하는 Open-ended로 나눈다. 안전한 경계: 선언형 방식에서는 컴포넌트 카탈로그와 스키마가 AI가 실행할 수 있는 범위를 결정한다. 개방형 방식은 샌드박스가 필요하다. 프로토콜의 역할 분리: AG-UI는 에이전트와 클라이언트 사이의 이벤트를 전달하고, A2UI는 화면을 구성하는 컴포넌트와 속성을 표현한다. 실무 결론: 세 방식 중 하나를 고르는 것이 아니라, 제품의 위험도와 가변성에 따라 세 방식을 조합한다. 생성형 UI의 핵심은 화면 생성이 아니다 “AI가 생성한 사용자 인터페이스”라는 정의는 생각보다 넓다. Figma나 Claude Design으로 시안을 만드는 일, ChatGPT에 UI 코드를 작성하게 해 웹 앱으로 제공하는 일, AI로 발표 자료를 만들고 애니메이션을 넣는 일도 모두 생성형 UI라고 부를 수 있다.\n원문은 이 중 서버와 인터페이스 사이에서 AI가 실행 시점에 UI를 구성하는 경우에 집중한다. 이 관점에서 생성형 UI의 가장 분명한 용도는 AI 응답의 ‘텍스트 벽’을 없애는 것이다.\n사용자가 여행지를 물었을 때 장문의 설명만 반환하는 대신 지도와 장소 카드가 나타날 수 있다. 학습 내용을 요청했을 때 긴 문단만 보여주는 대신 바로 조작할 수 있는 플래시카드가 생성될 수도 있다. 핵심은 매번 새로운 애플리케이션을 만드는 것이 아니다. 사용자의 질문과 목적에 맞는 짧고 일시적인 인터페이스를 응답에 끼워 넣는 것이다.\n생성형 UI가 성숙할수록 AI 제품에는 고정된 답변 화면보다 사용자의 의도에 따라 잠시 나타났다가 사라지는 UI 요소가 많아진다.\n복잡해진 제품과 의도 기반 진입점 성공한 디지털 제품은 시간이 지나면서 기능과 책임이 늘어난다. 자체 기능뿐 아니라 결제, 예약, 지도, 소셜 미디어, 외부 SaaS 같은 제3자 연동도 붙는다. 일부 파트너는 자체 UI를 제공하지만, 브랜드 콘텐츠나 화이트 라벨 페이지처럼 제품이 직접 화면을 책임져야 하는 연동도 많다.\n기능과 연동이 늘어날수록 UI 조합의 수는 곱셈처럼 증가한다. 팀은 모든 경우를 미리 설계하기 어렵고, 사용자는 자신에게 필요하지 않은 기능까지 포함된 복잡한 앱을 탐색해야 한다.\n이 문제를 하나의 진입점으로 좁히려는 흐름이 슈퍼 앱과 AI 챗봇이다. 챗봇 안에서 쇼핑, 여행 예약, 일정 관리, 이메일, 음식 주문을 처리한다면 사용자는 서비스마다 다른 화면을 찾아다니지 않아도 된다.\n원문은 이 지점에서 WeChat Mini Program과 AI 챗봇을 비교한다. WeChat은 QR 코드처럼 예측 가능한 진입점에서 시작했고, AI 시스템은 자유로운 텍스트처럼 의도 기반(intent-based) 진입점에서 시작한다. 사용자가 매번 다른 질문을 한다면, 그에 대한 결과 UI도 매번 달라질 수 있어야 한다. 생성형 UI는 바로 이 의도와 인터페이스 사이의 간극을 메우는 방식이다.\n세 가지 생성 방식 OpenUI의 생성형 UI 분류는 두 축을 구분한다. UI가 어디에 나타나는지를 결정하는 전송(transport) 축과, 모델이 얼마나 자유롭게 UI를 만들 수 있는지를 결정하는 생성(generation) 축이다. 아래 세 가지는 생성 축에 해당하며 서로 배타적인 선택지가 아니다.\n1. Static/Controlled — 기존 부품을 안전하게 연결한다 Static/Controlled 방식에서 AI는 화면 자체를 만들지 않는다. 사용자의 자연어 요청을 해석해 도구의 인자를 결정하고, 애플리케이션은 도구 결과를 이미 만들어 둔 컴포넌트에 연결한다.\n예를 들어 장소 탐색 서비스라면 다음과 같이 동작한다.\n사용자가 “아이와 가기 좋고 지금 문을 연 공원을 찾아줘”라고 입력한다. 에이전트가 recommendPlaces 도구에 검색어, 영업 여부, 평점, 예산 같은 인자를 전달한다. 실제 검색과 필터링, 관련성 순위 계산은 애플리케이션 코드가 실행한다. 도구가 장소 목록과 적용된 필터를 반환한다. 프런트엔드는 결과 수와 상태에 따라 EmptyMatch, OpenStatus, PlaceCard, PlaceResults 같은 등록된 컴포넌트 중 하나를 선택한다. 이 방식은 기존 컴포넌트, 레이아웃, 디자인 시스템을 그대로 재사용한다. AI는 도구 스키마가 허용한 범위 안에서 검색 조건만 선택하고, 어떤 컴포넌트를 실제로 마운트할지는 결정론적인 애플리케이션 코드가 책임진다.\n따라서 일관된 UI를 유지하면서 자연어 입력을 추가하고 싶은 팀에 적합하다. 기존 제품에 생성형 UI를 도입하는 첫 단계로도 가장 현실적이다. 다만 AI가 새 레이아웃을 만들지는 못하므로, 가능한 화면 조합은 개발자가 미리 준비한 범위에 머문다.\n2. Declarative — 허용된 부품으로 새로운 구성을 만든다 Declarative 방식에서는 AI가 기존 화면 중 하나를 고르는 데서 더 나아가, 허용된 컴포넌트와 레이아웃을 조합한다. 개발자가 모든 화면을 미리 설계하지 않아도 AI가 사용자의 목표에 맞춰 대시보드를 구성할 수 있다.\n예를 들어 “파리에서 포르투로 가는 날씨 기반 주말 여행을 계획해줘”라는 요청에 AI가 다음 요소를 하나의 화면에 배치할 수 있다.\n여행 계획을 설명하는 문장 항공편 예상 정보 실시간 날씨 위젯 날짜별 일정 준비물 체크리스트 Static/Controlled 방식에서는 장소 검색 도구의 결과를 고정된 장소 그리드에 넣었다. Declarative 방식에서는 모델이 어떤 컴포넌트를 사용할지, 어떤 순서와 레이아웃으로 배치할지까지 결정한다. 단, 아무 코드나 실행하는 것은 아니다. 모델은 제품이 제공하는 카탈로그 안에서만 선택한다.\n이 구조를 단순화하면 다음과 같다.\n에이전트 서버 → 전송 프로토콜 → 클라이언트 각 층을 명세로 구체화하면 다음과 같은 조합이 된다.\nA2UI: 모델이 어떤 컴포넌트를 만들고, 어떤 속성을 전달하며, 어떻게 중첩할지 표현한다. AG-UI: 실행 시작·종료, 텍스트, 도구 호출, 상태, UI 활동 같은 이벤트를 서버와 클라이언트 사이에 전달한다. A2A: 에이전트가 다른 에이전트를 발견하고 협력해야 할 때 사용할 수 있는 에이전트 간 프로토콜이다. 원문에서 사용한 예시는 Mastra agent → AG-UI → A2UI 구조다. 모델은 A2UI 형식에 맞춰 컴포넌트 트리를 만들고, AG-UI의 이벤트를 통해 이를 클라이언트로 스트리밍한다. 클라이언트는 트리를 순회하며 각 컴포넌트 ID를 실제 React 렌더러에 연결한다.\n여기서 중요한 것은 **카탈로그가 계약(contract)**이라는 점이다. 카탈로그에는 모델이 사용할 수 있는 컴포넌트, 각 컴포넌트가 받는 속성, 컴포넌트가 중첩될 수 있는 방식이 정의된다. Zod 같은 스키마는 모델이 요청할 수 있는 값을 제한하고, React 렌더러는 실제 브라우저에서 실행될 동작을 구현한다.\n이 경계가 있기 때문에 AI는 새로운 레이아웃을 조합할 수 있지만 임의의 JavaScript를 페이지에 삽입할 수는 없다. 대신 더 많은 명세와 SDK, 카탈로그 버전 관리, 정책 설계가 필요하다. 유연성은 커지지만 그 유연성을 관리할 규칙도 함께 늘어난다.\n3. Open-ended — UI 코드 자체를 생성한다 Open-ended 방식은 모델이 HTML·CSS·JavaScript 같은 raw UI 코드를 직접 출력한다. 카탈로그나 스키마가 없어도 되므로 표현의 자유는 가장 크다. 내부용 대시보드나 짧은 실험처럼 통제된 환경에서는 빠르게 결과를 만들 수 있다.\n하지만 외부 사용자를 대상으로 임의의 코드를 브라우저에서 실행하는 일은 심각한 보안 위험을 만든다. 현재 널리 거론되는 해결책은 MCP Apps의 샌드박스 iframe처럼 실행 환경을 격리하는 것이다.\n샌드박스가 있어도 문제가 모두 사라지지는 않는다. 생성 결과의 지연시간, 캐시 가능성, 감사 가능성, UI 일관성, 비용, 장애 대응을 함께 해결해야 한다. 그래서 Open-ended 방식은 가장 강력하지만, 일반적인 핵심 제품 흐름의 기본값으로 쓰기에는 아직 부담이 크다.\n프로토콜보다 중요한 것은 경계다 Declarative 구조를 처음 보면 A2UI와 AG-UI가 무엇을 구분하는지 헷갈리기 쉽다. 둘의 역할은 간단히 나눌 수 있다.\n층 담당하는 질문 AG-UI 에이전트 실행 상태와 UI 관련 이벤트를 어떻게 전달하는가? A2UI 어떤 컴포넌트를 어떤 속성과 계층으로 그릴 것인가? 컴포넌트 카탈로그 실제 클라이언트에서 어떤 코드와 디자인을 실행할 것인가? AG-UI는 UI의 모양을 알 필요가 없다. 이벤트를 운반하는 역할을 한다. A2UI는 화면을 표현하지만, 실제 React 컴포넌트 구현 자체는 아니다. 카탈로그와 렌더러가 최종적으로 어떤 화면을 보여줄지 결정한다.\n이 분리는 생성형 UI를 특정 모델이나 특정 프런트엔드 구현에 묶이지 않게 한다. 서버의 에이전트, 이벤트 전송, 화면 명세, 클라이언트 렌더러를 교체하거나 조합할 수 있는 여지가 생긴다. 반대로 명세와 SDK가 늘어나므로 팀이 관리해야 할 계약도 많아진다.\n세 방식을 섞어 쓰는 이유 세 범주는 경쟁 관계가 아니다. 제품 안에서 요구하는 자유도와 위험도가 서로 다르기 때문이다.\n핵심 내비게이션과 결제처럼 예측 가능성이 중요한 부분은 고정 컴포넌트로 유지한다. 사용자의 목표에 따라 카드와 위젯을 조합해야 하는 영역은 Declarative 방식으로 만든다. 한 번만 쓰는 외부 도구나 특정 업무를 위한 위젯은 샌드박스 안의 Open-ended 방식으로 격리한다. 원문은 MCP와 A2UI를 조합하는 세 가지 방향도 소개한다.\nMCP 위의 A2UI: MCP 서버가 텍스트나 완성된 웹 앱 대신 A2UI 페이로드를 반환하고, 호스트가 자신의 렌더러로 화면을 그린다. A2UI 안의 MCP Apps: 샌드박스 iframe을 하나의 A2UI 컴포넌트로 정의해 선언형 화면 안에 MCP App을 넣는다. MCP Apps 안의 A2UI: MCP App이 iframe 내부에 A2UI 렌더러를 포함하고, 앱 브리지를 통해 받은 명세를 내부에서 렌더링한다. 첫 번째 방식은 같은 화면 명세를 서로 다른 호스트에서 재사용할 가능성을 보여준다. 두 번째와 세 번째 방식은 네이티브 컴포넌트의 일관성과 외부 앱의 자유도를 한 화면에서 함께 얻으려는 시도다. 대신 iframe을 쓰면 디자인 시스템 충돌, 중복 스크롤바, 성능 비용, 새로운 보안 경계를 직접 관리해야 한다.\n제품에 도입할 때의 판단 순서 생성형 UI를 도입할 때 “AI가 화면을 만들 수 있는가”부터 묻는 것은 충분하지 않다. 먼저 화면이 동적으로 달라질 때 사용자가 실제 이득을 얻는지 확인해야 한다.\n다음 순서가 현실적인 출발점이 된다.\n기존 컴포넌트에 자연어 입력을 연결한다. 검색·필터·추천처럼 도구 결과가 명확한 영역에서 Static/Controlled 방식을 적용한다. 허용된 컴포넌트 카탈로그를 만든다. 컴포넌트별 속성, 중첩 규칙, 사용 조건, 금지 조합, 실패 시 대체 UI를 명시한다. 선언형 조합을 제한된 영역에서 실험한다. 대시보드나 계획 수립처럼 사용자 목표와 화면 구성이 크게 달라지는 곳부터 시작한다. 임의 코드가 필요한 경우 실행 환경을 격리한다. Open-ended UI를 핵심 제품 DOM에 직접 넣지 말고, 샌드박스·권한·감사 로그·자원 제한을 함께 설계한다. 운영 지표를 확인한다. 속도, 지연시간, 캐시 가능성, 비용, 보안, 감사, 일관성, 실패율을 정적인 화면과 비교한다. 이 과정의 핵심은 자유도를 한 번에 최대로 올리지 않는 것이다. 통제형에서 시작해 선언형으로 넓히고, 꼭 필요한 경우에만 개방형 실행 공간을 추가하면 제품의 안정성과 실험 속도를 함께 관리할 수 있다.\n결론 및 시사점 한 줄 결론: 생성형 UI의 미래는 하나의 방식이 모든 화면을 대체하는 데 있지 않고, 통제형·선언형·개방형 UI를 의도와 위험도에 맞춰 조합하는 데 있다.\n생성형 UI는 “AI가 예쁜 화면을 만들어준다”는 기능이 아니다. 사용자의 자유로운 의도를 안전하게 해석하고, 제품이 허용한 재료 안에서 필요한 인터페이스를 구성하는 아키텍처다.\n따라서 가장 중요한 자산은 모델 자체보다 컴포넌트 카탈로그, 스키마, 전송 프로토콜, 렌더러, 실패 시 대체 흐름이 된다. 코드를 작성하는 비용이 낮아질수록 사람은 화면 하나하나보다 더 높은 수준의 명세와 경계를 설계해야 한다. 좋은 GenUI는 화면을 무한히 열어두는 시스템이 아니라, 필요한 곳에서만 유연하고 나머지 영역에서는 예측 가능한 시스템이다.\n","wordCount":1451,"tags":["AI","GenUI","생성형 UI","A2UI","AG-UI","MCP","인터페이스"],"categories":["AI","Product Design"],"frameworks":["Progressive Adoption","Specification-driven Design","Defense in Depth"],"mental_models":["Controlled Flexibility","Intent-based Interface","Separation of Concerns"],"philosophy_type":"product-design","schema_type":"TechArticle","actionable":true,"priority":"medium","key_points":["생성형 UI의 핵심은 코드를 만드는 일이 아니라 사용자의 의도에 맞춰 필요한 인터페이스를 그때그때 구성하는 일이다","Static/Controlled는 기존 컴포넌트와 도구 결과를 연결해 가장 안전하게 도입하는 방식이다","Declarative는 AI가 허용된 컴포넌트와 레이아웃을 선택하도록 하며, A2UI는 인터페이스를 AG-UI는 이벤트 전달을 담당한다","Open-ended는 HTML·CSS·JavaScript를 직접 생성해 가장 유연하지만 보안·지연시간·감사·일관성 문제가 크다","실제 제품은 핵심 흐름에 통제형 UI를, 동적 조합에 선언형 UI를, 한시적 위젯에 격리된 개방형 UI를 섞는 방향으로 발전한다"],"related":["posts/designing-for-genui-ai-builds-ui","posts/apps-after-agents","posts/agent-harness-engineering"]}