'소프트 코랄 텍스트, 따뜻한 크림 배경.' 스크린샷으로는 완벽한 팔레트였다. 그런데 누군가 "햇빛 아래 폰으로는 제목이 안 읽힌다"고 말했다. dev.to에 공유된 한 개발자의 고백이다. 대비율을 재봤더니 2.1:1. WCAG AA 기준인 4.5:1의 절반도 안 됐다.
색상 대비 실패는 '예쁜 디자인의 작은 실수'가 아니다. 저시력 사용자, 야외에서 화면을 보는 사람, 화면 밝기를 줄인 다크모드 사용자 모두가 배제된다. WCAG가 정해둔 기준은 단순하다. 일반 본문 텍스트는 4.5:1, 24px 이상 대형 텍스트는 3:1, 더 엄격한 AAA 기준은 7:1이다. 흑백 조합이 21:1인 것을 생각하면, 우리가 '예쁘다'고 선택하는 중간 톤 색상들이 얼마나 위험한 구간에 있는지 실감된다.
확인 방법은 30초면 충분하다. Chrome DevTools에서 텍스트 요소를 inspect하고 Styles 패널의 색상 스워치를 클릭하면 대비율과 AA/AAA 배지가 바로 표시된다. 별도 툴 설치도 없고 플러그인도 필요 없다. 이미 내 개발 환경 안에 있던 기능이다.
더 중요한 건 워크플로우다. 대비 검사를 마지막에 돌리는 게 아니라, 팔레트를 고를 때 각 색상의 역할을 먼저 배정하는 것이다. 가장 밝은 색은 배경, 가장 어두운 색은 텍스트, 선명한 중간 톤은 버튼·배지·일러스트레이션—절대 본문에는 쓰지 않는다. 이 단순한 역할 분리만으로도 접근성 위반의 상당수를 사전에 막을 수 있다.
그런데 이쯤에서 다른 이야기를 꺼내야겠다. 같은 날 dev.to에서 눈에 띈 또 다른 글—PR 리뷰용 Chrome 확장을 6주째 매일 쓰고 있다는 개발자의 회고록이었다. 이 사람이 꼽은 '다시 만든다면 바꿀 결정 2위'가 흥미로웠다. "나는 누군가 원한다는 걸 확인하기도 전에 AI 기능을 먼저 만들었다."
CI 상태 + 나이(age) 기반 정렬만으로 이미 문제의 80%가 해결됐다. AI 리스크 점수 레이어는 인증 코드를 건드리는 조용한 PR처럼 결정적 신호를 놓칠 때 진짜 빛났지만, 대부분의 사용자는 API 키를 설정하지 않았다. 지원 메일에 쌓인 요청은 다중 계정 지원, 스테일 PR 알림, CSV 내보내기—모두 AI와 무관한 기능들이었다.
두 이야기는 표면상 다르지만 같은 구조를 가리킨다. '멋있어 보이는 것'을 먼저 만들고, '실제로 작동하는지'는 나중에 확인한다. 색상 팔레트에서는 시각적으로 아름다운 조합이 우선이고, 프로덕트 빌드에서는 AI 기능이 우선이다. 그 결과는 비슷하다—어떤 사용자는 화면을 읽지 못하고, 어떤 사용자는 정작 필요한 기능을 찾지 못한다.
접근성을 '나중에 체크하는 항목'으로 대하는 한, 이 패턴은 반복된다. WCAG 대비율 계산은 수학이다. 감각의 문제가 아니라 측정의 문제다. DevTools 안에 이미 있고, 팔레트 도구 PaletteCSS처럼 컬러 선택 단계에 내장할 수도 있다. 핑계가 없다는 뜻이다.
AI 기능이 나쁜 게 아니다. 문제는 순서다. Chrome 확장 개발자가 내린 결론처럼—"결정론적 버전을 먼저 배포하고, 사용자가 AI를 원한다고 말하면 그때 만들어라." 접근성도 마찬가지다. 색상 역할을 배정하고 대비를 확인하는 것, 그것이 UI가 실제로 '작동하는' 상태의 최소 조건이다. 그 위에 AI 요약이든 스마트 정렬이든 올려야 의미가 있다.
앞으로 AI 도구는 더 빠르게 화면을 생성할 것이다. v0.dev에 프롬프트 한 줄 던지면 컴포넌트가 뚝딱 나오는 시대다. 그런데 생성 속도가 올라갈수록 접근성 검증이 워크플로우에서 밀려날 위험도 커진다. 아무도 명시적으로 요청하지 않으면 AI는 '예쁜' 색상을 고를 뿐, '읽을 수 있는' 색상을 고르지 않는다. 검사 기준을 프롬프트에 심거나, CI 파이프라인에 Lighthouse 접근성 감사를 붙이거나, 디자인 토큰 단계에서 대비를 고정하는 것—이 작업은 여전히 개발자의 설계 의도에서 시작된다.
디자인이 완성되는 순간은 '보기 좋을 때'가 아니다. 모든 사람이 읽을 수 있을 때다. AI 기능은 그 다음이다.