디자인 시스템, 대체 너는 누구니?

01. 디자인 시스템, 왜 필요한가?

디자인 시스템이라는 개념, 처음 들으면 '그냥 디자인 가이드라인 아냐?' 싶을 수도 있어요. 그런데 말이죠, 이건 단순한 가이드라인을 넘어서는 종합 매뉴얼이자 살아있는 유기체라고 할 수 있답니다. 제품 디자인 및 개발에 대한 체계적이고 모듈화된 접근 방식으로, 지침, 원칙, 철학 등을 모두 포함하는 개념이죠. 쉽게 말해, 우리가 만드는 서비스나 제품들이 '일관성'을 유지하면서도 '효율적으로' 만들어질 수 있도록 도와주는 기준과 원칙들의 집합이에요.

그럼 왜 이런 복잡해 보이는 걸 굳이 만들어야 할까요? 🤔 현업에서 겪는 수많은 고충(Pain Points)들을 해결해주고, 그만큼 다양한 이점(Benefits)을 제공하기 때문이랍니다.

1. 현업에서 겪는 '고통스러운 문제들' (Pain Points)

실제 프로젝트 현장에서는, 팀 규모가 커지고 서비스가 복잡해질수록 디자이너와 개발자 사이에 크고 작은 문제들이 더 자주, 더 복잡하게 발생하게 되기도 해요. 처음엔 단순한 스타일 차이였던 것이 반복되다 보면 리소스가 뒤섞이고, 결국에는 사용자 경험에도 영향을 주게 되죠. 디자인 시스템이 없을 때 실제로 겪게 되는 문제들은 다음과 같아요.

🤯 리소스 파편화 및 불일치
상상해 보세요. 회사가 성장하고 서비스가 많아지면, 디자이너나 개발자가 여러 명 붙어서 각자 스타일대로 작업을 할 수 있겠죠? 이런 상황에서 일관된 가이드라인이 없으면, 같은 버튼인데 크기나 색깔이 조금씩 다르고, 폰트도 제각각이고… 이렇게 중구난방이 되면 사용자들은 서비스가 헷갈리고 혼란스러워질 수 있어요. 이건 '리소스 파편화'나 '불일치'라고 부르는데, 정말 골치 아픈 문제죠. 디자이너가 바뀌거나 새로운 기능의 UI가 기존 스타일과 달라지는 경우도 빈번하게 발생하고요.

🐢 작업 효율성 저하
디자인 가이드라인이 명확하지 않으면, 디자이너는 매번 새로운 UI를 구상하느라 머리가 아프고, 개발자는 미세하게 달라진 디자인을 일일이 맞춰야 해서 작업 효율이 확 떨어져요. 웹, 모바일, 태블릿 등 다양한 환경에서 동일한 내용을 별도로 구현할 때도 추가적인 논의가 필요해서 시간과 노력이 많이 소요된답니다. 매일 같은 디자이너가 작업하면 일관성이 있어 좋겠지만, 여러 명의 디자이너가 작업하거나 심지어 사람이 바뀌기도 하니까요.

😵 휴먼 에러 발생
사람이 하는 일이다 보니 실수는 언제든 발생할 수 있어요. 디자인 가이드라인이 없으면, 디자이너가 바뀌거나 새로운 기능의 UI가 기존 스타일과 달라지는 경우, 개발자가 모든 UI와 컴포넌트의 스타일 코드를 파악해서 대응해야 하므로  휴먼 에러 발생 가능성이 높아요. 혹시라도 누락이 발생하면, 제각각의 UI가 탄생할 수도 있죠. 이렇게 한 번 어긋나기 시작하면, 개발자들은 혼란 지수가 증가하고 손쓸 새도 없이 레거시는 괴물이 된답니다.

📈 레거시 증가
처음부터 틀이나 규칙이 잘 정해져 있지 않으면, 개발자마다 코드 스타일이 다르거나, 이미 만들어진 컴포넌트와 유사한 기능을 다시 만들게 되어 레거시가 양적, 질적으로 늘어나요. 스토어에 종속되거나 API 통신 로직이 포함된 컴포넌트, 너무 많은 기능을 담당하는 로직 및 컴포넌트, 오래된 빌드 방식, CI/CD 등 다양한 형태의 레거시가 발생할 수 있답니다. 회사가 커지면, 과거에 빠르게 결과물을 만들려고 했던 방식이 나중에는 큰 부담으로 다가올 수 있죠.

