Google은 2025년 11월에 Generative UI 실험을 출시했으며, 이는 테스트된 사례 중 약 절반 정도에서 인간이 설계한 인터페이스와 일치했습니다. 나머지 절반에서는 찌지 않은 만두가 음식인 것과 마찬가지로, 형태는 알아볼 수 있지만 실제로 먹을 수는 없는 아티팩트(artifact)를 생성했습니다. 이 시스템은 단일 페이지를 렌더링하는 데 1분 이상이 걸릴 수 있었고, 새로고침할 때마다 매번 다른 출력을 생성했습니다. 제가 읽은 대부분의 의견은 이 격차를 "더 많은 연산량(compute)이 해결할" 문제로 규정했습니다. 하지만 그렇지 않을 것입니다.

Google 자체의 점수 산정 방식도 이를 솔직하게 보여줍니다. 그들의 구현 방식은 ELO 점수 1736.2를 기록하며, 다른 모든 출력 형식보다 강력한 선호도를 보였으나, 오직 인간 전문가에게만 패배했습니다. 그리고 그 전문가와는 약 절반 정도의 확률로 일치했을 뿐입니다. 이는 잘못된 목표를 향한 인상적인 결과입니다.

어느 절반이 주목을 받는지 주목하십시오. "절반의 사례에서 인간 전문가와 대등하다"는 것은 관대한 해석입니다. 그 반대의 해석은 나머지 절반은 더 나쁘게 나온다는 것입니다. 그리고 화면은 하나씩 도착하는 것이 아니라, 워크플로(workflow)로 체인처럼 연결됩니다. 확률은 아무도 직관적으로 예상하지 못한 방향으로 복리로 작용합니다. 화면당 동전 던지기 확률(50%)이라고 가정할 때, 4단계의 흐름이 깔끔하게 렌더링될 확률은 16번 중 단 한 번, 즉 약 6%에 불과합니다. 즉, 사용자의 94%는 적어도 하나의 잘못된 화면을 마주하게 됩니다. 이를 6단계로 늘리면 그 수치는 98%에 달합니다. 데모는 동전 던지기처럼 들리지만, 워크플로는 거의 확실한 실족처럼 느껴집니다. 사람들은 "50%"라는 말을 들으면 대등한 수준이라고 생각합니다. 하지만 그렇지 않습니다. 그것은 공정한 도박으로 포장된, 거의 확실한 실패의 보증수표입니다.

"Generative UI"는 최소 세 가지의 서로 다른 기술적 접근 방식에 걸쳐 사용되는 명칭이며, 이러한 혼용으로 인해 논의가 어려움을 겪고 있습니다. 첫 번째는 모두가 감탄하지만 아무도 출시할 수 없는 데모입니다. 두 번째는 첫 번째 방식에서 약간 개선되었지만 여전히 제대로 작동하지 않는 방식입니다. 세 번째는 너무 온건해서 대부분의 사람들이 Generative UI 범주에 넣지도 않을 방식이며, 바로 이 방식이 승리할 것입니다.

한 가지 먼저 구분해 두어야 할 점이 있습니다. 나머지 논의가 이 차이에 달려 있기 때문입니다. 코드를 생성하는 것(generating code)과 인터페이스를 생성하는 것(generating interfaces)은 같지 않습니다. v0나 Claude Code와 같은 도구들은 UI를 생성하지만, 그 결과물은 정적인 산출물(static artifact), 즉 한 번 만들어 두고 재사용하는 상자와 같습니다. 여기서 중요하게 다루는 Generative UI는 런타임 동작(runtime behavior), 즉 사용하면서 문맥(context)과 입력에 따라 적응하는 인터페이스를 의미합니다. 이 둘의 차이는 AI에게 캠핑 장비를 담을 상자를 만들어 달라고 요청하는 것과, AI가 당신이 한 움큼의 통조림을 떨어뜨릴 뻔한 것을 지켜보다가 당신에게 배낭이 필요하다고 판단하여, 배낭을 꿰매어 건네주는 것의 차이와 같습니다. 후자는 경이로운 일입니다. 동시에 수많은 가정(assumptions)의 행렬이기도 하며, 그 가정 하나하나가 틀릴 수 있는 새로운 기회입니다. 이것이 대략 우리가 언어를 먼저 진화시킨 이유이기도 합니다. 누군가가 허둥대는 것을 보고 추론하는 것보다, 그 사람이 무엇을 필요로 하는지 직접 듣는 것이 더 낫기 때문입니다.

