색 하나하나가 아니라, 팔레트 전체를 설계한다

KRDS DS-003 — 명도 대비 기준을 고려하여 단계별 색상을 설정하여 색상 팔레트를 구성하고 있다.

0. 들어가며 — 점검에서 설계로

앞의 두 편을 잠깐 복습해 봅시다.

1편(DS-001) 은 “임의 색 말고 팔레트의 색을 우선 쓰라”고 했습니다.

2편(DS-002) 은 “그 색들이 명도 대비를 충족하라”고 했습니다.

그런데 두 편을 읽으며 이런 의문이 들었을 수 있습니다. “매번 색을 고를 때마다 대비를 계산해야 하나? 그건 너무 번거로운데?”

바로 그 의문에 대한 답이 DS-003입니다. DS-003은 개별 색의 문제가 아니라 팔레트라는 ’시스템 전체’의 설계 를 봅니다. 핵심 발상은 이렇습니다.

개별 색을 매번 검사하지 말고, 처음부터 ’대비가 보장되도록 단계를 설계한 팔레트’를 만들어 두자.

즉 DS-001·002가 “색을 쓰는 사람”의 규칙이라면, DS-003은 “색을 설계하는 사람”의 규칙입니다. 한 단계 위, 디자인 시스템의 뼈대를 다루는 항목이죠. 이번 편은 조금 더 깊이 들어가지만, 끝까지 읽으면 “좋은 색상 시스템은 어떻게 만들어지는가” 라는 큰 그림이 잡힙니다.

1. 규칙 원문 — 세 토막으로 나눠 읽기

DS-003 (디자인 스타일 > 색상) “명도 대비 기준을 고려하여 / 단계별 색상을 설정하여 / 색상 팔레트를 구성하고 있다.”

이 문장은 세 개의 동작이 겹쳐 있습니다. 순서대로 읽어야 의미가 풀립니다.

① “색상 팔레트를 구성하고 있다”

가장 큰 틀입니다. 색을 하나하나 그때그때 고르는 게 아니라, 미리 정의된 색 묶음(팔레트) 을 갖추고 있느냐를 봅니다. 1편에서 다룬 “팔레트 우선 사용”이 가능하려면, 애초에 쓸 팔레트가 존재해야 합니다. DS-003은 그 팔레트의 ’존재’와 ’구성 방식’을 점검합니다.

② “단계별 색상을 설정하여”

팔레트가 단순히 “파랑 1개, 회색 1개”가 아니라, 하나의 색이 연함→진함으로 여러 단계(scale) 를 갖도록 구성됐는지를 봅니다. 예: 연한 파랑(blue-10) → 중간 파랑(blue-50) → 진한 파랑(blue-90). 이 ’단계’가 색상 시스템의 핵심 재료입니다.

③ “명도 대비 기준을 고려하여”

가장 중요한 조건입니다. 그 단계들이 아무렇게나 나뉜 게 아니라, 명도 대비(2편의 그 기준)를 고려해서 설정됐느냐를 봅니다. 즉 “이 단계와 저 단계를 조합하면 대비 4.5:1이 나온다” 가 설계에 미리 반영돼 있어야 합니다.

세 토막을 합치면 이렇게 됩니다.

“우리는 색을 연함~진함의 단계로 나눠 팔레트를 만들었고, 그 단계 간격은 명도 대비 기준이 자동으로 충족되도록 설계했다.”

이게 되면, 색을 쓰는 사람은 더 이상 대비 계산을 할 필요가 없습니다. ’설계된 단계’에서 고르기만 하면 되니까요.

2. 왜 중요한가 — ’검사’가 아니라 ’구조’로 푸는 접근성

(1) 개별 점검은 결국 무너진다

화면에 들어가는 색 조합은 수백 가지입니다. 본문/배경, 버튼/글자, 링크/배경, 테두리/면, 상태색/배경… 이걸 하나하나 “대비 4.5:1 넘나?” 검사하는 방식은 두 가지 이유로 실패합니다.