2. 디자인 시스템이 가져다주는 '눈부신 이점들' (Benefits)

이런 문제들을 해결하고, 더 나아가 팀의 생산성과 서비스의 품질을 높이기 위해 디자인 시스템은 꼭 필요해요. 디자인 시스템이 가져다누는 대표적인 이점들을 아래에서 하나씩 살펴볼게요.

✨ 일관된 사용자 경험 제공
디자인 시스템의 가장 중요한 목적 중 하나는 일관성 있는 UI를 통해 사용자가 헷갈릴 만한 요소를 배제하고, 서비스 이용 경험을 향상시키는 거예요. 어떤 환경에서든, 누가 작업하든 똑같은 결과물이 나와서 사용자들이 우리 서비스를 더 쉽고 편하게 느낄 수 있게 되죠. 회사만의 브랜드 디자인과 컬러를 딱! 각인시키기에도 좋고요.

🚀 생산성 및 효율성 향상
디자이너는 이미 잘 정의된 부품들(컴포넌트)을 가져다 조립하기만 하면 되니까 UI 구성이 쉬워지고, 개발자도 디자인 시스템에 맞게 만들어진 컴포넌트들을 조립하기만 하면 되니 개발 속도가 미친 듯이 빨라져요. 반복적인 작업이 줄어드니 업무량이 효율화되고, 핵심 기능 개발에 집중할 수 있답니다. "앞으로 우리 서비스의 버튼은 4종류의 size가 있고, 해당 사이즈에서의 font-size는 OO이야" 와 같은 간단한 규칙만 있어도 큰 차이를 만들 수 있는 거죠.

🛠 유지보수 용이성
나중에 디자인이 싹 바뀌는 대규모 리뉴얼 작업이 있어도 미리 정해둔 규칙대로 컴포넌트만 수정하면 되니까 훨씬 수월해요. 유지보수 측면에서 정말 큰 장점이죠.

☝ 단일 소스 진실 (Single Source of Truth)
디자인 시스템은 디자인과 개발 간의 '단일 소스 진실(Single Source of Truth)'을 목표로 해요. 이는 디자인 일관성, 효율적인 확장성, 테마 관리 용이성, 그리고 디자인에서 개발로의 더 나은 전환을 가능하게 하죠. 디자이너와 개발자가 똑같은 정보를 보고 작업하니까 서로 엇나갈 일이 없어져요.

🤝 디자인-개발 간 격차 해소
이 부분은 특히 뒤에서 설명할 '디자인 토큰'이 큰 역할을 하는데요, 디자인 시스템, 특히 디자인 토큰을 통해 디자인과 개발 간의 간극을 줄일 수 있답니다. 디자이너가 컴포넌트의 디자인을 변경하더라도 개발자는 해야 할 일이 적어지며, 개발자는 어떤 시스템 토큰이 연결되든 상관없이 자동으로 적용되므로 '관심사의 분리'가 이루어지는 거죠.

🌐 멀티 플랫폼 지원
웹, 모바일, 태블릿, 데스크톱 앱 등 다양한 환경에서 일관된 디자인을 제공하기 훨씬 쉬워져요. 여러 플랫폼을 지원하는 서비스라면 디자인 시스템은 더욱 강력하답니다. 회사만의 브랜드 디자인과 컬러를 모든 클라이언트에 각인시키고, 변경 시에도 모든 플랫폼에서 빠르게 대처할 수 있다는 엄청난 장점이 있어요.

3. 디자인 시스템의 '뼈대' (구성 요소)

회사마다 디자인 시스템을 구성하는 방법은 조금씩 다르겠지만, 일반적으로 다음과 같은 요소들이 포함돼요. 마치 건물을 지을 때 설계도, 자재, 시공 매뉴얼이 필요한 것처럼요.

· 원칙 (Principles)
이건 디자인 시스템이 어떤 방향으로 나아가야 할지, 그리고 이 시스템을 사용하는 사람들이 지켜야 할 원칙들을 담고 있는 부분이에요. 우리 서비스의 디자인 철학이나 핵심 가치를 담는다고 생각하면 돼요.

