KRDS 체크리스트란 무엇인가

KRDS INTRO — 디지털 정부서비스 UI/UX 가이드라인 ‘KRDS’ 점검 체크리스트란 무엇인가?

00. 디지털 정부서비스 UI/UX 가이드라인 ‘KRDS’ 점검 체크리스트란 무엇인가?

〈846 규칙 완전 분해 시리즈 — 프롤로그(00편)〉 846개의 점검 항목을 하나씩 파헤치기 전에, “그 846개가 대체 무엇이고 왜 지켜야 하는지”부터 정리합니다.

0. 들어가며 — “우리 사이트, KRDS 맞춰야 한다는데요?”

어느 날 공공기관 담당자의 메일함에 이런 공문이 도착합니다.

“홈페이지 개편 시 범정부 UI/UX 디자인시스템(KRDS) 을 준수하시기 바랍니다.”

담당자는 검색을 합니다. KRDS 사이트에 들어가 보니 색상·타이포그래피·컴포넌트·패턴… 방대한 가이드라인이 펼쳐집니다. 그리고 어딘가에서 “846개 점검 항목” 짜리 체크리스트 엑셀을 받습니다. 열어보면 줄줄이 적힌 점검 문장들. 담당자의 머릿속에 떠오르는 질문은 대개 이렇습니다.

이게 법으로 강제되는 건가, 권장인가?

846개를 우리 사이트에 다 적용해야 하나?

우리 기관(시청? 공단? 부처?) 에는 뭐가 해당되나?

이걸 누가, 어떻게 점검하나?

이 시리즈는 바로 그 막막함을 풀기 위해 시작합니다. 846개를 한 항목씩, 누구나 이해할 수 있게 풀어내되, 그 첫걸음으로 이번 프롤로그에서는 “KRDS 체크리스트라는 것의 정체” 를 끝까지 정리하겠습니다. 이 글 하나면 위 네 가지 질문에 모두 답할 수 있습니다.

1. KRDS란 무엇인가 — 정부가 만든 ‘디자인 표준’

정식 명칭과 주관

KRDS는 KoRea Design System의 약자이며, 한글 정식 명칭은 「범정부 UI/UX 디자인시스템」 입니다. 공식적으로는 「디지털 정부서비스 UI/UX 가이드라인」 이라는 이름으로 불립니다.

항목	내용
영문명	KoRea Design System (KRDS)
한글명	범정부 UI/UX 디자인시스템 / 디지털 정부서비스 UI/UX 가이드라인
주관	행정안전부 (디지털플랫폼정부위원회 협력)
수행	한국지능정보사회진흥원(NIA) + PULIP 컨소시엄
정식 개시	2025년 1월 16일
공식 사이트	https://www.krds.go.kr

한마디로 정의하면

KRDS는 “대한민국 디지털 정부 서비스의 편의성·일관성·접근성·사용성을 보장하기 위해 설계된 디자인 시스템” 입니다.

쉽게 말하면, 정부·공공기관이 웹사이트나 앱을 만들 때 따라야 할 ‘디자인 표준 설명서’ 입니다. 색은 어떻게, 버튼은 어떻게, 폼은 어떻게, 로그인·검색·신청 화면은 어떻게 — 이 모든 것을 통일된 규격으로 정리해 둔 것이죠.

왜 ’KR’이 붙었나 — 해외 정부 디자인시스템과 KRDS

미국에는 USWDS(U.S. Web Design System), 영국에는 GOV.UK Design System이 있습니다. 선진국 정부는 이미 오래전부터 “정부서비스는 하나의 일관된 경험이어야 한다”는 원칙 아래 자국 디자인 시스템을 운영해 왔습니다. KRDS는 그 대한민국(KoRea) 버전입니다. 즉 한국만의 유난스러운 규제가 아니라, 글로벌 정부 디자인 표준의 한국판입니다.

구분	🇰🇷 KRDS	🇺🇸 USWDS	🇬🇧 GOV.UK Design System
주관	행정안전부	미국 연방총무청(GSA)	영국 정부 디지털서비스(GDS)
색 체계	0~100 명도 단계, 디자인 토큰	0~100 grade, 24개 색 계열	팔레트 + tints/shades
색 배분 원칙	60 : 30 : 10	60 : 30 : 10	—
핵심 원칙	“팔레트 색상값을 우선 사용”	“시스템 토큰에서 테마 구성”	“Always use the colour palette”
접근성	WCAG 기반 명도 대비	WCAG 기반	WCAG 2.2 1.4.3 AA

