컬러 피커

형식별 특징과 알맞은 쓰임

Hex와 rgb()는 같은 것을 다르게 쓴 것으로, 디스플레이가 구동하는 세 채널 값입니다. 정확하고 어디서나 통하지만, 어떤 색이 다른 색 옆에서 어떻게 보일지는 전혀 알려 주지 않습니다.

hsl()은 같은 정보를 색상, 채도, 명도로 재배열한 것으로 생각하기가 더 쉽습니다. 색상을 돌리고 나머지는 그대로 두면 되니까요. 그래서 CSS에서 팔레트를 만드는 기본 방식이 되었습니다. hsv()는 대부분의 그래픽 프로그램 색상 선택기가 쓰는 형제 격입니다.

아직 모른다면 배워 둘 만한 것이 oklch()입니다. cmyk()는 참고용으로 넣었으며 근사값으로 봐야 합니다. 실제 변환은 잉크, 용지, 출력 프로파일에 따라 달라지기 때문입니다. 여기의 값은 표준 산술 공식으로 계산한 것이라 대략적인 감을 잡는 데는 쓸모 있지만 인쇄소에 넘길 값은 아닙니다.

OKLCH가 다른 이유

HSL의 명도는 채널들의 기하학적 평균이지 색이 얼마나 밝아 보이는지를 재는 값이 아닙니다. 순수한 노랑과 순수한 파랑은 HSL에서 둘 다 명도 50%이지만, 눈에는 하나는 거의 흰색, 다른 하나는 거의 검은색으로 보입니다. 그래서 HSL 명도를 고정해 만든 팔레트는 모두 고르지 않게 나오고, 보기 좋아질 때까지 색마다 손으로 고치게 됩니다.

OKLCH는 지각적 색 공간인 Oklab을 바탕으로 하며, 수치상 같은 간격이 지각상으로도 대략 같은 차이에 대응합니다. 색상이 달라도 명도를 고정하면 정말로 같은 밝기로 보이고, 명도를 고르게 바꾸면 균일한 단계가 만들어집니다. 틴트와 셰이드를 만들고, 접근성을 갖춘 색 조합을 구성하고, RGB로 섞을 때 중간에 나타나는 탁한 회색 없이 두 색 사이를 보간하는 데 유용한 이유입니다.

주의할 점이 하나 있습니다. OKLCH는 sRGB 색역 밖의 색도 표현할 수 있으며, 그런 색은 일반 화면에서 잘려서 표시됩니다. 극단적인 명도에서 채도가 높을 때 나타나며, 서로 다른 두 OKLCH 값이 똑같은 색으로 보이는 결과로 드러납니다.

명암비 읽는 법

명암비는 WCAG 2 공식으로 계산합니다. sRGB 채널을 선형화해 각 색의 상대 휘도를 구한 뒤, 밝은 쪽에 0.05를 더한 값을 어두운 쪽에 0.05를 더한 값으로 나눕니다. 결과는 같은 두 색의 1:1부터 흰 바탕의 검정인 21:1까지입니다.

기준은 AA 등급에서 일반 본문 텍스트 4.5:1, 큰 텍스트(대략 24px, 굵게는 19px)와 인터페이스 요소 및 의미 있는 그래픽 3:1, AAA 등급 7:1입니다. 흰색과 검은색에 대한 비율을 모두 보여 주는 것은, 어느 쪽이 필요한지가 그 색을 무엇 위에 두느냐에 달려 있고, 흰색 위에서 기준에 못 미치는 색이 검은색 위에서는 넉넉히 통과하는 경우가 많기 때문입니다.

이 공식에는 알려진 약점이 있어서 숫자를 전부로 여기지 않는 것이 좋습니다. 어두운 배경의 밝은 글자에서 명암을 체계적으로 과대평가하므로, 서류상으로는 통과하지만 읽기 불편한 다크 테마가 생깁니다. 또한 큰 텍스트 기준 하나를 빼면 글꼴 굵기나 크기를 고려하지 않아, 통과한 아주 가는 글꼴도 여전히 읽기 힘들 수 있습니다. 후속 지표인 APCA가 두 문제를 모두 다루지만 아직 지침의 요구 사항은 아닙니다. 비율을 맞춘 다음, 직접 눈으로 보세요.

