KRDS 가이드라인(2025.08) 통독 가이드 — 어디부터 볼까

공공 웹사이트 일을 한 번이라도 맡아 본 분이라면, 어느 날 메일함에 "KRDS 가이드라인 준수해서 만들어 주세요"라는 한 줄이 떨어진 경험이 있으실 겁니다. 그 문장을 받고 KRDS 공식 사이트에 들어가 본 순간의 막막함도요. 가이드라인 PDF를 내려받았더니 파일 하나가 수백 페이지. 스크롤을 내려도 내려도 끝이 안 보이고, 표지를 넘기면 목차만 또 몇 장입니다. "이걸 다 읽으라고? 마감은 다음 주인데?" 한숨이 절로 나옵니다. 그러다 결국 적당히 앞부분 몇 장 훑고, 컴포넌트 그림 몇 개 보고, "대충 이런 느낌이구나" 하고 작업에 들어갑니다. 그게 현실이죠.

저도 처음엔 그랬습니다. 수백 페이지짜리 가이드라인을 정독한다는 건 비현실적이라고 생각했고, 실제로 그렇게 일하는 사람도 거의 못 봤습니다. 그런데 공공 사이트를 수백 개 분석하면서 깨달은 게 하나 있습니다. KRDS 가이드라인 PDF는 "처음부터 끝까지 읽는 소설"이 아니라 "필요할 때 펴 보는 사전"에 가깝다는 것. 그리고 이 두꺼운 문서에는 분명한 구조와 우선순위가 있어서, 어디부터 봐야 하는지만 알면 의외로 빠르게 핵심을 잡을 수 있다는 것입니다.

이 글은 KRDS 완전해부 시리즈 중에서도 좀 특별한 자리입니다. 다른 글들이 셀렉트, 아이콘처럼 개별 컴포넌트를 뜯어본다면, 이 글은 그 모든 컴포넌트의 기준이 담긴 원전(原典) 자체를 다룹니다. "디지털 정부서비스 UI/UX 가이드라인(2025.08판)"이라는 이 PDF를 어떻게 읽어야 하는지, 어디부터 봐야 하는지, 그리고 다 읽고 나서 내 사이트가 정말 그 기준을 지켰는지 어떻게 확인하는지까지요. 말하자면 "정답지 사용 설명서"입니다.

한 가지 미리 솔직하게 말씀드리면, 이 글을 다 읽는다고 가이드라인 PDF를 안 봐도 되는 건 아닙니다. 오히려 반대예요. 이 글의 목표는 여러분이 그 두꺼운 PDF를 덜 무서워하게 만드는 겁니다. 어디에 뭐가 있는지 지도를 손에 쥐여 드리면, 막막함이 "아, 그 부분 보면 되는구나"로 바뀌거든요. 그 지도 한 장 그려 드리는 게 이 글의 전부입니다.

KRDS 가이드라인 PDF란 무엇인가 — 정의부터

먼저 용어와 사실관계를 정확히 맞추고 가겠습니다. "KRDS"는 Korea Reference Design System, 즉 대한민국 정부가 공공 디지털 서비스의 화면을 일관되고 접근 가능하게 만들기 위해 정리한 공식 디자인 시스템입니다. 그리고 이 디자인 시스템은 한 덩어리 문서가 아니라, 여러 형태의 자산으로 제공됩니다.

• 가이드라인 PDF (문서): "디지털 정부서비스 UI/UX 가이드라인" — 디자인 원칙, 컴포넌트 정의, 사용 기준이 글과 그림으로 정리된 문서. 이 글의 주인공입니다.
• 컴포넌트 킷 (코드): GitHub KRDS-uiux/krds-uiux 저장소의 HTML/CSS/JS 코드. 가이드라인이 "이렇게 만들어라"라고 말한 걸 실제로 구현해 둔 것.
• 디자인 라이브러리 (Figma): 공식 Figma(@krds)에 있는 디자이너용 컴포넌트와 토큰.

여기서 핵심은 이 셋이 따로 노는 게 아니라 한 세트라는 점입니다. 가이드라인 PDF가 "헌법"이라면, 컴포넌트 킷은 그 헌법을 구현한 "코드 법전"이고, Figma는 "디자인 표준안"입니다. 셋 다 같은 기준을 가리키되, 보는 사람(기획자·개발자·디자이너)에 따라 입구가 다를 뿐입니다.

그렇다면 PDF는 왜 따로 있을까요? 코드만 있으면 안 되나요? 안 됩니다. 코드는 "어떻게(how)"를 말해 주지만 "왜(why)"는 말해 주지 않습니다. 어떤 컴포넌트를 언제 써야 하는지, 왜 이 색이 아니라 저 색을 써야 하는지, 어떤 상황에서 이 패턴이 부적절한지 — 이런 판단의 근거는 글로 된 가이드라인에만 담겨 있습니다. 코드는 결과물이고, PDF는 그 결과물에 이르는 사고 과정입니다. 그래서 개발자라도 "그냥 킷 가져다 쓰면 되지 PDF는 왜 봐?"라고 생각하면 절반만 아는 겁니다. 컴포넌트를 언제 어디에 쓸지는 PDF가 알려 주거든요.

"2025.08판"이라는 버전 표기의 의미

가이드라인 파일명에 붙은 "2025.08"은 그냥 날짜가 아니라 버전입니다. 디자인 시스템은 한 번 만들고 끝나는 게 아니라, 웹 환경과 접근성 기준이 바뀌면 함께 업데이트됩니다. 그래서 작업을 시작하기 전 가장 먼저 확인할 것이 "내가 보고 있는 PDF가 최신판인가"입니다. 1년 전에 내려받아 둔 구버전 PDF를 기준으로 작업하면, 그사이 추가된 컴포넌트나 바뀐 기준을 놓치게 됩니다.

현업에서 의외로 자주 생기는 사고가 이겁니다. 팀 공유 폴더에 누가 올려 둔 옛날 PDF를 그대로 받아 보거나, 외주 업체가 들고 온 자료가 구버전인 경우. 그래서 작업 착수 시점에 KRDS 공식 사이트(커뮤니티 자료실)에서 직접 최신 버전을 확인하고 내려받는 습관이 중요합니다. 출처가 불분명한 PDF는 기준으로 삼지 마세요. 디자인 시스템에서 버전 관리는 사소해 보여도 결과물의 정합성을 좌우하는 첫 단추입니다.