양이 많아서 — 디자이너가 매번 계산기를 두드릴 수 없습니다. 결국 어딘가는 건너뜁니다.

사람이 바뀌어서 — 외주가 바뀌고, 운영 담당이 바뀌고, “이 색 살짝만 연하게” 요청이 쌓이면서 애써 맞춘 대비가 슬금슬금 무너집니다.

그래서 접근성을 ’사후 검사’로 지키려 하면 반드시 샙니다. 지속 가능한 유일한 방법은 ’설계’로 지키는 것 — 즉 애초에 잘못된 조합을 만들기 어렵게 팔레트를 구성하는 것입니다. DS-003이 바로 그 접근입니다.

(2) 확장성 — 새 색이 필요해도 흔들리지 않는다

서비스가 커지면 색이 더 필요해집니다. 새 상태색, 새 강조색, 새 카테고리 색… 단계 체계가 잡혀 있으면, 새 색도 같은 단계 규칙(예: 0~100, 매직 넘버 간격)으로 찍어내면 됩니다. 체계 없이 그때그때 색을 추가하면, 추가될 때마다 팔레트가 누더기가 됩니다.

(3) 유지보수 — 한 번 바꿔도 전부 일관

단계가 설계돼 있으면 “본문을 한 단계 더 진하게”라는 결정도 체계적으로 반영됩니다. “여기저기 흩어진 회색을 다 찾아 고치는” 게 아니라, 단계 정의를 조정하면 전체가 일관되게 따라옵니다.

핵심: DS-003은 “색을 예쁘게”가 아니라 “접근성과 일관성을 매번 노력하지 않아도 유지되는 구조로 만들라” 는, 디자인 시스템의 근본 원리를 담은 규칙입니다.

비유로 이해하기 — 계단과 난간

단계별 색상 팔레트를 ’계단’에 비유하면 명확해집니다. 잘 만든 계단은 모든 단의 높이가 일정합니다. 그래서 사람들은 발밑을 일일이 확인하지 않고도 안전하게 오르내립니다. 만약 어떤 단은 5cm, 어떤 단은 25cm라면? 매번 발밑을 봐야 하고, 결국 누군가는 넘어집니다.

색상 단계도 똑같습니다. 단계 간격이 일정하고 대비가 보장되도록 설계된 팔레트는, 디자이너가 색을 고를 때마다 “이거 대비 괜찮나?”를 확인하지 않아도 됩니다 — 계단처럼 믿고 밟으면 됩니다. 반대로 단계가 들쭉날쭉한 팔레트는 매번 발밑(대비)을 확인해야 하고, 바쁘면 건너뛰고, 결국 접근성이 무너집니다.

DS-002(개별 색의 대비)가 “이 계단 한 칸이 안전한가”라면, DS-003은 “계단 전체가 일정하게 설계됐는가” 입니다. 한 칸씩 검사하는 것보다, 계단 자체를 제대로 만드는 게 근본 해법입니다. 그리고 한 번 잘 만든 계단은 모두가 평생 안전하게 씁니다.

3. ’단계별 색상’이란 정확히 무엇인가

색상 시스템을 처음 접하면 “단계”라는 말이 막연합니다. 구체적으로 풀어봅시다.

하나의 색 = 하나의 ‘명도 사다리’

현대 디자인 시스템에서 ’파랑’은 색 하나가 아니라 연함부터 진함까지 이어지는 사다리입니다.

blue-5 ▏아주 연한 하늘색 → 연한 배경, 강조 영역 바탕 blue-10 ▏연한 파랑 → 배경, 비활성 면 blue-30 ▏중간 연한 파랑 → 보조 요소 blue-50 ▏기준 파랑(Base) → 핵심 색, 버튼 (가장 대표) blue-70 ▏진한 파랑 → hover, 강조 텍스트 blue-90 ▏아주 진한 파랑 → 진한 배경 위 강조

