446개 컴포넌트 규칙, DOM과 ARIA로 자동 감지한다는 것 — ViewCheck 컴포넌트 준수 분석 이야기

버튼 하나에도 규칙이 있고, 446개 규칙을 사람이 다 확인한다는 건 불가능에 가깝다

들어가며 — "이 버튼, 맞게 만든 건가요?"라는 질문

공공 웹사이트를 운영하거나 개발해 본 사람이라면 어느 순간 이런 질문을 받은 적이 있을 것이다.

"이 버튼, KRDS 기준에 맞게 만든 건가요?"

단순해 보이는 질문이지만 실제로는 꽤 복잡한 문제다. 버튼 하나를 제대로 만들었다는 것은 어떤 의미인가. 색상이 KRDS 토큰을 사용했는가, 크기가 기준 이상인가, 텍스트 레이블이 있는가, 비활성화 상태일 때 스크린 리더가 그 사실을 알 수 있는가, 포커스가 왔을 때 시각적으로 명확히 구분되는가 — 이 모든 조건을 사람이 눈으로 하나하나 들여다보는 일은 수십 개, 수백 개의 버튼이 흩어진 공공 사이트에서는 현실적으로 불가능에 가깝다.

KRDS(Korea Design System)는 공공 웹사이트가 지켜야 할 UI/UX 기준으로, 컴포넌트 범주에서만 **446개의 규칙(CP)**이 정의되어 있다. 버튼·입력창·탭·모달·체크박스·라디오버튼·드롭다운·카드·배지·알림·아코디언·페이지네이션… KRDS가 명시한 거의 모든 UI 부품에 각각의 검증 기준이 붙어 있다. 이것을 사이트의 수십 개 페이지에 걸쳐 전수 검사한다? 사람의 손으로는 거의 불가능하다.

그래서 우리가 실험하는 것이 DOM(Document Object Model)과 ARIA(Accessible Rich Internet Applications) 속성을 읽어 이 446개 규칙을 자동으로 판정하는 방법이다. 이 글은 그 실험의 구체적인 방법과 한계, 그리고 왜 컴포넌트 준수가 단순한 "코드 스타일 문제"가 아니라 디자인 거버넌스의 핵심 문제인지를 이야기한다.

미리 솔직하게 말해두고 싶은 것이 있다. 446개 규칙을 100% 자동으로 완벽하게 판정하는 건 지금도 어렵고, 아마 앞으로도 쉽지 않을 것이다. 이 글은 "ViewCheck가 다 해결했습니다"가 아니라 "우리는 이렇게 접근하고 있고, 이런 점이 아직 어렵다"는 R&D 여정의 한 장면이다.

디자인 시스템 리뷰 중 버튼과 입력창 UI 컴포넌트 카드를 벽보드에 배열하는 한국인 디자이너. — 디자인 시스템 리뷰 세션에서 버튼·입력창 컴포넌트 카드를 벽에 정리하는 디자이너. 컴포넌트 거버넌스는 이렇게 보이는 카드 뒤에 수백 개의 규칙이 숨어 있다.

컴포넌트 준수가 왜 거버넌스 문제인가

컴포넌트 준수(component compliance)를 이야기할 때 가장 먼저 해야 할 것은, 이게 단순히 "버튼 색상을 정해진 것으로 쓰는가"의 문제가 아니라는 점을 명확히 하는 것이다.

디자인 시스템을 도입한 조직이라면 누구나 알다시피, 시스템을 만드는 것과 그것이 실제로 지켜지는 것 사이에는 엄청난 간극이 있다. 이 간극을 "디자인 드리프트(design drift)"라고 부른다. 처음에는 충실히 따르다가, 시간이 지나고 담당자가 바뀌고 외주 개발사가 교체되면서 조금씩 달라지기 시작한다. 버튼의 둥근 정도가 달라지고, 오류 메시지의 색상이 달라지고, 폼 입력창의 높이가 제각각이 되는 것이다.

닐슨 노먼 그룹(Nielsen Norman Group, 이하 NN/g)은 디자인 시스템의 본질을 이렇게 정의한다.

"A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels." (Nielsen Norman Group, "Design Systems 101")

한국어로 풀면, 디자인 시스템은 중복을 줄이고 다양한 페이지·채널에 걸쳐 공통 언어와 시각적 일관성을 만들기 위한 표준의 집합이다. 그런데 NN/g는 같은 리서치에서 이렇게도 말한다. 약속만 있고 집행이 없는 디자인 시스템은 결국 무력해진다고. 누군가 일관성을 깨는 변경에 거부권을 행사할 수 있어야 한다고 말이다 (NN/g, "Your Design System Needs an Enforcer").

이것이 컴포넌트 거버넌스 문제다. 규칙이 있다는 것과, 그 규칙이 사이트 전체에서 실제로 지켜지고 있다는 것을 확인할 수 있다는 것은 완전히 다른 차원의 이야기다. 그리고 공공 웹사이트의 경우 여기에 한 가지 조건이 더 붙는다. 컴포넌트 규칙의 상당 부분이 접근성과 직결된다는 것이다.

버튼에 role="button"이 없으면 스크린 리더 사용자는 그것이 버튼인지 모른다. 비활성화 버튼에 aria-disabled="true"가 없으면 보조기술이 그 상태를 전달하지 못한다. 포커스 스타일이 없으면 키보드로 사이트를 이용하는 사람이 현재 자신이 어디 있는지 알 수 없다. 이런 문제들은 디자인 팀의 미적 선택이 아니라, 시민 누군가의 서비스 이용 가능 여부를 결정하는 요소다.

2024년 웹 접근성 실태조사 결과에 따르면, 국내 웹사이트의 웹 접근성 평균 점수는 66.7점으로 전년 대비 소폭 상승했다(과학기술정보통신부·NIA 한국지능정보사회진흥원, 2024). 100점 만점에 66.7점. 그것도 꾸준히 높아지고 있다는 건 긍정적이지만, 뒤집으면 여전히 상당수 공공 웹사이트가 기준에 못 미치는 컴포넌트를 갖고 있다는 의미다.

이 문제를 자동화로 풀 수 있다면? 그것이 우리가 KRDS CP(컴포넌트) 446개 규칙을 DOM과 ARIA 분석으로 검증하려는 이유다.

KRDS 컴포넌트 규칙(CP)이란 무엇인가 — 446개의 구체적인 의미

먼저 "CP 446개"가 실제로 어떤 내용인지를 이해해야 한다. 숫자만 들으면 막연하게 느껴지지만, 실제로는 아주 구체적인 규칙들의 집합이다.

KRDS 공식 사이트(krds.go.kr)에는 다양한 컴포넌트의 상세 가이드가 공개되어 있다. 버튼 하나를 예로 들면 이런 식이다.

KRDS 버튼 컴포넌트 공식 가이드는 이렇게 명시한다:

"버튼으로 작동하는 모든 요소는 스크린 리더에서 버튼으로 인지될 수 있도록 하며, <button> 대신 불가피하게 다른 태그를 사용해야 하는 경우 role='button'을 사용하여 스크린 리더에서 요소의 역할이 버튼으로 인식될 수 있도록 해야 합니다." (KRDS 공식, 버튼 컴포넌트 가이드)