KRDS 가이드라인은 무엇을 요구하나 — 구조 완전 해부

이제 본론입니다. 그 두꺼운 PDF가 대체 어떤 구조로 짜여 있는지를 큰 덩어리로 나눠 보겠습니다. KRDS 가이드라인은 크게 세 개의 층위로 이해하면 머릿속에 잘 들어옵니다. 원칙(Foundation) → 컴포넌트(Component) → 패턴(Pattern). 위에서 아래로 갈수록 추상적인 철학에서 구체적인 화면 구현으로 내려옵니다.

1층위) 원칙·기반(Foundation) — "왜"의 영역

가이드라인의 앞부분은 개별 화면 얘기가 아니라 전체를 관통하는 원칙으로 시작합니다. 이 부분이 의외로 많은 사람이 건너뛰는 곳인데, 사실 가장 중요합니다. 여기엔 디자인 시스템이 추구하는 가치(일관성·접근성·효율성 같은), 그리고 모든 화면의 바탕이 되는 디자인 토큰이 정의돼 있습니다.

디자인 토큰이라는 말이 낯설 수 있는데, 쉽게 말하면 "디자인의 최소 단위 약속"입니다. 색상 하나하나, 글자 크기 하나하나, 여백 간격 하나하나를 임의로 정하지 않고 정해진 값으로 쓰자는 겁니다. 예를 들어 "주요 버튼 색은 #파랑"이라고 코드에 직접 박는 게 아니라, "primary 색상 토큰"이라는 이름표를 붙여 두고 그 이름표를 참조하는 식이죠. 이렇게 하면 나중에 브랜드 색이 바뀌어도 토큰 값 하나만 고치면 전체 화면이 한꺼번에 바뀝니다.

KRDS는 이 토큰을 영역별로 정리해 둡니다. 대표적으로:

• 색상 토큰: 주조색·보조색·의미색(성공/경고/오류/정보)·중립색(회색 단계) 등. 단순히 "예쁜 색"이 아니라, 각 색이 어떤 의미와 명도 대비를 갖는지가 함께 정의됩니다.
• 타이포그래피 토큰: 글꼴, 글자 크기 단계, 줄 간격, 굵기. 본문은 몇 px, 제목은 몇 px 같은 위계가 토큰으로 정해집니다.
• 간격(Spacing) 토큰: 요소 사이의 여백을 일정한 단위(흔히 4px 또는 8px의 배수)로 통일.
• 둥근 모서리(Radius)·그림자·테두리 등 시각 속성 토큰.

이 토큰 영역이 바로 이 글이 다루는 ViewCheck DS(디자인 시스템) 규칙군의 핵심 검증 대상이기도 합니다. 뒤에서 다시 다루겠습니다. 어쨌든 기억할 건 하나입니다 — 토큰을 따르는 것이 KRDS 준수의 출발점이라는 것. 컴포넌트가 아무리 잘 만들어져도 그 안의 색·글자·여백이 제각각이면 디자인 시스템을 따랐다고 할 수 없습니다.

2층위) 컴포넌트(Component) — "무엇으로"의 영역

토큰이라는 재료가 정해졌으면, 그 재료로 만드는 부품이 컴포넌트입니다. 버튼, 입력창, 셀렉트, 체크박스, 탭, 모달, 테이블, 페이지네이션 같은 것들. 가이드라인의 가장 두꺼운 부분이 보통 이 컴포넌트 영역입니다. 각 컴포넌트마다 정의·종류·상태·사용 시점·접근성 요건이 그림과 함께 정리돼 있습니다.

컴포넌트 페이지를 읽을 때 한 가지 요령이 있습니다. 모든 컴포넌트 설명은 대체로 비슷한 틀을 따릅니다. ① 이게 무엇인지(정의), ② 어떤 종류·변형이 있는지, ③ 상태(기본·포커스·비활성·오류 등)는 어떻게 표현하는지, ④ 언제 쓰고 언제 쓰지 말아야 하는지, ⑤ 접근성 주의사항. 이 다섯 가지 틀을 머릿속에 넣어 두면, 처음 보는 컴포넌트 페이지도 "아, 여기가 종류 설명, 여기가 상태 설명"하고 빠르게 스캔할 수 있습니다. 마치 사전에서 단어 뜻·발음·예문이 늘 같은 자리에 있는 것처럼요.

3층위) 패턴(Pattern) — "어떻게 흐르게"의 영역

컴포넌트가 부품이라면, 패턴은 그 부품들을 조합해 만드는 사용자 흐름입니다. 로그인하기, 검색하기, 신청서 작성하기, 단계별 마법사(스텝) 진행하기 같은 것. 개별 버튼 하나가 아니라 "회원가입이라는 전체 여정을 어떻게 설계할 것인가"를 다룹니다. 폼을 어떻게 나누고, 오류를 언제 어떻게 알리고, 확인·동의 단계를 어디에 둘지 같은 거시적 설계 지침이 여기 담깁니다.

이 세 층위 — 원칙·컴포넌트·패턴 — 가 가이드라인 PDF의 뼈대입니다. 그리고 이 뼈대는 그대로 ViewCheck가 사이트를 분석하는 846규칙의 분류 체계와 맞닿아 있습니다. ViewCheck는 KRDS 기준을 DS(디자인 시스템/토큰), CP(컴포넌트), BP(기본 패턴), SP(서비스 패턴)로 나눠 판정하는데, 이게 가이드라인의 층위 구조를 거의 그대로 옮겨 온 것이거든요.

정리하면, KRDS 가이드라인 PDF는 원칙(왜) → 컴포넌트(무엇으로) → 패턴(어떻게 흐르게)의 3층 구조입니다. 막막한 수백 페이지가 사실은 이 세 덩어리로 나뉘어 있고, 본인 역할에 따라 봐야 할 덩어리가 다릅니다. 이걸 알면 "전부 읽기"가 아니라 "필요한 데부터 읽기"가 가능해집니다.

한 장면 — 같은 PDF, 두 팀

추상적인 구조 설명을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 광역지자체 산하 기관 두 곳이 비슷한 시기에 홈페이지를 새로 만든다고 합시다. 둘 다 발주서에 "KRDS 가이드라인 준수"라는 같은 문구가 들어 있습니다.

