Chapter 03

색을 숫자로

"조금 더 밝은 초록으로 해 주세요." 이 부탁을 받은 사람이 열 명이면 초록도 열 가지가 나온다. 그래서 디지털 도구는 색을 숫자로 적는다. 그런데 숫자에도 여러 방언이 있다. 같은 초록이 #2f7d5b이기도 하고, hsl(154 45% 34%)이기도 하고, oklch(53.2% 0.094 162)이기도 하다. 어떤 방언은 화면이 빛을 내는 방식에 맞춰져 있고, 어떤 방언은 사람이 색을 느끼는 방식에 맞춰져 있다. 이 장은 그 차이가 실제 작업에서 어떤 결과를 내는지 본다.

RGB와 hex가 화면의 빨강·초록·파랑 빛의 세기를 적은 것임을 안다.
화면의 숫자가 빛의 양에 비례하지 않는다는 것(감마)과, 그래서 "숫자의 평균"과 "빛의 평균"이 다르다는 것을 확인한다.
HSL로 만든 명도 단계가 고르지 않고 색상까지 흔들리는 이유를 본다.
CIELAB과 OKLCH 같은 지각 균일 색 공간에서 색을 고르고 단계를 만든다.
색역의 뜻과 sRGB·Display P3의 차이를 알고, 같은 숫자가 화면마다 다르게 보이는 이유를 설명한다.

이름 대신 숫자

2장에서 본 것처럼 눈은 빛을 세 개의 숫자로 줄여서 본다. 그러니 색을 적는 데도 숫자 세 개면 충분하다. 문제는 어떤 세 숫자를 쓰느냐다. 가장 흔한 것은 화면이 내는 빨강(R)·초록(G)·파랑(B) 빛의 세기를 그대로 적는 RGB(Red, Green, Blue)다. 각 값은 0~255의 정수로 적고, 웹과 디자인 도구는 이를 16진수 두 자리씩 붙인 hex 코드(Hex code)로 쓴다.

그림 1. hex 코드 읽기. #2f7d5b는 빨강 47, 초록 125, 파랑 91을 뜻한다. 1장에서 서윤이 고른 로고 초록 후보다. 숫자 세 개가 각각 화면의 빨강·초록·파랑 화소를 얼마나 켤지를 정한다.

RGB의 세 값을 세 축으로 놓으면 모든 화면 색은 한 변이 255인 정육면체 안에 들어간다. 한 모서리는 검정, 맞은편 모서리는 흰색이고, 나머지 여섯 모서리가 빨강·초록·파랑과 그 둘씩의 섞임(노랑·청록·마젠타)이다. 아래는 파랑 값을 하나로 정하고 그 정육면체를 자른 단면이다. 손잡이를 끌어 색을 고르고, 슬라이더로 단면의 높이를 바꾼다.

SIMULATOR

RGB 정육면체의 한 단면

단면 위를 끈다

파랑 B 같은 명도(L*)끼리 선으로 잇기

hex · RGB—

사람이 느끼는 명도 L*—

해볼 것: ① 손잡이를 단면 위에서 움직여 #2f7d5b(빨강 47, 초록 125)를 찾는다. ② "같은 명도끼리 선으로 잇기"를 켠다. 같은 밝기로 느껴지는 색들을 이은 선이 축과 나란하지 않고 비스듬하며, 초록 쪽으로 기울어 있다. 초록 값 10을 올리는 것은 빨강 값 10을 올리는 것보다 훨씬 밝아지고, 파랑 10은 거의 표가 나지 않는다. ③ 파랑을 0과 255로 끝까지 민다. 파랑 값이 255나 바뀌는 동안 명도 L*는 생각보다 적게 변한다. 숫자 하나하나가 사람의 감각에 대응하지 않는다는 뜻이다. (L*는 CIELAB 명도, 0 = 검정, 100 = 흰색. 화면 색은 기기마다 다르므로 같은 값이라도 기기에 따라 조금씩 다르게 보인다.)

RGB는 화면에 일을 시키기에는 완벽한 숫자다. 화면은 정확히 그 세 빛을 켜는 기계이기 때문이다. 그러나 사람에게 묻는 질문, "이 색은 얼마나 밝은가", "얼마나 선명한가", "무슨 색 계열인가"에는 RGB의 세 숫자 중 어느 것도 직접 대답하지 않는다. 이 장의 나머지는 그 질문에 대답하는 숫자를 찾아가는 길이다. 그 전에 RGB 숫자에 숨은 함정 하나를 먼저 본다.

화면의 숫자는 빛의 양이 아니다

RGB 값 128은 255의 거의 절반이다. 그렇다면 128로 칠한 회색은 흰색의 절반만큼 빛을 낼까. 그렇지 않다. 화면은 숫자를 그대로 빛으로 바꾸지 않고, 정해진 곡선을 거쳐 바꾼다. 128은 흰색의 약 22%의 빛만 낸다. 이 곡선을 감마(Gamma, 전달 함수)라고 부른다. 웹과 대부분의 화면이 따르는 sRGB 표준(IEC 61966-2-1)의 곡선은 다음과 같다.

