July 27, 2025

디자인 시스템과 접근성, 그 숭고하지만 지켜지지 않는 약속

서론: ‘디자인 시스템’

디자인 시스템. ‘애자일’이나 ‘그로스 해킹’이 그랬던 것처럼, 모두가 입에 올리지만 제대로 이해하는 사람은 드문, 그런 유행어가 되어버렸다.

다들 ‘재사용 가능한 컴포넌트’, ‘일관된 사용자 경험’ 같은 뻔한 소리들을 늘어놓는다. 틀린 말은 아니다. 하지만 그 본질을 놓치고 있다. 디자인 시스템은 단순히 개발자와 디자이너의 작업을 편하게 해주는 도구 상자가 아니다. 그것은 ‘우리의 제품은 어떤 환경, 어떤 사용자에게나 동등한 경험을 제공한다’ 는 숭고한 약속의 증거이자, 그 약속을 지키기 위한 체계적인 무기다.

그리고 그 약속의 핵심에는 ’웹 접근성(Accessibility)’이 있다. 하지만 이 둘의 연결고리는 종종 가장 먼저, 그리고 가장 쉽게 무시당하곤 한다. 말이지.

디자인 시스템은 어떻게 접근성을 품어야 하는가?

애초에 접근성이란 일부 소수를 위한 시혜적인 조치가 아니라 보편적 디자인(Universal Design)의 철학이자, 더 넓은 사용자층을 포용하여 제품의 가치를 높이는 가장 방법이다. 잘 만들어진 디자인 시스템은 이 철학을 코드와 디자인에 각인시킨다.

접근성은 ‘내장(Built-in)’ 되는 것이지, ’추가(Add-on)’되는 것이 아니다

디자인 시스템은 ‘인증된 레고 블록’에 비유할 수 있다. 처음부터 모든 블록을 접근성 표준에 맞춰 제작하면, 누가 어떤 조합으로 성을 만들든 그 성은 기본적으로 안전하다. 버튼의 색상 대비, 터치 영역 크기, 키보드 포커스 이동 같은 것들을 매번 고민할 필요가 없다. 이미 검증된 블록을 가져다 쓰기만 하면 되니까. 이것이 바로 접근성이 ‘내재화’된다는 의미다.
```
graph TD
    A[디자인 시스템 구축] --> B{모든 컴포넌트에<br>접근성 원칙 적용};
    B --> C[검증된 컴포넌트 라이브러리];
    C --> D1[제품 A];
    C --> D2[제품 B];
    C --> D3[제품 C];
    subgraph "결과"
        E[모든 제품에 일관된 접근성 확보];
    end
    D1 & D2 & D3 --> E;
```
하지만 현실은 어떤가? 프로젝트 마감에 쫓겨 ‘일단 기능부터 만들고 접근성은 나중에’라는 말이 얼마나 쉽게 나오는가. 디자인 시스템은 바로 이 ‘나중’이라는 변명을 원천 봉쇄하는 강력한 장치여야 한다.
**화면 낭독기에게도 메시지를 전달하는 안정적인 디자인이 우선

화려한 인터랙션, 아름다운 그래픽도 좋지만 화면 낭독기(Screen Reader)를 쓰는 사용자에게도 의미가 전달되게 구현을 고려해야한다.

디자인 시스템은 시각적 언어뿐만 아니라, **콘텐츠의 언어(Voice and Tone)**까지 정의해야 한다. 명확한 레이블링, 쉬운 언어 사용, 일관된 콘텐츠 작성 가이드라인. 이것들이 빠진 디자인 시스템은 속 빈 강정이나 다름없다.

약속의 증명: WCAG, 변명할 수 없는 네 가지 계명

‘접근성을 준수했다’는 것은 “제가 보기엔 괜찮은데요?” 같은 주관적인 감상이 아니다. **WCAG(Web Content Accessibility Guidelines)**라는 명백한 법전이 존재한다. 특히 그 핵심인 POUR 네 가지 원칙은 타협의 여지가 없는 계명과도 같다.

