AI가 UI를 직접 생성하는 시대가 왔다. 텍스트 대신 컴포넌트를, JSON 대신 렌더링 가능한 마크업을 돌려주는 Generative UI는 이미 데모를 넘어 프로덕션 로드맵에 올라와 있다. 문제는 속도다—모델의 생성 속도는 빨라졌지만, 그 출력을 안전하게 받아낼 인프라는 여전히 대부분의 팀에 존재하지 않는다.
아무도 말하지 않는 세 가지 고장 지점
dev.to에 공개된 「The Missing Layer Between LLMs and Your DOM」은 Generative UI를 실제로 배포할 때 반드시 마주치는 세 가지 문제를 정면으로 꺼낸다. 첫째, LLM 출력은 본질적으로 신뢰할 수 없는 입력이다. dangerouslySetInnerHTML에 CMS 대신 모델을 꽂은 것과 다르지 않다. 시스템 프롬프트는 보안 경계가 아니다—모델은 얼마든지 인라인 이벤트 핸들러나 외부 fetch를 hallucinate할 수 있다. 둘째, 모델은 당신의 디자인 시스템을 모른다. 존재하지 않는 prop을 자신 있게 생성하고, 6버전 전 API를 현재인 양 쓴다. 셋째, 스트리밍 UI는 스트리밍 텍스트와 전혀 다른 문제다. 토큰 단위로 HTML이 흘러들어오면 반쯤 닫힌 태그, prop이 아직 완성되지 않은 컴포넌트, 렌더마다 스크롤 위치와 포커스를 잃는 상태 파괴가 뒤따른다.
그래서 레이어가 필요하다
기사가 제안하는 해법은 세 개의 독립된 레이어다. 격리(Isolation): 모델 출력은 호스트 페이지 DOM에 닿아선 안 된다. 자동 생성된 엄격한 CSP와 타입드 postMessage 채널을 갖춘 샌드박스 iframe이 그 경계를 만든다. 생성 시점 검증(Ground truth at generation time): 모델이 컴포넌트 API를 기억에 의존해 추측하는 대신, 실제 빌드 산출물에서 추출한 타입 시그니처와 예시를 MCP 서버로 제공해야 한다. 사람이 관리하는 문서가 아니라 코드 자체가 정보의 원천이 된다. 패치 기반 스트리밍(Real patch, not re-render): 청크가 들어올 때마다 DOM을 전체 교체하는 대신, 스크립트·상태·포커스를 보존하면서 변경분만 적용하는 patch() 인터페이스가 필요하다. 오픈소스 TypeScript 툴킷 Vielzeug는 이 세 레이어를 실제 코드로 구현한 레퍼런스다.
Phantom CLS: 눈에 안 보이는 성능 부채
Generative UI 논의와 별개로, 「Phantom CLS in Lighthouse」 기사는 AI와 무관해 보이지만 정확히 같은 문제를 건드린다—런타임에 동적으로 주입되는 UI가 레이아웃을 얼마나 조용히 망가뜨릴 수 있는가. Phantom CLS란 눈으로는 보이지 않지만 Lighthouse와 Chrome이 감지하는 레이아웃 이동이다. 히어로 배너의 loading="lazy" 하나, defer 없는 스크립트 두 줄이 CLS 점수를 무너뜨린다. 치료제는 단순하다: 폴드 위 이미지는 fetchpriority="high"와 preload로 우선순위를 높이고, 동적으로 주입되는 컴포넌트가 차지할 공간을 min-height로 미리 예약한다. 핵심은 defer만으로는 부족하다는 것—공간 예약 없는 지연 로딩은 오히려 레이아웃 간격을 더 도드라지게 만든다.
연결고리: AI가 생성한 UI도 같은 법칙을 따른다
여기서 두 기사의 교점이 생긴다. Generative UI가 샌드박스 iframe 안에서 스트리밍으로 렌더링될 때, 각 청크는 사실상 '동적으로 주입되는 UI 컴포넌트'다. patch() 인터페이스가 상태를 보존한다 해도, 컴포넌트가 차지할 공간을 미리 선언하지 않으면 Phantom CLS는 그대로 발생한다. 모델이 생성한 히어로 이미지에 width·height 속성이 없다면? 슬라이더 컴포넌트가 JS 실행 후 크기를 바꾼다면? 검증 레이어가 Custom Elements Manifest 기준으로 마크업을 체크할 때 레이아웃 안정성 속성까지 포함하지 않으면, CLS는 자동으로 딸려온다.
오프라인 에이전트가 더하는 변수
dev.to에 공개된 Oryn 프로젝트—Ollama 기반으로 100% 로컬에서 동작하는 데스크톱 AI 코딩 에이전트—는 또 다른 시나리오를 추가한다. 클라우드 모델 대신 로컬 모델이 UI 코드를 생성할 경우, 프론티어 모델 대비 멀티스텝 추론 품질이 낮아지는 트레이드오프가 있다. Oryn 개발자 스스로 인정하듯, 로컬 모델은 단순 리팩토링이나 보일러플레이트에는 충분하지만 복잡한 컴포넌트 조합에서는 격차가 드러난다. 검증 레이어 없이 로컬 모델 출력을 그대로 DOM에 올리면, 보안과 성능 부채가 동시에 쌓인다. Oryn이 제시하는 단계별 승인(manual approval gate)은 그 간극을 사람이 메우는 방식—좋은 설계지만, 규모가 커지면 한계가 온다.
개발자가 설계해야 할 것들
세 기사를 하나의 맥락으로 읽으면 시사점이 선명해진다. Generative UI는 기존 UI를 대체하는 게 아니라, 손으로 짜기엔 경우의 수가 너무 많은 '애드혹 표면'에 쓰인다. 그리고 바로 그 표면에서 성능과 안정성에 대한 책임 소재가 가장 불분명해진다. 모델은 코드를 생성하지만 Core Web Vitals 점수를 책임지지 않는다. 에이전트는 파일을 쓰지만 레이아웃 시프트를 디버깅하지 않는다.
지금 당장 팀이 설계해야 할 것은 세 가지다: 모델 출력이 DOM에 닿기 전 거치는 격리 경계, 생성된 마크업이 컴포넌트 스펙을 충족하는지 확인하는 검증 게이트, 동적 컴포넌트가 주입되기 전 레이아웃 공간을 선점하는 공간 예약 규약. 이 세 가지가 없으면, AI가 짜준 UI는 빠르게 배포되고 천천히 무너진다.
전망: 검증 인프라가 다음 차별점이 된다
Generative UI가 프로덕션 표준이 되는 속도는 생각보다 빠를 것이다. v0.dev, Cursor, 그리고 각종 AI 코딩 에이전트가 컴포넌트 코드를 쏟아내는 속도는 이미 인간의 리뷰 속도를 앞서고 있다. 그 격차를 좁히는 건 더 좋은 모델이 아니라 더 촘촘한 검증 파이프라인이다. Custom Elements Manifest 기반 자동 검증, 샌드박스 환경에서의 CLS 사전 측정, 청크 단위 레이아웃 안정성 체크—이런 인프라를 먼저 갖춘 팀이 AI 생성 UI를 신뢰 가능한 수준으로 운용하는 팀이 된다. 속도는 모델이 제공하지만, 신뢰성은 팀이 설계하는 것이다.