4.5:1을 통과했는데 왜 안 읽힐까

컬러 대비 검사를 통과했는데 사용자가 텍스트를 못 읽겠다고 한다. WCAG 2.x의 4.5:1 비율을 충실히 지켰는데도. 디자인 시스템을 운영해본 사람이라면 이 상황이 낯설지 않을 것이다. 문제는 우리가 아니라 공식 자체에 있다.

#4.5:1이 무시하는 변수들

WCAG 2.x의 대비 공식은 전경색과 배경색의 상대 휘도를 비교해서 단일 비율을 뽑는다. 거기서 끝이다. 폰트 크기? 반영 안 함. 굵기? 마찬가지. 밝은 배경 위 어두운 글자와 어두운 배경 위 밝은 글자의 인지 차이? 역시 무시된다.

흰 배경에 파란 텍스트(#0000FF)와 노란 배경에 흰 텍스트가 동일한 대비 비율을 가질 수 있다. 실제 가독성은 완전히 다른데 말이다. 16px 본문과 72px 헤딩이 같은 기준을 충족해야 한다는 것도 직관에 맞지 않는다. 다들 알고 있었지만 대안이 없었다.

#APCA는 뭘 다르게 하나

APCA(Advanced Perceptual Contrast Algorithm)는 WCAG 3.0 워킹 드래프트에서 제안된 새로운 대비 측정 방식이다. 기존 공식과 결정적으로 갈라지는 지점이 세 가지 있다.

방향성 반영. 밝은 배경 위 어두운 텍스트와 그 반대는 같은 가독성을 제공하지 않는다. WCAG 2.x에서는 두 경우의 비율이 동일하게 나오지만, APCA는 Lc(Lightness contrast) 값을 양수와 음수로 구분해서 이 비대칭을 잡아낸다. 다크 모드 팔레트를 설계해본 사람이라면 이게 얼마나 큰 차이인지 체감할 것이다. 라이트 모드에서 잘 보이던 보조 텍스트 색상이 다크 모드에서 갑자기 읽기 힘들어지는 현상 — 기존 공식으로는 둘 다 "통과"였다.

폰트 사이즈와 웨이트가 변수로 진입. APCA는 "이 Lc 값에서 가독성을 확보하려면 최소 몇 px에 몇 weight여야 한다"를 구체적으로 명시한다. 16px regular 본문이라면 Lc 75 이상이 필요하고, 48px bold 헤딩은 Lc 45면 충분하다. 대비 기준이 타이포그래피 맥락에 연동되면서, "대비 충분한가?"라는 질문이 "어디에 쓰이는 텍스트인가?"로 바뀐다.

인지 모델 기반 계산. 단순 휘도 비율 대신 인간 시각계의 명도 적응과 공간주파수 반응을 반영한 모델을 사용한다. 수식이 복잡해지는 대신, 실제 눈이 느끼는 가독성에 훨씬 가까운 결과를 낸다.

#컬러 토큰 구조가 흔들린다

대부분 디자인 시스템의 시맨틱 컬러 토큰은 이런 형태다:

--color-text-primary: #1A1A1A;
--color-text-secondary: #666666;
--color-bg-surface: #FFFFFF;

primary가 4.5:1을 넘기면 통과, 끝. 하지만 APCA 기준을 적용하면 이야기가 달라진다. 같은 #1A1A1A가 16px 본문에서는 Lc 75를 넘겨야 하면서 48px 타이틀에서는 Lc 45면 충분하다. 토큰 하나에 pass/fail 하나가 아니라, 용도에 따른 대비 스펙트럼이 생기는 셈이다.

이건 primary/secondary라는 추상화가 접근성 맥락에서 불충분하다는 뜻이기도 하다. 노르웨이 정부 디자인 시스템(Designsystemet)은 이미 APCA 기반 토큰 재설계를 진행 중인데, 토큰 이름에 용도를 명시하고 용도별로 대비 기준을 분리하는 접근을 취한다.

당장 시도해볼 수 있는 구조 변경:

같은 primary가 본문과 헤딩에서 다른 대비 기준을 요구한다면, 이름부터 용도를 반영하는 게 맞다. 이 구조가 잡혀 있으면 나중에 대비 값만 APCA 기준으로 교체하면 된다.

#전면 전환은 아직이다

2026년 4월 현재, WCAG 3.0은 워킹 드래프트 상태다. 법적 기준은 여전히 WCAG 2.1 AA이고, 한국의 KWCAG 2.1 인증 심사도 기존 비율 기준으로 진행된다. APCA 단독으로 갔다가 인증에서 걸리면 곤란하다.

현실적 접근은 이중 운영이다. 법적 컴플라이언스는 WCAG 2.x로 확보하되, 내부적으로 APCA Lc를 보조 지표로 추적한다. Figma 플러그인 중 APCA 대비를 측정하는 도구가 이미 있고, Style Dictionary 빌드 파이프라인에 검증을 붙이는 것도 크게 어렵지 않다. 토큰 구조를 용도 기반으로 세분화하는 작업은 어떤 기준을 쓰든 커뮤니케이션을 명확하게 만든다. 구조는 먼저 잡아두는 게 나중에 바꾸는 것보다 항상 쉽다.