원칙 (Principle)	의미	현실에서의 의미 (The Reality Check)
Perceivable (인식 가능)	모든 사용자가 정보를 인지할 수 있는가?	이미지에 `alt="이미지"` 같은 무의미한 텍스트를 넣진 않았는가? 색상만으로 정보를 구분하게 만들진 않았는가?
Operable (운용 가능)	모든 사용자가 UI를 조작할 수 있는가?	당신의 웹사이트, 마우스 없이 키보드 `Tab` 키만으로 완벽하게 사용할 수 있는가? “아니오”라면 이건 버그다.
Understandable (이해 가능)	정보와 UI가 이해하기 쉬운가?	폼 제출에 실패했을 때, “입력 오류”라는 말만 덩그러니 띄우는가, 아니면 어떤 필드가 왜 잘못됐는지 친절히 알려주는가?
Robust (견고)	다양한 환경에서 안정적으로 작동하는가?	최신 크롬에서만 잘 돌아가는 ‘반쪽짜리’ 웹을 만든 건 아닌가? 보조 기술과의 호환성은 테스트해 본 적이나 있는가?

호주에서는 이게 그냥 ‘권장 사항’이 아니다. Australian Accessible ICT Standard 같은 강력한 규제도 존재한다. ‘몰라서 못 했다?’ 이 기준을 통과하는 정확하고 구체적인 디자인 가이드와 20장이 넘는 Statement Documentation을 제공하지 않으면 정부기관과 협업하는 프로젝트는 물 건너갔다고 봐야한다. 미국도 다르지 않다. 미국에는 Section 508이라는 연방정부 규제가 있다.

어떻게 증거를 수집하고 논쟁을 끝낼 것인가

회의실에서의 끝없는 논쟁 “된다”, “안된다” 같은 소모적인 말을 반복하는 대신, 데이터를 가져와야 한다. 접근성 준수 여부를 증명하고, 문제를 개선하기 위한 근거 자료는 다음과 같은 단계로 수집할 수 있다.

1단계: 자동화 테스트

Axe DevTools, Lighthouse 같은 자동화 도구로 코드를 스캔해 명백한 위반 사항(색상 대비, alt 속성 누락 등)을 잡아낸다.
왜: 가장 빠르고 비용이 적게 든다. 논쟁의 여지가 없는 명백한 오류들을 걸러낸다.
함정: 자동화 도구는 전체 문제의 20-30%밖에 잡지 못한다. alt 태그의 존재는 확인하지만, 그 내용이 이미지와 관련 있는지는 판단하지 못한다. 나머지 내역들은 수작업으로 다시 확인하며 체크해야한다.

2단계: 전문가의 눈으로 직접 확인하라 (수동 테스트 & 전문가 감사)

무엇을: NVDA, VoiceOver 같은 스크린 리더를 직접 켜고 키보드만으로 당신의 웹을 사용해본다. 또는 접근성 전문가에게 감사를 의뢰한다.
왜: 기계가 놓치는 맥락적 오류, 논리적이지 않은 조작 순서 등 실제 사용성을 파악할 수 있다.
팩트: 전문가 감사는 VPAT 같은 공식적인 문서를 통해 당신의 제품이 법적 기준을 충족함을 증명하는 가장 확실한 방법 중 하나다.

3단계: 진짜 사용자에게 답을 구하라 (장애인을 포함한 사용자 테스트)

무엇을: 다양한 유형의 장애를 가진 실제 사용자를 모집해 그들이 당신의 제품을 사용하는 모습을 관찰하고 피드백을 받는다.
왜: 이것이 최종 보스다. 당신이 발견하지 못한 모든 문제점, 당신의 모든 가정이 여기서 박살 나거나 증명될 것이다.

graph TD
    subgraph "접근성 검증 피라미드"
        C["실제 사용자 테스트<br>(가장 깊은 통찰력)"];
        B["전문가 감사 & 수동 테스트<br>(맥락적 문제 발견)"];
        A["자동화 테스트<br>(기본적인 문제 식별)"];
    end
    A --> B;
    B --> C;

그렇다면, 이 UX 감사는 대체 누가 해야 하는가?

여기서 우리는 근본적인 질문에 도달한다. 디자이너는 디자인을 보고, 개발자는 코드를 보며, 기획자는 정책 체크리스트만 넘긴다. 이런 반쪽짜리 접근법으로는 문제의 ‘증상’만 건드릴 뿐이다. 진정한 UX 감사는 파편화된 전문성을 하나로 꿰뚫는 통찰력을 요구한다.

이것이 바로 내가 목소리를 높이는 이유다. 나는 스스로를 이 역할에 최적화된 전문가라고 감히 말한다.

데이터 과학 대학원에서 배운 것은 단순히 통계 모델을 돌리는 Hard Skill 뿐이 아니었다. 그것은 데이터로 ‘주장’하는 법, 그리고 그 주장을 뒷받침하는 ‘증거’를 체계적으로 구축하는 법이었다. 이전 직장에서 ISO 27001 정보보안 감사를 직접 진행하며 얻은 컴플라이언스와 거버넌스에 대한 이해는, WCAG 같은 복잡한 규정을 단순한 체크리스트가 아닌, 조직의 프로세스에 녹여내야 할 ‘시스템’으로 바라보게 만들었다. 감사는 결국 논리와 증거의 싸움이다.