뒤의 숫자가 명도 단계입니다. 보통 숫자가 작을수록 밝고, 클수록 어둡습니다(시스템에 따라 반대인 경우도 있습니다). 이렇게 한 계열을 단계로 펼쳐두면, 상황에 맞는 명도의 색을 같은 계열 안에서 골라 쓸 수 있습니다. 배경엔 연한 단계, 그 위 글자엔 진한 단계 — 이렇게요.

왜 ’단계’가 접근성과 직결되나

여기가 핵심입니다. 두 색의 명도 대비는, 두 색의 ’단계 차이’와 거의 비례합니다. 단계가 멀수록(밝은 것과 어두운 것) 대비가 큽니다. 그래서 단계를 대비 기준에 맞춰 일정 간격으로 설계해 두면, “어느 단계와 어느 단계를 조합하면 4.5:1이 나온다”가 공식처럼 정해집니다.

KRDS가 2편에서 본 매직 넘버로 한 일이 정확히 이것입니다. 단계 간 차이를 수치화해서, 단계 빼기만으로 대비를 알 수 있게 만든 것이죠. DS-003은 그 매직 넘버 체계가 팔레트 전체에 적용돼 있느냐를 봅니다.

단계가 화면에서 하는 일 — 위계와 깊이

단계별 색상은 접근성만을 위한 게 아닙니다. 화면의 위계(hierarchy)와 깊이감도 단계가 만듭니다. 이걸 이해하면 “왜 색 하나로는 부족한가”가 분명해집니다.

잘 만든 화면을 떠올려 봅시다. 가장 진한 색은 제목과 핵심 행동에, 중간 단계는 본문에, 연한 단계는 보조 설명과 비활성 요소에, 가장 연한 단계는 배경과 구획에 쓰입니다. 사용자는 이 명도의 차이만으로 “무엇이 중요하고 무엇이 부차적인지”를 무의식적으로 읽어냅니다. 진한 것에 먼저 눈이 가고, 연한 것은 배경으로 물러납니다. 이게 시각적 위계입니다.

만약 색이 단계 없이 한두 개뿐이라면? 모든 게 비슷한 명도로 평평해지고, 사용자는 “어디를 먼저 봐야 할지” 길을 잃습니다. 반대로 단계가 잘 설계돼 있으면, 디자이너는 같은 색 계열의 다른 단계를 골라 위계를 주는 것만으로 정돈된 화면을 만듭니다. 색을 새로 추가하지 않고도요.

깊이감도 마찬가지입니다. 카드가 배경 위에 살짝 떠 있는 느낌, 모달이 화면 앞으로 나온 느낌 — 이런 깊이는 명도 단계의 미묘한 차이로 표현됩니다(이건 뒤에 나올 ‘엘리베이션’ 항목과도 이어집니다). 단계가 촘촘할수록 이 깊이 표현이 자연스럽습니다.

그래서 단계별 팔레트는 접근성(대비) + 일관성(통일) + 표현력(위계·깊이) 을 한꺼번에 해결하는 도구입니다. DS-003이 단순한 ’기술 규칙’이 아니라 좋은 화면의 토대인 이유입니다. 색을 단계로 다루기 시작하면, 디자인의 품질 자체가 올라갑니다.

4. 의외로 어려운 문제 — ‘눈에 고르게 보이는 단계’ 만들기

“단계를 똑같은 간격으로 나누면 되는 거 아냐?”라고 생각하기 쉽지만, 여기에 함정이 있습니다. 컴퓨터가 계산하는 밝기와 사람 눈이 느끼는 밝기가 다르기 때문입니다.

사람 눈은 밝기를 ’제곱근’으로 느낀다

RGB 값을 기계적으로 10%씩 올린다고 해서, 사람 눈에 밝기가 10%씩 균등하게 밝아지는 게 아닙니다. 사람의 명도 지각은 대략 세제곱근 곡선을 따릅니다. 그래서 RGB를 균등 분할한 색 단계는 어두운 쪽은 뭉치고 밝은 쪽은 듬성한 불균형한 사다리가 됩니다. 이런 팔레트는 “단계가 있긴 한데 어딘가 어색한” 느낌을 줍니다.

