정적 화면의 종말: 의도 중심 UX 설계

URL: https://www.youtube.com/watch?v=QrMcNe2jjt8 날짜: 2026-09-02 채널: aiDotEngineer

메타데이터

• 원문 제목: The End of the Static Screen: Architecting Intent-Driven UX — Gus Iwanaga, commercetools
• 영상 ID: QrMcNe2jjt8
• 실제 업로드 시각: 2026-09-02 05:00 (KST, yt-dlp timestamp 기준)
• 콘텐츠 유형: YouTube 자막 기반 심층 다이제스트
• 발표자: Gus Iwanaga, commercetools 제너럴 매니저(General Manager)
• 발표자의 책임 범위: zero-to-one 제품의 Product, UX, Engineering
• 주제: 생성형 UX(Generative UX), 생성형 UI(Generative UI), 의도 중심 인터페이스, UI 프로토콜, 에이전틱 오케스트레이션(Agentic Orchestration)
• 핵심 조직: commercetools, aiDotEngineer
• 언급된 기술·프로토콜: MCP(Model Context Protocol), React, Zod, HTMX, JSON Render, OpenUI, ATUI
• 영상 길이: 23분 18초

📌 핵심 질문 / 의도 중심 UX의 핵심 논점

==소프트웨어가 사용자의 의도에 맞춰 경험을 조립해야 한다면, AI에게 화면의 모든 결정을 맡기지 않으면서도 정적 화면의 인지 부담을 줄이는 방법은 무엇인가?==

• 지난 40년 동안 사용자는 각 애플리케이션의 고유한 정신 모델과 탐색 방식을 배워야 했다.
• 단순히 컴포넌트 카탈로그를 주고 화면을 조합하게 하면 같은 질문에도 KPI 카드, 차트, 텍스트, 기간 표기가 매번 달라져 신뢰할 수 없는 UX가 된다.
• 의도 분류, 도구 호출, 데이터와 UI 컴포넌트의 매핑, UI 명세(UI spec), 네이티브 컴포넌트 렌더링을 분리하면 AI의 적응성과 제품의 통제력을 함께 확보할 수 있다.
• 제어 수준은 고정 컴포넌트, LLM의 완전 자율 렌더링, 선언적(declarative) UI 프로토콜 사이의 스펙트럼으로 설계할 수 있다.
• 선언적 접근의 핵심 계약은 컴포넌트 카탈로그와 레이아웃 스키마이며, 정보 구조와 디자인 시스템 지식을 에이전트가 반복적으로 적용할 수 있게 만드는 큐레이션이 품질을 좌우한다.

정적 화면의 문제는 화면이 단순히 고정돼 있다는 데만 있지 않다. 사용자가 여러 SaaS를 오가며 서로 다른 탐색 규칙을 학습해야 하고, 제품팀이 복잡성을 화면에 계속 쌓는 데 있다. 생성형 UX는 사용자의 의도에 따라 필요한 도구와 컴포넌트를 선택해 화면을 구성할 수 있지만, 무제한 생성은 일관성·브랜드·안전·정보 구조를 훼손한다. 따라서 AI가 선택하고 제품이 허용 범위와 구조를 규정하는 중간 지대가 실용적인 방향이 된다.

1. 40년간 이어진 정적 소프트웨어의 비용

정적 인터페이스는 제품마다 다른 사용법을 사용자에게 전가하고, 조직에는 기능·온보딩·유지보수 비용을 누적시킨다.

1.1. 사용자가 소프트웨어에 적응해 온 구조

1. 적응 방향의 역전

   1. 현재의 기본값: 사용자는 자신이 원하는 일을 말하는 대신, 제품이 미리 만든 메뉴·페이지·폼·테이블의 순서를 따라가야 한다.
   2. AI 이후의 가능성: GPT가 2022년 11월에 등장했을 때 실제 개인화의 가능성을 보여줬지만, 대부분의 제품 경험은 여전히 정적 화면으로 남아 있다.
   3. 근본 질문: AI 덕분에 더 많은 소프트웨어를 더 빠르게 출하하는데도 상호작용 방식은 왜 여전히 고정돼 있는지 질문해야 한다.