세 시스템을 비교하면 놀라울 만큼 같은 말을 하고 있습니다. “색은 팔레트(토큰)로 관리하라”, “명도 대비로 접근성을 보장하라”, “컴포넌트를 표준화하라”. KRDS의 846개 규칙도 이 글로벌 공통 원칙 위에 서 있습니다. 이 시리즈에서 각 규칙을 다룰 때, 가능한 한 해외 정부 디자인시스템의 같은 원칙을 함께 비교해 드리는 이유가 여기 있습니다 — “한국만 까다로운 게 아니다”를 보여주기 위해서입니다.

KRDS는 ‘완성품’이 아니라 ’계속 진화하는 표준’

한 가지 중요한 점 — KRDS는 한 번 만들고 끝난 문서가 아닙니다. 지속적으로 개정되는 살아있는 표준입니다.

시점	내용
2023년~	행정안전부·NIA·PULIP 컨소시엄이 개발 착수
2024년	가이드라인·디자인 키트 순차 공개
2025년 1월 16일	범정부 UI/UX 디자인시스템(KRDS) 정식 개시
이후	가이드라인·체크리스트 주기적 개정 (분기 단위 버전 업데이트)

자체 검증 체크리스트도 마찬가지로 버전이 올라갑니다. 항목의 표현이 다듬어지거나, 새 컴포넌트가 추가되기도 합니다. 그래서 점검할 때는 항상 최신 버전의 체크리스트를 기준으로 삼아야 합니다. 이 시리즈 역시 최신 체크리스트(846개 기준)를 토대로 작성합니다. — 표준이 바뀌면, 해당 편도 갱신할 수 있도록 설계했습니다.

2. 왜 만들었나 — ’제각각 정부서비스’라는 오랜 문제

KRDS가 등장하기 전, 국민이 겪던 문제를 떠올려 봅시다.

A 부처 사이트의 ‘신청’ 버튼은 파란색, B 공단 사이트는 초록색, C 시청은 주황색

로그인 위치가 사이트마다 제각각

어떤 곳은 글씨가 너무 작고, 어떤 곳은 색 대비가 약해 잘 안 보임

같은 ‘검색’ 기능인데 사이트마다 모양도 동작도 다름

국민 한 사람이 1년에 접속하는 정부·공공 사이트는 수십 개입니다. 그런데 사이트마다 사용법을 새로 배워야 한다면, 그건 명백한 시간 낭비이자 불편입니다. 특히 고령자·저시력자·디지털 취약계층에게는 ’접근 자체가 어려운 벽’이 됩니다.

KRDS의 개발 목적은 공식 문서에 이렇게 명시돼 있습니다.

“국민이 다양한 공공 웹·앱을 직관적이고 일관성 있게 사용함으로써 불필요한 시간 낭비를 줄이고, 범정부 차원에서 효율적인 UI/UX 개발 체계를 구축하기 위해 본 가이드라인을 개발하게 되었습니다.”

정리하면 KRDS의 목표는 세 가지입니다.

일관성 — 어느 정부 사이트를 가도 같은 방식으로 쓸 수 있게

접근성 — 누구나(고령·장애·취약계층 포함) 쓸 수 있게

효율성 — 각 기관이 매번 디자인을 새로 만들지 않고 표준을 재사용하게

3. 법적 위상 — 권장인가, 의무인가?

담당자가 가장 궁금해하는 부분입니다. 결론부터: 단순 권장을 넘어, 법령·지침에 근거한 ‘준수 대상’ 입니다.

KRDS 가이드라인은 다음 세 가지에 근거합니다.

근거	성격
「전자정부법」	전자정부 서비스의 기본 법률
「행정기관 및 공공기관 정보시스템 구축·운영 지침」	정보시스템 구축 시 따라야 할 행정규칙
「전자정부 웹사이트 품질관리 지침」	공공 웹사이트 품질(7대 영역) 관리 기준

공식 문서의 표현은 이렇습니다.

“디지털 정부서비스 UI/UX 가이드라인은 「전자정부법」, 「행정기관 및 공공기관 정보시스템 구축·운영 지침」, 「전자정부 웹사이트 품질관리 지침」에 따라 행정기관 및 공공기관이 준수해야 할 디지털 정부서비스 UI/UX에 대한 세부 사항을 제시합니다.”

