AI가 헤매지 않게 디자인 시스템을 다시 짜라

LLM으로 UI를 짜다 보면 세션마다 결과의 시각 품질이 들쭉날쭉해집니다. Hardik Pandya는 그 원인을 세 가지로 짚었습니다 — LLM은 존재하지 않는 토큰 값을 그럴듯하게 지어내고(fabricate), 세션 사이에 맥락을 전혀 기억하지 못하며, 소스코드에서 디자인 의도를 읽어내지 못합니다. 해법은 프롬프트를 다듬는 것이 아니라, 디자인 시스템 자체를 LLM이 신뢰성 있게 읽을 수 있는 형식으로 다시 구조화하는 것입니다.

"당신의 10번째 세션이 첫 번째 세션과 똑같은 시각 품질을 낸다."Hardik Pandya

왜 중요한가

문제의 뿌리는 AI의 창의성이 아니라 ‘참조할 근거의 부재’입니다 — LLM은 var(--color-link) 같은 정해진 참조를 쓰는 대신 그럴듯한 hex 값을 만들어내고, 그 미세한 오차가 세션을 거듭할수록 눈덩이처럼 쌓입니다. Pandya의 구현은 이 표류(drift)를 숫자로 틀어막았습니다. 파운데이션·컴포넌트·패턴 3계층에 걸친 64개 스펙 파일, 3단 인다이렉션으로 매핑한 230여 개의 CSS 변수, 그리고 코드에서 걷어낸 418개의 하드코딩 값이 그것입니다.

실무 적용

핵심은 네 겹의 구조입니다 — 매 세션 LLM이 읽어들이는 마크다운 스펙 파일, 값 날조를 원천 차단하는 닫힌(closed) CSS 토큰 레이어, CI에서 하드코딩을 잡아내 위반 시 종료 코드 1을 반환하는 감사(audit) 스크립트, 그리고 업스트림 라이브러리의 변경을 감지하는 드리프트 탐지입니다. 요지는 분명합니다. LLM이 무슨 값을 쓸지 ‘결정’하게 두지 말고, 미리 정의된 값을 ‘참조’만 하도록 선택지를 좁히는 것입니다.

교차 참고

• DesignSystems.one: AI-ready design systems — 병목이 ‘생성’에서 ‘통합’으로 옮겨갔다며, 기계가 읽는 토큰·MCP 서버·타입이 잡힌 컴포넌트를 세 기둥으로 제안합니다.
• Nathan Curtis: Component Contracts and Schemas — 컴포넌트를 계약과 스키마로 정의해 예측 가능하게 만드는 접근으로, 닫힌 토큰·스펙 파일과 같은 문제의식을 공유합니다.

Wemeet의 관점

Wemeet은 AI가 UI를 대신 짜는 시대의 경쟁력이 ‘더 좋은 프롬프트’가 아니라 ‘AI가 헤맬 여지가 없는 시스템’에서 나온다고 봅니다. 값을 지어낼 틈을 없애고 참조만 남기는 설계 — 사람과 AI가 같은 규칙을 읽는 팀이 열 번째 세션에서도 일관성을 지킵니다.