2. SaaS가 만드는 인지 부채

   1. 각자의 정신 모델: 일상 업무에 여러 SaaS 애플리케이션이 필요하고, 각각은 고유한 정신 모델과 작업 완료 방식을 요구한다.
   2. 복리처럼 쌓이는 부담: 애플리케이션이 늘어날수록 사용자는 탐색·검색·이동 규칙을 제품별로 다시 배워야 한다.
   3. 인지 부하의 전가 실패: 원래 기계로 옮기고 싶었던 인지 부하가 사용자에게 남아 있으며, 시간이 흐를수록 부채가 커진다.

1.2. 복잡한 화면과 온보딩의 교환 관계

1. 대표적인 정적 제품 화면

   1. 대형 CRM: 널리 알려진 CRM의 첫 화면에는 정보와 기능이 너무 많아 어디서 시작해야 할지 알기 어렵다.
   2. 복잡한 테이블: 정교하게 만든 테이블도 기능과 정보가 많아 사용자가 처음부터 작업의 진입점을 찾기 어렵다.
   3. 직관적인 UI의 이면: 아름답고 직관적인 화면도 사용자가 그 화면을 익히기까지 회사가 많은 온보딩 시간과 인력을 투입해야 한다.

2. 복잡성의 조직 비용

   1. 기능의 공동 제작: 화면 하나를 출하하는 데 여러 팀이 관여하고, 그 결과물은 사용자에게 다양한 기능을 한꺼번에 노출한다.
   2. 온보딩의 반복: 애플리케이션이 다섯 개가 되면 사용자는 다섯 가지 탐색 방식과 업무 논리를 익혀야 한다.
   3. 정적 화면의 역사: 제품이 추가될 때마다 새로운 규칙을 학습시키는 방식이 지금까지의 기본적인 성장 모델이었다.

2. commercetools가 던진 질문과 첫 번째 실패

API 우선 회사가 가진 수백 개의 기능을 정적 화면이 아닌 의도 중심 경험으로 연결하려면, 생성된 UI를 통제 가능한 제품으로 만드는 과정이 필요하다.

2.1. API 우선 회사에서 시작된 문제 정의

1. 출발점

   1. 시점: Gus Iwanaga는 발표 시점 기준 전년도 8월에 회사 창업자이자 자신의 상사와 이 문제를 논의했다.
   2. 기술적 배경: commercetools는 300개가 넘는 API를 제공하는 API-first 회사이며, API 수는 계속 늘고 있다.
   3. 전환 질문: 인공지능의 관점에서 소프트웨어와 상호작용하는 방식을 근본적으로 바꾼다면 어떤 기반적 변화가 가능한지 물었다.

2. 목표의 재정의

   1. 정적 화면 탈피: 미리 정해진 화면을 더 많이 만드는 대신 사용자의 질문과 의도에 따라 적절한 경험을 구성한다.
   2. 생성형 UX의 실험: 팀은 에이전틱 오케스트레이션을 포함해 실제로 의미 있는 생성형 UX·UI를 구축하기 시작했다.
   3. 실용적 결과: 논의의 결과는 단순한 데모가 아니라 회사 제품에 적용할 수 있는 UI 생성 시스템으로 이어졌다.

2.2. “Q1 매출 보고서를 만들어라” 데모가 실패한 이유

1. 초기 설계

   1. 입력: 사용자가 “Create a sales report for Q1”이라고 요청했다.
   2. AI의 역할: 오른쪽 영역의 화면을 AI가 자동 생성했고, 팀의 가이드에 따라 정보 구조·배치·컴포넌트 선택을 결정했다.
   3. 잘못된 전제: 컴포넌트 카탈로그를 제공하고 모델에게 경험을 조합하게 하면 충분하다고 가정했다.