먼저 A 기관. 담당 주무관은 가이드라인 PDF를 내려받아 보고는 페이지 수에 질려 버립니다. 결국 표지와 컴포넌트 그림 몇 장만 훑고 외주 업체에 "여기 KRDS 봐 가면서 만들어 주세요"라고 파일을 던집니다. 업체도 마감에 쫓겨 모양만 비슷하게 흉내 냅니다. 버튼은 KRDS 버튼처럼 생겼지만 색은 업체가 늘 쓰던 파랑이고, 여백은 눈대중 12px·15px·18px이 섞여 있습니다. 검수 단계에서 주무관은 "그림이 비슷하니 됐네" 하고 넘깁니다. 몇 달 뒤, 한 시각장애인 민원인이 "신청 폼의 셀렉트가 안 읽힌다"고 항의합니다. 그제야 다시 뜯어보니, 토큰도 안 맞고 접근성 요건도 곳곳이 비어 있습니다. 재작업 비용과 민원 대응이 동시에 터집니다.

이번엔 B 기관. 담당 주무관은 이 글에서 말한 대로 PDF를 "사전"처럼 씁니다. 먼저 원칙·토큰 부분을 읽어 큰 그림을 잡고, 화면 정의서에 "KRDS 셀렉트(필수, 미선택 시 오류)", "primary 색상 토큰", "간격 4단계" 식으로 토큰 이름까지 명시합니다. 업체에는 PDF와 함께 "GitHub 킷을 가져다 쓰고 토큰을 참조하라"고 못 박습니다. 산출물을 받은 뒤엔 ViewCheck로 채점해 "색상 토큰 채택률 88%, 미통과 항목 12개"를 확인하고, 그 목록을 업체에 보내 보완을 요구합니다. 출시된 사이트는 처음부터 토큰이 맞고 접근성 요건이 채워져 있어, 같은 민원이 애초에 생기지 않습니다.

같은 PDF, 같은 발주 문구. 그런데 한 팀은 재작업과 민원에 시달리고, 다른 팀은 매끄럽게 출시합니다. 차이를 만든 건 예산이나 기술이 아닙니다. PDF를 어떻게 읽고 어떻게 검증했느냐라는 작은 차이입니다. 이 글이 다루는 게 바로 그 차이를 만드는 방법입니다.

어디부터 볼까 — 역할별 통독 경로

이 글의 제목이 "어디부터 볼까"인 만큼, 가장 실용적인 부분을 자세히 풀겠습니다. 수백 페이지를 처음부터 끝까지 읽는 건 비현실적이니, 자기 역할에 맞는 진입 경로를 따르는 게 정답입니다. 세 직군으로 나눠 보겠습니다.

기획자·PM이라면 — "원칙 + 패턴" 위주로

기획자는 화면 하나하나를 직접 그리거나 코딩하지 않습니다. 대신 "어떤 흐름으로, 어떤 컴포넌트를 써서 서비스를 구성할지"를 결정하죠. 그래서 기획자에게 가장 가치 있는 부분은 맨 앞의 원칙·기반과 맨 뒤의 패턴입니다.

원칙 부분을 읽으면 "왜 이 디자인 시스템을 따라야 하는가"에 대한 명분과 언어가 생깁니다. 윗선을 설득하거나 외주 업체에 요건을 전달할 때, "그냥 예쁘게요"가 아니라 "KRDS 접근성 원칙에 따라 이렇게요"라고 말할 수 있게 됩니다. 패턴 부분을 읽으면 화면 정의서를 쓸 때 "신청 폼은 이런 단계로, 오류는 이 시점에 이렇게 알린다"처럼 구체적으로 명세할 수 있습니다. 컴포넌트 세부 스펙은 디자이너·개발자에게 맡기고, 기획자는 큰 그림과 흐름에 집중하는 게 효율적입니다.

디자이너라면 — "원칙(토큰) + 컴포넌트 비주얼" 위주로

디자이너에게는 디자인 토큰이 출발점입니다. 색상·타이포·간격 토큰을 먼저 머리에 넣어야, 시안을 그릴 때 임의의 색이나 어중간한 여백을 쓰지 않게 됩니다. 그다음 각 컴포넌트의 비주얼 정의(종류·상태·크기)를 봅니다.

그런데 디자이너에게 정말 효율적인 길은 PDF를 보면서 동시에 공식 Figma 라이브러리를 여는 겁니다. PDF로 "왜 이렇게 생겼는지" 원리를 이해하고, Figma에서 실제 컴포넌트를 가져다 배치하면, 글로 읽은 기준이 곧바로 손에 잡히는 부품이 됩니다. 직접 다시 그리는 게 아니라 표준 컴포넌트를 조립하는 거죠. 이렇게 하면 시안과 실제 구현 사이의 간극도 확 줄어듭니다. PDF는 이해용, Figma는 작업용 — 두 개를 같이 펼치는 게 디자이너에게는 최단 경로입니다.

개발자라면 — "컴포넌트 + 접근성 요건" 위주로, 코드와 병행

개발자에게는 컴포넌트 영역과 그 안의 접근성 요건이 핵심입니다. 각 컴포넌트가 어떤 상태를 가져야 하고, 어떤 ARIA 속성이 필요하고, 키보드로 어떻게 조작돼야 하는지가 구현의 명세서니까요.

다만 개발자에게도 PDF만 보는 건 비효율적입니다. PDF로 "이 컴포넌트가 어떤 동작·상태를 가져야 하는지" 요건을 확인하고, 동시에 GitHub의 컴포넌트 킷(KRDS-uiux/krds-uiux)에서 이미 구현된 코드를 가져다 쓰는 게 가장 빠릅니다. 가이드라인이 "셀렉트는 키보드로 열려야 한다"고 말하면, 킷에는 그 키보드 동작이 이미 들어간 셀렉트 코드가 있습니다. 직접 만들다 빠뜨리지 말고, 검증된 코드를 가져와 토큰만 맞추는 게 현실적입니다. PDF는 "무엇을 만족해야 하나"의 체크리스트, 킷은 "그걸 만족한 코드"의 라이브러리로 생각하세요.

설치는 npm install krds-uiux로 패키지를 받거나, CDN으로 krds.min.css·krds.min.js를 불러오면 됩니다. 저장소의 html/code 폴더에 컴포넌트별 HTML 코드가 그대로 들어 있어, 복사해 시작할 수 있습니다.

왜 이렇게까지 따지나 — 가이드라인이 존재하는 이유