알파와 8자리 Hex

Hex는 알파를 네 번째 채널로 담을 수 있습니다. 전체 형식은 #RRGGBBAA, 짧은 형식은 #RGBA이며, 현재 모든 브라우저가 지원하고 여기서도 둘 다 받아들입니다.

여기에는 두 가지 함정이 있습니다. 첫째는 채널 순서입니다. Android를 비롯한 일부 플랫폼은 알파를 앞에 두어 #AARRGGBB로 쓰기 때문에, 그런 도구에서 복사한 값을 CSS에 붙이면 오류가 아니라 그럴듯하게 틀린 색이 나옵니다. 둘째는 알파가 16진수라서 불투명도 50%가 50이 아니라 80이라는 점입니다. 최신 rgb(0 0 0 / 50%) 문법을 쓰면 계산 자체가 필요 없고, 여섯 달 뒤에 다시 읽기도 쉽습니다.

색상 값이 실제로 설명하는 것

16진수 세 쌍은 색이 아니라 디스플레이에 보내는 지시입니다. #CC0000은 빨강 채널을 최대치의 80%로, 나머지는 0으로 구동하라는 뜻이며, 보는 사람이 무엇을 보게 될지는 패널과 그 보정 상태, 주변광, 그리고 그 숫자가 어떤 색 공간으로 해석되는지에 달려 있습니다.

따로 명시가 없으면 그 색 공간은 sRGB입니다. 1996년에 당시의 CRT 모니터를 기술하려고 표준화되었고, 웹에 모두가 공유할 수 있는 전제가 하나 필요했기에 그대로 굳었습니다. 요즘 휴대폰과 노트북 화면은 sRGB보다 넓은 범위를 표현하므로, Display P3로 태그된 이미지는 같은 숫자를 sRGB로 해석한 것보다 더 채도가 높아 보입니다.

숫자 속에 숨은 미묘한 점이 하나 더 있습니다. sRGB는 선형이 아닙니다. 값 128은 255의 절반 밝기가 아닌데, 인코딩에 감마 곡선이 들어 있어 사람 눈이 더 민감한 어두운 영역에 정밀도를 더 많이 배분하기 때문입니다. 그래서 두 16진수 값을 채널별로 평균하면 같은 색을 선형 공간에서 섞었을 때보다 탁한 결과가 나오고, 명암비 공식이 계산 전에 채널을 선형화하는 이유도 이것입니다.

한 가지 색에서 쓸 만한 팔레트 만들기

대부분의 인터페이스 팔레트는 몇 가지 색상을 각각 여러 명도 단계로 표현한 것입니다. 배경, 은은한 표면, 테두리, 흐린 본문색, 선명한 브랜드 색, 그리고 호버와 활성 상태를 위한 한두 단계의 짙은 색이죠. 색상 하나당 아홉에서 열한 단계가 흔히 선택되는 것은 하나의 정의로 라이트와 다크 테마를 모두 감당할 수 있기 때문입니다.

통하는 방법은 각 단계의 지각적 명도를 색상 전반에 걸쳐 고정하고 채도를 변화시키는 것입니다. 파랑의 500, 초록의 500, 빨강의 500은 페이지에서 같은 무게로 읽혀야 합니다. 어느 하나가 튀면 그 스케일은 쓰이는 모든 곳에서 균형이 어긋나 보입니다. OKLCH에서 이 작업을 하면 숫자가 일을 해 주고, HSL에서 하면 색마다 눈으로 보정하게 됩니다.

채도는 보통 양 끝에서 줄여야 합니다. 아주 밝거나 아주 어두운 색은 sRGB 색역 안에서 높은 채도를 유지하지 못하므로, 채도를 일정하게 둔 스케일은 양쪽 끝에서 잘려 인접한 두 단계가 똑같이 렌더링됩니다.