핵심 단어는 “준수해야 할” 입니다. 즉, “예쁘게 하면 좋은 가이드”가 아니라 기관이 따라야 할 기준 입니다. 특히 신규 구축·개편 사업에서는 RFP(제안요청서)와 품질 점검의 기준으로 작동합니다.

다만 현실적 관점: 846개를 ’하나라도 어기면 위법’이라는 식의 경직된 규제는 아닙니다. 뒤에서 설명할 적용 대상·적용 수준·예외(N/A) 개념을 통해, 기관 유형과 서비스 성격에 맞게 단계적으로 적용하도록 설계돼 있습니다. “지켜야 하지만, 우리 상황에 맞게”가 정확한 표현입니다.

KRDS와 ’공공 웹사이트 7대 품질 영역’의 관계

세 번째 근거인 「전자정부 웹사이트 품질관리 지침」 은 공공 웹사이트가 갖춰야 할 품질을 7대 영역으로 규정합니다. KRDS가 이 큰 그림 안에서 어디에 위치하는지 알면, 846개의 ’의미’가 더 분명해집니다.

품질 영역	무엇을 보는가	KRDS 846과의 관계
호환성	HTML/CSS 표준, 여러 브라우저 호환	컴포넌트 표준 구현(CP)과 연계
접근성	누구나 쓸 수 있는가 (KWCAG)	색 대비·대체텍스트·키보드 등 전 영역에 녹아 있음
개방성	robots/메타데이터/크롤링 허용	직접 항목은 적으나 헤더·구조와 연관
접속성	가용성·응답 시간	성능 영역(별도 측정)
편의성	사용자 편의 기능	기본 패턴(BP)·서비스 패턴(SP) 의 핵심
효율성	페이지 로딩 성능	별도 성능 측정
신뢰성	SSL·개인정보처리방침·보안	푸터·정책 링크 등과 연관

→ KRDS 846개 체크리스트는 이 7대 영역 중 특히 ‘접근성·편의성’, 그리고 디자인 통일성을 가장 깊게 다룹니다. 즉 “예쁜 디자인”의 문제가 아니라 국가가 정한 공공 웹 품질 기준의 핵심 축이라는 뜻입니다.

4. KRDS가 제공하는 것 — ’가이드라인’과 ’체크리스트’는 다르다

KRDS는 말로만 된 가이드가 아니라, 실제로 쓸 수 있는 자산 묶음을 제공합니다.

디자인 라이브러리 — 컴포넌트, 스타일 가이드

디자인 토큰 — 색·간격·서체 등을 이름으로 관리하는 체계(Primitive / Semantic / Component)

HTML 컴포넌트 키트 — 실제 HTML·CSS·JavaScript 코드

디자인 리소스 — Figma / XD / Sketch 파일

문서 사이트 — 가이드라인·튜토리얼(krds.go.kr)

여기서 이 시리즈의 주인공인 ‘체크리스트’ 의 위치를 분명히 해둡시다.

가이드라인 = “이렇게 만드세요”라는 설명서 (방대한 원칙·예시)

체크리스트 = 그 가이드라인을 “지켰는지 점검하는 시험지” (846개 점검 문장)

즉 체크리스트는 가이드라인을 점검 가능한 형태로 항목화한 것입니다. 정식 명칭은 「디지털 정부서비스 UI/UX 가이드라인 자체 검증 체크리스트」. 이 846개 문장 하나하나가 바로 이 시리즈가 풀어낼 대상입니다.

5. 846개의 구조 — 4개 영역으로 나뉜다

체크리스트는 846개 항목을 4개 영역으로 나눕니다. 이 구조를 머릿속에 넣어두면 시리즈 전체가 한눈에 들어옵니다.

영역	코드	항목 수	무엇을 점검하나
디자인 스타일	DS	120	색상·타이포그래피·형태·레이아웃·아이콘·엘리베이션·선명한 화면 모드 — 디자인의 ‘기본 재료’
컴포넌트	CP	446	헤더·푸터·버튼·모달·표·달력 등 45종 UI 부품의 사용·구현 규칙
기본 패턴	BP	108	개인정보 입력·동의·오류 처리·필터/정렬 등 공통 상호작용 패턴
서비스 패턴	SP	172	방문·검색·로그인·신청·정책 정보 확인 등 서비스 흐름 시나리오
합계		846