하나의 이름을 가진 세 가지 변체

가장 야심 찬 변체는 매 로드(load) 시마다 인터페이스를 처음부터 생성합니다. 모델이 프롬프트(prompt)를 받아 HTML, CSS, JavaScript를 작성하면, 브라우저가 그 결과물을 렌더링(render)합니다. 이 방식은 잠재력(ceiling)이 가장 높습니다. UI에 무엇이든 담길 수 있기 때문이며, Google이 데모에서 보여준 버전이기도 합니다. 하지만 이 방식은 사용 가능한 인터페이스를 만들어낼 확률이 동전 던지기 수준이었고, 페이지당 몇 분이 소요되었으며, 토큰(token)을 엄청나게 소모했고, 새로고침할 때마다 다르게 렌더링되었습니다. 모델을 10배 더 크고 빠르게 만든다 해도, 이는 여전히 확률적(stochastic)이며, 여전히 비용이 많이 들고, 여전히 일관성이 없습니다. 컴퓨팅 파워(Compute)가 문제의 본질적인 형태를 바꾸지는 못합니다.

중간 단계의 변형(Middle variant)은 모델을 유한한 컴포넌트 라이브러리(Component library)로 제한합니다. 레이아웃 코드(Layout code)를 작성하는 대신, 모델은 어떤 기존 컴포넌트를 어떤 속성(Props)과 어떤 배치로 렌더링할지 명시하는 직렬화된 페이로드(Serialized payload), 주로 JSON을 생성합니다. 클라이언트는 이 페이로드를 읽어 페이지를 조립합니다. 이는 진정한 개선입니다. 컴포넌트가 일관성을 유지하고, 새로고침할 때마다 접근성(Accessibility)이 저하되지 않으며, 모델이 디자인 시스템(Design system)에서 금지하는 것을 보낼 수 없기 때문입니다. 또한 실제로 추진력을 얻고 있습니다. Google은 정확히 이러한 방식의 에이전트 생성 인터페이스(Agent-emitted interface)를 표준화하기 위해 2025년 12월 A2UI를 오픈 소스로 공개했으며, 현재 일련의 상용 도구들을 통해 비기술직 직원들도 승인된 컴포넌트 세트 내에서 양식(Form)과 보고서를 조립할 수 있게 되었습니다. 대부분 지루한 일입니다. 하지만 대부분의 기업용 소프트웨어는 지루한 법이며, CIO(최고 정보 책임자)는 최소한 표준에 대해 어느 정도 발언권을 가질 수 있습니다. 이는 전화가 첫 번째 벨소리를 울리기도 전에 이미 식은땀을 흘리며 새벽 3시에 깨어날 확률을 조금이라도 줄여줄 만큼의 권한입니다.

문제는 중간 단계의 변형 역시 여전히 모델에게 화면 전체에 대한 권한을 부여한다는 점입니다. 모든 버튼, 모든 입력창, 모든 레이아웃 호출이 모델의 결정에 달려 있습니다. 전체 코드(Full-code) 버전을 신뢰할 수 없게 만들었던 변동성(Variance)이 컴포넌트 선택 축(Component-selection axis)으로 옮겨갔을 뿐입니다. 새로고침을 하면 필드 순서가 달라지거나, 빈 상태(Empty state)가 달라지거나, 기본 동작(Primary action)이 달라질 수 있습니다. 이는 추가적인 단계만 더해졌을 뿐 동일한 사용성(Usability) 문제입니다. 경쟁 관계에 있는 미완성 표준들과 디자이너가 아닌 사람들은 여전히 정보 흐름(Information flow)을 구성할 수 없다는 사실까지 더해지면, 이 변형 방식은 기반 시설(Plumbing)이 제대로 작동하는 곳에서조차 단기적으로 정체될 것입니다.