색만이 전달 수단은 아니다

남성의 약 12명 중 1명, 여성의 약 200명 중 1명이 어떤 형태의 색각 이상을 가지고 있으며, 가장 흔한 것은 빨강과 초록을 구별하기 어려운 경우입니다. 빨강과 초록만으로 만든 상태 표시는 그들에게 보이지 않고, 색상만으로 계열을 구분한 차트도 마찬가지입니다.

해법은 색을 피하는 것이 아니라 중복해서 알리는 것입니다. 색에 모양, 아이콘, 라벨, 위치를 함께 쓰세요. 느낌표 아이콘과 '오류'라는 단어가 붙은 빨간 메시지는 모두에게 통하고, 빨강만으로는 대부분에게만 통합니다. 차트에서는 범례보다 직접 라벨이 낫고, 색상뿐 아니라 명도까지 달리하면 페이지를 흑백으로 인쇄해도 계열을 구분할 수 있습니다.

명암비도 여기에 관련되며 확인 비용이 저렴합니다. 본문 텍스트 4.5:1, 인터페이스 요소 3:1이라는 기준은 소프트웨어를 조달하는 대부분의 조직과 접근성 감사가 사용하는 값입니다.

다크 테마는 반전이 아니다

모든 색을 뒤집으면 어딘가 잘못된 느낌의 다크 테마가 나오며, 이유는 대부분 지각에 있습니다. 어두운 배경의 밝은 글자는 번져 보이고 더 무겁게 읽혀서 같은 굵기라도 더 굵어 보입니다. 채도가 높은 색은 어두운 표면 위에서 떨립니다. 그리고 완전한 검정 위의 완전한 흰 글자는 헤일로 현상을 일으켜 본문을 읽기 피곤하게 만듭니다.

흔한 조정은 검정 대신 아주 어두운 회색을 쓰고, 강조색의 채도를 낮추며, 검정 위에서는 그림자가 보이지 않으므로 그림자 대신 더 밝은 표면으로 높낮이를 표현하고, 라이트 테마와 똑같이 맞추기보다 글자 굵기를 약간 낮추는 것입니다.

두 테마는 각각 따로 확인해야 합니다. 흰 배경에서 명암비를 통과한 색이 어두운 표면에서는 실패하는 일이, 그리고 그 반대의 일이 자주 일어납니다. 여기서 흰색과 검은색에 대한 비율을 함께 보여 주는 이유입니다.

CSS에서의 색, 그리고 정리하는 방법

요즘 CSS는 이 모든 형식을 그대로 받아들입니다. oklch()도, 알파를 슬래시로 쓰는 공백 구분 구문 rgb(0 0 0 / 50%)도 됩니다. 이 구문은 채택할 만합니다. 모호하지 않게 읽히고, 알파가 아무도 암산하지 못하는 16진수 두 자리가 아니라 백분율이기 때문입니다.

색을 정리하는 오래가는 방법은 사용자 정의 속성을 두 층으로 두는 것입니다. 첫 층은 팔레트를 문자 그대로 이름 짓습니다. --blue-500, --grey-900처럼요. 둘째 층은 역할을 이름 짓습니다. --color-text, --color-surface, --color-border, --color-accent처럼요. 컴포넌트는 역할만 참조하므로, 다크 테마는 역할 층을 다시 정의하는 일이 되고 모든 컴포넌트를 고치는 일이 아니게 됩니다.

비교적 새로운 두 기능이 가능성을 바꿉니다. color-mix()는 지정한 색 공간에서 두 색을 정해진 비율로 섞으므로, 호버 상태를 손으로 고르지 않고 기준색에서 파생할 수 있습니다. 그리고 상대 색 구문은 기존 값의 한 채널만 조정해 변형을 만들게 해 주어, 스케일이 파생된 색과 계속 맞물려 있게 합니다. 둘 다 현재 브라우저에서 지원되며, 둘 다 HSL보다 OKLCH에서 훨씬 다루기 쉽습니다.