각 영역을 한 문장으로

DS(디자인 스타일, 120개) — “재료를 표준대로 쓰는가?” 색·글꼴·간격 같은 가장 기초 단위.

CP(컴포넌트, 446개) — “부품을 표준대로 만들었는가?” 가장 항목이 많습니다. 버튼 하나, 모달 하나에도 여러 점검 항목이 붙습니다. 그만큼 담당자가 “우리 사이트에 이게 있나?”로 가장 직관적으로 판단할 수 있는 영역이기도 합니다.

BP(기본 패턴, 108개) — “공통 동작을 올바르게 처리하는가?” 폼 입력, 동의 받기, 오류 안내처럼 화면 종류를 가리지 않고 반복되는 상호작용.

SP(서비스 패턴, 172개) — “사용자의 일 처리 흐름이 매끄러운가?” 로그인하고, 검색하고, 신청서를 내는 전체 여정. 가장 ‘서비스다운’ 영역입니다.

왜 CP가 446개로 압도적으로 많을까? UI는 결국 부품(컴포넌트)의 조합이기 때문입니다. 부품 하나가 잘못되면 그 부품이 쓰인 모든 화면이 영향을 받습니다. 그래서 컴포넌트 점검이 가장 촘촘합니다.

영역별 세부 분류 — 846개는 이렇게 쪼개진다

각 영역이 다시 어떤 하위 분류로 나뉘는지 보면, 시리즈의 ’지도’가 그려집니다.

① 디자인 스타일(DS) 120개 — 7개 분류

분류	항목 수	분류	항목 수
색상	26	아이콘	22
타이포그래피	16	엘리베이션(그림자·깊이)	10
형태	8	선명한 화면 모드	14
레이아웃	24

② 컴포넌트(CP) 446개 — 45종 UI 부품 공식배너·운영기관 식별자·헤더·푸터·건너뛰기 링크·메인 메뉴·브레드크럼·사이드 메뉴·페이지네이션·탭바· 구조화 목록·긴급 공지·달력·디스클로저·모달·배지·아코디언·이미지·캐러셀·탭·표·텍스트 목록·링크·버튼· 라디오 버튼·체크박스·셀렉트·태그·토글 스위치·단계 표시기·스피너·도움 패널·툴팁·날짜 입력·텍스트 영역· 텍스트 입력·파일 업로드·언어 변경·화면 크기 조정·접근 가능한 미디어·숨긴 콘텐츠 등 45종. → 부품 1종에 평균 약 10개의 점검 항목이 붙습니다.

③ 기본 패턴(BP) 108개 — 11개 패턴

패턴	항목 수	패턴	항목 수
입력 폼	17	도움	14
개인 식별 정보 입력	16	상세 정보 확인	11
필터링·정렬	16	목록 탐색	8
동의 / 오류	각 6	사용자 피드백 / 첨부파일	각 5
확인	4

④ 서비스 패턴(SP) 172개 — 5개 시나리오

시나리오	항목 수	설명
신청	58	신청서 작성·제출의 전 과정 (가장 많음)
검색	49	검색어 입력·결과·필터
로그인	42	인증·계정 접근
정책 정보 확인	14	정책·공지 열람 흐름
방문	9	첫 진입·메인 페이지 경험

→ 이 지도를 머릿속에 넣어두면, 매주 발행되는 글이 “지금 846개 중 어디쯤을 지나고 있는지” 감이 잡힙니다.

6. 적용 대상 — ’우리 기관’은 어디에 속하나

846개가 모든 기관에 똑같이 적용되는 건 아닙니다. KRDS는 기관을 4가지 유형으로 나누고, 유형별로 적용 기준에 차이를 둡니다. (출처: KRDS 적용 대상 및 기준)

#	기관 유형	대상	특징
1	중앙행정기관(대표)	정부 상징 로고를 쓰는 부·처·청의 대표 웹사이트	정부 상징색·공식 배너 등 가장 엄격
2	중앙행정기관(운영 서비스·시스템)	독자 브랜드를 쓰는 부처 소관 서비스·포털	브랜드색 허용, 단 표준 구조는 준수
3	공공기관	공공기관이 운영하는 대표 웹사이트·서비스·포털	헤더·푸터 배치 등 준수, 일부 선택
4	지방자치단체	지자체가 운영하는 웹사이트·서비스·포털	운영기관 식별자 등 선택 적용