2. 네 가지 출력의 불일치

   1. 첫 번째 변형: Q1과 Urban Thread라는 맥락이 보이고 KPI 카드가 여러 개 배치됐지만, 정보가 과도해 논리적으로 맞지 않았다.
   2. 두 번째 변형: 같은 질문인데 Q1 대신 January to March로 표시돼 기간 표기부터 달라졌다.
   3. 세 번째 변형: KPI 카드·많은 텍스트·차트가 더해져 화면 오른쪽에 정보가 더욱 많이 쌓였다.
   4. 네 번째 변형: Q1 표기는 돌아왔지만 여전히 레이아웃과 정보량이 혼란스러웠다.

3. 실패 판정

   1. 표현의 비결정성: 같은 의도를 다른 표현으로 입력할 때마다 모델이 다른 화면을 만들면 사용자는 무엇이 맞는지 판단할 수 없다.
   2. 개인화와 혼란의 경계: 개인화가 매번 다른 KPI 카드와 차트, 기간, 카피를 뜻한다면 개인화가 아니라 혼란이 된다.
   3. 출하 보류: Gus와 팀은 네 번의 결과를 확인한 뒤 “no, no, and no”라고 판단했고 프로덕션에 배포하지 않았다.

2.3. 현재 제품으로의 진화

1. 의도 중심 오케스트레이션

   1. 의도 추출: 오케스트레이터(orchestrator)가 자연어 질의에서 사용자의 의도를 분류한다.
   2. 도구 탐색: 의도에 맞춰 자사 도구(first-party tools)와 외부 도구(third-party tools)를 찾는다.
   3. MCP 에이전트 활용: MCP 서버에 있는 여러 에이전트의 출력도 함께 모아 질의를 처리할 맥락과 근거를 확장한다.

2. UX 에이전트의 렌더링

   1. 데이터와 맥락의 결합: 호출된 도구들의 출력이 UX 에이전트에 필요한 “ammunition and context”가 된다.
   2. 의미 있는 결과: UX 에이전트는 수집된 맥락을 바탕으로 사용자 질의에 의미 있는 화면을 구성한다.
   3. AI와 가이드의 공동 결정: 결과는 AI가 결정하지만, 제품팀의 규칙과 큐레이션이 결정 범위를 가이드한다.

3. 실험에서 제품으로

   1. 기존 결과와의 대비: 첫 번째 Q1 데모보다 캠페인 계획 질의의 결과는 시각적 균형과 정보 배치가 훨씬 낫다.
   2. 검토 가능한 흐름: 사용자가 결과를 승인하면 화면이 실제 제품 흐름에 반영되며, 시연 단계에서는 pre-production 상태로 확인됐다.
   3. 가능성의 조건: 규모 있게 가능한 접근이지만 매일 품질을 검증하고 제품팀이 결과를 계속 도전해야 한다.

3. 생성형 UI를 통제하는 세 가지 선택지

생성형 UI는 고정 컴포넌트부터 LLM 완전 자율 렌더링까지 제어 수준의 스펙트럼으로 봐야 하며, 사업 성격에 따라 적절한 지점을 선택해야 한다.

3.1. 통제된 컴포넌트: 완성된 화면을 선택하게 하기

1. 오피니언이 강한 UI

   1. 예시: ChatGPT에 “오늘 샌프란시스코에서 일본 식당을 찾아줘”라고 요청하면 식당 검색 결과를 정해진 형태의 컴포넌트로 보여준다.
   2. 완전한 시각 통제: 제품팀이 컴포넌트의 모양·구조·표현을 미리 결정하고, 에이전트는 카탈로그에서 적절한 컴포넌트를 선택한다.
   3. 결정성: 동일한 컴포넌트가 선택되면 항상 설명된 그대로 렌더링되므로 브랜드와 UX 일관성을 확보하기 쉽다.

2. 사업 유형에 따른 적합성

   1. 예약 서비스의 적합성: Booking처럼 사용자 흐름이 비교적 명확하고 검색 결과 카드의 형태가 중요한 사업에는 이 방식이 잘 맞는다.
   2. B2B SaaS의 한계: commercetools처럼 설정과 구성 옵션이 많은 B2B SaaS는 지나치게 처방적인 플로우가 사용자의 인지 부하를 줄이지 못할 수 있다.
   3. 고객 피드백: 고객은 이미 흐름이 혼란스럽고 구성이 많다고 느끼므로, 고정된 컴포넌트만 늘리는 접근은 문제를 완전히 해결하지 못한다.