세 번째 변형 방식은 제품이 실제로 안착하게 될 지점입니다. 핵심 인터페이스(Core interface)는 결정론적(Deterministic)으로 유지하십시오. 즉, 인간이 설계하고, 고정된 컴포넌트(Components)로 배포되며, 방문할 때마다 예측 가능해야 합니다. 그런 다음 동적인 위젯 선택(Dynamic widget selection)이 일어나는 제한된 영역(Bounded surface)을 따로 마련하십시오. 디자인 팀은 유한한 위젯 라이브러리(20개, 30개, 50개 등)를 구축하고, 그 상위 계층(LLM, 단순 규칙 엔진(Rules engine), 또는 종종 이 둘 모두)이 어떤 맥락에서 어떤 위젯을 노출할지 결정합니다. 모델은 페이지를 레이아웃(Layout)하는 것이 아닙니다. 메뉴에서 선택하는 것입니다. 그 영역은 종종 보조적인 역할을 하지만, 반드시 그럴 필요는 없습니다. 누락된 데이터가 무엇인지 파악함에 따라 스스로 필드를 확장해 나가는 양식(Form)처럼, 그것이 주된 영역이 될 수도 있습니다.

음악의 80/20 법칙

효과적인 인터페이스는 효과적인 음악이 따르는 균형을 따릅니다. 노래의 대부분은 친숙합니다. 박자를 맞출 수 있고, 진행을 예측할 수 있으며, 기대하는 구조가 있습니다. 아주 얇은 조각만이 참신합니다. 예상치 못한 전조(Modulation), 갑작스러운 코러스 생략, 전혀 예상치 못한 반전 같은 것들 말입니다. 친숙한 부분은 당신이 음악을 들을 수 있게 해주는 이유입니다. 참신한 부분은 당신이 음악을 계속 듣게 만드는 이유입니다. 이 비율이 어느 한쪽으로 너무 치우치면 노래는 실패합니다. 반복이 너무 많으면 지루해지고, 참신함이 너무 많으면 들어줄 수 없게 됩니다.

인터페이스도 마찬가지입니다. 사용자가 접하는 대부분의 요소는 근육 기억(Muscle memory)을 형성하고 인터페이스의 외형(Chrome)을 의식하지 않을 정도로 충분히 예측 가능해야 합니다. 더 작은 참신한 부분 — 스마트한 기본값(Smart default), 맥락적 도우미(Contextual helper), 적시 위젯(Just-in-time widget) — 이 제품을 지능적으로 느껴지게 만듭니다. 이 비율을 뒤집으면 완전한 코드 기반의 생성형 UI(Generative UI)가 됩니다. 즉, 예측 가능한 것이 거의 없고 사용자가 방문할 때마다 인터페이스를 새로 배워야 하는 상태입니다. 모델이 매번 훌륭한 로컬 판단(Local call)을 내린다 하더라도 경험은 여전히 실패합니다. 왜냐하면 일관성(Consistency)은 개별 상호작용의 속성이 아니라, 상호작용 시퀀스(Sequence of interactions)의 속성이기 때문입니다.

세 번째 변형은 비율을 준수하지만, 그 비율은 각 화면이 아니라 제품 전체에 관한 것입니다. 결정론적 핵심 (Deterministic core)이 80%를 차지합니다. 동적 표면 (Dynamic surface)은 20%입니다. 일부 개별 화면은 매우 동적으로 기울어질 수 있으며, 그것은 괜찮습니다. 중요한 것은 사용자가 의존하는 부분은 그대로 유지되는 반면, 모델은 오류가 발생하더라도 복구 가능한 제한된 공간 내에서 영리하게 작동할 수 있어야 한다는 점입니다.

여행 앱 테스트

여행 예약은 제가 계속해서 다시 언급하는 예시인데, 그 이유는 가정이 매우 명확하게 드러나기 때문입니다. Kayak, Travelocity, 항공사 사이트들은 모두 한 명의 여행자 또는 한 그룹, 하나의 출발지, 하나의 목적지, 그리고 아마도 몇 개의 구간이 포함된 왕복 여정을 중심으로 구축되어 있습니다. 이것이 대부분의 여행을 커버합니다. 하지만 여행이 이 틀에 맞지 않는 순간 시스템은 무너지고, 인터페이스는 유연하게 대응할 수 있는 우아한 방법을 갖추고 있지 않습니다.

