토큰 이름 짓기에도 규칙이 있을까?

토큰은 실제로 업무에서는 다음과 같이 쓰인다. 버튼이 있다고 가정해 보면, 이 버튼의 백그라운드 컬러는 Foundation 토큰, Semantic 토큰 그리고 Component 토큰들로 이루어져 있다고 할 수 있다. 모두 같은 컬러를 가리키고 있지만 목적과 필요에 따라 바꾸고 관리하기 쉽게 하기 위해서 이런 식으로 정리해놓곤 한다. 

그런데 우선 토큰 이름을 잘 짓는 것이 꽤 중요하다. 왜 그럴까? 예를 들어 한 디자이너가 버튼의 배경색은 어떤 색이고 버튼의 글씨 색상은 어떻게 할지 문서화하는 과정이라고 생각해 보자. 

디자이너는 이런 식으로 정리했다. 

(디자이너 version)
버튼의 배경: Main accent color
버튼의 글씨: Main white color

이를 엔지니어가 보고 자신들이 이해하기 쉬운 방식으로 다음과 같이 메모해 놓았다. 

(엔지니어 version)
버튼의 배경: colorBgPrimaryBtn
버튼의 글씨: colorFgPrimaryBtn

 

그리고 며칠 뒤 두 사람은 회의를 하며 이야기할 시간을 가졌는데 엔지니어는 자꾸 'Primary 버튼 컬러와 Foreground 컬러'에 대해 이야기하고 디자이너는 'Primary 버튼 컬러가 Accent 컬러를 의미하는 것인지 그리고 Foreground가 무엇인지 도통 감이 안 잡힌다. 그래서 결국 그것이 무엇인지 질문한다. 디자이너는 왜 그렇게 자기들 마음대로 이름을 짓고 이야기하는지 이해가 안 되고 엔지니어는 당연히 이해할 수 있는 것을 왜 일일이 설명해야 하는지 이해를 못 하는 혼란스러운 상황이 발생한다. 

그래서 이름 짓는 것에도 규칙을 정해서 그렇게 탄생한 토큰 이름을 통해 같은 언어로 소통하면 함께 일하기에도 그들이 관리하기에도 편리해지는 장점이 있다. 

1. 첫 번째, Foundation 토큰은?

Name-00 뒤의 숫자는 05처럼 작을수록 색은 연하거나 어떤 요소의 크기가 작을 경우 사용하며 숫자가 90처럼 커질수록 색이 진하거나 크기가 클 경우 사용한다.
예시) red-05, red 10, red, 20, red 30.. etc.

혹은 숫자로 크기를 나타내기 어려울 경우에는 T-shirts 사이즈 단위를 사용한다. 예시) xsmall, small, medium, large 등)
예시) size-large

2. Semantic과 Component specific token, 어떻게 이름을 만들어낼까?

이 토큰의 경우 Foundation 토큰보다는 범위가 좁다.

그림에서처럼 각각의 파트별로 그 구성요소가 어떤 것들이 들어갈지 정해야 한다. 아웃라인으로 표시된 캡슐들이 그 파트(진한색으로 표시)에 속하는 예시들이다.

System은 회사 혹은 팀마다 다른 시스템의 이름을 쓴다. 나는 예시로 hello라고 지었다. 디자인 문서에 적을 때에는 생략할 수 있다. 

Category와 Property는 한 그룹에 속하다고 볼 수 있어서 비슷한 계열의 파란색으로 표시하였다.
Category는 말 그대로 종류를 말하며 Property는 카테고리들을 설명하게 만드는 디자인 속성들이다. 
예를 들어, Color라는 카테고리는 Background, Foreground(텍스트나 아이콘), Border 등과 같은 속성들로 설명할 수 있다. 예시) color-border

Variant는 특별한 경우를 표현하는 것들로 필요하지 않을 경우 사용하지 않을 수도 있다. 예를 들어 Hierarchy의 경우, 계층을 의미하는 Primary, Secondary, Tertiary 등이 쓰일 수 있다.

그리고 Component 토큰은 아래 그림처럼 이루어질 수 있다.

그림에서 보다시피 밝은 초록색으로 된 Component 부분이 추가되었다. 이 파트에는 다양한 것들로 대체될 수 있다. button, link, sidenav, menu, card, notification 등 특정한 Component나 Element들이 들어갈 수 있다. 

마지막으로 나는 저 다양한 구성요소들을 '-'으로 엮었는데 camel case라고 해서 앞글자만 대문자로 엮을 수도 있다. 

예시) colorBgPrimary

이는 엔지니어와 상의해서 어떤 것이 그들이 코드에 적거나 구분해서 보기 편한지에 따라 정할 수 있다.