3.2. 개방형 렌더링: LLM에게 전체 경험 맡기기

1. 완전 자율 구성

   1. Claude 사례: Claude에 “세 단계의 조직도를 만들어라”라고 요청하자 모델이 조직도 다이어그램을 직접 렌더링했다.
   2. HTML 전달: MCP 도구가 HTML을 반환하고, 호스트는 이를 샌드박스 iframe(sandboxed iframe) 안에서 렌더링할 수 있다.
   3. 호스트 범위: 렌더링 결과는 Claude, ChatGPT, Perplexity 또는 다른 채팅 호스트에 삽입할 수 있다.

2. 기업이 감수해야 할 위험

   1. 출력 통제 부재: 기업은 모델이 매번 어떤 구조와 카피를 만들지 예측하거나 보장하기 어렵다.
   2. 디자인 판단의 위임: 디자인의 취향(taste)과 판단(judgment)을 전부 LLM에 넘기면 브랜드·접근성·정보 구조가 흔들릴 수 있다.
   3. 실무적 결론: 기술적으로 잘 작동하는 데모라도, 기업 제품의 실제 경험을 완전히 위임하는 선택은 신중해야 한다.

3.3. 선언적 UI: 적응성과 통제력의 중간 지대

1. 프로토콜 선택

   1. 중간 지점: 선언적(declarative) 방식은 컴포넌트 선택과 배치를 AI가 돕되, 최종 렌더링은 제품의 규칙과 네이티브 컴포넌트가 담당한다.
   2. 언급된 프로토콜: Gus는 HTMX from Google, Vercel의 JSON Render, Thesis의 OpenUI, 그리고 ATUI를 관련 선택지로 언급했다.
   3. 공통 문제: 프로토콜마다 특성이 다르므로 특정 표준 하나보다 제품이 필요한 통제 수준을 먼저 정해야 한다.

2. commercetools의 처리 흐름

   1. 질의에서 도구까지: 사용자가 질의하면 의도 분류가 일어나고, 의도에 맞는 도구가 호출되어 데이터가 수집된다.
   2. 엔티티와 컴포넌트 매핑: 도구가 반환한 엔티티를 컴포넌트 카탈로그에서 허용된 컴포넌트와 연결한다.
   3. UI 명세 방송: 오케스트레이터는 화면을 직접 그리기보다 UI description, 즉 UI spec을 방송한다.

3. 스키마 기반 네이티브 렌더링

   1. 계약 준수: UI spec은 컴포넌트 카탈로그와 Zod 스키마를 준수해야 하며, 선택된 필드와 속성이 프로토콜 요구사항에 맞아야 한다.
   2. 최종 출력: 호스트는 명세를 해석해 React 네이티브 컴포넌트를 렌더링한다.
   3. 디자인 시스템 보존: 모든 결과가 조직의 디자인 시스템을 따르므로, AI가 임의의 마크업과 카피를 만들어내는 위험이 줄어든다.

4. 선언적 접근의 트레이드오프

   1. 일관성의 이점: Q1이 January to March로 바뀌는 식의 기간·카피 변형을 제품이 통제할 수 있다.
   2. 남은 비결정성: 어떤 컴포넌트를 선택할지는 규칙으로 제한할 수 있지만, 선택된 컴포넌트를 화면 어디에 배치할지는 여전히 LLM의 결정에 남을 수 있다.
   3. 다음 문제로의 연결: 컴포넌트 선택과 배치를 분리하면 정보 구조라는 UX 핵심 문제가 새롭게 드러난다.

4. 선택된 컴포넌트를 어떻게 배치할 것인가

에이전트가 허용된 컴포넌트를 골라도 정보 구조를 정하지 않으면 결과는 무작위 배치가 되므로, 레이아웃 지식을 별도의 계층과 규칙으로 모델링해야 한다.

4.1. 배치의 책임과 정보 구조

