CSS 파일, Tailwind 설정, Figma 문서—이 세 곳의 파란색이 다르다
프론트엔드 개발을 조금이라도 해봤다면 이 상황을 안다. 브랜드 컬러를 바꿨는데 스테이징 사이트, 랜딩 페이지, Figma 시안이 미묘하게 다른 파란색을 쓰고 있는 것. #2563EB인지 #2564EB인지 px 단위로 color picker를 들이대야 겨우 잡히는 그 차이. 사소해 보이지만, 이게 실제로 프로덕션에 올라가면 "이거 왜 이렇게 했을까?" 의심이 드는 순간이 온다.
dev.to에 소개된 brandspec은 이 문제를 "코드의 single source of truth 원칙을 브랜드 아이덴티티에 적용하면 된다"는 단순한 전제로 푼다. brand.yaml 하나에 색상 토큰, 타이포그래피, 에셋, 보이스 가이드라인까지 정의해두면, CLI 한 줄로 CSS Custom Properties, Tailwind v4 테마, Figma Tokens Studio 포맷, Style Dictionary 출력물을 동시에 뽑아낼 수 있다. 토큰 포맷은 W3C DTCG 스펙을 따르고, 색상은 oklch를 기본으로 쓴다. perceptual uniformity와 wide gamut 지원 때문인데—솔직히 헥스 쓰던 버릇이 있어서 처음엔 낯설지만, oklch로 짜고 나면 왜 이게 맞는지 바로 이해된다.
특히 인상적인 건 brandspec lint가 빌드 전 단계에서 WCAG 명도 대비를 검증한다는 점이다. background/foreground 대비가 4.5:1 미만이면 에러로 처리한다. 접근성(a11y) 체크를 코드가 아니라 토큰 정의 레벨에서 막는다는 발상—이게 CI 파이프라인에 brandspec lint --json을 붙여두면, 디자이너가 실수로 낮은 대비 색상을 넣었을 때 PR 머지 전에 잡힌다. Figma에서 볼 때는 괜찮았는데 실제 구현하면 미묘하게 이상한 그 경험을 업스트림에서 차단하는 구조다.
MCP를 붙인 컴포넌트 라이브러리, AI가 props를 '아는' 시대
디자인 토큰이 정의됐다면 다음 단계는 컴포넌트다. Vacano UI는 64개 React 컴포넌트, 1800개 이상의 아이콘, 17개의 react-hook-form 래퍼를 묶은 라이브러리인데—차별점은 MCP(Model Context Protocol) 서버를 함께 제공한다는 것이다. Claude Code, Cursor, Windsurf 같은 AI 코딩 어시스턴트가 MCP를 통해 전체 문서에 접근할 수 있어서, AI가 존재하지 않는 props를 hallucinate하는 대신 실제 타입 정의를 쿼리해서 정확한 코드를 생성한다.
구조적으로도 꽤 생각해서 만들었다. Global ThemeProvider 같은 boilerplate 없이 컴포넌트를 바로 import해서 쓸 수 있고, 스타일 커스터마이징은 classnames={{ trigger: 'my-trigger' }} 형태의 typed classname slots로 처리한다. !important도 없고 DOM inspector를 뒤질 필요도 없다—TypeScript가 어떤 slot이 있는지 알려준다. 개인적으로 FieldRow가 CSS Grid subgrid로 인접 필드 레이아웃 시프트를 막는 것, OtpCode가 모바일 키보드 quirk 때문에 maxLength={2} 핵을 쓴 것 같은 프로덕션 엣지케이스를 코드에 녹여둔 부분이 마음에 든다. 이런 건 직접 겪어보지 않으면 생각 못 한다.
그런데 AI와 함께 짜면 정말 빨라질까—METR 연구가 던지는 불편한 질문
여기서 멈춰야 한다. brandspec으로 토큰 자동화하고, Vacano UI MCP로 AI가 컴포넌트 코드 뚝딱 생성하면, 디자인 시스템 구축이 정말 빨라지는 걸까.
METR의 연구는 이 기대에 찬물을 끼얹는다. 경험 많은 오픈소스 개발자 16명이 AI 도구를 쓸 때 24% 빨라진다고 느꼈지만, 실제 측정값은 19% 느렸다. 더 불편한 건 실험 후에도 참여자들이 "AI가 도움이 됐다"고 믿었다는 점이다. 체감과 데이터의 방향이 반대다.
이 연구가 말하는 메커니즘은 명확하다. AI가 boilerplate와 syntax 같은 "쉬운 부분"을 처리해주면 빨라진 것처럼 느껴진다. 하지만 실제 인지 부하는 오히려 증가한다—내가 작성하지 않은 코드를 이해하고, 맞는지 검증하고, 내가 놓친 게 없는지 디버깅하는 것은 "내가 이해하면서 작성하는 것"보다 인지적으로 더 비싸다. Simon Willison이 AI로 80개 이상의 도구를 만들고도 "프로젝트가 어떻게 돌아가는지 더 이상 확실한 멘탈 모델이 없다"고 토로한 것은 그래서 의미심장하다.
디자인 시스템 맥락에서 이 문제는 더 날카롭게 드러난다. AI가 컴포넌트 코드를 생성하는 건 쉽다. 그런데 그 컴포넌트가 브랜드 토큰을 제대로 참조하는지, 접근성 요구사항을 충족하는지, 기존 시스템과 일관성이 있는지—이걸 검증하는 건 결국 사람이 해야 한다. 홈페이지 카테고리 구조에 대한 AllInOneTools의 고민이 보여주듯, "더 많은 것이 더 좋다"는 직관이 실제 사용자 행동과 충돌하는 패턴은 AI 생성 코드에도 그대로 적용된다. 12개 카테고리가 사용자를 압도하듯, AI가 쏟아내는 컴포넌트 변형이 시스템을 압도할 수 있다.
시사점: 시스템을 '더 잘 정의한 사람'이 AI를 이긴다
brandspec의 _workshop/ 디렉터리 구조가 흥미롭다. position.yml, decisions.yml, memo.md, session.md—브랜드 정의의 "AI workshop state management"라고 설명하는 이 파일들은 사실 AI에게 컨텍스트를 제공하기 위한 구조다. Vacano UI가 MCP 문서를 "인간과 AI 에이전트 두 독자를 위해 작성했다"고 명시하는 것도 같은 맥락이다.
결국 공통된 방향이 보인다. AI가 잘 작동하려면, 시스템이 먼저 명확하게 정의되어 있어야 한다. YAML로 토큰을 정확히 기술하고, TypeScript로 props를 엄밀하게 타이핑하고, 문서에 제약사항과 엣지케이스를 명시하는 것—이게 AI를 위한 작업이기도 하지만, 동시에 좋은 디자인 시스템이 원래 해야 하는 일이기도 하다. METR 연구가 권하는 "AI 쓰기 전에 내가 원하는 것, 이유, 완료 기준을 먼저 텍스트로 써라"는 조언과 정확히 겹친다.
전망: 디자인 시스템이 AI의 인터페이스가 되는 세계
앞으로의 방향은 어느 정도 그림이 그려진다. brandspec 같은 도구가 성숙하면 brand.yaml 변경이 CI에서 자동으로 토큰을 재생성하고, lint가 접근성을 검증하고, Figma에 sync되는 파이프라인이 표준이 될 것이다. Vacano UI처럼 MCP를 붙인 컴포넌트 라이브러리는 더 많아질 것이고, AI 어시스턴트는 점점 더 정확하게 컴포넌트를 조합하게 될 것이다.
그러나 METR 데이터를 잊으면 안 된다. 속도가 아니라 주의(attention)를 어디에 쓰는가가 핵심이다. 토큰 정의, 컴포넌트 설계 원칙, 정보 아키텍처 결정—이런 "시스템을 정의하는 작업"에 더 많은 주의를 쏟을수록, AI가 생성하는 산출물의 질도 올라간다. 반대로 "AI가 알아서 하겠지"라는 태도로 임하면, 12개 카테고리가 사용자를 압도하는 것처럼 컴포넌트와 토큰이 통제 불능으로 늘어난다.
AI 시대 디자인 시스템의 민낯은 이것이다: 툴은 좋아지고 있고, 자동화는 실제로 작동하지만, "무엇을 자동화할 것인가"를 결정하는 일은 여전히 사람의 몫이다. 그리고 그 결정을 잘 내리는 사람이 1px 단위로 시안을 검토하는 사람과 같다—디테일이 시스템을 만들고, 시스템이 AI를 제어한다.