핵심 차이는 ‘브랜드 색·로고를 얼마나 자유롭게 쓸 수 있는가’ 에 있습니다.

유형 1(대표 부처) 은 정부 상징(태극·정부 청색)을 그대로 따릅니다. 가장 엄격합니다.

유형 2·3·4 는 독자 로고·브랜드색을 쓸 수 있습니다. 단, 그 경우에도 헤더·푸터의 배치, 컴포넌트 구조, 기본/서비스 패턴은 표준을 따라야 합니다.

예: 어떤 시청이 자기 상징색(예: 녹색)을 메인 색으로 쓰는 것은 허용됩니다(유형 4). 하지만 그 색을 체계 없이 아무 값이나 쓰는 것, 헤더·푸터 구조를 제멋대로 바꾸는 것은 안 됩니다. — 바로 다음 편부터 나올 규칙들이 이 지점을 점검합니다.

7. 적용 수준 — 필수 · 권장 · 우수

또 하나 중요한 개념이 적용 수준 입니다. KRDS는 특히 서비스 패턴(SP) 의 사용성 가이드라인에 대해 3단계 적용 수준을 둡니다.

수준	의미	안 지키면?
필수	핵심 서비스가 갖춰야 할 최소 기준	작업 실패로 직접 이어짐. 사용자가 스스로 일을 끝낼 방법이 없음
권장	더 많은 사용자의 만족도를 높이는 실용 기준	작업 난도는 올라가지만, 실패하진 않음
우수	만족도를 기하급수적으로 끌어올리는 매력 기준	불편하거나 비효율적인 절차를 경험할 수 있음

핵심 원칙은 **“가장 낮은 수준인 ‘필수’부터 먼저 지키고, 서비스 상황에 맞게 권장→우수로 확장”** 하는 것입니다. 또 하나 — 상위 수준을 지켰다고 해서 하위가 자동 보장되는 게 아닙니다. 대부분의 ’우수’ 가이드는 ’필수·권장’이 지켜진 상태에서야 효과를 냅니다.

참고: 이 필수/권장/우수 3단계는 주로 서비스 패턴(SP) 에 적용됩니다. 디자인 스타일(DS)·컴포넌트 (CP)·기본 패턴(BP)은 ‘스타일 가이드 준수’ 항목으로서 기관 유형에 따라 공통 적용됩니다. 즉 영역마다 ‘적용의 결’ 이 조금씩 다릅니다.

8. 어떻게 점검하나 — ’자체 검증 체크리스트’의 사용법

이 846개는 ‘자체 검증(self-assessment)’ 을 전제로 만들어졌습니다. 실제 체크리스트 엑셀을 열면, 각 항목마다 다음과 같은 칸이 있습니다.

NO	점검 요소	구분	준수사항	미사용	준수	미준수	예외	비고

담당자는 각 항목을 보고 네 가지 중 하나로 표시합니다.

준수 — 우리 사이트가 이 항목을 지키고 있다 ✅

미준수 — 지키지 못하고 있다 ❌ (개선 대상)

미사용 — 해당 요소(컴포넌트·기능)가 우리 사이트에 아예 없다 → 점검 불필요

예외 — 불가피한 사유로 적용 못 함 (사유를 비고에 기재)

가장 중요한 개념: ‘미사용 = 예외(N/A)’

이 시리즈에서 반복해서 강조할 핵심입니다. 우리 사이트에 없는 컴포넌트의 규칙은 ’해당 없음(N/A)’으로 빠집니다.

예를 들어 ‘달력(Calendar)’ 컴포넌트 관련 규칙이 여러 개 있는데, 우리 사이트에 달력 기능이 없다면 그 규칙들은 미사용 = 예외 처리됩니다. 즉 846개 전부가 모든 사이트에 적용되는 게 아니라, 우리 사이트가 실제로 쓰는 요소에 해당하는 규칙만 점검 대상이 됩니다.

바로 이 부분이 자동 점검 도구(ViewCheck 같은)가 자동으로 걸러주는 영역입니다. 사이트를 분석해 “이 컴포넌트는 있고, 저건 없다”를 판별해, 없는 것의 규칙은 자동으로 예외(N/A) 처리합니다. 담당자가 846개를 일일이 “이건 우리한테 해당되나?” 고민할 필요를 줄여줍니다.

