디자인 토큰 (Design Token) 도입률이 단 1년 만에 제품 팀의 56%에서 84%로 급증했습니다. 이것은 느린 추세가 아니라, 거대한 돌진입니다. 그리고 이는 Adobe, Google, Meta, Figma, Salesforce, Shopify의 지원을 받는 W3C의 첫 번째 안정적인 Design Tokens Format Module 버전이 출시되는 시점과 맞물렸습니다. 수년 동안 두 진영은 토큰이 실제로 어떻게 작동해야 하는지를 두고 싸워왔습니다. 그 싸움은 이제 훨씬 덜 흥미로워졌으며, 그 이유는 당신의 팀이 습관적으로 한쪽을 선택하기 전에 이해할 가치가 있습니다.

여기에 긴장 상태가 있습니다. 첫 번째 진영은 다음과 같이 말합니다: 네이티브(native) 방식을 유지하고, 단순함을 유지하며, Figma Variables가 진실의 원천 (Source of Truth)을 소유하게 하라. 두 번째 진영은 다음과 같이 말합니다: Figma Variables만으로는 실제 복잡성을 처리할 수 없으니, Tokens Studio와 적절한 빌드 파이프라인 (Build Pipeline)을 도입하라. 두 진영 모두 프로덕션 디자인 시스템을 출시했습니다. 또한 두 진영 모두 특정 조건에서 자신들의 방식이 무너지는 것을 목격했습니다. 각 방식이 실제로 무엇을 제대로 하고 있는지 살펴본 후, 결론을 내려보겠습니다.

캠프 1: Figma Variables, 네이티브 경로

2023년에 출시된 Figma Variables는 팀이 색상, 간격(spacing), 타이포그래피 값을 저장하는 방식으로서 Styles를 대부분 대체했습니다. 제안 내용은 명확합니다: 설치할 플러그인이 없고, 동기화해야 할 두 번째 도구가 없으며, 디자이너는 하나의 파일에서 작업하고 값은 컴포넌트 바로 옆에 존재합니다.

2026년의 업그레이드는 계산법을 바꿉니다. 이제 Figma는 플러그인이나 커스텀 내보내기 스크립트 없이도 Variables를 DTCG 준수 JSON으로 내보냅니다. 이것이 중요한 이유는 DTCG (Design Tokens Community Group 형식)가 모든 토큰에 $value와 $type을 부여하며, 이는 Style Dictionary, Theo, Specify, Supernova, Penpot가 이미 모두 읽을 수 있는 형태이기 때문입니다. 네이티브 Figma 토큰은 더 이상 폐쇄된 정원 (Walled Garden)이 아닙니다. 그것들은 나머지 툴체인 (Toolchain)이 이해할 수 있는 형식으로 외부로 나옵니다.

네이티브 방식이 여전히 어려움을 겪는 부분: 대규모 환경에서의 멀티 모드 테이밍 (Multi-mode theming). Variables는 라이트 모드와 다크 모드를 잘 처리합니다. 하지만 8개의 브랜드, 3개의 밀도 (densities), 그리고 플랫폼별 오버라이드 (overrides)를 동시에 다루기 시작하면, 평면적인 모드 시스템은 당신과 싸우기 시작합니다.

캠프 2: Tokens Studio, 파워 경로

Tokens Studio는 토큰을 직접적인 git 동기화가 가능한 다중 파일 시스템 (multi-file system)으로 취급하며, 이는 상황이 복잡해질 때 캠프 1 (Camp One)의 네이티브 방식이 정확히 결여하고 있는 부분입니다. 실제 테마 설정 (theming) 요구사항, 다중 브랜드, 다중 플랫폼을 가진 디자인 시스템에는 추가적인 구조가 필요합니다. 즉, 결합되는 토큰 세트 (token sets), 파일 간의 에일리어싱 (aliasing), 그리고 수동 내보내기 (manual export) 단계 대신 리포지토리 (repo)로 직접 연결되는 파이프라인이 필요합니다.

문제는 Tokens Studio의 형식이 DTCG (Design Tokens Community Group)보다 앞선다는 점입니다. 따라서 Style Dictionary로 연결하려면 먼저 @tokens-studio/sd-transforms를 실행해야 합니다. 이는 하나의 의존성 (dependency)이 더 늘어나는 것이며, 버전 동기화에서 벗어날 수 있는 요소가 하나 더 추가됨을 의미합니다. 근본적인 토큰 형태 (token shapes)가 어차피 수렴하고 있기 때문에 과거보다는 비용이 적게 들지만, 분명히 실질적인 비용입니다.

