발행 2026-06-12

웹 접근성은 AI 인용에 어떤 영향을 주나

스크린리더가 읽기 좋은 페이지는 AI도 읽기 좋습니다. 접근성은 규정 준수이기 전에 기계 가독성의 토대 — 시맨틱 HTML, 헤딩 위계, alt, 표 마크업은 사람의 보조기술과 AI 추출기를 동시에 섬기는 구조입니다. 그런데 대부분의 페이지는 그 토대에서부터 실패합니다. 상위 100만 홈페이지의 95.9%에서 WCAG 2 위반이 검출됐고[WebAIM Million, 2026], AI 크롤러는 화면이 아니라 마크업을 읽습니다[Vercel × MERJ, 2025].

AI 크롤러는 페이지를 어떻게 '읽는가'?

사람처럼 렌더링된 화면을 보는 게 아닙니다. 서버가 준 원본 HTML을 그대로 읽습니다. 주요 AI 크롤러는 JavaScript를 실행하지 않습니다. GPTBot 5억+ fetch 분석에서 JS 실행 증거가 하나도 나오지 않았습니다 — 단, Gemini는 Googlebot 인프라를 써서 렌더링할 수 있는 예외입니다(2025년 초 실측 기준)[Vercel × MERJ, 2025].

크롤러가 JS 파일을 받기는 합니다(ChatGPT 11.5%, Claude 23.8%). 받되 실행하지 않습니다. 즉 클라이언트에서 그려지는 콘텐츠는 이 독자들에게 보이지 않습니다. 게다가 원본 HTML은 그대로 처리하기엔 비대해서 — Common Crawl 표본의 29.3%가 32k 토큰을 넘습니다 — AI 파이프라인은 본문만 골라내는 전처리에 기댑니다[Dripper, 2025, 프리프린트]. 이 과정에서 무엇이 본문이고 무엇이 보일러플레이트인지 구분하는 단서가 바로 시맨틱 마크업으로 보입니다.

이 독서 방식, 어디서 들어본 것 같지 않나요. 스크린리더입니다.

접근성과 기계 가독성은 어디서 겹치나?

겹치는 건 '구조 계열'입니다. 시맨틱 HTML, 헤딩 위계, alt, 표 마크업 — 스크린리더가 페이지를 해석하는 신호가 곧 AI가 추출에 쓰는 신호입니다. 단, WCAG 전체가 겹치는 건 아닙니다. 색 대비나 키보드 조작 같은 항목은 AI 가독성과 무관합니다.

"LLM은 비시각적 사용자이고, WCAG를 지키면 기계 가독성이 오른다"는 업계 프레임이 있습니다(accessiBe, Siteimprove 등). 직관적이지만 이 글들은 전부 추론입니다 — 실측 데이터를 제시한 곳은 없었습니다. 견고한 건 그 아래 한 층입니다. <h2>·<table>·<nav> 같은 네이티브 요소로 의미가 표시된 페이지와, 의미 없는 <div> 더미로 쌓인 페이지는 파서가 보는 정보량이 다릅니다. 이 차이는 "가능하면 네이티브 HTML 요소를 써라"는 W3C 제1원칙이 뒷받침합니다[W3C ARIA in HTML, 2025].

"접근성 좋으면 AI에 인용된다"는 근거가 있나?

직접 인과 실측은 아직 없습니다. "접근성 점수를 올렸더니 AI 인용이 늘었다"는 A/B 실험도, 인용 점유율 추적도 어디에서도 찾지 못했습니다. 그러니 "접근성 = 인용 보장"은 사실이 아닙니다. 있는 건 메커니즘 근거와, 구조 개선이 가시성을 올린 인접 실험뿐입니다.

메커니즘은 이렇습니다. 같은 표라도 시맨틱 HTML 형식으로 주면 LLM이 더 정확히 이해합니다 — 구분자로 나눈 자연어 텍스트보다 +6.76%[Table Meets LLM, Microsoft, 2024]. 그리고 인용·통계·출처를 더해 구조와 명확도를 높이면 생성형 엔진 안에서 출처 가시성이 최대 ~40%까지 올랐습니다[Princeton GEO, 2024]. 둘 다 "형식이 이해와 인용에 영향을 준다"는 쪽을 가리킵니다.

