아무 색이나 쓰면 왜 안 될까

KRDS DS-001 — 주요 색상 외에 색상이 필요할 경우 색상 팔레트에 있는 색상 값을 우선으로 사용하고 있다.

이 시리즈는 행정·공공기관이라면 한 번쯤 들어봤을 KRDS(디지털 정부서비스 UI/UX 가이드라인) 의 846개 점검 항목을, 담당자가 실제로 이해하고 적용할 수 있도록 한 항목씩 깊게 풀어내는 콘텐츠입니다. 그 846개의 첫 번째 항목, DS-001부터 시작합니다.

0. 들어가며 — 846개 중 가장 먼저 만나는 규칙

홈페이지를 새로 만들거나 개편할 때, 공공기관 담당자가 가장 먼저 부딪히는 질문이 있습니다.

“우리 기관 색을 그냥 우리가 정하면 안 되나요?”

결론부터 말하면 — 반은 맞고 반은 틀립니다. 기관의 상징색(브랜드색)은 가질 수 있습니다. 하지만 그 색을 ‘아무 값이나’ 정하는 것, 그리고 버튼·경고·배경·구분선에 쓸 나머지 색들을 그때그때 디자이너 감각으로 뽑아 쓰는 것은 안 됩니다. 바로 이 원칙을 한 문장으로 못 박은 항목이 846개 중 첫 번째, DS-001입니다.

이 글 하나만 제대로 읽으면, 색상과 관련된 KRDS 규칙(DS-001부터 DS-026까지 26개)을 관통하는 ’사고방식’이 잡힙니다. 단순히 “이 규칙을 지켜라”가 아니라, 왜 전 세계 정부 디자인 시스템이 하나같이 ’색상 팔레트를 우선 사용하라’고 못 박는지를 함께 짚겠습니다.

1. 규칙 원문 — 한 글자씩 뜯어보기

먼저 DS-001의 공식 점검 문장입니다.

DS-001 (디자인 스타일 > 색상) “주요 색상 외에 색상이 필요할 경우 색상 팔레트에 있는 색상 값을 우선으로 사용하고 있다.”

짧지만 단어 하나하나에 의미가 있습니다. 분해해 봅시다.

“주요 색상(Primary color)”

화면에서 가장 눈에 띄어야 할 핵심 색입니다. KRDS는 이를 정부 상징색에서 가져온 정부 청색을 디지털에 최적화한 색으로 정의합니다. “신청하기”, “제출”, “다음 단계” 같은 핵심 행동 버튼과 중요한 강조에 쓰는 색이죠.

“주요 색상 외에 색상이 필요할 경우”

여기가 핵심입니다. 실제 화면은 메인 색 하나로 굴러가지 않습니다.

배경은 흰색·연회색

본문 글자는 진회색

구분선은 연한 회색

경고 메시지는 빨강, 성공 메시지는 초록

보조 버튼은 메인보다 약한 색

비활성(disabled) 요소는 흐릿한 회색

이렇게 메인 색이 아닌 색이 필요한 순간이 화면마다 수십 번 옵니다. DS-001은 바로 그 순간을 겨냥합니다.

“색상 팔레트에 있는 색상 값을 우선으로 사용”

“팔레트(palette)”란 KRDS가 미리 정의해 둔 색상표입니다. 화가의 팔레트처럼, 쓸 수 있는 색이 이미 번호와 값으로 정해져 있습니다. DS-001은 추가 색이 필요할 때 즉흥적으로 #3a7bd5 같은 값을 뽑지 말고, 이 색상표 안에서 골라 쓰라는 뜻입니다.

핵심 키워드는 “우선(優先)” 입니다. “무조건 팔레트만”이 아니라 “팔레트를 1순위로”입니다. 정말 불가피하게 팔레트 밖 색이 필요하면 예외를 둘 수 있되, 그건 마지막 수단이어야 한다는 의미입니다.

2. 왜 이게 중요한가 — ’색은 감각’이라는 착각

대부분의 사람은 색을 감각의 영역으로 생각합니다. “이게 더 예쁘다”, “이 파랑이 더 신뢰감 있다”처럼요. 그런데 잘 설계된 디지털 서비스에서 색은 감각이 아니라 시스템입니다. DS-001이 지키려는 가치는 크게 세 가지입니다.

