AI가 만든 UI, 기본값은 '접근 불가'다

프런트엔드 개발자 Durgesh Pawar가 AI 코드 생성 도구의 불편한 진실을 해부했습니다. LLM에게 사이드바 내비게이션을 요청하면 몇 초 만에 그럴듯한 React 컴포넌트가 나오지만, 그 안을 들여다보면 <nav> 랜드마크가 없고 'Settings'는 제목이 아닌 스타일만 입힌 <div>이며, 목록은 <ul>·<li>가 아니고, 클릭 요소는 <button>이 아니라 <div onClick>인 경우가 흔하다는 것입니다. 화면에는 멀쩡히 보여도, 스크린 리더가 실제로 읽는 접근성 트리에는 아무 의미도 남지 않습니다.

"CSS는 <div>를 버튼처럼 '보이게' 만들 수 있지만, 그것을 실제 버튼으로 '만드는' 것은 오직 HTML 시맨틱뿐이다."Durgesh Pawar, Frontend Masters

왜 중요한가

모델이 접근성을 빠뜨리는 건 우연이 아니라 구조적입니다. LLM은 시각적 결과물에 최적화돼 있고, 학습 데이터에서 시맨틱 HTML은 과소 대표되며, 평가는 '보기에 그럴듯한가'에 쏠려 있고, 토큰 경제학은 더 짧은 코드를 선호합니다. 대가는 비용으로도 드러납니다 — 생성 단계에서 접근성 제약을 넣으면 컴포넌트당 3~8분이면 되지만, 배포 후에 찾아 고치면 45~90분이 든다고 저자는 말합니다.

실무 적용

해법은 '사람이 나중에 검수'가 아니라 파이프라인으로 시맨틱을 강제하는 5겹 방어입니다. ① 프롬프트 제약, ② 정적 분석(ESLint), ③ 런타임 테스트(axe-core), ④ CI 통합, ⑤ 접근성이 내장된 컴포넌트 추상화(Radix·Headless UI)를 겹겹이 쌓으세요. 다만 자동 도구가 잡아내는 건 실제 문제의 70~85%뿐이므로, 보조기술로 직접 만져보는 수동 테스트는 끝까지 남겨둬야 합니다.

교차 참고

• Smashing Magazine: Why Accessibility Is An Operational Capability, Not A Feature — 접근성이 '기능'이 아니라 팀의 운영 성숙도임을 함께 봅니다.
• Smashing Magazine: How To Make Your Design System AI-Ready — AI가 올바른 컴포넌트를 뽑도록 디자인 시스템을 준비하는 관점을 보완합니다.

Wemeet의 관점

Wemeet은 AI가 만든 화면일수록 '보이는 것'과 '읽히는 것'의 간극을 먼저 의심해야 한다고 봅니다. 접근성은 출시 직전의 영웅적 스프린트가 아니라 시스템에서 나옵니다 — 사람이 감당할 수 없는 속도로 코드가 쏟아지는 시대라면, 시맨틱을 강제하는 장치를 파이프라인에 심어두는 편이 유일하게 지속 가능한 길입니다.