그리고 포커스 상태에 대해서는:

"모든 버튼은 초점을 받은 상태가 시각적으로 명확하게 구분되어야 합니다. 포커스링의 스타일에 변경이 필요하다면 모든 유형의 버튼에서 포커스링이 가려지지 않고 명확하게 표시되며 인접 배경과 3:1 이상의 명도 대비를 가져야 합니다." (KRDS 공식, 버튼 컴포넌트 가이드)

이것이 CP 규칙의 성격이다. 컴포넌트가 존재하는지, 그 컴포넌트가 시맨틱 HTML로 올바르게 마크업되어 있는지, ARIA 속성이 적절히 붙어 있는지, 상태(비활성, 포커스, 선택됨 등)가 시각적으로 그리고 프로그래밍적으로 구분되는지를 확인한다.

KRDS가 정의하는 주요 컴포넌트 유형을 보면 이 446개의 스케일을 실감할 수 있다. 버튼(단독·그룹·텍스트·아이콘), 입력창(텍스트·숫자·날짜·시간·파일), 라디오 버튼, 체크박스, 토글·스위치, 셀렉트 박스(드롭다운), 탭, 아코디언, 모달(팝업·레이어), 카드, 배지·태그, 알림·토스트, 툴팁, 로딩 인디케이터, 페이지네이션, 네비게이션(GNB·LNB·브레드크럼), 테이블, 공식 배너(Masthead), 프로그레스 바, 슬라이더, 캘린더·데이트피커, 검색창, 목록형·카드형·갤러리형 레이아웃 패턴… 이렇게 나열하면 446개가 이해된다.

각 컴포넌트마다 "존재 여부", "역할(role)", "이름(name)", "상태(state)", "값(value)", "구조", "크기/위치", "상태별 시각 구분"을 확인하는 세부 규칙이 붙는다. WCAG 4.1.2 성공 기준이 요구하는 "모든 UI 컴포넌트는 이름, 역할, 그리고 해당되는 경우 값을 프로그래밍적으로 결정할 수 있어야 한다"는 원칙이 CP 규칙의 상당 부분에 반영되어 있다(W3C WCAG 2.2 기법).

W3C WAI-ARIA Authoring Practices Guide(APG)도 이 부분에서 핵심 역할을 한다. APG는 버튼·입력·탭·모달·아코디언 등 공통 UI 패턴에 대해 ARIA 역할, 상태, 속성, 키보드 상호작용 방식을 구체적으로 명시하고 작동 예시를 제공한다(W3C WAI, ARIA Authoring Practices Guide). KRDS 컴포넌트 가이드의 ARIA 관련 내용은 상당 부분 이 APG와 일치하거나 공공 맥락에 맞게 적용된 형태다.

DOM을 읽어 컴포넌트를 찾는다 — 자동 감지의 원리

그렇다면 ViewCheck는 실제로 어떻게 이 446개 규칙을 자동으로 검증하려 하는가.

출발점은 DOM이다. DOM은 브라우저가 HTML을 파싱해서 메모리 안에 구성하는 트리 구조다. <button>, <input>, <select>, <dialog>, <nav>, <table> 같은 HTML 요소들이 그 안에 있고, 각 요소는 속성(attribute), 스타일, 콘텐츠를 갖는다.

ViewCheck는 Playwright라는 브라우저 자동화 도구를 통해 공공 웹사이트에 실제로 접속하고, 그 페이지의 DOM 전체를 추출한다. 단순히 HTML 소스를 내려받는 것이 아니라 실제 브라우저가 렌더링한 뒤의 DOM을 본다. 이것이 중요한 이유는, 요즘 공공 웹사이트 중 상당수가 자바스크립트로 UI를 동적으로 구성하기 때문이다. 자바스크립트가 실행되기 전의 HTML 소스에는 아무것도 없고, 실제 화면에는 버튼이 가득한 경우도 있다. 그 "실제 화면의 버튼"을 잡으려면 렌더링 이후의 DOM을 봐야 한다.

DOM에서 추출하는 것들은 대략 이런 것들이다.

컴포넌트 존재 여부 감지:

모든 <button> 요소, role="button"을 가진 요소
모든 <input> 요소(type별: text, number, date, checkbox, radio, file 등)
<select> 요소, 커스텀 드롭다운으로 구현된 <div role="listbox"> 등
<dialog>, role="dialog" 요소(모달)
<nav>, role="navigation" 요소
<table>, role="table" 요소
탭 패턴: role="tablist", role="tab", role="tabpanel"
아코디언: aria-expanded 속성을 가진 <button> + 연결된 콘텐츠 영역

ARIA 속성 검증:

aria-label, aria-labelledby, aria-describedby — 접근 가능한 이름/설명 연결
aria-hidden, aria-expanded, aria-selected, aria-checked, aria-disabled — 상태 표현
role 속성 — 시맨틱 의미 부여
aria-live, aria-atomic — 동적 콘텐츠 변경 알림

시각적 속성:

computed style로 색상 대비 계산
포커스 스타일(:focus CSS의 존재와 outline 값)
터치 타겟 크기(width × height의 계산값)

이 데이터를 바탕으로, 각 CP 규칙의 checkFunction이 통과 / 미통과 / 해당없음 중 하나를 판정한다. 예를 들어 "CP-001: 버튼에 접근 가능한 이름이 있어야 한다" 규칙이라면, DOM에서 발견된 모든 버튼 요소를 순회하며 innerText, aria-label, aria-labelledby, title 중 하나라도 비어있지 않은 값이 있으면 통과, 전부 없으면 미통과, 페이지에 버튼 자체가 없으면 해당없음으로 판정한다.

컴포넌트 라이브러리 격자 화면에 손을 올린 채 트랙패드를 사용하는 디자이너의 클로즈업. — 컴포넌트 라이브러리 화면을 들여다보는 디자이너의 손. 자동 감지는 이 화면 뒤의 DOM 구조를 읽는 것에서 시작된다.

이 방식의 강점은 속도와 일관성이다. 사람이 한 페이지씩 들여다보는 것과 달리, 코드로 DOM을 분석하면 수십 개 페이지를 수 초 안에 처리할 수 있다. 그리고 "버튼에 aria-label이 있어야 한다"는 규칙은 사람마다 해석이 달라지지 않는다. 있거나 없거나다. 이런 명확한 규칙은 자동화가 사람보다 훨씬 더 일관되고 빠르다.

다만 한계도 분명하다. 이 한계에 대한 이야기는 뒤에서 따로 다루겠다.

446개 규칙을 카테고리별로 들여다보기

CP 446개를 막연하게 "컴포넌트 규칙"이라고 부르는 것보다, 실제로 어떤 종류의 검증이 이루어지는지를 범주별로 살펴보면 더 실감이 난다.

1. 역할(Role) 검증

가장 기본적인 것은 컴포넌트가 자신이 무엇인지를 보조기술에 올바르게 전달하고 있는가다.

