디자인 시스템을 만들면서 가장 오랜시간 고민했다고 해도 과언이 아닌.. 네이밍과 컨벤션에 대해 이야기해보고자 한다.

체계적인 네이밍과 컨벤션

디자인 시스템엔 ‘완성’이라는 단어는 붙이기 어렵다. 디자이너의 커스텀 니즈에 맞게 형태가 변경되거나, 새로운 컴포넌트가 추가되거나, 혹은 빠지거나,…

그래서 작은 요소 하나하나에 이름을 붙일 시 주의해야 한다. 디자인 시스템에서 정의된 각각 요소들의 이름은 모든 프로젝트에서 사용될 변수명과 같다. 따라서 이 변수명은 되도록 바뀌지 않아야하며, 이해하기 쉬우면서 확장성있어야한다. 따라서 처음 지을 때 아주 잘 지어야한다.

특히 나는 네이밍 시 다음을 주의한다.

• 확장성 있는 이름인가?
• 사용처에 국한된 이름은 아닌가?
• 같은 레벨에 있는 속성의 이름과 align 되는가?
• 서로 구분되는 이름인가? (직관적이면 좋으나 항상 직관적일 순 없음)

비교급을 사용하는 체계

만약, background 색상이 다음과 같이 세가지가 있다고 해보자.

interface BackgroundColor {
	light: string;
	lighter: string
	lightest: string
}

강조될 영역을 위해서, 더 밝은 컬러를 background 컬러에 추가하게 된다면 어떻게 추가해야할까? realLightest? 🤯

물론 이런 네이밍을 사용하고 있는 디자인 시스템도 존재하며, 직관적이라는 점에서 장점은 있지만 background 컬러는 반드시 세 가지만 갖는다! 는 규칙과 합의가 없다면 이러한 네이밍은 개발에 엄청난 제한을 가져다줄 것이다.

더 밝은 컬러를 추가하기 위해 가장 밝았던 lightest 를 lighter로 강등시키고, 그 아래 단계의 컬러들도 하나씩 옮기는 작업을 하는 멍청한 상황이 생길 수 있다.

⇒ 만약 이렇게 바꾼다면 Migration 비용도 늘어날 뿐만 아니라, 기존 사용되던 light가 이전의 Light인지 변경된 Light인지… 🤯🤯🤯

그렇다면 네이밍, 어떻게 해야할까?

그렇다면 어떻게 하는 것이 확장성에 좋고, 체계적인 네이밍일까?

나는 다음과 같은 몇 가지 종류를 고려하여 정하는 편이다.

1. 사용되는 역할에 따라

