KRDS vs GOV.UK·USWDS — 세 나라 공공 디자인시스템 비교

베끼기가 아니라 대화: 강점을 배우고 빈틈을 직시하기 위한 비교 연구

---

들어가며 — 왜 해외 디자인시스템을 들여다보는가

ViewCheck가 KRDS를 점검하는 도구를 만들면서, 우리 스스로에게 자주 던지는 질문이 있다. "KRDS는 얼마나 잘 설계된 시스템인가?" 그리고 그 질문 옆에는 항상 비교 대상이 따라붙는다. "GOV.UK Design System은 어떻게 했을까?" "USWDS는 이걸 어떤 방식으로 접근했지?"

이 글은 그 질문들을 하나씩 풀어본 기록이다. 결론부터 말하면, 세 시스템은 각자의 강점이 뚜렷하고 빈틈도 분명하다. KRDS를 "한국판 GOV.UK"라고 부르는 건 너무 단순하고, "USWDS를 한국 실정에 맞게 포팅한 것"이라고 보는 것도 정확하지 않다. 셋은 서로 다른 나라의 서로 다른 역사적 맥락에서 탄생했고, 그 차이가 시스템의 구조와 철학에 고스란히 배어 있다.

우리가 이 비교를 하는 이유는 두 가지다. 첫째, ViewCheck가 KRDS를 846개 규칙으로 점검할 때, 그 규칙의 '수준'이 국제 기준과 얼마나 맞닿아 있는지 파악해야 한다. 우리가 "이 규칙은 중요하다"고 판단하는 기준이 막연한 직관이 아니라, 글로벌 공공 서비스 디자인의 흐름 안에서 위치를 갖고 있어야 한다. 둘째, KRDS의 빈틈을 발견할 수 있기 때문이다. "해외에서는 이미 이런 패턴을 시스템화했는데, KRDS에는 아직 없다"는 발견은, 우리 점검 도구가 미래를 향해 어떻게 진화해야 하는지를 힌트를 준다.

다만 이 글이 "GOV.UK가 더 낫다" 혹은 "USWDS를 따라 해야 한다"는 식의 결론으로 흐르지 않도록 처음부터 주의하려 한다. 각 시스템은 그 나라의 법제도, 언어, 사용자 조사, 행정 조직의 방식 위에 서 있다. 맥락을 빼고 숫자나 컴포넌트 수만 비교하는 건 무의미하다. 우리가 하려는 건 "대화"다 — 세 시스템이 서로 어떤 대화를 나눌 수 있을지를 상상하는 것.

---

세 시스템의 탄생 배경 — 어디서, 왜 만들어졌는가

비교를 시작하기 전에, 각 시스템이 어디서 태어났는지를 짚어야 한다. 탄생 맥락이 다르면, 같은 이름의 컴포넌트도 전혀 다른 의미를 가질 수 있기 때문이다.

GOV.UK Design System — 영국 GDS의 2018년 출발

영국 GOV.UK Design System의 직접적인 출발점은 2018년 6월이다. 영국 정부디지털서비스(Government Digital Service, GDS)는 2018년 6월 22일, 공식 블로그에 "Introducing the GOV.UK Design System"이라는 글을 올리며 이 시스템을 공개했다(GDS Blog, 2018). GDS의 블로그에 따르면, 이전까지 디자인 패턴과 코드가 여러 곳에 흩어져 있어 관리하는 전담 팀이 없었고, 그 탓에 사용자들이 최신 상태인지를 신뢰하기 어려웠다. GOV.UK Design System은 이런 분산을 한 곳으로 모으고, GDS 전담 팀이 지속적으로 유지·발전시키는 구조를 만들기 위한 시도였다.

이 출발은 사실 2012년으로 거슬러 올라간다. GDS는 2012년에 이미 '정부 디자인 원칙(Government Design Principles)'을 공표했다. 2012년 4월 3일에 처음 게시된 이 원칙은 2025년 4월 2일에도 여전히 유효하게 유지되고 있다(GOV.UK, Government Design Principles). 총 10개의 원칙 중 접근성("Accessible design is good design")과 사용자 조사("Start with user needs")는 초창기부터 핵심이었다. 2018년의 Design System은 이 6년간의 원칙이 실제 코드와 컴포넌트로 구체화된 결과물이라고 볼 수 있다.

2022년 3월에는 "The GOV.UK Design System is now live"라는 블로그 포스트로 정식 버전 공개를 알렸다(GDS Blog, 2022). 이후 GOV.UK Design System은 계속 업데이트를 거듭해 2024년에는 WCAG 2.2 AA 대응 업데이트를 완료했다. GOV.UK의 Accessibility in Government 블로그는 2024년 1월에 "Get to WCAG 2.2 faster with the GOV.UK Design System"이라는 글에서, WCAG 2.2 표준에 대응하는 구체적인 업데이트 내역을 상세히 공개했다(Accessibility in Government Blog, 2024).

USWDS — 미국 연방 정부의 2015년 디지털 경험 표준화

미국의 U.S. Web Design System(USWDS)은 2015년에 시작됐다. GOV.UK보다 3년 앞선다. 만들어진 배경은 영국과 다르다. 미국은 연방 정부 기관이 수백 개에 달하고, 각 기관이 독립적으로 웹사이트를 운영한다. 기관마다 UI가 제각각이어서, 시민이 연방 정부 서비스를 이용할 때 매번 낯선 화면과 씨름해야 했다.

USWDS의 공식 페이지(designsystem.digital.gov)는 이 시스템이 "원칙, 가이드, 코드로 연방 기관이 접근 가능하고 모바일 친화적인 정부 웹사이트와 디지털 서비스를 구축하기 쉽게 만든다"고 설명한다(USWDS 공식, 2025). 2018년에 통과된 '21세기 통합 디지털 경험법(21st Century Integrated Digital Experience Act, 21st Century IDEA)'은 연방 기관이 USWDS를 적용하도록 명시적으로 요구한다. 즉, USWDS는 "사용하면 좋은" 가이드라인이 아니라, 연방법이 뒷받침하는 의무에 가까운 표준이다.

USWDS는 2022년에 버전 3.0을 출시했다. 이 버전에서 가장 크게 달라진 건 Sass 모듈 방식의 전환이다. 하나의 진입점에서 @use...with() 규칙으로 설정을 불러오는 방식이 도입됐고, 이로써 팀마다 디자인 토큰을 독립적으로 커스터마이징할 수 있게 됐다. 2024년에는 WCAG 2.2의 Section 508 통합이 이루어졌고, 44개의 USWDS 컴포넌트가 2025년 3월에 접근성 평가를 받아 같은 해 5월에 결과가 공개됐다(USWDS 공식, 2025).

KRDS — 한국 행안부의 2024년 공식 배포

KRDS는 'KoRea Design System'의 약자로, 행정안전부와 디지털플랫폼정부위원회가 배포한 범정부 디자인 시스템이다. 공식적으로 2024년에 배포됐다. GOV.UK(2018)나 USWDS(2015)보다 훨씬 나중이지만, 그 나중에 시작된 만큼 앞선 사례들을 참고할 수 있었고, 실제로 WCAG 2.1 AA 기준을 처음부터 토큰과 컴포넌트 단계에 내장했다.

KRDS의 공식 소개(krds.go.kr)는 이 시스템이 "모든 사용자가 동등하게 이용할 수 있는 디지털 정부 서비스를 구현할 수 있도록 웹 접근성 지침에 기반한 UI/UX 설계 기준을 스타일, 컴포넌트, 패턴 등의 구성 요소별로 제공한다"고 명시한다(KRDS 공식, krds.go.kr). 접근성 기준으로는 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2, 전자정부 웹사이트 품질관리 지침(웹 접근성), 국제 표준 WCAG 2.1을 따른다.