시맨틱 HTML을 사용하면 이건 자동으로 해결된다. <button>은 브라우저가 자동으로 role=button을 부여한다. 하지만 공공 웹사이트에는 <div>나 <span>으로 만든 커스텀 버튼이 여전히 많다. 클릭 이벤트가 달려 있고 시각적으로 버튼처럼 생겼지만, 스크린 리더 사용자에게는 그냥 텍스트 덩어리다. role="button"을 명시적으로 붙이지 않으면, 시각 장애인은 그 버튼이 버튼인지 알 수 없다.

ViewCheck의 CP 규칙 중 역할 검증은 이렇게 작동한다.

<button>, <a href>, <input type="submit"> → 네이티브 역할 보유 → 별도 role 없어도 통과
<div>, <span> + 클릭 이벤트가 감지되는 경우 → role 속성 검사 → 없으면 미통과
<nav>, <main>, <header>, <footer> → 랜드마크 역할 검증

W3C WAI의 ARIA Authoring Practices Guide는 이 원칙을 이렇게 설명한다. "버튼 역할은 사용자 입력이 활성화될 때 응답을 트리거하는 상호작용 가능한 요소를 식별한다. 버튼 클릭과 Enter 키 누름은 모두 활성화를 트리거해야 한다"(W3C WAI, APG Patterns - Button). 즉 역할뿐만 아니라 키보드 상호작용도 규칙의 일부다.

2. 이름(Name) 검증

컴포넌트에 접근 가능한 이름이 있는지는 CP 규칙에서 빠지지 않는 검증 항목이다. WCAG 4.1.2 성공 기준 "이름, 역할, 값"의 핵심이기도 하다.

접근 가능한 이름은 보조기술이 "이 요소가 무엇인지"를 사용자에게 전달하는 텍스트다. 버튼에 텍스트 레이블이 있으면 그게 이름이다. 아이콘만 있는 버튼이라면 aria-label로 이름을 제공해야 한다. 이미지 버튼이라면 alt 텍스트가 그 역할을 한다.

흔한 문제는 아이콘만 있는 버튼이다. 공공 웹사이트의 헤더에는 검색 버튼, 메뉴 닫기 버튼, SNS 공유 버튼처럼 텍스트 없이 아이콘으로만 구성된 버튼이 많다. 시각적으로는 직관적일 수 있지만, 스크린 리더 사용자에게 이 버튼은 이름이 없는 버튼이다. "버튼"이라고 읽히거나, 최악의 경우 아무것도 읽히지 않는다.

ViewCheck는 DOM에서 발견된 모든 버튼 유형의 요소에 대해 accessible name 계산 알고리즘을 적용한다. aria-labelledby → aria-label → title → innerText → alt 순서로 이름을 찾고, 아무것도 없으면 미통과로 판정한다.

3. 상태(State) 검증

컴포넌트는 상태를 갖는다. 버튼은 활성/비활성, 체크박스는 체크됨/미체크됨, 드롭다운은 열림/닫힘, 탭은 선택됨/미선택, 아코디언은 펼쳐짐/접힘이다. 이 상태가 시각적으로만 구분되고 프로그래밍적으로는 표현되지 않으면, 보조기술 사용자는 상태를 알 수 없다.

aria-expanded, aria-selected, aria-checked, aria-disabled 같은 속성들이 바로 이 상태를 표현하는 수단이다. KRDS 버튼 가이드가 명시하듯, 비활성화 상태일 때는 시각적 처리뿐 아니라 aria-disabled="true" 또는 disabled 속성으로 프로그래밍적 상태도 함께 표현해야 한다.

ViewCheck CP 규칙의 상태 검증은 이렇게 작동한다.

체크박스: <input type="checkbox">의 checked 속성 또는 aria-checked 상태 검증
아코디언: <button aria-expanded="..."> 여부 확인
탭: role="tab"을 가진 요소에 aria-selected 상태 검증
모달: <dialog> 또는 role="dialog" 요소에 aria-modal, aria-labelledby 검증

4. 구조(Structure) 검증

컴포넌트는 혼자 존재하지 않고 다른 요소들과 관계 속에서 의미를 갖는다. 폼 입력창은 레이블과 연결되어야 하고, 오류 메시지는 입력창과 연결되어야 하며, 그룹화된 라디오 버튼은 <fieldset>과 <legend>로 묶여야 한다.

이런 관계가 제대로 코딩되지 않으면 스크린 리더 사용자는 "이 입력창에 무엇을 입력해야 하는지"를 알 수 없다. 입력창에 텍스트 레이블이 시각적으로 바로 옆에 있더라도, <label for="...">로 연결되지 않으면 프로그래밍적 관계는 없는 셈이다.

ViewCheck는 다음과 같은 구조 검증을 수행한다.

모든 <input>, <select>, <textarea>에 대해 <label for> 연결 또는 aria-labelledby/aria-label 존재 확인
그룹화 검증: <fieldset> + <legend> 조합
오류 메시지 연결: aria-describedby로 오류 메시지가 입력창에 연결되어 있는지
탭 구조: role="tablist" 내에 role="tab" 존재, aria-controls로 tabpanel 연결

5. 크기와 위치 검증

컴포넌트의 물리적 크기도 규칙의 대상이다. KRDS와 WCAG는 터치 타겟의 최소 크기를 요구한다. 손가락으로 탭할 수 있을 만큼 충분히 커야 하고, 인접 요소와 너무 가까이 붙어 있으면 실수 터치가 발생한다.

ViewCheck는 Playwright를 통해 요소의 getBoundingClientRect()를 계산하여 실제 렌더링된 크기를 확인한다. 화면 밀도(DPR)를 고려해 물리적 픽셀 크기를 환산하고, KRDS와 WCAG 2.5.8 기준(최소 24×24 CSS 픽셀, 권장 44×44 CSS 픽셀)과 비교한다.

증적으로 보는 실제 컴포넌트 분석 결과

ViewCheck LLM 분석 컴포넌트 탭의 실제 화면 캡처. KRDS CP 규칙 446개의 통과·미통과·해당없음 판정 결과가 컴포넌트 유형별로 분류되어 표시됨. — ViewCheck LLM 분석의 컴포넌트(CP) 분석 결과 화면. KRDS CP 446개 규칙의 판정 결과가 컴포넌트 유형별로 정리되어, 어떤 컴포넌트가 어떤 규칙에서 미통과되었는지 확인할 수 있다. — 실제 분석 화면

실제 ViewCheck 분석 화면을 보면, 컴포넌트 탭에는 CP 446개 규칙의 판정 결과가 집계되어 나온다. 이를 통해 어떤 컴포넌트 유형에서 얼마나 많은 미통과가 발생하는지, 특정 ARIA 속성이 어느 페이지에서 누락되어 있는지를 한눈에 파악할 수 있다.

우리가 여러 공공 사이트를 분석하면서 자주 발견한 패턴 몇 가지를 공유한다.

패턴 1: 아이콘 버튼의 접근 가능한 이름 누락 검색 버튼, SNS 공유 버튼, 메뉴 닫기 버튼처럼 텍스트 없이 아이콘만 쓰는 버튼에 aria-label이 없는 경우가 많다. 이건 시각적으로는 아무 문제 없어 보이지만, 스크린 리더 사용자에게는 이름 없는 버튼이다.