(1) 통일성 — 흩어진 정부서비스를 하나로

국민 한 사람이 1년 동안 접속하는 정부·공공 사이트는 수십 개입니다. 정부24, 국세청 홈택스, 건강보험공단, 시청, 구청, 각종 공단·공사…. 이 사이트들의 파랑이 전부 미묘하게 다르면, 사용자는 무의식적으로 “여기는 또 다른 곳”이라고 느끼고 매번 새로 학습해야 합니다.

반대로 색상 팔레트가 통일되면, 사용자는 “이 파란 버튼은 핵심 행동”, “이 빨강은 경고”라는 학습을 한 번만 하면 모든 정부서비스에 그대로 적용할 수 있습니다. 이게 범정부 디자인 시스템(KRDS)이 존재하는 근본 이유입니다.

(2) 접근성 — 팔레트는 ‘이미 검증된 색’

이게 의외로 가장 중요한 이유입니다. KRDS 팔레트의 색들은 아무렇게나 고른 게 아니라, 명도 대비 기준을 통과하도록 설계된 값입니다.

KRDS는 색상 단계를 ‘매직 넘버(Magic Number)’ 라는 영리한 장치로 관리합니다. 색상 팔레트의 명도 단계 간 차이를 수치화해서, 두 색의 매직 넘버 차이만 보면 명도 대비를 곧바로 알 수 있게 한 것입니다.

두 색의 매직넘버 차이	명도 대비(Contrast Ratio)	의미
40	3:1	큰 글씨·UI 요소 최소 기준 (WCAG AA)
50	4.5:1	본문 텍스트 최소 기준 (WCAG AA)
70	7:1	강화 기준 (WCAG AAA)
90	15:1	최고 대비 (선명한 화면 모드 본문)

즉, 팔레트 안의 색을 규칙대로 조합하면 명도 대비 계산을 따로 안 해도 접근성이 보장됩니다. 반대로 디자이너가 감각으로 뽑은 임의의 회색 글씨는, 보기엔 세련돼도 저시력자나 밝은 야외에서 안 보이는 접근성 위반이 되기 쉽습니다. (참고: WCAG 2.1 성공기준 1.4.3은 본문 4.5:1, 큰 글씨 3:1을 요구합니다.)

핵심: “팔레트를 쓰라”는 건 단순한 디자인 취향 강요가 아니라, 접근성을 자동으로 보장받는 가장 쉬운 길입니다.

(3) 유지보수 — 색 하나 바꾸려고 수백 페이지를 고치는 악몽

색상값을 페이지마다 #3a7bd5처럼 하드코딩해 두면, 나중에 브랜드 색이 바뀌거나(기관 통폐합, CI 개편) “이 파랑이 너무 어둡다”는 피드백 하나에 수백 개 화면, 수천 줄 CSS를 일일이 찾아 고쳐야 합니다.

팔레트(디자인 토큰)를 쓰면 다릅니다. color-primary라는 이름표 하나만 바꾸면 그 색을 참조하는 모든 화면이 동시에 업데이트됩니다. 업계에서는 이 방식이 유지보수 생산성을 최소 5배 이상 끌어올린다고 봅니다.

3. 한 걸음 더 — ’색상 팔레트’는 사실 ’디자인 토큰’이다

DS-001을 제대로 이해하려면 디자인 토큰(Design Token) 개념을 알아야 합니다. 어렵지 않습니다.

과거 협업 방식은 이랬습니다.

디자이너 → 개발자: “이 버튼은 #0066FF로 해주세요.”

지금의 방식은 이렇습니다.

디자이너 → 개발자: “이 버튼은 color-primary로 해주세요.”

0066FF라는 날것의 값(하드코딩) 대신 color-primary라는 의미 있는 이름(토큰) 을 주고받는 것. 이게 디자인 토큰의 핵심입니다. 토큰은 보통 두 계층으로 나뉩니다.

Primitive 토큰 (원자 토큰): 색 그 자체. KRDS의 primary-50, gray-70, red-50 같은 것. 0~100 단계로 정의되며, 직접 화면에 쓰지는 않습니다.