그래서 ’인지적 명도’로 설계한다

좋은 색상 시스템은 단순 RGB가 아니라 인지 균등 색공간에서 단계를 만듭니다.

CIE L* — 0(검정)~100(흰색)의 ‘인지 밝기’ 축. 이 축에서 균등 분할하면 사람 눈에 고르게 보입니다.

OKLab / OKLCH — 비교적 최근 모델로, 특히 파랑·보라 계열의 색상 정확도와 명도 일관성이 뛰어나 요즘 디자인 시스템 색 스케일 생성에 널리 쓰입니다.

HSLuv 등 — 인지 균등성을 활용해 모든 색 계열에서 일관된 대비비를 갖도록 명도 단계를 정의.

핵심 한 줄: “단계는 RGB 산수가 아니라 ‘사람이 보는 밝기’ 기준으로 설계해야, 균등하고 대비도 일관된다.”

KRDS가 “색상(Hue)과 채도(Saturation)를 기준으로 명도(Lightness)를 13단계로 구분”한다고 명시한 것도 이 맥락입니다. 명도 축을 기준으로 단계를 설계해야 대비가 예측 가능해지기 때문입니다.

담당자가 이 색공간 이론까지 알 필요는 없습니다. 다만 “단계는 대충 나누는 게 아니라, 인지 밝기 기준으로 정교하게 설계되는 것” 이라는 점, 그리고 그 설계가 끝난 팔레트(KRDS 같은)를 쓰면 이 어려운 일을 안 해도 된다 는 점만 기억하면 됩니다.

5. KRDS의 단계 설계 — 13단계와 매직 넘버

KRDS는 이 단계 설계를 표준으로 못 박아 뒀습니다.

명도 13단계 / 11단계

“표준형 스타일의 색상 팔레트는 색상(Hue)과 채도(Saturation)를 기준으로 명도(Lightness)를 총 13단계로 구분하였으며, Gray의 0(White), 100(Black)을 제외한 다른 색상들은 11단계로 구성됩니다.”

Gray — 0(흰색)부터 100(검정)까지 13단계. 화면의 배경·텍스트·구분선 대부분을 책임지므로 가장 촘촘.

그 외 색 계열 — 0·100(순백·순흑)을 뺀 11단계.

매직 넘버가 단계 간격을 ’대비 기준’에 묶는다

2편에서 본 매직 넘버를 다시 봅시다. 이건 사실 “단계 간격을 대비 기준으로 환산한 표” 입니다.

단계 차이(매직넘버)	보장 대비비	의미
40	3 : 1	큰 글씨·UI
50	4.5 : 1	본문
70	7 : 1	본문 강화
90	15 : 1	선명한 화면 모드 본문

즉 KRDS 팔레트에서 두 색의 단계 번호 차이가 50 이상이면, 별도 계산 없이 본문 대비(4.5:1)가 보장됩니다. 이게 바로 DS-003이 말하는 “명도 대비 기준을 고려하여 단계별 색상을 설정” 의 완성형입니다. 단계 설계 안에 대비 기준이 내장된 것이죠.

세 규칙의 합류점: DS-001(팔레트 사용) · DS-002(대비 충족) · DS-003(단계 설계)은 결국 하나의 그림입니다 — “대비가 내장된 단계 팔레트를 설계해(003) 두고, 그걸 우선 써서(001), 자동으로 대비를 충족한다(002).” 색상 규칙의 핵심 삼각형입니다.

6. 해외 디자인 시스템의 단계 설계

단계별 색상 팔레트는 현대 디자인 시스템의 공통 문법입니다.

시스템	단계 표기	특징
🇰🇷 KRDS	0~100 (Gray 13단계 / 기타 11단계)	매직 넘버로 단계 차=대비비 환산
🇺🇸 USWDS	grade 0~100, 계열당 다수 단계	grade 차이로 대비 표현, “magnitude” 개념
Material Design	50, 100, 200 … 900	구글의 10단계 표준, 광범위 채택
Tailwind CSS	50, 100 … 900, 950	11단계, 웹 개발 사실상 표준