패턴 2: 폼 입력창과 레이블의 비연결 <label>이 시각적으로는 입력창 바로 옆에 있지만, for 속성으로 연결되지 않은 경우. 또는 플레이스홀더 텍스트만 있고 레이블이 아예 없는 경우. 플레이스홀더는 입력하면 사라지기 때문에 사용자가 무엇을 입력했는지 기억하기 어렵고, 기본적으로 접근 가능한 이름으로 인정되지 않는다.

패턴 3: 커스텀 컴포넌트의 ARIA 부재 외주 개발로 만들어진 커스텀 드롭다운이나 모달, 탭 등에서 ARIA 속성이 완전히 빠진 경우. 자체 디자인 시스템의 컴포넌트를 쓰지 않고 직접 구현한 경우 이런 문제가 특히 많다.

패턴 4: 상태 변화의 ARIA 미반영 아코디언이 열리고 닫힐 때 시각적으로는 변화가 있지만 aria-expanded 속성이 업데이트되지 않는 경우. 자바스크립트로 클래스를 토글해서 CSS로 표시/숨김을 처리하면서 ARIA 상태를 빠뜨리는 것이 원인인 경우가 많다.

패턴 5: 포커스 관리 부재 모달이 열릴 때 포커스가 모달 내부로 이동하지 않거나, 모달이 닫힐 때 포커스가 원래 위치로 돌아오지 않는 경우. 마우스 사용자에게는 큰 문제가 아니지만, 키보드 사용자는 모달이 닫힌 뒤 어디에 있는지 알 수 없게 된다.

이런 패턴들을 자동으로 감지하고 "어느 페이지의 몇 번째 버튼에서 이 문제가 발생한다"고 구체적으로 짚어주는 것이 CP 규칙 자동화의 핵심 가치다.

디자인 거버넌스와 자동화 — 해외 디자인 시스템은 어떻게 하고 있나

컴포넌트 준수를 자동으로 측정하려는 시도는 ViewCheck만의 아이디어가 아니다. 잘 만든 해외 정부 디자인 시스템들이 어떻게 접근하고 있는지를 살펴보면, 이 문제가 얼마나 보편적이고 중요한지를 알 수 있다.

GOV.UK Design System과 자동화된 접근성 검증

영국의 GOV.UK Design System은 이 분야에서 선구적인 사례로 자주 인용된다. GDS(Government Digital Service)가 운영하는 이 시스템은 컴포넌트 레벨에서 접근성 검증을 어떻게 내장하고 있는지를 잘 보여준다.

2024년 GOV.UK Design System 블로그에는 이런 내용이 있다:

"Get to WCAG 2.2 faster with the GOV.UK Design System." 2024년 10월부터 영국 정부 공공 섹터 웹사이트의 새로운 최소 접근성 기준은 WCAG 2.2 AA이며, GOV.UK Design System은 수천 개의 정부 서비스가 이 새로운 요건을 충족하도록 2024년에 업데이트되었다. (UK Government Accessibility blog, 2024)

GOV.UK Design System의 접근성 페이지는 이렇게 말한다:

"Using GOV.UK Design System in a service does not immediately make that service accessible. You'll still need to carry out additional research, design, development and testing work." (GOV.UK Design System, Accessibility)

즉, 디자인 시스템을 쓴다는 것이 자동으로 접근성을 보장하지 않는다는 것이다. 시스템의 컴포넌트 자체는 접근성을 갖추고 있지만, 그것을 어떻게 조합하고 사용하느냐에 따라 접근성이 무너질 수 있다. 컴포넌트의 "올바른 사용"을 확인하는 것이 거버넌스의 핵심이다.

USWDS의 컴포넌트 접근성 검증 접근

미국의 USWDS(U.S. Web Design System)는 2025년 3월에 USWDS 3.11.0의 44개 컴포넌트에 대한 접근성 적합성 보고서를 발표했다(USWDS, Accessibility Conformance Report, 2025). WCAG 2.1 AA를 최소 기준으로, 가능한 한 많은 WCAG 2.2 기준까지 달성하려 노력한다고 밝히고 있다.

중요한 점은 USWDS가 단순히 컴포넌트를 만들어 배포하는 데서 그치지 않고, 각 컴포넌트별 접근성 테스트 방법을 함께 제공한다는 것이다. USWDS 공식 사이트에는 각 컴포넌트의 접근성 테스트 페이지가 별도로 존재하며, 자동화 테스트와 수동 테스트를 병행할 것을 권고한다:

"Building with accessible USWDS components does not guarantee an accessible service, and you need to keep testing to stay accessible." (USWDS, Accessibility)

이 권고는 컴포넌트 자체의 접근성과, 그 컴포넌트가 실제 사이트에서 올바르게 사용되는지는 다른 문제임을 명확히 한다.

디자인 시스템 거버넌스의 글로벌 트렌드

NN/g의 "Your Design System Needs an Enforcer" 아티클이 지적하듯, 디자인 시스템이 실제로 작동하려면 준수를 강제할 수 있는 메커니즘이 필요하다. 2024년 디자인 시스템 거버넌스 관련 연구에서 나온 데이터 몇 가지를 보면:

Knapsack의 2024년 리포트에 따르면 최근 2년 내에 출시된 디자인 시스템의 41%가 더 이상 활발하게 유지·보수되지 않는다. 거버넌스 부재가 주요 원인이다. (Knapsack, 2024)
100명 이상 규모의 기업에서 디자인 시스템을 도입한 경우, 디자인·개발 비용 46% 절감, 출시 속도 22% 향상이 보고된다. (Enterprise Design Systems, Softkraft 리포트)
자동화된 컴포넌트 준수 검사를 도입한 팀은 설계 리뷰에 소요되는 시간을 최대 60% 줄인다고 보고된다. (Miro, Design System Governance Research)

이런 데이터들이 가리키는 방향은 분명하다. 컴포넌트 준수는 한 번 만들고 끝나는 것이 아니라 지속적으로 측정하고 관리해야 하는 것이며, 그 측정을 자동화할 수 있다면 거버넌스 비용을 크게 낮출 수 있다는 것이다.

공공 웹에서 컴포넌트 준수가 왜 더 중요한가

민간 서비스와 공공 서비스를 비교하면, 공공 웹에서 컴포넌트 준수가 더 중요한 이유가 몇 가지 있다.

첫 번째: 사용자 다양성 공공 서비스의 사용자는 민간 서비스보다 훨씬 더 다양하다. 젊은 사람부터 고령자까지, 마우스 사용자부터 키보드 사용자·스크린 리더 사용자까지, 모바일부터 데스크톱까지 모든 환경에서 동등하게 이용할 수 있어야 한다. 특정 사용자 그룹에 맞춰 최적화하는 것이 아니라 모든 사람에게 동등한 접근을 보장해야 하기 때문에, 컴포넌트의 ARIA 속성과 키보드 접근성이 특히 중요하다.

