AirJelly의 GenUI 엔진을 구축하며 남긴 노트 — 그리고 LLM에 더 많은 자유를 줬더니 결과가 더 나빠진 이유.
Translated by AI이 블로그는 AirJelly 프로젝트에서 GenUI 엔진을 직접 탐구한 경험에서 나왔습니다. 우리는 이론에서 시작하지 않았습니다. 솔직히 꽤 답답했던 한 실험에서 시작했습니다: LLM에 UI를 생성할 자유를 더 많이 줬는데 왜 결과가 더 나빠졌을까?
세부 사항에 들어가기 전에, GenUI가 단순한 데모 트릭이 아니라 진지한 엔지니어링 문제인 이유를 분명히 짚고 넘어갈 가치가 있습니다. Generative Interfaces for Language Models에서 SALT-NLP / Stanford 팀은 GenUI와 전통적인 텍스트 기반 채팅 사이의 사용자 선호도를 비교했습니다. 결론은 명확합니다: AI 시스템이 구조화되고 정보 밀도가 높은 콘텐츠를 전달해야 할 때, 동적으로 생성된 인터페이스는 텍스트의 벽보다 훨씬 나을 수 있습니다.
GenUI의 물결은 2023년에서 2025년 사이에 가속화되었는데, 두 가지 조건이 동시에 성숙했기 때문입니다: LLM이 코드 생성에서 훨씬 나아졌고, shadcn/ui와 Radix 같은 컴포넌트 생태계가 그 위에 구축할 수 있을 만큼 안정화되었습니다. 그 조건들이 갖춰지자 도구들이 자연스럽게 등장했습니다 — Vercel v0는 가장 대표적인 업계 구현 중 하나입니다.
feat/genui-real-content-experiment 브랜치에서 우리는 일련의 비교를 진행했습니다. 기존 접근 방식은 고정된 레이아웃과 통일된 컴포넌트를 가졌습니다 — 세련되고 예측 가능했습니다. 새로운 접근 방식은 레이아웃을 더 유연하게 만들었지만, 시각적 결과물은 지저분해지고 컴포넌트 스타일은 일관성이 없어졌습니다.
이것은 우리의 직관에 반했습니다. 모델에 더 많은 자유를 줄수록 통제력은 줄어들었고, 시각적 일관성은 더 나빠졌습니다. Gen-UI-Lang 논문도 같은 점을 지적합니다: LLM에게 원시 HTML이나 JSX를 요청하면 출력은 장황하고 취약하며 쉽게 깨집니다. 그것은 프롬프트 품질의 문제가 아닙니다 — 우리가 LLM을 그것이 가장 잘하지 못하는 세분화 수준으로 밀어붙였다는 뜻입니다.
실험을 통해 우리는 사실상 모든 GenUI 시스템에 적용되는 내부 모순을 확인했습니다.
LLM이 가진 자유도가 높을수록 시각적 일관성을 보장하기가 더 어려워집니다. 제약이 강할수록 GenUI는 의미가 줄어듭니다.
이것은 하나의 구현에 있는 버그가 아니라 패러다임의 구조적 긴장입니다. 모든 GenUI 시스템은 이 두 힘 사이 어딘가에서 균형점을 찾아야 합니다. 그래서 질문은 매우 구체적으로 바뀝니다: LLM의 생성 경계는 어디에서 멈춰야 하는가?
우리만의 답을 정하기 전에, 다른 이들이 같은 질문에 어떻게 접근했는지 살펴보는 것이 도움이 됩니다.
v0는 LLM이 끝까지 내려가 완전한 React 컴포넌트 코드를 생성하도록 합니다. 시각적 일관성은 shadcn/ui의 시맨틱 토큰 시스템에서 나옵니다 — 일관성을 라이브러리의 테마에 외주화하는 것입니다. 비용은: 생성 로직이 컴포넌트 생태계에 강하게 결합되어, shadcn/ui + Next.js + Vercel 스택에서 벗어나면 실질적인 마찰이 생깁니다.
<Card className={cn("flex flex-col",
plan.recommended && "border-primary shadow-lg scale-105"
)}>SALT-NLP / Stanford 접근 방식은 자연어와 UI 코드 사이에 구조화된 중간 표현을 삽입하며, 두 수준으로 나뉩니다: 고수준 상호작용 흐름(사용자 경로와 작업 단계의 방향 그래프)과 저수준 유한 상태 기계(각 컴포넌트의 상태와 이벤트 응답)입니다. 최종 출력은 여전히 HTML, CSS, JavaScript입니다 — 그 표현은 목적지가 아니라 가드레일입니다.
Gen-UI-Lang은 전용 DSL을 설계하여 LLM이 구조화된 노드 설명만 출력하도록 합니다. 노드 구조는 명시적이고 얕으며 일관적입니다 — 바로 LLM이 안정적으로 생성하는 것입니다. HTML을 직접 생성하는 것과 비교해 토큰 사용량이 65.3% 감소했다고 보고하면서 안정성은 향상되었고, 동일한 설명으로부터 HTML, React JSX, 또는 Gradio로 렌더링할 수 있습니다.
genui(
row(
text("Sales Overview"),
btn("Load", on_load=lambda: get_graph(2001, 2002))
),
chart(type="line", data="sales_q4"),
)세 가지 접근 방식 모두 LLM을 렌더링 계층에서 멀어지게 위로 밀어 올립니다. 차이는 어디에서 멈추는지뿐입니다. 우리는 그들 중 어느 것보다 더 높은 곳에서 멈추기로 했습니다: 제품 의미론 계층입니다.
LLM은 row나 btn 같은 일반적인 UI 노드를 출력하지 않습니다. 제품 개념을 출력합니다 — "이것은 작업 요약 카드이고, 정보 밀도가 높으며, 오늘의 캘린더에서 가져온 것입니다." 어떤 컴포넌트를 렌더링할지, 어떻게 배치할지는 전적으로 컴포넌트 라이브러리가 결정합니다 — LLM이 아닙니다.
LLM의 생성 자유도를 풀자 시각적 결과가 더 나빠졌습니다. LLM이 렌더링 계층에 가까워질수록 그 무작위성의 비용이 더 커집니다.
브라우저는 페이지 JavaScript가 픽셀을 직접 제어하도록 두지 않습니다. 통제된 DOM 설명을 받아들이고, 엔진이 픽셀을 결정합니다. GenUI 엔진도 같은 방식으로 작동해야 합니다.
OpenAI는 2024년에 형식 이탈에 맞서기 위해 Structured Outputs를 출시했습니다. 출력이 렌더링 계층에 가까울수록 형식 오류의 비용이 더 커집니다.
제품 의미론 계층에서 멈추면 컴포넌트 라이브러리는 플러그 가능한 렌더링 백엔드가 됩니다 — 의미론 계층을 건드리지 않고 내일 디자인 시스템을 교체할 수 있습니다.
복잡한 GenUIPager 컴포넌트를 디버깅하던 중, 우리는 단일 LLM 패스가 콘텐츠 품질과 레이아웃 품질을 동시에 최적화하는 데 어려움을 겪는다는 것을 발견했습니다. 그것이 우리를 2라운드 아키텍처로 이끌었습니다 — 가설로서.
First-round LLM: content orchestration + page-structure decisions
(product semantics layer)
↓
Second-round LLM / component library: concrete rendering decisions동기는 합리적입니다: 콘텐츠 오케스트레이션과 렌더링은 서로 다른 인지 작업이며, 이를 단일 패스로 강제하면 서로 간섭할 수 있습니다.
하지만 솔직해져야 합니다: 이것은 가설일 뿐이며, 우리는 이를 완전히 검증하지 못했습니다.
이것이 여기 있는 이유는 탐구할 가치가 있는 방향을 가리키기 때문이지, 확정된 결론이기 때문이 아닙니다.
보편적으로 옳은 세분화 선택은 없습니다. 그것은 제품이 시각적 불일치를 얼마나 용인하는지, 컴포넌트 라이브러리의 예상 수명 주기, 그리고 생성된 콘텐츠가 얼마나 구조화되어 있는지에 달려 있습니다.
| 접근 방식 | LLM이 출력하는 지점 | 일관성 보장 방식 | 라이브러리 교체 가능? | 적합한 시나리오 |
|---|---|---|---|---|
| Vercel v0 | 컴포넌트 코드 계층 | shadcn/ui 시맨틱 토큰 | 아니오, 강하게 결합됨 | Vercel 생태계 내 신속한 프로토타이핑 |
| Gen-UI-Lang | 일반 UI 의도 계층 | 다중 대상 렌더러 | 예, 프레임워크 독립적 | 크로스 프레임워크 프로토타이핑, 효율성 우선 워크플로 |
| arXiv 접근 방식 | HTML / CSS / JS | 가드레일로서의 구조화된 중간 표현 | 상황에 따라 다름 | 상호작용 복잡성이 높은 시나리오 |
| AirJelly | 제품 의미론 계층 | 컴포넌트 라이브러리가 렌더링을 전적으로 소유 | 예, 플러그 가능 | 제품 UI 일관성에 대한 요구가 높은 애플리케이션 |
제품이 시각적 불일치를 잘 용인하지 못한다면, 세분화는 더 높아야 하며 제품 의미론에 더 가까워야 합니다. 컴포넌트 라이브러리가 진화하거나 교체될 가능성이 있다면, 더욱 높아야 합니다. 그리고 생성된 콘텐츠가 고도로 구조화되어 있다면, 더 높은 수준에서 의미론적으로 설명하는 것이 더 적합합니다.
가장 큰 깨달음은 우리가 정답을 찾았다는 것이 아닙니다. 우리가 질문을 명확히 했다는 것입니다. GenUI는 LLM이 인터페이스를 그리게 하는 것이 아닙니다. LLM과 렌더링 시스템 사이의 명확한 책임 분담을 설계하는 것입니다.
세분화 수준의 선택이 그 경계선이 어디에 그어지는지를 결정하고, 경계선이 어디에 그어지는지는 시스템의 유지보수성, 시각적 안정성, 그리고 장기적으로 진화할 수 있는 능력을 결정합니다.
2025년 10월, W3C 디자인 토큰 커뮤니티 그룹은 안정적인 Design Tokens 2025.10 사양을 발표했습니다. 이는 의미론을 시각적 요소로부터 분리하는 것이 엔지니어링 표준이 되어가고 있다는 신호입니다. GenUI의 세분화 문제는 바로 그 같은 흐름이 AI 생성 인터페이스 내부에서 나타나는 것입니다.
우리는 아직 그 길 위에 있습니다. 비슷한 것을 탐구하고 계신다면, 이야기를 나누고 싶습니다.
AirJelly 팀의 더 많은 글 →