점검 방식도 여러 가지

체크리스트는 점검 대상을 ① 디자인 파일 ② HTML ③ 운영 중인 웹 서비스 ④ 기타 중에서 선택하도록 합니다. 즉 아직 개발 전 디자인 시안 단계에서도, 이미 운영 중인 사이트에서도 점검할 수 있습니다.

9. 그런데 — 846개를 사람이 손으로 다 점검할 수 있을까?

여기서 현실적인 벽에 부딪힙니다.

846개 항목 × 사이트의 모든 페이지 (수십~수백 페이지)

색상값 대조, 명도 대비 계산, ARIA 속성 확인, 컴포넌트 구조 검증…

이걸 사람이 눈으로 페이지마다 반복?

현실적으로 불가능에 가깝습니다. 간단한 산수를 해봅시다. 846개 항목을 한 사람이 항목당 1분씩만 본다고 해도 14시간이 넘습니다. 그런데 점검은 한 페이지가 아니라 사이트 전체(수십~수백 페이지) 를 대상으로 해야 하고, 색상값 대조나 명도 대비 계산처럼 눈으로는 정확히 판단하기 어려운 항목도 많습니다. 게다가 사이트는 계속 바뀌므로 점검은 한 번이 아니라 반복되어야 합니다.

그래서 이 846개는 두 가지 접근이 필요합니다.

이해 — 각 규칙이 무엇을 왜 점검하는지 담당자가 ‘개념적으로’ 아는 것 → 이 시리즈가 하는 일

자동 점검 — 실제 사이트를 기계가 훑어 846개를 자동 판정하는 것 → 점검 도구가 하는 일

이 둘은 어느 하나로 대체되지 않습니다. 이해 없이 자동 점검 결과만 보면 “왜 미준수인지, 어떻게 고치는지”를 모릅니다. 반대로 이해만 있고 자동 점검이 없으면 846개 × 수백 페이지를 감당할 수 없습니다.

이 시리즈는 1번을 책임집니다. 846개를 한 항목씩, 담당자의 언어로 풀어내서, “아, 우리 사이트의 이 부분이 이 규칙에 해당하는구나”를 스스로 알 수 있게 하는 것. 그게 목표입니다.

10. 이 시리즈를 읽는 법

발행 방식

규칙 1개 = 게시물 1개. 846개 규칙 → 846편의 글로 1:1 대응합니다. 묶지 않습니다.

순차 발행. DS(디자인 스타일) → CP(컴포넌트) → BP(기본 패턴) → SP(서비스 패턴) 순서로, 매주 10편씩 차례로 공개합니다.

번호는 발행 순서대로 001 ~ 846 통짜로 매깁니다.

매 편의 구성

각 편은 담당자가 실무에 바로 쓸 수 있도록 다음 흐름으로 짭니다.

규칙 원문을 한 글자씩 뜯어보기

왜 중요한가 (통일성·접근성·유지보수 관점)

국내외 사례·표준 비교 (KRDS 원문 + WCAG + USWDS/GOV.UK 등)

무엇을 어떻게 점검하나

누가 담당하나 (디자이너/퍼블리셔/개발/기획 R&R)

우리 사이트에 해당될까? (4기관 유형 × 적용 수준 × 예외 판단)

단계별 개선 방법 (Before/After)

30초 자가진단 + FAQ

이 시리즈가 답하려는 단 하나의 질문

“우리 사이트는 846개 중 무엇에 해당하고, 무엇을 지키고 있으며, 무엇을 고쳐야 하는가?”

이 질문에 담당자 스스로 답할 수 있게 되는 것 — 그게 846편의 최종 목표입니다.

11. 자주 묻는 질문 (FAQ)

Q1. 신규 구축 사업에만 적용되나요, 기존 운영 사이트도 대상인가요? 둘 다입니다. 신규 구축·개편 사업은 RFP 단계부터 KRDS 준수가 기준이 되고, 기존 운영 사이트도 품질 점검· 개선의 대상입니다. 다만 기존 사이트는 한 번에 전부가 아니라 접근성·편의성에 직접 영향을 주는 항목부터 단계적으로 개선하는 것이 현실적입니다.