KRDS가 뒷받침하는 상위 법령은 「전자정부 웹사이트 품질관리 지침」이다. 행정안전부고시 제2025-46호(2025. 6. 25. 일부개정)는 이 지침을 가장 최근에 업데이트한 버전으로, 7대 품질 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)을 규정하고 있다(국가법령정보센터, law.go.kr; 행정안전부, mois.go.kr).

이렇게 놓고 보면, 세 시스템은 '디자인 시스템'이라는 같은 범주 안에 있지만 출발 연도, 법적 의무의 강도, 초기 설계 철학이 모두 다르다. 이 맥락을 염두에 두고 이제 본격적인 비교로 들어가 보자.

---

철학 비교 — 세 시스템이 품고 있는 서로 다른 가치

디자인 시스템을 비교할 때 가장 표면적인 방법은 "컴포넌트가 몇 개냐"를 세는 것이다. 하지만 그건 제일 피상적인 비교다. 더 중요한 건 시스템이 '왜 이렇게 설계됐는가'를 드러내는 철학적 원칙들이다.

GOV.UK의 10대 정부 설계 원칙 — "사용자 필요에서 시작하라"

GOV.UK의 설계 철학은 10개의 정부 디자인 원칙(Government Design Principles)으로 압축된다. 그 첫 번째가 "Start with user needs(사용자 필요에서 시작하라)"다. 원칙의 설명은 이렇다: 서비스 설계는 사용자 필요를 파악하는 것에서 시작한다. 정부의 필요가 아니다. 사용자가 원하는 것이다. 이를 위해 조사하고, 데이터를 분석하고, 실제 사용자와 대화해야 한다(GOV.UK, Government Design Principles, 2025).

이 원칙이 단순한 선언이 아닌 이유는, GOV.UK Design System 자체가 이 원칙의 산물이기 때문이다. GOV.UK Design System의 컴포넌트와 패턴은 "우리가 만들고 싶어서"가 아니라, 수백 개 정부 서비스 팀이 실제로 사용하면서 반복적으로 필요로 한 것들을 거꾸로 정리한 것이다. 커뮤니티 기반의 기여 구조가 핵심이다. GOV.UK Design System 공식 문서는 "대부분의 컴포넌트와 패턴이 외부 사용자의 기여로 이루어진다"고 명시하며, 매달 커뮤니티 캐치업을 열어 의견을 모은다(GOV.UK Design System, Community, 2024). 즉, 시스템이 커뮤니티를 먹여 살리는 게 아니라, 커뮤니티가 시스템을 진화시키는 구조다.

열 번째 원칙인 "Make things open: it makes things better(공개하라, 그러면 더 좋아진다)"도 주목할 만하다. GOV.UK Frontend는 MIT 라이선스로 공개돼 있다. 소스코드, 디자인, 아이디어, 심지어 실패한 경험도 공유하는 문화다. 이 원칙이 NHS 디자인 시스템, 호주 DTA의 시스템 등이 GOV.UK를 직접 참고해 만들어진 배경이 됐다. 2019년에는 GDS 블로그에 "Adapting the GOV.UK Design System for the NHS"라는 게스트 포스트가 실리기도 했다(GDS Blog, 2019).

USWDS의 4대 디자인 원칙 — "접근성은 모두에게 영향을 미친다"

USWDS는 4개의 디자인 원칙을 갖고 있다: ① 실제 사용자 필요에서 시작하라(Start with real user needs), ② 신뢰를 얻어라(Earn trust), ③ 접근성을 껴안아라(Embrace accessibility), ④ 연속성을 촉진하라(Promote continuity). 이 원칙들은 21세기 통합 디지털 경험법의 중요한 가이드를 지원하고 반영한다고 명시돼 있다(USWDS, Design Principles, 2025).

이 중 "Embrace accessibility" 원칙의 설명이 인상적이다. "접근성은 모두에게 영향을 미친다. 이것을 모든 결정에 내장하라. 법적 요건은 접근성을 고려하기 위한 중요한 출발점이지만, 그것은 시작에 불과하다. 접근성은 서비스를 이용하는 실제 사람들에 관한 것이다 — 이용 방식과 무관하게 가능한 한 넓은 청중을 위한 사용성이다. 연방 자원에 접근성을 만드는 일에는 정부 웹사이트에서 일하는 모든 사람이 역할을 맡고 있다. 관대하게 설계하고, 접근성 요건을 모든 사용자를 위해 더 좋은 제품을 만드는 설계 제약으로 축하해야 한다"(USWDS, Design Principles, 2025).

USWDS의 '성숙도 모델(maturity model)'도 GOV.UK에는 없는 독특한 개념이다. 원칙(Principles) → 가이드(Guidance) → 코드(Code)의 세 동심원으로 구성되며, 기관들이 한꺼번에 전환하지 않아도 단계적으로 디자인 시스템을 도입할 수 있도록 돕는다(USWDS, Maturity Model). 연방 기관 수백 개가 서로 다른 기술 스택과 예산, 내부 역량을 갖고 있기 때문에 필요한 유연성이다. 실제로 "연방 행정부 도메인 중 약 4분의 1 정도만이 어떤 형태로든 디자인 시스템 코드를 사용하고 있다"는 조사 결과도 있다(USWDS, Research). 성숙도 모델은 나머지 4분의 3에게 문을 열어두기 위한 장치이기도 하다.

KRDS의 3방향 — "일관성, 접근성, 효율성"

KRDS는 다소 다른 방식으로 철학을 표현한다. 공식 소개(krds.go.kr)에 따르면 KRDS는 "일관성(Consistency), 접근성(Accessibility), 효율성(Efficiency)"의 세 가지 방향성을 기준으로 설계됐다. GOV.UK나 USWDS에 비해 원칙의 수가 적고, 표현도 간결하다.

주목할 점은 접근성이 GOV.UK·USWDS와 동일하게 핵심 가치로 명시된다는 것이다. 다만 KRDS의 접근성은 조금 다른 법적 근거 위에 서 있다. 「장애인차별금지 및 권리구제 등에 관한 법률」과 「웹 접근성 국가표준 KWCAG 2.1」이 공공기관 웹·앱에 WCAG 2.1 AA 동등 이상의 접근성을 요구하고, KRDS는 이를 토큰과 컴포넌트 단계부터 강제하는 기술 표준 역할을 한다. KWCAG 2.2는 4개 원칙과 14개 지침, 33개 검사항목으로 구성된 한국형 웹 콘텐츠 접근성 지침이다(KWCAG 2.2, a11ykr.github.io).

흥미로운 점은 KRDS의 '효율성'이 세 원칙 중 하나라는 것이다. GOV.UK나 USWDS의 핵심 원칙에서 '효율성'이 명시적으로 등장하지는 않는다. KRDS의 효율성은 "공공기관이 시스템을 빠르게 도입하고 유지 비용을 줄일 수 있도록 한다"는 의미를 담고 있다. 행안부가 수천 개의 공공기관에 하나의 시스템을 보급해야 하는 현실적 제약이 원칙에 반영된 셈이다.

---

구조 비교 — 세 시스템은 어떻게 나뉘어 있는가

철학 다음은 구조다. 같은 "디자인 시스템"이라도 내부 위계가 어떻게 나뉘느냐는, 사용자가 시스템을 어떻게 이해하고 쓰는지에 큰 영향을 준다.

GOV.UK: 스타일 → 컴포넌트 → 패턴 (3단계)

GOV.UK Design System(design-system.service.gov.uk)은 크게 세 층으로 구성된다.