Semantic 토큰 (의미 토큰): 역할·맥락을 가진 이름. color-text-default, color-border-divider, color-action-primary 같은 것. Primitive를 참조해서 정의합니다. 화면에는 이걸 씁니다.

DS-001에서 말하는 “색상 팔레트에 있는 색상 값”이 바로 이 Primitive/Semantic 토큰 체계입니다. “팔레트를 우선 사용한다”는 건 결국 “임의 HEX를 박지 말고 토큰을 참조해서 쓴다”는 개발/디자인 실무 원칙과 정확히 같은 말입니다.

4. 색상 팔레트 해부 — KRDS는 색을 이렇게 나눈다

“팔레트를 쓰라”고 했으니, 그 팔레트가 실제로 어떻게 생겼는지 알아야 합니다. KRDS 색상 팔레트는 크게 4개 계열 + 투명도(Alpha) + 모드로 구성됩니다. 이 구조를 알면 DS-001부터 DS-026까지 색상 규칙 전체가 한눈에 들어옵니다.

(1) Primary — 정부의 얼굴, 핵심 행동의 색

정부 상징을 구성하는 정부 청색을 디지털 UI에 최적화한 색입니다. KRDS는 Primary를 이렇게 정의합니다.

“UI의 중요한 요소를 표현하는 primary의 색상은 명도와 채도를 높여 시각적으로 눈에 띄도록 하고… 인터페이스에서 가장 주목받는 요소로 주요 액션이나 중요한 정보를 강조하는 데 사용”

“신청하기”, “제출”, “다음” 같은 사용자가 눌러야 할 핵심 버튼과 활성 링크가 Primary의 자리입니다.

(2) Secondary — 신뢰감을 받치는 보조의 색

“전체적인 UI의 톤을 표현하는 secondary의 색상은 신뢰감과 안정감을 줄 수 있는 안정적인 톤으로 사용… 덜 중요한 액션을 표시하거나 구분을 위한 배경으로 사용”

Primary가 ’주연’이라면 Secondary는 ’조연’입니다. 보조 버튼, 강조가 덜한 영역, 구분용 배경 등에 쓰여 화면 전체의 톤을 잡아줍니다.

(3) Gray — 화면의 90%를 책임지는 무채색

가장 많이 쓰이지만 가장 눈에 안 띄는 색입니다.

“주로 배경, 텍스트, 구분 선에 사용”

Gray는 0(White)부터 100(Black)까지 13단계로 정의됩니다. 본문 글자는 진한 Gray(예: gray-90), 보조 설명은 중간 Gray(gray-50), 배경은 연한 Gray(gray-10), 구분선은 더 연한 Gray… 이런 식으로 같은 회색 계열의 서로 다른 단계를 골라 씁니다. “회색이 다 거기서 거기”가 아니라, 단계마다 명도 대비가 계산된 정밀한 도구입니다.

(4) System — 상태를 말하는 색 (가장 많이 틀리는 부분)

사용자에게 상황·상태를 전달하는 색입니다. KRDS는 4가지로 구분합니다.

System 색	역할	대표 색 계열
Danger	오류·위험 표시	빨강 계열
Warning	잠재적 위험·주의	주황/노랑 계열
Success	완료·긍정 결과	초록 계열
Information	참고 정보·안내	파랑 계열

각 System 색은 아이콘·텍스트·배경·보더 색이 한 세트로 정의됩니다. DS-001 위반이 가장 자주 터지는 곳이 바로 여기입니다 — “경고니까 그냥 빨강”, “성공이니까 그냥 초록”으로 감각적인 값을 박아버리기 때문이죠. 상태색이야말로 팔레트(System 토큰)를 우선 써야 하는 영역입니다.

(5) Alpha — 5단계 투명도

겹쳐지는 요소(모달 뒤 어두운 막, 비활성 처리, 반투명 구분선)에는 불투명한 색이 아니라 투명도가 들어간 색을 씁니다.

“다양한 배경 색상과 콘텐츠에 자연스럽게 융화되는 데 도움이 되는 Alpha 색상은 5단계 투명도를 사용… BG, Text, Line에 사용”

이 투명도도 5단계로 표준화돼, 겹쳐지는 요소들이 일관된 깊이감을 갖습니다. (별도 항목 DS-010에서 더 깊게 다룹니다.)