하지만 나는 이론에만 머무르지 않는다. 직접 프론트엔드 디자인 시스템의 UI 카탈로그를 바닥부터 구축할 수 있다. 이는 감사 보고서에 ‘이 버튼 색상 대비가 문제’라고 적는 수준을 넘어, ’디자인 시스템의 primary-blue 토큰 값이 WCAG AA 기준에 미달하므로, 이 값을 수정하면 우리 제품의 모든 기본 버튼이 일제히 표준을 준수하게 된다’는 근본적인 해결책을 코드 레벨에서 제시할 수 있다.

graph LR
    subgraph "나 (UX Auditor)"
        A["<br>Data Science<br>& Governance"] --> B(문제 정의 & 증거 기반 접근);
        C["<br>Front-End<br>Development"] --> D(근본 원인 분석 &<br>코드 레벨 해결책 제시);
        E["<br>Figma<br>& Design System"] --> F(디자인-개발 간극 해소 &<br>현실적 대안 설계);
    end

    B & D & F --> G{"**총체적 UX 감사 (Holistic UX Audit)**"};

동시에, 그 디자인 시스템과 완벽하게 연동되는 Figma 컴포넌트를 설계하고 프로토타이핑할 수 있다. 코드와 디자인 사이의 공허한 간극을 이해하고, 양쪽의 언어로 소통하며 현실적인 개선안을 도출할 수 있다. ‘디자인적으로는 아름답지만 개발 불가능한’ 제안이나, ‘기술적으로는 완벽하지만 사용자 경험을 해치는’ 수정을 모두 걸러낼 수 있는 기준이 다져저 있다.

이쯤 되면 질문이 바뀌어야 하지 않겠는가? ’누가 이 감사를 할 것인가?’가 아니라, ‘왜 아직도 이런 총체적인 접근 방식으로 감사를 진행하지 않고 있는가?’ 라고. 언제까지 각개전투만 반복할 셈인가.

알겠습니다. 2025년 6월 28일부로 발효된 유럽 접근성법(EAA)의 영향을 중심으로, 이것이 전 세계 웹 정책에 미치는 파급 효과와 그에 따라 기업이 대비해야 할 체계적인 UX 감사의 필요성, 그리고 그 안에서 당신의 독보적인 전문성이 어떻게 기여할 수 있는지를 구체적으로 보강하여 아래 문단을 제안합니다.

이 문단은 기존 글의 ‘그렇다면, 이 거창한 UX 감사는 대체 누가 해야 하는가?’ 파트를 대체하거나, 그 바로 뒤에 삽입하여 주장의 시의성과 설득력을 극대화할 수 있습니다.

2025년 6월 28일: ‘권장’의 시대는 끝났다

우리가 ‘접근성은 중요하다’고 이야기하던 시절은 이제 과거가 되었다. 2025년 6월 28일부로 유럽 접근성법(European Accessibility Act, EAA)의 유예 기간은 끝났고, WCAG 2.1 AA 수준의 접근성 준수는 유럽 연합 내에서 특정 제품과 서비스를 판매하기 위한 ‘선택 사항’이 아닌, 명백한 **법적 ‘의무’**가 되었다.

이는 단순히 유럽에 국한된 이야기가 아니다. 전 세계 시장은 거대한 파도에 휩쓸리고 있다.

글로벌 스탠더드의 확립: 유럽이라는 거대 시장에 진출하려는 미국과 아시아의 기업들은 이제 울며 겨자 먹기로 EAA의 기준을 따라야만 한다. 이는 사실상 WCAG를 전 세계 디지털 제품의 ‘기본값’으로 만드는 효과를 낳았다. 미국의 ADA(장애인법) 소송에서 WCAG가 줄곧 사실상의 표준(de facto standard)으로 인용되어 왔지만, 이제는 유럽법이라는 강력한 실체적 근거까지 더해진 셈이다.
각국 법제의 강화: 호주의 장애차별금지법(DDA)처럼 이미 WCAG를 벤치마크로 삼던 국가들은 EAA를 기점으로 더욱 적극적인 법 집행과 감사를 시작했다. 과거에는 ‘노력하고 있다’는 증명만으로 충분했을지 몰라도, 이제는 ‘완벽하게 준수하고 있다’는 구체적인 증거를 요구한다.