처녀 파티(Bachelorette party)를 상상해 보세요. 네 개의 도시에서 여섯 명의 친구가 라스베이거스로 모이며, 모두 Penn & Teller 티켓을 위해 금요일 오후 8시 전에는 착륙해야 합니다. 두 명은 업무 마감 기한 때문에 귀국 날짜가 고정되어 있고, 나머지 인원은 좀 더 유연합니다. 오늘날 여러분은 이를 여섯 개 이상의 브라우저 탭, 스프레드시트, 그리고 스크린샷으로 가득 찬 그룹 채팅으로 해결합니다. 아무도 이를 위한 인터페이스를 출시하지 않습니다. 이는 NP-형태 (NP-shaped)이며, 수작업으로 디자인할 가치가 없을 만큼 드문 경우이기 때문입니다.

Generative UI (생성형 UI)가 실제로 제공하는 가치는 다음과 같으며, 이는 데모 영상들이 시사하는 바와는 다릅니다. 당신은 처녀 파티(bachelorette) 케이스를 위해 인터페이스를 디자인하는 것이 아닙니다. 당신은 출발지 위젯(origin widget), 목적지 위젯(destination widget), 숙박 위젯(lodging widget), 지상 교통 위젯(ground-transport widget)을 각각 독립적으로, 그리고 각각 합리적인 기본값(defaults)을 갖도록 디자인하며, 모델에게 이들을 언제 유연하게 사용할지 알 수 있도록 충분한 컨텍스트(context)를 제공합니다. 출발지 위젯은 최대 10개의 도시를 수용하는 상태(state)를 확장하거나, 모델이 병렬 추적을 위해 캔버스에 두 번째 출발지 위젯을 배치합니다. 어떤 방식이든, 출발지 위젯은 출발지 위젯일 뿐입니다. 이 위젯은 여행이 라스베이거스를 왕복하는 한 명의 여행인지, 아니면 세 도시에서 집으로 흩어지는 여섯 명의 여행인지 알 필요도 없고 상관하지도 않습니다. 각 컴포넌트(component)에 충분한 유연성을 구축하고, 모델에게 좋은 기본값과 그 사이에서 선택할 수 있는 충분한 컨텍스트를 넘겨주면, 가능한 경우의 수(permutations)는 스스로 해결됩니다. 어차피 그 모든 경우를 일일이 수작업으로 디자인할 수는 없었을 것입니다.

동일한 메커니즘은 훨씬 더 흔한 사례인 비즈니스 루프 여행(business loop trip), 즉 A → B → C → D → A를 처리합니다. 핵심 인터페이스는 이 루프를 보여줍니다. 제한된 패널(bounded panel)이 비둘기집 원리(pigeonhole logic)를 실행합니다: 어떤 구간에 렌터카가 있는지, 없는지, 어떤 호텔이 확정되었는지, 어떤 호텔이 아직 열려 있는지 등을 판단합니다. 채워야 할 25개의 칸 중 16개가 채워지고 9개가 남았다면, 모델의 역할은 그 9개를 순위 매기고 가장 중요한 것을 다음에 노출하는 것입니다. 이를 렌더링(render)하는 위젯들은 이미 디자인되어 있습니다.

인터페이스가 아닌 경우의 수(Permutation)를 분해하라

나는 Reva에서 이 방식의 버전을 출시했습니다. 신용 및 범죄 경력 조회 보고서는 수천 가지의 경우의 수로 돌아오며, 우리는 지원자와 자산 관리자 모두에게 특정 결과가 실제로 무엇을 의미하는지 평이한 언어로 설명하는 동시에, 그 결과를 바탕으로 서로 다른 워크플로(workflow), 검증(validation), 에스컬레이션(escalation)을 실행할 수 있도록 그 범위를 표현해야 했습니다. 모든 조합에 대해 레이아웃을 디자인하는 것은 애초에 고려 대상이 아니었습니다.

