서론: 접근성, 이제는 선택이 아닌 운영의 문제

AI가 코드 작성을 대신하는 시대, 시니어 엔지니어가 오후 하나로 체크아웃 플로우를 만들 수 있게 되었습니다. 하지만 스크린 리더 사용자는 '결제하기' 버튼을 찾지 못해 구매를 포기합니다. 코드가 실행되는 것과 사람이 실제로 쓸 수 있는 제품 사이의 간극은 AI 시대의 핵심 엔지니어링 과제가 되었습니다.

이 글은 단순한 규정 준수 체크리스트나 감사(audit)에 관한 내용이 아닙니다. 접근성을 보안, 개인정보 보호, 신뢰성, 관찰 가능성과 같은 운영 능력으로 다루는 엔지니어링 시스템에 대한 이야기입니다. 특히 AI가 UI 생성을 가속화하는 지금, 접근성은 더욱 시스템적으로 접근해야 합니다.

Engineer reviewing accessibility compliance dashboard with security and compliance metrics

본론 1: 접근성을 시스템으로 만들기

감사의 함정 (The Audit Trap)

전통적인 접근성 접근 방식은 일회성 감사였습니다. 컨설팅 업체를 고용해 200개의 문제점을 발견하고, 일부만 수정하고, 보고서를 제출하는 방식이죠. 감사는 판매, 조달, 거버넌스 측면에서 중요합니다. VPAT나 ACR 문서가 필요할 때, 법무팀이 요구사항 충족 여부를 물을 때 감사는 필수적입니다.

하지만 감사는 스프린트 계획 중에 접근성 있는 기능을 만드는 데 도움이 되지 않습니다. 머지 리퀘스트 전에 문제를 잡아내지 못하고, 배포 속도를 따라가지 못합니다. WebAIM Million 보고서에 따르면 2026년 기준 상위 100만 페이지 중 95.9%가 WCAG 실패를 겪었고, 페이지당 평균 56.1개의 오류가 있었습니다. 페이지 요소 수는 1년 만에 20% 이상 증가했는데, 이는 AI 기반 개발과 '바이브 코딩'의 영향으로 보입니다. 접근성 부채는 기술 부채와 정확히 동일하게 작용합니다.

AI 문제, 아무도 말하지 않으려는 것

2025년 2월, Andrej Karpathy가 '바이브 코딩'이라는 용어를 만들었습니다. 의도를 설명하면 모델이 코드를 생성하고, 개발자는 그 diff를 읽지 않고 수락하는 방식이죠. Y Combinator는 2025년 겨울 배치의 25%가 95% AI 생성 코드베이스를 가졌다고 보고했습니다.

문제는 AI 생성 UI가 기본적으로 접근성이 떨어진다는 것입니다. 한 개발자가 Frontend Masters에서 AI 생성 React 컴포넌트를 테스트했는데, 29줄의 사이드바에서 10개의 접근성 실패를 발견했습니다. 랜드마크 없음, 헤딩 없음, 리스트 구조 없음, 클릭 핸들러가 있는 div, aria-expanded 없음, 키보드 핸들링 없음, 라벨 없는 아이콘 등이었죠. 접근성 트리는 완전히 평평했습니다. "같은 픽셀이지만, 하나는 문이고 다른 하나는 문 그림이다"라는 표현이 적절합니다.

보안도 같은 뿌리에서 문제가 발생합니다. Veracode의 2025년 GenAI 코드 보안 보고서는 AI 생성 코드가 OWASP Top 10 취약점을 포함할 가능성이 높다고 밝혔습니다. 개발자가 보안 제약 조건을 명시하지 않고 생성 결과를 검증 없이 수락하는 과정의 문제입니다. 접근성도 마찬가지입니다. AI를 금지하는 것이 아니라, 제약하고 검증하는 시스템이 필요합니다.

실무 적용: 접근성을 운영 능력으로 만드는 패턴

