출처
- source_url: https://blog.gskinner.com/archives/2026/06/designing-for-genui-what-changes-when-ai-builds-the-ui.html
- author: Cameron Brodie (gskinner)
- published: 2026-06-17
- raw: raw source:
web-2026-07-11-Designing for GenUI What Changes When AI Builds the UI
요약
Flutter 팀이 공개한 GenUI SDK는 런타임에 디자인 시스템을 바탕으로 AI가 UI를 조립하게 해준다. gskinner는 Google I/O·Cloud Next 시연을 위해 이 SDK로 Hatcha라는 오픈소스 이벤트 기획 앱을 만들었다 — 호스트가 AI와 대화형 인터뷰를 하며 이벤트를 기획하면, GenUI가 그때그때 테마가 적용된 동적인 초대장을 생성하고, 게스트 응답이 쌓일수록 기획 화면 자체가 그 맥락에 맞춰 계속 재구성된다.
디자이너 역할의 변화: 전통적인 UI는 모든 화면과 흐름을 사전에 설계하지만, 이벤트마다 성격이 완전히 다른(가벼운 포틀럭 저녁 모임 vs 스타디움급 콘서트) 도메인에서는 무한에 가까운 비결정적 사용 사례를 미리 다 그릴 수 없다. 그래서 디자이너의 일은 “화면과 흐름을 그리는 것”에서 구조·원칙·규칙을 설계하는 것으로 옮겨간다 — 범위(range), 관계, 위계를 정의하고, 최종 UI 대신 가드레일과 우선순위를 설계한다.
디자인 시스템 = 재고(inventory): GenUI가 런타임에 조립하므로 디자인 시스템은 AI가 꺼내 쓰는 부품 창고가 된다. 모든 컴포넌트는 여러 맥락에서 재사용될 만큼 범용적이어야 하고, “언제 등장해야/등장하지 말아야 하는지”에 대한 명확한 지침이 필요하다. 예를 들어 식이 정보 하나가 응답 시점엔 다중 선택 리스트로, 하루 뒤 대시보드에선 파이 차트로, 행사 주간엔 쇼핑 리스트의 한 줄로 — 같은 데이터가 세 가지 다른 컴포넌트로 나타난다. 디자이너는 이 세 화면을 그리지 않았다; 재고와 조건만 정의했을 뿐이다.
무엇을 GenUI로 만들지 판단하기: GenUI 표면마다 예측 가능성과 가변성을 맞바꾼다. 고정된 부분은 빠르고 저렴하며 항상 같게 동작하지만, GenUI 부분은 조립할 때마다 토큰을 쓰고 렌더링이 느리며 예상 못한 형태로 나타날 수 있다. 주 내비게이션처럼 예측 가능해야 하는 부분은 고정 흐름이 여전히 정답이고, 게스트별 맞춤 모듈처럼 개인화가 필요한 부분엔 GenUI가 어울린다. 규제가 강한 선형 프로세스에도 고정 흐름이 맞다.
산출물의 변화: 디자이너는 이제 모든 화면이 아니라, GenUI가 조립할 때 참조할 기준선(컴포넌트, 조건, 프롬프트)을 만든다. “정의 → 테스트 → 다듬기 → 재정의”의 짧은 루프가 필수이며, 개발팀과의 밀착 피드백 루프 없이는 컴포넌트 정의가 의도대로 작동하는지 알 수 없다. 다만 사용자를 깊이 이해해야 좋은 디자인이 나온다는 원칙 자체는 변하지 않는다 — GenUI는 오히려 그 이해의 중요성을 더 키운다.
관련 위키
원문 보존 위치
원문 전체는 raw source: web-2026-07-11-Designing for GenUI What Changes When AI Builds the UI에 source_url과 함께 저장되어 있다.