AI 디자인 도구의 다음 혁신은 Prompt가 아니라 Inspectable Design AST일 수 있다

Prompt-to-UI 도구는 시작이 빠르다. 대신 완성된 화면이 의도와 다르면 문제가 프롬프트에 있었는지, 모델의 해석에 있었는지, 생성 중 추가된 가정에 있었는지 알기 어렵다. 사용자는 숨은 판단을 직접 고치는 대신 프롬프트를 바꾸고 전체 결과를 다시 뽑는 식으로 디버깅하게 됨.

LEGOUI는 이 문제를 최종 결과의 품질만으로 풀지 않는다. 자연어 Prompt와 UI 사이에 UI-DSL이라는 추적 가능한 중간 설계 표현(intermediate design representation)을 두고, 모델의 설계 판단을 사용자가 검토하는 단계형 생성 프레임워크다. 연구진은 특히 초기 아이데이션 단계의 초보 사용자를 대상으로 이 구조를 설계함.

01. 먼저 Prompt와 모델의 추론을 분리한다

연구진이 세운 설계 목표는 순서대로 다음과 같다.

1. 구조화된 Prompt와 명시적 추론 — 사용자가 직접 말한 내용과 모델이 추론한 내용을 분리한다. 작업 목표·컴포넌트 요구사항·인터랙션 선호 등을 드러내 해석을 추적하고 조정할 수 있게 함.
2. 제어 가능한 단계형 생성 — 레이아웃·인터랙션·스타일을 한 번에 섞지 않고, 설계 차원별 단계로 나눈다. 각 단계의 결과와 판단 출처를 구조화된 표현에 기록함.
3. 추론의 사용자 수정 — 모델이 보충한 구조나 컴포넌트가 의도와 다르면 거부하고, 사용자가 요구사항을 추가하거나 바꿀 수 있게 한다.

핵심은 완성된 화면을 사후 수정하는 데서, 화면을 만들 조건을 사전에 검토하는 쪽으로 개입 시점을 옮기는 것임. 모델이 내린 판단은 잠정적인 설계 약속이고, 사용자가 남길 것과 버릴 것을 정한다.

02. 생성은 다섯 단계를 지나며 명세를 누적한다

LEGOUI의 단계는 요구사항 분석 → 레이아웃 생성 → 인터랙션 생성 → 관계 생성 → 스타일 생성 순서다. 첫 단계는 Prompt에서 Base UI-DSL brick을 추출한다. 뒤의 네 단계는 현재까지 쌓인 명세를 입력으로 받아 새 판단을 더함.

레이아웃 단계는 기존 컴포넌트를 페이지 구조에 배치하면서 필요한 속성이나 전역 경로를 보충할 수 있다. 인터랙션 단계는 배치된 컴포넌트와 그 속성을 참조해 이벤트와 동작을 만든다. 관계와 스타일도 같은 방식으로 누적된 상태 위에 기록됨.

각 단계에서 새로 생긴 판단은 바로 다음 단계로 숨겨지지 않는다. 사용자가 확인할 수 있는 항목으로 노출되고, 검토 결과가 이후 추론의 입력이 된다. 한 단계의 결정이 다음 단계의 제약이 되는 구조임.

03. 일곱 종류의 brick이 현재 설계 상태를 표현한다

UI-DSL은 설계 판단을 독립적으로 가리키고 수정할 수 있는 최소 단위, 즉 brick으로 기록한다. 최상위 명세는 논문 순서대로 일곱 종류다.

모든 항목에는 provenance가 붙는다. Prompt에서 나온 판단인지, 모델이 추론했는지, 사용자가 추가하거나 수정했는지를 구분하고 이력을 유지함. 요구사항 분석 화면에서는 Prompt 유래 항목을 원문의 강조 구절과 연결한다.

사용자가 항목을 거부하면 user_edit 출처와 remove subtype의 provenance가 추가되고, 해당 판단은 이력에서 지워지는 대신 활성 추론 상태에서 제외된다. 새 요구사항은 add subtype을 가진 새 항목이 되어 후속 단계의 명시적 가정으로 들어감. 논문은 수정과 재수락도 지원한다고 설명하지만, 별도의 revise 문법이나 정확한 수락 token까지 정의하지는 않는다.