두 번째: 법적 의무 「장애인차별금지 및 권리구제 등에 관한 법률」(장차법)과 「한국형 웹 콘텐츠 접근성 지침(KWCAG 2.2)」은 공공 웹사이트의 접근성 준수를 의무화하고 있다. KRDS 컴포넌트 규칙의 상당 부분은 이 법적 기준과 직결된다. 컴포넌트를 잘못 만들면 법 위반이 될 수 있다는 것이다.

세 번째: 외주 개발의 분산성 공공 웹사이트는 대개 외주 개발로 만들어지고, 개발사가 교체되고, 유지보수도 다양한 업체가 맡는다. 이 과정에서 KRDS 컴포넌트 가이드가 얼마나 충실히 지켜지는지를 담당자가 일일이 확인하기 어렵다. 자동화된 검증이 없으면 드리프트는 시간이 지날수록 누적된다.

네 번째: 일관성의 가치 공공 서비스의 사용자는 다양한 부처·기관의 사이트를 오간다. 중앙행정기관의 사이트, 지자체의 사이트, 공공기관의 사이트가 모두 KRDS 컴포넌트를 올바르게 사용한다면, 사용자는 "이건 정부 사이트구나"라는 일관된 경험을 갖는다. 버튼은 이렇게 생겼고, 모달은 이렇게 닫히고, 폼은 이렇게 작동한다는 것을 한 사이트에서 배우면 다른 사이트에서도 그 경험이 전이된다. 이것이 범정부 디자인 시스템이 추구하는 핵심 가치다.

WebAIM 연구가 가르쳐주는 것 — ARIA가 오히려 문제를 만드는 경우

ARIA가 접근성을 위한 도구라는 것은 맞지만, ARIA를 잘못 사용하면 오히려 접근성을 더 나쁘게 만들 수 있다. 이 역설적인 사실이 CP 규칙 검증에서 중요한 이유가 있다.

WebAIM의 2024년 접근성 연구 데이터는 이 점을 직접적으로 드러낸다:

"Pages that use ARIA (excluding landmarks) show 34% more errors compared to pages without ARIA attributes." (WebAIM, 2024 Web Accessibility Research)

랜드마크를 제외한 ARIA 속성을 사용하는 페이지가 ARIA를 전혀 사용하지 않는 페이지보다 접근성 오류가 34% 더 많다는 것이다. 이것은 ARIA 자체의 문제가 아니라, ARIA를 잘못 사용하는 개발자가 많다는 뜻이다.

흔한 실수들을 보면:

시맨틱 HTML 요소를 써도 되는데 불필요하게 ARIA를 추가해서 충돌 발생
role="presentation" 또는 aria-hidden="true"를 잘못 적용해서 중요한 콘텐츠를 보조기술에서 숨김
aria-label과 화면에 보이는 텍스트가 달라서 WCAG 2.5.3(Label in Name) 위반
aria-expanded를 설정했지만 연결된 콘텐츠 영역이 실제로 표시/숨김 처리되지 않음

이 때문에 ViewCheck의 CP 규칙 검증은 단순히 "ARIA가 있는가"를 확인하는 것을 넘어, "ARIA가 올바르게 사용되고 있는가"까지 확인하려 한다. 예를 들어 aria-label이 있지만 화면에 보이는 텍스트와 완전히 다른 경우, aria-expanded="true"가 있지만 연결된 aria-controls가 없는 경우 등을 미통과로 판정한다.

물론 이 모든 경우를 100% 자동으로 잡아내는 건 어렵다. 특히 aria-label의 내용이 의미론적으로 적절한지는 자동화로 판정하기 어렵다. 이것이 자동화의 한계이자 우리가 계속 연구하는 영역이다.

큰 디스플레이 앞에서 컴포넌트 준수 내용을 토론하는 두 명의 한국인 디자이너. — 컴포넌트 준수 결과를 놓고 논의하는 두 디자이너. 자동화가 잡아준 문제 목록을 바탕으로 실제 개선을 이끄는 것은 사람의 몫이다.

자동화의 한계 — N/A와 시각적 판단의 벽

솔직하게 말하자. DOM과 ARIA 분석으로 CP 446개 규칙을 자동 판정한다는 것은 가능하지만, 그 판정의 완성도는 규칙마다 크게 다르다.

N/A(해당없음) 문제

CP 규칙의 특성상 "해당없음" 판정이 많다. 예를 들어 모달 관련 규칙(CP-xxx: 모달에 aria-labelledby가 있어야 한다)은 해당 페이지에 모달이 없으면 해당없음이다. 공공 웹사이트는 페이지마다 사용하는 컴포넌트 유형이 다르기 때문에, 한 페이지에서 "해당없음"인 규칙이 다른 페이지에서는 핵심 검증 대상이 된다. 그래서 ViewCheck는 여러 페이지를 분석하고 결과를 집계한다. 메인 페이지에서 모달이 없어서 N/A였던 규칙이, 로그인 페이지 분석에서는 실제 판정 대상이 될 수 있기 때문이다.

동적 컴포넌트의 한계

자바스크립트로 동적으로 생성되는 컴포넌트는 초기 DOM 분석으로는 잡히지 않는 경우가 있다. 사용자가 버튼을 클릭해야만 나타나는 모달, 스크롤 이후에야 로드되는 카드 등은 정적 DOM 스냅샷에서 존재 자체가 안 보인다. Playwright는 실제 브라우저를 띄우기 때문에 자바스크립트 실행 후의 DOM은 잡을 수 있지만, 사용자 인터랙션 이후에야 나타나는 요소까지는 제한이 있다.

시각적 판단이 필요한 규칙

"포커스 스타일이 시각적으로 명확한가"는 CSS의 outline 값을 확인하는 것으로 어느 정도 판정할 수 있지만, 완전하지 않다. CSS 트릭으로 outline: none을 설정하면서 다른 방법으로 포커스를 표시하는 경우(예: box-shadow), 코드 분석만으로는 포커스가 시각적으로 충분히 표시되는지를 확신하기 어렵다. 실제 화면을 눈으로 확인하거나, 스크린샷을 Vision AI로 분석하는 방법이 필요하다.

의미론적 적절성 판단

aria-label="닫기"와 aria-label="모달 창 닫기 버튼" 중 어느 것이 더 좋은가? 이것은 자동화로 판정하기 어렵다. 있기만 하면 통과로 처리하면 불성실한 구현을 놓칠 수 있고, 내용의 질까지 평가하려면 LLM의 도움이 필요하다. 우리는 현재 일부 이런 규칙에서 LLM을 보조 판정자로 활용하는 실험을 하고 있지만, 이 방법의 신뢰도를 어떻게 높일 것인지는 여전히 연구 중이다.

이런 한계들 때문에 ViewCheck의 CP 규칙 판정은 "이 사이트에 컴포넌트 접근성 문제가 있는가 없는가"를 확실하게 판별하는 것보다는, "이 부분을 사람이 확인해봐야 한다"는 신호를 최대한 많이, 정확하게 포착하는 것을 목표로 한다. 자동화는 사람의 검토 범위를 좁혀주는 도구지, 검토 자체를 대체하는 도구가 아니라는 것이 우리의 기본 입장이다.

KRDS HTML Kit과 컴포넌트 준수의 기준선

