디자인 토큰 네이밍 완전 정리 – KRDS vs Material Design 비교

 

안녕하세요 찐망고입니다.

이전 포스팅에서 피그마의 Variable을 다뤘고,

디자인 토큰이 어떤 개념인지도 대충 알겠다! 싶다면,

이제는 여러 디자인 시스템에서 실제로 토큰 네이밍을 어떻게 하고 있는지 살펴보는 게 순서겠죠.

 

 

디자인 토큰은 디자인 시스템의 스타일 가이드 요소인

색상, 글자, 간격 같은 속성을 변수로 정의해 코드화한 값입니다.
반복적으로 사용되는 디자인 속성을 효율적으로 관리하기 위한 일종의 추상화된 변수라고 할 수 있죠.

즉, 자주 사용하는 스타일 속성을 정의하고 이를 코드로 변환하면

디자인 시스템 전반에 걸쳐 일관된 스타일을 유지할 수 있게 됩니다.

token_visua

 

 

가장 대표적인 토큰은 구글의 머터리얼 디자인 토큰이에요.

피그마에서 바로 쓸 수 있는 머터리얼3 디자인 키트도 제공되고 있죠.

구글 머터리얼 디자인 토큰

 

클릭하시면 머터리얼3 디자인 키트 피그마 커뮤니티로 넘어갑니다.

 

 

KRDS 디자인 토큰은 디지털 취약계층을 고려하여 설계된 공공기관용 스타일 가이드 토큰이에요.
표준형 스타일을 준수하는 기관이라면 바로 적용할 수 있도록 정리돼 있습니다.

krds 디자인토큰

 

KRDS에서는 토큰을 세 가지 레벨로 나눠요:

• Primitive Token: 원시 값 자체 (예: color-blue-500: #0066FF, spacing-8: 8px)
• Semantic Token: 의미를 부여한 값 (예: button-primary-bg → color-blue-500)
• Component Token: 특정 컴포넌트에 적용되는 값

※참고로 KRDS 시스템에서는 디자인 툴에서는 시멘틱 토큰까지만 정의한다고 해요. ※

krds 디자인 토큰 레벨

 

 

 

토큰 네이밍도 중요한데

토큰 네이밍은 간결함 + 일관성이 핵심입니다.

아래는 KRDS에서 지정한 토큰 네이밍인데요.

 

색상: primary, secondary, gray 같은 의미 중심 네이밍 사용

 

• blue, red → 용도를 알 수 없음 (브랜드? 경고? 링크?)
• primary, error, info → 맥락이 드러남
• 명도/채도: "primary-10", "primary-20"처럼 숫자 단위로 정의 (보통 10단위, 세밀할 땐 5단위)

 

 

 

line-height 같은 값은 px 대신 rem/em을 활용하면 반응형 대응에 유리.

당연히 모든 크기 단위는 동일한 단위를 쓰는게 좋겠죠..

근데 line-height는 px쓰기 싫은데..

그럼 rem을 써야 하나..em? 그럼 계산..어..?

 

 

숫자 토큰: spacing, radius, height 등을 정의.

 

• 보통 4px, 8px 단위를 기본으로 확장.
• 시멘틱 요소엔 small, medium, large 같은 명확한 네이밍 부여.

 

namespace > theme > category > component > type > modifier 순으로 구성하여 네이밍 구조를 체계화합니다.

 

1. 이름 (Namespace)

• 코드에서 구분할 수 있도록 krds 같은 네임스페이스 사용.

2. 테마 (Theme)

• 스타일 테마 정의: light, high-contrast

3. 속성 (Category)

• 큰 범주의 속성: color, typography, spacing, shape

4. 컴포넌트 (Component)

• UI 구성 요소: button, input, link, card

5. 유형 (Type)

• 역할/기능: background, surface, icon, padding, text

6. 변형 (Variant)

• 계층 구조나 시스템적 부분: primary, secondary, tertiary, danger, warning, success, info

7. 요소 (Element)

• 컴포넌트의 하위 구성: label, title, body, line

8. 상태 (State)

• 상태값: default, hover, pressed, focused, disabled, selected, unselected, indeterminate

9. 크기 (Size)

• 일관된 단위: xxsmall, xsmall, small, medium, large, xlarge, xxlarge

10. 수정자 (Modifier)

• 추가적 스타일:
  • 모양: rounded, square
  • 선/채움: line, fill, outlined
  • 강조: subtle, bold, bolder
  • 밝기: lighter, light, dark, darker

 

KRDS와 머터리얼 디자인 토큰 네이밍을 비교해볼까요?

구조 방식	Suffix 중심 (토큰 뒤에 -background, -surface 등 붙임)	Prefix + Context 중심 (md.sys.color.primary, on-primary)	둘 다 계층적 구조지만 표현 방식 다름
색상 (Color)	-background, -surface, -divider, -element, -fill, -line, -neutral, -on(background)	primary, on-primary, surface, on-surface, error, on-error, outline	의미 기반 시멘틱 네이밍은 동일
투명 /강조	-alpha, -dim, -transparency, -inverse, -static	on-* 대비 토큰, container/elevation 단계로 구분 (투명도 직접 네이밍은 드묾)	KRDS가 속성 네이밍을 더 세분화
상태 (State)	-default, -hover, -pressed, -focused, -disabled, -error, -active, -completed, -selected	hover, pressed, focused, disabled	주요 상호작용 상태는 동일, KRDS가 좀 더 확장됨
밝기 단계	-lighter, -light, -normal, -dark, -darker	container, surface-variant, primary-container 등 컨테이너/서피스 계층으로 밝기 표현	KRDS는 숫자·단어 단계, Material은 컨테이너 컨셉
강조 (Intensity)	-subtler, -subtle, -bold, -bolder	없음 (대신 색상 계열 팔레트/톤으로 강조 조절)	KRDS만 별도 정의
모드 (Mode)	-light, -high-contrast	Light/Dark 모드 세트로 분리 관리 (md.sys.color.*.light, *.dark)	접근성 모드 지원 공통, 네이밍 처리만 다름

 

이렇게 보면 KRDS와 Material Design 토큰 네이밍은 방향성은 같지만, 접근 방식이 다릅니다.

• KRDS는 suffix 기반으로 속성을 촘촘하게 정의 → 문서화·공공기관 환경에 적합.
• Material은 prefix와 계층 구조를 활용해 시스템화 → 글로벌 제품/멀티플랫폼 대응에 적합.

 

결국 디자인 토큰 네이밍은 단순한 작명 규칙이 아니라,

협업 효율성과 접근성, 유지보수성을 좌우하는 핵심 요소입니다.

팀에 맞는 네이밍 구조를 잘 정의해두면,

새로운 기능이나 모드를 추가할 때도 흔들리지 않는 디자인 시스템을 유지할 수 있겠죠?

 

 

 

 

출처

디자인 토큰(Design Token) | 스타일 가이드 - KRDS

 

Design tokens – Material Design 3