Q2. 모바일 앱도 해당되나요? KRDS는 웹사이트와 모바일 웹·앱을 모두 적용 대상으로 명시합니다. 다만 본 가이드라인은 웹/모바일 웹 중심으로 작성됐고, 네이티브 앱 특화 인터페이스는 별도 자료(모바일 서비스 UI/UX 개선)를 함께 참고하도록 안내합니다.

Q3. 846개를 다 못 지키면 불이익이 있나요? ’846개 전부 100%’가 목표는 아닙니다. 적용 대상(기관 유형)·적용 수준(필수/권장/우수)·예외(미사용) 에 따라 우리 사이트에 실제 해당하는 항목만 점검 대상입니다. 핵심은 ‘필수’ 수준부터 지키고, 미준수 항목을 개선 계획에 반영하는 것입니다. 품질 점검에서 미흡 사항은 개선 권고로 이어집니다.

Q4. 디자인을 외주 업체에 맡겼는데, 우리가 직접 점검해야 하나요? 준수 책임은 발주 기관에 있습니다. 가장 효과적인 방법은 계약서·RFP에 “KRDS 준수”를 명시하고, 점검 결과(준수/미준수 목록)를 업체에 전달해 수정 지시의 근거로 삼는 것입니다. 막연한 “잘 만들어 주세요”가 아니라 항목 단위의 구체적 기준이 생깁니다.

Q5. 우리 기관 고유 브랜드 색·로고를 못 쓰는 건가요? 아닙니다. 유형 2·3·4(운영 서비스·공공기관·지자체)는 독자 브랜드색과 로고를 쓸 수 있습니다. 다만 그 색조차 체계(디자인 토큰)로 관리해야 하고, 헤더·푸터 구조나 컴포넌트·서비스 패턴은 표준을 따라야 합니다. “브랜드 금지”가 아니라 “체계 없는 자유 금지”입니다.

Q6. 체크리스트는 어디서 받나요? KRDS 공식 사이트(krds.go.kr)에서 가이드라인·디자인 키트·체크리스트 등 자산을 내려받을 수 있습니다. 체크리스트는 주기적으로 업데이트되므로(예: 분기별 개정), 최신 버전을 받아 점검하는 것이 좋습니다.

12. 마무리 — 이제, 첫 번째 규칙으로

여기까지가 KRDS 체크리스트의 정체입니다. 정리하면,

KRDS는 행정안전부가 주관하고 2025년 1월 정식 개시한 범정부 디자인 표준이며,

「전자정부법」 등에 근거해 기관이 준수해야 할 기준이고,

그 점검 도구가 846개 항목의 자체 검증 체크리스트이며,

846개는 DS·CP·BP·SP 4개 영역으로 나뉘고,

기관 유형(4종) · 적용 수준(필수/권장/우수) · 예외(미사용=N/A) 에 따라 우리 사이트에 해당하는 것만 점검하면 됩니다.

이제 막연한 “846개”가 조금은 손에 잡히실 겁니다. 다음 편부터 본격적으로, 그 846개를 1번부터 하나씩 풀어갑니다.

첫 번째 규칙은 디자인의 가장 기초 재료, 색상입니다.

다음 편 예고 ▶ 「001. 주요 색상 외에 색상이 필요할 경우 색상 팔레트에 있는 색상 값을 우선으로 사용하고 있다.」 — 공공 웹사이트가 ‘아무 색이나’ 쓰면 안 되는 이유를 깊게 파헤칩니다.

846개를 한 번에 점검해 보고 싶다면? ViewCheck는 URL 하나만 넣으면 사이트를 자동 분석해, 846개 항목 중 우리 사이트에 해당하는 규칙만 추려 준수/미준수를 판정하고, 없는 컴포넌트의 규칙은 자동으로 예외(N/A) 처리합니다. 손으로 846개를 훑는 대신, 결과부터 확인할 수 있습니다.

📚 참고 출처

KRDS 소개 — https://www.krds.go.kr/html/site/utility/utility_01.html

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

행정안전부 보도자료 「범정부 UI/UX 디자인시스템(KRDS)」 — https://www.mois.go.kr/

디지털 정부서비스 UI/UX 가이드라인 자체 검증 체크리스트 (846개 항목, DS 120 / CP 446 / BP 108 / SP 172)

KRDS #공공웹 #웹접근성 #KWCAG #장애인차별금지법 #정보접근성 #스크린리더 #전자정부 #공공웹사이트 #디지털포용 #접근성진단 #ViewCheck