CP 규칙 검증에서 중요한 참조 자료 중 하나가 KRDS HTML Kit이다. KRDS는 공식 UI 구현체로 HTML/CSS/JavaScript로 된 컴포넌트 키트를 배포하고 있다(KRDS-uiux GitHub). 이 키트의 각 컴포넌트 HTML 구조가 CP 규칙이 기대하는 "올바른 마크업"의 기준선이 된다.

예를 들어 KRDS HTML Kit의 버튼 컴포넌트는 이런 식으로 구현되어 있다.

<!-- 기본 버튼 -->
<button type="button" class="btn btn-primary">
  확인
</button>

<!-- 아이콘만 있는 버튼 -->
<button type="button" class="btn btn-icon" aria-label="검색">
  <svg aria-hidden="true">...</svg>
</button>

<!-- 비활성화 버튼 -->
<button type="button" class="btn btn-primary" disabled aria-disabled="true">
  확인 불가
</button>

이 패턴을 보면 몇 가지 원칙이 보인다. 텍스트가 있으면 텍스트가 이름이 된다. 아이콘만 있으면 aria-label로 이름을 제공하고, 아이콘 이미지 자체는 aria-hidden="true"로 보조기술에서 숨긴다. 비활성화 상태는 disabled 속성과 aria-disabled="true" 둘 다 사용한다.

ViewCheck의 CP checkFunction들은 이 기준선을 참조해 실제 사이트의 마크업이 얼마나 일치하는지를 검증한다. 완벽한 키트 코드를 그대로 복사·붙여넣기 했다면 대부분 통과지만, 커스텀 구현이 들어갈수록 벗어나는 부분이 생긴다.

KRDS HTML Kit 자체를 ViewCheck의 KRDScan 엔진이 RAG(검색 증강 생성) 지식베이스로 인제스트해서, 판정의 근거로 활용하기도 한다. "이 규칙이 왜 미통과인가"를 물었을 때 "KRDS HTML Kit의 버튼 컴포넌트는 아이콘만 있는 버튼에 aria-label을 요구합니다. 현재 구현에는 aria-label이 없습니다"와 같이 공식 구현체를 근거로 답할 수 있는 것이다.

책상 위에 버튼과 입력창 카드로 구성된 물리적 UI 키트가 펼쳐져 있는 클로즈업 사진. — 책상 위에 펼쳐진 버튼과 입력창 카드로 구성된 실물 UI 키트. 디지털 컴포넌트 키트의 각 항목이 CP 규칙의 기준선이 된다.

컴포넌트 유형별 자동 감지의 난이도 차이

모든 컴포넌트가 똑같이 쉽게 자동 감지되는 건 아니다. 컴포넌트 유형에 따라 자동화의 난이도가 크게 달라지는데, 이것을 솔직하게 정리해 보면 다음과 같다.

감지가 상대적으로 쉬운 컴포넌트

버튼, 링크, 입력창, 체크박스, 라디오버튼: 이들은 시맨틱 HTML 요소로 직접 대응되는 경우가 많다. <button>, <a>, <input>, <select> 같은 요소는 DOM에서 쉽게 식별되고, ARIA 속성 존재 여부도 직접 확인할 수 있다.

레이블 연결: <label for=""> 속성과 <input id=""> 속성의 일치 여부는 단순 문자열 비교로 확인된다.

랜드마크: <header>, <nav>, <main>, <footer>, <aside> 같은 HTML5 랜드마크 요소의 존재 여부는 DOM 쿼리로 쉽게 파악된다.

감지 난이도가 중간인 컴포넌트

탭, 아코디언: role="tablist", role="tab", role="tabpanel" 패턴을 찾아야 하는데, 커스텀 구현이 많아서 다양한 마크업 패턴을 알아야 한다. aria-controls로 연결 관계를 확인하는 것도 필요하다.

드롭다운(셀렉트): 네이티브 <select>는 쉽지만, 커스텀 드롭다운(combobox 패턴)은 role="combobox", role="listbox", role="option" 조합을 찾아야 한다.

모달: <dialog> 요소는 쉽지만, 클래스 토글로 구현된 커스텀 모달은 role="dialog" 또는 aria-modal="true"를 찾아야 하고, 없으면 DOM 구조 패턴으로 추정해야 한다.

감지가 어려운 컴포넌트

슬라이더, 캐러셀: 구현 방식이 매우 다양하고, ARIA 패턴 적용이 복잡하다.

데이트피커: JavaScript로 렌더링되는 달력 UI는 정적 DOM에서 잡기 어렵고, 키보드 상호작용 검증은 자동화가 더욱 어렵다.

알림(Toast/Alert): 동적으로 생성되었다가 사라지는 컴포넌트는 DOM 스냅샷 시점에 따라 존재하지 않을 수 있다.

비표준 구현 컴포넌트: KRDS HTML Kit을 전혀 사용하지 않고 완전히 자체 제작한 UI 라이브러리로 구현된 경우, DOM 구조만으로는 컴포넌트 유형 자체를 식별하기 어려울 수 있다.

이런 어려운 컴포넌트들을 잡기 위해 KRDScan 엔진(Vision AI)과의 협업이 필요하다. DOM 분석으로 파악하지 못한 컴포넌트를 스크린샷 기반 시각 감지로 보완하는 것이다. 예를 들어 DOM에는 <div class="custom-date-picker"> 같은 정보밖에 없지만, 스크린샷에서는 캘린더 UI가 명확히 보인다. Vision AI가 그 스크린샷에서 "이것은 날짜 선택 컴포넌트"라고 감지하면, 해당 CP 규칙들을 적용할 대상이 있다는 것을 알 수 있게 된다.

CP 규칙과 다중 페이지 분석 — 한 페이지로는 부족한 이유

CP 446개 규칙의 핵심적인 특성 중 하나는, 페이지 유형에 따라 어떤 컴포넌트가 있는지가 완전히 달라진다는 것이다.

메인 페이지에는 보통 네비게이션, 배너, 카드 목록, 검색창, 버튼들이 있다. 하지만 모달, 아코디언, 탭, 폼 입력창, 체크박스, 라디오버튼 같은 컴포넌트는 메인 페이지에 없거나 드물다. 이것들은 검색 결과 페이지, 신청 페이지, 마이페이지, 게시판 상세 페이지 등에 등장한다.

메인 페이지만 분석한다면 모달 관련 CP 규칙, 폼 관련 CP 규칙, 탭 관련 CP 규칙 등 수백 개가 N/A로 처리된다. 그 N/A가 "정당한 N/A"(해당 페이지에 그 컴포넌트가 없음)인지, "발견 못 한 N/A"(다른 페이지에는 있는데 메인만 봐서)인지 구분이 안 된다.

ViewCheck가 다중 페이지 분석을 기본값으로 설계한 이유 중 하나가 여기에 있다. 여러 페이지 유형(메인, 검색, 목록, 상세, 신청, 로그인, 정책 안내 등)을 골고루 분석하면:

페이지별로 어떤 컴포넌트가 어떤 상태인지 파악 가능
"메인에서는 통과지만 신청 페이지에서 같은 규칙이 미통과" 같은 불일관성 감지
사이트 전체에 걸쳐 어떤 컴포넌트 유형이 체계적으로 문제가 있는지 파악