여기까지 읽고 "한낱 디자인 가이드 하나에 뭐 이리 거창한가" 싶으실 수 있습니다. 그런데 KRDS 가이드라인이 수백 페이지에 걸쳐 색 하나, 여백 하나까지 정해 둔 데에는 분명한 이유가 있습니다.

공공 서비스는 "안 쓸 자유"가 없다

상업 사이트는 불편하면 사용자가 떠나면 그만입니다. 경쟁사로 가면 되니까요. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 건강보험을 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없습니다. 사용자에게 "안 쓸 자유"가 없어요. 그래서 공공 웹이 누군가에게 작동하지 않으면, 그건 단순한 불편이 아니라 행정 서비스 접근권의 박탈이 됩니다.

가이드라인이 접근성 요건을 "있으면 좋은 것"이 아니라 "지켜야 하는 기준"으로 못 박는 이유가 이겁니다. 화면이 시각장애인·고령자·손이 불편한 사용자에게도 작동해야 하는 건, 친절이 아니라 의무거든요. 가이드라인은 그 의무를 누구나 따를 수 있도록 구체적인 형태로 번역해 둔 문서입니다.

수백 개 사이트의 일관성 = 학습 비용 제로

국민 한 사람이 1년 동안 거치는 공공 사이트는 생각보다 많습니다. 세금, 복지, 건강, 교육, 민원… 각 사이트가 검색 버튼을 다른 모양으로, 신청 폼을 다른 흐름으로, 오류를 다른 방식으로 알리면, 사용자는 사이트를 옮길 때마다 사용법을 처음부터 다시 배워야 합니다. 디지털에 익숙하지 않은 사람일수록 이 "다시 배우기"가 큰 장벽입니다.

가이드라인이 색·컴포넌트·패턴을 표준화하는 핵심 목적이 바로 이 일관성입니다. 모든 공공 서비스가 같은 시각 언어와 같은 흐름을 쓰면, 한 번 익힌 사용법이 모든 사이트에서 통합니다. 표준화는 디자이너의 창의성을 억누르는 게 아니라, 국민의 인지 부담을 덜어 주는 일입니다. 가이드라인이라는 한 권의 문서가 수백 개 사이트를 하나의 경험으로 묶는 거죠.

"각자 잘하기"의 한계

가이드라인이 없다면 어떻게 될까요? 각 기관·각 업체가 "우리 나름대로 잘하면 되지"라고 생각할 겁니다. 문제는 그 "잘함"의 기준이 제각각이라는 데 있습니다. 어떤 팀은 접근성을 중요하게 보고, 어떤 팀은 모바일을 중요하게 보고, 어떤 팀은 그냥 예쁜 걸 중요하게 봅니다. 결과적으로 품질이 들쭉날쭉해지죠.

가이드라인은 이 "각자 기준"을 하나의 공통 기준으로 끌어올립니다. 잘하는 팀에게는 검증된 자산을 제공해 시간을 아껴 주고, 기준이 모호하던 팀에게는 명확한 목표를 줍니다. 디자인 시스템의 진짜 가치는 "최고를 만드는 것"이 아니라 "바닥을 올리는 것"입니다. 어떤 기관이 만들어도 일정 수준 이상은 보장되게 하는 것 — 그게 공공 영역에서 표준 문서가 하는 가장 중요한 일입니다.

글로 된 문서가 코드·디자인보다 먼저인 이유

요즘은 디자인 시스템 하면 Figma 라이브러리나 코드 컴포넌트를 먼저 떠올리는 사람이 많습니다. "어차피 가져다 쓸 건데 문서를 왜 읽어?" 하는 거죠. 그런데 가이드라인 PDF가 여전히 시스템의 중심에 있는 이유가 있습니다. 코드와 디자인 자산은 "이미 정해진 답"을 담지만, 판단이 필요한 상황까지 담지는 못합니다.

예를 들어 "선택지가 몇 개면 셀렉트를 쓰고 몇 개면 라디오를 쓰나", "오류 메시지는 어느 시점에 띄우나", "이 화면에 이 컴포넌트를 쓰는 게 맞나" 같은 질문은 코드가 답해 주지 않습니다. 컴포넌트 킷에는 셀렉트와 라디오가 둘 다 들어 있을 뿐, 언제 무엇을 쓸지는 알려 주지 않으니까요. 그 판단의 근거가 글로 된 가이드라인에 있습니다. 그래서 코드만 보고 작업하면 "잘 만든 부품을 엉뚱한 자리에 붙이는" 일이 생깁니다. 부품은 표준인데 조합이 비표준인 거죠. 가이드라인은 그 조합의 원칙을 알려 주는, 자산들의 "사용 설명서"입니다.

가이드라인은 살아 있는 문서다

또 하나 오해하기 쉬운 게, 가이드라인을 "한 번 만들어 박제된 규칙집"으로 보는 겁니다. 실제로는 그렇지 않습니다. 웹 기술이 바뀌고, 접근성 기준이 강화되고, 새로운 사용 맥락(예: 모바일 비중 증가)이 생기면 가이드라인도 함께 진화합니다. 버전 표기(2025.08 같은)가 붙어 있는 이유가 이겁니다. 이건 단점이 아니라 장점입니다. 시대에 뒤떨어진 기준을 강요하지 않고, 계속 현실에 맞게 다듬어진다는 뜻이니까요.

그래서 가이드라인을 대하는 올바른 자세는 "한 번 외우면 끝"이 아니라 "버전이 바뀌면 변경점을 따라가는" 것입니다. 토큰을 참조 구조로 만들어 두고, 새 버전이 나오면 무엇이 바뀌었는지 변경 이력 위주로 확인하는 습관. 이게 장기적으로 유지보수 비용을 가장 크게 줄이는 길입니다.

가이드라인을 다룰 때 자주 틀리는 지점 — 그리고 올바른 태도

가이드라인 PDF를 손에 넣고도 잘못 쓰는 경우가 의외로 많습니다. 현업에서 반복되는 실수들을 익명화해 정리합니다(특정 기관·업체를 지목하지 않습니다).

실수 1) 표지와 컴포넌트 그림만 보고 "다 봤다"고 하기

가장 흔한 실수입니다. 두꺼운 PDF에 압도된 나머지, 앞부분 몇 장과 컴포넌트 그림 몇 개만 훑고는 "KRDS 봤다"고 넘어갑니다. 그러면 가장 중요한 원칙과 토큰, 그리고 컴포넌트의 상태·접근성 요건을 통째로 놓칩니다.