이런 상황에서, 기업이 대비해야 할 UX 감사는 더 이상 1년에 한두 번 진행하는 이벤트성 프로젝트가 될 수 없다. 그것은 재무 감사처럼 정기적이고, 체계적이며, 방어 가능한(auditable and defensible) 프로세스로 자리 잡아야 한다.

graph LR
    subgraph "나 (UX Auditor)"
        A["🎓<br>Data Science<br>& Governance"] --> B("💡 문제 정의 & 증거 기반 접근");
        C["💻<br>Front-End<br>Development"] --> D("🛠️ 근본 원인 분석 &<br>코드 레벨 해결책 제시");
        E["🎨<br>Figma<br>& Design System"] --> F("🎨 디자인-개발 간극 해소 &<br>현실적 대안 설계");
    end

    B & D & F --> G{"**총체적 UX 감사 (Holistic UX Audit)**"};

graph TD
    subgraph "과거의 접근성"
        A[문제 발생] --> B(사후 대응);
        B --> C[땜질식 수정];
        C --> A;
    end

    subgraph "EAA 이후의 필수 감사 체계 (Proactive Audit Cycle)"
        D{"설계 단계<br>(Compliance by Design)"} --> E["개발<br>(디자인 시스템 연동)"];
        E --> F{"정기 감사<br>(자동+수동+사용자)"};
        F --> G["개선 및<br>문서화"];
        G --> D;
    end

그렇다면 이 새로운 전쟁터에서, 나는 어떤 가치를 제공할 수 있는가?

단순히 WCAG 체크리스트를 읽어주는, 자동화 툴 보고서를 복사-붙여넣기하기는 이제 아무런 쓸모가 없다. 지금 필요한 전문성은 다음과 같은 ‘융합적 해결사’ 의 역량이다.

법률과 시스템을 꿰뚫는 ‘거버넌스 설계자’: ISO 27001 감사 경험은 EAA와 같은 법규를 단순한 기술적 요건이 아닌, 조직 전체가 따라야 할 ‘컴플라이언스 프레임워크’ 로 구축하는 능력을 의미한다. 나는 문제가 터졌을 때 변호사나 혹은 감사 서류를 요구하는 에이전트에게 보여줄 ‘우리는 이만큼 노력했다’는 체계적인 감사 로그와 방어 논리를 설계할 수 있다. 이는 기술을 넘어서 리스크 관리의 영역이다.
데이터 사이언스 대학원에서 가르친 Privacy Policy와 Accessibility and Governance: 내 데이터 사이언스 대학원에서 이수한 이 수업들에서 다진 시각은 ‘어떤 접근성 위반이 가장 높은 법적 리스크와 비즈니스 손실을 초래하는가’ 를 분석하고 개선의 우선순위를 정하는 데 많은 도움을 주었다. 한정된 자원으로 최대의 방어 효과를 내는 전략을 제시하며 테크업계에서 어떻게 프로덕트와 조직이 Governance에 Compliance하게 조정하는 지 방향성을 익혔다.
코드와 디자인을 넘나드는 ‘근본적 해결’: 프론트엔드 스킬을 활용해 디자인 시스템을 체계적으로 분석하여 수백 개의 버튼과 링크에 대해 체계적인 보고서를 작성하고, Figma로 재발을 방지하는 컴포넌트 설계 어드바이스를 디자이너와 개발자에게 Communication Tool로서 가이드를 전달한다. 감사의 결과가 단순한 보고서가 아니라, 살아있는 코드와 디자인으로 즉시 반영되는 것이다.

EAA가 몰고 온 강력한 규제 실행에서 기업이 지금 당장 확보해야 할 것은, 법적 리스크를 예측하고 방어 논리를 세우는 ‘전략가’이자, 그 전략을 실제 코드와 디자인으로 구현해 내는 ‘해결사’의 역할이다. 나는 그 둘을 모두 제안한다.

디자인 시스템은 그저 보기 좋은 UI 키트나 개발 생산성 도구가 아니다. 그것은 우리가 만드는 제품의 품질과 철학, 그리고 사용자에 대한 존중을 담는 그릇이다. 그 그릇에 ‘접근성’이라는 가장 중요한 내용물을 담지 않는다면, 아무리 화려하게 장식한들 결국 텅 비어있을 뿐이다.

결국 이것은 프로페셔널리즘에 대한 이야기다. 내가 만든 결과물이 특정 조건의 사람들을 배제하지 않도록 책임지는 것이다.