interface BackgroundColor {
	base: string;
	nested: string;
	hightlight: string;

• 장점: 디자이너가 각 색상을 어디에 사용해야할지 알기 쉽다, 한 속성을 제거해도 다른 속성의 네이밍에 영향을 주지 않는다.
• 단점 : 속성이 여러 개일 때 각각 구분되는 역할의 이름을 찾기 어려운 편이다.

2. 사용빈도 혹은 중요도

interface BackgroundColor {
	primary: string;
	secondary: string;
	tertiary: string;
}

• 장점: 직관적이다. MUI 컬러 네임 체계에서도 사용되는 이름(secondary까지만)
• 단점:
  • 제4의(quaternary), 제5의(quinary), … 로 넘어갔을 땐 한국인으로서 익숙하지 않은 이름이다. (영어권에서도 잘 사용되는 단어인지 모르겠다. 사실 tertiary도 디자인 시스템 작업하면서만 사용해본 단어다.)

3. 레벨에 따라

interface BackgroundColor {
	bgLevel0: string;
	bgLevel1: string;
	bgLevel2: string;
}

• 장점: 확장이 아주 편하다.
• 단점: 각 속성의 역할이나 주 사용처를 가늠하기 어렵다.

⇒ background와 같이 특별한 정보전달 없이 사용되는 색상엔 적합한 이름이라고 생각함

4. 형태에 따라

interface ChipVariants {
	outlined: string;
	contained: string;
	muted: string;
}

기본 MUI Chip의 variants는 filled, outlined 로 두 가지이다.

interface ChipVariants {
	outlined: string;
	filled: string;
	muted: string;
}

하지만 우리 디자인 시스템에서는 투명도가 있는 약한 톤의 백그라운드를 가지는 Chip이 필요하여 pale 이라는 Variant가 추가되었다.

나는 이 pale 이라는 이름이 직관성이 부족하다고 생각했다. 그 이유는,

• 단어 형태나 이름이 설명하는 대상이 다른 속성들의 이름과 통일되지 않는다.
  • ~ed 형태로 통일
  • 기존 이름은 설명 대상이 요소의 형태에 가깝지만, pale은 색상을 설명하고 있다.
• pale도 filled 처럼 백그라운드가 있다는 점에서 그 역할이 완전히 구분되지 않으며, 형태만 보자면 filled에도 해당될 수 있는 것처럼 보인다.

따라서 수동형 분사 규칙에 맞으면서 서로 구분될 수 있도록 네이밍을 위와같이 제안했다.

이때, contained란 MUI에서 사용되는 variant 이름이며, solid한 (투명도가 없는) 색상으로 채워짐을 의미한다. Button에서 사용되는 이름이며, chip도 이에 대응되게 사용하면 좋다고 생각했다.

muted는 사전에서 뜻을 찾아보면 다음과 같다.

muted는 단순히 색상에 대한 설명이 아니라, 전체적인 형태와 역할에 대한 설명이 될 수 있다 생각했다.

물론, filled 는 MUI 기본 스펙의 이름이기 때문에 우리의 디자인 시스템 컨셉에 맞게 수정하지 않았고, filled는 단순히 ‘백그라운드가 채워졌다’기보다 ‘100% 꽉 채워진(solid하게)’으로 이해하기로 하였다.

문서화

디자인 시스템에서 가장 중요한 것이라고 해도 과언이 아니다.

디자이너와 개발자가 소통할 공통의 언어라고 비유할 수 있는 디자인 시스템,에 대한 사전을 만든다고 생각하면 된다. 체계적으로 잘 시스템을 정리해놓고 문서는 엉망이라면 과연 좋은 디자인시스템이라고 할 수 있을까? 디자인 시스템의 시작과 끝은 문서화이다. 잘 만들어둔 컴포넌트를 아무도 모른다면 절대 잘 사용할 수 없다. 모든 정보는 팀원들에게 이해하기 쉽게 공유되어야 한다.

또한, 계속해서 생기는 변동사항에 대한 버전관리가 필요하며, 이 또한 문서에 작성해두어야한다.

나는 다음과 같은 항목이 컴포넌트 문서에 꼭 포함되도록 했다.

• 기본 스펙
• 다양한 사용 예시
• 가이드라인
• 버전(change log)

시스템 용어 정리

위에서 말했듯, 디자인 시스템은 디자인팀과 개발팀이 사용할 공통의 언어이다.

하지만 사전이 잘 되어있어도 방언이 여기저기서 사용된다면? 과연 잘 소통할 수 있을까?

예를 들어, Dialog 컴포넌트를 누구는 Modal이라 하고, 누구는 Popup이라고 부른다면 의사소통에 혼란이 올 것이다. 따라서 개인이 일반적으로 사용되는 언어가 아닌, 약속된 언어를 사용할 수 있도록 해야한다.

우리의 경우, 모바일 팀에서는 react 기반의 MUI가 아닌 flutter에서 사용되는 material 기반으로 디자인 시스템을 만들게 되었고, 이 둘 사이에서 사용되는 언어의 간극이 발생했다. 디자인 또한 MUI기반으로 스펙이 짜여있기 때문에 모바일 팀원만 의사소통에 어려움을 겪게되는 문제가 발생했다. → 이를 위해 각 용어가 어떻게 대응되는지 사전을 만들자는 의견이 나왔다.

또 한가지 예로는, 특정 용어에 대한 잘못된 이해이다.

MUI에서 Theme이란 하나의 시스템을 의미한다. 따라서 theme안에는 palette, component, typography, breakpoints 등이 포함된다. 하지만 흔히 dark theme, light theme에 사용되는 단어다 보니 MUI의 palette mode나 palette 이름 자체로 오해하여 사용하는 경우가 발생했다.

한 용어에 대해 서로 생각하고 있는 개념이 다르다면 디자인 시스템의 목적 중 하나인 효율적 의사소통은 달성하기 어려워진다.

따라서 이러한 시스템 용어에 대한 정리가 필요하며, 팀원들이 공통된 언어를 사용할 수 있도록 지속적인 노력 (예)문서화)가 필요하다.

세심함, 꼼꼼함, 인내심이 필요

스펙이 잘못 반영되는 경우, 생각보다 큰 작업이 될 수 있다.

“Chip의 default 색상이 priamry여야하는데 secondary로 들어갔어요!” 하는 경우엔 좀 성가셔진다.

Chip을 사용중인 모든 프로젝트에서 버전 업데이트 후 마이그레이션 작업을 해야하기 때문이다.

default 색상이 secondary였기 때문에 명시적으로 color 프롭을 넘기지 않은 경우도 꽤 있을 것이다.

마이그레이션뿐 아니라, 모든 개발자에게 스펙이 변경되었음을 인지시켜야 한다.