Generative UI란? 디자이너가 AI에게 화면을 맡기기 전에 설계할 5가지
AI의 답변을 카드·폼·비교 화면처럼 다음 행동으로 바꾸려면 무엇을 먼저 정해야 할까요? 첫 Generative UI에 필요한 다섯 가지 설계 질문을 정리합니다.
AI에게 “2박 3일 여행 일정을 만들어줘”라고 말하면, 그럴듯한 화면을 순식간에 여러 장 만들 수 있어요. 하지만 사용자가 날짜 하나를 바꾸는 순간 문제가 시작됩니다. 가격 카드는 사라지고, 필터는 바뀌고, 예약 버튼의 의미도 화면마다 달라집니다.
이 장면이 낯설지 않다면, 지금 필요한 건 더 긴 프롬프트가 아닙니다. Generative UI의 핵심은 AI가 화면을 만드는 속도가 아니라, 화면이 바뀌어도 제품답게 행동하도록 경계를 설계하는 일이에요.
이 글에서는 생성형 UI가 무엇인지, 챗봇 UI와 어디서 갈리는지, 그리고 AI 초보 디자이너가 첫 프로토타입 전에 답해야 할 다섯 질문을 정리합니다. 읽고 나면 예쁜 시안이 아니라 수정·되돌리기·접근성까지 검토할 수 있는 브리프를 만들 수 있어요.
Generative UI는 답변을 다음 행동으로 바꾼다
Generative UI는 AI가 임의의 HTML을 만들어 내는 일을 뜻하지 않습니다. 사용자 의도, 현재 맥락, 도구가 가져온 데이터에 맞춰 카드·폼·비교표·차트처럼 검증된 컴포넌트를 필요한 순간에 조합해 보여주는 방식에 가까워요.
기존 챗봇은 질문이 달라도 대개 같은 입력창과 말풍선으로 답합니다. 반면 여행을 비교해야 하면 날짜 선택기와 예산 슬라이더를, 여러 옵션에서 골라야 하면 비교 카드와 필터를 먼저 제시할 수 있습니다. 사용자가 문장으로 세 번 되물을 일을 화면에서 한 번의 조작으로 끝내게 하는 거죠.
Vercel은 도구 호출 결과를 React 컴포넌트로 연결하는 생성형 UI 흐름을 공개했고, Flutter도 앱이 제공한 위젯 카탈로그와 데이터 모델 안에서 UI를 조합하는 GenUI 방식을 소개합니다. 화면을 “그린다”기보다, AI가 지금 필요한 인터랙션을 선택하고 제품이 안전하게 렌더링한다고 보는 편이 정확합니다. Vercel AI SDK · Flutter GenUI
1. 사용자가 지금 끝내려는 일은 하나인가
첫 GenUI를 “AI 여행 앱”처럼 넓게 잡으면 금방 데모가 됩니다. 대신 사용자가 세 번 이상 되묻는 한 장면을 고르세요. 예를 들어 “예산 안에서 일정 세 개를 비교하고 하나를 고르는 일”입니다.
그 목표가 선명하면 화면도 달라집니다. 긴 추천문 대신 가격·이동 시간·우천 대안을 비교하는 카드와 하나만 바꿀 수 있는 컨트롤이 먼저 나와야 해요. Generative UI의 첫 질문은 “무엇을 생성할까?”가 아니라 “사용자가 어떤 결정을 더 빨리 내리게 할까?”입니다.
2. AI가 조합할 블록은 어디까지인가
AI에게 자유로운 코드 생성 권한을 주면 브랜드와 품질이 같이 흔들립니다. 가장 현실적인 방식은 디자이너가 만든 레고 상자 안에서만 조립하게 하는 것입니다.
버튼, 입력, 선택 카드, 표, 알림, 로딩 상태를 승인된 컴포넌트로 제한하고, 색·간격·문구·오류 표현도 토큰과 규칙으로 고정하세요. Google의 A2UI도 실행 가능한 HTML이나 JavaScript 대신 선언형 데이터와 신뢰한 컴포넌트 카탈로그를 중심에 둡니다. 이 방식은 디자인 일관성과 UI 주입 위험을 함께 줄여 줍니다. Google A2UI
3. 근거와 불확실성은 화면의 어느 곳에 보이는가
AI가 추천한 결과는 보기 좋다고 곧바로 믿을 수 있는 정보가 아닙니다. 가격·재고·정책처럼 바뀌는 데이터에는 출처와 확인 시점이 필요하고, 확신이 낮은 제안에는 “확인 필요”라는 상태가 필요합니다.
여기서 디자이너는 카드의 모양보다 판단의 근거를 설계합니다. 고객 인터뷰 요약 도구라면 결론 카드 아래에 원문 발화와 표본 수를 열 수 있어야 합니다. 사용자가 결과를 읽는 데서 멈추지 않고, 왜 그런 추천이 나왔는지 확인하고 수정할 수 있게 만드는 것이 신뢰의 시작이에요.
4. 수정·재시도·되돌리기는 바로 옆에 있는가
생성 결과는 정답이 아니라 가설입니다. 그래서 “다시 생성”만 두는 것으로는 충분하지 않아요. 사용자가 어떤 조건을 바꿨는지 보이고, 결과 일부를 직접 고치고, 이전 상태로 돌아갈 수 있어야 합니다.
특히 결제·공유·삭제처럼 되돌리기 어려운 행동은 AI가 제안하더라도 확인 단계를 거쳐야 합니다. Apple의 생성형 AI 디자인 가이드도 AI 사용을 명확히 알리고, 사용자가 결과를 수정·재시도·되돌릴 수 있도록 권고합니다. 좋은 GenUI는 자동화의 속도보다 사용자의 조작권을 더 눈에 띄게 둡니다. Apple HIG
5. AI가 실패했을 때도 제품은 계속 작동하는가
모델 지연, 데이터 누락, 애매한 요청은 예외가 아니라 기본 시나리오입니다. 로딩 중에는 실제 진행 상황을 알려 주고, 정보가 부족하면 다음에 입력할 항목을 보여 주고, 생성 기능을 쓰지 않아도 핵심 작업을 할 수 있는 고정 UI를 남겨야 해요.
접근성도 같은 원칙입니다. 생성 뒤에 검사하기보다 컴포넌트 계약 안에 라벨, 키보드 조작, 포커스 순서, 대비, 오류 메시지 정책을 넣어야 합니다. 생성될 화면의 수는 많아도, 사용할 블록과 행동 규칙은 적고 검증 가능해야 합니다.
첫 프로토타입은 이 다섯 줄이면 충분하다
처음부터 모든 화면을 생성하게 만들 필요는 없습니다. 다음 브리프 한 장으로 시작해 보세요.
- 사용자 목표: 사용자가 지금 끝내려는 결정 한 가지
- 허용 컴포넌트: AI가 조합할 카드·입력·표·차트 목록
- 필수 근거: 표시해야 할 데이터 출처·시점·불확실성
- 사용자 통제: 수정·재시도·되돌리기와 중요한 행동의 확인
- 실패 시 경로: 데이터 없음·지연·오류일 때의 고정 UI
Generative UI는 디자이너를 화면 생산에서 밀어내는 기술이 아닙니다. 오히려 화면이 유동적일수록 “이 사람에게 지금 필요한 다음 행동은 무엇인가”를 더 정확히 정해야 합니다. 챗봇을 조금 더 화려하게 만드는 데서 시작하지 마세요. 한 가지 반복 질문을 카드·폼·비교 화면으로 바꿔 보는 것. 그 작은 전환이 가장 현실적인 시작입니다.