$$C_{\text{빛}}=\left(\frac{C+0.055}{1.055}\right)^{2.4}$$

$C$: 0~1로 적은 화면 값(255로 나눈 값), $C_{\text{빛}}$: 실제로 나오는 빛의 상대적인 양. 이 식은 $C>0.04045$에서 쓰고, 아주 어두운 구간($C\le 0.04045$)은 $C/12.92$로 곧게 이어진다. 128/255 = 0.502를 넣으면 약 0.216이 된다.

왜 이렇게 했을까. 사람의 눈은 어두운 쪽의 작은 차이에 훨씬 민감하다. 빛의 양을 그대로 0~255로 나누면 어두운 쪽 계단이 눈에 띄게 거칠고 밝은 쪽 계단은 낭비된다. 감마 곡선은 숫자를 어두운 쪽에 더 촘촘히 배정해서, 255단계로 사람 눈에 고르게 보이는 계단을 만든다. 숫자는 대략 "느끼는 밝기"에 가깝게, 빛은 그 곡선을 거쳐 나온다. 직접 확인해 본다. 왼쪽은 검정과 흰색 줄을 한 줄씩 번갈아 그은 칸이고, 오른쪽은 한 가지 회색이다. 줄무늬 칸은 정확히 흰빛의 50%를 낸다.

SIMULATOR

줄무늬의 회색은 몇일까

오른쪽 칸의 화면 값 숫자로 반(128)인 칸도 보기

오른쪽 칸이 내는 빛—

줄무늬가 내는 빛50%

해볼 것: ① 화면에서 한두 걸음 물러나거나 눈을 가늘게 떠서 줄무늬가 한 덩어리 회색으로 보이게 한다. 기본값 128은 줄무늬보다 확실히 어둡다. ② 슬라이더를 올려 오른쪽 칸이 줄무늬와 같아 보이는 값을 찾는다. 잘 맞춘 sRGB 화면이라면 188 근처다. 188은 빛으로 50%다. ③ 값이 188에서 많이 벗어난 곳에서 맞는다면, 그 화면의 감마가 표준과 다르거나 화면 배율 때문에 줄무늬가 뭉개진 것이다. (브라우저 확대·축소를 100%로 두고 본다. 1장의 "내 화면 점검"과 마찬가지로 이것은 대략의 확인이다.)

이 차이는 색을 섞을 때 문제가 된다. 사진을 줄이거나 흐리게 할 때, 점묘화를 멀리서 볼 때, 빛은 빛의 양끼리 섞인다. 그런데 프로그램이 화면 숫자를 그대로 평균하면 실제보다 어둡고 탁한 결과가 나온다. 1장의 점묘 시뮬레이터에서 "숫자를 그대로 평균"을 켰을 때 본 그 현상이다. 반대로 "보기에 고른 그라데이션"을 만들 때는 빛의 평균이 오히려 밝은 쪽으로 치우친다. 두 색 사이를 잇는 방법이 여러 가지라는 뜻이다.

아래는 같은 두 색을 네 가지 방법으로 이은 띠다. "숫자 평균"은 RGB 숫자를 그대로 섞고, "빛 평균"은 감마를 풀어 빛의 양으로 섞고, "OKLab"과 "OKLCH"는 다음 절들에서 만날 지각 균일 공간에서 섞는다. 아래 그래프는 띠를 따라가며 잰 명도 L*다.

SIMULATOR

두 색 사이의 네 갈래 길

살펴볼 지점

숫자 평균—

빛 평균—

OKLab—

OKLCH—

해볼 것: ① 빨강–초록의 가운데를 본다. 숫자 평균은 탁한 갈색(L* 약 46)으로 가라앉고, 빛 평균과 OKLab은 더 밝은 황토색, OKLCH는 색상환을 돌아가며 주황과 황록을 지나 선명함을 지킨다. ② 파랑–노랑으로 바꾼다. 숫자 평균과 OKLab은 가운데가 회색으로 꺼진다. 두 색이 서로 보색에 가까워 직선으로 이으면 회색 근처를 지나기 때문이다. OKLCH는 청록과 초록 쪽으로 돌아간다. ③ 검정–흰색에서 명도 그래프를 본다. 빛 평균은 밝은 쪽으로 크게 휘고(가운데 L* 76), 숫자 평균은 거의 곧다. 감마가 숫자를 대략 "느끼는 밝기"에 맞춰 두었기 때문이다. 섞는 방법에 정답은 없다. 빛이 실제로 섞이는 일(흐림, 축소, 점묘)은 빛 평균이, 눈에 고른 단계는 지각 공간이 맞다. (OKLCH의 색상은 짧은 쪽 호로 돌아간다. 색역 밖으로 나가면 채도를 줄여 화면 안으로 넣었다.)