• 스타일(Styles): 색상, 타이포그래피, 이미지, 레이아웃, 스페이싱. 가장 기본적인 시각 언어.
• 컴포넌트(Components): 아코디언, 버튼, 날짜 입력, 오류 메시지, 오류 요약, 폼 그룹, 태스크 리스트, 파일 업로드 등 재사용 가능한 UI 부품(GOV.UK Design System, Components, 2025).
• 패턴(Patterns): 여러 컴포넌트를 조합해 특정 서비스 상황에 맞는 해법. "답변 확인(Check answers)", "여러 작업 완료(Complete multiple tasks)", "오류에서 회복(Recover from validation errors)", "문제 있는 서비스 페이지(Problem with the service pages)" 같은 패턴이 있다(GOV.UK Design System, Patterns, 2025).

GOV.UK의 특이점은 '패턴' 층이 매우 서비스 지향적이라는 점이다. "답변 확인(Check answers)" 패턴은 사용자가 신청서를 제출하기 전에 자신의 입력 내용을 검토하게 하는 전형적인 공공 서비스 패턴이다. 이 패턴은 사용자의 자신감을 높이고 오류율을 낮춘다고 명시돼 있다(GOV.UK Design System, Check answers pattern, 2025). "태스크 리스트(Task list)" 컴포넌트는 사용자가 완료해야 할 여러 작업의 진행 상태를 한눈에 파악하게 한다 — 장기에 걸친 복잡한 정부 서비스를 신청할 때 필요한 UI다.

GOV.UK Frontend는 오픈소스 Nunjucks 템플릿 라이브러리로 공개돼 있고, Vue, Rails, .NET 등 다양한 프레임워크로의 커뮤니티 포팅 버전도 존재한다(GitHub, alphagov/govuk-design-system). 기술 스택에 구애받지 않고 접근할 수 있는 생태계가 형성돼 있다는 점이 강점이다.

USWDS: 디자인 토큰 → 유틸리티 → 컴포넌트 → 템플릿 (4단계)

USWDS는 GOV.UK보다 한 층이 더 있다. "디자인 토큰"이 별도의 층으로 독립돼 있다.

• 디자인 토큰(Design Tokens): 색상, 스페이싱, 타이포그래피, 불투명도 같은 가장 원자적인 스타일 단위. Sass 변수로 관리된다. "USWDS의 시각 디자인은 디자인 토큰이라고 불리는 일관된 팔레트의 타이포그래피, 스페이싱 단위, 색상, 그리고 다른 개별 스타일 요소들을 기반으로 한다"(USWDS, Design Tokens, 2025).
• 유틸리티(Utilities): 토큰에 매핑된 단일 목적의 CSS 클래스. margin-x-neg-2 같은 방식으로 HTML 클래스로 바로 쓸 수 있다. 프로토타이핑을 빠르게 할 수 있는 도구다.
• 컴포넌트(Components): 버튼, 카드, 아코디언, 알림, 테이블 등. 2025년 3월에는 44개 컴포넌트의 접근성 평가가 완료됐다.
• 템플릿(Templates): 여러 컴포넌트를 조합한 페이지 레벨의 레이아웃 예시.

USWDS의 스페이싱 단위 토큰은 8px 배수 기반이다(USWDS, Spacing Units). KRDS가 8pt 그리드를 기본으로 하는 것과 동일한 원리다. 우연이 아니다 — 8px 그리드는 모바일부터 데스크탑까지 다양한 화면에서 픽셀이 깔끔하게 맞아떨어지는 가장 보편적인 기준이기 때문이다.

USWDS가 GOV.UK와 다른 점 중 하나는 서체다. USWDS는 "Public Sans"라는 연방 정부 전용 오픈소스 폰트를 개발했다. "USWDS의 서체 Public Sans는 시스템 폰트와 시각적으로 유사하게 개발됐다"(USWDS, Font, 2025). 시스템 폰트와의 유사성은 폰트 로딩 속도와 친숙함 두 가지를 동시에 챙기기 위한 선택이다.

KRDS: 원칙 → 스타일 → 컴포넌트 → 기본 패턴 → 서비스 패턴 (5단계)

KRDS는 세 시스템 중 위계가 가장 세분화돼 있다. 특히 '패턴' 층이 '기본 패턴(Basic Pattern)'과 '서비스 패턴(Service Pattern)'으로 나뉘는 것이 특징이다.

• 스타일(Style): 색상, 타이포그래피, 스페이싱, 그리드, 그림자.
• 컴포넌트(Component): 버튼, 입력창, 셀렉트박스, 테이블, 탭, 모달, 알림, 날짜 선택 등 UI 부품.
• 기본 패턴(Basic Pattern): 반복적으로 쓰이는 상호작용 방식의 묶음. 폼 작성, 동의/확인, 오류 처리, 필터·정렬.
• 서비스 패턴(Service Pattern): 특정 서비스 흐름 전체. 로그인, 검색, 민원 신청, 정책 안내.

KRDS의 서비스 패턴에는 GOV.UK의 패턴과 유사한 개념이 있지만, 한국 공공 서비스의 특성이 반영된 내용도 있다. '민원 신청' 패턴은 한국 행정 서비스에서 반복적으로 등장하는 절차 — 신청서 작성, 본인 인증, 서류 첨부, 제출, 결과 확인 — 를 하나의 흐름으로 정의한다.

또한 KRDS의 서비스 패턴에는 "필수(Do) - 권장(Better) - 우수(Best)"라는 세 단계의 적용 수준이 있다(KRDS 공식, krds.go.kr). 이는 GOV.UK나 USWDS에는 없는 독특한 설계다. 모든 기관이 같은 수준의 자원과 역량을 갖추고 있지 않다는 현실을 인정하고, '일단 최소한 이것만은 하라(Do)'부터 시작해 점진적으로 수준을 높여갈 수 있는 구조를 제공한다. USWDS의 성숙도 모델과 비슷한 발상이지만, 표현 방식이 다르다.

ViewCheck가 KRDS를 846개 규칙으로 점검할 때, 이 4개의 카테고리(DS·CP·BP·SP)가 바로 이 5단계 위계에서 '스타일→컴포넌트→기본 패턴→서비스 패턴'에 대응한다. 각 카테고리에서 규칙 수가 다른 것도 이 위계의 복잡도 차이를 반영한다 — 컴포넌트(CP) 446개가 가장 많은 건, 공공 서비스에 쓰이는 UI 부품의 종류가 그만큼 다양하기 때문이다.

---

접근성 비교 — 세 시스템은 얼마나 깊이 접근성을 다루는가

세 시스템 모두 접근성을 핵심 가치로 내세운다. 그런데 깊이를 들여다보면 각자의 방식이 다르다.

GOV.UK: "사용하는 것만으로 접근성이 확보되지 않는다"는 솔직함

GOV.UK Design System의 접근성 페이지(design-system.service.gov.uk/accessibility/)는 중요한 문장을 담고 있다. "GOV.UK Design System을 서비스에 사용한다고 해서 그 서비스가 자동으로 접근성을 갖추는 것은 아니다. 서비스가 접근 가능하도록 하기 위해서는 스타일, 컴포넌트, 패턴을 사용할 때도 추가적인 조사, 설계, 개발, 테스트 작업이 필요하다"(GOV.UK Design System, Accessibility, 2025).

이 솔직함은 중요하다. 많은 도구가 "이걸 쓰면 접근성이 해결된다"고 과장하는 경향이 있는데, GOV.UK는 그 한계를 명시한다. 접근성은 컴포넌트 하나가 결정하는 게 아니라, 서비스 전체의 콘텍스트에서 판단해야 한다는 것이다.

GOV.UK Design System은 2023년에 새로운 접근성 전략을 발표했다(Accessibility in Government Blog, 2023). 이 전략의 핵심은 컴포넌트를 WCAG AA 기준에서 먼저 출시하고, 이후 추가적인 접근성 개선을 우선순위에 따라 진행하는 방식이다. 완벽하게 만든 다음 출시하기보다, 최소 기준을 충족한 상태에서 빠르게 출시하고 이후 반복 개선하는 GDS의 일반적 방법론을 접근성에도 적용한 것이다.