여기서 진지하게 살펴볼 만한 실제 사례 연구 (case study)가 있습니다. 한 팀은 단 하나의 컴포넌트도 복제하지 않고 브랜드 수준의 테마 설정을 위해 Figma variables를 사용하여, 공유 플랫폼으로 이전하는 8개의 서로 다른 브랜드를 지원하기 위한 통합 디자인 시스템을 1.5개월 만에 구축했습니다. 이것이 바로 캠프 2 (Camp Two)의 추가적인 툴링 (tooling) 투자가 즉각적으로 가치를 발휘하고, 캠프 1 (Camp One)의 단순함이 한계에 부딪히기 시작하는 복잡성의 영역입니다.

Two paths for managing design tokens: native Figma Variables versus Tokens Studio, compared side by side on ownership, theming depth, and export format

2026년에 실제로 변한 것

진정한 이야기는 Figma 대 Tokens Studio의 대결이 아닙니다. 핵심은 _형식 (format)_에 대한 싸움이 끝났다는 것입니다. 2025년 10월 DTCG 규격이 안정화되기 전에는 모든 도구가 각자의 JSON 형태를 가지고 있었고, 토큰 도구를 선택한다는 것은 특정 도구에 종속 (lock-in)되는 것을 의미했습니다. 이제는 어디에서나 $value와 $type이라는 하나의 형태가 존재하며, 두 진영 모두 이 형식으로 내보내기를 수행합니다.

그 단 한 번의 변화 덕분에, 과거에는 몇 주가 걸리던 리브랜딩(rebrand) 작업을 이제는 핵심 UI에 이틀 만에 적용하고 3일 만에 전체 배포를 완료할 수 있게 되었습니다. 색상(color), 간격(spacing), 타이포그래피(typography) 결정 사항이 50개의 컴포넌트 파일에 흩어진 헥스 코드(hex codes)가 아닌 데이터로서 존재할 때, 브랜드 리프레시(brand refresh)는 디자인 QA 마라톤이 아니라 토큰 파일에서의 '찾기 및 바꾸기' 작업이 됩니다.

Salesforce는 2014년 Lightning Design System을 통해 아무도 읽지 않는 문서에 의존하지 않고 시각적 일관성을 해결하기 위해

How AI coding agents use a DESIGN.md file plus DTCG token exports to generate UI that matches brand instead of guessing at a plausible approximation

두 진영의 기저에는 이 모든 것을 작동하게 만드는 실제 아키텍처인 3계층 계층 구조(three-tier hierarchy)가 있습니다: 코어 토큰 (core tokens, blue.500과 같은 원시 값), 코어 값을 가리키는 시맨틱 토큰 (semantic tokens, color.brand.primary), 그리고 시맨틱 토큰을 가리키는 컴포넌트 토큰 (component tokens, button.background)입니다. 시맨틱 계층에서 브랜드 색상을 한 번만 변경하면, 단 하나의 컴포넌트 파일도 건드리지 않고 참조된 모든 곳에 변경 사항이 폭포수처럼 전달(cascade)됩니다.

Design token hierarchy: core tokens with raw values, semantic tokens that reference them, and component tokens that reference semantic tokens

결론 (The verdict)

단일 브랜드이고, 소수의 플랫폼을 운영하며, 관리해야 할 도구를 하나라도 줄이고 싶은 팀이라면 Figma Variables와 Style Dictionary로의 DTCG 내보내기(export) 조합을 선택하세요. 솔직히 이 설정만으로도 대부분의 팀을 커버할 수 있으며, 추가적인 플러그인 비용 없이도 기능이 극적으로 향상되었습니다.

여러 브랜드를 관리하거나, 복잡한 테마 지정(theming)이 필요하거나, 이미 전환 시 혼란만 가중될 정도로 성숙한 git 동기화 파이프라인을 갖추고 있다면 Tokens Studio를 선택하세요. 추가적인 변환(transform) 단계는, 아직 이를 위해 구축되지 않은 도구에서 전체 테마 시스템을 다시 구축해야 하는 대안에 비하면 작은 비용(tax)에 불과합니다.

하지 말아야 할 행동은 이전 직장에서 사용했던 것을 기준으로 선택하는 것입니다. 이 선택을 영구적으로 만들었던 형식 전쟁(format war)은 끝났습니다. 이제 두 경로 모두 동일한 JSON을 사용합니다. 2년 전에 배운 도구에 대한 집단적 충성도가 아니라, 오늘날 여러분의 실제 테마 지정 복잡성에 따라 선택하십시오.

👨‍💻 저와 소통하세요

Rohit Raghuvansh
💡 UX Thinker · AI Builder · 복잡한 기술을 인간 중심적으로 만드는 중

연결 및 팔로우

LinkedIn — Rohit Raghuvansh

📢 이 기사가 도움이 되었나요?

이 기사가 여러분의 학습 여정에 가치를 더했다면:

✅ 네트워크에 공유하기 ✅ 나중에 참고할 수 있도록 북마크하기 ✅ 더 많은 정보를 위해 팔로우하기

계속 학습하세요. 계속 만드세요. 계속 성장하세요. 🚀