서론
과거에 디자인 토큰으로 설계하는 디자인 시스템글을 작성했었다. 당시엔 Token Studio와 스타일 딕셔너리를 도입해서 토큰 기반의 UI 코드를 구조화하는 방법을 소개했었다. 그런데 시간이 지날수록 우리는 더 확장성 있고 현실적인 워크플로우가 필요하다는 걸 느끼게 되었고, 그 과정에서 많은 구조적 변화와 실험을 해왔다.
이 글에서는 Token Studio + 스타일 딕셔너리를 제거하고, Figma 변수 기반의 디자인 토큰 구조로 진화시킨 이유와 실제 적용 방식, 그리고 그로 인해 얻은 이점들을 소개하려 한다. 단순한 이론이 아닌, 실제 우리가 서비스에 적용하면서 마주친 문제와 해결 방향을 담은 Design Token V2의 기록이다.
왜 Token Studio가 아닌 Figma 변수인가?
처음에는 Token Studio와 스타일 딕셔너리를 디자인 토큰의 주된 소스로 사용했었다. 여러 팀에서 검증된 도구이기도 하고, 토큰 관리에 특화된 기능이 많았기 때문이다. 하지만 실제로 시스템을 운영하면서 다음과 같은 한계에 부딪혔다.
Token Studio 기반 워크플로우의 한계
-
확장성 부족 : 토큰이 점점 많아지고 복잡해질수록 Token Studio의 구조가 무거워졌다. 특히 서비스별로 커스텀 디자인토큰을 반영해야 할 때, Token Studio만으로는 제한이 있었다.
-
Figma 자체 변수의 잠재력 : Figma가 제공하는 변수(Variables)는 디자이너 입장에서 기본 제공되는 기능이라 협업이 쉽고, 여러 기능을 자체적으로 지원한다는 기대가 있었다.
이러한 이유로 우리는 Token Studio와 스타일 딕셔너리를 제거하고, Figma 변수에 기반한 디자인 토큰 구조로 전환했다.
진화된 구조: 토큰 체인의 분리
기존의 디자인 시스템 글에서 다룬것과 동일하게, 토큰에는 레퍼런스 토큰, 시스템 토큰, 컴포넌트 토큰이 있다. 여기서 컴포넌트 토큰이 컴포넌트에 직접적으로 바인딩되는 토큰이다. 우리는 여기서 하나의 아이디어를 얻었다.
컴포넌트 토큰만 컴포넌트에 직접 바인딩되고, 나머지 토큰들은 체인처럼 연결되는 구조이다. 여기서 컴포넌트 토큰에 연결된 시스템 토큰만 변경한다면 어떻게 될까? 컴포넌트의 UI가 변경될 것이다. 즉, 컴포넌트의 기능은 그대로 사용하면서, 컴포넌트의 색상, 보더, 라운드 등 UI만 다르게 할 수 있게 된다.
이것은 서비스별 커스터마이징 가능하다는 말과 동일하다. 예를 들어, 서비스 A는 색상 팔레트가 다르고, 서비스 B는 UI 요소의 radius가 다를 때, 우리는 서비스 별로 시스템토큰을 설계하면 된다. 시스템 토큰 레벨에서 값만 변경하면 컴포넌트 전체 UI에 반영할 수 있는 것이다. 즉, 컴포넌트 코드를 건드릴 필요 없이 토큰 값만 바꾸면 각 서비스에 맞는 UI가 자동으로 만들어진다.
또한, 컴포넌트 토큰 중심 설계를 할 수 있다. 우리의 철학은 단 하나다. '컴포넌트가 의존하는 토큰만 정확히 바인딩하고, 나머지는 참조로 연결하자'이다. 이것은 컴포넌트마다 UI/UX 일관성 유지할 수 있게 해주고, 서비스별 커스터마이징 시 부작용 최소화하며, UI 요소의 속성이 명확하게 분리된다. 우리 서비스에서는 셀렉트, 케스케이더, 데이트 피커, 체크박스, 라디오, 다이얼로그, 토스트와 같은 컴포넌트는 모두 이 구조를 따르고 있다.
컴파운드 컴포넌트 구조와 토큰
<Dialog.Root open={open} onOpenChange={setOpen}>
<Dialog.Trigger asChild>
<button>Open Dialog with Trigger</button>
</Dialog.Trigger>
<Dialog.Overlay />
<Dialog.Portal>
<Dialog.Content>
<Dialog.ContentHeader>
<Dialog.Title>Trigger Dialog</Dialog.Title>
</Dialog.ContentHeader>
<Dialog.ContentMain>Main</Dialog.ContentMain>
</Dialog.Content>
</Dialog.Portal>
</Dialog.Root>단지 토큰 구조만 좋다고 끝나는 게 아니다. 우리는 컴파운드 컴포넌트 패턴으로 설계를 했기 때문에, 컴포넌트 자체의 커스터마이징도 쉽다. 이 구조에 컴포넌트 토큰을 바인딩해두면 서로의 장점들을 더 부각시켜줄 수 있다. 서비스별로 디자인 속성 유연 적용할 수 있고, 커스텀도 쉽게 할 수 있으며, 이는 컴포넌트 재사용성이 극대화되는 효과를 가지게 된다.
왜 우리는 완전한 Headless로 가지 않았는가?
많은 디자인 시스템들이 요즘 Headless UI 패턴을 따르고 있다. 하지만 우리는 다음의 이유로 Headless만을 고집하지 않았다.Headless는 구조적으로 로직과 스타일을 완전히 분리한다는 장점이 있지만, 서비스별 테마나 스타일을 반영할 때나 공통 UI 패턴은 유지하면서 일부 스타일만 바꾸고 싶을 경우에는 적합하지 않다고 생각했다.
즉, Headless만으로는 공통 스타일 유지 + 자유로운 커스터마이징이라는 목표를 만족시키기 어려웠다.
Figma에서 서비스별 UI를 “선택”할 수 있는 구조
컴포넌트 토큰에 바인딩된 시스템 토큰 혹은 레퍼런스 토큰의 값만 변경되면, 시스템별로 도메인 색깔에 맞는 UI를 볼 수 있다고 했다. 이것을 스토리북에서도 확인 할 수 있도록, 하나의 공통 컴포넌트에 서비스별 테마를 선택할 수 있는 기능을 추가했다.
기존에는 서비스별로 스토리북이 존재하고, 디자이너는 서비스별로 만들어둔 디자인 시스템과 비교하며 여러 비용이 들었을 것이다. 하지만 이와 같은 구조를 설계하고 난 뒤에는 하나의 스토리북에서 간단한 조작을 통해, 특정 서비스에 해당하는 컴포넌트의 UI/UX를 확일 할 수 있게 되었다. 이것은 디자이너와 개발자 간 커뮤니케이션 비용도 감소하고, 유지보수하는 측면에서도 이점이라고 생각한다.
마무리
디자인 토큰 구조를 Token Studio 기반에서 Figma 변수 기반으로 전환하는 과정에는 여러 고민이 필요했다. 고심끝에 전환한 결과는 만족스러웠다. 확장성, 서비스별 커스터마이징, UI/UX 일관성 등을 만족시키는 구조로 진화했기 때문이다.
실제로 챕터 조직으로 바뀌면서, 여러 서비스에 투입되고 있는데, 컴파운드 컴포넌트 + 디자인 토큰 + 서비스별 UI 대응 가능한 구조로 인해 매우 많은 시간을 아낄 수 있게 되었다. 이처럼 앞으로도 DX를 개선하기 위해서 노력할 것이다.