그라데이션이 회색으로 꺼질 때 디자인 도구나 CSS의 그라데이션은 오랫동안 숫자 평균(sRGB)으로 그려졌다. 파랑에서 노랑으로 가는 배경이 가운데에서 회색 띠를 만드는 것이 그 때문이다. 해결은 두 가지다. 가운데에 원하는 색(예: 청록 또는 연두)을 하나 더 넣어 길을 정해 주거나, 섞는 공간을 바꾼다. CSS Color 4는 linear-gradient(in oklch, …)처럼 섞는 공간을 지정하는 문법을 정의했고, 최신 브라우저가 지원한다. 화가의 습관과도 같다. 수채화에서 보색 두 색을 번지기로 이으면 가운데가 탁해지므로, 화가들은 이웃한 색을 거쳐 가도록 중간 색을 따로 칠한다.

HSL: 편리하지만 고르지 않은 원통

RGB로는 "조금 더 밝게"를 말하기 어렵다. 그래서 1978년 앨비 레이 스미스(Alvy Ray Smith)는 RGB 정육면체를 원통 모양으로 다시 배치한 HSV를 발표했고, 비슷한 HSL도 널리 쓰이게 되었다. HSL(Hue, Saturation, Lightness)은 색상 H(색상환 위의 각도, 0~360°), 채도 S(0~100%), 명도 L(0~100%)로 색을 적는다. 디자인 도구의 색 선택기에서 흔히 보는 HSB·HSV도 같은 집안이다. 이름만 보면 사람의 언어와 꼭 맞는다.

1장에서 HSL 명도 50%의 열두 색이 실제로는 L* 30에서 97까지 벌어지는 것을 봤다. 이번에는 한 색상 안에서 명도 단계를 만들어 본다. 버튼, 배경, 테두리, 글자처럼 같은 계열의 색을 여러 밝기로 쓰는 일은 UI 디자인에서 매일 한다. 윗줄은 HSL의 L을 같은 간격으로 올린 단계, 아랫줄은 같은 두 끝 사이를 OKLCH의 명도로 같은 간격으로 나눈 단계다. 칸 아래 막대는 이웃한 두 칸의 명도(L*) 차이다.

SIMULATOR

HSL 계단과 OKLCH 계단

단계 수

HSL 계단의 명도 간격 L*—

OKLCH 계단의 명도 간격 L*—

HSL 계단의 색상 흔들림—

해볼 것: ① 책방 초록에서 윗줄 막대를 본다. 어두운 쪽 계단은 L* 13~15씩 크게 뛰고 밝은 쪽은 6~7씩 촘촘하다. 밝은 쪽 칸들이 서로 비슷해 보이는 이유다. 아랫줄은 막대 높이가 고르다. ② 오른쪽 위 "흑백"을 눌러 명도만 남겨 본다. 윗줄의 회색 계단이 고르지 않은 것이 더 잘 보인다. ③ 노랑으로 바꾼다. 어두운 쪽 간격은 15~16, 밝은 쪽은 5로 고르지 않음이 더 심하고, 어두운 칸은 노랑이 아니라 올리브빛 갈색이 된다. 파랑과 보라는 간격이 비교적 고르다. HSL의 고르지 않음은 색상마다 정도가 달라서, 한 색에서 맞춘 규칙을 다른 색에 그대로 쓸 수 없다. 책방 초록은 밝은 칸으로 갈수록 색상이 6°쯤 푸르게 기운다("색상 흔들림"). HSL은 색상 숫자를 고정해도 사람이 느끼는 색상까지 고정해 주지는 않는다. (OKLCH 계단은 기준색의 색상과 채도를 지키되, 그 명도에서 화면이 낼 수 없는 채도는 낼 수 있는 만큼으로 줄였다.)

HSL이 고르지 않은 이유는 간단하다. HSL의 L은 RGB 세 값 중 가장 큰 값과 가장 작은 값의 평균일 뿐이다. 감마로 인코딩된 숫자의 평균이고, 초록이 파랑보다 훨씬 밝게 느껴진다는 사실(2장의 $\bar y$ 곡선)을 전혀 모른다. HSL은 RGB를 사람이 다루기 쉽게 배치한 좌표이지, 사람의 감각을 잰 좌표가 아니다. 빠르게 색을 고를 때는 충분히 편리하다. 문제는 그 숫자로 "같은 간격"이나 "같은 밝기"를 만들려 할 때 생긴다.

눈으로 만드는 회색 9단계 흰 종이에 엄지손톱만 한 칸 아홉 개를 그린다. 한쪽 끝은 종이의 흰색 그대로, 다른 쪽 끝은 검정 물감(또는 4B 연필로 가장 진하게)으로 칠한다. 그 사이 일곱 칸을 이웃한 칸과의 차이가 모두 "같아 보이도록" 칠한다. 수채라면 물을 섞는 양으로, 연필이라면 누르는 힘과 겹치는 횟수로 조절한다. 다 칠한 뒤 한 걸음 물러서서, 차이가 큰 곳과 작은 곳을 다시 고친다. 이렇게 눈으로 맞춘 계단을 이 장의 "흑백" 단추로 본 OKLCH 계단과 HSL 계단 옆에 놓아 본다. 대체로 OKLCH 쪽과 비슷하다. 화면 색은 기기마다 다르므로 비교는 대략으로만 한다.