표기 숫자는 달라도(0~100이냐 50~900이냐) 발상은 동일합니다 — 하나의 색을 명도 단계로 펼치고, 그 단계로 대비·위계를 관리한다. KRDS의 차별점은 그 단계에 대비비를 직접 환산하는 매직 넘버를 결합해, 접근성 충족을 더 기계적으로 만들었다는 점입니다.

즉 DS-003은 “한국 정부만의 특이 요구”가 전혀 아니라, 민간·해외를 막론한 현대 디자인 시스템의 기본기를 공공 영역에 명문화한 것입니다.

왜 지금 ’단계’가 표준이 되었나 — 짧은 진화사

단계별 색상 팔레트가 처음부터 당연했던 건 아닙니다. 웹 초창기에는 색을 다루는 방식이 지금과 완전히 달랐습니다. 디자이너가 “이 버튼은 파란색”이라고 하면, 개발자가 #0066FF 같은 값을 화면마다 직접 적어 넣었습니다. 색은 화면 하나하나에 박힌 고정된 숫자였고, 같은 ’파랑’이라도 페이지마다 미묘하게 달랐으며, 브랜드 색을 바꾸려면 수백 군데를 손으로 찾아 고쳐야 했습니다.

2014년 무렵 구글이 Material Design을 내놓으면서 흐름이 바뀌었습니다. 색을 50·100·200…900처럼 명도 단계로 체계화하고, 그 단계를 이름으로 관리하는 방식이 확산됐습니다. 이어서 ‘디자인 토큰’ 개념이 자리 잡으면서, 색은 더 이상 화면에 박힌 숫자가 아니라 의미를 가진 이름(color-primary, gray-60)이 됐습니다. 단계와 토큰은 한 쌍으로 진화했습니다 — 단계가 ’무엇을 고를지’를 정리해 주고, 토큰이 ’어떻게 부를지’를 정리해 준 것이죠.

이 진화의 동력은 두 가지였습니다. 첫째는 규모입니다. 서비스가 수백 개 화면으로 커지자, 색을 일일이 관리하는 건 불가능해졌고 체계가 필수가 됐습니다. 둘째는 접근성입니다. 웹 접근성이 법적 요구로 강해지면서, “대비가 보장된 색을 고르는 일”을 매번 사람이 하는 대신 팔레트 설계에 한 번 녹여두는 방식이 합리적임이 분명해졌습니다.

KRDS는 이 10여 년의 진화가 도달한 결론을 공공 표준으로 받아들인 것입니다. 그래서 DS-003을 지키는 일은 ’한국 정부의 까다로운 신규 요구를 따르는 것’이 아니라, 이미 업계가 검증을 끝낸 베스트 프랙티스를 도입하는 것에 가깝습니다. 늦게 도입할수록 손해이고, 일찍 도입할수록 이후 모든 작업이 편해집니다. 단계별 팔레트는 ’추가 비용’이 아니라 ’미래의 비용을 줄이는 투자’입니다.

7. 잘못된 단계 설계 — 흔한 실패 패턴

자체 팔레트를 만들 때 자주 나오는 실패들입니다. (KRDS 팔레트를 그대로 채택하면 대부분 자동 회피됩니다.)

단계가 너무 적다 — “파랑은 진한 거 하나면 되지” 하고 1~2단계만 둠. 그러면 연한 배경이 필요할 때 결국 팔레트 밖 색을 즉흥적으로 뽑게 되고(→ DS-001 위반), 대비도 들쭉날쭉해집니다.

명도가 한쪽에 몰림 — 단계가 6개인데 전부 중간~진한 영역에 몰려 있음. 밝은 배경용 색이 없어 화면이 답답하거나, 역시 임의 색을 끌어다 씀.

