(번역) 컴포넌트 레벨 디자인 토큰: 그것들은 가치가 있을까요?
139
Table of Contents
본문
원문 Component-level Design Tokens: are they worth it? 을 번역한 포스트입니다. 문제가 될 시 삭제하겠습니다.
개요
디자인 토큰이란 무엇인지를 배우고, 어떻게 사용하는지, 그리고 디자인 시스템에 대한 장점을 알려주는 리소스들이 많이 있습니다. 하지만 이 글은 그런 글이 아닙니다.
이 글의 목적은 컴포넌트 레벨의 디자인 토큰의 실제 사용 사례를 제공하는 것입니다. 이 글은 디자인 시스템 전체에서 왜 디자인 토큰을 사용하고자 하는지, 언제 사용하는 것이 유용한지, 그리고 얼마나 많이 사용해야 할지에 대한 이해를 돕습니다. 이 문서의 예시는 저자가 Adobe의 Spectrum Design System에서 컴포넌트 레벨의 토큰을 구현하는 과정에서 얻은 경험을 바탕으로 합니다.
컴포넌트 토큰의 이점
우선, 컴포넌트 레벨의 디자인 토큰을 사용하는 몇 가지 이점을 살펴보겠습니다.
디자인 보안 (Design security)
디자인 토큰은 색상, 간격, 타이포그래피와 같은 기본적인 디자인 요소의 보안, 유연성, 통일성을 제공합니다. 컴포넌트 레벨 토큰에도 동일한 기능적 이점이 있습니다. 컴포넌트 레벨 토큰은 디자인과 구현 사이의 관심사 분리를 최종적으로 구현하는 역할을 하며, 시스템의 중복과 파편화를 줄입니다.
컴포넌트 레벨 토큰이 컴포넌트 라이브러리에 구현되면, 디자인은 컴포넌트의 모든 속성에 대해서 제작자가 선택한 값이 원하는대로 반영되었음을 보장할 수 있습니다 (모든 토큰이 의도한 위치에서 올바르게 사용되는 경우에 한해). 디자인 시스템이 해결하려는 가장 큰 문제 중 하나는 의사소통 오류, "인수인계" 및 디자인 번역에 대한 인간의 실수입니다. 컴포넌트 레벨 토큰은 디자인과 개발자 간의 명확하고 오류가 없는 프레임워크를 제공합니다.
Spectrum에서는 이 접근 방식을 사용하여 7개 이상의 고유한 프레임워크가 우리 디자인을 일관되고 정확하게 구현하는 것을 보장했습니다.
규모에 따른 유연성
컴포넌트 레벨 토큰을 사용하면 팀은 시간이 지남에 따라 디자인을 발전 시킬 수 있고 이때 엔지니어링 사용자에게 주는 영향을 최소화할 수 있습니다. 대부분의 작은 디자인 업데이트(패치)에 대해서도 이는 주요한 시간 절약 요소가 될 수 있습니다.
Spectrum에서는 많은 기간 동안 컴포넌트 토큰에 대한 패치 업데이트를 수행했고 변경 사항이 컴포넌트 토큰을 사용하는 모든 프레임워크에 연쇄적으로 적용되도록 보장했습니다. 조율을 위한 의사소통 외의 필요한 작업은 토큰을 가장 최신 버전으로 업그레이드하는 일 뿐이었습니다. 이로써 팀은 프레임워크에서 토큰 할당을 직접 업데이트하는 반복 작업을 많이 피할 수 있었습니다.
셀프 서비스 친화적 (Self-service-friendly)
컴포넌트 레벨 토큰은 토큰이 사용되어야 하는 위치에 대한 구체성을 제공합니다. 일관된 프레임워크를 통해 이러한 토큰은 셀프 서비스 모델을 지원합니다. 다시 말해, 이러한 토큰은 **"자기 자신을 대변"**하며 컴포넌트에 통합하는 것은 간단해야 합니다. 예를 들어, button-cta-background-color-hover와 같은 토큰은 토큰이 무엇인지 (배경 색상), 어떤 컴포넌트와 어떤 역할인지 (CTA 버튼), 그리고 적용된 특정 인터랙션 상태 (hover) 등의 필요한 정보를 모두 가지고 있습니다.
Spectrum에서 초기에는 디자인 시스템을 컴포넌트 라이브러리에 구현하는 매우 작은 규모의 팀과 파트너 팀이 있었습니다. 이러한 팀은 전 세계적으로 분산되어 있어 협업이 어려웠습니다. 컴포넌트 레벨 토큰은 모든 팀이 최소한의 의사 소통으로 업무를 진행할 수 있도록 도움을 주었습니다. 또한 엔지니어링 팀에 대한 공통 언어와 시스템에 대한 이해를 확립하는 데도 도움이 되었습니다.
자동화 친화적 (Automation-friendly)
컴포넌트 레벨 토큰은 디자인 시스템에서 자동화 워크플로우의 기초입니다. 컴포넌트의 속성과 상태의 모든 순열을 철저히 구현하고 기계가 읽을 수 있는 형식으로 구현하면, 코드를 생성하고 회귀 테스트를 자동화하며 코드베이스에서 적절한 토큰 구현을 위한 규칙을 생성 (lint)할 수 있는 데이터를 얻을 수 있습니다. 디자인 시스템에서의 자동화는 디자인 시스템 팀뿐만 아니라 전체 조직에 큰 이점을 제공합니다. 이는 운영 효율성의 목표를 대표합니다.
Spectrum의 컴포넌트 레벨 디자인 토큰은 몇몇 프레임워크 팀의 시각적 회귀 테스트를 향상시키는 데 사용되었습니다. 토큰을 업그레이드할 때, 특정 컴포넌트의 VRT (시각적 회귀 테스트)가 실패했지만 토큰 할당이 동일한 경우, 해당 변경 사항이 이전 커뮤니케이션과 릴리스 노트를 통해 예정된 디자인 변경인지 빠르게 확인할 수 있었습니다. 또 다른 예로, 일부 팀은 컴포넌트의 API와 컴포넌트 레벨의 토큰을 기반으로 스타일(예: CSS)의 생성을 자동화할 수 있었습니다.
도전과 함정
컴포넌트 레벨 토큰의 잠재적 이점에 너무 흥분하기 전에, 사용 시 발생하는 일부 심각한 도전에 대해서 알아야합니다.
제작 규모의 확장 (Authoring bloat)
컴포넌트 레벨의 토큰 작성은 쉽게 어려워질 수 있습니다. 컴포넌트의 모든 속성을 토큰화하고, 모든 조합과 상태에 대해 토큰화하면 데이터가 다차원적이고 기하급수적으로 증가합니다. Style Dictionary나 Theo와 같은 기존의 디자인 토큰 작성 메커니즘은 이 접근 방식에는 부족합니다. 그러나 이 문제는 그 메커니즘의 문제라기보다는, 여러분이 "디자인 토큰"으로 정의한 것에 더 관련이 있습니다.
Spectrum에서는 제작 규모의 확장을 수용하기 위해 계속해서 내부 디자인 토큰 작성 도구를 발전시켜야 했습니다. 우리는 토큰 데이터의 상속/확장을 지원하는 도구를 구현했으며, 이를 사용하여 컴포넌트의 모든 조합에 대한 토큰을 확장했습니다. 이는 컴포넌트의 다양한 옵션과 상태에 따라 특정 토큰을 반환하기 위해 조건 또는 함수를 작성할 수 있는 기능으로 발전되었습니다. 도구는 이렇게 강력해졌지만, 학습이 어렵기 때문에 토큰 시스템에 참여할 수 있는 기여자의 수를 제한하는 함정이 있었습니다.
패키지 및 소비 확장 (Package & consumption bloat)
확장의 가장 눈에 띄고 영향력 있는 측면은 토큰의 결과물에서 나타납니다. 철학적인 방식인 키-값 쌍이나 데이터(예: JSON) 방식으로 토큰에 접근한다면, 어떤 단일 컴포넌트에 대한 결과물은 매우 커질 수 있습니다. 예를 들어, 세 가지 variant (primary, secondary, tertiary), 세 가지 크기 (small, medium, large) 및 네 가지 상호작용 상태 (default, hover, keyboard focus, down/pressed)를 갖는 컴포넌트가 있다고 생각해 봅시다. 또한 이 컴포넌트는 12개의 속성(예: border-radius, height 등)이 정의되고 토큰화되었다고 가정합시다. 간단한 계산으로도 이 정도 규모의 데이터 세부성 (specificity)은 432개의 토큰을 생성할 것임을 알 수 있습니다. 이는 컴포넌트 라이브러리 팀이 코드 상에서 432개의 토큰에 대한 연결을 자동화 도구에 의존하거나 수동으로 작성해야 한다는 것을 의미합니다. 이는 좋은 상황이 아닙니다. 이는 의도된 것보다 더 많은 시간을 소비할 수 있습니다.
한 때 spectrum은 18MB 크기의 JSON 파일에 210,180개의 디자인 토큰을 보유하고 있었습니다. 우리는 고도의 세부성 (보안성, 유연성, 자동화)을 수용할 수 있는 동시에 전통적인 디자인 토큰 결과물 형식의 확장 없이, 디자인 토큰을 “재발명”해야 했습니다. 이는 더 많은 혁신을 의미했지만, 동시에 학습 곡선이 더욱 크게 증가했습니다. 결과적으로 이는 토큰 시스템에 대한 기여를 성장시키는 데 부정적인 영향을 미쳤습니다.
인지 부하 (Cognitive load)
디자인 토큰은 사용자(디자이너 및 개발자 모두)를 위한 인터페이스임을 기억하는 것이 중요합니다. 컴포넌트 레벨의 토큰은 셀프 서비스 모델을 제공하지만, 동시에 오랜 기간 동안 이해하기 어려워지고 더 많은 혼돈을 야기할 수도 있습니다. 확장은 인지 부하에 영향을 미치지만, 컴포넌트 레벨의 토큰 이름은 이를 더욱 악화시킬 수 있습니다.
Spectrum에서 우리는 몇 가지 컴포넌트 토큰의 이름이 너무 길어서 개발자들이 각 단어가 무엇과 관련이 있는지 이해할 수 없게 되었습니다. 다양한 옵션의 다차원성으로 인해 토큰의 셀프 서비스 기능이 상실되었습니다. 이러한 토큰의 구체적인 예는 spectrum-button-m-warning-quiet-overbackground-textonly-focus-ring-animation-duration입니다.
유연한 시스템에 대한 유연하지 않은 API
이 접근 방식은 컴포넌트 토큰의 토큰 이름이나 데이터 구조에 매우 크게 의존합니다. 토큰의 이름이 API가 되므로 속성의 순서나 "토큰 이름"의 구성은 매우 중요합니다. 처음에는 큰 문제로 보이지 않을 수 있지만, 속성 이름이 변경되거나(예: variant) 디자인에서 이전에 존재하지 않던 컴포넌트 옵션을 추가하는 경우에 매우 큰 변경이 될 수 있습니다.
Spectrum은 컴포넌트 토큰과 해당 옵션 + 상태에 대한 네이밍 규칙을 강제하기 위해 간단한 규칙을 사용했습니다. 이러한 표준 네이밍 규칙(API)에 따르면, 예를 들어, 만약 모든 컴포넌트에 “t-shirt-size”라는 항목을 새롭게 추가하려고 할 때 문제가 생길 수 있습니다. 토큰 이름 뒤에 “t-shirt-size”를 무작정 추가할 수는 없기 때문입니다. 따라서 “t-shirt-size”를 표준에 맞게 토큰의 특정 순서에 배치했습니다. 이로 인해 이제 “t-shirt-size”를 지원하는 각 컴포넌트의 모든 디자인 토큰이 변경되었습니다. 예를 들어,
spectrum-button-primary-textonly-height는spectrum-button-m-primary-textonly-height가 되었습니다 (중간 사이즈를 나타내기 위해-m이 추가되었습니다). 각 프레임워크는 새로운 토큰 이름으로 코드를 업데이트해야 했으며, 대부분은 찾아 바꾸기 (ctrl + f)로 수행되었습니다.
디자인 시스템에서 컴포넌트 레벨의 토큰을 사용하는 시기?
보시다시피, 컴포넌트 레벨의 토큰에는 강력한 이점과 치명적인 단점이 있습니다. 제 경험에 따르면, 대부분의 디자인 시스템에 좋은 접근 방식은 필요한 경우에만 소수의 컴포넌트별 토큰을 사용하는 것입니다. Spectrum에서 사용한 것과 같은 완전한 수준의 컴포넌트 토큰 시스템은 특정 시나리오에 맞을 때만 가치가 있습니다. 예를 들어 다음과 같은 경우입니다:
- 지원해야 할 프레임워크 구현이 많은 경우 (4개 이상)
- 중앙 집중화된 디자인 팀
- 단일 디자인 언어 (하나의 브랜드, 하나의 스타일)
- 플랫폼의 일관성 (iOS 또는 Android 중심 디자인이 거의 없는 경우)
- 강력하고 전문적인 디자인 도구 팀
대부분의 디자인 팀은 이러한 모든 요건을 충족시키지 못할 것입니다. 사실 Spectrum도 이에 해당하지 않으며 현재는 각 플랫폼(iOS, Android, Windows)에 더 잘 적응하기 위해 진화하고 있습니다. 만약 여러분의 디자인 시스템이 이 다섯 가지 요건과 일치하는 경우에는 컴포넌트 레벨의 디자인 토큰이 고려해볼 가치가 있지만, 그렇지 않을 경우 비용이 수익을 크게 상회할 수 있습니다.
더 생각해볼 사항
오늘날의 “디자인 토큰”의 정의에 따르면, 저는 컴포넌트 레벨 토큰의 가장 큰 잠재력은 그들의 사용 (use)에 있기 보다는 철학과 그들이 달성하고자 하는 목표에 더 있다고 생각합니다.
자동화, 기계 판독 가능성, 관심사의 더 나은 분리, 시스템 지향적 접근, 그리고 더 나은 디자인 및 엔지니어링 도구는 모두 가치 있는 목표입니다.
솔직히 말해서, 오늘날의 도구는 "디자인 토큰" 작성이나 유지 관리에서 가치를 제공하기에는 너무 간단한 경우를 제외하고는 세련되지 않았습니다. 디자인 시스템은 반복 가능한 규칙, 조건, 공통 스타일 및 상속에 기반합니다. 이를 지원하는 도구가 필요합니다.
토큰의 정의 방식도 비슷하게 진화해야 합니다. 정적 데이터와 키-값 쌍 대신, 컴포넌트 레벨의 토큰 개념은 올바른 토큰에 도달하기 위한 지침으로만 존재해야 합니다. 별칭(alias)과 마찬가지로, 이들은 디자인 토큰을 사용하여 컴포넌트를 구성하는 데 필요한 지시사항입니다. 하지만 이를 위해 새로운 형식이나 파일 형식이 필요합니다. 이 형식은 가볍고 시스템 지향적이며 상호 운용 가능해야 합니다.
이러한 통찰력이 디자인 시스템 팀과 그 사용자들을 위해 디자인 토큰 추상화의 다양한 수준을 탐색하는 데 도움이 되기를 바랍니다.