디자인 토큰 파이프라인, 자동화 안 하면 어떻게 되는가
디자이너가 Figma에서 primary 컬러를 #2563EB에서 #1D4ED8로 바꿨다. 슬랙에 공유하고, 개발자가 확인하고, CSS 변수를 수정하고, iOS 팀은 다음 스프린트에 반영하겠다고 한다. 2주 뒤 안드로이드 앱에만 예전 색이 남아 있다. 이 시나리오를 직접 겪어본 적 있다면, 토큰 자동화 파이프라인이 왜 필요한지 따로 설명할 필요가 없을 것이다
UI/UX 트렌드, Figma 워크플로우, 디자인 토큰 — 한국 서비스 UX를 분석한다.
디자이너가 Figma에서 primary 컬러를 #2563EB에서 #1D4ED8로 바꿨다. 슬랙에 공유하고, 개발자가 확인하고, CSS 변수를 수정하고, iOS 팀은 다음 스프린트에 반영하겠다고 한다. 2주 뒤 안드로이드 앱에만 예전 색이 남아 있다. 이 시나리오를 직접 겪어본 적 있다면, 토큰 자동화 파이프라인이 왜 필요한지 따로 설명할 필요가 없을 것이다
컬러 대비 검사를 통과했는데 사용자가 텍스트를 못 읽겠다고 한다. WCAG 2.x의 4.5:1 비율을 충실히 지켰는데도. 디자인 시스템을 운영해본 사람이라면 이 상황이 낯설지 않을 것이다. 문제는 우리가 아니라 공식 자체에 있다. #4.5:1이 무시하는 변수들 WCAG 2.x의 대비 공식은 전경색과 배경색의 상대 휘도를 비교해서 단일 비율을 뽑는다. 거기서
Figma가 캔버스의 쓰기 권한을 AI 에이전트에게 열었다. 읽기만 되던 MCP 서버에 write 기능이 붙으면서, Claude Code나 Cursor 같은 도구가 컴포넌트를 만들고, 변수를 적용하고, 실제 디자인 에셋을 직접 조작할 수 있게 됐다. 이 변화의 핵심은 기술 자체가 아니라, 디자인 시스템의 위상이 근본적으로 달라진다는 점이다. #무슨 일이 벌
컴포넌트 Detach. 디자인 시스템 운영자라면 이 단어만으로 속이 쓰리다. 디자이너가 인스턴스를 Detach하는 순간, 그 컴포넌트는 시스템에서 이탈한다. 색상 토큰이 바뀌어도 반영 안 되고, 스펙 문서와 Figma 파일 사이에 유령 같은 차이가 쌓인다. 그래서 디자인 시스템 팀은 "가능한 모든 변형을 Variant로 만들어야 한다"는