예를 들어 버튼의 aria-label 문제가 특정 페이지에만 있는지, 아니면 사이트 전체에 걸쳐 나타나는 패턴인지를 알 수 있다. 전자라면 담당 페이지 개발자의 개별 수정이 필요하고, 후자라면 공통 UI 라이브러리나 개발 가이드라인 자체를 수정해야 한다는 신호다. 이런 인사이트는 다중 페이지 데이터 없이는 도출할 수 없다.

컴포넌트 준수 측정의 현실적 활용 — 담당자 입장에서

CP 446개 규칙 자동 검증이 공공 웹 담당자에게 실제로 어떤 가치를 줄 수 있는지를 생각해 보자.

외주 개발 품질 확인

새로운 기능을 외주로 개발받았을 때, 납품 전에 "이 구현이 KRDS 컴포넌트 기준에 맞는가"를 자동으로 확인할 수 있다. "버튼에 ARIA 속성이 다 들어가 있나요?"라고 개발사에 구두로 물어보는 것과, 분석 결과를 공유하며 "이 5개 컴포넌트에서 이런 속성이 누락되었습니다"라고 구체적으로 요청하는 것은 결과의 질이 다르다.

정기 준수 모니터링

사이트를 처음 만들 때는 컴포넌트를 올바르게 구현했더라도, 업데이트나 콘텐츠 추가 과정에서 무너지는 경우가 있다. 정기적으로(예: 분기별) 동일한 사이트를 분석하여 새로 생긴 컴포넌트 문제를 조기에 발견할 수 있다.

접근성 감사 준비

웹 접근성 품질마크 인증이나 법적 접근성 요건 점검 전에, 어떤 컴포넌트에서 어떤 문제가 있는지를 미리 파악하여 수정할 수 있다. "이 부분을 수동으로 더 꼼꼼히 확인하자"는 우선순위를 설정하는 데 자동화 결과가 도움을 준다.

개발사 간 비교

같은 사이트를 다른 외주 개발사가 제작한 섹션들이 혼재할 때, 어느 업체 작업물에서 컴포넌트 문제가 더 많은지를 데이터로 확인할 수 있다. 이것이 계약 검토나 개발사 선정 기준에도 활용될 수 있다.

물론 이런 활용의 전제는 자동화 판정 결과를 이해하고 해석할 수 있는 역량이다. "CP-123 미통과: aria-expanded 없음"이라는 결과를 받았을 때, 이게 어떤 문제인지, 어떻게 고쳐야 하는지를 담당자가 이해하지 못하면 결과는 쓸모없다. 그래서 ViewCheck는 각 판정 결과에 "왜 미통과인가"와 "어떻게 고치면 되는가"를 함께 제시하려 한다. 기술 전문가가 아닌 담당자도 결과를 읽고 개발사에 구체적인 수정 요청을 할 수 있도록.

큰 터치스크린에서 컴포넌트를 드래그하는 한국인 디자이너의 모습. — 대형 터치스크린에서 컴포넌트를 드래그하는 디자이너. 컴포넌트 거버넌스는 만들고 끝이 아니라, 배치하고 사용하고 검증하는 지속적인 순환이다.

현재 우리가 실험 중인 것들

CP 규칙 자동 검증과 관련해 우리가 지금 실험하고 있거나 연구하고 있는 것들을 솔직하게 공유한다. "완성됐다"고 말하기보다, "지금 이런 것들을 풀고 있다"는 쪽이 더 정확하기 때문이다.

실험 1: 커스텀 컴포넌트 패턴 분류 고도화

DOM에서 컴포넌트를 감지할 때, 시맨틱 HTML로 만든 컴포넌트는 비교적 쉽다. 하지만 클래스 명이나 ID 패턴, 속성 구조를 통해 "이건 아마 커스텀 탭 컴포넌트"를 추론해야 하는 경우가 있다. 더 다양한 공공 사이트 DOM 데이터를 분석하여 이런 패턴들의 사전을 넓히는 작업을 하고 있다.

실험 2: Vision AI와의 상호보완

DOM으로 잡지 못한 컴포넌트를 KRDScan Vision AI(현재 YOLOv8 기반 컴포넌트 감지 모델 + VLM 평가)로 보완하는 파이프라인을 구축하고 있다. DOM이 "여기 버튼 같은 게 있는 것 같다"고 알려주고, Vision AI가 "맞다, 이건 버튼이다"를 확인해 주거나, DOM이 놓친 컴포넌트를 스크린샷에서 찾아내는 식이다.

실험 3: 상태 변화 동적 검증

Playwright를 통해 실제로 컴포넌트를 클릭하거나 포커스를 이동시켜, 상태 변화에 따른 ARIA 업데이트를 확인하는 동적 검증이다. 아코디언을 클릭하면 aria-expanded가 바뀌는지, 모달을 열면 포커스가 이동하는지 같은 것들이다. 이는 정적 DOM 분석보다 훨씬 더 많은 시간이 걸리지만, 잡을 수 있는 문제의 종류가 크게 늘어난다.

실험 4: LLM을 보조 판정자로 활용

"aria-label의 내용이 화면에 보이는 텍스트와 충분히 일치하는가" 같은 의미론적 판단이 필요한 규칙에서, LLM을 보조 판정자로 호출하는 실험이다. 자동화 판정(DOM 규칙)이 먼저 1차 판정을 하고, 모호한 케이스에서만 LLM이 추가 판정을 내리는 방식이다. 다만 LLM 판정의 신뢰도와 환각 억제 방법에 대해서는 아직 연구 중이다.

실험 5: 컴포넌트 준수율 트렌드 추적

같은 사이트를 다른 시점에 여러 번 분석하여, "이 사이트의 컴포넌트 준수율이 시간이 지남에 따라 어떻게 변했나"를 추적하는 기능이다. 업데이트 후에 새로운 문제가 생겼는지, 지난번 분석에서 지적한 문제가 수정되었는지를 확인할 수 있다.

이 다섯 가지 실험 모두 아직 완성 단계가 아니다. 각각 나름의 어려움이 있고, 어떤 것은 접근 방식 자체를 바꿔야 할 수도 있다. 하지만 방향은 분명하다 — DOM 기반의 정확하고 빠른 1차 판정 + Vision AI의 시각적 보완 + LLM의 의미론적 보조. 이 세 층위가 잘 맞물려야 CP 446개 규칙 검증이 실제로 유용한 수준에 도달할 수 있다.

디자인 드리프트를 막는 자동화 — 거버넌스의 미래

디자인 거버넌스라는 주제를 조금 더 큰 그림으로 바라보며 마무리 이야기를 해보자.

KRDS를 포함한 모든 디자인 시스템이 직면하는 가장 현실적인 문제는 "드리프트"다. 처음에는 가이드라인을 충실히 따르지만, 시간이 지나면서 조금씩 벗어나기 시작한다. 이것은 나쁜 의도가 아니라, 자연스럽게 발생하는 현상이다. 다른 업무가 바쁘고, 작은 수정이 누적되고, 담당자가 바뀌고, 급하게 납품해야 하는 상황에서 가이드라인의 세세한 부분이 지켜지지 않는다.

