실무에서 통하는 색상 팔레트 문서화: 유지보수를 위한 컬러 변수명(토큰) 짓는 가이드
서론 디자인 시스템을 구축하거나 팀 단위로 협업을 시작할 때 가장 먼저 마주하는 난관 중 하나는 색상 팔레트의 문서화입니다. 단순히 예쁜 색상을 고르는 것을 넘어, 이 색상들을 코드와 디자인 툴에서 어떻게 부를 것인가 하는 문제는 프로젝트의 유지보수성에 직결됩니다. 약간 밝은 파란색, 메인 컬러 2번 같은 주관적인 표현이나 헥스(HEX) 코드를 그대로 소통에 사용하게 되면, 프로젝트 규모가 커질수록 혼란이 가중됩니다. 색상 변수명, 즉 컬러 토큰(Color Token)을 체계적으로 짓는 것은 디자이너와 개발자 사이의 공통 언어를 만드는 작업입니다. 제대로 된 이름표를 붙여두면 테마를 변경하거나 다크 모드를 도입할 때 코드를 일일이 수정하는 수고를 덜 수 있습니다. 하지만 처음부터 완벽한 시스템을 만들려다 보면 오히려 복잡성만 높아져 실무에 적용하기 어려워지기도 합니다. 따라서 확장성과 직관성을 동시에 잡을 수 있는 네이밍 규칙을 이해하는 것이 중요합니다. 원색 기반 네이밍과 시맨틱 네이밍의 차이 컬러 토큰을 만들 때 가장 흔히 겪는 고민은 색상의 실제 모습(형태)을 이름으로 할지, 아니면 그 색상이 쓰이는 목적(의미)을 이름으로 할지 결정하는 것입니다. 원색 기반 네이밍은 'Blue-500', 'Gray-100'처럼 색상명과 명도 단계를 직관적으로 조합하는 방식입니다. 이 방식은 팔레트 전체의 구성을 한눈에 파악하기 좋고, 디자이너가 색상을 선택할 때 색상환을 보듯 쉽게 접근할 수 있다는 장점이 있습니다. 반면 시맨틱 네이밍은 'Primary-Action', 'Text-Warning'처럼 해당 색상이 UI에서 어떤 역할을 하는지 의미를 담아 이름을 짓습니다. 버튼 색상을 'Blue-500' 대신 'Button-Primary-Background'로 지정해 두면, 나중에 브랜드 컬러가 파란색에서 보라색으로 바뀌더라도 변수명을 수정할 필요 없이 값만 변경하면 됩니다. 실무에서는 이...