• 나쁜 태도: "버튼이 이렇게 생겼구나" 하고 모양만 따라 그림. 정작 그 버튼이 비활성·오류 상태일 때 어떻게 보여야 하는지, 키보드로 어떻게 동작해야 하는지는 안 봄.
• 올바른 태도: 컴포넌트 페이지를 볼 때 "정의-종류-상태-사용시점-접근성"의 다섯 틀을 의식하며 스캔. 특히 상태와 접근성 부분은 절대 건너뛰지 않기.

실수 2) 토큰을 무시하고 임의 값 쓰기

가이드라인에 색·간격 토큰이 정해져 있는데도, 디자이너나 개발자가 "이 정도 색이면 비슷하지", "여백은 대충 12px"라며 임의 값을 씁니다. 모양은 비슷해 보여도, 이건 디자인 시스템을 따른 게 아닙니다.

• 나쁜 태도: 토큰 표는 안 보고 눈대중으로 색·여백을 정함. 페이지마다 미묘하게 다른 색·간격이 섞임.
• 올바른 태도: 색·타이포·간격을 정할 때 반드시 토큰 표를 참조. 토큰에 없는 값이 필요하면 "정말 필요한가"를 먼저 의심. 일관성은 "비슷하게"가 아니라 "같은 값으로"에서 나옴.

실수 3) 구버전 PDF를 기준으로 작업

앞서 말한 버전 문제입니다. 공유 폴더에 떠도는 옛 PDF나 출처 불명 자료를 기준으로 삼으면, 최신판에서 바뀐 기준을 반영하지 못합니다.

• 나쁜 태도: "작년에 받아 둔 거 있으니까 그거 쓰자."
• 올바른 태도: 작업 착수 시점에 KRDS 공식 사이트에서 최신 버전을 직접 확인·다운로드. 파일명의 버전 표기(예: 2025.08)를 팀 전체가 동일하게 맞춤.

실수 4) PDF만 보고 코드·Figma는 안 보기

가이드라인 PDF는 "무엇을 해야 하는지"를 말하지만, 그걸 직접 손으로 다시 구현하려 들면 시간도 많이 걸리고 빠뜨리기도 쉽습니다. 이미 제공되는 코드·디자인 자산을 안 쓰는 건 비효율입니다.

• 나쁜 태도: PDF 보고 컴포넌트를 처음부터 직접 코딩·작화. 접근성 속성을 빠뜨리고도 모름.
• 올바른 태도: PDF로 요건을 이해하고, 구현은 GitHub 킷 코드와 Figma 라이브러리를 가져다 활용. PDF·코드·Figma를 한 세트로 운용.

실수 5) "가이드라인 준수"를 감으로 판단

작업을 마치고 "이 정도면 KRDS 따랐지"라고 느낌으로 결론 내리는 것. 정작 페이지 하나하나가 토큰을 지켰는지, 컴포넌트가 접근성 요건을 충족했는지는 확인하지 않습니다.

• 나쁜 태도: "가이드라인 보면서 만들었으니 준수한 거지"라는 막연한 자기 확신.
• 올바른 태도: 만든 결과물을 실제로 점검. 손으로 다 보기 어려우니 자동 점검 도구로 토큰 채택률·컴포넌트 준수 여부를 객관 수치로 확인. (뒤에서 ViewCheck로 다룹니다.)

실수 6) 가이드라인을 "제약"으로만 받아들이기

마지막은 태도의 문제입니다. 가이드라인을 "자유를 뺏는 규제"로만 보면 일이 괴로워집니다. 그런데 관점을 바꾸면, 가이드라인은 "이미 검증된 답안을 무료로 주는 것"이기도 합니다.

• 나쁜 태도: "왜 이렇게 하라는 대로만 해야 해" 하는 반발. 우회하거나 무시.
• 올바른 태도: 매번 색·여백·접근성을 처음부터 고민하는 대신, 검증된 기준을 가져다 쓰고 정작 고민할 가치가 있는 곳(서비스 고유의 흐름·콘텐츠)에 에너지를 집중. 가이드라인은 "안 해도 되는 고민"을 줄여 주는 도구.

실수 7) 컴포넌트만 보고 패턴(흐름)은 안 보기

개발자·디자이너가 흔히 빠지는 함정입니다. 컴포넌트 페이지는 열심히 보는데, 그 컴포넌트들을 어떻게 엮어 하나의 흐름으로 만들지를 다룬 패턴 부분은 건너뜁니다. 그러면 부품 하나하나는 표준인데 전체 여정은 엉성해집니다.

• 나쁜 태도: 버튼·입력창은 KRDS대로 만들었는데, 신청 폼 전체 흐름은 단계도 뒤죽박죽이고 오류 안내 시점도 제각각.
• 올바른 태도: 컴포넌트를 조립하기 전에 패턴 부분을 먼저 읽고 "이 화면은 어떤 흐름이어야 하나"를 잡기. 부품의 품질과 조합의 품질을 둘 다 챙기기.

실수 8) "한 사람만 읽고 끝"

가이드라인을 팀에서 한 사람(보통 디자이너 한 명)만 읽고, 나머지는 그 사람 말만 듣는 경우. 그러면 정보가 전달 과정에서 새고, 직군마다 봐야 할 부분을 놓칩니다.

• 나쁜 태도: "디자이너가 KRDS 봤대" 하고 개발자·기획자는 PDF를 한 번도 안 펴 봄.
• 올바른 태도: 직군별로 자기 영역(기획=원칙·패턴, 디자인=토큰·컴포넌트, 개발=컴포넌트·접근성)을 각자 읽기. 같은 문서를 보되 보는 각도를 나누기.

직접 적용하기 — 역할별 실행 가이드

가이드라인을 읽었다면, 이제 그걸 작업에 녹이는 단계입니다. 직군별로 바로 쓸 수 있는 실행 가이드를 정리합니다.

개발자라면 — PDF에서 만들 컴포넌트의 요건(상태·키보드·ARIA)을 먼저 확인한 뒤, npm install krds-uiux 또는 CDN(krds.min.css/krds.min.js)으로 컴포넌트 킷을 불러오세요. KRDS-uiux/krds-uiux 저장소의 html/code 폴더에 컴포넌트별 코드가 있어, 가져다 쓰면 접근성 요건이 이미 충족된 상태로 시작합니다. 토큰은 CSS 변수 형태로 제공되니, 색·여백을 하드코딩하지 말고 토큰 변수를 참조하세요.