정리하면, 접근성은 인용을 보장하지 않습니다. 다만 인용의 전제 조건 — AI가 페이지를 추출할 수 있는 구조 — 을 만듭니다. 측정 가능한 건 그 전제 조건이지 인용 횟수가 아닙니다.

헤딩·alt·표 — 무엇이 어떻게 추출을 좌우하나?

세 신호가 각각 다른 통로를 엽니다. 헤딩 위계는 패시지 추출의 목차이고, alt는 이미지 정보가 기계로 가는 유일한 텍스트 통로이며, 표 마크업은 데이터가 행·열 관계째 추출될지를 결정합니다. 그런데 현실의 웹은 이 셋 모두에서 무너져 있습니다.

헤딩부터 봅시다. 41.8%의 페이지가 헤딩 레벨을 건너뛰고(h2 다음 바로 h4), 18.1%는 h1이 여러 개, 7.5%는 헤딩 자체가 없습니다[WebAIM Million, 2026]. 위계가 망가지면 패시지의 경계도 흐려집니다. 이미지 쪽은 홈페이지 이미지의 16.2%(페이지당 평균 10.8개)가 alt 텍스트 없이 떠 있습니다[WebAIM Million, 2026]. 구글은 이미지를 이해할 때 alt 텍스트와 컴퓨터 비전, 주변 본문을 함께 쓰는데, 그중 내용을 명시적으로 전달하는 1차 신호가 alt입니다[Google Search Central, 2025]. 표는 더 심합니다. 관측된 948,225개 표 중 올바른 데이터 표 마크업(<th> 등)을 갖춘 건 19%뿐입니다[WebAIM Million, 2026].

(자동 검출 기준이라 실제 위반은 더 많을 수 있습니다.)

ARIA를 더 바르면 되나?

아닙니다. ARIA를 덧바르는 게 답이 아닙니다. W3C 제1원칙은 "네이티브 HTML로 가능하면 ARIA 대신 그것을 쓰라"입니다 — 잘못 쓴 ARIA는 오히려 구조를 해칩니다. "No ARIA is better than bad ARIA"[W3C ARIA in HTML, 2025].

데이터도 이 방향을 거듭니다. 페이지당 평균 ARIA 속성이 133개로 전년 대비 27% 늘었는데, ARIA를 쓰는 페이지가 오히려 오류가 더 많습니다(평균 59.1개 vs 42개)[WebAIM Million, 2026]. 단, 이건 상관이지 인과는 아닙니다 — 복잡한 페이지일수록 ARIA를 많이 쓰기 때문일 수도 있습니다. 그러니 교훈은 "ARIA를 더 쓰자"가 아니라 "네이티브 요소를 먼저 쓰자"입니다.

내 페이지의 접근성·인용가능성, 어떻게 점검하나?

위 구조 신호를 항목화해 사실값으로 확인하면 됩니다. 헤딩 위계가 이어지는지, 이미지에 alt가 있는지, 표가 데이터 표로 마크업됐는지 — 하나씩 셀 수 있는 값입니다. zupzup는 이 신호들을 8 카테고리 84 분석기로 진단하고, 표 접근성 같은 항목을 포함한 4축 점수로 무엇부터 고칠지 우선순위를 보여줍니다.

한국 웹의 현주소도 참고할 만합니다. 2024년 실태조사 기준 국내 평균 접근성은 66.7점으로, 2019년 53.7점부터 완만히 오르는 중입니다[과기정통부·NIA 실태조사, 2024]. 한국어 사이트는 표 접근성이나 언어 태그(BCP47) 같은 특화 휴리스틱이 따로 의미를 갖습니다.

zupzup는 검색 순위나 AI 인용 횟수를 추적하지 않습니다. 추적할 수 없으니까요. 대신 인용의 전제 조건이 되는 신호들을 사실값으로 진단합니다 — 측정 가능한 것만.

결론 / 다음 단계

접근성은 두 독자, 사람의 보조기술과 AI의 추출기를 동시에 섬기는 구조 투자입니다. 인용을 보장해 주지는 않습니다. 하지만 전제는 분명합니다 — AI가 추출할 수 없는 구조라면, 인용은 시작도 못 합니다. 그리고 그 전제 조건은 측정 가능합니다.

내 페이지가 그 전제를 통과하는지부터 확인해 보세요. zupzup로 접근성·인용가능성을 진단해 보면 됩니다.