사실 저는 AI가 생성한 컴포넌트 코드를 처음 받아봤을 때, 감탄보다 불안이 먼저 왔습니다. padding: 12px이 하드코딩돼 있고, --spacing-md 토큰은 아예 무시됐고, <div> 열한 개가 중첩된 구조를 보면서 "이걸 Figma 시안이랑 나란히 놓으면 디자이너가 울겠다"는 생각부터 들었거든요. AI는 코드를 '빠르게' 만드는 데는 천재지만, '맞게' 만드는 건 완전히 다른 문제입니다.
dev.to에 올라온 "Why AI Needs UX Developers" 글이 정확히 이 지점을 찌릅니다. 저자는 MCP(Model Context Protocol) 서버와 Claude Code Skills를 직접 구축해서 AI 도구가 자신의 디자인 시스템과 상호작용하도록 만들고 있다고 말합니다. 핵심은 이렇습니다 — 컴포넌트 문서가 곧 AI의 컨텍스트 윈도우가 되고, 디자인 토큰 체계가 AI의 어휘가 되고, API 컨벤션이 AI가 넘지 못하는 가드레일이 된다는 것. 사용자 입장에서는 결국 semantic token을 무시한 버튼 하나가 전체 페이지의 시각적 일관성을 무너뜨리는데, AI는 그걸 스스로 판단하지 못합니다. 판단을 주입하는 사람, 즉 디자인과 엔지니어링 양쪽의 언어를 번역할 수 있는 UX 개발자가 이제 'nice to have'에서 'force multiplier'로 격상된 거죠.
그런데 "AI에게 디자인 시스템을 가르친다"는 말이 구체적으로 뭘 의미할까요? 실무에서 부딪히는 첫 번째 벽은 생각보다 사소합니다. SVG 아이콘 하나가 CSS로 색상이 안 바뀌는 것 같은 문제요. Next.js 환경에서 SVG를 <Image> 태그로 불러오면 정적 파일 취급을 받아서 fill, stroke 같은 속성을 CSS로 제어할 수 없습니다. dev.to의 한 가이드가 소개한 해법은 SVGR로 SVG를 React 컴포넌트로 변환하고, SVGO로 하드코딩된 fill="#0F0F0F" 같은 속성을 일괄 제거한 뒤 currentColor를 주입하는 워크플로우입니다. TurboPack 기반 Next.js v16+에서 next.config.ts에 SVGR 로더를 등록하면 끝이죠.
여기서 1px짜리 인사이트가 생깁니다. 이 SVGO 설정 파일 — removeAttrs로 fill|stroke|style을 날리고 addAttributesToSVGElement로 fill="currentColor"를 삽입하는 그 svgo.config.js — 이것 자체가 디자인 토큰 철학의 연장선입니다. 색상 결정권을 SVG 파일 내부가 아니라 CSS 레이어, 궁극적으로는 디자인 토큰 시스템에 위임하는 거니까요. AI에게 아이콘 컴포넌트를 만들라고 시킬 때, 이 SVGO 파이프라인과 currentColor 컨벤션이 문서화되어 있지 않으면? AI는 십중팔구 fill="#000000"을 하드코딩합니다. Figma에서 볼 때는 까만 아이콘이 괜찮아 보였는데, 다크 모드로 전환하는 순간 아이콘이 배경에 묻혀 사라지는 그 참사, 다들 한 번쯤 겪어보셨을 겁니다.
두 번째 벽은 설계 패턴 수준의 문제입니다. Velog에 올라온 전략 패턴(Strategy Pattern) 스터디 글이 좋은 레퍼런스인데요, TypeScript로 결제 모듈을 구현하면서 PaymentStrategy 인터페이스를 정의하고 CardPayment, KakaoPayment, NaverPayment를 끼워 넣는 구조를 보여줍니다. "무엇을 할지는 Context가 알고, 어떻게 할지는 Strategy가 결정한다" — 이 원칙은 디자인 시스템 컴포넌트 설계에 그대로 적용됩니다. <Button> 컴포넌트의 variant(primary, secondary, ghost)가 바로 Strategy이고, 이를 소비하는 페이지가 Context인 셈이죠. AI가 버튼을 만들 때 variant prop 대신 인라인 스타일로 배경색을 때려 넣는다면, 그건 전략 패턴을 모르는 게 아니라 우리 팀의 컴포넌트 API 규칙을 모르는 겁니다.
결국 이 세 가지 이야기 — UX 개발자의 재정의, SVG 스타일링 파이프라인, 전략 패턴의 컴포넌트 적용 — 는 하나의 질문으로 수렴합니다. AI에게 '우리 팀의 판단 기준'을 어떻게 인코딩할 것인가? 디자인 토큰 JSON 파일, 컴포넌트 Storybook 문서, SVGO 설정, Zod 스키마를 활용한 props 검증, 이 모든 것이 AI의 컨텍스트로 들어갈 때 비로소 "생성된 코드"가 "쓸 수 있는 코드"가 됩니다.
시사점은 명확합니다. 앞으로 프론트엔드 팀의 경쟁력은 '코드를 얼마나 빨리 치느냐'가 아니라 '디자인 시스템을 얼마나 정밀하게 문서화하고 자동화했느냐'에 달릴 겁니다. MCP 서버가 디자인 토큰을 읽고, Claude가 컴포넌트 API 규칙을 준수하며 코드를 생성하고, CI 파이프라인에서 Lighthouse 점수와 a11y 검사가 자동으로 돌아가는 — 그런 워크플로우를 세팅하는 사람이 결국 AI 시대의 프론트엔드를 설계하는 사람입니다. AI가 코드를 짜는 속도는 점점 빨라지겠지만, padding에 --spacing-md를 쓸지 12px을 쓸지 판단하는 건 여전히 디자인 시스템을 이해하는 사람의 몫입니다. 그 1px의 판단이 쌓여서 제품의 품질이 되니까요.