데모는 완벽했다. 스크린리더는 아무 말도 못 했다.
AI로 UI 컴포넌트를 만드는 속도는 이제 놀라운 수준이다. v0.dev나 Cursor에 "수량 선택 스피너 컴포넌트 만들어줘"라고 치면 30초 안에 그럴싸한 코드가 나온다. 버튼 두 개, 인풋 하나, 마우스로 클릭하면 잘 동작한다. 시각적으로도 깔끔하다. 스테이크홀더 데모에서 박수가 나온다.
그런데 VoiceOver를 켜면 침묵이 흐른다. NVDA로 탭을 눌러보면 포커스가 어디로 갔는지 알 수 없다. 수량을 키보드로 바꾸려 해도 Up/Down Arrow가 아무 반응이 없다. AI가 생성한 코드는 시각적으로는 완전하지만, 감각 대체 수단이 필요한 사용자에게는 사실상 빈 껍데기다.
"잘 동작한다"의 기준이 틀렸다
접근성 전문가 Mica Avigliano가 직접 손으로 작성한 Quantity Spinbutton 패턴 분석은 이 문제를 정면으로 꺼낸다. 그는 글 도입부에 솔직하게 적는다. AI로 리서치를 도우려 했지만, 제대로 문서화되지 않은 접근성 엣지 케이스에서 AI가 그냥 답을 지어냈다고. 그래서 직접 뇌와 손을 써서 처음부터 만들었다고.
그 결과물이 보여주는 건 단순하지 않다. Spinbutton 하나를 제대로 구현하려면 키보드 인터랙션만 해도 Up/Down Arrow의 step 증감, Home/End의 min/max 점프, Apple 키보드에서 End 키가 없는 경우의 대체 단축키(Command + 방향키)까지 커버해야 한다. 여기에 NVDA의 Browse Mode와 Focus Mode 전환, VoiceOver의 VO 커서 진입 방식, iOS TalkBack의 제스처 네비게이션까지 더하면 — 이건 더 이상 "간단한 컴포넌트"가 아니다.
W3C APG(ARIA Authoring Practices Guide)가 제공하는 Spinbutton 패턴조차 페이지 상단에 경고를 붙여둔다. "이 코드는 프로덕션 환경을 위한 것이 아닙니다." APG는 성경이 아니라 출발점이다. 그런데 AI는 이 출발점을 그대로 복사해 완성품처럼 포장한다. "No ARIA is better than Bad ARIA"라는 접근성 필드의 오랜 경구가 AI 코드 생성 시대에 새로운 무게를 얻는 순간이다.
아키텍처 문제가 접근성 문제와 같은 뿌리에서 자란다
흥미롭게도, 이 패턴은 AI 에이전트 아키텍처 논쟁과 같은 구조를 공유한다. dev.to의 한 분석 글은 팀들이 챗봇을 에이전트라고 부르면서 발생하는 비용을 다룬다. 데모에서는 작동한다. 해피 패스에서는 완벽하다. 하지만 프로덕션에서 엣지 케이스가 터지면 — 멀티스텝 실패 복구, 세션 간 상태 유지, 도구 선택 추론 — 그제야 아키텍처가 틀렸다는 게 드러난다. 그리고 그 비용은 3~6개월의 리워크로 청구된다.
AI가 생성한 접근성 없는 UI 컴포넌트도 같은 패턴이다. 데모 단계에서는 아무도 스크린리더를 켜지 않는다. QA도 마우스로 클릭해보는 게 전부다. 접근성 문제는 조용히 쌓이다가 — ADA 소송장이 날아오거나, 접근성 감사 결과가 나오거나, 장애를 가진 실제 사용자가 구매를 포기할 때 — 비로소 가시화된다. 이미 수십 개의 컴포넌트가 같은 방식으로 만들어진 뒤에.
AI는 "틀리지 않았다"고 말한다. 그게 문제다.
오디오 합성 엔진을 직접 만든 개발자의 경험이 여기서 울림을 준다. 물리 모델링 코드에서 무언가 잘못된 느낌이 들어 AI에게 리뷰를 요청했더니 "코드가 맞아 보인다"는 답이 돌아왔다. 하지만 직접 파고들었더니 실제로 틀려 있었다 — 코드가 물리적으로 무엇을 모델링해야 하는지 이해하지 못하면 잡을 수 없는 방식으로. AI는 틀린 로직을 맞는 로직만큼 자신 있게 검증한다.
접근성도 똑같다. role="spinbutton"이 input에 붙어 있고, aria-valuenow와 aria-valuemin, aria-valuemax가 세팅되어 있으면 AI는 "접근성 구현이 되어 있다"고 판단한다. 하지만 NVDA Focus Mode에서 Up Arrow가 실제로 값을 바꾸는 이벤트 핸들러가 연결되어 있지 않으면? VoiceOver에서 스피너 진입을 위한 VO + Shift + Down Arrow 시퀀스가 처리되지 않으면? 코드는 맞아 보이지만, 스크린리더 사용자에게는 작동하지 않는다. 이 간극을 AI는 스스로 듣지 못한다.
접근성을 되찾는 자리는 생성 이후다
그렇다면 AI 워크플로우에서 접근성을 어떻게 되찾을 수 있을까. 핵심은 AI가 생성한 시점이 아니라 검증 단계에 접근성 레이어를 구조적으로 심는 것이다.
첫째, 컴포넌트 프롬프트에 접근성 요구사항을 명시적으로 포함시킨다. "수량 스피너 만들어줘"가 아니라 "NVDA Focus Mode와 VoiceOver에서 Up/Down Arrow로 값 변경이 가능하고, aria-valuenow가 실시간 업데이트되며, Home/End 키로 min/max 이동이 가능한 Spinbutton 패턴"으로 구체화하면 출력 품질이 달라진다. AI는 명시된 조건은 비교적 잘 충족한다 — 명시되지 않은 조건은 그냥 빠뜨린다.
둘째, 접근성 테스트를 PR 단계가 아닌 컴포넌트 완성 직후로 당긴다. axe-core나 jest-axe를 컴포넌트 단위 테스트에 붙이면 자동화 가능한 접근성 오류(color contrast, label 누락, role 오용 등)를 즉시 잡을 수 있다. 다만 키보드 플로우와 스크린리더 동작은 자동화 도구가 잡지 못하는 영역이다 — 여기는 개발자가 실제로 키보드와 스크린리더를 써보는 수밖에 없다.
셋째, W3C APG를 성경이 아닌 출발점으로 읽는 팀 컨벤션을 만든다. APG 패턴을 AI가 그대로 가져다 쓰면 "프로덕션 비권장" 경고도 함께 사라진다. 팀이 APG 패턴을 왜 그대로 쓰면 안 되는지 이해하고 있어야 AI 출력을 올바르게 수정할 수 있다.
속도와 품질 사이의 진짜 트레이드오프
AI가 프로토타이핑 속도를 높이는 건 사실이다. 빠른 실험과 검증이 중요한 초기 단계에서 AI 생성 컴포넌트는 강력한 도구다. 문제는 프로토타입 품질이 그대로 프로덕션으로 넘어갈 때 발생한다.
접근성은 나중에 붙이는 레이어가 아니다. Quantity Spinbutton 같은 핵심 전환 흐름에서 접근성이 깨지면 — e-커머스 기준으로는 장애를 가진 사용자가 장바구니에서 이탈하는 것이고, 법적으로는 ADA 소송의 빌미가 된다. 그리고 이 비용은 처음부터 제대로 만드는 비용보다 훨씬 크다.
AI가 코드를 빠르게 짤수록, 그 코드가 "작동한다"고 말하는 기준을 우리가 더 정밀하게 정의해야 한다. 마우스로 클릭했을 때 동작하는 것과, 키보드만으로 완전히 조작 가능하고 스크린리더가 의미 있는 피드백을 주는 것은 다른 기준이다. AI는 우리가 물어본 것만 만든다. 접근성을 물어보지 않으면, 접근성은 조용히 빠진다.