(6) 기본 모드 vs 선명한 화면 모드

KRDS는 같은 팔레트를 두 가지 모드로 제공합니다.

기본 모드: 일반 사용자를 위한 표준 색상 모드

선명한 화면 모드: 색상 대비를 높여 시각 접근성을 강화한 모드 (저시력·고령 사용자 대응)

예를 들어 배경 색은 모드에 따라 정반대로 흐릅니다.

	기본 모드 (밝아짐)	선명한 화면 모드 (어두운 바탕)
배경 elevation	Gray10 → Gray0 → Gray5 → Gray0	Gray90 → Gray100 → Gray95 → Gray90

→ 핵심은 두 모드 모두 같은 팔레트 체계 안에서 정의된다는 것. 모드가 달라도 “팔레트를 우선 쓴다”는 DS-001 원칙은 그대로 유지됩니다.

여기까지의 결론: KRDS 팔레트는 단순한 색 목록이 아니라 Primary(강조) · Secondary(보조) · Gray(중립 13단계) · System(상태 4종) · Alpha(투명도 5단계) × 2개 모드로 짜인 정교한 체계입니다. DS-001의 “팔레트를 우선 쓰라”는, 이 체계 안에서 색을 고르라는 뜻입니다.

5. 비교 연구 — 한국만 유난인 게 아니다

“색상 팔레트를 우선 쓰라”는 원칙이 한국 정부만의 까다로운 요구일까요? 전혀 아닙니다. 전 세계 정부 디자인 시스템이 똑같은 원칙을 못 박고 있습니다.

🇺🇸 미국 — USWDS (U.S. Web Design System)

미국 연방정부 표준 디자인 시스템입니다. USWDS는 색을 시스템 토큰(24개 색상 계열) 으로 정의하고, 각 색은 red-50, blue-warm-60v처럼 계열명 + 등급(grade) 으로 이름 붙입니다. 등급은 0(순백)~100(순흑) 의 100점 척도로 명도를 표현합니다. KRDS의 0~100 단계와 발상이 똑같죠.

또한 USWDS는 색 사용 비율을 primary 60% : secondary 30% : accent 10% 의 비례 관계로 권장합니다. (네, KRDS의 60:30:10과 동일합니다. 뒤에서 다시 나옵니다.)

🇬🇧 영국 — GOV.UK Design System

영국 정부 디자인 시스템의 색상 문서 첫 문장이 이겁니다.

“Always use the GOV.UK colour palette.” (항상 GOV.UK 색상 팔레트를 사용하세요.)

그리고 한 줄 더.

“Do not copy the hex values.” (16진수 값을 직접 복사하지 마세요.)

대신 govuk-colour("blue") 같은 함수(=토큰) 로 색에 접근하라고 안내합니다. DS-001과 표현만 다를 뿐 완전히 같은 요구입니다. 임의 HEX 금지, 팔레트/토큰 우선.

정리: 세 나라가 같은 말을 한다

구분	🇰🇷 KRDS	🇺🇸 USWDS	🇬🇧 GOV.UK
핵심 원칙	팔레트 색상값 우선 사용	시스템 토큰에서 테마 구성	항상 팔레트 사용, HEX 복사 금지
색 명도 척도	0~100 (13단계, 기타 11단계)	0~100 grade	tints/shades
접근 방식	디자인 토큰	디자인 토큰	Sass 함수
색 배분	60 : 30 : 10	60 : 30 : 10	—

→ DS-001은 글로벌 표준입니다. “우리 기관만 특별히 까다로운 규칙을 받았다”가 아니라, 선진국 정부가 공통으로 채택한 베스트 프랙티스를 한국이 도입한 것입니다.

6. 현장에서 자주 보이는 위반 패턴

실제 점검을 해 보면, DS-001 위반은 대개 아래 5가지 패턴으로 나타납니다. 우리 사이트에 해당하는 게 있는지 떠올려 보세요.

패턴 ① 페이지마다 흩어진 생(生) HEX 값

가장 흔합니다. 디자인 시안에서는 색이 통일돼 있었는데, 퍼블리싱·개발 과정에서 페이지마다 조금씩 다른 값이 박힙니다.

