디자인시스템 네이밍과 컬러 설정 방법의 모든것

디자인 시스템을 만들 때 알아야할 것들

Apr 9. 2025

디자인 시스템을 만들다 보면 결국 베리어블이라는 난관에 봉착합니다. 그래서 베리어블을 어떻게 만드는지 찾아보면 처음 보는 언어들이 보이죠. primitive라던지 property를 사용해서 variable을 어쩌고 저쩌고.. 하는 글을 보면 머리가 아파집니다. 디자인 토큰은 뭐고 왜 토큰인건지도 모르겠기도 합니다. 동전인가?라는 생각도 들죠. 디자인 시스템을 구축하다 보면 새로운 것들이 너무 많습니다. 아예 처음부터 A-Z까지 간단한 개념을 알가 고자 만들었습니다. 총 두 편으로 구성했습니다.

1. 디자인 토큰과 네이밍의 모든 것(현재)

디자인 토큰과 네이밍의 기본기에 대한 이야기

2. 다크모드와 웹접근성에 맞는 컬러 설정법

기본을 알았다면 실제 베리어블과 컴포넌트 구성을 어떻게 해야 하는지

1. 디자인 토큰의 개념

- 디자인 토큰이 뭐야?

- 정리

2. 디자인 토큰의 구조(아토믹 디자인)

- 아토믹 디자인과 디자인 토큰의 관계(디자인 시스템 설계 방식)

- 정리

3. 베리어블 네이밍 기본

- 베리어블 네이밍

- 육하원칙으로 네이밍 읽는 법

- 정리

4. 후일담

1. 디자인 토큰의 개념

디자인 토큰이 뭐야?

각 글로벌 회사별 디자인 토큰 정의를 알아보자

-구글 머테리얼 디자인-
디자인 토큰을 디자인의 의미와 스타일 속성들을 코드로 표현한 단위로 본다.

- 세일즈포스-
디자인 토큰을 디자인 시스템의 스타일 속성을 플랫폼과 언어에 독립적으로 관리하는 변수로 정의한다.

- 어도비 -
스펙트럼 디자인 시스템에서는 디자인 토큰을 디자인 의도를 나타내는 속성의 명명된 값이다.

- 카본 디자인 시스템 -
디자인 토큰은 디자인 속성을 코드로 추상화한 재사용 가능한 단위로 정의

-쇼피파이-
디자인 시스템에서 디자인 토큰을 디자인 시스템의 시각적 스타일을 나타내는 변수 집합

무슨 말인지 이해가 안 된다.

저 각기 다른 정의를 보면 잘 모르겠습니다. 속성.. 코드니.. 재사용 가능한 값.. 각기 다른 관리 가능한 변수의 집합.. 오히려 더 어렵죠. 디자인 토큰을 쉽게 정리해 보겠습니다.

그래서 디자인 토큰이란 뭐야?

디자인에서 자주 쓰이는 색상, 글꼴, 여백, 버튼 크기 같은 스타일 속성들을 "작은 조각"으로 만들어서 모아두는 것! 이런 조각들을 '디자인 토큰'이라고 부릅니다. 그리고 이건 어도비에서나 다른 정의에서도 나와있듯 디자인의 의미를 반영하고 있어야 하죠.

무슨 말인지 어려우니 예를 한번 들어볼게요

색상 토큰 : color-primary = #3498 db
→ 웹사이트, 앱에서 파란색을 쓸 땐 이 코드를 불러와!

색상 토큰은 color-primary으로 color 중에 primary라는 의미로 쓰입니다. 토큰이 맞죠?

글꼴 크기 토큰 : heading-font-xl = 24px
→ 제목에 쓰는 글자 xl는 24px이야.

마찬가지 heading-size-xl는 24px로 XL라는 의미로 묶었으니 토큰이 맞죠?

디자인 토큰은 단순히 #3498 db이라는 아무런 의미 없는 색상 컬러(속성)에 디자인의 의미를 담아낸 하나의 단위입니다. 그래서 #3498db을 디자인 토큰으로 네이밍 하면 color-primary가 됩니다. 아무런 의미 없는 색상값에 의미가 더 해졌습니다. 그래서 디자인 토큰입니다.