단계 간격이 불균등 — 인지 명도를 고려 안 해, 어떤 단계 차는 대비가 충분하고 어떤 차는 부족. “같은 2단계 차이인데 어떤 조합은 읽히고 어떤 조합은 안 읽히는” 혼란.

채도만 다르고 명도는 비슷 — 색은 여러 개인데 밝기가 다 비슷함. 겹쳐 놓으면 대비가 안 나옴 (색맹 사용자에겐 거의 같은 색).

대비 기준을 사후에 끼워맞춤 — 일단 예쁜 색으로 팔레트를 만든 뒤 “대비 통과하는 조합만 쓰자”고 함. 결국 쓸 수 있는 조합이 적어 운영이 어려움. 설계 단계에서 대비를 고려했어야 함(=DS-003의 요구).

공통 교훈: 단계는 ’예쁜 색 모음’이 아니라 ’대비가 보장되는 도구 세트’로 설계해야 합니다.

8. 무엇을 점검하나

DS-003은 개별 색이 아니라 팔레트의 구조를 봅니다.

팔레트의 존재 — 색이 토큰(디자인 변수)으로 정의돼 있는가, 아니면 화면에 흩어진 생 HEX뿐인가.

단계 구성 — 주요 색 계열이 연함~진함의 다단계로 정의돼 있는가. 단계 수가 충분한가.

단계 간 대비 — 인접/주요 단계 조합이 명도 대비 기준(본문 4.5:1 등)을 만족하도록 간격이 설계됐는가.

KRDS 단계와의 정합 — 단계 체계가 KRDS 규격(Gray 13 / 기타 11, 매직 넘버)과 매핑되는가.

이 항목은 운영 사이트의 화면을 훑는 것만으로는 100% 판정이 어렵고, 팔레트(토큰) 정의 자체를 함께 봐야 정확합니다. 그래서 ‘디자인 시스템 문서/토큰 점검’ 성격이 강한 항목입니다.

9. 누가 담당하나

역할	책임
디자인 시스템 담당 / 리드 디자이너	팔레트의 단계 체계 설계(또는 KRDS 채택 결정) — 이 항목의 주인
퍼블리셔 / 프론트 개발	설계된 단계를 토큰(CSS 변수 등)으로 정확히 구현
접근성 담당	단계 간 대비가 기준을 충족하는지 검증

DS-001·002가 ’쓰는 사람 모두’의 책임이었다면, DS-003은 디자인 시스템을 설계하는 소수의 책임입니다. 그래서 한 번 잘 설계해 두면, 나머지 모두가 그 위에서 편하게 일하게 됩니다. 레버리지가 가장 큰 항목이죠.

10. 우리 사이트에 해당될까?

적용 대상

기관 유형	DS-003 적용
중앙행정기관(대표)	✅ KRDS 표준 팔레트 채택
중앙행정기관(운영)	✅ 자체 팔레트면 단계 설계 필요, KRDS 채택 시 자동 충족
공공기관	✅ 동일
지방자치단체	✅ 동일

핵심: ’직접 설계하느냐’가 갈림길

KRDS 팔레트를 그대로 채택하면 → DS-003은 사실상 자동 충족입니다. 단계 설계와 대비 보장이 이미 KRDS 안에 들어 있으니까요. 가장 쉽고 안전한 길입니다.

자체 브랜드 팔레트를 설계하면 → 그 팔레트가 단계별로 구성되고, 단계 간격이 대비 기준을 고려했는지 직접 책임져야 합니다. 자유를 얻는 대신 설계 책임이 따라옵니다.

즉 대부분의 기관에게 가장 합리적인 답은 “KRDS 팔레트(또는 그 단계 체계)를 채택하고, 브랜드색만 같은 단계 규칙으로 얹는 것” 입니다. 바퀴를 다시 발명할 필요가 없습니다.

자체 설계가 위험한 이유 — ‘디자인은 됐는데 시스템은 없는’ 함정