1. 첫 번째 미해결 문제

   1. 선택과 배치의 분리: 에이전트가 컴포넌트를 골랐다는 사실만으로 사용자가 읽기 좋은 페이지가 만들어지지 않는다.
   2. 정보 구조의 역할: 어떤 정보가 먼저 보이고, 어떤 컴포넌트가 어느 영역에 들어가는지는 핵심적인 UX·정보 구조 결정이다.
   3. 무작위성의 위험: 배치 규칙이 없으면 같은 데이터에도 카드·차트·텍스트가 임의 순서로 놓여 사용자가 흐름을 잃는다.

2. 사용자 관점의 품질 기준

   1. 평균 사용자의 기대: 사용자는 시스템 내부의 컴포넌트 선택 과정을 알지 못하고, 화면 전체가 자연스러운 업무 흐름으로 읽히기를 기대한다.
   2. 인지 부하의 재발: 정적 화면의 인지 부하를 줄이려다 랜덤 레이아웃을 만들면 같은 문제가 생성형 UI에서 재현된다.
   3. 제품팀의 개입: AI가 구성할 수 있는 자유도와 제품팀이 보장해야 하는 정보 구조를 분리해야 한다.

4.2. Atomic Design으로 UX 지식을 계층화하기

1. 방법론의 활용

   1. 다섯 단계의 계층: Atomic Design은 인터페이스 디자인 시스템을 더 의도적이고 계층적인 방식으로 만드는 다섯 개의 구분된 단계로 구성된다.
   2. 작은 단위에서 전체로: 개별 요소를 조합해 더 큰 단위와 페이지 구조를 만들므로, 각 요소가 들어갈 수 있는 범위를 명시할 수 있다.
   3. 조정 가능성: 팀은 화면 전체를 매번 픽셀 단위로 설계하지 않고도, 구조와 배치의 방향을 원하는 대로 조정할 수 있다.

2. UX 에이전트 학습

   1. 좋은 결과의 정의: UX 에이전트에 상황별로 무엇이 좋은 레이아웃인지, 어떤 구성과 순서가 최적인지 가르쳤다.
   2. 템플릿 카탈로그: 여러 상황에 대응하는 템플릿 카탈로그를 만들어 에이전트가 가능한 구조를 선택하도록 했다.
   3. 지식의 코드화: 숙련된 디자이너의 판단을 설명 가능한 계층·템플릿·속성으로 바꾸면 같은 규칙을 다음 질의에도 적용할 수 있다.

4.3. 레이아웃 계층과 역방향 매핑

1. 정방향 구조

   1. 페이지와 레이아웃: 가장 바깥에 전체 페이지와 레이아웃이 있다.
   2. 슬롯(slot): 레이아웃은 header와 main 같은 여러 슬롯을 포함한다.
   3. 서브 슬롯(sub-slot): 슬롯 안에는 더 작은 서브 슬롯이 들어갈 수 있으며, 서브 슬롯은 다시 서브 슬롯을 포함할 수 있다.
   4. 컴포넌트 카테고리: 서브 슬롯 안에는 해당 위치에 들어갈 수 있는 컴포넌트 카테고리가 놓인다.

2. 오케스트레이터에 맞춘 역방향 매핑

   1. 기본 계층: layout → slot → sub-slot → component가 일반적인 페이지 구성 방향이다.
   2. 에이전트의 작업 순서: 오케스트레이터는 먼저 질의를 수행할 수 있는 컴포넌트를 선택하므로 component → sub-slot → slot → template 순으로 역매핑한다.
   3. 배치의 통제: 선택된 컴포넌트를 적합한 서브 슬롯에 연결하고, 서브 슬롯을 슬롯에, 슬롯을 템플릿에 연결하면 필요한 레이아웃으로 조립할 수 있다.

5. 컴포넌트 카탈로그는 에이전트와 UI 사이의 계약이다

생성형 UI의 품질은 모델의 창의성보다 카탈로그·레이아웃·속성의 큐레이션과 스키마 설계에 더 크게 좌우된다.

5.1. 디자인 시스템과 카탈로그의 중심성