더 나아가 세일즈포스 디자인 토큰 정의에서 나왔듯 관리가능한 변수라고 했는데 이 말의 의미는 다음과 같습니다. 예를 들어, 우리 회사 웹사이트에 "주황색 버튼"이 필요하다고 했을 때. 디자이너가 주황색을

color-button-primary = #e67e22라는 토큰으로 만들어두면, 개발자는 그냥 이걸 불러서 쓰면 되고. 나중에 색을 바꾸고 싶을 때, 이 토큰만 수정하면 모든 버튼 색이 바뀌는 겁니다. 그래서 관리가능한 작은 조각들의 모음이라고 말한 겁니다. button컬러는 #e67e22를 참조하니까 그걸 바꾸면 버튼컬러를 다 바꿀 수 있는 편리함이 있죠. 그래서 관리가능한 디자인 토큰을 변수라 말한 겁니다.

자, 그럼 이 디자인 토큰이 왜 필요한지 감이 잡힐 거 같습니다.

디자인 토큰을 만들면 단순한 코드가 아니라 의미로 묶을 수 있다. 디자인 토큰으로 지정된 컬러를 수정하면 관리가 하기가 편하구나? 그래서 이렇게 정리됩니다.

1. 일관성 → 의미별로 묶여있으니 버튼 색을 쓸 땐 button-primary을 꺼내면 쓰면 되겠구나!
2. 편의성 → 디자인 토큰만 만들어서 수정하면 되니 편하네! 시스템화해서 시간을 아꼈어!

그런데 왜 토큰일까? 무슨 동전도 아니고

토큰이라고 하니 마치 동전 같아서 이해하기가 어려울 수 있습니다. 그냥 디자인 토큰은 디자인 시스템에서 복잡한 시각적 속성을 간단하고 일관되게 관리하기 위한 최소 단위를 의미합니다. 토큰의 단어 의미 중 동전의 의미뿐만 아니라 상징을 뜻하기도 하죠. 그래서 디자인 속성 값의 하나의 상징 값이라 보면 이해하기 쉬울 겁니다.

정리

디자인 토큰의 정의

디자인을 작은 조각들로 쪼개서 쉽게 관리하고 모두가 똑같이 쓸 수 있게 해주는 값들입니다.

왜 필요하다고?

일관성과 시스템의 편의성을 위해서입니다.

예시는 뭐야

button-color-hover = #e67e22라는 토큰으로 만들어두면 디자이너나 개발자는 해당 디자인을 만들 때 이걸 불러다 쓰면 되죠. 바꾸고 싶을 땐 해당 토큰을 수정하면 버튼 컬러의 값이 모두 수정돼서 편해져 디자이너도 hover 색이 primay 600이었나.. 700이었나.. 고민할 필요도 없이 hover컬러를 정하면 됩니다. 그래서 일관적인 디자인이 연출됩니다.

그래? 그럼 이거 어떻게 만들면 되는데?

디자인 토큰의 기본 개념을 알았다면 다음 디자인 토큰의 구조를 알고 아토믹 디자인을 알아야 합니다. 대부분 아토믹 디자인을 알 거라고 봅니다. 하지만 디자인 토큰, 아토믹 디자인 헷갈릴 수도 있습니다. 이 개념을 좀 정리하고 어떻게 만드는지 아래로 에 설명이 나와있습니다.

2. 디자인 토큰 구조

아토믹 디자인과 디자인 토큰의 관계(디자인 시스템 설계 방식)

아 그럼 아토믹 한 디자인은 뭐고
디자인 토큰은 또 뭐야? 뭐 다른 거야?

아토믹 디자인은 디자인을 아주 작은 단위부터 시작해 점점 더 큰 컴포넌트로 쌓아 올리는 방식입니다. 이때 가장 기초가 되는 작은 단위들이 바로 디자인 토큰이죠. 디자인 토큰은 색상, 글자 크기, 간격 같은 최소한의 속성 값입니다. 디자인 시스템에서는 이 값들을 모아 기초(Foundation)를 만들고, 그걸 조합해서 버튼이나 카드 같은 컴포넌트를 만듭니다. 디자인 시스템을 만들려면 가장 기본이 되는 디자인 토큰들이 있어야 한다는 것입니다. 이런 디자인 토큰은 모듈화 되어있어서 수정하기도 편하죠!