접근성을 성공적으로 확장하는 조직은 히어로에 의존하지 않고 시스템에 의존합니다. 가장 효과가 큰 시작점은 디자인 시스템입니다. GOV.UK 디자인 시스템은 JAWS, NVDA, VoiceOver, TalkBack 같은 보조 기술로 자동 및 수동 테스트를 수행합니다. 컴포넌트가 올바르게 시작되면 접근성은 인프라가 됩니다.

// 예시: 접근성 고려한 React 버튼 컴포넌트
import React from 'react';

const AccessibleButton = ({ onClick, children, disabled }) => {
  return (
    <button
      type="button"
      onClick={onClick}
      disabled={disabled}
      aria-disabled={disabled}
      className="btn"
    >
      {children}
    </button>
  );
};

export default AccessibleButton;

이 코드는 시맨틱 HTML 버튼을 사용하고, aria-disabled로 상태를 노출합니다. 이런 기본 원칙이 지켜지면 스크린 리더와 키보드 사용자가 모두 문제없이 사용할 수 있습니다.

엔지니어링 워크플로우에 접근성 통합하기:

  • 완료 조건(Definition of Done)에 접근성 요구사항 포함
  • PR 리뷰에 명시적 접근성 체크 추가
  • 인터랙티브 컨트롤은 기본적으로 시맨틱 요소(,) 사용
  • 키보드 내비게이션과 포커스 관리를 표준 엔지니어링 관심사로 취급

자동화로 강제하기:

  • eslint-plugin-jsx-a11y로 커밋 전 일반적인 문제 감지
  • LevelCI, Pa11y로 CI/CD 파이프라인에서 자동 테스트
  • @storybook/addon-a11y로 컴포넌트 개발 중 문제 표면화

Developer using semantic HTML and ARIA attributes in code editor for accessible web development IT Technology Image

본론 2: 확장 가능한 패턴과 비즈니스 영향

패턴 1: AI 생성을 제약하기

생성 후 수정하는 대신, Cursor rules, Copilot instructions, 저장소 수준 표준에 접근성 요구사항을 직접 주입하세요. 모델에게 시맨틱 HTML을 쓰라고 지시하고, 버튼과 링크의 사용 시점을 명시하고, 상태와 라벨을 올바르게 노출하라고 알려주세요. 모델은 일회성 프롬프트보다 지속적인 제약을 훨씬 잘 따릅니다.

패턴 2: 복잡한 위젯을 직접 만들지 않기

콤보박스, 메뉴, 탭, 모달 같은 컨트롤은 접근성 문제가 자주 발생합니다. Radix UI, React Aria, Headless UI 같은 라이브러리는 이미 이러한 문제를 해결합니다. 잘 테스트된 프리미티브에서 접근성 동작을 상속받는 것이 반복 구현보다 훨씬 확장 가능합니다.

패턴 3: 디자인 핸드오프에서 접근성 캡처

포커스 순서, 라벨, 헤딩 계층, 인터랙션 상태는 구현 전에 명시되어야 합니다. 디자인 산출물에 접근성 요구사항이 없으면 최종 제품에도 없는 경우가 많습니다. 탭 순서, 라벨, 에러 시 동작을 담은 간단한 메모가 나중에 큰 추측을 제거합니다.

비즈니스 영향

규제 압력은 계속 증가하고 있습니다. 미국에서 디지털 접근성 소송은 연간 수천 건에 이르고, 유럽 접근성법(EAA)은 EU 전역에서 시행됩니다. 하지만 규정 준수는 일부일 뿐입니다. 세계경제포럼(2023년 12월)은 전 세계 13억 장애인의 구매력이 13조 달러에 달한다고 추정합니다. 영국에서만 접근성 문제로 인한 이탈 비용이 171억 파운드에 달합니다.

조달 측면에서도 접근성은 비용이 아니라 경쟁 우위가 됩니다. B2B나 정부 대상 판매 시 VPAT/ACR 문서가 요구되는 경우가 늘고 있습니다. Level Access의 7차 연례 보고서에 따르면 조직의 75%가 디지털 제품 구매 시 접근성 증명을 요구합니다. 강력한 접근성 스토리는 영업 사이클을 가속화하고, 약한 스토리는 거래를 지연시키거나 실패시킵니다.

