접근성 검사를 통과하기 위해 작성한 ARIA 마크업은 사실 AI 엔진에도 가장 명확한 소스가 됩니다. 스크린 리더와 AI 에이전트가 웹페이지를 읽는 방식은 거의 같습니다. 정교하게 꾸민 화면을 보는 대신 HTML을 태그, 계층, 이름으로 구성된 구조 트리로 해석합니다. 접근성을 한 번 제대로 설정하면 시각장애인의 이용을 지원하는 동시에 ChatGPT, Perplexity, Claude 같은 엔진이 콘텐츠를 정확히 추출하고 인용하도록 만들 수 있습니다. GEO에서 자주 언급되지만 실제 구현 단계에서는 흔히 빠지는 부분입니다.
스크린 리더와 AI 에이전트는 같은 트리를 읽습니다
일반 브라우저는 CSS, 이미지, 애니메이션을 조합해 사람이 보는 화면을 만듭니다. 스크린 리더의 작동 방식은 다릅니다. 브라우저가 생성한 접근성 트리를 읽고 “여기는 내비게이션 영역입니다”, “여기는 본문입니다”, “이것은 ‘장바구니에 담기’ 버튼입니다”처럼 페이지를 계층별로 설명합니다. AI 엔진의 크롤러는 이보다 더 단순하게 작동합니다. 대부분 JavaScript를 실행하지 않고 원본 HTML을 직접 가져온 뒤 태그, 제목 계층, 링크 텍스트, aria 속성을 일반 텍스트로 추출해 모델에 전달합니다. 두 방식의 공통점은 분명합니다. 화면의 시각적 단서는 읽지 못하고 구조와 텍스트만 읽습니다.
따라서 <div>에 클릭 이벤트만 붙여 만든 가짜 버튼, alt가 없는 제품 이미지, 글자 크기와 굵기만 키워 제목처럼 보이게 만든 문단은 사람의 눈에는 문제가 없어 보여도 두 유형의 리더에게는 빈칸과 같습니다. 콘텐츠가 아무리 좋아도 추출 단계에서 구조가 무너지면 AI는 의미를 추측하거나 해당 페이지를 아예 건너뛸 수밖에 없습니다.
먼저 네이티브 시맨틱 HTML로 기반을 다집니다
ARIA라고 하면 많은 팀이 role과 aria- 속성을 잔뜩 추가하는 것부터 떠올립니다. 하지만 순서는 반대입니다. W3C 접근성 작성 지침의 첫 번째 원칙은 명확합니다. 네이티브 HTML 요소로 의미를 표현할 수 있다면 ARIA로 덮어쓰지 말아야 합니다. <button>은 본래 버튼이고, <nav>는 내비게이션이며, <h2>는 하위 제목입니다. 이러한 네이티브 태그에는 의미와 기본 키보드 동작이 이미 포함돼 있어 크롤러와 스크린 리더가 모두 인식할 수 있습니다. 별도의 대응표를 관리할 필요도 없습니다. ARIA는 빈틈을 메우는 수단이지 기반 자체가 아닙니다.
한 번 설정해 양쪽 모두에 효과를 내는 네 가지 요소
엔지니어링 리소스는 다음 네 가지에 우선 투입하는 것이 효과적입니다. 접근성 감사에서 반드시 확인하는 항목이자 AI가 콘텐츠를 추출할 때 가장 크게 의존하는 신호입니다.
- 랜드마크 구조: <header>, <nav>, <main>, <aside>, <footer>로 페이지의 골격을 표시합니다. AI 크롤러는 이 랜드마크를 기준으로 본문과 내비게이션·푸터 템플릿을 구분합니다. 그래야 메뉴 문구를 답변에 섞지 않고 실제 콘텐츠만 인용할 수 있습니다.
- 제목 계층: 페이지마다 <h1>은 하나만 사용하고, 그 아래에서는 <h2>, <h3> 단계를 건너뛰지 않습니다. 이 제목 트리는 AI가 글의 개요를 파악하는 목차이자 스크린 리더 사용자가 원하는 구간으로 빠르게 이동하는 기준입니다.
- 이미지 대체 텍스트: 의미 있는 이미지는 alt로 내용을 설명하고, 장식용 이미지는 무시할 수 있도록 alt 값을 비워 둡니다. 특히 인포그래픽의 핵심 내용은 alt나 인접한 텍스트에 적어야 합니다. 그렇지 않으면 그래픽에 담긴 숫자는 기계가 인식할 수 없습니다.
- 조작 요소의 이름: 모든 버튼과 링크에는 읽을 수 있는 이름이 있어야 합니다. 아이콘만 있는 버튼에는 aria-label로 텍스트를 제공해 AI 에이전트가 해당 아이콘의 기능을 알 수 있게 합니다.
아이콘 버튼과 링크: 가장 흔한 빈칸
고객사의 기술 감사를 진행할 때 가장 자주 발견하는 문제는 그래픽으로만 구성된 요소입니다. 햄버거 메뉴, 장바구니, 검색 아이콘, 소셜 공유 버튼은 텍스트 없이 SVG를 <div>로 감싼 형태인 경우가 많습니다. 이때 스크린 리더는 그저 “버튼”이라고 읽거나 아무 말도 하지 않습니다. AI 에이전트에도 이름 없이 클릭만 가능한 객체로 보입니다. 한 이커머스 고객사의 결제 버튼도 이런 상태였습니다. 에이전트 테스트 도구는 결제 진입점을 전혀 찾지 못했습니다. aria-label을 추가해 “결제”라는 이름을 지정하자 시각장애인과 자동화 에이전트 모두 같은 버튼을 식별할 수 있었습니다. 링크도 마찬가지입니다. “자세히 보기”, “여기를 클릭” 같은 문구만 반복하면 시각적 맥락에서 분리되는 순간 목적지를 알 수 없습니다. 링크마다 그 자체로 의미가 통하는 구체적인 텍스트를 제공하면 한 번의 설정으로 양쪽 문제를 해결할 수 있습니다.
동적 요소: AI 에이전트가 현재 가능한 동작을 알게 합니다
AI 에이전트는 정적 콘텐츠를 읽는 데 그치지 않고 메뉴 펼치기, 페이지 전환, 양식 제출 같은 실제 작업까지 점점 더 많이 수행합니다. 이때는 요소의 이름만으로 부족하며 현재 상태도 제공해야 합니다. ARIA의 상태 속성은 “이 구성요소가 지금 열려 있는지 닫혀 있는지, 어떤 항목이 선택됐는지”를 기계가 읽을 수 있는 방식으로 전달합니다. 이를 바탕으로 에이전트는 다음 행동을 결정하고 이전 단계가 제대로 반영됐는지도 확인할 수 있습니다.
- aria-expanded: 접이식 메뉴, 아코디언, 드롭다운 메뉴가 열려 있는지 닫혀 있는지를 나타냅니다. 에이전트는 이 값을 보고 먼저 클릭해야 하는지 판단합니다.
- aria-current: 페이지네이션이나 브레드크럼에서 현재 위치를 표시해 에이전트가 같은 계층을 반복해서 맴돌지 않도록 합니다.
- aria-selected와 aria-checked: 페이지, 옵션, 체크박스의 선택 상태를 나타내 에이전트가 작업이 적용됐는지 확인할 수 있게 합니다.
- aria-live: 양식 오류나 로딩 결과처럼 실시간으로 갱신되는 영역을 라이브 리전으로 표시해 에이전트와 스크린 리더가 화면의 변화를 인지하도록 합니다.
검증: “화면상 문제없다”는 판단을 믿지 마세요
- curl이나 브라우저의 “페이지 소스 보기” 기능으로 서버가 실제로 반환하는 HTML을 확인합니다. 콘텐츠가 JavaScript 실행 후에야 나타난다면 대부분의 AI 크롤러는 읽을 수 없습니다.
- ax DevTools나 Lighthouse의 접근성 검사를 실행해 이름 누락, 대비 부족, 제목 단계 건너뛰기 같은 문제를 찾습니다.
- 스크린 리더도 직접 실행해 봅니다. Mac에서는 VoiceOver, Windows에서는 NVDA를 켜고 키보드만으로 페이지를 이동하며 실제로 어떻게 읽히는지 들어보세요.
- isitagentready 같은 에이전트 대응 점검 도구로 AI 에이전트가 핵심 구성요소를 인식하고 조작할 수 있는지 시뮬레이션합니다.
접근성은 별도의 규정 준수 비용만을 의미하지 않습니다. 시각장애인을 위해 적용한 모든 시맨틱 태그는 AI 에이전트도 다시 읽습니다. 한 번의 엔지니어링 투자로 두 가지 가치를 동시에 얻을 수 있는 드문 영역입니다.— Tenten GEO Technical Audit
ARIA와 시맨틱 마크업이 검색 순위를 직접 끌어올리지는 않습니다. 하지만 AI 엔진이 콘텐츠를 명확히 이해하고 추출해 인용할 수 있는지를 좌우합니다. 이것이 GEO의 기반입니다. AI 에이전트의 눈에 웹사이트가 어떻게 보이는지, 어떤 핵심 구성요소가 실제로 빈칸으로 인식되는지 확신하기 어렵다면 30분 GEO 진단을 예약해 보세요. 실제 점검을 통해 개선이 필요한 지점을 보여드립니다.
