속도의 역설: 빠를수록 기반이 흔들린다
AI 코딩 에이전트 덕분에 솔로 개발자 한 명이 풀스택 플랫폼을 단기간에 출시하는 일이 현실이 됐다. dev.to에 공개된 Et3am 프로젝트가 그 증거다. 이집트 알렉산드리아의 한 개발자는 식량 부족으로 가족을 잃은 비극적인 뉴스를 접한 뒤, AI 코딩 에이전트를 활용해 React + Express + Socket.io 기반의 실시간 푸드 셰어링 플랫폼을 혼자 완성했다. 아키텍처 판단과 제품 방향은 사람이 잡고, 구현 코드는 에이전트가 채우는 방식이었다. '기술 장벽은 더 이상 문제가 아니다'라는 그의 회고는 과장이 아니다.
그런데 바로 여기서 새로운 질문이 생긴다. 빌드 속도가 10배 빨라지면, 그 속도를 받쳐줄 기반도 10배 단단해야 하지 않을까? UI를 빠르게 뽑아낼수록 컴포넌트 간 색상·간격·타이포그래피가 제각각 하드코딩될 위험도 커진다. AI는 지시한 대로 코드를 만들지만, 시스템 일관성은 지시하지 않으면 만들어주지 않는다.
디자인 토큰 표준화, 10년 만에 온 '합의의 순간'
디자인 토큰이라는 개념은 2014년 Salesforce에서 처음 등장했다. 이후 Amazon이 Style Dictionary를 오픈소스로 공개하면서 업계 전반으로 퍼졌다. 그런데 10년이 넘도록 해결되지 않은 문제가 하나 있었다. 포맷 표준이 없었다. 팀마다, 도구마다 토큰을 저장하는 방식이 달랐고, 어떤 도구에서든 읽을 수 있는 중립적인 형식이 존재하지 않았다.
dev.to의 한 분석 기사는 이 공백을 메우려는 W3C 산하 커뮤니티 그룹 DTCG(Design Tokens Community Group)의 동향을 상세히 다룬다. 2025년 말 첫 번째 안정 스펙이 공개됐고, 지지 명단이 예사롭지 않다. Adobe, Google, Microsoft, Meta, Amazon, Shopify, Salesforce, Figma, Disney, Framer, Penpot—사실상 디자인 툴링 업계 전체가 서명한 셈이다. 사이드 프로젝트가 아니라, 업계가 조용히 합의한 방향이다.
Figma의 아이러니, 그리고 구조적 교훈
Figma도 DTCG 지지 목록에 이름을 올렸다. 그런데 아이러니가 있다. 지금 Figma 변수를 열면 FLOAT 10이라는 값만 보인다. 그게 10px인지, z-index 10인지, 10ms인지 파일 자체는 알려주지 않는다. LLM을 갖다 붙여도 마찬가지로 추측에 의존해야 한다. 세계에서 가장 많이 쓰이는 디자인 도구가 자기 토큰 포맷조차 완전히 정의하지 못한 상태다.
이 사실이 실무에 주는 교훈은 명확하다. 특정 도구의 포맷에 토큰 파이프라인을 묶어두는 것은 구조적 위험이다. Figma는 DTCG 네이티브 익스포트를 단계적으로 롤아웃하고 있지만, 복합 토큰(타이포그래피, 그림자, 그라디언트) 지원은 아직 미완이다. 도구가 완성되기를 기다리며 파이프라인을 멈출 수는 없다. 지금 당장 Figma-to-DTCG 어댑터를 얇게 만들어두고, 그 아래 모든 다운스트림—CSS 커스텀 프로퍼티, iOS/Android 토큰—은 표준을 바라보게 설계하는 것이 현실적인 전략이다. 어댑터는 교체 가능한 부품으로 만들어두면, 나중에 Figma 네이티브 지원이 완성됐을 때 어댑터만 떼어내면 된다. 나머지는 아무것도 바뀌지 않는다.
DTCG는 아직 완성형이 아니다, 그래도 지금 앵커링해야 하는 이유
물론 DTCG가 완벽하지 않다는 반론도 타당하다. Google의 DESIGN.md처럼 DTCG를 기반으로 삼되 자체 스키마로 분기하는 사례가 이미 생겼다. 표준이 아직 젊고, 엣지 케이스에서 분열이 일어나고 있다. 그러나 분열이 일어나는 지점을 들여다보면 패턴이 보인다. 색상·간격·라디우스 같은 프리미티브 토큰에서는 이미 수렴하고 있고, 복합 토큰(타이포그래피, 그림자)에서만 각론이 갈린다. Style Dictionary, Tokens Studio, Terrazzo가 동일한 베이스 위에서 수렴 중이고, 공동 포맷 제안도 진행 중이다. 지금 색상과 간격에서 표준을 신뢰하는 것은 안전하다. 복합 토큰은 약간 앞서 베팅하는 셈이지만, 방향 자체는 닫혀가고 있다.
AI 에이전트 + 디자인 토큰: 시너지의 조건
Et3am 사례로 돌아가보자. 개발자가 AI 에이전트에게 RTL 레이아웃과 프라이버시 설계를 구현하도록 지시했을 때, 일관된 디자인 언어가 있었다면 어땠을까. 색상과 간격이 토큰으로 정의되어 있었다면, 에이전트는 임의의 값을 하드코딩하는 대신 토큰 참조를 삽입했을 것이다. AI가 생성하는 코드의 양이 많아질수록, 그 코드가 참조해야 할 단일 진실 공급원(single source of truth) 의 존재가 더 중요해진다.
이것이 '빠른 프로토타이핑 → 검증 → 고도화' 흐름에서 디자인 토큰이 갖는 진짜 역할이다. 프로토타이핑 단계에서는 토큰이 없어도 동작하는 화면을 만들 수 있다. 하지만 검증 이후 고도화 단계로 넘어갈 때, 하드코딩된 값들을 전수 수정하는 리팩토링 비용은 초반에 토큰을 세팅하는 비용보다 항상 크다. AI가 속도를 높여줄수록, 이 빚은 더 빠르게 쌓인다.
실무 시사점: 지금 당장 할 수 있는 것
구체적인 행동으로 옮기면 세 가지가 된다. 첫째, 프리미티브 토큰(색상, 간격, 라디우스)부터 DTCG 형식으로 정의하라. 복합 토큰은 툴링이 따라오는 속도에 맞춰 점진적으로 추가하면 된다. 둘째, Figma 변수를 진실의 원본으로 삼지 말고, DTCG 파일을 원본으로 삼아라. Figma는 토큰의 소비자 중 하나일 뿐이고, CSS 변수와 모바일 토큰도 같은 원본에서 생성되어야 한다. 셋째, AI 에이전트에게 컴포넌트 코드를 생성시킬 때 토큰 참조 규칙을 컨텍스트로 제공하라. .cursor/rules나 시스템 프롬프트에 '색상은 반드시 --color-* 토큰을 참조할 것'이라는 제약을 명시하면, 에이전트가 하드코딩 대신 토큰을 사용하는 코드를 훨씬 일관되게 만들어낸다.
전망: 표준이 정착되면 AI 워크플로우가 바뀐다
DTCG가 완전히 안착하면, 디자인-개발 협업의 구조 자체가 달라진다. Figma 네이티브 DTCG 익스포트가 완성되는 시점엔 디자이너가 변수를 정의하면 그 값이 표준 형식으로 코드베이스에 바로 흘러들어올 수 있다. AI 에이전트는 그 토큰을 입력으로 받아 컴포넌트를 생성하고, Style Dictionary가 플랫폼별 아웃풋으로 변환한다. 사람이 개입해야 하는 지점은 '이 값이 무엇을 의미하는가'에 대한 판단—즉, FLOAT 10이 px인지 ms인지 결정하는 의미론적 판단—으로 집중된다.
속도가 경쟁력인 시대에, 시스템 기반을 나중으로 미루는 것은 합리적인 선택처럼 보인다. 하지만 Et3am이 보여주듯 AI 에이전트로 빌드 속도를 올리는 것이 가능해진 지금, 기반을 세우는 비용도 이전보다 낮아졌다. 빠르게 빌드하는 것과 올바른 기반 위에 빌드하는 것, 이제 둘을 동시에 선택할 수 있다. 그렇다면 선택하지 않을 이유가 없다.