실무에서 가장 흔한 함정이 있습니다. 외주 업체가 멋진 시안을 만들어 왔고, 화면도 예쁩니다. 그런데 그 색들이 ’단계 체계’로 정리돼 있지 않은 경우가 대부분입니다. 시안의 파랑은 그 화면에서만 예쁜 한 컷의 색일 뿐, 연함~진함의 사다리로 설계된 게 아닙니다.

이런 사이트는 처음엔 문제가 없어 보입니다. 하지만 시간이 지나면 반드시 터집니다. 새 페이지를 추가할 때 필요한 명도의 색이 팔레트에 없어서 “비슷한 색을 새로 뽑고”, 담당자가 바뀌면서 “이 파랑이 좀 칙칙하니 살짝 바꾸고”, 캠페인 배너 때문에 “이번만 다른 톤을 쓰고” — 이렇게 단계 체계 없는 색이 누적되면서 사이트는 서서히 누더기가 됩니다. 그리고 그 시점엔 이미 손대기 어려울 만큼 색이 흩어져 있습니다.

그래서 DS-003은 ‘지금 예쁜가’가 아니라 ’계속 일관될 수 있는 구조인가’ 를 묻습니다. 자체 설계를 택한다면 — 시안의 아름다움만 검수하지 말고, 그 색들이 단계 토큰으로 체계화됐는지를 반드시 함께 확인해야 합니다. 발주 RFP에 “색상 팔레트를 단계별 디자인 토큰으로 구성하고 KRDS 매직 넘버 기준 대비를 충족할 것”을 명시하는 것이 가장 확실한 방법입니다. 막연한 “KRDS 준수”보다 훨씬 강력한 기준이 됩니다.

예외(N/A)

색을 쓰는 모든 사이트가 팔레트를 필요로 하므로, 이 항목 자체가 N/A 되는 경우는 드뭅니다. 다만 점검 대상이 디자인 파일/토큰 단계라, 운영 사이트만으로는 ’단계 설계 여부’를 부분적으로만 판정할 수 있습니다.

11. 단계별 개선 방법

가장 빠른 길 — KRDS 단계 채택

