v0.dev에 프롬프트 한 줄 넣으면 그럴싸한 대시보드가 뚝딱 나온다. Claude Code에 Figma 스크린샷 몇 장 던지면 컴포넌트 코드가 생성된다. 속도만 보면 혁명이다. 그런데 막상 프로덕션에 붙이려는 순간, 뭔가 이상하다는 걸 느낀다. 색상 토큰이 제각각이고, 버튼 크기가 페이지마다 미묘하게 다르고, Lighthouse 점수는 바닥을 친다. AI가 UI를 '만들어줬는데' 품질은 왜 내가 다 잡아야 하는 걸까.
이 질문의 답은 생각보다 단순하다. AI는 '발산'에 탁월하지만 '수렴'엔 취약하다. GeekNews에서 소개된 아티클이 정확히 이 지점을 짚는다. AI 기반 디자인 도구가 아이디어를 폭발적으로 펼쳐주는 건 맞지만, 그 결과물을 하나의 일관된 제품으로 모아주는 힘은 여전히 명확한 설계 규칙에서 나온다. 역설적이게도, AI가 강력해질수록 디자인 시스템은 더 정교해져야 한다.
문제는 기존 디자인 시스템이 '인간 디자이너의 인지'를 전제로 만들어졌다는 점이다. Pri, Btn처럼 줄임말을 써도 사람은 맥락으로 읽어낸다. 하지만 AI는 다르다. 시맨틱 네이밍(Primary, Button), JSON 기반 토큰 계층 구조(Primitive → Semantic → Component → Pattern), 그리고 역할과 규칙을 명시한 마크다운 프롬프트 프로토콜—이 세 가지가 AI가 디자인 시스템을 '이해'하는 언어가 된다. Figma Variables를 JSON으로 변환하고, 이를 Tailwind v4 CSS 변수로 연결하면 AI가 클래스명만으로 디자인 시스템 전체에 접근할 수 있는 구조가 만들어진다. 디자인 시스템이 AI의 '컨텍스트'가 되는 순간이다.
그런데 디자인 일관성만 잡았다고 품질이 보장되지는 않는다. AI가 생성한 UI는 시각적으로 그럴싸해도 성능 측면에서 구멍이 많다. velog에 올라온 프론트엔드 성능 최적화 글이 이 문제를 정면으로 다룬다. 핵심 메시지는 하나다. "측정이 먼저다." memo를 모든 컴포넌트에 붙여도 LCP는 안 좋아지고, Code Splitting으로 인터랙션이 빨라지지 않는다. 도구를 잘못된 레이어에 적용하면 코드 복잡도만 올라가고 지표는 그대로다.
실제 사용자가 체감하는 성능은 세 단계에서 결정된다. 네트워크 단계(번들 크기, 이미지 용량), 렌더링 단계(JS 파싱, Critical CSS), 런타임 단계(인터랙션 반응성). 각 단계가 만드는 문제는 다르고, 영향받는 Core Web Vitals 지표도 다르다. LCP가 나쁘다면 번들을 줄이거나 SSR을 검토해야 하고, INP가 나쁘다면 메인 스레드를 점유하는 JS 실행을 봐야 한다. AI가 생성한 컴포넌트는 번들 최적화나 렌더링 전략을 고려하지 않는 경우가 많기 때문에, 이 측정과 진단은 결국 개발자의 몫으로 남는다.
두 흐름을 엮으면 하나의 실용적인 원칙이 보인다. AI 생성 UI의 품질 게이트는 디자인 시스템과 성능 측정 두 축으로 구성되어야 한다. 디자인 시스템은 AI가 만드는 결과물의 '일관성'을 담보하고, Core Web Vitals 기반 측정은 그 결과물의 '체감 품질'을 수치로 잡아준다. 전자가 없으면 컴포넌트가 제각각이 되고, 후자가 없으면 빠른 것처럼 보이는데 실제로는 느린 UI가 배포된다.
도구 생태계는 빠르게 성숙하고 있다. Google Stitch의 design.md 자동 추출, Claude의 Figma 연동, Tailwind v4의 CSS 변수 체계—이 흐름이 계속되면 디자인 파일 몇 개만 있어도 AI가 일관된 시스템을 뽑아주는 시대가 곧 온다. 하지만 그 세상에서도 Core Web Vitals 기준을 CI에 심고, 어떤 레이어에서 병목이 생겼는지 진단하는 일은 AI가 대신해줄 수 없다. 생성 속도는 AI가 올려줬지만, 품질의 책임 구조는 여전히 개발자가 설계해야 한다. AI가 UI를 짜는 시대일수록, 무엇을 측정하고 무엇을 강제할지를 먼저 결정하는 사람이 제품의 실제 품질을 결정한다.