그래서 그렇게 하지 않았습니다. 저는 스크리닝 결과(screening result)를 약 30개의 핵심 지표(metrics)로 분해했습니다. 인터페이스는 헤드라인(headline), 부제목(subheading), 요약(summary), 크레딧 라인 항목(credit line item) 등 12개의 영역(regions)으로 분해했습니다. 그런 다음 각 영역을 채울 수 있는 5개에서 20개의 텍스트 변체(text variants)로 다시 분해했습니다. 그 결과물은 i18n 키(i18n keys)를 구동하는 30여 개의 지표로 구성된, 깔끔하고 사람이 읽을 수 있는 JSON 페이로드(payload)였습니다. 그리고 이 키들은 범죄 기록 플래그(criminal flag)가 있는 깨끗한 신용 정보, 아무 기록도 없는 얇은 파일(thin file) 등 모든 조합을 커버했습니다. 저는 전체 순열(permutation)을 한 번에 해결하지 않았습니다. 저는 작고 독립적인 조각들을 해결했으며, 이것이 제가 결과가 수학적으로 완전하다는 것을 증명할 수 있었던 유일한 이유였습니다. 결국 그것은 일련의 규칙(rules)이었습니다. 정보 문제를 충분히 깔끔하게 분해하면 겉으로 보이는 복잡성의 대부분은 실제로 존재하지 않았습니다. 찾으려고 노력한다면 모든 물류 문제(logistics problem)에는 Shannon의 지문이 남아 있습니다.

이것이 왜 나쁜 상황의 리스크를 줄이는가 (De-Risks)

세 번째 변체는 야심 찬 방식들이 갖지 못한 조용한 이점을 가지고 있습니다. 모델이 틀렸을 때 — 그리고 모델은 일상적으로 틀릴 것입니다 — 그 피해는 사용자가 무시할 수 있는 표면(surface) 내에 머뭅니다. 핵심 인터페이스는 계속 작동하고, 기본값(defaults)은 정상적으로 유지되며, 디자인 팀이 크롬(chrome, 인터페이스 외곽 요소)을 소유하고 있기 때문에 탈출구(escape hatches)를 설계하기가 쉽습니다.

전체 코드(full-code) 변체에서 모델의 실수는 깨진 페이지입니다. 모든 곳에 컴포넌트가 있는(component-everywhere) 변체에서 모델의 실수는 사용자가 해독해야 하는 혼란스러운 레이아웃입니다. 하지만 경계가 정해진(bounded) 변체에서 모델의 실수는 사용자가 무시할 수 있는(또는 다음 호출을 날카롭게 만들기 위한 신호를 다시 피드백으로 제공하는 교정 작업을 수행할 수 있는) 이상하게 선택된 위젯일 뿐이며, 그동안 사용자의 실제 작업은 건드려지지 않은 채 계속 실행됩니다. 동일한 모델, 동일한 오류율이지만, 폭발 반경(blast radius)은 판이하게 다릅니다.

실제로 무엇을 구축해야 하는가

만약 제가 오늘 제품에 생성형 UI (Generative UI)를 구축한다면, 그 작업은 구체적입니다. 유한한 위젯 라이브러리 (widget library)를 구축하십시오. 여러분의 애플리케이션이 실제로 보유한 워크플로우 구성 요소를 아우르는 20개에서 50개 사이의 위젯을 만드십시오. 핵심은 관심사의 깔끔한 분리 (separation of concerns)입니다. 만약 기점(origin) 위젯이 오직 기점만을 캡처한다면, 그것은 거의 모든 물류 작업의 핵심인 정보 문제에 정확히 하나의 조각(slice)을 기여하게 됩니다. 각 위젯이 어떤 데이터를 읽는지, 어떤 상태(states)를 가질 수 있는지, 어떤 컨텍스트(context)가 해당 위젯을 관련성 있게 만드는지를 정의하십시오. 그런 다음 실시간 컨텍스트, 즉 사용자가 무엇을 하고 있는지, 무엇을 완료했는지, 무엇이 여전히 누락되었는지에 따라 위젯을 선택하는 선택 계층 (selection layer) — 때로는 LLM, 때로는 규칙 엔진 (rules engine), 대개는 둘 다 — 을 구축하십시오.