WCAG 2.2 대응에 관해서는, GOV.UK Design System이 2024년에 50개 이상의 새로운 WCAG 2.2 가이드 콘텐츠를 추가하고, GOV.UK Frontend 코드 변경을 완료했다(accessibility.blog.gov.uk, 2024). 포커스 상태(focus states)는 GOV.UK 특유의 노란색과 검정색 조합으로 구현돼 있으며, 이는 WCAG 2.2의 성공 기준 1.4.11(비텍스트 대비, Non-text contrast) AA 수준을 충족한다(GOV.UK Design System, Understanding focus state styles, 2025). 이 포커스 스타일은 GOV.UK Design System의 시각적 정체성 중 하나가 됐을 만큼 독특하다.

USWDS: "법적 요건은 시작일 뿐"이라는 야망

USWDS의 접근성 원칙은 앞에서 인용한 것처럼, "법적 요건은 시작에 불과하다"고 말한다. 미국 연방 정부에서 접근성의 법적 근거는 1973년 재활법 508조(Section 508)다. 1998년에 개정돼 연방 기관이 조달·유지·사용하는 전자 정보 기술이 장애인에게도 접근 가능해야 한다고 명시하고 있다(Section508.gov, 2024). USWDS는 이 법적 의무의 기술적 구현체이면서, 동시에 그 최솟값을 넘어서기를 지향한다.

WCAG 2.2는 W3C가 2023년 10월 5일에 정식 권고안으로 공표한 버전이다(W3C, 2023). 2025년에는 국제표준(ISO/IEC 40500:2025)으로도 채택됐다(W3C Press Release, 2025). USWDS는 이 버전을 따라가고 있으며, 2025년에 44개 컴포넌트의 접근성 평가 결과를 공개했다.

USWDS의 접근성 문서(designsystem.digital.gov/documentation/accessibility/)는 WCAG의 4대 원칙(인식 가능·조작 가능·이해 가능·견고함)을 접근성의 토대로 설명한다. 그리고 "접근성은 서비스를 이용하는 실제 사람들에 관한 것"이라는 문장을 반복한다. 이건 숫자 충족을 넘어선 인간 중심 접근성의 개념이다.

KRDS: KWCAG 2.2와 WCAG 2.1의 이중 기준

KRDS의 접근성 기준은 KWCAG 2.2와 WCAG 2.1의 이중 구조다. KWCAG(한국형 웹 콘텐츠 접근성 지침) 2.2는 4개 원칙, 14개 지침, 33개 검사항목으로 구성된다. WCAG 2.1의 4개 원칙을 계승하면서, 한국 실정에 맞게 재편한 버전이다.

KRDS는 디자인 토큰 단계부터 접근성을 내장한다. 예를 들어, 색상 대비 비율은 WCAG AA 기준(일반 텍스트 4.5:1, 대형 텍스트 3:1)을 충족하도록 토큰이 설계돼 있다. Pretendard GOV 서체는 2023년 디자이너 길현진이 KRDS의 공식 서체로 만든 오픈소스 폰트다. "접근성과 공공 기관을 위한 가독성에 초점을 맞춰 설계됐다"(나무위키, Pretendard GOV). 기본 사이즈는 17px으로 다른 서체보다 약간 작아 보이도록 설계됐고, 본문 최소 크기는 16px 이상을 권장한다.

KRDS의 접근성이 GOV.UK·USWDS와 다른 한 가지 특징은, 컴포넌트별로 WCAG 적합성 수준을 문서 내에 명시한다는 점이다. 공식 웹사이트의 컴포넌트 페이지 아래에 어떤 WCAG·KWCAG 항목을 충족하는지가 표기돼 있다. GOV.UK나 USWDS에도 접근성 정보가 있지만, KRDS처럼 컴포넌트 페이지 안에 기준 번호까지 병기하는 방식은 점검 도구가 활용하기 쉬운 구조다. ViewCheck가 규칙을 만들 때 이 구조가 실용적인 참고 자료가 된다.

---

증적 — ViewCheck가 KRDS 비교 기능을 실제로 어떻게 보여주는가

ViewCheck의 24개 분석 기능 중 하나가 'KRDS 비교(KRDS Comparison)'다. 이 카드는 분석한 사이트의 KRDS 846규칙 판정 결과를 바탕으로, 어떤 영역에서 어느 정도의 준수도를 보이는지를 정리해 준다. 여기서 "비교"는 단순히 점수를 보여주는 것이 아니다. 각 카테고리(DS·CP·BP·SP)에서 통과된 규칙의 비율, 주요 미통과 항목, 그리고 그 미통과가 국제 기준(WCAG·KRDS 공식 체크리스트)과 어떤 맥락에서 연결되는지를 함께 보여준다.

이 기능을 만들면서 우리가 반복해서 부딪힌 문제가 있다. 규칙이 "미통과"라고 판정됐을 때, 그게 실제로 사이트의 문제인지, 아니면 우리 분석 도구의 한계인지를 어떻게 구분하느냐는 것이다. 예를 들어, 해당 페이지에 특정 컴포넌트 자체가 없어서 "해당없음(N/A)"으로 처리됐는데, 그걸 "미통과"로 잘못 분류하면 사이트에 대한 과도한 평가가 된다. 반대로, 시각적으로 문제가 있는데 DOM만 봐서는 감지하지 못하고 "통과"로 처리하면 그것도 부정확하다.

이 'KRDS 비교' 카드를 제대로 만들기 위해서는, 비교 기준이 되는 GOV.UK·USWDS 같은 해외 시스템이 어떤 항목을 어떻게 정의하는지를 정확히 알아야 한다. 단순히 "이 기준이 있다"를 아는 것이 아니라, "이 기준이 왜 이렇게 설계됐는지"를 이해해야 한다. 그래야 KRDS의 어떤 규칙이 국제적으로도 중요한 기준인지, 어떤 규칙이 한국 고유의 맥락에서만 유효한지를 구분할 수 있고, 분석 결과를 더 의미 있게 전달할 수 있다.

---

컴포넌트 비교 — 같은 이름, 다른 깊이

세 시스템 모두 버튼, 입력창, 테이블, 탭 같은 기본 컴포넌트를 갖고 있다. 그런데 같은 이름을 갖고 있어도, 그 컴포넌트가 어떤 상황까지 정의하는지는 꽤 다르다.

버튼을 예로 들어보자. GOV.UK Design System의 버튼 컴포넌트는 "Start now" 버튼처럼 서비스 진입점에 쓰이는 특별한 변형을 갖고 있고, 경고(Warning) 버튼이나 보조(Secondary) 버튼 같은 변형도 있다. 중요한 건 각 변형이 "언제 쓰고, 언제 쓰지 말아야 하는지"의 가이드를 함께 제공한다는 것이다. GOV.UK Design System의 버튼 페이지에는 "버튼은 지금 즉시 일어나는 행동에 사용하라. 링크는 사용자를 다른 페이지나 영역으로 보낼 때 사용하라"처럼 구체적인 사용 원칙이 있다.

USWDS의 버튼 컴포넌트는 색상 변형이 풍부하다. Primary, Secondary, Accent cool, Accent warm, Base, Outline, Unstyled 등 다양한 변형이 있고, 각각의 색상은 USWDS의 디자인 토큰 팔레트에서 가져온다. 이 풍부한 변형은 연방 기관마다 브랜드 아이덴티티가 다를 수 있다는 현실에서 나온다. 기관마다 토큰을 커스터마이징해 자신의 브랜드 색상 체계를 유지하면서도 USWDS의 구조를 쓸 수 있게 한다.