04. 렌더링은 Prompt가 아니라 선택한 명세 상태에서 시작한다

현재 UI-DSL은 어느 시점에서든 HTML 기반 UI 코드로 렌더링할 수 있다. 첫 결과가 나온 뒤에도 명세는 남는다. 사용자가 항목을 바꾸고 특정 UI-DSL 상태를 선택하면, 원래 Prompt부터 다시 해석하지 않고 그 상태에서 새 UI나 변형을 생성함.

프로토타입은 Vue 3와 Ant Design 프런트엔드, Python과 FastAPI 백엔드로 구현됐다. Claude Sonnet 4를 주 모델로 쓰며 GPT-4o와 Gemini 2.5도 지원한다. 결과물은 현재 명세에서 생성한 HTML이고, 새 생성을 실행할 때 갱신됨.

05. 기술 평가는 전체 파이프라인이 아니라 첫 관문만 측정했다

기술 평가의 범위는 요구사항 분석 단계가 Prompt의 명시적 내용을 일곱 명세로 얼마나 잘 분해하는가다. 레이아웃 추론, 인터랙션 실행, 관계의 정확성, 스타일 렌더링, 생성 HTML의 품질이나 종단 간 동작은 평가하지 않았다.

데이터는 UIPrompt에서 모은 장문 Prompt 36개를 GPT-4o로 150–200단어, 컴포넌트 6–10개, 인터랙션 2–4종, 명시적 스타일 제약 1–3개 조건에 맞춰 다시 쓴 것이다. 기존 36개에 relationSpec이 없어 같은 복잡도의 GPT-4o 생성 Prompt 4개를 더해 총 40개로 구성함. 두 annotator가 정답 checklist를 독립 작성한 뒤 토론으로 불일치를 해소했고, 시스템 출력은 UI 명세 전문가 두 명과 제3 검토자가 판정했다. 다만 inter-rater reliability 수치는 보고하지 않았다.

결과는 intentSpec 97.30%, componentPool 97.55%, interactionSpec 95.24% 정확도였다. relationSpec은 100%였지만 단위가 14개뿐이다. 가장 약한 styleSpec은 정확도 89.29%, coverage 90.91%였고, 전역 조건·레이아웃·인터랙션과 스타일의 경계에서 오류가 집중됐다. 모든 범주의 redundancy는 0%로 보고됨.

이 수치는 통제된 재작성·추가 Prompt에서 명시적 요구사항을 추출하는 능력의 근거다. 실제 사용자 Prompt 전체나 후속 생성 품질로 일반화할 수는 없다. 논문은 정답이 40개 Prompt의 484개 항목이면서 Prompt당 평균 9.7개라고 적었는데, 두 수치는 산술적으로도 일치하지 않으며 본문에서 해소되지 않음.

06. N=15 연구에서 편집 과정의 평가는 높았지만 통계 검정은 없었다

사용자 연구는 15명 대상의 within-subject 설계였다. 대학원생·연구자·개발자로 구성됐고 생성 디자인 도구 경험은 초급 11명, 중급 4명이었다. 모든 참가자가 약 75분 동안 Task 1, 2, 3을 같은 순서로 수행함.

Task 1은 dashboard·portfolio·productivity Prompt에서 LEGOUI, Claude Chat, Bolt, Lovable, Vercel v0의 익명화된 결과를 평가했다. 다섯 기준의 전체 Prompt 평균에서 LEGOUI는 의도 정렬 4.22, 사용성 4.31, 접근성 4.49, 시각적 일관성 4.53, 신뢰성 4.42로 가장 높았다. Claude Chat은 순서대로 3.82, 3.73, 3.87, 4.20, 3.78이었다. LEGOUI는 23번 1순위, 13번 2순위로 선택됐고 Claude Chat은 각각 11번, 13번이었다.

논문은 Task 1의 일부 시스템 쌍에 paired t-test 유의성 표시를 제시한다. 그러나 정확한 p-value, t, 자유도와 숫자로 된 Cohen’s d는 싣지 않았고 다중 비교 보정이나 가정 검사도 밝히지 않음. 별표가 없는 비교를 동등하다고 해석할 수도 없다.