디자인 토큰: 색상, 글자 크기, 간격 같은 최소 단위의 값
아토믹 디자인: 가장 작은 단위(토큰)들을 모아 컴포넌트(버튼, 카드 등)로 확장해 나가는 방법

결론적으로 디자인 토큰은 아토믹 디자인의 기초 재료이고, 아토믹 디자인은 그 재료들을 조립해서 완성된 디자인을 만들어가는 과정입니다. 다음의 이미지를 보면 더 쉽게 이해될 겁니다.

GS SHOP의 디자인 시스템 설계방식

foundation을 바탕으로 component를 만들고 component들이 모여 하나의 pattern이 되고 그게 모여 template이 되고 page가 됩니다. 이게 아토믹 한 디자인 시스템입니다. 왜 잘게 쪼게 진 어토믹 한 디자인 시스템을 만들어야 하는지는 앞서 말했듯 디자인 토큰을 통해 일관되고 쉽게 관리할 수 있기 때문입니다. 일괄적으로 수정도 가능하며 다크모드와 라이트모드도 일괄적으로 부여가능하죠. blue 600만 수정해도 blue 600을 참조하는 값이 모두 수정하면 되기 때문이다.

정리

디자인 시스템의 기초

디자인 시스템은 어토믹 하게 설계되어야 관리하기 편하다. 그래서 가장 먼저 foundation 단계를 만든다. foundation은 디자인의 기초로, UI를 구성하는 color, typo, icon 같은 작은 요소들을 정의하는 것이다. 이런 작은 단위들이 모여 UI를 완성하는데, 이때 필요한 게 디자인 토큰이다.

디자인 토큰

디자인 토큰은 엄청 추상적인 로우 데이터부터 시작해서 컴포넌트까지 만들 수 있지만 컴포넌트까지는 주로 가지 않는다. 의미가 명확하면 되기에 컴포넌트까지 명명해서 복잡하게 만들 필요는 없다. 우린 플러그인을 돌려서 blue50~900까지를 쉽게 만들 수 있다.

하지만 그게 어떤 의미를 가지진 않는다. 그냥 blue 600인 거다. 하지만 blue 600을 primary 컬러에 normal로 지정한다면 비로소 의미를 가지게 되고 하나의 의미를 가진 디자인 토큰이 완성된다.

3. 베리어블 네이밍 구조

베리어블의 네이밍

디자인 토큰 구조를 이해했다면 이제 베리어블을 만들 수 있습니다. 저는 디자인 토큰 네이밍과 베리어블 네이밍이 달라서 또 뭐가 뭔지 많이 헷갈렸습니다. 로우 값이 뭔지는 알겠고 primitive(원시 값)도 플러그인 돌리면 색상을 뽑을 수 있다. 각각 어떤 의미를 가지게 할 건지도 알죠. 그러니까 blue 600으로 쓰지 않고 이제 primary-strong이라는 의미를 가진다는 것을 알겠습니다. 이제 디자이너들이 강조색을 누군가는 blue 500을 썼다가 700을 썼다가 하는 게 아니라 색상의 의미를 알고 primary-strong을 쓸 거다 까진 알 수 습니다. 그런데 어려운 건 여기서부터입니다.

베리어블의 네이밍은 이렇게 정리하는 게 업계표준입니다. 디자인 시스템 관련 서칭을 하면 정말 많이 봤었을 분류표입니다. name space부터 modifier까지 이름을 정리해서 만드는데 이렇게 정석대로 정확하게 만드는 곳은 매우 드물긴 합니다. 엄청 거대한 조직이 아니라면 name space을 굳이 만들 이유는 없죠. 두 번째 카테고리인 object 또한 특정 컴포넌트들을 가지고 시스템을 만들면 디자인 토큰만 300개는 넘어갈 겁니다. 디자인 토큰은 단순하고 간결한 게 낫습니다. 편하려고 디자인 시스템을 만드는데 관리하기 힘들고 비효율을 낳는 디자인 시스템은 쓸모가 없을 겁니다. 그래서 base와 modifier만 제작해도 괜찮다고 봅니다.