KRDS의 버튼은 기본, 아웃라인, 고스트, 텍스트 변형이 있고, 크기(Large·Medium·Small)와 상태(Normal·Hover·Active·Focus·Disabled)도 정의돼 있다. 포커스 상태의 스타일은 KRDS 접근성 기준에 따라 WCAG AA 이상을 충족하도록 설계됐다. KRDS의 버튼이 GOV.UK나 USWDS와 다른 점 하나는, 한국 공공 서비스에서 많이 쓰이는 "이전/다음" 쌍 버튼 패턴이 기본 패턴으로 정의돼 있다는 것이다. 이건 여러 단계를 거치는 민원 신청 흐름에서 반드시 필요한 패턴이다.

오류 처리는 세 시스템의 철학 차이가 가장 뚜렷이 드러나는 영역이다. GOV.UK의 오류 메시지 컴포넌트(design-system.service.gov.uk/components/error-message/)는 "오류가 발생하면 화면 오류 요약(Error summary)을 맨 위에 표시하고, 해당 필드 옆에 인라인 오류 메시지도 함께 표시하라"고 이중 안내를 요구한다. 이 가이드는 시각 장애인이 스크린 리더로 페이지를 탐색할 때 오류를 놓치지 않도록 하기 위한 것이다. 오류 메시지 컴포넌트의 HTML에는 스크린 리더를 위해 숨겨진 'Error:'라는 텍스트가 포함돼 있다(GOV.UK Design System, Error message, 2025).

KRDS도 오류 처리 패턴을 기본 패턴(BP)으로 정의하고 있다. ViewCheck의 BP 카테고리 108개 규칙 중 오류 처리 관련 규칙들이 포함된다. 다만 우리가 분석 과정에서 발견한 것은, 실제 공공 사이트에서 오류 처리가 가장 취약한 영역 중 하나라는 점이다. 폼을 작성하다 오류가 나면 안내가 없거나, 안내가 있어도 시각적으로만 표시되고 스크린 리더가 읽을 수 없는 형태인 경우를 자주 만난다. GOV.UK의 이중 안내 원칙이 KRDS에도 명시적으로 반영돼 있지만, 실제 적용 여부는 사이트마다 다르다. 이걸 자동으로 점검하는 것이 BP 카테고리 점검의 핵심 목적 중 하나다.

---

서비스 패턴 비교 — 공공 서비스의 흐름을 어떻게 정의하는가

서비스 패턴은 세 시스템 중 KRDS가 가장 깊이 정의한 영역이다. 그리고 동시에 세 시스템의 문화적 차이가 가장 뚜렷하게 드러나는 영역이기도 하다.

GOV.UK의 패턴 라이브러리에는 실용적인 서비스 흐름들이 담겨 있다. "주소 묻기(Addresses)", "날짜 묻기(Dates)", "이름 묻기(Names)", "국적 묻기(Nationality)" 같은 것들이다. 영국 정부 서비스에서 반복적으로 나타나는 정보 수집의 패턴을 정의한 것이다. "Check answers" 패턴이나 "Task list" 패턴처럼, 복잡한 신청 흐름을 관리하는 구조도 있다(GOV.UK Design System, Patterns, 2025). 주목할 건, 이 패턴들이 "어떻게 보여주는가"보다 "어떤 상황에서 왜 이렇게 해야 하는가"를 더 강조한다는 점이다. 사용자 연구에서 도출된 근거가 패턴마다 함께 제시된다.

USWDS의 패턴은 "디지털 경험을 일관되게 만들기 위한 일반적인 UX 문제에 대한 검증된 해법"으로 정의된다(designsystem.digital.gov). 예를 들어 "비밀번호 만들기(Create a user profile)" 패턴은 연방 기관의 계정 관리 서비스에서 반복되는 흐름을 정의한다. USWDS는 이 패턴들이 특정 기관만의 것이 아니라, 연방 정부 전체에서 일관되게 적용될 수 있도록 설계됐다. 기관 간의 경험 연속성(Promote continuity)이 USWDS의 핵심 원칙 중 하나인 이유도 여기에 있다. 시민이 한 연방 기관의 서비스를 경험한 후 다른 기관의 서비스로 이동할 때, 비슷한 경험을 기대할 수 있어야 한다는 것이다.

KRDS의 서비스 패턴(SP)은 이 두 시스템과는 결이 약간 다르다. '로그인', '검색', '신청', '정책 안내' 같은 패턴은 한국 공공 서비스에서 가장 자주 만나는 흐름들이다. 특히 '신청' 패턴은 한국 전자 정부의 핵심 서비스 유형으로, 본인 인증 → 신청서 작성 → 서류 첨부 → 제출 → 처리 결과 확인의 흐름이 세세하게 정의돼 있다.

ViewCheck의 SP 카테고리 172개 규칙은 이 서비스 패턴을 얼마나 잘 따르는지를 점검한다. 우리가 이 점검을 설계할 때 가장 어려웠던 부분은, 서비스 패턴의 준수 여부가 단일 페이지가 아니라 여러 페이지에 걸친 흐름 전체를 봐야 한다는 점이다. '로그인 패턴'을 점검하려면 로그인 페이지만 보는 게 아니라, 로그인 후의 흐름, 세션 만료 안내, 비밀번호 재설정 흐름까지 봐야 완전한 판정이 가능하다. 이게 ViewCheck가 다중 페이지 분석을 기본값으로 하는 핵심 이유 중 하나다.

---

타이포그래피와 디자인 토큰 — 세 시스템의 가장 원자적인 차이

타이포그래피와 디자인 토큰은 비교적 기술적인 주제지만, 공공 서비스의 접근성과 브랜드 일관성에 직접적인 영향을 미친다.

