'같은 프롬프트를 줬는데 왜 결과물이 이렇게 다르지?' 이 질문은 AI 코딩 도구를 쓰는 프론트엔드 개발자라면 한 번쯤 마주하는 순간이다. 최근 dev.to에 올라온 두 편의 글이 이 질문에 정면으로 답한다. 하나는 Codex에 UI/UX 스킬을 주입했을 때 결과물이 어떻게 달라지는지를 실험한 비교 연구이고, 다른 하나는 접근성을 '나중에 붙이는 것'이 아니라 '처음부터의 제약 조건'으로 삼았을 때 컴포넌트 설계가 어떻게 달라지는지를 보여주는 케이스 스터디다. 두 글을 나란히 읽으면 하나의 핵심 질문이 떠오른다. AI가 생성한 UI는 진짜 설계 사고를 담을 수 있는가?
AI는 기본적으로 '데모 최적화'를 한다
Yuki Furuta의 실험은 단순하다. 동일한 프롬프트로 두 버전의 팩토리 대시보드 앱을 생성했다. 하나는 기본 Codex, 다른 하나는 ui-ux-pro-max-skill이라는 UI/UX 설계 프레임워크를 주입한 Codex다. 결과는 흥미롭다.
기본 Codex가 만든 virtual-factory-1은 즉시 보여줄 수 있는 강력한 데모다. 다크톤, 글라시 패널, 히어로 섹션—전형적인 SaaS 데모의 언어로 가득 차 있다. 업로드 플로우, 스캔 전환, 검색, 노트, 문서 연결이 하나의 화면에 촘촘히 엮여 있고, 3DGS 뷰어 같은 복잡한 부분은 캔버스 기반 목업으로 영리하게 처리했다. 실제로 src/App.jsx 하나에 상태, 핸들러, 뷰어, 인터랙션이 집약되어 있다. 모놀리식이지만, 그렇기 때문에 빠르다.
반면 ui-ux-pro-max-skill을 적용한 virtual-factory-2는 다른 방향을 가리킨다. Next.js App Router 구조, sidebar, viewer-stage, viewer-hud, rail-card 같은 CSS 어휘, 3컬럼 레이아웃—이 모든 것이 '어떻게 보여줄까'보다 '어떻게 쓰일까'를 먼저 생각한 흔적이다. 화려한 다크 SaaS 느낌 대신 공장 모니터링 툴에 어울리는 차분한 오퍼레이셔널 콘솔 미학을 택했다. 네비게이션, 뷰잉, 모니터링, 보조 정보의 위치가 컴포넌트를 쌓기 전에 먼저 결정된 느낌이다.
이 차이는 단순한 스타일 차이가 아니다. ui-ux-pro-max-skill의 SKILL.md가 명시하는 것처럼, 이 도구는 AI의 디폴트 질문을 바꾼다. "어떻게 보기 좋게 만들까?" 에서 "이 제품은 어떻게 사용되는가? 정보 계층은 어떻게 구성해야 하는가?" 로. 즉, 프롬프트에 무엇을 담느냐가 AI의 사고 방향 자체를 바꾼다.
접근성은 '나중에 붙이는 것'이 아니다
UI 설계 사고의 또 다른 차원은 접근성이다. 대부분의 컴포넌트 라이브러리는 접근성을 나중에 덧붙인다. ARIA 속성을 추가하고, 키보드 내비게이션을 연결하고, 색상 대비를 확인한다. axe-core 감사를 통과하면 '접근성 준수'라고 부른다. 하지만 dev.to의 또 다른 글이 지적하듯, 감사를 통과하는 것과 접근성을 위해 설계하는 것은 근본적으로 다른 프로세스다.
nuka-ui의 케이스가 그 차이를 구체적으로 보여준다. 이 라이브러리는 WCAG 2.2 AA를 첫 커밋부터 '목표'가 아닌 '제약 조건'으로 삼았다. 그 결과가 어떻게 나타나는지를 9가지 설계 결정을 통해 해부한다.
가장 인상적인 사례는 드롭다운 컴포넌트다. 일반적인 React 패턴은 {open && <SelectContent />}처럼 조건부 렌더링을 쓴다. 깔끔하고 관용적이다. 하지만 SelectTrigger의 aria-controls가 닫힌 상태에서 존재하지 않는 엘리먼트를 참조하게 되고, 선택된 옵션의 레이블 등록도 마운트 시점에 일어나지 않아 스크린 리더가 처음 렌더링 시 레이블 데이터를 갖지 못한다. 해법은 hidden={!open}—항상 DOM에 존재하지만 필요할 때만 접근성 트리에서 숨긴다. 접근성 요구사항 하나가 세 가지 구현 결과를 만들어낸다.
토스트 컴포넌트에서도 같은 철학이 드러난다. aria-live 속성을 intent에 따라 동적으로 설정한다. 성공·경고 토스트는 polite(사용자가 현재 작업을 마친 뒤 읽어줌), 위험 토스트는 assertive(즉시 인터럽트). 시각적 스타일링과 접근성 동작이 동일한 intent prop에서 파생되니 항상 동기화된다. 접근성이 처음부터 제약 조건이었기 때문에 가능한 설계다.
AI 생성 UI의 진짜 한계는 어디에 있나
두 관점을 종합하면 AI 생성 UI의 현주소가 더 선명하게 보인다. 현재 AI 코딩 도구는 '데모 완성도' 최적화에 탁월하다. 빠르게 동작하는 것을 만들고, 시각적으로 설득력 있는 화면을 구성하는 데 있어서는 이미 상당한 수준이다. 하지만 두 가지 설계 사고는 여전히 취약하다.
첫째는 정보 아키텍처다. AI는 기본적으로 '이 화면이 어떻게 보여야 하는가'를 먼저 생각한다. '이 제품이 어떻게 사용되어야 하는가', '어떤 정보가 어디 있어야 하는가'는 명시적으로 요청하지 않으면 생략된다. ui-ux-pro-max-skill 실험이 보여주듯, 이 사고를 프롬프트나 스킬 형태로 주입해야만 비로소 결과물에 반영된다.
둘째는 접근성이다. axe-core 감사를 통과하는 코드와 처음부터 접근성을 제약 조건으로 삼은 코드는 겉으로는 같아 보이지만 완전히 다른 아키텍처를 갖는다. AI는 ARIA 속성을 '추가하는 것'은 비교적 잘 하지만, hidden vs 조건부 렌더링의 트레이드오프, aria-live 긴급도의 의미론적 분리, aria-label 폴백 체인 같은 깊이 있는 판단은 적절한 컨텍스트 없이는 스스로 도달하기 어렵다.
결국 AI 코딩 도구가 설계 사고를 담으려면, 개발자가 그 사고를 먼저 구조화해 주어야 한다. 프롬프트에 정보 구조를 담고, 스킬이나 시스템 프롬프트로 설계 원칙을 주입하고, 접근성 요구사항을 생성 단계의 제약으로 명시하는 것이다.
앞으로: 설계 사고를 AI에게 '주입'하는 방법론이 경쟁력이 된다
두 실험이 동시에 가리키는 미래는 명확하다. AI가 UI를 생성하는 속도는 계속 빨라지겠지만, 그 결과물의 품질은 개발자가 AI에게 어떤 설계 사고를 얼마나 잘 전달하느냐에 의해 갈린다.
ui-ux-pro-max-skill 같은 도메인 특화 스킬, WCAG를 첫 커밋부터 제약으로 삼는 컴포넌트 라이브러리 설계, 그리고 AI 생성 결과물을 검증하는 접근성 테스트 파이프라인—이 세 가지가 맞물릴 때 비로소 AI가 만든 UI가 단순한 데모를 넘어 실제로 사용될 수 있는 제품이 된다.
지금 단계에서 현실적인 워크플로우는 이렇다. AI에게 빠른 프로토타입을 맡기되, 정보 아키텍처와 컴포넌트 역할 구분은 개발자가 명시적으로 지정한다. 접근성은 검증 단계가 아니라 프롬프트 설계 단계에서 제약 조건으로 포함시킨다. 그리고 AI가 생성한 결과물을 '완성된 것'이 아니라 '검증 대기 중인 첫 번째 초안'으로 취급하는 팀 문화를 만든다.
결국 질문은 'AI가 설계 사고를 담을 수 있는가'가 아니라, '개발자가 AI에게 설계 사고를 어떻게 전달할 것인가'로 바뀌고 있다. 그 방법론을 먼저 만든 팀이 AI 시대의 프론트엔드 품질 경쟁에서 앞서게 된다.