이제 좀 단순해집니다. 이 두 가지만 봅시다.

base는 기본 값과 같은 것입니다. color, text와 같은 foundation요소들이 있죠. 좀 더 세분화해서 category의 property를 나누어 구체적인 기본값을 설정할 수 있습니다. 컬러에도 bg, text와 같은 다양한 속성들이 있습니다. 이런 것들은 잘 변하지 않죠. 변수가 잘 없습니다. 그래서 base입니다. 이런 기본 값을 정의했다면 다음은 modifier입니다. color-text-strong이 될 수 있고 color-text-normal이 될 수 있다. 그래서 상태나 상황에 따라 변형된다 해서 modifier 변형 값이라 부릅니다.

기본 값은 사실 정해져 있어서 자료가 많습니다. 쇼피파이나 원티드를 참고해 보면 좋을 거 같습니다.

color-(text, bg, band, border, icon 등등등) 각 자사마다 어떤 속성을 넣을 건지 정합니다.. base에 sucess나 warning 같은 상태값을 넣는 곳도 있죠.

베리어블 읽는 법

그렇게 하나의 토큰을 만들었다고 해봅시다. color-bg-interactive-primary-hover. 처음 이걸 보면 이게 뭔 소린가.. 싶습니다. 저도 두 번 세 번 보니까 이제야 익숙해지는데 처음 봤을 때 도통 무슨 말인지 보이지 않았습니다. 하지만 이걸 쉽게 읽고 베리어블 네이밍까지 쉽게 만드는 방법이 있습니다.

color-bg-interactive-primary-hover을 이걸 한글로 만들면 어떨까요?

컬러를 백그라운드에서 인터렉티브 할 때 사용하는 컬러는 프라이머리 호버로 쓴다. 이렇게도 읽을 수 있지만

who(누가) - color가

where(어디서) : bg에서

when(언제) : interactive 할 땐

what (무엇을) : primary 컬러를

how (어떻게) : hover로 쓴다.

베리어블 네이밍은 육하원칙으로 이해합시다.

육하원칙이 보입니다.. 다른 디자인 시스템은 컴포넌트가 앞에 있고 엄청 복잡한 구조가 많습니다. 하지만 디자인 시스템은 협업의 도구로 쉽게 읽혀야 하며 학습용 이성이 뛰어나야 하죠. 그런 부분에서 육하원칙만큼 직관적인 도구가 있을까요. 다른 디자인 복잡한 디자인 시스템 네이밍 구조보다 직관적으로 단순한 네이밍을 설계하는 게 옳습니다. 레퍼런스를 찾다 보면 디자인 시스템에 정답이 없기에 너무 복잡해도 그걸 참고 삼아 만드는 경우도 있는데 최대한 단순하게 만들고 디자인 토큰도 줄이는 게 맞다고 생각합니다. 그런 의미에서 원티드와 쇼피파이의 시스템이 저는 좋습니다. 단순하고 재사용성이 좋거든요.

저는 앞서 말했듯 저는 component를 제외하고 컬러시스템을 만들 겁니다. 현재 이렇게 다 바뀌는 추세거든요. 역할중심으로 최적화로 맵핑하는 게 좋은 거 같습니다. 컴포넌트까지 하면 토큰만 수십 개 만들어야 하고 컴포넌트 새로 만드는 날이면 컬러토큰도 또 만들어야 해요. 아주 복잡합니다. 편하려고 디자인시스템 만드는 건데 배보다 배꼽이 더 커지면 안 되겠죠.

네이밍을 구조를 끝내고 먼저 엑셀에 정리합니다.

GRAY 900이 편했어요!

여기서 문제가 생길 수 있는 부분이 디자인시스템을 도입하다 보면 기존 시스템과 충돌이 일어나며 개발자와 디자이너 간의 커뮤니케이션 오류가 날 수 있습니다. gray 900으로 줄곧 개발단에 넘어왔는데 이제 color-text-heavy로 내려주니 시스템상에 넣어놨다 해도 헷갈릴 겁니다. 그래서 그 문제를 해결하기 위해 이름을 살짝 변형해 줍니다.