OKLCH 색 공간 설명 — Tailwind v4가 채택한 이유
2025년 이후의 어떤 디자인 시스템 소스든 열어 보십시오 — shadcn/ui, Radix Themes, Tailwind v4 기본 팔레트 — 가장 먼저 눈에 들어오는 것은 색상입니다. hex 코드도 아니고, hsl() 트리플렛도 아니며, 3년 전에는 아무도 입에 올리지 않던 함수, oklch()입니다. Tailwind v4는 전체 기본 팔레트를 OKLCH 리터럴로 출시합니다. shadcn은 이제 OKLCH 커스텀 프로퍼티를 내보내는 테마를 생성합니다. Vercel의 디자인 시스템은 2024년에 OKLCH를 중심으로 재구축되었습니다.
이는 유행을 따라간 것이 아닙니다. 모든 진지한 디자인 시스템이 조용히 색상 모델을 바꾸어 온 데에는 구체적이고 수학적인 이유가 있으며, 한번 보고 나면 우리가 HSL을 쓰던 용도에 HSL이 왜 항상 잘못된 선택이었는지 더 이상 모른 척할 수 없게 됩니다.
이 글은 그 이유를 제1원리부터 풀어 가며, hex 코드에서 OKLCH로 변환하는 작업 예제로 마무리하고, 여러분 자신의 팔레트를 위한 이주 레시피를 제공합니다.
색 공간이 무너진 순간
디자인 시스템에는 색조(tonal) 작업이 있습니다. 버튼은 평상 상태보다 호버 시 약간 더 밝아져야 합니다. 음소거된 카드는 주변 표면보다 한 단계 더 어두워야 합니다. 포커스 링은 뒤에 깔린 중성 크롬보다 눈에 띄게 더 밝아야 합니다. 이를 규모 있게 잘 해내려면 “더 밝다”와 “더 어둡다”가 팔레트의 모든 색조에서 동일한 의미를 가져야 합니다.
팔레트가 색상 여덟 개와 상태 세 개뿐이던 시절에는 이 요구사항을 무시하기 쉬웠습니다. 팀들이 11단계 램프(Tailwind 관례로 50–950), 시맨틱 컬러 여덟 개, 라이트/다크 변형, 그리고 iOS, Android, 웹의 시스템 컬러와 공존해야 하는 브랜드 액센트까지 출시하기 시작하면서 이는 불편한 문제가 되었습니다. 갑자기 “이 teal-500이 우리 blue-500과 같은 밝기인가”라는 질문이 아트 디렉션의 사치가 아니라 실제 엔지니어링 문제로 떠올랐습니다.
HSL — CSS 3 이래의 주력 모델 — 은 이 질문에 답할 수 없었습니다. L 값이 동일한 두 HSL 색상도 지각된 밝기가 극적으로 다르게 보일 수 있습니다. lightness: 50%인 순수 HSL 노란색은 같은 명도의 순수 HSL 파란색보다 훨씬 더 밝게 보입니다. 사람의 눈은 노랑과 파랑을 똑같이 지각하지 않기 때문이며, HSL은 피커에 직관적이도록 설계된 것이지 램프에 지각적으로 일관되도록 설계된 것이 아닙니다. 2023년 무렵에는 색상 몇 개를 넘어 규모를 키운 모든 디자인 시스템이 커스텀 믹싱 스크립트나 수작업 오버라이드로 이를 우회하고 있었습니다.
우리에게 필요했던 것은 L이 실제로 “사람이 보고할 지각된 밝기”를 의미하고, 색조를 회전시키거나 채도를 줄여도 그 부작용으로 밝기가 보이지 않게 바뀌지 않는 색상 모델이었습니다. 그 모델은 학술적 색채 과학에는 이미 존재했지만 — 단지 아직 CSS에까지 도달하지 못했을 뿐입니다.
HSL 문제, 구체적으로
브라우저에 이것들을 넣고 나란히 보십시오.
.a { background: hsl(60 100% 50%); } /* yellow */
.b { background: hsl(240 100% 50%); } /* blue */
.c { background: hsl(120 100% 50%); } /* green */셋 다 L: 50%입니다. 어느 것도 같은 명도로 보이지 않습니다. 노란색은 거의 눈을 태우고, 파란색은 흰 페이지 위에서 거의 검정처럼 읽히며, 초록색은 그 사이에 자리합니다. L에 10%를 더해 호버 상태를 만들면, 노란색의 호버는 거의 보이지 않는 반면 파란색의 호버는 극적인 변화가 됩니다. 인터랙션의 마감이 결국 디자이너가 어느 색조에서 시작했느냐에 의존하게 됩니다.
이는 HSL의 버그가 아닙니다. HSL은 1978년에 색상번호로 칠하기 식 색상 피커를 위해 설계되었으며, 사용자는 hue, saturation, 그리고 (max(R,G,B) + min(R,G,B)) / 2로 정의된 “lightness”를 조작해 색을 맞추었습니다. 그 수식에는 사람의 지각이라는 개념이 없습니다. HSL에서 lightness는 sRGB 채널의 기하학적 중점일 뿐, 그 이상이 아닙니다.
CIE — 측색학을 위한 국제 표준화 기구 — 는 1970년대부터 이 문제를 알고 있었습니다. 그들은 두 개의 지각적 균일성을 가진 공간, CIELAB와 CIELUV를 발표했고, 명도를 사람의 시각이 실제로 하는 일에 더 가깝게 정의했습니다. 1990년대에는 CIE LAB이 인쇄, 사진, 색 관리에서 표준이었습니다. 그러나 RGB로의 변환은 까다로웠고, CSS는 이를 폭넓게 채택하지 않았습니다. 웹 개발자들은 HSL이 옳아서가 아니라 거기에 있었기 때문에 계속 HSL을 썼습니다.
CIE LAB / LCH: 학술적 해법, 그러나 그 나름의 문제
CIELAB는 XYZ 삼자극값(사람의 원추세포가 빛에 반응하는 방식의 모델)을 받아 세제곱근과 2D 회전을 거쳐 세 채널, L*(명도, 0–100), a*(녹↔적), b*(청↔황)을 만들어 냅니다. LCH는 같은 공간을 극좌표 형식으로 표현한 것입니다. L*, C*(chroma, 중성으로부터의 거리), H*(색조 각도).
이 공간들은 측정 가능한 의미에서 지각적으로 균일합니다. ΔE가 1 — LAB 공간에서 어느 방향이든 한 단위만큼 이동한 것 — 이면 훈련된 관찰자가 검출할 수 있는 가장 작은 색차에 거의 해당합니다. 인쇄와 사전 작업 파이프라인은 수십 년간 LAB와 LCH 위에서 돌아왔습니다.
그렇다면 왜 CSS는 그냥 LCH를 채택하고 끝내지 않았을까요?
이유는 두 가지입니다. 첫째, CIE LAB는 표면 반사를 위해 최적화된 특정 관측 조건(D50 광원 아래 2도 표준 관측자)에 맞춰 보정되었으며, 발광 디스플레이용이 아닙니다. 화면에서는 그 지각적 균일성이 흐트러집니다 — LAB에서 “동일하게 밝은” 색상이 휴대전화에서 항상 동일하게 밝게 보이는 것은 아닙니다. 둘째, LCH 색역은 어색합니다. LAB가 잘 기술하는 가시 색상 중 일반적인 디스플레이 색역 바깥에 자리한 것들이 있고, LCH에서 sRGB로의 매핑은 가끔 색조 이동을 일으킵니다(chroma를 줄이면 파란색이 살짝 보라로 갑니다). 디자인 시스템 작업에는 둘 다 치명적인 문제입니다.
CSS Color 4는 2021년에 lab()과 lch()를 추가했고, 현대 브라우저에서 동작합니다. 그러나 발광 화면 위에 일관된 색조 램프를 만드는 특정 문제에 대해서는, 커뮤니티가 계속 답을 찾고 있었습니다.
OKLAB / OKLCH: Ottosson의 2020년 통찰
2020년 12월, 스웨덴의 색상 엔지니어 Björn Ottosson은 “A perceptual color space for image processing”이라는 제목의 논문을 발표했습니다. 논문은 작았습니다. 짧은 행렬 셋, 세제곱근 단계 하나, 보정 표 없음, 저작권 있는 참조 데이터 없음. Ottosson은 기존의 IPT와 CAM16-UCS 색상 모델 — 좋은 성질을 가졌지만 수식이 나쁜 학술적 공간 — 을 가지고, 선형광 XYZ 삼자극값에 보통 행렬 곱셈만으로 그 지각적 거동을 근사하는 더 단순한 공간을 유도했습니다.
그는 이를 OKLAB이라 불렀습니다. 극좌표 형식이 OKLCH입니다.
OKLCH를 특별하게 만드는 것은 새로움이 아니라 목적적합성입니다. 세 가지 속성이 함께 있습니다.
- OKLCH의 명도는 진정으로 지각적입니다.
L: 0.7인 순수 노랑과L: 0.7인 순수 파랑은 보정된 디스플레이에서 같은 밝기로 보입니다.L + 0.05로 정의된 호버 상태는 팔레트 전체에서 시각적으로 동등한 변화를 만들어 냅니다. - chroma 변화에도 색조가 보존됩니다.
oklch(0.7 0.2 30)의 C 값을 줄여oklch(0.7 0.1 30)로 만들어도, 색조는 제자리에 머무릅니다. LCH에서는 같은 연산이 가시적인 색조 이동을 일으키는 경우가 잦습니다. OKLCH에서는 브랜드 색상의 음소거된 변형을 생성 위해 chroma를 평탄화해도, 색조가 의도치 않게 다른 쪽으로 흘러갈 일이 없습니다. - 수식이 저렴합니다. 행렬 곱셈 두 번과 세제곱근 한 번. 30줄짜리 JavaScript 함수로 구현 가능합니다. 룩업 테이블 없음, 디바이스별 보정 없음, 라이선스 우려 없음.
이 조합이 OKLCH를 실제 CSS에서 쓸 수 있게 만든 요인입니다. W3C는 2022년에 oklch()를 CSS Color 4에 추가했습니다. Chrome 111은 2023년에 이를 출시했습니다. 2024년 중반에는 모든 상시 업데이트 브라우저가 이를 지원했습니다. 같은 해에 Tailwind v4가 이를 기본 팔레트 형식으로 삼았습니다.
수식: HEX → OKLCH 변환 작업 예제
#3b82f6 — Tailwind의 blue-500 — 을 OKLCH로 따라가 보겠습니다. 이는 Color Converter 도구와 HEX to OKLCH 스포크가 모든 키 입력에 대해 실행하는 것과 동일한 수식입니다. 내부에서 무슨 일이 일어나는지 알아 두면 다음 절의 함정들이 더 잘 이해됩니다.
Step 1: Hex에서 sRGB로. 여섯 자리 hex를 세 쌍으로 나누고 각각을 255로 나눕니다.
const r = 0x3b / 255; // 0.231
const g = 0x82 / 255; // 0.510
const b = 0xf6 / 255; // 0.965이는 감마 인코딩된 sRGB 값입니다 — 이미지 파일이 저장하고 있는 채널 값으로, 모니터가 빛을 내는 방식을 보정하기 위한 비선형 곡선이 안에 구워져 있습니다.
Step 2: sRGB에서 선형 sRGB로. 선형광 채널 값을 얻기 위해 감마 곡선을 제거합니다. CSS Color 4 §11.2의 표준 구간별 변환입니다.
const linear = (v) => v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
const [lr, lg, lb] = [r, g, b].map(linear);
// lr ≈ 0.045, lg ≈ 0.220, lb ≈ 0.923Step 3: 선형 sRGB에서 XYZ D65로. CSS Color 4 §15.1에 정의된 표준 행렬 곱셈입니다.
const x = 0.4124564 * lr + 0.3575761 * lg + 0.1804375 * lb;
const y = 0.2126729 * lr + 0.7151522 * lg + 0.0721750 * lb;
const z = 0.0193339 * lr + 0.1191920 * lg + 0.9503041 * lb;
// x ≈ 0.265, y ≈ 0.231, z ≈ 0.927이는 정규 XYZ 삼자극 표현입니다 — “이 색상이 사람의 원추세포 반응 측면에서 어떤 파장인가” 형식입니다.
Step 4: XYZ에서 LMS로. Ottosson의 첫 번째 행렬이 XYZ를 OKLAB용으로 조정된 long/medium/short 원추 기본 공간에 매핑합니다.
const lms = [
0.8189330101 * x + 0.3618667424 * y - 0.1288597137 * z,
0.0329845436 * x + 0.9293118715 * y + 0.0361456387 * z,
0.0482003018 * x + 0.2643662691 * y + 0.6338517070 * z,
];Step 5: LMS 값에 세제곱근을 취합니다. 이는 지각 압축 단계로 — CIE LAB의 세제곱근에 해당합니다.
const lms_ = lms.map(Math.cbrt);Step 6: LMS’에서 OKLAB로. Ottosson의 두 번째 행렬입니다.
const L = 0.2104542553 * lms_[0] + 0.7936177850 * lms_[1] - 0.0040720468 * lms_[2];
const a = 1.9779984951 * lms_[0] - 2.4285922050 * lms_[1] + 0.4505937099 * lms_[2];
const b_ = 0.0259040371 * lms_[0] + 0.7827717662 * lms_[1] - 0.8086757660 * lms_[2];
// L ≈ 0.629, a ≈ -0.022, b_ ≈ -0.191여기까지가 OKLAB입니다. 명도 채널 L ≈ 0.629는 이 특정 파랑에 대해 눈이 “60% 밝기”로 지각하는 값입니다.
Step 7: OKLAB에서 OKLCH로 (직교에서 극좌표로).
const C = Math.sqrt(a * a + b_ * b_); // 0.193
const H = (Math.atan2(b_, a) * 180 / Math.PI + 360) % 360; // 263.4
// → oklch(0.629 0.193 263.4)따라서 #3b82f6은 oklch(0.629 0.193 263.4)입니다. 명도 0.629, chroma 0.193, 색조 263.4°.
이 색상에서 시작해 L만 변화시켜(0.95에서 0.15까지 11단계로) C와 H를 고정한 채 50–950 램프를 만들면, 모든 음영이 시각적으로 동일한 색조이고, 명도가 균일하게 옅어지는 팔레트를 얻습니다. HSL에서 같은 작업을 하면 어두운 음영은 보라 쪽으로 이동하고 밝은 음영은 회색으로 갑니다. 그것이 핵심 성과입니다.
Display P3 + Rec2020: OKLCH가 광색역을 여는 이유
OKLCH는 경계가 없습니다. HSL(sRGB에 한정됨)과 LCH(반사 표면에 맞춰 보정됨)와는 달리 OKLCH에는 암묵적 색역이 없습니다. oklch(0.7 0.25 30)라고 쓰면 Display P3의 색 영역 안에 있지만 sRGB 바깥에 있는 선명한 빨강을 만들어 낼 수 있습니다. 최근 iPhone이나 MacBook에서는 그대로 렌더링됩니다. 오래된 모니터에서는 브라우저가 자동으로 가장 가까운 sRGB 표현으로 스냅합니다.
이는 Apple, Samsung, W3C 모두가 2010년대 후반에 광색역 하드웨어를 내놓는 데 시간을 쏟았기 때문에 중요합니다. MacBook Pro 14”/16”(mini-LED)는 기본으로 P3를 출시합니다. iPhone 15 Pro는 Safari에서 Display P3를 렌더링합니다. Android 플래그십은 Rec2020 패널을 출시합니다. 2025년에 이르면 디자인 시스템 트래픽의 상당 부분이 HSL/sRGB가 단순히 표현할 수 없는 색상을 보여 줄 수 있는 광색역 하드웨어 위에서 발생합니다.
OKLCH는 별도의 @media (color-gamut: p3) 선언을 덧붙이지 않고도 그런 색상을 쓸 수 있게 해 줍니다. 폴백은 브라우저가 처리합니다. 여러분의 디자인 시스템은 별도 설정 없이 “디바이스가 렌더링할 수 있는 가장 선명한 빨강을 써라”를 얻습니다.
이것이 OKLCH가 디자인 토큰에 적합한 형식인 이유이기도 합니다. OKLCH로 작성된 --brand 변수는 의도에 대한 디바이스 독립적 기술입니다. 사용자가 어떤 디스플레이를 쓰는지에 따라 무엇을 렌더링할지는 브라우저가 알아내며, 여러분의 코드는 CSS, SwiftUI(Display P3를 네이티브로 지원), Android Compose(Rec2020 인식), Flutter 사이에서 이식 가능합니다.
Tailwind v4와 디자인 토큰 혁명
2024년에 출시된 Tailwind v4는 OKLCH를 연구 영역에서 업계 기본값으로 끌어올린 변곡점이었습니다. Tailwind 작성자들은 세 가지 의견 있는 결정을 내렸습니다.
- 기본 팔레트가 OKLCH입니다. Slate, gray, zinc, neutral, stone — 모든 Tailwind 색상이 소스에서
oklch()로 정의됩니다. 50–950 램프는 구성상 지각 명도에서 균일합니다. - 커스텀 테마는 OKLCH 리터럴이 있는
@theme블록을 사용합니다. 브랜드 색상은oklch()토큰으로 정의되고, 하위 유틸리티(bg-brand-500,text-brand-300)가 생성됩니다. - 폴백 절차가 필요 없습니다. OKLCH를 지원하지 않는 브라우저는 Tailwind v4의 문서화된 기준선 아래에 있습니다.
마지막 결정이 채택을 풋건 없는 선택지로 만들었습니다. 불과 2023년만 해도 디자이너들은 구형 Safari가 깨지지 않도록 모든 색상의 oklch() 버전과 hsl() 버전을 함께 출시해야 했습니다. Tailwind v4에서는 기준선이 2023년 또는 그 이후의 브라우저이며, OKLCH가 어디서나 동작합니다.
shadcn/ui의 테마 생성기도 같은 패턴을 따릅니다. 브랜드 색상을 입력하면 OKLCH 램프가 나옵니다. Vercel의 디자인 시스템은 시맨틱 색상에 OKLCH를 씁니다. Radix Themes의 색상 스케일은 OKLCH로 정의됩니다. 커뮤니티가 수렴했습니다.
실전 이주: HEX 팔레트 → OKLCH 팔레트
오늘 hex 기반 팔레트를 갖고 있다면, 이주는 기계적입니다. 레시피는 다음과 같습니다.
1. 램프 구조를 결정합니다. Tailwind의 50–950(11단계)이 사실상의 기본이며, 특별한 이유가 없는 한 따를 만한 가치가 있습니다. L = 0.97, 0.93, 0.86, 0.76, 0.63, 0.50, 0.42, 0.34, 0.26, 0.18, 0.10의 단계는 매끄러운 지각 램프를 제공합니다.
2. 브랜드 hex를 OKLCH로 변환합니다. Color Converter나 HEX to OKLCH 도구를 사용하십시오. oklch(0.629 0.193 263.4) 같은 트리플렛을 얻게 됩니다. H 값을 기록해 두십시오 — 이것이 여러분의 브랜드 색조입니다.
3. C와 H를 일정하게 유지한 채 L을 변화시킵니다. 다음을 출력해 램프를 만듭니다.
--brand-50: oklch(0.97 0.193 263.4);
--brand-100: oklch(0.93 0.193 263.4);
...
--brand-950: oklch(0.10 0.193 263.4);4. 극단의 단계를 조정합니다. 매우 낮은 L(≤ 0.20)과 매우 높은 L(≥ 0.95)에서는 높은 chroma 값이 sRGB 바깥으로 떨어집니다. 그 단계에서는 C를 줄이거나, 브라우저의 자동 스냅을 받아들이십시오. Tailwind의 기본값은 양쪽 끝으로 갈수록 chroma를 줄입니다 — 그 패턴을 따라가십시오.
5. 시맨틱 별칭을 정의합니다. --surface: var(--brand-50), --surface-elevated: var(--brand-100), --text-primary: var(--brand-900) 등. 이제 디자인 토큰이 색상이 아니라 의도로 읽힙니다.
6. 명암비를 검증합니다. APCA Lc 또는 WCAG 2 명암비를 사용해 각 --text-* 쌍이 각 --surface-* 쌍에 대해 접근성 기준을 만족하는지 확인하십시오. OKLCH L이 지각적이기 때문에, 명암비 수식은 HSL에서보다 더 신뢰할 만합니다.
60색의 레거시 팔레트에서 이 이주를 진행하는 팀은 보통 한나절에 30–40개 토큰으로 더 작고 더 균일한 OKLCH 팔레트로 안착합니다. 새 팔레트는 더 작게 출시되고, 더 작은 CSS를 생성하며, 별도 조정 없이 호버 상태와 비활성 상태에서 시각적으로 더 나은 색조 이동을 만들어 냅니다.
함정과 대처법
들어가기 전에 알아 둘 몇 가지가 있습니다.
색역 외 경고. 일부 OKLCH 값은 Display P3나 sRGB 바깥으로 떨어집니다. 현대 브라우저는 가장 가까운 유효 색상으로 스냅하는 작업을 자동으로 처리해 주지만, 그 스냅은 손실이 있습니다. 여러분이 작성한 oklch(0.7 0.25 30)이 실제로는 약간 덜 채도가 높은 모습으로 렌더링될 수 있습니다. Color Converter의 색역 행 같은 도구는 여러분의 색상이 sRGB 안전인지, P3 안전인지, Rec2020 안전인지를 알려 주며, 작성한 그대로 보이도록 sRGB로 한 번에 스냅하는 기능을 제공합니다.
서브픽셀 chroma 기이함. OKLCH chroma는 경계가 없지만, 가시 색상에 대한 유용한 범위는 대략 0에서 ~0.4까지입니다. 0.4를 넘는 값은 단색 레이저 광으로만 달성 가능합니다 — 디스플레이가 렌더링할 수 있는 물리적 색상이 아닙니다. Color Converter는 이 때문에 chroma 슬라이더를 0.4에서 잘라 둡니다. 그 너머의 값은 어떤 실제 디스플레이에서도 지각 가능한 차이를 만들지 않습니다.
2025년 기준 브라우저 지원. Chrome 111+, Safari 15.4+, Firefox 113+ 모두 oklch()를 네이티브로 지원합니다. 2023년 이전의 브라우저는 그렇지 않습니다. 레거시 IE/Edge나 더 오래된 모바일 Safari를 지원해야 한다면(청중에 따라 트래픽의 1–3%), @supports (color: oklch(0 0 0))을 사용해 OKLCH 선언에 hex 폴백을 짝지을 수 있습니다 — 그러나 2025년에 출시되는 디자인 시스템 토큰의 경우, 폴백 비용이 레거시 이득을 초과하는 경우가 많습니다.
Hex 코드의 영속성. OKLCH는 디자인 시스템의 의도를 위한 것입니다. 여러분의 CMS는 레거시 이유로 여전히 hex 값을 요구할 수 있습니다(이메일 서명, Office 문서, 브랜드 자산 체크리스트). 각 OKLCH 토큰에 대해 sRGB로 스냅한 hex를 내보내는 생성된 룩업 테이블을 유지하되, hex로 작성하지는 마십시오.
OKLCH와 OKLAB을 혼동하지 마십시오. OKLAB은 직사각형 형식(L, a, b 채널)이고, OKLCH는 같은 색 공간을 극좌표 형식(L, C, H)으로 표현한 것입니다. 둘 사이는 직교↔극좌표 변환 한 단계로 오갈 수 있습니다. 토큰에는 OKLCH를 쓰고(가독성이 높고 램프를 생성 쉽습니다), 색상을 보간하거나 블렌딩해야 하면 내부적으로 OKLAB을 쓰십시오.
여러분 자신의 팔레트로 시도해 보십시오
여기서 설명한 내용을 실제로 보는 가장 빠른 방법은 브랜드 hex를 Color Converter에 넣어 보는 것입니다. HEX 입력란에 브랜드 색상을 입력하고 OKLCH 출력을 읽으십시오. 그런 다음 OKLCH 쪽 슬라이더를 움직여, chroma를 줄여도 같은 색조가 그대로 유지되는 모습과, 색조를 회전시켜도 같은 명도가 그대로 유지되는 모습을 지켜보십시오. 몇 분만 지나면 HSL이 색조 램프에 왜 항상 잘못된 도구였는지, 그리고 모든 진지한 디자인 시스템이 왜 OKLCH로 옮겨 갔는지에 대한 직관이 생깁니다.
특정 HEX-to-OKLCH 변환에는 HEX to OKLCH를 사용하십시오 — 이 글과 동일한 수식이며, 추가 이점이 하나 있습니다. 색역 분류(sRGB / Display P3 / Rec2020)를 표시해 주므로, 어떤 브랜드 색상이 어디서나 안전한지, 그리고 어떤 색상이 완전히 렌더링되려면 광색역 디바이스가 필요한지 알 수 있습니다.
이상이 OKLCH입니다. 이주할 가치가 있습니다. 잘 해 두면, 다시는 hsl()을 쓰지 않게 됩니다.