디자이너라면 — PDF로 토큰 체계(색·타이포·간격)와 컴포넌트 비주얼을 이해한 뒤, 공식 Figma(@krds) 라이브러리에서 표준 컴포넌트를 가져다 배치하세요. 직접 그리는 대신 컴포넌트를 조립하면, 디자인 단계에서부터 토큰·상태·간격이 기준에 맞춰집니다. 시안에 "이건 primary 색상 토큰", "여백은 spacing 4단계"처럼 토큰 이름을 표기해 두면, 개발 단계로 넘길 때 의사소통이 깔끔해집니다.

기획자라면 — PDF의 원칙·패턴 부분을 읽고, 화면 정의서에 "여기 셀렉트 하나" 식으로 막연히 적지 말고 "KRDS 셀렉트(단일 선택, 필수, 미선택 시 오류)"처럼 컴포넌트·역할·상태를 함께 명시하세요. 또 신청·검색 같은 흐름은 패턴 부분의 권고를 참고해 단계와 오류 처리 시점을 정의해 두면, 디자인·개발 단계의 누락이 크게 줄어듭니다.

공통 — 가이드라인 PDF를 팀의 "공용 사전"으로 만드세요. 논쟁이 생길 때("이거 빨강이 맞아 주황이 맞아?") 감으로 싸우지 말고 "PDF 토큰 표 보자"로 끝내는 문화. 그 한 권이 같은 기준을 가리키면, "네 취향/내 취향" 논쟁이 "기준이 뭐라고 하지"로 바뀝니다.

그래서 우리 사이트는? — ViewCheck로 채점하기

여기까지가 KRDS 가이드라인 PDF를 어떻게 읽고 적용하는지입니다. 그런데 가장 어려운 마지막 단계가 남았습니다. "그래서 우리 사이트가 정말 이 기준을 지켰나?"를 확인하는 일입니다.

가이드라인을 아무리 열심히 읽어도, 다 만든 사이트가 그 기준을 실제로 지켰는지는 별개의 문제입니다. 페이지마다 색이 토큰을 따랐는지, 글자 크기가 정해진 단계 안에 있는지, 여백이 일관된지, 컴포넌트가 접근성 요건을 충족했는지를 사람이 페이지 하나하나 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요. 게다가 "이 색이 토큰의 primary랑 같은가"를 눈으로 정확히 판별하는 건 사실상 불가능합니다.

ViewCheck(krds.viewcheck.co.kr)는 이 채점을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 화면의 색·타이포·간격이 KRDS 토큰을 따르는지, 컴포넌트가 기준을 충족하는지를 판정합니다. 그리고 이 글이 다룬 가이드라인의 원칙·토큰 영역이 바로 ViewCheck의 DS(디자인 시스템) 규칙군 120개에 해당합니다. 분석 결과의 디자인 시스템(Design System) 탭에서 확인할 수 있습니다.

ViewCheck가 DS 영역에서 자동으로 보는 것들:

• 색상 토큰 채택률: 페이지에 실제로 쓰인 색들이 KRDS 색상 토큰과 얼마나 일치하는지. 토큰 밖의 임의 색이 얼마나 섞여 있는지.
• 타이포그래피 일치: 글꼴·글자 크기·줄 간격이 정해진 타이포 토큰 체계 안에 있는지.
• 간격(Spacing) 일관성: 여백이 정해진 간격 단위(4px/8px 배수 등)를 따르는지, 제각각인 값이 난무하는지.
• 시각 속성: 둥근 모서리·테두리 같은 속성이 토큰을 따르는지.

특히 ViewCheck는 디자인 토큰 채택률 리포트를 제공합니다. "우리 사이트가 KRDS 토큰을 몇 %나 따르고 있는가"를 객관적인 수치로 보여 주는 거죠. "느낌상 잘 지킨 것 같다"가 아니라 "색상 토큰 채택률 72%, 간격 토큰 채택률 60%"처럼 숫자로 나오니, 어디가 약한지가 명확해집니다.

DOM(코드)만으로 판단하기 어려운 시각적 부분 — 예를 들어 이미지나 비표준 방식으로 구현된 색·레이아웃 — 은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드상으론 토큰을 쓴 것 같은데 실제 화면에선 어긋난" 경우도 놓치지 않습니다. 사람이 눈으로 보듯 화면을 함께 보기 때문에, 코드 검사만으로는 잡기 어려운 시각적 불일치까지 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 디자인 시스템 탭에서 DS 규칙들의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법이 함께 나옵니다. 예를 들어 "메인 페이지에서 토큰 밖 색상 5종 사용", "신청 페이지의 간격이 토큰 단위를 벗어남"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면 "메인은 토큰을 잘 지키는데 게시판 페이지는 색이 제각각"처럼 페이지별 편차도 드러납니다.

여기서 가이드라인 PDF와 ViewCheck의 관계가 분명해집니다. PDF는 정답지이고, ViewCheck는 내 답안을 채점해 주는 도구입니다. 둘을 함께 쓰면 한 바퀴가 완성됩니다 — 기준을 이해하고(가이드라인 PDF) → 내 사이트가 그 기준에 맞는지 채점하고(ViewCheck) → 검증된 코드로 고치는(킷). 가이드라인만 읽고 끝나면 "공부는 했는데 시험은 안 본" 상태입니다. ViewCheck는 그 시험지 역할을 합니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 토큰 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "잘하자"가 아니라 "이 페이지의 이 색을 토큰으로 바꾸자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

가이드라인 PDF를 처음 마주한 분들이 반복해서 던지는 질문을 모았습니다.

Q. 수백 페이지를 정말 다 읽어야 하나요? 시간이 없는데요.

다 읽을 필요는 없습니다. 이 글에서 다룬 대로 자기 역할에 맞는 부분부터 보면 됩니다. 기획자는 원칙·패턴, 디자이너는 토큰·컴포넌트 비주얼, 개발자는 컴포넌트·접근성 요건. 처음엔 본인 영역만 읽고, 작업하다 막히는 부분이 나오면 그때그때 해당 컴포넌트 페이지를 펴 보는 "사전식 읽기"가 현실적입니다. 한 번에 정독하겠다고 마음먹으면 영영 못 읽습니다. "필요한 데부터"가 답입니다.