이 드리프트를 막는 전통적인 방법은 사람 기반의 리뷰다. 개발자가 PR(Pull Request)을 올리면 디자인 시스템 팀이 리뷰하고, 가이드라인을 위반한 부분을 지적하는 방식이다. 하지만 공공 웹사이트의 특성상, 이런 지속적인 리뷰 체계가 갖춰진 곳은 많지 않다. 담당 공무원이 개발 코드 리뷰를 할 수 없고, 외주 개발사가 스스로 KRDS 준수를 체크하는 것에만 의존해야 하는 경우가 대부분이다.

자동화된 컴포넌트 준수 검증이 이 공백을 메울 수 있다. 코드 리뷰가 아니라 배포된 사이트를 주기적으로 분석해서, "지난 분기와 비교해 어디서 드리프트가 발생했나"를 자동으로 알려주는 것이다. 이것이 완벽하게 작동하려면 아직 해결해야 할 기술적 문제들이 있지만, 방향으로서는 충분히 의미 있다.

세계적으로도 이 방향으로의 움직임이 있다. zeroheight, Supernova, Figma Radar 같은 도구들이 Figma 디자인 파일과 프로덕션 코드 간의 컴포넌트 사용 일치율을 측정하려 한다(zeroheight Design System Measurement). 이들은 "디자인 시스템을 얼마나 잘 사용하고 있나"를 데이터로 보여주는 방향을 추구한다.

ViewCheck의 접근은 프로덕션 사이트(실제 배포된 웹사이트)를 직접 분석한다는 점에서 이들과 다르다. Figma 파일이나 코드 저장소에 접근할 필요 없이, 공개된 URL만 있으면 된다. 공공 웹사이트처럼 외부에서 접근 가능한 사이트라면 어디든 분석할 수 있다. 이것이 담당자가 개발 환경에 접근 권한이 없어도 활용할 수 있는 강점이다.

물론 이 접근도 한계가 있다. 프로덕션 사이트 분석이기 때문에 개발 단계에서의 가이드라인 위반을 사전에 막기보다, 이미 배포된 문제를 발견하는 사후 방식이다. 이상적으로는 CI/CD 파이프라인에서 배포 전에 자동 검증이 이루어지는 것이 좋겠지만, 그것은 공공 조직의 개발 인프라 접근이 필요한 다른 차원의 이야기다.

마무리 — "자동화가 잡아주는 것"과 "사람이 봐야 하는 것"

이 글을 마무리하면서 가장 중요한 메시지를 하나 남기고 싶다.

DOM과 ARIA 분석으로 CP 446개 규칙을 자동 판정하는 것은 가능하고 가치 있다. 하지만 그 가치는 "자동화가 모든 문제를 찾아낸다"는 데 있지 않다. 가치는 "사람이 봐야 할 것을 훨씬 빠르고 넓게 스캔해서, 어디를 중점적으로 들여다봐야 하는지를 알려주는 데" 있다.

자동화가 잘 잡는 것: 접근 가능한 이름의 누락, 역할 속성의 부재, 레이블과 입력창의 미연결, 상태 속성의 정적 검증, 컴포넌트 유형별 기본 구조 확인.

자동화가 여전히 어려운 것: 의미론적 적절성 판단, 시각적 충분성 판단, 동적 상호작용 후의 상태 검증, 비표준 커스텀 컴포넌트의 의도 파악.

이 두 영역을 명확히 구분하고, 자동화는 전자를 맡아 빠르고 일관되게 처리하며, 후자는 사람이 우선순위를 가지고 수동으로 확인하도록 안내하는 것 — 그것이 ViewCheck가 CP 규칙 자동화에서 추구하는 균형이다.

446개 규칙을 100% 자동으로 완벽하게 판정하는 것은 아마 오랫동안, 어쩌면 영원히 불가능할 것이다. 그러나 446개 규칙 중 자동화가 가능한 영역에서 사람보다 빠르고 일관되게 잡아내면서, 자동화가 못 하는 영역에서는 사람의 판단을 명확히 요청하는 것 — 그 조합이 지금 우리가 실험하고 있는 방향이다.

다음 편에서는 같은 맥락에서 컴포넌트 분석 결과를 더 자세히 살펴보는 이야기를 이어가겠다. 컴포넌트 준수와 디자인 거버넌스, 그리고 자동화 도구의 역할에 대한 이야기는 여기서 끝나지 않는다.

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 WebSearch로 검증했다. 국내 공식 기준, 해외 표준·연구 자료를 함께 실었다.

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

행정안전부·디지털플랫폼정부위원회, KRDS(범정부 UI/UX 디자인시스템) 공식 사이트. 버튼 컴포넌트 가이드 및 접근성 규칙. https://www.krds.go.kr/html/site/component/component_05_02.html
KRDS-uiux GitHub, KRDS HTML Component Kit. https://github.com/KRDS-uiux/krds-uiux
과학기술정보통신부·한국지능정보사회진흥원(NIA), 「2024년 디지털 정보격차·웹 접근성·스마트폰 과의존 실태조사 결과 발표」. https://www.korea.kr/briefing/pressReleaseView.do?newsId=156681128
한국지능정보사회진흥원(NIA), 웹 접근성 실태조사 통계. https://www.nia.or.kr/site/nia_kor/ex/bbs/List.do?cbIdx=99873

해외 — 표준 / 디자인 시스템 / 연구

W3C WAI, "ARIA Authoring Practices Guide (APG) — Patterns". 버튼, 탭, 모달, 아코디언 등 컴포넌트별 ARIA 패턴 및 키보드 상호작용 가이드. https://www.w3.org/WAI/ARIA/apg/patterns/
W3C WCAG 2.2, "Technique ARIA4: Using a WAI-ARIA role to expose the role of a user interface component" and "Technique ARIA5". https://www.w3.org/WAI/WCAG22/Techniques/
Nielsen Norman Group, "Design Systems 101". 디자인 시스템 정의 및 거버넌스 중요성. https://www.nngroup.com/articles/design-systems-101/
Nielsen Norman Group, "Your Design System Needs an Enforcer". 디자인 시스템 준수 강제의 필요성. https://www.nngroup.com/articles/design-system-enforcer/
GOV.UK Design System, "Accessibility". WCAG 2.2 AA 준수 전략 및 컴포넌트 접근성. https://design-system.service.gov.uk/accessibility/
UK Government Accessibility Blog, "Get to WCAG 2.2 faster with the GOV.UK Design System" (2024). https://accessibility.blog.gov.uk/2024/01/11/get-to-wcag-2-2-faster-with-the-gov-uk-design-system/
USWDS, "Accessibility — U.S. Web Design System". 44개 컴포넌트 접근성 적합성 보고서 및 테스트 방법론. https://designsystem.digital.gov/documentation/accessibility/
WebAIM, 2024 접근성 연구 (ARIA 사용 시 오류 34% 증가 데이터). https://webaim.org
zeroheight, "Design Systems Measurement". 컴포넌트 채택률 측정 방법론. https://zeroheight.com/measurement/