/* ❌ 위반: 같은 '파랑'인데 페이지마다 값이 다름 */ .page-a .btn { background: #0a6cff; } .page-b .btn { background: #0b6dfe; } .page-c .btn { background: #1170ff; }

사람 눈엔 다 같은 파랑이지만, 시스템 관점에선 3개의 서로 다른 색입니다. 통일성도, 유지보수성도 깨집니다.

패턴 ② 외부 라이브러리·템플릿이 끌고 들어온 색

부트스트랩, 무료 관리자 템플릿, jQuery 플러그인 등이 자기 기본색(#007bff 같은)을 그대로 화면에 주입하는 경우입니다. 담당자는 인지조차 못 하는데 팔레트 밖 색이 곳곳에 깔립니다.

패턴 ③ “조금만 더 진하게” 요구로 생긴 변종 색

“이 회색이 너무 연하니 살짝만 진하게 해주세요”라는 요청이 반복되면서, 팔레트의 gray-50도 gray-60도 아닌 어중간한 회색이 태어납니다. 명도 대비 보장이 깨지는 전형적인 경로입니다.

패턴 ④ 상태 색(빨강·초록)의 임의 사용

경고는 빨강, 성공은 초록인데 그 빨강·초록을 KRDS System 색이 아니라 감각으로 뽑는 경우. 색약 사용자 대응(뒤에서 설명)과도 직결되는 문제입니다.

패턴 ⑤ 그라데이션·이미지 배경 속 텍스트 색

배너 그라데이션이나 사진 위에 글자를 얹으면서, 그 글자색을 팔레트 밖에서 즉흥적으로 정하는 경우. 대비가 깨지기 가장 쉬운 지점입니다.

다섯 패턴의 공통점: “누가 일부러 위반한 게 아니라, 관리 체계가 없어서 새어 든다” 는 것입니다. 그래서 DS-001은 ’한 번 고치고 끝’이 아니라 ‘팔레트(토큰)라는 관리 체계를 세웠는가’ 의 문제입니다.

7. 무엇을 어떻게 점검하나 — 자동 점검의 원리

그럼 DS-001은 실제로 어떻게 ’판정’할까요? 점검 도구(ViewCheck 같은) 관점에서 원리는 이렇습니다.

1단계 — 사이트의 모든 색상값 수집

페이지의 CSS를 전부 읽어, 실제로 사용된 색상값(HEX, RGB, RGBA, HSL)을 빠짐없이 추출합니다. color, background-color, border-color, box-shadow, fill(SVG) 등 색이 들어가는 모든 속성이 대상입니다.

2단계 — KRDS 팔레트 토큰과 대조

수집한 색값을 KRDS가 정의한 1,000여 개 색상 토큰 목록과 1:1로 매칭합니다.

팔레트 안의 값과 일치 → ✅ 통과

팔레트에 없는 임의 값 → ⚠️ 위반 후보

3단계 — 근접 색 분석

0a6cff처럼 팔레트 색과 미세하게 다른 값은, 가장 가까운 팔레트 색을 찾아 “의도한 색에서 얼마나 벗어났는지” 를 계산합니다. 이렇게 하면 “원래 primary-50을 쓰려다 살짝 어긋난 것”인지, “완전히 동떨어진 색”인지 구분됩니다.

4단계 — 위치·빈도 리포트

팔레트 밖 색이 어느 요소에, 몇 군데, 어떤 색으로 쓰였는지 목록화합니다. 담당자는 이 목록만 보고 정비 우선순위를 정할 수 있습니다.

직접 점검하려면: 브라우저 개발자도구(F12)에서 요소를 클릭해 Computed 탭의 color / background-color 값을 확인하고, 그 값이 우리 디자인 토큰 문서의 색과 같은지 비교하면 됩니다. 다만 수백 페이지를 손으로 하는 건 비현실적이라, 보통 자동 도구를 씁니다.

8. 누가 담당하나 — R&R과 협업 흐름

DS-001은 한 사람의 문제가 아닙니다. 색이 화면에 도달하기까지 거치는 손이 여러 개이기 때문입니다.

단계	담당	할 일	흔한 실수
1. 팔레트 정의	디자인 시스템 담당 / 디자이너	KRDS 팔레트 채택 또는 브랜드색을 토큰으로 정의	토큰 없이 시안에만 색 지정
2. 시안 작성	UI 디자이너	팔레트 안에서만 색 선택	“이번 한 번만” 팔레트 밖 색 사용
3. 퍼블리싱	퍼블리셔 / 프론트 개발	토큰(CSS 변수)으로 구현, HEX 직박 금지	시안 색을 HEX로 그대로 복붙
4. 운영·수정	운영 담당 / 외주	수정 시에도 토큰 사용	급한 수정에 임의 색 추가

핵심은 2번과 3번 사이, 3번과 4번 사이에서 색이 새어 든다는 것입니다. 그래서 DS-001을 지키려면 “디자이너가 잘하면 된다”가 아니라, 토큰 체계를 세우고 → 퍼블리싱 규칙으로 강제하고 → 운영 단계까지 유지하는 전 과정 합의가 필요합니다.

9. 우리 사이트에 해당될까? — 적용 대상과 수준

이 시리즈의 핵심 목적입니다. “우리 기관은 이 규칙을 지켜야 하나?”

적용 대상 — 4개 기관 유형 모두 해당

KRDS는 적용 대상을 4가지로 나눕니다(출처: KRDS 적용 대상 및 기준).

기관 유형	DS-001 적용	비고
① 중앙행정기관 (대표)	✅ 필수	정부 상징 로고 사용. 정부 청색 기반 팔레트 그대로
② 중앙행정기관 (운영 서비스·시스템)	✅ 필수	독자 브랜드색 허용. 단 Primary만 대체, 나머지는 팔레트 우선
③ 공공기관	✅ 필수	동일. 브랜드색은 Primary로, 보조·중립·상태색은 팔레트
④ 지방자치단체	✅ 필수	동일

→ 색을 쓰는 모든 공공 웹/앱은 예외 없이 DS-001 대상입니다. “우리는 색을 안 쓴다”는 사이트는 존재하지 않으니까요.

다만 유연성이 있습니다. 독자 로고(브랜드)를 쓰는 ②③④ 유형은 Primary를 자기 브랜드색으로 대체 할 수 있습니다. 강원도청의 초록, 어떤 공사의 주황처럼요. 하지만 그 브랜드색조차 토큰으로 정의해야 하고, 그 외의 보조색·회색·상태색(빨강·초록 등)은 KRDS 팔레트를 우선 써야 합니다.

적용 수준 — DS 항목은 ‘스타일 가이드 준수’

KRDS는 서비스 패턴(SP) 영역에 한해 필수·권장·우수 3단계 적용 수준을 둡니다. 색상이 속한 디자인 스타일(DS) 은 이 3단계 구분 대상이 아니라, ‘스타일 가이드 준수’ 항목으로서 4개 기관 유형 모두에 공통 적용됩니다. 즉 DS-001은 “상황 봐서”가 아니라 기본 준수 대상입니다.

이 규칙이 ’예외(N/A)’가 되는 경우

이 시리즈 내내 중요한 개념입니다. KRDS 체크리스트에는 ‘미사용’ 칸이 있습니다. 해당 요소를 안 쓰면 그 규칙은 예외(N/A) 처리됩니다 — 이게 ViewCheck가 자동으로 걸러내는 부분이기도 합니다.

DS-001의 경우, 색을 안 쓰는 웹은 없으므로 예외 처리가 거의 불가능합니다. 즉 대부분의 사이트에서 ‘반드시 판정되는’ 규칙입니다. (반대로 뒤에 나올 “모달 투명도”, “캐러셀” 같은 규칙은 해당 컴포넌트가 없으면 깔끔하게 예외 처리됩니다.)

10. 단계별 개선 방법 — Before / After

위반을 발견했다면, 어떻게 고칠까요? 현실적인 순서로 정리합니다.

Step 1. 토큰(팔레트) 먼저 정의한다

가장 먼저 할 일은 색을 줍는 게 아니라 색 체계를 세우는 것입니다. KRDS 팔레트를 그대로 도입하거나, 브랜드색이 있으면 그것을 Primary 토큰으로 얹습니다.

/* ✅ After: 팔레트를 CSS 변수(토큰)로 정의 */ :root { /* Primitive (원자) — KRDS 팔레트 채택, 브랜드색은 primary만 대체 */ --primary-50: #0a6cff; /* 우리 기관 대표 파랑 */ --gray-90: #1a1a1a; /* 본문 글자 */ --gray-50: #8c8c8c; /* 보조 텍스트 */ --gray-10: #f2f2f2; /* 배경 */ --red-50: #e53935; /* 경고/오류 (System) */ --green-50: #2e7d32; /* 성공 (System) */ /* Semantic (의미) — 역할에 원자 토큰을 연결 */ --color-action-primary: var(--primary-50); --color-text-default: var(--gray-90); --color-text-muted: var(--gray-50); --color-bg-subtle: var(--gray-10); --color-state-danger: var(--red-50); --color-state-success: var(--green-50); }

Step 2. 화면 코드에서 생 HEX를 토큰으로 치환한다

/* ❌ Before: 페이지마다 흩어진 임의 색 */ .btn-submit { background: #0b6dfe; } .notice-text { color: #999; } .divider { border-color: #e8e8e8; } /* ✅ After: 전부 토큰 참조 */ .btn-submit { background: var(--color-action-primary); } .notice-text { color: var(--color-text-muted); } .divider { border-color: var(--color-bg-subtle); }

Step 3. 외부 라이브러리 기본색을 덮어쓴다

부트스트랩 등이 끌고 온 기본색은 변수 오버라이드로 팔레트에 맞춥니다.

/* 부트스트랩 primary를 우리 토큰으로 강제 */ :root { --bs-primary: var(--color-action-primary); }

Step 4. ’예외 색’은 문서로 남긴다

정말 불가피하게 팔레트 밖 색을 써야 하면(예: 외부 브랜드 로고의 고유색), 왜 예외인지 사유를 문서화 합니다. KRDS 체크리스트의 ‘예외’ 칸이 바로 이 용도입니다. 사유 없는 예외는 그냥 위반입니다.

정비 우선순위

전수 정비가 부담된다면 이 순서를 권합니다. ① 본문 텍스트 색(가독성 직결) → ② 핵심 버튼/링크 색(행동 유도) → ③ 상태색(빨강·초록) → ④ 구분선·배경 → ⑤ 장식 요소

11. 30초 자가진단 + 자주 묻는 질문(FAQ)

✅ 30초 자가진단 체크리스트

아래 5개 중 “아니오”가 하나라도 있으면 DS-001 점검이 필요합니다.

□ 우리 사이트 색이 CSS 변수(토큰)로 관리되나요? (페이지마다 생 HEX가 흩어져 있지 않나요?)

□ 같은 ’파랑’이 사이트 전체에서 동일한 값인가요?

□ 본문 글자색이 배경과 충분히 또렷한가요? (연회색 글씨 남발 ✕)

□ 경고(빨강)·성공(초록) 색이 KRDS System 색과 같은가요?

□ 디자인 가이드 문서에 ’우리 색상 팔레트’가 정의돼 있나요?

❓ FAQ

Q1. 우리 기관 고유 색(브랜드색)을 못 쓰는 건가요? 아니요. 쓸 수 있습니다. 다만 그 브랜드색을 Primary 토큰으로 정의하고, 나머지 보조·중립·상태색은 KRDS 팔레트를 우선 쓰면 됩니다. “브랜드색 금지”가 아니라 “체계 없이 아무 색이나 금지”입니다.

Q2. 이미 운영 중인 사이트인데 전부 다 바꿔야 하나요? 한 번에 다 할 필요는 없습니다. 위 ’정비 우선순위’대로 가독성·접근성에 직접 영향을 주는 본문·버튼색부터 단계적으로 정비하면 됩니다. 토큰 체계를 먼저 세우면 이후 정비가 훨씬 빨라집니다.

Q3. 디자이너가 “이 색이 더 예쁘다”는데요? 색의 ’예쁨’과 ’시스템 준수’는 충돌하지 않습니다. KRDS 팔레트는 1,000여 개 색을 13단계 명도로 제공해서, 그 안에서도 충분히 세련된 조합이 가능합니다. 진짜 문제는 ’예쁜 색’이 아니라 ’검증 안 된 색’입니다.

Q4. 명도 대비를 일일이 계산해야 하나요? 팔레트를 매직 넘버 규칙대로 쓰면 계산이 필요 없습니다. 본문은 배경과 매직넘버 차이 50(=4.5:1) 이상, 큰 글씨는 40(=3:1) 이상이 되도록 단계를 고르면 자동으로 WCAG AA를 충족합니다.

Q5. 다크모드/선명한 화면 모드는요? DS-001은 일반 모드의 팔레트 사용 원칙입니다. 선명한 화면 모드는 별도 항목(DS-005 등)에서 다루며, 거기서도 원칙은 같습니다 — 모드별 팔레트를 미리 정의해 두고 그 안에서 쓴다.

Q6. 외주 업체가 만든 사이트라 우리가 CSS를 못 건드립니다. 그렇더라도 DS-001 준수 책임은 발주 기관에 있습니다. 가장 현실적인 방법은 유지보수 계약·차기 개편 RFP에 “KRDS 색상 팔레트(디자인 토큰) 적용”을 명시하는 것입니다. 점검 도구로 위반 목록을 뽑아 업체에 전달하면, 모호한 “예쁘게 해주세요”가 아니라 구체적 수정 지시서가 됩니다.

Q7. 색이 몇 개나 팔레트 안에 있나요? 너무 적으면 표현이 제한되지 않나요? KRDS 팔레트는 계열별 명도 단계까지 합치면 1,000여 개의 색상 토큰을 제공합니다. Primary·Secondary· Gray·System 각 계열이 0~100단계로 세분돼 있어, 그 안에서도 충분히 다양하고 세련된 조합이 가능합니다. ’제한’이라기보다 ’검증된 선택지’에 가깝습니다.

Q8. 점검에서 ’위반’이 나왔는데, 정말 다 고쳐야 하나요? 위반의 ’성격’을 봐야 합니다. ① 본문·버튼처럼 가독성/행동에 직접 영향을 주는 색은 우선 수정 대상입니다. ② 외부 로고의 고유색처럼 불가피한 예외는 사유를 문서화하면 됩니다. 모든 위반을 0으로 만드는 게 목적이 아니라, ’관리되지 않는 색’을 ’관리되는 색’으로 전환하는 게 목적입니다.

12. 마무리 — DS-001이 던지는 진짜 질문

DS-001은 표면적으로 “팔레트 색을 우선 쓰라”는 단순한 규칙입니다. 하지만 그 안에 담긴 진짜 질문은 이것입니다.

“당신의 기관은 색을 ’감각’으로 다루고 있습니까, ’시스템’으로 다루고 있습니까?”

색을 시스템으로 다루는 순간, 통일성·접근성·유지보수성이 한꺼번에 따라옵니다. 그리고 이건 한국만의 요구가 아니라 미국(USWDS)·영국(GOV.UK)이 똑같이 못 박은 글로벌 정부 디자인 표준입니다.

846개 규칙의 첫 항목을 색상 팔레트로 시작하는 이유가 여기 있습니다. 색을 시스템으로 보기 시작하면, 나머지 845개도 자연스럽게 ’시스템의 언어’로 읽히기 때문입니다.

다음 편(2편)에서는 DS-002 — 명도 대비를 다룹니다. 오늘 잠깐 등장한 ’매직 넘버’와 ’WCAG 4.5:1’이 실제 화면에서 어떻게 점검되는지, 가장 흔한 접근성 위반을 어떻게 잡아내는지 깊게 들어가 봅니다.

우리 사이트는 846개 중 무엇에 해당하고, 무엇을 놓치고 있을까? ViewCheck는 URL 하나만 넣으면 사이트 전체 CSS의 색상값을 자동 수집해 KRDS 팔레트와 1:1로 대조하고, 팔레트 밖 색이 어디에 몇 군데 쓰였는지까지 짚어줍니다. DS-001을 포함한 846개 항목을 한 번에 점검할 수 있습니다.

📚 참고 출처

KRDS 색상(Color) 스타일 가이드 — https://www.krds.go.kr/html/site/style/style_02.html

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

KRDS 적용 대상 및 기준 — https://www.krds.go.kr/html/site/utility/utility_07.html

WCAG 2.1 Understanding 1.4.3 Contrast (Minimum) — https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum

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

GOV.UK Design System — Colour — https://design-system.service.gov.uk/styles/colour/