· UI 라이브러리 (UI Library)
디자인 시스템에서 흔히 말하는 '디자인 토큰'과 가장 깊은 관련이 있는 부분이에요. 이 UI 라이브러리는 다시 세분화될 수 있답니다.
 · 컴포넌트 (Components): 이건 재사용 가능한 UI 요소들을 말해요. 우리가 자주 사용하는 버튼, 하단 내비게이션, GNB(글로벌 내비게이션 바) 같은 것들이죠.
 · 패턴 (Patterns): 컴포넌트들이 조합되어 사용되는 규칙이에요. 예를 들어, '로그인 폼'이라는 패턴은 '입력 필드', '버튼' 등의 컴포넌트들이 특정 방식으로 배치되고 상호작용하는 규칙을 담고 있는 거죠.
 · 기반 (Foundation): 디자인 시스템의 가장 기본적인 요소들이에요. 레이아웃, 내비게이션, 색상, 타이포그래피, 사운드 등으로 구성될 수 있답니다. 특히 시각적 기초 요소들을 중심으로 '디자인 토큰'을 설계할 수 있어요.
· 가이드라인 (Guidelines)
이건 디자인 시스템이 어떤 방향으로 나아가야 할지, 그리고 이 시스템을 사용하는 사람들이 지켜야 할 원칙들을 담고 있는 부분이에요. 우리 서비스의 디자인 철학이나 핵심 가치를 담는다고 생각하면 돼요.

02. 디자인 토큰, 디자인과 개발의 '비밀 언어'!