1. 두 번째 미해결 문제

   1. 프로토콜의 실험: 팀은 ATUI, JSON Render, OpenUI 등 여러 UI 프로토콜을 계속 시험하며 경계를 넓히고 있다.
   2. 카탈로그의 역할: 컴포넌트 카탈로그는 에이전트와 최종 UI 사이의 계약(contract)이다.
   3. 속성의 중요성: 카탈로그의 모든 property가 모델의 선택·매핑·렌더링 결과에 영향을 주므로 사소한 필드도 대충 정의할 수 없다.

2. 레이아웃도 계약의 일부다

   1. 레이아웃 속성: layout에는 컴포넌트·slot·sub-slot이 있고, 각각 고유한 속성과 허용 범위를 갖는다.
   2. 구조적 제약: AI가 아무 컴포넌트나 아무 위치에 놓지 못하도록 슬롯별 허용 카테고리와 속성을 명시한다.
   3. 일관된 렌더링: 컴포넌트와 레이아웃의 계약이 맞아야 UI spec이 네이티브 React 컴포넌트로 안전하게 변환된다.

5.2. 큐레이션이 데모와 제품을 가른다

1. 의미 있는 결과를 만드는 조건

   1. 큐레이션의 정의: 어떤 컴포넌트를 제공할지, 어떤 속성을 노출할지, 어떤 템플릿과 슬롯에 연결할지 결정하는 전체 작업을 큐레이션으로 묶을 수 있다.
   2. 데모 이상의 품질: 단순히 AI가 화면을 만들었다는 시각적 데모가 아니라 사용자의 업무에 의미 있는 결과를 만들려면 큐레이션이 반드시 필요하다.
   3. UX 관점의 조향: 큐레이션은 AI를 완전히 묶는 제약이 아니라 제품팀이 UX 방향을 조향할 수 있게 하는 조절 장치다.

2. 검증 루프

   1. 반복 시험: 팀은 서로 다른 UI 프로토콜과 카탈로그 정의를 계속 테스트해야 한다.
   2. 속성 단위 검토: 화면 전체의 미적 완성도뿐 아니라 property, 슬롯, 매핑 규칙이 의도한 결과를 만드는지 확인해야 한다.
   3. 운영 기준: 프로토콜을 선택하는 것보다 디자인 시스템에 맞는 결과가 매번 재현되는지 검증하는 일이 중요하다.

6. 픽셀을 설계하지 않는 팀으로의 변화

생성형 UX는 산출물만 바꾸지 않고 Product·UX·Engineering 구성원의 일과 협업 언어까지 바꾼다.

6.1. 화면 설계에서 시스템 설계로 이동한 업무

1. 세 번째 도전

   1. 픽셀 단위 작업의 감소: 팀은 더 이상 전체 플로우의 모든 픽셀을 직접 디자인하지 않는다.
   2. AI의 흐름 결정: AI가 사용자 의도에 맞춰 상당 부분의 흐름과 화면 구성을 결정할 수 있게 됐다.
   3. 일의 성격 변화: 디자인 업무가 사라진 것이 아니라, 화면의 픽셀을 조정하는 일에서 생성 시스템의 경계와 규칙을 설계하는 일로 이동했다.

2. 비기술 직군에 요구되는 새 대화

   1. 스키마: PM과 UX 디자이너도 UI spec, Zod schema, 속성 정의를 이해하고 논의해야 한다.
   2. 큐레이션과 규칙: 어떤 컴포넌트와 템플릿을 카탈로그에 넣고, 어떤 질의가 어떤 컴포넌트로 매핑되는지 정해야 한다.
   3. 상호작용 패턴: 화면을 한 장씩 그리는 대신 질의·도구·컴포넌트·사용자 승인 사이의 상호작용을 설계해야 한다.

6.2. Synthetic Data와 매핑 테스트

1. 테스트 재료 만들기

   1. Synthetic Data: 다양한 도메인 상황과 결과를 시험하기 위해 합성 데이터를 생성한다.
   2. 질의 생성: 특정 컴포넌트로 이어져야 하는 사용자 질의를 만들고, 해당 질의가 올바른 매핑 로직을 거치는지 확인한다.
   3. 경계 사례: 유사한 의도·불완전한 요청·데이터가 많은 요청에서도 카탈로그와 레이아웃 규칙이 흔들리지 않는지 시험한다.

