컬러 시스템은, 세 직군의 합작입니다.

“브랜드 컬러 정해 주세요”라는 요청을 받으면, 저희는 색을 하나 고르는 일로 시작하지 않습니다. 디자이너는 ‘이 색이 어떤 가족을 거느릴까’를 보고, 접근성 담당은 ‘이 색 위에 글자가 읽힐까’를 묻고, 개발자는 ‘이 색을 어디 한 곳에 적어두고 전부 참조하게 할까’를 생각합니다. 같은 색을 세 사람이 다른 눈으로 봅니다. 그 셋이 합쳐질 때 비로소 ‘시스템’이 됩니다.

먼저, 색 하나에서 시스템을 만들어 보세요

설명보다 빠릅니다. 아래에서 기준 색을 하나 고르면, 그 색에서 밝은 단계와 어두운 단계가 즉시 생깁니다. 색 하나가 어떻게 한 줄의 시스템이 되는지 눈으로 보세요. 이게 디자이너가 가장 먼저 하는 일입니다.

액센트와 중립 — 색마다 ‘일’이 다릅니다

색은 개수가 아니라 역할로 셉니다. 액센트는 ‘여길 누르세요’라고 외치는 색이라, 화면에서 가장 중요한 행동 하나(제출·구매·문의)에만 씁니다. 중립은 배경·테두리·본문 텍스트를 책임지는 회색 계열이라 넓고 차분하게 깝니다. 액센트를 여기저기 쓰면 강조가 사라지고, 중립이 흔들리면 화면 전체가 들뜹니다. 위 생성기에서 만든 단계가 바로 이 역할들을 나눠 맡는 ‘계단’입니다.

틴트와 셰이드 — 한 색을 위아래로 늘리는 법

기준색에 흰색을 섞으면 밝아지고(틴트), 검정을 섞으면 어두워집니다(셰이드). 위 생성기의 한 줄이 바로 그 계단입니다. 왼쪽 끝은 거의 배경처럼 옅고, 오른쪽 끝은 글자로 써도 될 만큼 진합니다. 이렇게 5~9단계를 만들어 두면, 같은 색 가족 안에서 배경·옅은 테두리·기본 텍스트·호버 상태를 전부 해결합니다. 색을 늘리는 게 아니라 한 색을 깊게 파는 겁니다.

그런데 그 조합, 읽을 수 있나요?

예쁜 조합이 가장 자주 무너지는 지점이 여기입니다. 연한 회색 글자에 흰 배경, 파스텔 위의 파스텔. 디자이너 모니터에선 멀쩡해 보여도 햇빛 아래 휴대폰이나 저시력 사용자에겐 글자가 사라집니다. 그래서 색을 고르면 반드시 대비를 ‘측정’합니다. 이게 접근성 담당이 합류하는 지점입니다. 직접 해보세요. 두 색을 골라보면 합격 여부가 즉시 나옵니다.

이 검사기는 WCAG의 상대 명도 공식 그대로 계산합니다. 본문 글자라면 4.5:1, 24px 이상이거나 굵은 19px 이상의 큰 글자라면 3:1을 넘겨야 합니다(WCAG 2.1 AA). 저희는 시안을 넘기기 전에 본문·버튼·플레이스홀더까지 전부 이 기준을 통과시킵니다. 접근성은 ‘배려’이기 이전에 ‘읽히느냐’의 문제입니다. 위 팔레트 생성기에서 단계를 미리 만들어 두면, 옅은 틴트 위엔 진한 셰이드, 진한 셰이드 위엔 밝은 틴트로 통과하는 짝을 고르기가 쉽습니다.

이제 개발자가 합류합니다 — 토큰화

디자인이 단계를 만들고 접근성이 대비를 통과시켰다면, 마지막은 그 색들을 코드 한 곳에 묶는 일입니다. 색을 화면마다 직접 적으면(#3fe6c0을 버튼·링크·강조에 일일이) 나중에 한 군데만 빠뜨려도 톤이 어긋납니다. 그래서 --accent·--bg·--text 같은 토큰으로 한 곳에 정의하고, 모든 곳은 그 이름만 참조합니다.

그래서 액센트 하나만 바꿔도 전체가 조화로워집니다

이게 합작의 결실입니다. 기준 액센트에서 단계를 다시 생성하고, 그 단계를 토큰에 연결해 두면 — 기준색 하나를 바꿨을 때 그 토큰을 쓰는 배경·테두리·텍스트·버튼이 한꺼번에 같은 톤으로 움직입니다. 위 팔레트 생성기에서 기준색을 바꿔보세요. 한 줄 전체가 함께 움직이죠. 실제 사이트도 똑같습니다. 색을 ‘고르는 일’이 아니라 ‘시스템을 만드는 일’로 다루는 이유입니다.

과채도와 저대비를 경계합니다

두 가지가 시스템을 가장 자주 망칩니다. 과채도는 너무 쨍한 색을 넓은 면적에 깔 때 생깁니다. 눈이 피로하고 번져 보여 텍스트 가독성이 떨어집니다. 그래서 넓게 까는 배경·중립은 채도를 낮추고, 쨍한 채도는 좁은 액센트에만 허락합니다. 저대비는 위 검사기로 잡습니다. 색을 만드는 단계에서 미리 측정하면, 디자인이 끝난 뒤 ‘안 읽힌다’며 뒤집는 일이 없습니다.

이 컬러 시스템, 세 직군이 어디서 만났나요?

같은 색 하나를 두고 디자인·접근성·개발이 서로 다른 질문을 던진다고 앞서 말했죠. 그 질문과 결과를 한 표로 모았습니다. 위 두 위젯이 바로 이 분업의 산물입니다.

세 칸이 다 채워질 때만 '액센트 하나를 바꿔도 전체가 함께 움직이는' 시스템이 됩니다. 하나라도 빠지면 톤이 들쭉날쭉하거나, 예쁜데 안 읽히거나, 색이 코드 곳곳에 흩어집니다.

그리고 이 두 위젯은 무거운 색상 라이브러리 없이, 표준 기술만으로 돕니다. 구동 재료를 그대로 적어 둡니다.

대비 검사기는 WCAG 2.1 상대 명도 공식을 그대로 계산할 뿐, 어떤 외부 도구도 부르지 않습니다. 색을 '고르는 일'이 아니라 '시스템으로 묶는 일'로 만드는 게 이 표준 기술들의 역할입니다.

색을 이렇게 보는 사람들이, 사이트 전체를 만듭니다

색은 사이트에서 사용자가 가장 먼저 느끼는 인상입니다. 그 인상을 기준색 하나에서 체계로 키우고, 대비로 검증하고, 토큰으로 묶는 세 직군이 한 팀일 때 비로소 ‘바꿔도 무너지지 않는’ 컬러 시스템이 됩니다. Findable에서는 이런 합작이 기본값입니다. 당신의 사이트, 어떤 기준색에서 시작해볼까요?

이 글에 박힌 두 위젯과 컬러 시스템 방법론은, 각 직군이 따로 정리해 둔 실제 작업 노트에서 왔습니다. 더 깊게 보고 싶다면 원본을 펼쳐 보세요.

• 팔레트 생성 — 기준색 하나에서 틴트·셰이드 단계를 만드는 디자인 작업: 팔레트 생성기 노트
• 대비 검증 — WCAG 상대 명도 공식으로 합격 여부를 측정하는 접근성 작업: 색·대비 담당자의 노트
• 토큰화 — 라이트·다크를 한 토큰 체계로 조율하는 개발 작업: 라이트·다크 토큰 노트