두 개의 규범, 하나의 오해
공공 웹 구축 문서에는 늘 KRDS와 KWCAG가 같이 등장한다. 처음엔 비슷한 것의 다른 이름인가 싶었지만, 층이 다른 규범이었다.
KRDS(Korea Government Design System)는 행정·공공기관 화면을 통일하려고 정부가 배포하는 범정부 디자인 시스템으로, 「디지털 정부서비스 UI/UX 가이드라인」의 실체가 이것이다. 색상 토큰·타이포그래피·컴포넌트 55종·패턴으로 구성되고, 가이드 문서와 공식 HTML/CSS 킷으로 배포된다.
KWCAG 2.2(한국형 웹 콘텐츠 접근성 지침)는 웹 접근성 국가표준이다. W3C의 WCAG 2.1을 국내 실정에 맞게 고친 것으로 2022년 12월에 2.2로 올라갔고, 4개 원칙 → 14개 지침 → 33개 검사항목 구조다. 중요한 건 판정 방식인데, 자동 도구 점수가 아니라 전문가 심사와 스크린리더 실사용 평가로 가른다.
그래서 가설을 세웠다. “KRDS 컴포넌트가 접근성을 고려해 설계됐다면, KRDS를 쓰면 KWCAG도 따라오는 게 아닐까?”
절반만 맞았다. 제대로 쓰면 상당수 항목이 기본 충족되는 건 사실이다. 그런데 컴포넌트는 “부품이 규격대로인가”까지만 보장한다. 준수를 가르는 나머지는 부품을 채우고 조립한 결과에서 나온다.
- 콘텐츠 — 대체 텍스트·링크 문구의 “내용”은 부품이 채워줄 수 없다.
alt속성이 있어도 값이image123.jpg면 미준수다 - 조립 — 키보드 탭 이동 순서, 모달의 초점 가두기, 제목(h1~h6) 위계처럼 여러 컴포넌트에 걸친 항목은 페이지 수준에서만 판정된다
기존 도구를 열어보다
결국 부품 밖의 나머지는 사람이 눈으로 잡는다는 뜻이다. 그럼 KRDS 적용과 KWCAG 검사를 함께 다뤄주는 도구가 이미 있지 않을까. 찾아보니 없었고, 그 과정에서 판단이 두 번 뒤집혔다.
첫 번째: 이름이 검사기라고 검사기는 아니다
국내 접근성 진단 도구의 고전은 OpenWAX다. 이쪽은 뒤집힐 것도 없었다. Chrome 확장인데 업데이트가 2022년 4월에서 멈춰 있었고, KWCAG 2.2 고시는 그로부터 8개월 뒤인 2022년 12월이다. 2.2 미반영이 물리적으로 확정된 셈이다.
다른 하나인 KWCAG A11y Inspector는 이름만 보고 전반 검사기로 분류했다가, 스토어 설명을 열어보고 고쳤다. 하는 일은 클릭 대상 크기(대각선 6mm)와 명도 대비율을 마우스오버로 재는 것이다. 검사기가 아니라 측정 도구이고, 33개 항목 중 극히 일부만 다룬다.
국제 도구인 axe-core는 검사 엔진의 사실상 표준이다. Lighthouse의 접근성 점수도 이걸 돌린 결과다. 문제는 결과가 WCAG 기준으로 나온다는 것. 국내 심사와 산출물은 KWCAG 항목 번호 기준이라, 그 사이를 매번 사람이 번역하고 있었다.
두 번째: 커뮤니티 MCP의 데이터
KRDS 쪽에는 커뮤니티가 만든 MCP(Model Context Protocol) 서버가 있었다. AI 코딩 도구에 외부 데이터를 규격화해 물려주는 방식이다. 처음엔 README만 보고 “이미 있으니 만들 필요 없다”고 판단했다가, 저장소를 열어보고 뒤집었다.
만듦새는 성실했다. 모듈 구조, 테스트·CI·린트 설정이 갖춰져 있었다. 문제는 데이터의 깊이와 출처였다.
// (요약) data/components.js — 컴포넌트 하나의 정의
{
id: 'masthead',
name: '마스트헤드 (Masthead)',
usageGuidelines: ['페이지 최상단에 위치', ..., '높이는 40px 고정', ...],
accessibilityNotes: '스크린리더를 위한 랜드마크 역할 설정 필요',
codeExample: `<header role="banner" class="krds-masthead">...`
}파일 전체가 949줄인데 컴포넌트가 46종, 하나당 스무 줄 남짓이다. 마크업 한 조각과 지침 몇 줄이 전부라 목차 수준이었다. 파일 첫머리 주석은 “총 37개”라 적혀 있어 배열 개수와도 안 맞고, 공식 55종에는 어느 쪽도 못 미친다.
더 걸린 건 출처였다. krds-masthead__container 같은 클래스명과 “높이 40px 고정” 같은 수치가 어디서 왔는지, 기준 버전이나 출처 표기가 어디에도 없었다. 공식 킷을 받아 대조해 보니 실제로 어긋났다. __container 같은 클래스는 공식 CSS에 한 건도 없었고, 높이도 고정값이 아니라 토큰으로 잡힌 min-height 32px였다.
검증되지 않은 데이터를 처방의 근거로 삼으면, 도구가 “KRDS를 지키라”면서 비공식 마크업을 권하는 모순이 생긴다. 구조는 참고하되 데이터는 공식 킷에서 직접 추출하기로 했다.
방향을 바꾸다 — 검사에서 적용으로
처음 구상은 axe를 돌려 위반을 찾고 KWCAG 항목으로 번역해 리포트를 뽑는, “검사해서 고치는 도구”였다. 그런데 정작 원한 건 KRDS를 적용하는 것만으로 KWCAG가 최대한 함께 충족되는 상태였다.
도구의 중심에는 표 하나가 필요하다. KWCAG 33개 검사항목을 한 축에 두고, axe가 내는 WCAG 규칙과 KRDS 컴포넌트를 각각 짝지어 둔 대응 표, 이하 매핑표다. 목표를 바꾸면 표를 채우는 방향도 달라진다. KWCAG 항목이 아니라 컴포넌트에서 출발해, 하나를 놓고 33개 항목을 세 부류로 가른다.
| 분류 | 무엇인가 | 예 |
|---|---|---|
| ① 자동 충족 | 컴포넌트의 마크업·토큰이 보장 | 명암비, 랜드마크 역할 |
| ② 조건부 | 쓰는 사람이 채워야 성립 | 대체 텍스트, 라벨 |
| ③ 범위 밖 | 페이지·사이트 수준에서만 판정 | 초점 순서, 제목 위계 |
핵심은 ②번이다. 컴포넌트가 스스로 채울 수 없는 빈칸을 필수 입력으로 강제하면, 안 채운 상태로는 생성 자체가 되지 않는다. 검사는 “alt가 비었다”까지만 알려주지, 거기 무슨 문장이 들어가야 하는지는 모른다. 그건 그 이미지를 넣은 사람만 아는 것이고, 페이지가 다 만들어진 뒤엔 이미 잊힌 정보다.
검사는 ③번을 받치는 안전망으로 내려간다. 그래서 도구를 세 층으로 나눴다. ①·②는 1층에서 끝내고, ③만 2·3층으로 내려보내는 구조다. 같은 매핑표를 1층은 컴포넌트 열로, 2·3층은 axe 열로 재사용한다.
| 층 | 시점 | 하는 일 |
|---|---|---|
| 1층 (주축) | 페이지 만들 때 | KWCAG 충족 조건이 내장된 컴포넌트 공급 + 조건부 항목 필수 입력 강제 |
| 2층 | PR/빌드 | 변경 페이지 검사 — 회귀 방지 |
| 3층 | 제출 전 | 전수 검사 → 항목별 보고서 자동 생성 |
못 박아둔 제약도 하나 있다. 2·3층의 검사는 반드시 렌더된 DOM 기준으로 한다. 소스를 파싱하면 그 순간 스택에 종속되기 때문이다. 이 원칙 하나로 React·Vue·JSP 어디에나 물릴 수 있다.
회고
KRDS는 절반까지 데려다준다. 남은 절반을 어디서 막을지가 이 리서치의 결론이었다.
기존 도구를 조사하는 동안 판단을 두 번 뒤집었다. 두 번 다 이름이나 README가 아니라 스토어 설명과 저장소를 직접 열어본 뒤였다. 그리고 도구의 성격 자체도 검사에서 적용으로 옮겼다.
도구의 한계도 문서 맨 앞에 적어두기로 했다. 자동 판정이 가능한 이슈는 통상 전체의 3~4할 정도로 인용된다. 나머지는 여전히 사람이 본다.
“이 도구를 쓰면 준수됩니다”라고 팔면 안 된다. 준수는 결과물로 심사받는 것이고, 도구가 할 수 있는 일은 출발선을 당기고, 회귀를 막고, 증빙을 자동으로 남기는 것까지다.