디자이너가 Figma에서 primary 컬러를 #2563EB에서 #1D4ED8로 바꿨다. 슬랙에 공유하고, 개발자가 확인하고, CSS 변수를 수정하고, iOS 팀은 다음 스프린트에 반영하겠다고 한다. 2주 뒤 안드로이드 앱에만 예전 색이 남아 있다. 이 시나리오를 직접 겪어본 적 있다면, 토큰 자동화 파이프라인이 왜 필요한지 따로 설명할 필요가 없을 것이다.

올리브영이 선택한 구조

올리브영 테크블로그에 공개된 사례가 이 문제에 대한 구체적인 해법을 보여준다.

  1. Figma에서 Tokens Studio 플러그인으로 토큰 정의 — primitive 토큰(순수 값)과 semantic 토큰(의미 기반 참조)을 분리한다. blue-600이 primitive, surface/primary가 semantic이다. 이 구분이 왜 중요하냐면, primitive는 팔레트고 semantic은 의도다. 버튼 배경색을 바꾸고 싶을 때 blue-600을 건드리는 게 아니라 surface/primary가 참조하는 값만 바꾸면 된다.

  2. Tokens Studio의 Push 기능으로 GitHub에 JSON 커밋 — 디자이너가 Figma에서 값을 바꾸면 수동 핸드오프 없이 GitHub 브랜치에 PR이 올라간다. 개발자는 코드 리뷰하듯 토큰 변경을 리뷰한다.

  3. CI에서 Style Dictionary가 JSON을 CSS 변수, Swift, Kotlin 등으로 변환 — 하나의 소스에서 멀티 플랫폼 산출물이 동시에 나온다.

  4. 모노레포 안에서 Panda CSS 기반 컴포넌트 라이브러리가 변환된 토큰을 소비 — 서비스 앱이 이 패키지를 가져다 쓴다.

핵심은 디자이너의 Figma 조작이 곧 코드 변경이 된다는 것이다. 슬랙 DM도, 스프레드시트도, "이거 반영됐나요?" 같은 확인 메시지도 사이에 끼지 않는다. PR 리뷰하고 머지하면 끝이다.

이 흐름이 현실적으로 가능해진 건 Tokens Studio가 Figma Variables와 양방향 싱크를 지원하면서부터다. 예전에는 플러그인 토큰과 네이티브 Variables가 따로 놀았는데, 이제는 같은 데이터를 바라본다. 디자이너가 Figma Variables 패널에서 수정해도, Tokens Studio 패널에서 수정해도 결과가 동일하다.

파이프라인의 표준 골격

올리브영만의 이야기가 아니다. 2026년 현재 토큰 자동화는 거의 표준적인 뼈대로 수렴하고 있다.

단계 도구 역할
정의 Figma + Tokens Studio 디자이너가 직접 편집하는 소스
버전 관리 GitHub (JSON) 변경 이력 추적, PR 기반 리뷰
변환 Style Dictionary 플랫폼별 출력 생성 (CSS, iOS, Android)
배포 npm 또는 내부 레지스트리 서비스에서 패키지로 import

Zeroheight를 문서화 레이어로 추가하는 팀도 있고, GitHub Actions에서 토큰 스키마 검증이나 contrast ratio 린트까지 자동화하는 팀도 있다. 세부 도구는 달라도 골격은 동일하다 — Figma → Git → Transform → Distribute.

Style Dictionary v4가 바꾼 것

변환 엔진인 Style Dictionary가 v4에서 구조적 전환을 맞았다. 가장 큰 변화: CTI(Category-Type-Item) 경로 의존 제거.

v3까지는 color.primary.base 같은 JSON 경로에서 토큰 타입을 추론했다. 경로 첫 세그먼트가 color면 색상으로 처리하는 식. v4는 이 방식을 버리고 토큰 객체의 $type 프로퍼티를 직접 읽는다. DTCG(Design Tokens Community Group) 스펙과 정렬하기 위한 결정이다.

DTCG 스펙 v2025.10 기준으로 strokeStyle 같은 새 타입이 추가됐고, dimension 값이 문자열 "8px" 대신 객체 {value: 8, unit: "px"}를 지원한다. 이 변화가 실무에서 체감되는 지점은 복합 토큰이다. typography 토큰 하나에 font-size, line-height, font-weight를 묶어서 Figma에서 관리하고, Style Dictionary가 CSS에선 개별 프로퍼티로, iOS에선 UIFont 설정으로 풀어주는 과정이 v4에서 빌트인으로 처리된다. v3에서 커스텀 transform 함수를 줄줄이 짜야 했던 부분이다.

{
  "heading-lg": {
    "$type": "typography",
    "$value": {
      "fontFamily": "Pretendard",
      "fontSize": { "value": 24, "unit": "px" },
      "lineHeight": { "value": 32, "unit": "px" },
      "fontWeight": 700
    }
  }
}

이 JSON 하나로 CSS font shorthand도, SwiftUI Font 선언도 뽑아낸다.

자동화해도 삐걱거리는 지점

파이프라인 구축한 팀들에서 반복적으로 등장하는 불만 두 가지가 있다.

네이밍 합의 실패. surface/primary인가, bg/main인가. 도구가 완벽해도 디자이너와 개발자가 네이밍 컨벤션에 합의하지 못하면 PR마다 이름 논쟁이 반복된다. 이건 기술 문제가 아니라 거버넌스 문제다.

다크 모드 너머의 테마 관리. semantic 토큰이 테마별로 다른 primitive를 참조해야 하는데, 이 매핑을 Figma에서 직관적으로 관리하기가 여전히 거칠다. Tokens Studio의 $themes 기능이 해법을 제시하지만, 테마가 라이트/다크를 넘어 고대비·브랜드별 변형으로 확장되면 JSON 구조 복잡도가 급상승한다.

배관은 충분히 좋아졌다. 올리브영 사례에서 보듯 Figma에서 프로덕션 코드까지 이어지는 관은 표준화됐고 도구도 성숙했다. 진짜 어려운 건 그 관 안에 뭘 흘려보내느냐다. 토큰 아키텍처와 네이밍 설계 — 그건 어떤 플러그인도 대신 해줄 수 없다.