컬러 시스템 설계 — 시맨틱 컬러와 명도 단계

컬러 시스템이 없는 팀은 버튼 색을 하나 바꾸려다가 화면 열두 개를 일일이 찾아 고치게 됩니다. 헥스 코드를 그때그때 복사해서 쓰다 보면, 브랜드 컬러가 살짝 바뀌는 것만으로도 전체 화면을 다시 훑어야 하는 상황이 옵니다. 컬러 시스템을 제대로 설계해두면 이런 반복 작업이 근본적으로 사라집니다.

1. 시맨틱 컬러가 필요한 이유

같은 파란색이라도 브랜드 프라이머리로 쓰일 때와 링크 텍스트로 쓰일 때는 역할이 다릅니다. 색상 값을 role-value로 한 번 더 감싸는 시맨틱 레이어를 두면, 브랜드 톤이 바뀌어도 컴포넌트 코드는 건드리지 않고 값만 교체할 수 있습니다.

2. 명도 단계 설계 — 50에서 900까지

컬러 시스템의 핵심은 하나의 색상을 명도별로 촘촘하게 쪼개는 것입니다. 보통 50에서 900까지 9~10단계로 나누고, 각 단계의 대비를 균일하게 맞춥니다. 배경에는 옅은 단계를, 텍스트에는 짙은 단계를 쓰는 규칙을 세워두면 디자이너마다 다른 색을 고르는 일이 줄어듭니다. 다크모드를 지원한다면 명도 단계를 반전시키는 것만으로 대응 가능한 구조로 설계하는 것이 좋습니다.

접근성 대비를 명도 단계에 미리 반영하기

명도 단계를 정할 때 눈으로만 보고 예뻐 보이는 값을 고르면 나중에 대비 문제로 다시 작업하게 됩니다. 텍스트로 쓰일 가능성이 있는 단계는 처음부터 배경 대비 4.5대1 이상을 만족하는지 확인하고 확정하는 편이 효율적입니다. 이 부분은 디자인 토큰 구조로 값을 관리하면 한 곳만 수정해도 전체에 반영되어 검증이 훨씬 쉬워집니다.

3. 피그마에서 컬러 시스템 관리하기

피그마를 쓴다면 컬러를 스타일이 아니라 Variables로 등록하는 것을 권합니다. 모드 기능으로 라이트와 다크를 하나의 컬렉션 안에서 관리할 수 있어 피그마 변수(Variables) 활용법에서 다룬 구조를 그대로 컬러 시스템에 적용하면 됩니다.

4. 왜 색상 하나가 시스템 전체를 흔드는가

컬러 값을 컴포넌트마다 직접 입력해두면, 브랜드 컬러가 바뀔 때마다 그 값을 쓰는 모든 화면을 하나씩 찾아 고쳐야 한다. 화면이 열 개일 때는 그럭저럭 버틸 수 있지만, 수십 개 화면과 수백 개 컴포넌트로 늘어나면 이 작업은 실질적으로 불가능에 가까워진다. 명도 단계와 시맨틱 이름으로 색을 관리하는 이유는 결국 이 반복 작업을 원천적으로 없애기 위해서다. 값을 한 곳에서만 바꾸면 그 값을 참조하는 모든 곳에 자동으로 반영되는 구조가, 색상 하나 바꾸는 일을 몇 주가 아니라 몇 분으로 줄여준다.

흔한 오해는 컬러 시스템을 “예쁜 팔레트를 고르는 작업”으로 여기는 것이다. 실제로 컬러 시스템의 본질은 미적 감각이 아니라 값을 관리하는 구조에 있다. 아무리 세련된 팔레트를 골라도 role 구조와 명도 단계 없이 헥스 코드를 그때그때 붙여넣는 방식이라면, 리브랜딩이나 다크모드 대응이 필요한 순간 처음부터 다시 작업해야 한다.

• 브랜드 색상마다 50에서 900 명도 단계 만들기
• 역할 기반 시맨틱 이름을 붙이기
• 텍스트용 단계는 대비 4.5대1 이상 확인하기
• 다크모드 대응 여부 미리 결정하기
• 피그마 Variables로 값 중앙 관리하기

디자인 토큰과 변수 구조를 처음 도입할 때는 컬러부터 시작하는 팀이 많다. 값의 수가 많고 눈으로 확인하기 쉬워서, 토큰 체계가 실제로 작동하는지 검증하기에 적합한 출발점이기 때문이다. 컬러에서 이 구조가 자리 잡으면, 간격이나 타이포그래피 같은 다른 값에도 같은 방식을 적용하기가 훨씬 수월해진다.

5. 마치며

컬러 시스템은 예쁜 팔레트를 만드는 작업이 아니라, 색상 변경이 한 곳에서 끝나도록 만드는 구조 설계입니다. 명도 단계와 시맨틱 이름을 먼저 정하고 나면, 이후의 리브랜딩이나 다크모드 작업이 훨씬 가벼워집니다. 다음에 새 색상을 추가하고 싶어질 때, 정말 새 role이 필요한지 먼저 점검해보세요.