진짜 문제는 핸드오프가 아니었다
디자이너와 개발자 사이의 협업 문제를 이야기할 때, 우리는 오랫동안 '핸드오프'를 병목으로 지목했다. Figma 링크 공유, 스펙 문서 작성, Zeplin 주석 달기—이 모든 프로세스가 개선됐지만 근본 문제는 사라지지 않았다. 디자이너가 색상을 바꾸면 누군가 JSON을 손으로 수정해야 했고, 오타 하나가 프로덕션에 잘못된 색상을 심었으며, 다크 테마를 빠뜨리는 건 흔한 실수였다. 핸드오프 툴이 아무리 좋아져도 '소스 오브 트루스'가 코드와 디자인 툴 양쪽에 분산돼 있는 한, 드리프트는 피할 수 없었다.
MCP가 만든 새로운 루프: 편집 → 검증 → 배포
dev.to에서 공개된 flintwork-token-sync 프로젝트는 이 문제를 정면으로 건드린다. 핵심 아이디어는 단순하다. Notion 테이블을 디자인 토큰의 유일한 편집 인터페이스로 만들고, Claude가 MCP(Model Context Protocol)를 통해 두 서버—Notion MCP와 커스텀 빌드 MCP—를 동시에 오케스트레이션한다. 디자이너가 셀 하나를 수정하고 'sync'를 요청하면, AI 에이전트가 253개 토큰 전체를 검증하고, JSON을 생성하고, CSS 커스텀 프로퍼티를 빌드한 뒤, 성공 또는 에러 메시지를 같은 Notion 행에 기록한다.
여기서 주목할 점은 단순 자동화가 아니라는 것이다. validate_tokens는 헥스 포맷, 순환 참조, 존재하지 않는 토큰 레퍼런스를 실제로 잡아낸다. diff_tokens는 커밋 전에 무엇이 바뀌는지 미리 보여준다. 이 검증 레이어가 없다면 자동화는 오히려 더 빠르게 잘못된 값을 배포하는 파이프라인이 된다. 'AI가 대신 해준다'는 것이 아니라 'AI가 의도를 코드 수준에서 검증한다'는 구조가 핵심이다.
토큰 우선 아키텍처가 왜 지금 다시 주목받는가
비슷한 시기에 등장한 Tokis는 다른 각도에서 같은 문제를 공략한다. 이 라이브러리가 흥미로운 이유는 '컴포넌트를 먼저 만들지 않는다'는 설계 원칙 때문이다. 토큰 → 프리미티브 → 컴포넌트 순서로 레이어를 쌓는 구조는, 프로젝트가 커질수록 스페이싱이 제각각 흩어지고 색상이 중복 선언되는 문제—개발자라면 누구나 경험하는 그 '스타일 드리프트'—를 아키텍처 수준에서 차단하려는 시도다.
제로 런타임 스타일링과 헤드리스 프리미티브를 조합한 것도 실용적인 판단이다. 런타임 CSS-in-JS의 유연함은 크지만, 번들 사이즈와 성능 오버헤드라는 대가가 따른다. Tokis는 스타일 결정을 빌드 타임으로 밀어내고 비주얼 레이어를 팀이 직접 제어하도록 둔다. 아직 실험적 단계이지만, 디자인 시스템을 처음부터 다시 설계하는 팀이라면 이 아키텍처 패턴은 충분히 참고할 만한 방향성을 제시한다.
AI 코딩 시장의 팽창이 디자인 시스템에 던지는 질문
이 두 프로젝트가 등장한 맥락을 이해하려면 더 큰 그림을 봐야 한다. ZDNet 보도에 따르면 Cursor의 ARR은 불과 몇 달 만에 10억 달러에서 20억 달러로 두 배가 됐고, Lovable은 직원 146명으로 연간 4억 달러 매출을 달성했다. 코드 생성 속도가 이 정도로 빨라지면, 기존 디자인 시스템의 병목—토큰 동기화, 스타일 일관성 유지, 컴포넌트 문서화—이 새로운 속도에 따라가지 못하는 순간이 온다.
AI가 코드를 빠르게 생성할수록 '토큰 드리프트'는 더 빠르게 쌓인다. 에이전트가 하드코딩된 색상 값으로 컴포넌트를 뚝딱 만들어낼 때, 그것을 잡아낼 시스템적 장치가 없다면 기술 부채는 AI의 속도에 비례해 증가한다. flintwork-token-sync가 보여준 검증 파이프라인과 Tokis가 제안한 토큰 우선 아키텍처는, 사실 이 속도 증가에 대한 대응 전략으로도 읽힌다.
시사점: '소스 오브 트루스'를 한 곳으로
세 가지 신호가 가리키는 방향은 일치한다. 디자인 토큰이 CSS 변수 몇 개를 관리하는 유틸리티가 아니라, 디자인-개발 협업의 계약 레이어가 되어야 한다는 것이다. 그리고 MCP 같은 프로토콜이 그 계약을 AI 에이전트가 읽고 검증하고 실행할 수 있는 인터페이스로 만들어준다.
실무에서 당장 적용 가능한 관점으로 좁히면: 디자인 시스템을 구축 중인 팀이라면 토큰 계층 구조(글로벌 → 시맨틱 → 컴포넌트)를 명확히 분리하는 것이 AI 워크플로우 통합의 전제 조건이다. 이 계층이 불분명하면 어떤 자동화 파이프라인을 붙여도 검증할 수 없고, 검증할 수 없는 자동화는 신뢰할 수 없다.
전망: 에이전트가 디자인 시스템을 감사하는 날
가까운 미래에 더 자연스러운 시나리오는 이것이다. 에이전트가 PR을 열 때마다 디자인 토큰 참조 여부를 자동으로 감사하고, 하드코딩된 색상 값이나 존재하지 않는 토큰 레퍼런스를 CI 단계에서 블로킹한다. 디자이너는 Figma나 Notion에서 의도를 수정하고, 그 의도가 코드베이스까지 검증된 채로 흐르는 파이프라인이 기본값이 된다.
flintwork-token-sync는 개인 프로젝트이고 Tokis는 아직 실험 단계다. 하지만 이 두 프로젝트가 던지는 질문—'왜 아직도 디자이너와 개발자가 같은 토큰 값을 두 곳에서 따로 관리하는가'—은 팀 규모와 무관하게 유효하다. AI가 워크플로우를 재편하는 속도를 감안하면, 이 질문에 답하지 않은 디자인 시스템은 머지않아 가장 느린 병목이 될 것이다.