Task 2에서 참가자는 LEGOUI·Claude Chat·Bolt의 전체 Prompt-to-UI 흐름을 사용했다. LEGOUI 안에서 단계별 설명이 결과의 출처를 이해하는 데 도움이 됐다는 항목은 4.33±0.72, 설명이 신뢰 판단에 도움이 됐다는 항목은 4.87±0.35였다. 반면 정보가 너무 많다는 역문항은 3.00±1.25로 응답 차이가 컸다. 이 Task의 수치는 LEGOUI 단독 questionnaire이며 baseline과의 추론 통계 비교는 없다.

Task 3은 세 도구에서 생성 후 편집을 수행했다. LEGOUI·Claude Chat·Bolt는 서로 다른 Prompt와 짝을 이뤘고 그룹 사이에 고르게 배분됐다. LEGOUI의 편집 대상은 컴포넌트·레이아웃·관계·인터랙션·스타일로 나눴고, Claude Chat과 Bolt에서는 one-shot UI를 최소 두 번 수정함.

다섯 차원 평균은 다음과 같다. 순서는 제어 / 설명·투명성 / 의도 정렬 / 사용성·신뢰 / 작업 효과·탐색임.

• LEGOUI — 4.38 / 4.57 / 4.31 / 4.31 / 4.60
• Claude Chat — 2.96 / 3.20 / 2.93 / 3.29 / 3.07
• Bolt — 3.38 / 3.10 / 3.44 / 3.87 / 3.60

방향과 평균 차이는 분명하지만 Task 3에는 SD, error bar, pairwise p-value, 검정 통계량, effect size가 없다. 따라서 이 결과만으로 편집 과정의 차이가 통계적으로 유의하다고 말할 수 없음. 인터뷰에서도 다수는 단계별 제어를 선호했지만 P12와 P15는 표현이 이해하기 쉽고 결과가 정확·완전하다는 이유로 Bolt를 선호했다.

07. 보이는 판단이 항상 판단하기 쉬운 것은 아니다

참가자는 컴포넌트처럼 목표와 가까운 결정을 비교적 쉽게 검토했다. 반면 인터랙션과 관계는 여러 컴포넌트·페이지·상태에 효과가 퍼져 텍스트만으로 결과를 예상하기 어려웠다. 논문도 LEGOUI가 해석의 투명성과 추론의 투명성은 더 잘 지원했지만, 결정이 화면에 어떤 영향을 줄지 보여주는 결과의 투명성은 약했다고 구분함.

중간 판단을 모두 노출하면 검토 비용도 생긴다. 단계형 생성은 일을 없애기보다 one-shot 이후의 사후 수정 일부를 렌더링 전의 검사로 옮긴다. 사용자가 중요도나 결과를 알기 어려운 항목까지 같은 비중으로 읽어야 하면 통제 장치가 정보 과부하가 될 수 있음.

구현과 연구 범위도 좁다. 현재 결과는 가벼운 HTML mockup이라 시각적 풍부함, 데이터 모듈화, 큰 프로젝트 통합, 직접 코드 편집이 제한된다. 뒤 단계의 수정이 앞 결정과 충돌해도 이를 자동 처리하지 않으며, 레이아웃이 인터랙션을 바꾸는 식의 교차 의존성이 있어도 단계 순서는 고정돼 있다.

사용자 연구는 작은 표본이고 대부분 초보자이며, 한 번의 짧은 세션에서 Task 순서도 고정됐다. Task 3은 시스템마다 다른 Prompt를 배정했기 때문에 Prompt 효과가 남을 수 있다. 전문 UI 디자이너의 장기 작업이나 프로덕션 프로젝트에서 같은 효과가 나는지는 이 연구로 확인되지 않음.

crit의 관점

논문은 AST라는 표현을 쓰지 않지만, crit가 보기엔 UI-DSL brick과 provenance는 Prompt와 결과 사이의 판단을 주소화하고 수정하는 Inspectable Design AST에 가까운 비유를 제공한다. 도메인 모델도 모델 자체보다 그 모델에 들어간 가정·관계·결정 이력을 함께 검사하는 환경이 될 때 같은 역할을 할 수 있다.