접근성과 속도는 적대 관계가 아니다

시프트 레프트(shift-left)는 DevOps의 핵심 논리이며 접근성에도 그대로 적용됩니다. 디자인 리뷰에서 발견된 접근성 문제는 한 줄 코멘트에 불과하지만, 운영 환경에서 발견된 문제는 수정 프로젝트가 됩니다. 컴포넌트를 만들 때 발견하면 몇 분이면 되지만, 나중에 감사에서 발견하면 몇 시간이 걸립니다. 수백 개의 문제가 있는 후기 감사는 수주간의 계획되지 않은 작업을 만듭니다. 접근성은 속도를 줄이지 않습니다. 예상치 못한 작업이 속도를 줄입니다.

Team collaborating on accessible design system components for enterprise applications Software Concept Art

결론: 시스템, 스프린트가 아니라

접근성은 감사, 히어로, 출시 전 영웅적인 수정 스프린트에서 나오지 않습니다. 시스템에서 나옵니다.

  • 접근성 있는 디자인 시스템으로 컴포넌트가 올바르게 시작
  • 완료 조건으로 지속적인 품질 유지
  • 자동 테스트와 CI 게이트로 회귀 실패
  • 거버넌스로 책임자 지정
  • AI 지원 개발에 가드레일을 설치해 가장 빠른 도구가 가장 큰 리스크가 되지 않게

이러한 관행은 화려하지 않지만, 보안, 신뢰성, 성능을 위해 이미 신뢰하는 지루하고 안정적인 시스템과 동일합니다. 하지만 어떤 도구도 장애인이 실제로 제품을 사용하는 경험을 대신할 수 없습니다. 시스템을 구축하되, 장애인 사용자와 정기적으로 테스트하세요. 도구는 통과 여부를 알려주지만, 실제 사람은 작동 여부를 알려줍니다.

국내 개발 생태계 적용 맥락: 한국의 SI 프로젝트에서는 접근성 감사가 마감 직전에 몰리는 경우가 많습니다. 그러나 이 글에서 강조하는 것처럼 일회성 감사는 지속적인 운영 능력이 되지 못합니다. 국내에서도 디자인 시스템과 CI/CD에 접근성 체크를 통합하는 문화가 자리 잡아야 합니다. 특히 공공기관 프로젝트는 KWCAG(한국형 웹 콘텐츠 접근성 지침)를 준수해야 하므로, 초기부터 접근성을 설계에 포함하는 것이 중요합니다.

한계 및 주의사항: 자동화 도구는 전체 접근성 문제를 찾지 못합니다. 예를 들어, 키보드 포커스 순서나 스크린 리더 사용자 경험은 자동으로 완벽하게 검증할 수 없습니다. 또한, 디자인 시스템이 모든 접근성을 '마법처럼' 해결하지는 않습니다. 팀의 지속적인 관심과 사용자 테스트가 필수입니다.

다음 단계 학습 방향: 접근성 전문가 과정(IAAP CPACC, WAS)을 고려하거나, 실제 장애인 사용자와의 테스트 세션을 정기적으로 진행하는 것을 추천합니다. 또한, React Conf 2025 핵심 정리 컴파일러 정식 출시부터 네이티브 대격변까지에서 다룬 최신 프론트엔드 트렌드와 접근성을 결합하는 방법을 탐구해보세요. KubeCon EU 2026에서 공개된 MS의 쿠버네티스 & AI 인프라 대규모 업데이트 총정리에서 AI 인프라 운영 능력과 접근성의 유사점을 발견할 수도 있습니다.

접근성은 기능이 아닙니다. 운영 능력입니다. 그렇게 대우할 때, 개발 및 제품 리더가 이미 중요하게 여기는 더 빠르고, 안전하고, 신뢰할 수 있는 소프트웨어를 얻을 수 있습니다.

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.