/* KRDS Gray 단계(예시)를 토큰으로 도입 — 0(흰)~100(검) 13단계 개념 */ :root { --gray-0: #ffffff; --gray-5: #f7f8f9; --gray-10: #eef0f2; --gray-30: #c5c8cc; --gray-50: #8a8e94; --gray-60: #6b6f76; /* 본문: 흰 배경과 매직넘버 60 → 대비 충분 */ --gray-90: #1c1f22; --gray-100: #000000; } /* 사용 시: 배경 gray-5 + 본문 gray-60 → 단계 차 55 ≥ 50 → 4.5:1 보장 */

자체 스케일을 검증하려면

주요 색 계열을 최소 7~11단계로 펼친다.

인지 명도(L*/OKLCH) 기준으로 단계를 균등 분할한다.

배경용 단계 ↔ 본문용 단계 조합이 4.5:1을 넘는지 검증한다.

검증된 단계 조합을 시맨틱 토큰(--color-text-default 등)으로 고정해, 쓰는 사람이 단계를 직접 고르지 않게 한다.

정비 우선순위

① Gray 단계부터 정비(화면 대부분 차지) → ② Primary 단계 → ③ System(상태) 색 단계 → ④ Secondary/기타

12. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 우리 ’파랑/회색’은 하나의 값인가요, 연함~진함 여러 단계인가요?

□ 그 단계들이 토큰(변수) 으로 정의돼 있나요?

□ 배경용 연한 단계와 본문용 진한 단계 조합이 대비 기준을 넘나요?

□ 새 색이 필요할 때 같은 단계 규칙으로 추가하나요, 즉흥적으로 뽑나요?

□ 우리 단계가 KRDS 단계(0~100, 매직넘버)와 매핑되나요?

❓ FAQ

Q1. 단계가 꼭 13개여야 하나요? KRDS 표준은 Gray 13 / 기타 11단계입니다. 자체 설계라면 최소 7단계 이상을 권장하지만, KRDS를 채택하면 이 고민이 사라집니다. 중요한 건 ’개수’보다 단계 간격이 대비를 보장하느냐입니다.

Q2. 우리는 색이 2~3개뿐인데 단계가 필요한가요? 화면에는 생각보다 많은 명도가 필요합니다(배경·면·테두리·텍스트·강조). 단계가 없으면 결국 임의 색을 끌어다 쓰게 됩니다. 색 ’개수’가 적어도 각 색의 ’단계’는 필요합니다.

Q3. 매직 넘버니 OKLCH니, 디자이너가 이걸 다 알아야 하나요? 아니요. KRDS 팔레트를 채택하면 이 이론은 몰라도 됩니다. 이미 그렇게 설계된 색을 가져다 쓰는 것이니까요. 직접 새 팔레트를 설계할 때만 깊이 들어가면 됩니다.

Q4. 운영 중인 사이트인데, 토큰이 없어요. DS-003 위반인가요? ’단계 설계된 팔레트의 부재’는 개선 대상입니다. 다만 한 번에 다 바꾸기보다, Gray 단계부터 토큰화하며 점진적으로 체계를 세우면 됩니다. 1편의 토큰 도입과 함께 진행하면 효율적입니다.

Q5. 브랜드색이 강렬한데, 단계로 펼치면 흐려지지 않나요? 브랜드색은 보통 Base 단계(예: 50) 에 두고, 그보다 밝은/어두운 단계를 파생시킵니다. 브랜드의 정체성은 Base가 지키고, 파생 단계는 배경·hover·강조 등 보조 역할을 합니다. 강렬함은 유지됩니다.

13. 마무리 — 좋은 팔레트는 ‘노력을 구조로 대체한다’

DS-003의 메시지는 한 문장으로 압축됩니다.

접근성과 일관성을 ’매번의 노력’이 아니라 ’한 번의 설계’로 해결하라.

대비를 매번 계산하는 팀과, 대비가 내장된 단계 팔레트를 한 번 설계해 둔 팀은 — 시간이 갈수록 격차가 벌어집니다. 후자는 색을 고를 때마다 접근성을 다시 고민하지 않습니다. 구조가 대신 지켜주기 때문입니다. 그리고 대부분의 공공기관에게 그 ’한 번의 설계’는 KRDS 팔레트를 채택하는 것으로 이미 끝나 있습니다.

다음 편에서는 이 단계 설계의 가장 구체적인 규격으로 들어갑니다. DS-004 — “색상과 채도를 기준으로 명도를 총 13단계로 구분하고, Gray의 0·100을 제외한 색상들을 11단계로 구분하여 팔레트를 구성하고 있다.” 오늘 큰 틀로 본 ’단계’가, 정확히 몇 단계로 어떻게 쪼개지는지 그 규격을 해부합니다.

다음 편 예고 ▶ 「004. 색상과 채도를 기준으로 명도를 총 13단계로 구분하고… 11단계로 구분하여 색상 팔레트를 구성하고 있다.」

우리 팔레트가 ’단계별 + 대비 보장’으로 설계됐는지 확인하려면? ViewCheck는 사이트가 실제 사용하는 색을 KRDS 표준 단계 팔레트에 역매핑해, 단계 체계가 잡혀 있는지· 단계 간 대비가 기준을 만족하는지·팔레트 밖 임의 색이 섞였는지를 함께 진단합니다.

📚 참고 출처

KRDS 색상(Color) 스타일 가이드 (13/11단계·매직넘버) — https://www.krds.go.kr/html/site/style/style_02.html

KRDS 디자인 토큰 가이드 — https://www.krds.go.kr/html/site/style/style_07.html

U.S. Web Design System — System color tokens (grade) — https://designsystem.digital.gov/design-tokens/color/system-tokens/

Programming Design Systems — Perceptually uniform color spaces (CIE L*) — https://programmingdesignsystems.com/color/perceptually-uniform-color-spaces/

OKLab/OKLCH 색상 스케일 설계 참고 — https://oklchpicker.com/