이제 진짜 주인공인 디자인 토큰에 대해 알아볼게요. 디자인 토큰은 디자인 시스템의 시각적인 스타일을 구성하는 작고 반복적인 디자인 결정을 뜻해요. 쉽게 말해, 우리가 흔히 쓰는 '검은색' 같은 색상 코드(#000000)나 '16px' 같은 폰트 사이즈 값을 그냥 숫자로 쓰는 게 아니라, '메인-브랜드-컬러'나 '기본-텍스트-사이즈'처럼 의미 있는 이름으로 바꿔서 사용하는 거예요.

결론적으로, 디자인 토큰은 디자인 결정에 쓰일 값들을 담는 재사용 가능한 객체를 만들고 거기에 별명을 붙이는 역할을 하는 거예요. 이렇게 하면 디자인의 일관성을 지키고, 테마 관리가 쉬워지고, 무엇보다 디자인과 개발 사이의 불필요한 소통이나 오해를 줄여주는 최고의 방법이 된답니다. 이처럼 디자인 토큰은 단순한 변수를 넘어, 디자인과 개발이 함께 제품을 만드는 수단이자 양측의 분류법을 정렬하는 데 필수적인 요소예요.

03. 디자인 토큰의 '겹겹이 쌓인 아키텍처' (3계층 구조)

디자인 토큰은 보통 세 가지 계층으로 나뉘는데, 이걸 '3계층 토큰 아키텍처'라고 불러요. Rangle을 비롯한 많은 곳에서 이 3계층 아키텍처를 사용하며 토큰의 장점을 극대화한다고 설명하고 있어요. 이 세 계층이 서로를 참조하면서 유기적으로 연결되어 있어서, 가장 상위 계층에서 뭔가를 바꾸면 그 아래 모든 토큰에도 자동으로 반영된답니다. 정말 스마트하죠! 디자인 토큰 시스템은 하나의 토큰으로는 부족하고, 수십 개의 디자인 토큰으로 이루어진 복잡한 계층 구조를 가지며 매우 엄격하게 통제된 어휘와 구문을 사용한다고도 언급됩니다. 이러한 3계층 아키텍처는 디자이너와 개발자에게 요소 속성에 대한 더 정밀한 제어 권한을 부여하고, 추측을 제거하며 디자인 결정과 구현을 간소화합니다.

1. 옵션 토큰 (Option Tokens) / 코어 토큰 (Core Tokens)

옵션 토큰(Option Tokens), 혹은 코어 토큰(Core Tokens)은 디자인 토큰 시스템에서 가장 기본이 되는 토큰이에요. 여기에는 특정한 ‘의미’나 ‘기능’, ‘디자인 결정’이 담겨 있지 않아요. 마치 요리를 할 때의 ‘기본 재료’ 같은 거라고 생각하면 돼요. 색상이나 크기, 폰트 값 같은 순수한 속성 값만을 담고 있죠. 예를 들어 $color-blue-500은 단순히 파란색 계열의 500번 톤 값을, $size-8은 8픽셀이라는 크기 자체만을 나타내요. 이렇게 정의된 값들은 이후에 버튼, 로고, 체크박스 같은 다양한 컴포넌트를 만들 때 기반이 되는 재료로 사용되며, 다른 토큰들이 이 값을 참조해 의미를 부여받게 되는 구조예요. Satellytes의 소스에서도 $color-blue-500이나 $size-8 같은 토큰을 ‘man’이나 ‘lemon’에 비유하고 있는데요, 이는 나중에 의미가 부여될 수 있는 순수한 형태의 값이라는 점을 잘 보여주는 표현이에요.

2. 시맨틱 토큰 (Semantic Tokens) / 별칭/기본/브랜드/결정/테마 토큰 (Alias/Base/Brand/Decision/Theme Tokens)

시맨틱 토큰(Semantic Tokens)은 의미를 부여하는 단계예요. 앞에서 정의한 순수한 값을 그대로 사용하는 것이 아니라, 그 값이 어디에, 어떤 맥락에서 쓰이는지를 명확하게 드러내는 이름을 붙여주는 거죠. 예를 들어 $color-blue-500이라는 옵션 토큰이 있다면, 이 값을 $bx-light-color-primary처럼 "브랜드 X의 라이트 테마에서 기본 색상으로 사용되는 토큰"으로 재정의할 수 있어요. 이렇게 되면 이 파란색이 단순한 색상이 아닌, 특정한 역할과 목적을 가진 요소로 인식되기 시작해요. 이런 방식은 디자인의 일관성을 유지하면서도 변경에 유연하게 대응할 수 있는 기반이 되죠. 시맨틱 토큰은 옵션 토큰을 현실적인 디자인 결정과 연결해주는 브랜드의 시각 언어를 정의하는 핵심 도구라고 볼 수 있어요.

3. 컴포넌트 토큰 (Component Tokens)

컴포넌트 토큰(Component Tokens)은 시맨틱 토큰보다 한 단계 더 구체화된 형태로, 실제 컴포넌트의 특정 속성에 시맨틱 토큰을 적용한 최종 적용 단위예요. 즉, 의미를 부여한 시맨틱 토큰을 실제 버튼, 카드, 입력창 등의 컴포넌트에 어떻게 사용할지를 명확하게 정의하는 거죠. 예를 들어 버튼의 기본 배경색을 정의할 때, $bx-light-color-primary 같은 시맨틱 토큰을 기반으로 $bx-button-bg-primary라는 컴포넌트 토큰을 만들 수 있죠. 이렇게 하면 이 토큰 하나로 특정 테마에서 버튼이 어떤 색을 써야 할지 명확하게 전달할 수 있어요.

컴포넌트 토큰은 실제로 개발자가 가장 자주 마주하게 되는 영역이에요. 코드에 background-color: $bx-button-bg-primary처럼 사용하면, 해당 토큰이 어떤 색을 참조하든 자동으로 반영돼서 개발자는 별도로 수정할 필요가 없죠. 무엇보다 이 구조는 테마 변경이나 브랜드 확장에 매우 유연하게 대응할 수 있게 해줘요. 같은 컴포넌트라도 라이트/다크 테마, 혹은 멀티 브랜드 환경에서 서로 다른 스타일을 적용해야 할 때, 이 토큰만 바꿔주면 전체 UI가 일관되게 바뀌거든요. 즉, 컴포넌트 토큰은 디자이너와 개발자가 공유하는 실제 구현 단위의 디자인 언어로, 시스템 전체의 확장성과 유지보수를 책임지는 중요한 역할을 하고 있어요.

예시를 통한 총 정리

앞선 토큰의 계층 구조가 조금 복잡하게 느껴졌을 수도 있어요. 그래서 앞서 설명한 옵션, 시맨틱, 컴포넌트 토큰이 실제로 어떻게 연결되는지를 예시로 정리해볼게요. 하나의 색상이 어떤 흐름으로 적용되는지 보면 훨씬 쉬워질 거예요!

우리 브랜드에 표준 파란색 $color-blue-500 (헥스 값 #0000FF)이 있다고 가정해 볼게요.

(1)옵션 토큰 정의: 가장 기본적인 재료인 순수한 파란색 값을 정의해요.
$color-blue-500: #0000FF;
(2)시맨틱 토큰 정의: "이 파란색은 우리 브랜드 X의 라이트 테마에서 '기본 색상'으로 쓸 거야"라고 의미를 부여하고 결정하는 단계예요.
bx-light-color-primary: $color-blue-500;
(3)컴포넌트 토큰 정의: "이 파란색은 링크나 버튼을 강조할 때 쓸 색상으로도 좋아!"라고 특정 컴포넌트에 적용할 이름을 만들어요.
bx-light-selectable-color-primary: $bx-light-color-primary;

이제 우리는 디자인할 때나 개발할 때 그냥 $bx-light-selectable-color-primary 이 토큰만 사용하면 되는 거죠.

· 시나리오1 : 만약 파란색이 바뀌거나 다른 색으로 쓰고 싶다면?
예를 들어 $color-blue-500의 헥스 값이 #3300FF로 바뀌었다고 쳐요. 그러면 옵션 토큰만 변경하면, 이 파란색을 쓰는 모든 곳이 자동으로 업데이트돼요. 디자이너/개발자가 일일이 찾아다니면서 고칠 필요가 없다는 거죠!

· 시나리오2 : 브랜드의 기본 색상을 보라색으로 바꾸고 싶다면?
색상 팔레트 자체는 그대로인데, 디자이너가 "이제부터 우리 서비스의 주요 상호작용 색상은 보라색으로 할 거야!"라고 결정했다고 쳐요. 그러면 시맨틱 토큰만 bx-light-color-primary: $color-purple-500; 이런 식으로 다시 할당해주면 끝! 개발자는 background-color: $component-button-color;처럼 코드를 짰기 때문에, 이 컴포넌트 토큰에 어떤 시맨틱 토큰이 연결되든 상관없이 자동으로 적용돼서 할 일이 확 줄어들어요. 이게 바로 '관심사의 분리'랍니다.

어때요, 정말 편리하죠? 토큰에 의미 있는 이름을 부여해서 디자인 결정을 쉽게 이해할 수 있고, 한 번 정의해두면 모든 의존성이 자동으로 업데이트되니 디자인 변경도 훨씬 유연하게 대응할 수 있는 거예요.

04. 디자인 토큰의 '다양한 종류'와 '정의 방법'

디자인 토큰은 색상, 타이포그래피, 간격 등 브랜드의 시각적 요소를 정의하는 데 필요한 다양한 유형으로 나뉠 수 있어요.

1. 색상 (Color)

색상 팔레트를 정의하는 것은 디자인 시스템의 핵심이죠. 소스에서는 몇 가지 전략을 제시하고 있어요.
 · 레인보우 팔레트 (Rainbow Palette)
이건 2014년 Material Design 컬러 팔레트처럼 광범위하고 고르게 퍼진 색상 팔레트를 말해요. 약 19가지 톤에 각각 14가지 쉐이드(명도)가 있어서 엄청나게 많은 색상(약 260개)을 제공하죠. 하지만 이 모든 색상이 한 프로젝트에 필요하지는 않으므로, 더 적합한 다른 전략을 선택하는 것이 현명하다고 조언하고 있어요. 필요한 색상보다 더 많이 정의하면 디자이너가 불필요한 색상을 사용할 수도 있다고 경고하고 있답니다.
 · 포커스드 팔레트 (Focused Palette)
이건 브랜드의 특성을 반영하는 제한된 색상 팔레트예요. 예를 들어 5~10가지의 색조(hue)에 각각 10가지의 명도(lightness) 쉐이드가 있는 방식이죠. 이는 레인보우 팔레트에서 필요한 색상만 선택하여 만든 것으로, 총 50~100가지 색상이 될 수 있어요. 하지만 여전히 사용되지 않을 명도 쉐이드가 있을 수 있다고 지적하고 있어요.

 · 리미티드 팔레트 (Limited Palette)
가장 좋은 전략일 수 있다고 추천하는 방식이에요. 실제로 필요한 색상만 아주 제한적으로 정의하는 팔레트죠. 단점은 모든 것을 미리 충분히 고민해야 한다는 점이에요. 모든 사용 사례와 조합, 그리고 접근성까지 고려해야 하죠. 시작점으로는  page-bg, card-bg, primary-selectable-bg, secondary-selectable-bg, heading, body 같은 의미 있는 시맨틱 색상 토큰을 라이트 테마에 먼저 정의하고, 이를 페이지에 배치하여 작동하는지 확인하면서 발전시켜 나가는 방법을 제안하고 있어요.

2. 타이포그래피 (Typography)

타이포그래피는 디자인에서 중요한 부분이지만, 간결하고 구별하기 쉽게 유지하는 것이 기본 규칙이에요. 정말 필요할 때만 새로운 폰트 스타일을 도입해야 한다고 조언하고 있죠. 일반적인 타이포그래피 매개변수로는 폰트 패밀리, 굵기(weight), 크기(size), 자간(letter/word/line/paragraph spacing), 대소문자(case), 장식(decoration) 등이 있어요.

3. 크기, 간격, 보더(테두리) 등 (Sizing, Spacing, Border Radius, Border Width)

이러한 모든 측정값은 픽셀(px) 또는 렘(rem)으로 정의할 수 있어요. 렘(rem)은 HTML에서 기본 크기로 사용되며 16px과 동일해요. 16px은 본문 텍스트나 기본 간격에 자주 사용되므로 좋은 값이라고 언급돼 있어요. Figma Tokens와 같은 도구에서 rem = 16과 같은 전역 토큰을 정의해두면, 나중에 간격이나 여백을 정의할 때 픽셀 대신 렘을 사용해서 디자이너와 개발자 간의 논의를 더 쉽게 만들 수 있다고 합니다. 보더 라디우스나 너비는 픽셀로도 괜찮다고 하고요.

4. 불투명도, 입체감, 그림자 (Opacity, Elevation, Shadow)

이러한 매개변수들은 디자인에 계층 구조와 초점을 추가해요 (크기, 대비, 여백도 마찬가지). 따라서 현명하게 사용해야 한다고 조언하고 있어요.

5. 기타 토큰 유형

위에서 언급된 것 외에도 다음과 같은 것들에 대한 토큰을 정의할 수 있어요. 하지만, "가능한 한 간단하게 유지하라"고 강조하고 있답니다.

6. 배수(Multiplier) 토큰 활용 (REM & SCALE)

토큰을 더 유연하게 사용하고 싶다면, 일부 토큰에 배수(multipliers)를 추가하는 것이 좋아요.

· 전역 REM 토큰: REM = 16과 같은 전역 REM 토큰을 만들고, 폰트 사이즈 토큰에  font-size-abc: $REM/16 * xyz와 같이 추가하면, 이 전역 REM 값만 변경하면 모든 폰트 사이즈가 한 번에 변경돼요.
· 전역 SCALE 토큰: SCALE = 16과 같은 전역 SCALE 토큰을 만들고, 크기 관련 토큰(크기/간격/차원)에 REM과 동일한 방식으로 적용하면, 폰트 사이즈를 제외한 다른 모든 크기 관련 토큰을 변경할 수 있어요.
· 지역 scale 토큰: border-roundness나 border-width와 같은 다른 그룹에 지역  scale = 16을 추가하면, 관련 토큰 그룹에 다른 스케일을 적용하여 디자인의 전반적인 모양을 쉽게 변경할 수 있답니다.

이런 기본 스케일 배수를 계층적인 토큰에 추가하는 것은 전반적으로 매우 유용하며 유연성을 높여줘요. 초기에 이런 배수 토큰들을 추가하는 것이 좋고, 나중에 추가하려고 하면 오류가 발생하기 쉽고 번거롭다고 조언하고 있어요.

05.디자인 토큰의 '이름 짓기와 구조화' (Hierarchy & Syntax)

디자인 토큰은 '–'를 구분자로 사용하여 폴더나 들여쓰기된 글머리 기호 목록처럼 트리(tree) 구조로 구성돼요. 이는 토큰의 계층과 의미를 명확히 보여주는 방법이죠. 어떤 변수들이 토큰 이름에 사용될 수 있는지 살펴볼까요?

1. 네임스페이스 (Namespace)

 · 시스템 (System): 브랜드 이름처럼 bx (Brand X), by (Brand Y)와 같이 시스템을 구분하는 데 사용돼요. 이는 필수로 포함하는 것을 권장하는 부분이에요.
 · (선택) 테마 (Theme): light, dark, image와 같이 라이트/다크 모드나 이미지 배경 같은 테마를 나타낼 때 사용돼요.
 · (선택) 도메인 (Domain): web, app과 같이 웹이나 모바일 앱 등 적용되는 플랫폼이나 도메인을 나타낼 때 사용돼요.

2. 객체 (Object)

 · 그룹/개념 (Group/Concept): brand, base (브랜드가 없는 경우 대안으로), navigation, content, selectable (선택 가능한 요소), form, footer 등과 같이 디자인 요소의 큰 그룹이나 개념을 나타내요.
 · (선택) 컴포넌트 (Component): button, dropdown, feedback, success, deliveryStatus 등 특정 컴포넌트를 지칭할 때 사용돼요.
 ·(선택) 변형 (Variant): primary, secondary, tertiary (ghost), success (confirmation, positive), error (alert, critical), info, warning, new 등 컴포넌트의 특정 변형이나 유형을 나타내요.
 ·(선택) 상태 (State): default, hover, press, active, visited, focus, disabled, error 등 컴포넌트의 상호작용 상태를 나타낼 때 사용돼요.

3. 유형 (Type)

 · 카테고리 (Category): color, typography, size (sizing), spacing , border radius, border width, opacity, elevation (shadow, depth), breakpoints, touch, time (animation, duration) 등 디자인 속성의 종류를 나타내요. 이는 필수로 포함하는 것을 권장하는 부분이에요.
 · (선택) 속성 (Property): notification, success, fg (foreground), unavailable (색상용), heading-xl , body-s, size, caption (타이포그래피용), size, border (크기용) 등 카테고리 내의 세부 속성을 나타내요.

4. 수정자 (Modifier)

 · (선택) 스케일 (Scale): 1, 2, 3, 4, 5와 같은 헤딩 레벨이나, 50, 100, ..., 900과 같은 구글 머티리얼 컬러 레벨처럼 열거된 값이나 순서가 있는 값을 나타낼 때 사용돼요. teal-10 (dark), teal-50 (medium), teal-100 (light)와 같은 HSL의 0~100 명도 값을 나타내는 제한된 스케일, 또는 1-x, 2-x, 4-x, half-x, quarter-x와 같은 비율, 그리고 small (s),  medium (m), large (l), xl, xs, xxxl과 같은 T-셔츠 사이즈도 스케일의 예시로 제시되고 있어요.
 · (선택) 모드 (Mode): on-light, on-dark, on-image와 같이 요소가 어떤 배경에 놓이는지를 나타낼 때 사용돼요.

이러한 토큰 테이블에서 컬럼의 순서를 변경하는 것은 괜찮다고 해요. 어떤 순서가 더 가독성이 좋거나 ("bx-light-button-color-bg-primary-hover"), 더 계층적으로 정확하거나("bx-light-button-primary-bg-color-hover"), 표기법의 다양성을 줄여줄 수 있기 때문이죠. 옵션, 시맨틱, 컴포넌트 토큰에 따라 적합한 순서가 다를 수 있으니, 직접 시도해보고 가장 적합하다고 느끼는 것을 선택하라고 조언하고 있어요.

06. 디자인 시스템 구축 및 토큰 관리를 돕는 '친구들' (Tools)

이런 디자인 시스템과 디자인 토큰 시스템을 만들고 관리하는 데 도움을 주는 아주 유용한 도구들이 있어요.

1. Tokens Studio for Figma (Figma 플러그인)

Tokens Studio for Figma는 Figma에서 디자인 토큰을 아주 효과적으로 관리하고 디자인에 통합할 수 있게 해주는 Figma 플러그인이에요. 주요 기능들은 다음과 같아요.

 · 재사용 가능한 토큰 제공: 보더 라디우스, 간격 단위부터 시맨틱 색상, 타이포그래피 스타일까지 다양한 디자인 옵션에 재사용 가능한 토큰을 제공해요.
 · 디자인 변경의 즉각적인 반영: 이 플러그인을 통해 토큰을 변경하면, 해당 토큰이 적용된 Figma 문서나 스타일에서  변경 사항이 즉시 적용되는 것을 확인할 수 있어요. 이는 디자인 변경 작업의 효율성을 엄청나게 높여준답니다.
 · 3계층 토큰 아키텍처 구현 및 관리: 위에서 설명한 3계층 토큰 아키텍처(옵션, 시맨틱, 컴포넌트)를 효과적으로 구현하고 관리하는 데 정말 탁월한 도구예요.
 · 디자인-개발 간극 해소: Figma에서 만든 토큰들은 나중에 개발자가 쓸 수 있도록 JSON 형태로 쉽게 내보낼 수 있어요. 이렇게 되면 디자이너와 개발자 사이에 똑같은 '단일 소스 진실'을 공유하게 되면서, 디자인과 개발 사이의 간극을 줄여주는 데 큰 역할을 한답니다.
 · 정밀한 제어 및 쉬운 관리: 요소 속성에 대해 더 정밀한 제어를 할 수 있게 해주고, 다양한 토큰 세트를 생성하고 참조하며, 토큰 속성을 쉽게 관리하고 변경할 수 있게 해준다고 해요.

2. Style Dictionary

Style Dictionary는 디자인 토큰이 담긴 JSON 파일을 가져다가 개발자들이 실제로 사용할 수 있는 다양한 스타일 파일 (예: CSS 변수, SCSS 변수, Android XML, iOS Swift 등)로 변환해주는 똑똑한 라이브러리예요. 주요 기능들은 다음과 같아요.

 · JSON을 스타일 파일로 변환: 디자인 토큰은 JSON 형태로 관리되는데, Style Dictionary는 이 JSON에 담긴 토큰의 종류(레퍼런스, 시스템, 컴포넌트), 타입(컬러, 크기, 간격 등), 값 등 다양한 정보를 바탕으로  체계적인 스타일 파일 변환 로직을 설계할 수 있도록 도와줘요.
 · 변환 로직의 유연성: 어떤 기준으로 스타일 파일을 변환할지(토큰 종류별, 토큰 타입별 등), 1px solid black처럼 여러 속성을 포함하는 border와 같은 다중 스타일을 어떻게 처리할지, 그리고 토큰의 값이 다른 토큰을 참조하는 경우(컴포넌트 토큰이 시스템 토큰을 참조하는 경우)를 어떻게 처리할지 등 다양한 상황에 맞춰 로직을 설계할 수 있답니다.
 · 개발자 도구에서의 가독성 향상: 예를 들어, 개발자 도구에서 그냥 #0000FF가 아니라 var (--버튼-컬러토큰)처럼 토큰 이름으로 보이게 만들 수도 있어서, 개발자들도 어떤 디자인 토큰이 적용되었는지 쉽게 확인할 수 있죠. 이는 개발자와 디자이너 간의 소통을 더욱 원활하게 하고 디버깅을 쉽게 만들어 줘요.

07. 디자인 토큰 생성 및 활용 '가이드라인'

디자인 시스템을 구축하려는 모든 팀에게 가장 중요한 건 ‘잘 시작하는 것’입니다. 앞서 설명한 디자인 토큰 아키텍처와 도구들을 잘 활용하기 위해, 참고할 만한 몇 가지 핵심 가이드라인을 소개해드릴게요.

08. 마무리하며

디자인 시스템은 단순히 "예쁘게 만들자"는 관점이 아닌, 제품을 어떻게 더 일관되고 효율적으로 만들어낼 수 있을까에 대한 근본적인 고민의 결과물이에요. 그리고 그 중심에는 디자인 토큰이 있죠. 디자인 토큰은 그 안에서도 가장 핵심적인 역할을 맡고 있고요. 특히 토큰 기반 아키텍처로 구성된 디자인 시스템은 변화에 훨씬 더 유연하게 대응할 수 있어요. 예전 같으면 수십, 수백 개의 컴포넌트를 하나하나 수정해야 했던 일도, 이제는 색상 하나만 바꿔도 전체 UI에 자동으로 반영되는 구조가 가능해졌죠. 이런 구조적 유연성 덕분에 브랜드는 새로운 환경이나 플랫폼에도 빠르게 적응하고, 일관된 경험을 유지하면서 자연스럽게 확장해나갈 수 있게 됩니다.

유플리트 역시 , 조직 내에서의 디자인 일관성과 효율성 향상을 위해 디자인 시스템을 준비하고 있습니다. 작은 실험과 논의들을 하나씩 쌓아가며, 점차 조직의 브랜드 언어를 구조화된 시스템으로 발전시키고 있죠.

이 글이 디자인 시스템과 디자인 토큰에 대해 고민하고 있는 분들에게 작은 나침반이 되었기를 바라며 글을 마치겠습니다.
감사합니다.