눈에 맞춘 공간: Lab과 OKLCH

"숫자의 차이가 눈으로 느끼는 차이와 비슷하도록" 만든 색 공간을 지각 균일 색 공간(Perceptually uniform color space)이라고 한다. 이 생각을 처음 체계로 만든 사람은 공학자가 아니라 화가였다. 미국의 화가이자 미술 교사 앨버트 먼셀(Albert H. Munsell, 1858–1918)은 색상·명도·채도의 세 축을 정하고, 이웃한 견본끼리의 차이가 눈으로 보기에 같아지도록 색표를 만들었다(1905년 『색 표기법』(A Color Notation)). 먼셀 표기법은 지금도 토양·식품 색 판정과 여러 나라의 산업 표준에 쓰인다.

국제조명위원회는 1976년 계산으로 구할 수 있는 지각 균일 공간 CIELAB(L*a*b*)을 정했다. L*는 명도(0~100), a*는 초록(−)에서 빨강(+)으로, b*는 파랑(−)에서 노랑(+)으로 가는 축이다. 2장 끝에서 본 반대색 신호(밝기, 빨강–초록, 노랑–파랑)와 같은 짜임이다. 이것을 원통 좌표로 바꾼 것이 LCh다. 2020년 비에른 오토손(Björn Ottosson)은 같은 짜임으로 색상이 더 고르게 유지되도록 다시 맞춘 OKLab과 그 원통 좌표 OKLCH를 발표했고, CSS Color 4가 이를 oklch() 함수로 받아들였다.

그림 2. OKLCH의 세 숫자. 세로축 L은 명도, 가운데 회색 축에서 바깥으로의 거리 C는 채도, 둘레의 각도 h는 색상이다. 가로 두 축 a(초록–빨강)와 b(파랑–노랑)는 2장의 반대색 신호와 같은 짜임이다. HSL과 모양은 비슷하지만, 같은 L이면 실제로 같은 밝기로 보이고 같은 h면 같은 색 계열로 보이도록 맞춘 것이 다르다. 실제 색 공간은 원통이 아니라 울퉁불퉁한 덩어리이고, 화면이 낼 수 있는 부분은 그 안의 일부다.

OKLCH의 C와 h는 OKLab의 두 가로축 a, b에서 바로 나온다.

$$C=\sqrt{a^2+b^2},\qquad h=\operatorname{atan2}(b,\,a)$$

$a, b$: OKLab의 두 반대색 축. $C$는 회색 축에서의 거리(채도), $h$는 그 방향의 각도(색상, 0~360°). 로고 초록 #2f7d5b는 OKLab으로 $L=0.532,\ a=-0.089,\ b=0.030$이고, OKLCH로 $L=0.532,\ C=0.094,\ h=162°$다.

OKLCH의 장점은 세 숫자가 서로 간섭하지 않는다는 데 있다. 명도만 바꾸면 색상이 따라 흔들리지 않고, 색상만 바꾸면 밝기가 따라 출렁이지 않는다(완벽하지는 않지만 HSL보다 훨씬 낫다). 아래 그림은 한 색상(h)에서 OKLCH 공간을 세로로 자른 단면이다. 세로가 명도 L, 가로가 채도 C다. 빗금 친 곳은 화면(sRGB)이 낼 수 없는 색이다. 손잡이를 끌어 색을 고르고, 슬라이더로 색상을 돌린다.

SIMULATOR

OKLCH 단면에서 고르기

단면 위를 끈다

색상 h

CSS 표기—

화면에 칠한 색—

색역—

해볼 것: ① 손잡이를 위아래로만 움직인다. 명도만 바뀌고 색 계열은 그대로다. 오른쪽 경계(화면이 낼 수 있는 가장 선명한 색)가 명도마다 다르다는 것도 본다. 초록(162°)은 중간보다 조금 밝은 곳에서 가장 멀리 나간다. ② 색상을 90°(노랑)와 265°(파랑)로 돌려 경계의 모양을 비교한다. 노랑은 밝은 쪽에서만 선명하고, 파랑은 어두운 쪽에서만 선명하다. 노랑 글자가 흰 종이에서 안 읽히는 이유가 이 모양에 있다. ③ 손잡이를 빗금 영역 깊숙이 끌고 "채널 자르기"로 바꾼다. RGB 값을 0~255로 잘라 버리면 색상까지 틀어진다(Δh 표시). "채도 줄이기"는 명도와 색상을 지키며 경계까지 채도만 줄인다. 이 책이 색역 밖의 색을 보여 줄 때 쓰는 방법이다(CSS Color 4의 색역 매핑 방식).