Q. PDF만 보면 되나요, 아니면 코드·Figma도 봐야 하나요?

PDF는 "왜·무엇을"을 알려 주고, 코드(GitHub 킷)와 Figma는 "어떻게"를 손에 쥐여 줍니다. 셋은 한 세트입니다. 개발자라면 PDF로 요건을 확인하고 킷 코드를 가져다 쓰고, 디자이너라면 PDF로 원리를 이해하고 Figma 컴포넌트를 배치하는 식으로 병행하는 게 가장 효율적입니다. PDF만 보고 전부 직접 만들면 시간 낭비에 누락 위험이 큽니다.

Q. 디자인 토큰이 뭔지 아직도 잘 모르겠어요.

쉽게 말하면 "디자인 값에 붙인 이름표"입니다. "#1F4E79"라는 색을 코드 여기저기에 직접 박는 대신, "primary 색상"이라는 이름표를 만들어 두고 그 이름표를 참조하는 거죠. 이렇게 하면 ① 색·여백이 항상 같은 값으로 통일되고, ② 나중에 바꿀 때 이름표 하나만 고치면 전체가 바뀝니다. KRDS는 색·글자·간격 같은 디자인 값을 이런 토큰으로 정리해 두었고, 그걸 따르는 게 디자인 시스템 준수의 출발점입니다.

Q. 우리는 이미 만들어진 사이트인데, 가이드라인을 지금 봐도 의미가 있나요?

네, 큽니다. 신규 구축이든 운영 중이든, 가이드라인은 "지금 우리 사이트가 어디가 기준에서 벗어났는지"를 판단하는 잣대가 됩니다. 먼저 ViewCheck로 현황(토큰 채택률·컴포넌트 준수율)을 확인해 약한 부분을 목록으로 만든 뒤, 가이드라인을 참고해 우선순위대로 고치면 됩니다. 운영 중인 사이트일수록 "어디부터 손볼지" 판단이 중요한데, 그 판단의 기준이 바로 가이드라인입니다.

Q. 가이드라인이 업데이트되면 기존에 만든 것도 다 바꿔야 하나요?

전부 갈아엎을 필요는 없습니다. 버전이 바뀌면 보통 추가·개선이 중심이고, 기존 기준이 통째로 뒤집히는 경우는 드뭅니다. 새 버전이 나오면 변경점 위주로 확인하고, 토큰을 제대로 참조하는 구조로 만들어 두었다면 토큰 값 업데이트만으로 상당 부분 따라갈 수 있습니다. 그래서 처음부터 토큰을 직접 박지 말고 참조 구조로 만들어 두는 게 중요합니다. 미래의 업데이트 대응 비용을 줄여 주거든요.

Q. 가이드라인을 지키면 자동으로 웹 접근성(KWCAG)도 지켜지나요?

상당 부분 겹치지만 완전히 같지는 않습니다. KRDS 가이드라인은 접근성을 핵심 가치로 삼아 만들어졌기 때문에, 컴포넌트의 접근성 요건을 충실히 따르면 KWCAG의 많은 항목이 자연스럽게 충족됩니다. 다만 접근성은 컴포넌트뿐 아니라 콘텐츠·구조·동적 동작 전반에 걸치므로, "KRDS 컴포넌트 썼으니 접근성 끝"이라고 단정하면 안 됩니다. ViewCheck는 KRDS 규칙과 별도로 KWCAG 항목도 함께 점검하니, 두 측면을 같이 확인하는 게 안전합니다.

Q. 외주 업체에 맡기는데, 가이드라인을 발주처(우리)가 알아야 하나요?

반드시요. 발주처가 가이드라인을 모르면 "KRDS 준수해 주세요"라는 한 줄로 끝나고, 검수 단계에서 "이게 진짜 준수된 건지" 판단할 길이 없습니다. 발주처가 최소한 원칙과 토큰 개념을 알고 있어야, 산출물을 받았을 때 ViewCheck 같은 도구로 채점하고 "토큰 채택률이 낮으니 보완해 달라"고 구체적으로 요구할 수 있습니다. 가이드라인은 개발하는 쪽만의 문서가 아니라, 발주·검수하는 쪽에도 필수입니다.

Q. 가이드라인 PDF와 KRDS 웹사이트(컴포넌트 문서), 둘 중 뭘 봐야 하나요?

둘 다 같은 기준을 가리키되 형태가 다릅니다. PDF는 처음부터 끝까지 한 흐름으로 정리돼 있어 "전체 그림"을 잡기 좋고, 웹 문서는 특정 컴포넌트를 빠르게 찾아보기 좋습니다. 처음 입문할 때는 PDF로 구조를 잡고, 작업 중에 "셀렉트 상태가 어떻게 되더라" 같은 특정 항목이 궁금할 때는 웹에서 바로 찾아보는 식으로 병행하면 효율적입니다. 어느 쪽이든 출처가 KRDS 공식인지, 최신 버전인지를 먼저 확인하세요.

Q. 토큰을 다 외워야 하나요? 색·간격 값이 너무 많은데요.

외울 필요 없습니다. 토큰의 핵심은 "값을 외우는 것"이 아니라 "이름으로 참조하는 것"입니다. 디자이너는 Figma에서 토큰을 선택해 쓰고, 개발자는 토큰 변수(CSS 변수 등)를 참조하면 됩니다. 정확한 16진수 색깔이나 px 값을 머리에 넣을 필요 없이, "여기는 primary 색상", "여기는 간격 4단계"처럼 의미 단위로 작업하면 됩니다. 그게 토큰을 쓰는 이유이기도 하고요. 외우는 게 아니라 도구가 채워 주는 구조로 일하세요.

Q. 가이드라인을 안 지키면 불이익이 있나요?

이 글은 법적·행정적 제재의 구체적인 내용을 단정하지 않겠습니다(그건 소관 부처의 고시·지침을 직접 확인하셔야 합니다). 다만 분명한 건, 가이드라인을 안 지키면 접근성·일관성 측면에서 실제 사용자가 불편을 겪고, 그것이 민원·재작업·평판 문제로 돌아온다는 점입니다. "안 지켰을 때의 벌"을 걱정하기 전에 "지켰을 때의 이득"(재작업 감소, 민원 감소, 모두가 쓸 수 있는 서비스)을 보는 게 더 생산적입니다. 그리고 그 이득은 ViewCheck로 채점하며 객관적으로 관리할 수 있습니다.