GOV.UK의 타이포그래피는 "GDS Transport"라는 자체 서체를 사용한다. 이 서체는 영국 도로 표지판에 사용된 Transport 서체를 디지털 환경에 맞게 재해석한 것이다. GOV.UK의 색상 팔레트는 매우 제한적이다. 배경은 흰색, 본문 텍스트는 짙은 회색에 가까운 검정(#0b0c0c), 링크는 파란색, 그리고 포커스 상태의 강렬한 노란색이 GOV.UK의 시각적 정체성이다. 이 제한된 팔레트는 "단순함을 유지하라(Keep it simple)"는 원칙의 시각적 표현이다.

GOV.UK의 색상 대비는 매우 높다. 배경 흰색과 본문 텍스트의 대비비는 WCAG AAA 수준을 초과한다(accessibility.blog.gov.uk, 2016). 영국 정부는 시각적 일관성과 접근성 두 마리 토끼를 잡기 위해, 단순하지만 고대비의 팔레트를 선택했다.

USWDS의 타이포그래피는 앞에서 언급한 Public Sans가 핵심이다. 이 폰트는 시스템 폰트(San Francisco, Segoe UI 등)와 시각적으로 유사하게 설계돼 있어, 폰트가 로딩되지 않는 상황에서도 사용자 경험이 크게 달라지지 않는다. 스페이싱은 8px 배수 기반이며, 타이포그래피 크기 토큰은 '1xs'부터 '3xl'까지 표준화된 이름으로 관리된다. USWDS의 색상 팔레트는 훨씬 다양하다. 90여 개의 색상 토큰이 있으며, 기관들이 USWDS의 색상 팔레트 안에서 자신의 브랜드 색상을 선택할 수 있다.

KRDS의 타이포그래피는 Pretendard GOV가 공식 서체다. "상하좌우 여백이 균형 잡힌 한글·영문 혼용 기준으로 최적화된 공공 서비스용 서체"가 목표다. 기본 크기는 17px이며, 본문 최소 크기는 16px이다. 코드에서는 rem 단위로 변환해 접근성과 반응형을 함께 챙긴다.

ViewCheck가 실측한 KRDS의 디자인 토큰 규모는 색상 토큰 약 586개, 전체 토큰 약 768개다. 이 숫자는 직접 소스를 읽어서 확인한 것이다(인터넷에서 '1,082개'라는 숫자가 돌아다니기도 하는데, 우리가 실측한 결과와 다르다). 토큰의 구조는 프리미티브 토큰(색상, 타이포, 간격, 반지름 등 원자 값) → 시멘틱 토큰(특정 맥락에서의 의미 값) → 컴포넌트 토큰(특정 컴포넌트에 직접 적용되는 값)의 3단계다(KRDS 공식). 이 구조는 USWDS의 디자인 토큰 방식과 유사한 철학을 공유한다.

색상 토큰 수를 단순 비교하면 KRDS(약 586개)가 USWDS(약 90여 개)보다 훨씬 많다. 이건 KRDS가 더 복잡하다는 뜻이기도 하고, 한국 공공 서비스의 브랜드 다양성을 수용하기 위한 설계이기도 하다. 반면 GOV.UK는 최소한의 팔레트를 고수한다. 어떤 게 더 낫다기보다, 시스템이 처한 맥락의 차이다. GOV.UK는 단일 GOV.UK 도메인 아래 단일 비주얼 아이덴티티를 유지해야 하는 반면, KRDS는 수천 개의 기관이 각자의 상황에 맞게 적용해야 하기 때문이다.

---

오픈소스와 생태계 — 시스템 바깥의 풍경

세 시스템을 비교할 때, 시스템 자체만큼 중요한 것이 그 주변의 생태계다. 누가 기여하고, 어떻게 발전하는지가 시스템의 미래를 결정한다.

GOV.UK Design System은 MIT 라이선스로 완전히 오픈소스다. GitHub의 alphagov/govuk-design-system 저장소에서 누구나 코드를 열어볼 수 있고, 기여할 수 있다. 더 중요한 건 커뮤니티 기여 모델이다. GOV.UK Design System의 컴포넌트 대부분이 외부 기여자에서 나왔다. 기여 기준(Contribution criteria)을 통과하면 누구의 컴포넌트도 시스템에 공식 포함될 수 있다. NHS, 교육부, 지방 정부 등에서 만든 변형 버전도 커뮤니티 내에 공유된다. Design System Day라는 연례 행사도 열린다(GDS Blog, 2024).

USWDS는 미국 공공 도메인 헌납(CC0 1.0 Universal) 라이선스로 공개돼 있다. 오픈소스 라이선스 중 가장 개방적인 형태다. USWDS는 GitHub에서 관리되며, 월간 콜(Monthly calls)을 통해 커뮤니티와 정기적으로 소통한다(designsystem.digital.gov). 2022년의 USWDS 3.0 출시는 수개월에 걸친 커뮤니티 피드백 과정을 거쳤다. 다만 USWDS의 도전 과제 하나는 연방 기관 중 약 4분의 1만이 실제로 디자인 시스템 코드를 쓰고 있다는 것이다(USWDS, Research). 의무에 가까운 요건임에도 실제 도입률이 높지 않다는 점은, 성숙도 모델이 있어도 현실의 전환은 쉽지 않다는 것을 보여준다.

KRDS의 생태계는 두 시스템과 다른 형태다. KRDS는 행안부가 중앙에서 관리하는 구조로, 커뮤니티 기여 모델보다는 정부 주도의 업데이트 방식에 가깝다. Figma 파일을 공식 배포하고, HTML/CSS/JavaScript 키트를 제공한다. 버전은 행안부의 정책 주기에 맞춰 업데이트된다. 단점은 외부 기여가 어렵고, 업데이트 주기가 GOV.UK나 USWDS에 비해 느릴 수 있다는 것이다. 장점은 공공 기관 입장에서 "이게 공식"이라는 신뢰도가 높다는 것이다.

ViewCheck가 KRDS 점검 도구를 만들 때 겪는 한 가지 어려움이 여기에 있다. GOV.UK나 USWDS는 GitHub에서 이슈와 변경 내역이 공개되고, 어떤 이유로 어떤 결정을 내렸는지가 추적 가능하다. KRDS는 공식 문서와 배포 파일이 있지만, 변경의 맥락을 추적하기가 상대적으로 어렵다. 규칙이 왜 이렇게 정의됐는지를 이해하는 것이 점검 도구를 제대로 만드는 데 중요한데, 그 '왜'를 찾기가 GOV.UK에 비해 더 품이 든다.

---

KRDS의 강점 — 해외 시스템이 가지지 못한 것들

공정한 비교라면 KRDS의 약점만 볼 게 아니라 강점도 봐야 한다. 우리가 분석을 통해 발견한 KRDS의 강점들이 있다.

첫 번째 강점: 서비스 패턴의 한국화

GOV.UK나 USWDS의 패턴은 서양 공공 서비스의 맥락에서 설계됐다. 예를 들어 "국적 확인" 패턴이나 "우편번호 입력" 패턴은 영국 우편 시스템과 영국식 주소 체계에 맞게 설계됐다. 한국의 공공 서비스는 다르다. 도로명 주소와 지번 주소 병기, 주민등록번호 체계, 공공 본인 인증(PASS, 공동인증서 등), 전자 민원 신청 흐름이 한국만의 특성이다. KRDS는 이 한국 고유의 서비스 흐름을 '서비스 패턴'으로 명시적으로 정의한다. GOV.UK나 USWDS를 아무리 잘 만들어도 이 부분은 대체할 수 없다.

두 번째 강점: 필수-권장-우수의 3단계 적용 수준

앞에서 언급한 "Do-Better-Best" 구조는 GOV.UK나 USWDS에 없다. 이건 한국 공공 기관의 현실을 반영한 유연한 설계다. 예산이 부족한 지자체, 내부 개발 역량이 낮은 기관도 "일단 이것만은" 할 수 있는 최솟값을 제시한다. 모든 기관에 같은 수준의 준수를 요구하는 것이 현실적이지 않다는 걸 인정하는 것이다. USWDS의 성숙도 모델과 비슷한 발상이지만, KRDS는 이걸 컴포넌트·패턴 수준에서 직접 구현했다.

세 번째 강점: 빠른 도입을 위한 Figma 키트와 HTML 키트의 공식 배포

KRDS는 Figma 컴포넌트 라이브러리와 HTML/CSS/JS 키트를 모두 공식 배포한다. 디자이너와 개발자가 서로 다른 출발점에서 동일한 컴포넌트를 쓸 수 있게 한다. GOV.UK도 Figma 자산을 제공하고 USWDS도 디자인 에셋을 제공하지만, KRDS의 특징은 이 모든 것이 공공 기관 도입을 전제로 패키징돼 있다는 점이다.

네 번째 강점: KWCAG와 WCAG의 이중 기준 명시

한국 공공 서비스는 WCAG 국제 기준과 함께 KWCAG라는 한국 고유의 접근성 지침도 따라야 한다. KRDS는 컴포넌트마다 어떤 WCAG·KWCAG 항목을 충족하는지를 명시한다. 이건 점검 도구 입장에서 매우 실용적인 정보다. ViewCheck가 KRDS 846규칙을 만들 때, 이 이중 기준 매핑이 직접적인 참고 자료가 됐다.

---

KRDS의 빈틈 — 솔직하게 보는 개선 여지

강점을 봤으니 빈틈도 봐야 한다. 우리가 KRDS를 분석 도구로 다루면서 발견한 개선 여지들이다. 이건 KRDS를 비판하려는 게 아니라, 앞으로 도구가 어떻게 발전해야 하는지를 가늠하기 위한 것이다.

첫 번째 빈틈: 연구 근거의 가시성

GOV.UK의 패턴에는 "왜 이렇게 해야 하는가"에 대한 사용자 연구 근거가 함께 제시된다. "Check answers 패턴은 사용자의 자신감을 높이고 오류율을 낮춘다"는 서술 뒤에 실제 사용자 연구 결과가 있다. KRDS의 문서는 "무엇을 해야 하는가"는 잘 정의하지만, "왜 이렇게 결정됐는가"의 근거가 상대적으로 약하다. 점검 도구를 만드는 입장에서, 규칙의 근거를 알아야 그 규칙의 중요도를 정확히 평가할 수 있다. 근거 없이 정해진 것처럼 보이는 규칙을 점검할 때 자신감이 낮아진다.

두 번째 빈틈: 변경 내역의 투명성

GOV.UK와 USWDS는 GitHub에서 모든 변경이 이슈와 PR로 추적된다. 어떤 버전에서 무엇이 왜 바뀌었는지를 누구나 볼 수 있다. KRDS는 버전 업데이트 시 공지가 있지만, 세부 변경 이유와 논의 과정이 공개적으로 추적되지 않는다. 점검 도구 입장에서는 규칙이 언제 바뀌었는지를 파악해야 "이 버전의 KRDS에서는 이 규칙이 유효한가"를 판단할 수 있다.

세 번째 빈틈: 동적 상호작용 패턴의 상세화

GOV.UK Design System은 "페이지 내 오류가 발생했을 때 스크린 리더가 어떻게 동작해야 하는가"를 HTML 수준에서 명시한다. USWDS는 모바일 접근성, 터치 제스처, 가상 키보드 사용 시나리오까지 컴포넌트 문서에 담는다. KRDS의 동적 상호작용 — 모달이 열리고 닫힐 때의 포커스 이동, 드래그 앤 드롭의 키보드 대안, 자동완성 목록의 화살표 키 탐색 등 — 에 대한 문서는 아직 상대적으로 얇다. 이 영역이 자동화 점검에서 가장 어려운 부분이기도 하지만, 동시에 가장 중요한 접근성 이슈가 발생하는 영역이기도 하다.

네 번째 빈틈: 성과 측정 지표

USWDS는 "Why track performance"라는 문서에서, 디자인 시스템 도입과 성능(로딩 속도, 접근성 점수) 사이의 관계를 추적하려 한다. GOV.UK도 서비스별 사용자 만족도와 완료율을 측정한다. KRDS에는 아직 "KRDS를 도입하면 이런 성과가 개선됐다"는 공개된 성과 데이터가 많지 않다. 이게 KRDS 채택의 동기 부여에 영향을 줄 수 있다. 공공 기관 담당자 입장에서 "KRDS를 도입하면 무엇이 좋아지는가"를 수치로 보여주는 데이터가 있다면 더 설득력이 있을 것이다.

---

ViewCheck는 이 비교에서 무엇을 배웠는가

세 시스템을 비교하면서 ViewCheck 내부에서 가장 많이 나눈 대화는, "우리가 만든 846개 규칙이 정말 중요한 것들인가"라는 질문이었다. KRDS 공식 문서에 있다고 해서 전부 중요한 건 아니고, 해외 사례에 있다고 해서 한국 공공 서비스에 그대로 적용되는 것도 아니다.

우리가 내린 잠정적인 결론은 이렇다. 중요도는 세 가지 기준으로 판단한다: ① 세 시스템이 모두 공통으로 강조하는 것 (예: 오류 처리, 포커스 상태, 색상 대비) → 이건 국경을 초월한 중요성이 있다. ② KRDS에서 법적·정책적 의무로 명시된 것 (예: KWCAG 33개 항목) → 한국 공공 기관에서 반드시 지켜야 한다. ③ 사용자 연구 근거가 있는 것 (GOV.UK 패턴 근거, USWDS 연구 결과) → 이론이 아니라 실제 사용자 행동으로 검증된 중요성이다.

이 세 기준이 겹치는 영역이 "가장 먼저 고쳐야 할 것"이다. 세 기준 중 하나만 해당되는 것은 "중요하지만 덜 급한 것"이다. ViewCheck의 '개선 로드맵' 기능에서 우선순위를 정하는 로직이 이 판단을 반영하려 한다.

또 하나 배운 것은, 점검 도구의 진정한 가치가 "몇 개를 자동으로 점검하는가"에 있지 않다는 점이다. 846개 규칙을 자동으로 점검하는 것보다, 그 결과가 맥락과 함께 이해될 때 더 가치가 있다. GOV.UK의 오류 처리 패턴이 "왜 이중 안내가 필요한가"를 설명하듯이, ViewCheck도 "왜 이 규칙이 미통과인가"와 "이게 실제 사용자에게 어떤 영향을 미치는가"를 함께 전달해야 한다. 그게 결과 카드에 근거를 붙이고, RAG로 공식 문서 원문을 연결하는 이유다.

그리고 솔직하게 말하자면, 이 비교를 깊이 할수록 우리가 아직 모르는 게 많다는 것도 확인했다. GOV.UK의 사용자 연구 방법론, USWDS가 연방 기관 도입을 늘리기 위해 어떤 실험을 하는지, KRDS의 다음 버전에서 무엇이 달라질지 — 이것들은 공개된 문서로만 알 수 없는 영역이다. 우리는 이 비교를 "완료된 연구"가 아니라 "진행 중인 대화"로 다루고 있다.

---

실무에서의 시사점 — 공공 웹 담당자가 이 비교에서 얻을 수 있는 것

이론적 비교를 넘어서, 실제 공공 웹사이트를 담당하는 사람 입장에서 이 비교가 어떤 실용적 의미를 갖는지도 생각해 봐야 한다.

하나. "왜 이걸 지켜야 하는가"를 설명할 수 있게 된다.

KRDS 규칙을 지켜야 한다는 요구를 받았을 때, "그냥 지침이라서"가 아니라 "GOV.UK에서도 이 패턴이 중요하고, USWDS도 같은 이유로 이걸 강조하며, W3C WCAG도 이걸 기준으로 삼는다"고 말할 수 있다면 훨씬 설득력이 있다. 국제적으로 검증된 기준과 KRDS가 어떻게 연결되는지를 이해하면, 내부 보고나 외주사에 대한 요구가 더 명확해진다.

둘. KRDS에 없는 것도 참고할 수 있다.

KRDS에 아직 패턴이 없는 영역이 있다. 예를 들어 공공 사이트에서 챗봇이나 AI 어시스턴트를 어떻게 접근 가능하게 만들 것인가 — 이건 KRDS가 아직 명시적으로 다루지 않는 영역이다. 반면 GOV.UK나 USWDS는 이미 이 주제에 대한 가이드를 발전시키고 있다. KRDS 공식 패턴이 없다고 해서 무시해야 한다는 뜻이 아니다. 오히려 GOV.UK·USWDS를 참고해 "KRDS 정신에 맞는 해법"을 스스로 설계할 수 있다.

셋. 점검 결과를 "점수"로만 보지 않을 수 있다.

ViewCheck가 KRDS 점검 결과를 보여줄 때, 숫자(통과율, 미통과 수)만 보는 것보다 "이 미통과가 GOV.UK의 어떤 원칙과 연결되고, USWDS의 어떤 기준에 해당하며, W3C WCAG의 어떤 항목으로 이어지는가"를 함께 볼 수 있다면 더 유용한 정보가 된다. 이게 ViewCheck의 'KRDS 비교' 카드가 지향하는 방향이다.

---

우리가 아직 모르는 것 — 비교 연구의 솔직한 한계

이 글을 마무리하면서, 우리가 아직 확실히 알지 못하는 것들을 적어두는 것이 정직하다고 생각한다.

첫째, 세 시스템이 실제 사용자 경험에 얼마나 다른 차이를 만드는지를 우리는 직접 측정하지 못했다. GOV.UK 서비스를 이용한 영국 시민과 USWDS 기반 서비스를 이용한 미국 시민, 그리고 KRDS 기반 공공 서비스를 이용한 한국 시민이 각각 얼마나 다른 경험을 하는지에 대한 직접 비교 데이터가 없다. 이건 실험 설계가 매우 어려운 문제다.

둘째, KRDS의 실제 도입률과 준수 수준을 우리는 아직 체계적으로 파악하지 못했다. 얼마나 많은 공공 기관이 KRDS를 실제로 도입했고, 도입한 기관 중 얼마나 깊이 구현하고 있는지 — 이 데이터는 행안부의 공식 점검이나 대규모 실측 없이는 알기 어렵다. ViewCheck가 분석한 사이트들에서 보이는 패턴이 있지만, 이를 전체 공공 사이트로 일반화하기에는 표본이 충분하지 않다.

셋째, 세 시스템의 미래 방향이 어떻게 수렴하거나 갈라질지 예측하기 어렵다. 생성형 AI의 등장이 공공 서비스 UX에 영향을 미치기 시작했다. 챗봇, AI 응답, 다국어 자동 번역이 공공 서비스에 도입되면, 기존 컴포넌트·패턴 라이브러리가 어떻게 확장돼야 하는지는 세 시스템 모두 아직 명확한 답을 갖고 있지 않다.

이 세 가지 한계를 적은 이유는, "우리는 아직 모르는 게 많다"는 것이 정직한 상태이고, 그 상태에서 계속 공부하고 실험하고 있다는 것을 남겨두기 위해서다. 비교 연구는 완성되는 게 아니라 계속되는 것이다.

---

마무리 — 대화는 계속된다

KRDS, GOV.UK Design System, USWDS — 세 시스템을 나란히 놓고 들여다보면, 하나의 큰 흐름이 보인다. 공공 서비스의 디지털화가 전 세계적으로 진행되는 과정에서, 각 나라가 자국의 맥락에 맞는 해법을 찾아가고 있다는 것이다. 영국은 커뮤니티와 오픈소스의 방식으로, 미국은 연방법과 성숙도 모델의 방식으로, 한국은 행정 주도와 한국 고유의 서비스 패턴 정의로.

어느 쪽이 더 낫다고 단언할 수 없다. 각 방식은 그 나라의 행정 문화, 기술 역량, 시민 요구를 반영한다. 우리가 이 비교에서 얻으려는 건 "KRDS는 이래서 문제"가 아니라, "서로에게서 배울 게 있다"는 것이다.

ViewCheck는 이 비교를 계속할 것이다. 세 시스템이 새 버전을 내놓을 때마다, 우리의 846개 규칙이 그 변화를 얼마나 잘 따라가고 있는지를 점검해야 한다. 기준이 살아 움직이는 만큼, 그것을 점검하는 도구도 살아 움직여야 한다.

그리고 이 시리즈의 한 편이 그 '살아 움직임'의 흔적이 되길 바란다. "우리는 이걸 지금 이렇게 이해하고 있다"는 기록. 다음에 다시 읽을 때는 또 다른 이해가 쌓여 있기를 기대하면서.

---

참고문헌

본문에 인용한 출처는 작성 시점(2026년 6월)에 WebSearch를 통해 실재 여부를 직접 검증했다. 공식 문서와 정책 자료, 기관 블로그를 기준으로 삼았다.

국내 — 공식 기준 / 정책자료

1. 행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://law.go.kr/admRulInfoP.do?admRulSeq=2100000260906
2. 행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부개정 및 「품질관리 가이드」 수정본 안내(고시 제2025-46호). https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
3. KRDS(범정부 UI/UX 디자인시스템) 공식 사이트. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
4. KRDS, "KRDS 소개". https://www.krds.go.kr/html/site/utility/utility_01.html
5. KRDS, "디지털 포용 | KRDS 소개". https://www.krds.go.kr/html/site/utility/utility_04.html
6. 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2. a11ykr.github.io. https://a11ykr.github.io/kwcag22/
7. 나무위키, "Pretendard GOV". https://namu.wiki/w/Pretendard%20GOV

해외 — 디자인 시스템 공식 문서 / 기관 블로그

8. Government Digital Service(GDS), "Introducing the GOV.UK Design System", GDS Blog, 2018. 6. 22. https://gds.blog.gov.uk/2018/06/22/introducing-the-gov-uk-design-system/
9. Government Digital Service(GDS), "The GOV.UK Design System is now live", GDS Blog, 2022. 3. 31. https://gds.blog.gov.uk/2022/03/31/the-gov-uk-design-system-is-now-live/
10. Government Digital Service(GDS), "How Design System Day makes our community stronger", GDS Blog, 2024. 10. 31. https://gds.blog.gov.uk/2024/10/31/how-design-system-day-makes-our-community-stronger/
11. GDS Blog, "Adapting the GOV.UK Design System for the NHS", 2019. 6. 4. https://gds.blog.gov.uk/2019/06/04/guest-post-adapting-the-gov-uk-design-system-for-the-nhs/
12. GOV.UK Design System(공식). https://design-system.service.gov.uk/
13. GOV.UK Design System, "Accessibility". https://design-system.service.gov.uk/accessibility/
14. GOV.UK Design System, "Accessibility strategy". https://design-system.service.gov.uk/accessibility/accessibility-strategy/
15. GOV.UK Design System, "Understanding focus state styles". https://design-system.service.gov.uk/get-started/focus-states/
16. GOV.UK Design System, "Error message". https://design-system.service.gov.uk/components/error-message/
17. GOV.UK Design System, "Check answers". https://design-system.service.gov.uk/patterns/check-answers/
18. GOV.UK Design System, "Task list". https://design-system.service.gov.uk/components/task-list/
19. GOV.UK Design System, "Community". https://design-system.service.gov.uk/community/
20. GOV.UK Design System, "Contribution criteria". https://design-system.service.gov.uk/community/contribution-criteria/
21. GOV.UK, "Government Design Principles", 최초 게시 2012. 4. 3., 최종 업데이트 2025. 4. 2. https://www.gov.uk/guidance/government-design-principles
22. Accessibility in Government Blog, "A new accessibility strategy for the GOV.UK Design System", 2023. 1. 6. https://accessibility.blog.gov.uk/2023/01/06/a-new-accessibility-strategy-for-the-gov-uk-design-system/
23. Accessibility in Government Blog, "Get to WCAG 2.2 faster with the GOV.UK Design System", 2024. 1. 11. https://accessibility.blog.gov.uk/2024/01/11/get-to-wcag-2-2-faster-with-the-gov-uk-design-system/
24. U.S. Web Design System(USWDS) 공식. https://designsystem.digital.gov/
25. USWDS, "Design principles". https://designsystem.digital.gov/design-principles/
26. USWDS, "Accessibility". https://designsystem.digital.gov/documentation/accessibility/
27. USWDS, "USWDS maturity model". https://designsystem.digital.gov/maturity-model/
28. USWDS, "Design tokens". https://designsystem.digital.gov/design-tokens/
29. USWDS, "Spacing units". https://designsystem.digital.gov/design-tokens/spacing-units/
30. USWDS, "Font". https://designsystem.digital.gov/design-tokens/typesetting/font/
31. USWDS, "Product values". https://designsystem.digital.gov/about/product-values/
32. USWDS, "Key benefits". https://designsystem.digital.gov/about/key-benefits/
33. Section508.gov, "Accessible Design Using the U.S. Web Design System (USWDS)". https://www.section508.gov/develop/accessible-design-using-uswds/
34. W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", W3C Recommendation, 2023. 10. 5. https://www.w3.org/TR/WCAG22/
35. W3C Press Release, "W3C Web Content Accessibility Guidelines 2.2 approved as ISO/IEC international standard", 2025. https://www.w3.org/press-releases/2025/wcag22-iso-pas/
36. Supernova.io, "Top 10 Government Design Systems: Enhancing Digital Public Services". https://www.supernova.io/blog/top-10-government-design-systems-enhancing-digital-public-services

---