2. 팀의 역량 재구성

   1. 기술과 UX의 결합: 스키마·도구 호출·프로토콜을 이해하는 UX 역량과 정보 구조·카피·상호작용을 이해하는 엔지니어링 역량이 함께 필요하다.
   2. 판단의 보존: AI에게 결정권을 넘겨도 제품의 취향·품질 기준·사용자 안전에 대한 인간의 판단은 시스템 규칙에 반영돼야 한다.
   3. 조직 변화의 현실: 좋은 생성형 UX는 모델만 교체해서 얻을 수 없고, 사람·제품·프로세스가 함께 바뀌어야 한다.

6.3. People, Product, Process의 세 축

1. People

   1. 역할의 확장: PM, UX, Engineering 모두 생성 시스템의 구성 요소와 한계를 이해해야 한다.
   2. 협업 언어: 컴포넌트·스키마·큐레이션·규칙·합성 데이터가 직군 간 공통 언어가 된다.
   3. 학습 문화: 프로토콜과 모델이 빠르게 변하므로 팀은 지속적인 실험과 검토를 감당해야 한다.

2. Product와 Process

   1. Product: 제품은 자유로운 생성보다 사용자의 의도에 맞는 정보 구조, 일관된 디자인 시스템, 승인 가능한 결과를 제공해야 한다.
   2. Process: Gus가 말한 프로세스는 무겁고 관료적인 절차가 아니라 품질을 확인하는 가벼운 운영 루프여야 한다.
   3. 세 축의 균형: 사람을 준비시키지 않고 기술만 도입하거나, 카탈로그 없이 모델만 호출하거나, 검증 루프 없이 출하하면 생성형 UX의 장점이 유지되지 않는다.

주요 발언 모음

“We’re still adapting ourselves to the software that we ship, not the other way around.”

“If every single time you need to prompt, the model will output something different, this is not good.”

“The catalog is the contract between the agent and the UI.”

“Every property matters.”

“You’ve got to be in control.”

“My teams do not design the pixel anymore.”

핵심 데이터 & 수치

• 2022년 11월: GPT 등장 이후 실질적인 개인화 가능성이 널리 보였지만, 대부분의 소프트웨어 화면은 여전히 정적이었다.
• 300개 이상: commercetools가 보유한 API 규모이며, 의도 중심 UI가 연결해야 할 도구 표면의 크기를 보여준다.
• 네 가지 변형: “Create a sales report for Q1”라는 동일한 의도에 대해 KPI 카드·차트·텍스트·기간 표기가 서로 다른 네 개 화면이 생성됐다.
• 23분 18초: 자막 기준 전체 발표 길이.
• 다섯 단계: Atomic Design이 인터페이스 시스템을 계층적으로 만드는 단계 수로 소개됐다.

결론 및 시사점

1. 의도를 1급 입력으로 만들기: 사용자가 제품의 메뉴 구조를 학습하기 전에 자신의 업무 의도를 표현하고, 오케스트레이터가 이를 도구와 UI로 연결하게 한다.
2. 제어 수준을 먼저 결정하기: 예약·검색처럼 흐름이 명확한 제품은 고정 컴포넌트가 적합할 수 있고, 구성 복잡도가 높은 B2B SaaS는 선언적 중간 지대가 더 적합하다.
3. 컴포넌트 카탈로그를 제품 자산으로 다루기: 카탈로그의 각 property, 슬롯, 서브 슬롯, 템플릿, 스키마는 모델과 UI의 계약이므로 디자인 시스템 수준으로 관리한다.
4. 레이아웃 지식을 에이전트에 내장하기: Atomic Design과 템플릿 계층을 이용해 component → sub-slot → slot → template의 역방향 매핑을 정의한다.
5. 카피와 기간도 UX 품질로 검증하기: 화면 모양만 맞추지 말고 Q1이 January to March로 바뀌는 식의 의미·카피 드리프트를 막는다.
6. 합성 데이터와 질의로 운영 전 테스트하기: 각 컴포넌트에 매핑될 질의와 경계 사례를 만들어 스키마·도구·레이아웃을 반복적으로 검증한다.
7. 팀의 역할을 재설계하기: PM과 UX는 픽셀 제작을 덜 하더라도 스키마·큐레이션·규칙·상호작용 패턴에 더 깊이 관여해야 한다.
8. People, Product, Process를 함께 바꾸기: 생성형 UX 도입은 모델 API를 추가하는 프로젝트가 아니라 조직의 공통 언어와 가벼운 품질 프로세스를 재구성하는 일이다.
9. 데모와 제품을 구분하기: LLM이 HTML이나 조직도를 멋지게 렌더링하는 데모의 성공은 기업이 통제 가능한 프로덕션 UX의 성공을 의미하지 않는다.
10. 새로운 멘탈 모델: AI는 경험을 선택·조합하는 실행자이고, 제품팀은 허용된 컴포넌트·정보 구조·디자인 시스템·품질 기준을 설계하는 조향자여야 한다.