지각 균일 공간도 완벽하지 않다 CIELAB은 1976년의 타협이다. 데이비드 맥아담(David MacAdam)이 1942년에 보인 것처럼, 사람이 구별하지 못하는 색의 범위는 색도도 위에서 장소마다 크기와 방향이 다른 타원이다. CIELAB은 이 차이를 많이 줄였지만 다 없애지는 못했다. 특히 파랑 근처에서 채도만 줄였는데 보랏빛으로 보이는 문제가 알려져 있다. 그래서 색차 공식도 CIE76(Lab 공간의 직선거리)에서 CIEDE2000으로 다듬어졌고, 이 책의 엔진은 색차를 CIEDE2000으로 잰다. OKLab은 파랑의 색상 문제를 크게 줄였지만, 명도 L의 눈금이 CIELAB의 L*와 조금 달라 중간 회색이 L*보다 어둡게 나온다(오토손은 이를 보정한 명도도 따로 제안했다). 어느 공간이든 "사람 눈의 평균을 흉내 낸 모형"이다. 마지막 판단은 언제나 실제로 놓일 자리에서 눈으로 한다.

색역: 화면이 낼 수 있는 색

앞의 단면에서 빗금 친 영역은 사람이 볼 수 있지만 화면이 낼 수 없는 색이다. 화면이 낼 수 있는 색의 범위를 색역(Gamut)이라고 한다. 색역은 화면의 세 원색(가장 선명한 빨강·초록·파랑 화소)이 정한다. 세 원색을 섞어서 만들 수 있는 색만 낼 수 있기 때문이다. 2장의 색 맞추기에서 청록 단색광을 세 빛으로 맞출 수 없었던 것과 같은 이유다.

색역을 한눈에 비교하려고 국제조명위원회의 xy 색도도(Chromaticity diagram)를 쓴다. 밝기를 빼고 "어떤 색인가"만 평면에 펼친 지도다. 말굽 모양의 바깥 테두리는 2장의 단색광들이 놓이는 자리이고, 사람이 볼 수 있는 모든 색은 그 안에 있다. 화면의 색역은 세 원색을 꼭짓점으로 하는 삼각형이 된다. 웹의 표준인 sRGB와, 요즘 휴대폰·노트북에 많이 쓰이는 더 넓은 Display P3를 비교한다.

SIMULATOR

sRGB 삼각형과 P3 삼각형

점을 끈다

Display P3 삼각형 로고 초록이 P3 화면에서 잘못 읽히면

고른 점 (x, y)—

sRGB로 낼 수 있나—

P3로 낼 수 있나—

해볼 것: ① 점을 초록 꼭짓점 근처로 끈다. sRGB 삼각형 밖이지만 P3 삼각형 안인 띠가 있다. 휴대폰 화면이 노트북보다 초록과 빨강을 더 선명하게 낼 수 있는 영역이다. 이 책의 계산으로 xy 평면 위 P3 삼각형의 넓이는 sRGB의 약 1.36배다. ② 점을 말굽의 왼쪽 위 테두리(청록·초록 단색광)까지 끈다. 두 삼각형 모두 밖이다. 어떤 화면도 단색광처럼 선명한 청록은 내지 못한다. ③ "로고 초록이 P3 화면에서 잘못 읽히면"을 켠다. 같은 숫자 #2f7d5b를 P3의 원색으로 해석하면 점이 테두리 쪽으로 밀려난다. 1장에서 휴대폰 화면의 초록이 더 선명하게 보였던 한 가지 설명이다. (말굽 안의 색은 화면이 낼 수 있는 범위로 줄여 그린 것이라 실제 색보다 탁하다. 테두리는 이 책의 엔진이 쓰는 CIE 1931 등색 함수 근사로 그렸다.)

휴대폰이 더 선명하게 보인 이유를 정리하면 이렇다. 파일에 적힌 #2f7d5b는 "sRGB의 원색으로 빨강 47, 초록 125, 파랑 91"이라는 뜻이다. 색 관리가 제대로 되는 프로그램은 P3 화면에 보내기 전에 이 값을 P3의 숫자(약 69, 123, 93)로 바꿔서 같은 색을 낸다. 그런데 색 관리가 빠진 경로(색 정보가 없는 이미지, 일부 앱이나 설정)에서는 47, 125, 91을 그대로 P3 화소에 보낸다. P3의 초록 화소는 sRGB의 초록보다 선명하므로 같은 숫자가 더 선명한 색이 된다. 이 책의 모델로 계산하면 채도가 0.094에서 0.120으로 약 28% 올라가고, 색상이 162°에서 165°로 조금 푸르게 옮겨 간다. 서윤이 본 "더 선명하고 푸르게"와 같은 방향이다.