점검했다면, 무엇부터 고칠까 — 우선순위

ViewCheck로 사이트를 돌려 보면 DS 영역에서 적잖은 항목이 미통과로 나올 수 있습니다. 페이지가 많을수록 "고칠 게 많다"는 압박이 듭니다. 그래서 우선순위가 중요합니다. 디자인 시스템 관점에서 무엇부터 손볼지 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 접근성과 직결된 토큰 문제. 대표적으로 색상 대비가 부족한 경우(연한 회색 글자, 배경과 구분 안 되는 텍스트)입니다. 이건 저시력 사용자가 내용을 못 읽는 문제라 1순위입니다. 단순히 "토큰을 안 썼다"를 넘어 "사용자가 못 본다"로 이어지는 항목부터요.

그다음(높음) — 핵심 경로(메인·신청·로그인·검색)의 토큰 불일치. 사용 빈도가 높은 페이지의 색·간격이 제각각이면, 가장 많은 사용자가 일관성 없는 경험을 합니다. 트래픽이 몰리는 페이지부터 토큰을 맞추면 적은 작업으로 큰 효과를 봅니다.

그 후(보통) — 일반 페이지의 토큰 채택률 끌어올리기. 게시판·안내 페이지 등에서 임의 색·간격을 토큰으로 정리하는 작업. 치명적이진 않지만 전체 일관성을 높입니다.

여력이 되면(낮음) — 시각 디테일(둥근 모서리·그림자 등)의 토큰 정합. 사용성을 막는 건 아니지만 완성도를 한 단계 올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "눈에 띄는 것부터"가 아니라 "사용자에게 영향이 큰 것부터" 순서대로 처리할 수 있습니다. 한정된 인력과 일정 안에서 가장 효과 큰 개선에 집중하는 게 핵심입니다.

더 깊이 확인하려면 — 공식 자료 안내

이 글은 KRDS 가이드라인 PDF를 어떻게 읽고 활용할지 실무 관점에서 풀어 쓴 것입니다. 정확한 원문 기준과 코드·디자인 자산은 아래 공식 자료에서 직접 확인하실 수 있습니다.

• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 원칙·컴포넌트·패턴 기준의 1차 원천. KRDS 공식 사이트 커뮤니티 자료실에서 최신 버전을 직접 내려받으세요.
• KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — 가이드라인을 구현한 HTML/CSS/JS 코드. html/code 폴더에 컴포넌트별 코드(npm install krds-uiux 또는 CDN).
• KRDS 공식 Figma(@krds) — 디자이너용 컴포넌트와 토큰 라이브러리. PDF로 이해하고 Figma로 작업하는 병행 추천.

공식 자료는 "정답지"이고, ViewCheck는 "내 답안을 채점해 주는 도구"입니다. 둘을 함께 쓰면, 기준을 이해하고(가이드라인) → 내 사이트가 그 기준에 맞는지 확인하고(ViewCheck) → 검증된 코드로 고치는(킷) 한 바퀴가 완성됩니다.

오늘의 체크리스트 — 가이드라인, 이것만은

마지막으로, 가이드라인 PDF를 손에 쥐고 작업을 시작할 때 바로 쓸 수 있는 체크리스트로 정리합니다.

• ☐ 내가 보고 있는 PDF가 최신 버전인가(공식 사이트에서 직접 확인했는가).
• ☐ 가이드라인의 3층 구조(원칙·컴포넌트·패턴)를 이해하고, 내 역할에 맞는 부분부터 읽고 있는가.
• ☐ 맨 앞의 원칙·토큰 부분을 건너뛰지 않았는가(가장 중요한데 가장 자주 생략됨).
• ☐ 컴포넌트 페이지를 볼 때 상태·접근성 요건을 챙기고 있는가(모양만 보지 않았는가).
• ☐ 색·타이포·간격을 토큰 표를 보고 정하는가(눈대중 임의 값을 쓰지 않는가).
• ☐ PDF와 함께 코드 킷·Figma를 병행해 쓰고 있는가(직접 다 만들려 하지 않는가).
• ☐ "준수했다"를 감이 아니라 객관 수치(토큰 채택률 등)로 확인했는가.
• ☐ 토큰을 직접 박지 않고 참조 구조로 만들어, 향후 업데이트에 대비했는가.
• ☐ 발주·검수하는 입장이라면, 산출물을 채점할 기준과 도구를 갖췄는가.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 중 컴포넌트·접근성 부분이 이미 구현된 상태로 시작할 수 있고, 공식 Figma(@krds)에서는 토큰과 컴포넌트를 그대로 가져다 쓸 수 있습니다.

가이드라인 PDF는 두껍지만, 그 두께만큼의 가치가 있습니다. 그 안에는 수많은 사용자가 막혔던 지점에서 역으로 도출된, 검증된 답이 담겨 있거든요. 우리가 매번 처음부터 고민할 필요 없이 가져다 쓸 수 있는 공용 자산입니다. 무서워서 안 펴 보는 대신, 지도 한 장 들고 필요한 곳부터 펴 보세요. 그러면 "수백 페이지"가 "그 부분 보면 되는구나"로 바뀝니다.

오늘 정리한 건 거창해 보여도 핵심은 단순합니다. 최신 버전을 확인하고, 3층 구조를 이해하고, 내 역할에 맞는 부분부터 읽고, 토큰을 따르고, 만든 결과를 채점하는 것. 이 다섯 가지만 챙겨도 "KRDS 준수"라는 막연한 요구가 구체적인 작업으로 바뀝니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 영향이 큰 페이지 하나부터 토큰을 맞춰 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게, 더 일관된 경험으로 열립니다. 다음 글에서는 이 가이드라인이 정의한 컴포넌트 하나를 같은 방식으로 더 깊이 뜯어보겠습니다.

우리 사이트는 KRDS 토큰을 몇 % 따르고 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 디자인 토큰 채택률을 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 가이드라인 기준이 실제로 지켜지고 있는지 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #가이드라인PDF #웹접근성 #ViewCheck #정부웹사이트 #UIUX #디자인토큰 #디지털정부 #UX가이드라인 #공공서비스 #가이드라인 #KRDS기준 #디자인원칙 #표준가이드 #전자정부 #행정안전부 #공공기관 #KWCAG