핵심 요약 (20줄)

정적 소프트웨어는 사용자가 제품마다 다른 정신 모델과 탐색 방식을 학습하게 만들어 인지 부하를 누적시킨다.

GPT가 2022년 11월 개인화 가능성을 보여줬어도 대부분의 화면은 여전히 정적인 방식으로 제공된다.

commercetools는 300개가 넘는 API를 정적 화면이 아닌 의도 중심 경험으로 연결할 방법을 질문했다.

컴포넌트 카탈로그만 주고 모델에게 화면을 조합하게 한 첫 실험은 같은 Q1 보고서 요청에 네 가지 레이아웃을 만들었다.

네 가지 결과는 KPI 카드와 차트의 양, 텍스트의 양, 정보 배치, Q1과 January to March라는 기간 표기가 서로 달랐다.

매번 다른 화면을 만드는 개인화는 사용자에게 선택지를 주는 대신 무엇이 맞는지 알 수 없는 혼란을 만든다.

현재 구조는 오케스트레이터가 질의 의도를 분류하고 적합한 자사·외부 도구와 MCP 에이전트를 호출한다.

도구 출력은 UX 에이전트가 의미 있는 화면을 만들 수 있도록 데이터와 맥락을 제공한다.

생성형 UI의 제어 수준은 고정 컴포넌트, LLM 완전 자율 렌더링, 선언적 UI의 스펙트럼으로 나뉜다.

고정 컴포넌트는 Booking처럼 흐름과 결과 카드의 형태가 분명한 제품에서 높은 일관성을 제공한다.

LLM 완전 자율 렌더링은 HTML을 sandboxed iframe에 삽입할 수 있지만 기업이 결과와 디자인 판단을 통제하기 어렵다.

commercetools는 JSON Render, OpenUI, HTMX, ATUI 등이 속한 선언적 중간 지대를 선택했다.

선언적 흐름은 UI spec을 방송하고 Zod 스키마에 맞는 React 네이티브 컴포넌트로 렌더링한다.

선언적 방식은 디자인 시스템을 지키지만 선택된 컴포넌트의 배치 문제까지 자동으로 해결하지는 않는다.

Atomic Design은 레이아웃과 슬롯 계층에 UX 지식을 담아 무작위 배치를 줄이는 방법을 제공한다.

오케스트레이터는 component에서 sub-slot, slot, template로 이어지는 역방향 매핑으로 화면을 조립한다.

컴포넌트 카탈로그는 에이전트와 UI 사이의 계약이므로 모든 property와 레이아웃 속성이 중요하다.

큐레이션은 단순한 데모가 아니라 의미 있는 업무 경험을 만드는 제품팀의 조향 장치다.

PM과 UX 디자이너의 일은 픽셀 설계에서 스키마, 규칙, 합성 데이터, 질의 매핑, 상호작용 패턴 설계로 이동한다.

생성형 UX의 성공 조건은 AI 모델 하나가 아니라 People, Product, Process를 함께 준비하는 가벼운 품질 운영 체계다.