그림 3. 같은 숫자, 두 갈래 길. 숫자 세 개는 "어느 원색으로" 읽느냐에 따라 다른 색이 된다. 색 관리는 파일이 쓰인 색 공간(sRGB)과 화면의 색 공간(P3)을 비교해 숫자를 바꿔 주는 일이다. 그 일이 빠지면 넓은 색역의 화면은 같은 숫자를 더 선명하게 보여 준다. 아래 칸은 OKLCH 채도 0.120의 색을 sRGB 화면이 낼 수 있는 만큼으로 줄여 그린 것이라 실제 P3 화면의 색보다 덜 선명하다. 색 관리 전반은 15장에서 다룬다.

지금 보고 있는 화면이 P3를 낼 수 있는지 바로 확인할 수 있다. 아래 두 칸은 CSS로 칠했다. 왼쪽은 sRGB가 낼 수 있는 가장 선명한 초록(#00ff00), 오른쪽은 P3의 가장 선명한 초록(color(display-p3 0 1 0))이다. P3 화면에서는 오른쪽이 확실히 더 진하고 형광에 가깝다. sRGB 화면에서는 브라우저가 오른쪽을 낼 수 있는 만큼으로 줄여서 두 칸이 같아 보인다.

sRGB 가장 선명한 초록#00ff00 P3 가장 선명한 초록display-p3 0 1 0 sRGB 가장 선명한 빨강#ff0000 P3 가장 선명한 빨강display-p3 1 0 0

넓은 색역은 "더 좋은 색"이 아니다 화면 색은 기기마다 다르다. 넓은 색역의 화면은 낼 수 있는 색이 많을 뿐, 같은 파일을 더 정확하게 보여 주는 것은 아니다. 색 관리가 빠지면 오히려 모든 색이 실제보다 과장되어 보인다. 브랜드 색을 P3 화면에서만 낼 수 있는 값으로 정하면, sRGB 화면과 대부분의 인쇄에서는 그 색을 낼 수 없어 결국 다른 색으로 바뀐다. 색역 밖의 색을 어떻게 다룰지는 15장에서 인쇄와 함께 다시 본다.

숫자로 일하기

그렇다면 어떤 숫자를 써야 할까. 이 책의 권장은 역할을 나누는 것이다. 기록과 설계는 OKLCH로 한다. 명도 단계, 채도 조절, 색상 돌리기가 모두 한 숫자만 바꾸면 되고, 그 결과가 눈의 감각과 비슷하다. 전달과 실행은 그 숫자에서 파생한 hex나 RGB로 한다. 많은 도구와 인쇄소가 아직 hex를 기준으로 일하기 때문이다. 그리고 섞기, 흐리게 하기, 이미지 줄이기처럼 빛이 실제로 합쳐지는 계산은 감마를 푼 선형 빛으로 한다.

숫자	잘하는 일	조심할 일
hex · RGB	화면에 정확히 무엇을 켤지 전달. 도구 사이에 값 옮기기	밝기·채도를 숫자로 조절하기 어렵다. 숫자 평균은 빛의 평균이 아니다
HSL · HSV	색상환에서 빠르게 고르기	같은 L이 같은 밝기가 아니다. 명도 단계가 고르지 않고 색상이 흔들린다
CIELAB · LCh	색차 재기(ΔE), 인쇄·측색 분야의 표준 언어	파랑 근처의 색상 왜곡. 백색점을 함께 적어야 한다
OKLCH	단계·팔레트 설계, 브랜드 색 기록. CSS에서 바로 쓴다	색역 밖 값을 쉽게 만든다. 실제로 낼 수 있는지 함께 확인한다
선형 RGB	빛 섞기, 흐림, 이미지 축소, 3D 조명 계산	사람이 읽고 고르기에는 맞지 않는다

색 하나를 세 줄로 기록한다 색을 기록할 때 디자이너들이 흔히 쓰는 형식은 이렇다. 첫 줄에 설계 값(예: oklch(53.2% 0.094 162)), 둘째 줄에 파생 값(#2f7d5b, 필요하면 인쇄용 값), 셋째 줄에 확인 조건(어느 화면, 어느 조명, 무엇 옆에서 봤는지). 1장에서 서윤이 정한 "값과 놓일 자리·옆의 색·조명을 함께 적는다"는 원칙을 숫자의 형식으로 옮긴 것이다. 값을 바꿀 때는 설계 값을 고치고 파생 값을 다시 계산한다. 반대로 hex만 손으로 조금씩 고치다 보면, 어느 것이 원래 의도였는지 잃어버리기 쉽다.

색 일지의 색에 숫자 붙이기 1장에서 시작한 색 일지에서 색 다섯 개를 고른다. 각 색 옆에 먼저 눈으로 OKLCH 세 숫자를 짐작해 적는다. 명도는 0(검정)~1(흰색), 채도는 0(회색)~0.3(아주 선명), 색상은 0°(분홍빛 빨강)·90°(노랑)·150°(초록)·250°(파랑)를 기준으로 어림한다. 그다음 이 장 마지막 시뮬레이터에서 슬라이더를 움직여 화면의 색을 일지의 색과 나란히 맞춰 보고, 실제 숫자를 옆에 적는다. 짐작과 가장 많이 어긋난 숫자가 무엇인지 본다. 대부분의 사람은 명도는 잘 맞히고 채도를 크게 틀린다. 화면 색은 기기마다 다르므로 맞춘 값은 "이 화면에서"의 값이라고 함께 적는다.

색 하나를 기록하는 카드

마지막 시뮬레이터는 이 장의 도구를 한 장의 카드에 모은다. 세 슬라이더는 OKLCH의 세 숫자다. 카드는 그 색을 여러 방언(hex, HSL, CIELAB, Display P3)으로 옮겨 적고, 흰 웹 배경·크라프트지 간판·검은 에코백 위에 놓아 보고, 같은 색상의 명도 단계를 만들고, sRGB와 P3에서 낼 수 있는 채도의 한계를 보여 준다. 기본값은 서윤의 로고 초록 후보다.

SIMULATOR

로고 초록 기록 카드

명도 L 채도 C 색상 h

CSS oklch()로 직접 칠한 칸. P3 화면이면 sRGB 밖의 색도 그대로 보인다.

설계 값 (CSS)—

파생 값 hex · HSL—

CIELAB—

Display P3—

해볼 것: ① 기본값에서 명도만 0.50과 0.60 사이로 움직인다. 흰 바탕 대비가 본문 글자 기준 4.5를 넘나드는 경계가 0.56 근처다. 색 계열은 그대로이고 단계 줄의 표시만 옮겨 간다. ② 채도를 0.15까지 올린다. 채도 막대의 sRGB 한계(약 0.117)를 넘는 순간 hex는 더 이상 같은 색을 적지 못하고(카드에 "sRGB 밖" 표시), P3 한계(약 0.160)까지는 P3 값으로만 적을 수 있다. CSS 칸은 P3 화면에서 더 선명해지고 sRGB 화면에서는 멈춘다. ③ 채도를 0.3까지 끝까지 민다. P3도 넘어선다. 숫자로는 적을 수 있지만 어떤 화면도 내지 못하는 색이다. 색을 숫자로 적을 수 있다고 그 색이 있는 것은 아니다. (대비는 WCAG 2 공식, Display P3 변환은 CSS Color 4의 행렬, 색역 밖의 색은 명도와 색상을 지키며 채도를 줄여 그렸다. 크라프트지와 에코백의 색은 이 책이 정한 예시 값이다.)

같은 색이 다섯 가지 방언으로 적혔다. 그중 어느 것도 틀리지 않았다. 다만 OKLCH의 세 숫자만이 "조금 더 밝게", "조금 덜 선명하게", "조금 더 푸르게"라는 사람의 말에 한 숫자씩 대응한다. 1장의 질문 "조금 더 밝은 초록으로 해 주세요"는 이제 "L을 0.05 올려 주세요"가 된다.

서윤의 작업 노트

CASE 서윤작업 노트 · 3장

고르게 올렸는데 고르게 밝아지지 않았다

서윤은 책방 E 웹사이트의 초록 단계를 HSL로 만들었다. 로고 초록 #2f7d5b는 HSL로 색상 154°, 채도 45%, 명도 34%다. 색상과 채도는 그대로 두고 명도만 15%에서 95%까지 10%씩 올려 아홉 단계를 만들었다. 숫자로는 완벽하게 고른 계단이었다. 그런데 화면에 놓고 보니 어두운 세 칸은 서로 너무 달랐고, 밝은 네 칸(테두리·배경용)은 서로 거의 구별되지 않았다. 밝은 칸일수록 초록이 아니라 민트색으로 푸르게 기울었다.

이 책의 모델로 재 보니 HSL 계단의 명도(L*)는 20.5, 35.1, 48.7, 61.7, 70.9, 77.0, 83.4, 90.0, 96.6이었다. 이웃 간격이 어두운 쪽에서는 14.6, 밝은 쪽에서는 6.4~6.6으로 두 배 넘게 차이가 났고, OKLCH 색상은 161°에서 168°까지 흔들렸다. 서윤은 같은 아홉 단계를 OKLCH로 다시 만들었다. 색상 162°를 고정하고 명도를 0.30에서 0.96까지 같은 간격으로 나누고, 채도는 0.094를 넘지 않되 그 명도에서 낼 수 있는 만큼만 쓰게 했다. 새 계단의 L* 간격은 9.1~9.8로 고르다.

한도경은 서윤의 화면을 보더니 자기 색 일지의 한 쪽을 펼쳤다. 젊을 때 물감으로 칠한 회색 9단계였다. "나는 이걸 눈으로 맞췄어. 숫자로 고른 너의 첫 번째 계단보다, 다시 만든 계단이랑 더 비슷하네." 서윤은 먼셀이 화가였다는 이야기를 해 주었고, 도경은 그 대가로 서윤에게 휴대폰 사진을 흑백으로 바꿔 계단을 확인하는 법을 배웠다. 마지막으로 서윤은 1장의 수수께끼 하나를 풀었다. 휴대폰 화면은 Display P3였고, 같은 숫자를 색 관리 없이 P3로 읽으면 채도가 0.094에서 0.120으로 올라간다. 휴대폰의 "더 선명한 초록"은 다른 색이 아니라 다른 방언으로 읽힌 같은 숫자였다.

이 장에서 정한 것브랜드 색은 OKLCH로 기록하고 hex는 파생값으로 둔다. 로고 초록 후보의 기록: 설계 값 oklch(53.2% 0.094 162), 파생 값 #2f7d5b(sRGB 안), L* 47.0, 흰 바탕 대비 4.99. 웹의 초록 단계는 OKLCH 명도 0.30~0.96, 색상 162°의 아홉 단계로 다시 만든다.

아직 남은 문제이 초록이 크라프트지 간판(대비 약 2.2)과 검은 에코백(약 3.4) 위에서는 숫자상 대비가 낮다. 인쇄 잉크로는 이 숫자를 어떻게 낼 것인가. 수채화의 색은 어떤 숫자로 생각해야 하는가.

다음 단계4장: 화면의 숫자에서 물감으로 건너간다. 도경의 조언으로 수채화 세 점의 제한 팔레트를 고른다.

핵심 정리

RGB와 hex는 화면의 빨강·초록·파랑 빛을 얼마나 켤지 적은 숫자다. 화면에 일을 시키기에는 정확하지만, 밝기·선명함·색 계열을 직접 말해 주지 않는다.
화면 숫자는 감마 곡선을 거쳐 빛이 된다. 128은 흰빛의 약 22%, 빛의 절반은 188이다. 빛이 실제로 섞이는 계산(흐림, 축소, 점묘)은 감마를 푼 선형 빛으로 한다.
HSL은 RGB를 원통으로 배치한 것이다. 같은 L이 같은 밝기가 아니고, L을 같은 간격으로 올려도 명도 단계가 고르지 않으며 색상이 흔들린다.
CIELAB과 OKLCH는 숫자의 차이가 눈의 차이와 비슷하도록 만든 지각 균일 공간이다. OKLCH의 L·C·h는 명도·채도·색상에 하나씩 대응한다.
색역은 화면의 세 원색이 정하는 범위다. Display P3는 sRGB보다 넓어서, 색 관리가 빠지면 같은 숫자가 더 선명하게 보인다.
숫자로 적을 수 있는 색이 모두 화면에 있는 것은 아니다. 색역 밖의 색은 명도와 색상을 지키며 채도를 줄여 보여 준다.
브랜드 색은 OKLCH로 설계·기록하고, hex는 그 파생값으로, 확인 조건(화면·조명·바탕)을 함께 적는다.

확인 퀴즈

1. HSL로 명도 L을 15%부터 95%까지 10%씩 올려 초록 아홉 단계를 만들었더니 밝은 쪽 칸들이 서로 거의 구별되지 않았다. 가장 알맞은 설명은?

서윤의 계단에서 L* 간격은 어두운 쪽 14.6, 밝은 쪽 6.4~6.6이었다. 간격을 넓혀도 고르지 않은 비율은 그대로다. OKLCH의 명도를 같은 간격으로 나누면 L* 간격이 9~10으로 고르게 된다. 초록의 밝은 단계도 지각 공간에서는 잘 구별된다.

2. 고운 흑백 줄무늬 사진을 프로그램으로 절반 크기로 줄였더니 원래보다 어두운 회색이 되었다. 무엇이 잘못되었나?

검정(빛 0)과 흰색(빛 1)을 반씩 섞은 빛은 0.5이고, sRGB 감마로 적으면 약 188이다. 숫자 0과 255를 그냥 평균하면 128인데, 128은 빛으로 약 22%라서 어둡게 보인다. 점묘를 멀리서 볼 때처럼 빛이 실제로 섞이는 계산은 선형 빛으로 해야 한다.

3. 같은 이미지 파일의 초록이 노트북보다 휴대폰에서 더 선명하게 보였다. 휴대폰은 Display P3 화면이다. 가장 그럴듯한 설명은?

숫자는 어느 원색으로 읽느냐에 따라 다른 색이 된다. 색 관리가 되면 P3 화면은 sRGB 색을 정확히 낼 수 있다(sRGB는 P3 안에 들어간다). 색 관리가 빠지면 같은 숫자가 P3의 넓은 원색으로 읽혀 과장된다. 이 책의 모델로 로고 초록의 채도는 0.094에서 0.120이 되었다.

4. 서윤이 브랜드 색을 oklch(53.2% 0.094 162)로 기록하고 hex는 파생값으로 두기로 했다. 그 이유로 가장 알맞은 것은?

OKLCH는 색을 설계하는 데 편한 숫자이지 화면과 인쇄의 차이를 없애 주지는 않는다. 화면 색은 기기마다 다르고 인쇄는 따로 맞춰야 한다(15장). hex는 오히려 sRGB 안의 색만 적을 수 있다. OKLCH로 설계 값을 두고 hex를 파생하면, 값을 고칠 때 의도를 잃지 않는다.