눈에 보이는 그대로의 컬러 시스템
*원문을 번역한 글입니다.
*원문은 발행 이후 수정될 수 있으며, 본 번역은 발송 시점 기준으로 작성되었습니다.
몇 주 전 빨간색 계열의 컬러를 찾으려고 Tailwind v4 문서를 훑어보고 있었습니다. 그때 이 코드를 발견했습니다.
--color-red-500: oklch(0.637 0.237 25.331);
Hex도 HSL도 아닌 완전히 처음 보는 형식이었습니다. 저는 잠시 멈춰 서서 제가 무엇을 보고 있는지 분석해 보았습니다. 당시 10년 넘게 디자인 토큰을 만들어 왔음에도 이 구문은 전혀 알아볼 수 없었습니다. 전에도 OKLCH라는 이름을 들어본 적은 있었습니다. 냉장고에 냉동실이 있다는 사실을 무의식적으로 인지하듯 딱히 깊게 생각해 본 적 없는 정보였습니다. 그런데 이제 세계에서 가장 인기 있는 CSS 프레임워크가 모든 팔레트 컬러의 기본값으로 이 형식을 채택했습니다. 공지사항이나 트위터 게시글은 없었습니다. 변화에 대해 양해를 구하는 마이그레이션 가이드조차 없었습니다. 그저 새로운 값들이 원래 그 자리에 있었던 것처럼 무심하게 놓여 있을 뿐이었습니다. 저는 페이지를 닫고 커피 한 잔을 내렸습니다. 그러고는 다음 3일 동안 이 형식에 대해 찾을 수 있는 모든 자료를 탐독했습니다.
모든 디자이너가 알고 있지만 아무도 입 밖으로 내지 않는 사실이 있습니다.
HSL은 결함이 있는 컬러 모델입니다.
밝기(Lightness) 50%의 노란색을 고르고, 똑같은 밝기 50%의 파란색을 골라 두 색을 비교해 보십시오. 노란색은 밝게 빛납니다. 반면 파란색은 거의 검은색에 가깝습니다. 두 색상 모두 L값은 동일합니다.
모니터 고장이 아닙니다. 이것이 바로 설계된 대로 작동하는 HSL의 본모습입니다. HSL의 밝기 척도는 R, G, B 채널의 최솟값과 최댓값 사이를 수학적으로 계산한 중간 지점일 뿐입니다. 실제 우리 눈에 색이 얼마나 밝게 보이는지와는 아무런 상관이 없습니다.
모든 디자이너는 실무에서 이 문제와 수년간 사투를 벌여 왔습니다. 파란색의 밝기를 20포인트 낮추면 보라색으로 변합니다. RGB 방식으로 노란색에서 파란색으로 이어지는 그라데이션을 만들면 중간 지점이 탁한 회색으로 죽어버립니다. 빨간색, 파란색, 초록색, 회색 등 모든 색상의 500번대 음영이 시각적으로 동일한 무게감을 갖도록 팔레트를 구성해 보십시오. 절대 불가능합니다. 수학적 계산이 인간의 눈과 일치하지 않기 때문입니다.
디자이너들은 모두 임시방편을 알고 있습니다. 컬러 코드를 미세하게 조정하고 명도 대비를 확인합니다. 다크 모드를 체크합니다. 다시 조절합니다. 테스트를 거쳐 배포합니다. 하지만 3개월 뒤, 누군가 "왜 300번대 컬러는 물이 빠진 듯 보이고 700번대 컬러는 칙칙해 보이냐"고 질문을 던지면 당신은 다시 처음으로 돌아가 이 모든 과정을 반복합니다.
잘못 설계된 컬러 모델을 보완하기 위해 우리가 쏟아부은 무보수 노동의 양은 엄청납니다. 하지만 우리 중 그 누구도 도구가 이 문제를 다르게 해결해야 한다고 의문을 제기하지 않았습니다.
요제프 알버스*는 이미 1963년에 이 사실을 언급했습니다.
"시각적 지각에 있어 색은 실제 있는 그대로 혹은 물리적인 형태 그대로 보이는 경우가 거의 없습니다. 이러한 사실은 색을 예술에서 가장 상대적인 매체로 만듭니다. 색을 효과적으로 사용하기 위해서는 색이 끊임없이 우리를 속인다는 사실을 반드시 인식해야 합니다."
- (요제프 알버스 Josef Albers : 바우하우스 교수, 추상 회화, 색채 연구 전공)
이 문장들은 요제프 알버스가 1963년 예일대에서 출간한 저서 '색의 상호작용(Interaction of Color)'의 서문입니다. 독일계 미국인 화가이자 교수였던 알버스는 평생에 걸쳐 이 한 가지 사실을 증명하는 데 매진했습니다. 파란색 바탕 위의 회색과 노란색 바탕 위의 회색은 동일한 색입니다. 하지만 우리 눈에는 완전히 다른 두 개의 회색으로 보입니다. 빛의 파장은 같습니다. 그러나 지각되는 결과는 다릅니다.
그는 63년 전에 이 글을 썼습니다. 제가 아는 모든 디자이너가 그 책을 읽었습니다. 하지만 우리는 모두 다시 편집기로 돌아가 HSL 방식으로 색을 입력했습니다. 이것은 단순한 실수가 아닙니다. 도구들이 60년에 걸친 색 지각 연구를 무시해 온 결과입니다. 수학적 공식이 인간의 눈이 실제로 작동하는 방식을 반영하기를 거부했기 때문입니다.
스웨덴의 게임 개발자 이야기입니다.
2020년 12월 비요른 오토손(Björn Ottosson)이라는 이름의 소프트웨어 엔지니어가 개인 블로그에 글을 하나 올렸습니다. 그는 컬러 과학자가 아니었습니다. 스톡홀름의 EA DICE에서 피파(FIFA), 배틀필드(Battlefield), 니드 포 스피드(Need for Speed) 프로젝트에 참여했던 엔지니어였습니다. 그는 업무 중에 계속해서 동일한 문제에 부딪혔습니다.
"가끔 색을 더 어둡게 만들거나 색조를 바꾸는 식의 간단한 조작을 하고 싶었습니다. 기존 컬러 스페이스들이 이런 간단한 작업에 얼마나 효율적인지 조사해 보았습니다. 결과적으로 모든 방식에 어떤 식으로든 결함이 있다는 결론을 내렸습니다."
그래서 그는 새로운 모델을 만들었습니다. 단 열 줄의 코드였습니다. 그는 이것을 Oklab이라고 불렀습니다. 이름은 일종의 농담이었습니다. 기존 컬러 스페이스들이 자신의 요구 사항을 충족하지 못해 '오케이(OK)'하지 않았습니다. 그래서 괜찮은(OK) 모델을 만드는 것을 목표로 삼았습니다. 그는 자신의 이름을 따서 '오토손 랩(Ottosson Lab)'이라 부르지 않았습니다. 그저 '오케이(Ok)'라고 불렀습니다.
여기서부터 이야기가 흥미진진하게 흘러갑니다. W3C의 크리스 릴리(Chris Lilley)가 그 블로그 포스트를 읽었고 애플의 사이먼 프레이저(Simon Fraser)는 이에 대해 트윗을 남겼습니다. 릴리는 논문을 깊이 파고들었습니다. 오토손에게 몇 가지 질문을 던졌습니다. 그러고는 W3C의 레아 베루(Lea Verou)와 함께 Color.js에 이 알고리즘을 구현했습니다.
그들은 함께 Oklab을 CSS 표준에 포함시키기 위해 힘을 모으기 시작했습니다.
포토샵은 그라데이션 보간을 위한 기본 방식으로 Oklab을 채택했고 유니티(Unity)는 이를 엔진에 통합했습니다. 고도(Godot) 엔진의 컬러 피커도 이를 사용하기 시작했습니다. 2021년 12월 즈음 Oklab과 그 형제격인 원통형 모델 OKLCH는 CSS 컬러 모듈 레벨 4 초안에 포함되었습니다. 2023년에 이르러 모든 주요 브라우저가 이를 지원하게 되었습니다. 한 엔지니어가 사이드 프로젝트로 시작한 결과물이 전 세계 디자이너와 개발자가 매일 사용하는 도구 속에서 60년 전통의 제도권 컬러 과학을 대체했습니다. 그의 코드가 기존 학계 모델들이 해결하지 못한 문제들을 풀어냈기에 가능한 변화였습니다.
OKLCH의 실제 작동 방식은 다음과 같습니다.
OKLCH는 Ok 밝기(Lightness), 채도(Chroma), 색조(Hue)를 의미합니다. 세 가지 숫자는 각각 이름이 의미하는 바를 정확히 수행합니다. 여기서 밝기는 실제 우리 눈에 보이는 밝기(Perceived brightness)를 뜻합니다. 밝기 70%의 노란색과 밝기 70%의 파란색은 시각적으로 거의 동일하게 밝아 보입니다. 이것이 핵심입니다. 이 원리가 있기에 나머지 모든 기능이 제대로 작동합니다.
색조(Hue)는 지정한 위치에 그대로 머뭅니다. 파란색을 어둡게 만들어도 여전히 파란색으로 유지됩니다. 빨간색을 밝게 조절해도 분홍색으로 변하지 않습니다.
채도(Chroma)는 정직합니다. HSL 방식처럼 모든 색조가 최대 채도에 도달할 수 있는 척 기만하지 않습니다. 대신 특정 밝기에서 해당 색조가 구현할 수 있는 실제 최대 색 함유량을 정확히 알려줍니다.
OKLCH 기반으로 팔레트를 다시 구축하면 어렵게 느껴졌던 작업들이 단순한 산수가 됩니다. 접근성을 고려한 대비 쌍이 필요하십니까? L값의 차이가 0.4 이상인 두 값을 선택하십시오. 5단계 명암 단계가 필요하십니까? L축을 기준으로 간격을 동일하게 배치하십시오. 다크 모드가 필요하십니까? 척도를 반전시키십시오. 중간 지점이 탁해지지 않는 그라데이션을 원하십니까? 그저 OKLCH 방식 안에서 보간하면 됩니다.
불필요한 작업들이 사라집니다. 똑똑한 도구가 이 문제를 해결했기 때문이 아닙니다. 컬러 스페이스가 마침내 우리 눈과 일치하게 되었기 때문입니다.
그 계보는 1905년으로 거슬러 올라갑니다.
이 주제를 조사하며 가장 놀랐던 점은 OKLCH의 지적 토대가 전혀 새로운 것이 아니라는 사실이었습니다. 20세기 초반 보스턴에서 활동한 앨버트 먼셀(Albert Munsell)은 색조, 명도, 채도라는 세 가지 독립적인 지각 차원을 중심으로 컬러 시스템을 구축했습니다. 그는 1905년 '컬러 노테이션(A Color Notation)'이라는 책을 통해 이를 발표했습니다. 우리 지각 시스템이 각 차원을 독립적으로 처리하기에 해당 차원들을 직교 구조로 설계했습니다. 그의 시스템은 이론에만 그치지 않았습니다. 피실험자들에게 색상 샘플을 보여주었습니다. 인접한 색상 칩 사이의 단계가 시각적으로 균등하게 느껴질 때까지 간격을 조정하며 시스템을 완성했습니다. OKLCH는 1905년 먼셀 시스템의 정통성을 직접 잇는 수학적 후손입니다.
그 사이에는 1976년 국제조명위원회(CIE)가 발표한 CIELAB이 자리합니다. CIELAB은 지각적 균일성을 위해 설계된 최초의 본격적인 수학적 컬러 스페이스였습니다. 수십 년 동안 인쇄, 사진, 영상 보정, 학술적 색채 과학의 표준이 되었습니다. 하지만 이미 알려진 결함들이 있었습니다. 가장 유명한 것은 학술적으로 '블루 턴(blue turn)'이라 불리는 현상입니다. CIELAB에서 파란색과 흰색 사이의 그라데이션을 만들면 보라색으로 변합니다. 해당 시스템이 색조를 모델링하는 방식의 비선형성 때문입니다. 다크 모드를 제작할 때 파란색이 보라색처럼 보였던 경험이 있다면 바로 이 문제를 직접 겪은 셈입니다. 색채 과학자들은 이를 해결하기 위해 40년을 보냈습니다. CIECAM02, CAM16 등 수많은 모델이 등장했습니다. 각 모델은 CIELAB의 특정 결함을 해결하려 노력했습니다. 그러나 수학적으로 너무 복잡했습니다. 주변 조명 환경을 세밀하게 설정해야 하는 번거로움도 있었습니다. 결과적으로 실제 디자이너들이 사용하는 도구에는 거의 채택되지 못했습니다. 그러던 중 오토손이 블로그 포스트를 올렸습니다.
왜 대부분의 디자이너가 이 변화를 놓쳤을까요? OKLCH는 이미 3년 전부터 모든 주요 브라우저에서 지원되었습니다. 2021년부터는 CSS 표준의 일부가 되었습니다. 포토샵은 더 오래전부터 그라데이션에 Oklab을 사용해 왔습니다. 2025년 초 출시된 Tailwind v4는 전체 팔레트의 기본값으로 이를 채택했습니다. shadcn/ui 역시 테마 설정에 OKLCH를 활용합니다. 최신 코드베이스를 학습한 모든 AI 코딩 어시스턴트들도 이제 OKLCH를 기본으로 출력합니다. 그럼에도 대부분의 디자이너는 여전히 이 사실을 모릅니다. 저 또한 몰랐습니다. 저는 디자인 시스템 구축을 업으로 삼는 사람입니다. 디자인 블로그를 읽고 트위터에서 주요 인물들을 팔로우합니다. 당연히 알아야 할 정보들을 놓치지 않으려 노력했습니다. 하지만 제가 HSL의 잘못된 수식들을 땜질하느라 바쁜 사이 변화는 보이지 않는 곳에서 조용히 일어났습니다.
그 원인 중 하나는 OKLCH가 해결하는 문제들이 너무나 익숙해진 나머지 인지조차 못 하게 되었기 때문입니다. 깨진 그라데이션, 틀어진 색조, 일정하지 않은 명도 대비 등이 그렇습니다. 다크 모드에서 무너지는 디자인 시스템도 마찬가지입니다. 우리는 이를 보완하기 위해 정교한 도구들을 만들었습니다. 대비 확인 도구와 팔레트 생성기 같은 것들입니다. 다크 모드를 제대로 구현하는 방법에 대한 수많은 글도 쏟아져 나왔습니다. 고통이 너무나 일상적이었기에 우리는 그것을 더 이상 고통으로 느끼지 않게 되었습니다. 또 다른 이유는 이 과정이 매우 정숙하게 진행되었기 때문입니다. 스웨덴의 한 엔지니어가 블로그에 글을 올렸습니다. W3C가 이를 채택했고 Tailwind가 기본 설정을 변경했습니다. 화려한 키노트나 프레임워크 출시 행사도 없었습니다. 대대적인 홍보 캠페인도 없었습니다. 혁명은 업계의 등 뒤에서 소리 없이 일어났습니다.
무엇을 해야 할까요?
현재 사용 중인 디자인 시스템을 열어 보십시오. 전체 팔레트가 아닌 단 하나의 컬러 스케일을 골라 OKLCH로 다시 구성해 보십시오. 주색상(Primary)부터 시작하는 것을 추천합니다.
500번대 값을 설정하십시오. L값을 동일한 단계로 높여 50부터 400까지 만드십시오. 반대로 L값을 동일하게 낮춰 600부터 950까지 구성하십시오. 채도와 색조는 일정하게 유지하십시오.
이 작업을 처음 마치고 나면 컬러 램프가 완벽하게 작동하는 모습을 보게 될 것입니다. 모든 단계가 눈으로 보기에 균등하게 배치됩니다. 추가적인 미세 조정은 필요 없습니다. 나머지 시스템 전체를 바꿔야 할 이유가 스스로 증명되는 순간입니다.
다음은 보조 색상에 적용해 보십시오. 그러고 나서 나머지 모든 색상에 적용하십시오. 마지막으로 L 스케일을 반전시켜 다크 모드를 구축해 보십시오. 모든 것이 의도대로 완벽하게 작동할 것입니다. 오토손이 작성한 열 줄의 코드는 사라지지 않습니다. 도구들에 대한 합의는 이미 끝났습니다. 알버스도 이를 알아봤을 것입니다. 이것은 혁명이 아닙니다. 바로잡음입니다.
컬러는 마침내 그가 항상 말했던 방식대로 작동하고 있습니다.
아티클에 소개된 기술들을 직접 시도해보고 싶은 분들을 위해 무료 도구 모음을 만들었습니다. 컬러 램프 제작부터 그라데이션 비교, 대비 탐색, 라이트 및 다크 테마 빌더까지 모두 포함되어 있습니다.
Live here: https://pawelklasa.github.io/okay-tools/
참고문헌
Björn Ottosson, “A perceptual color space for image processing,” personal blog, December 2020.
Philip Jägenstedt, “Interview With Björn Ottosson, Creator Of The Oklab Color Space,” Smashing Magazine, October 2024.
Josef Albers, Interaction of Color, Yale University Press, 1963.
Albert H. Munsell, A Color Notation, Boston, 1905. (public domain, full text on Internet Archive)
Chris Lilley, “Better than Lab? Gamut reduction in CIE Lab and OKLab,” W3C Workshop on Wide Color Gamut and High Dynamic Range for the Web, 2021. y
Tailwind CSS team, “Tailwind CSS v4.0” release notes, January 2025.
Andrey Sitnik, “OKLCH in CSS: why we moved from RGB and HSL,” Evil Martians blog, 2023.
Eric Portis, “Okay, Color Spaces,” February 2024.
원문 출처 : https://medium.com/design-bootcamp/color-is-finally-ok-82f368f3408c
