Lighthouse 에이전트 브라우징 실측: 2/2인데 키보드로 못 누르는 버튼

얼마 전 「AI 기반 접근성 표준 확산」이라는 트렌드 요약을 받았습니다. 첫 줄이 "W3C의 ARIA-AI Framework 논의 진행 중."이었는데, 찾아보니 그런 표준은 없었어요. 이 이름이 나오는 곳은 W3C 링크 하나 없는 자동 생성형 글뿐이었습니다.

그래도 AI와 접근성이 붙은 건 사실입니다. 표준이 아니라 도구 쪽에서요. OpenAI는 AI 브라우저 ChatGPT Atlas의 개발자 FAQ에 "웹사이트의 접근성을 높이면 Atlas의 ChatGPT 에이전트가 사이트를 더 잘 이해할 수 있습니다"라고 적었습니다(영어 원문 "Making your website more accessible helps ChatGPT Agent in Atlas understand it better.").

구글은 2026년 5월 Lighthouse(라이트하우스, 크롬 개발자 도구와 PageSpeed Insights에 들어 있는 점검 도구)에 에이전트 브라우징(Agentic Browsing) 카테고리를 넣었습니다. 한국어 화면에는 '에이전트형 브라우징'으로 나오고, 사이트가 AI 에이전트(사람 대신 웹을 읽고 누르는 AI 프로그램)를 맞을 준비가 됐는지 봅니다.

그럼 에이전트 브라우징을 통과한 페이지는 접근성도 괜찮을까요? 정상 페이지 하나와 결함 페이지 7개를 만들어 Lighthouse 13.5.0으로 재 봤습니다. 키보드로는 누를 수 없는 div 버튼이 접근성 점수 100점과 에이전트 브라우징 2/2를 함께 받았어요. 2/2는 그 페이지에서 채점된 항목 두 개를 모두 통과했다는 뜻입니다. 같은 페이지를 AI 에이전트용 브라우저 도구 두 가지로 찍어 보니 받는 모습도 서로 달랐고요. 결과부터 보려면 실측 결과로 가셔도 됩니다.

W3C ARIA-AI 프레임워크는 없습니다: AI 접근성 표준은 지금 어디까지

결론부터 말하면 W3C(웹 표준을 만드는 국제 기구)에는 ARIA-AI라는 표준도, 그런 이름의 논의도 없습니다. ARIA는 role·aria-label처럼 HTML 요소에 역할과 이름을 덧붙여 스크린 리더 같은 보조기술에 알려 주는 W3C 표준인데, 이를 만드는 ARIA 작업 그룹의 헌장(2024년 12월부터 2027년 1월까지)에도, AI와 개인화 연구를 맡은 APA 작업 그룹의 헌장(2025년 7월부터 2027년 7월까지)에도 그런 산출물이 없어요. 헌장은 그 기간에 만들겠다고 약속한 문서 목록이라, 여기에 없으면 공식 작업이 아닙니다.

W3C의 AI 관련 문서는 AI가 대체 텍스트·자막·평가 도구에 주는 영향을 정리한 비규범 편집자 초안(2026년 3월 28일)이고, 8월 회의록을 보면 아직 목차를 다시 짜는 중입니다. AI와 ARIA를 두고 오간 논의는 있습니다. 2025년 TPAC(W3C 연례 총회)에서 바로 그 Atlas 문서를 놓고 ARIA가 에이전트에게 맞는 도구인지 묻는 세션이 열렸고, ARIA 작업 그룹도 2026년 7월 회의에서 에이전트를 위해 ARIA를 쓰는 위험을 짚었어요. 표준이 나온 건 아닙니다.

표준 소식을 들으면 문서 맨 위의 성숙도부터 보세요. 편집자 초안에서 작업 초안(WD), 후보 권고안(CR), 제안 권고안(PR), 권고안(REC)으로 갈수록 무게가 붙습니다. Note는 처음부터 규범이 아니고, 커뮤니티 그룹(CG) 보고서는 표준 트랙 밖이에요.

표준이 아직 목차를 고치는 동안, 도구 쪽은 벌써 채점을 시작했습니다.

AI 에이전트는 접근성 트리로도 웹을 읽습니다

시각장애인 등이 쓰는 스크린 리더는 화면을 눈으로 보지 않습니다. 브라우저에게 페이지에 뭐가 있는지 묻고 "버튼, 장바구니 담기" 같은 답을 받아 읽어 줘요. 브라우저가 요소마다 역할과 이름(접근 가능한 이름)을 붙여 정리해 둔 이 구조가 접근성 트리입니다. 여기에 버튼이 없거나 이름이 엉뚱하면, 스크린 리더 사용자는 장바구니 버튼을 찾지 못하거나 무슨 버튼인지 알 수 없어요.

AI 에이전트 가운데 상당수도 이 트리를 씁니다. 화면 픽셀만 보는 에이전트도 있지만(OpenAI의 CUA, 구글 Gemini의 Computer Use), 정리된 목록을 받는 쪽이 빠르고 결과가 일정하거든요. AI 모델이 브라우저 자동화 도구 Playwright를 쓰게 해 주는 MCP 서버(AI에 외부 도구를 붙이는 연결 규격), Playwright MCP도 기본으로 스크린샷 대신 접근성 스냅샷을 건넵니다. 이 글의 기준 페이지를 그 방식으로 찍으면 상품 카드는 이렇게 나와요.

- article [ref=e8]:
  - img "하늘색 머그컵. 손잡이가 오른쪽에 있고 김이 오른다" [ref=e9]
  - generic [ref=e10]:
    - heading "하늘색 머그컵" [level=2] [ref=e11]
    - paragraph [ref=e12]: 12,000원
    - paragraph [ref=e13]: 350ml · 전자레인지 사용 가능
    - button "장바구니 담기" [ref=e14] [cursor=pointer]
    - status [ref=e15]

[ref=e14]는 에이전트가 누를 때 쓰는 번호표, [cursor=pointer]는 마우스 커서가 손가락 모양이 되는 요소라는 표시예요. 테스트 코드에서 쓰는 Playwright 기본 스냅샷에는 이 둘이 없는데, 이런 차이는 실측에서 다시 보여 드릴게요.

OpenAI FAQ는 Atlas가 스크린 리더와 같은 ARIA 레이블과 역할(FAQ 표현으로는 'ARIA 태그')로 페이지를 파악한다며 WAI-ARIA 권장사항을 따르라고 권합니다. 사이트들이 접근성을 챙길 계기는 되겠지만, 그 이유로 장애인 사용자 대신 봇을 내세웠다는 점은 걱정돼요.

접근성 컨설턴트 Adrian Roselli는 ARIA를 봇 안내용 메타데이터로 다룬다고 비판했고, ARIA in HTML 명세의 편집자였던 Steve Faulkner는 네이티브 HTML 이야기가 빠졌다고 짚었습니다. 인기 홈페이지 100만 곳을 해마다 검사하는 WebAIM Million 2026에서 ARIA를 쓴 홈페이지의 평균 오류(59.1개)가 안 쓴 홈페이지(42개)보다 많았던 것도 같은 걱정을 키웁니다. 상관관계일 뿐이지만, "ARIA를 붙이세요"가 퍼지면 잘못 붙은 ARIA도 늘기 쉽거든요.

그럼 구글의 점검은 무엇을 볼까요?

Lighthouse 에이전트 브라우징(Agentic Browsing)은 무엇을 검사하나

에이전트 브라우징은 Lighthouse 13.3.0(2026년 5월 7일)부터 기본 카테고리이고, 크롬 150 개발자 도구와 PageSpeed Insights에서 볼 수 있습니다(PageSpeed Insights에서는 다섯 번째 점수, 2026년 10월 2일 확인). 최신 13.5.0의 감사(점검 항목)는 7개예요.

표의 아래쪽 세 감사가 보는 것은 대부분의 사이트에 아직 없어서, 없는 주소에 404를 제대로 주는 보통 사이트라면 접근성 트리 감사와 CLS 두 문항만 남습니다. 이번에 잰 국내 홈페이지 10곳 중 6곳이 그랬어요. 나머지 셋은 이름만 알아 두면 됩니다. WebMCP는 웹페이지가 자바스크립트 함수를 에이전트가 부를 수 있는 기능으로 내놓는 API(W3C 커뮤니티 그룹 초안)예요. llms.txt는 LLM이 사이트를 이해하도록 안내를 마크다운으로 적어 두자는 제안 파일(llms.txt 정리 글이고, ai-catalog.json은 구글이 2026년 6월 발표한 ARD(Agentic Resource Discovery) 사양에서 에이전트가 사이트의 리소스를 찾도록 내놓는 목록 파일입니다.

점수는 '2/2'처럼 분수로 나옵니다. 앞이 통과한 항목 수, 뒤가 채점된 항목 수예요. 실제 리포트에서는 이렇게 보입니다.

구글은 에이전트 웹의 기준이 아직 만들어지는 중이라 순위보다 데이터와 신호를 주는 게 목적이라고 밝혔어요. 접근성 트리 감사는 기계 조작에 중요한 접근성 감사만 추린 것이니, 접근성 전반은 접근성 감사 문서를 보고 트리는 시맨틱 HTML과 올바른 ARIA 레이블을 우선해 만들라고도 적었고요.

2/2, 3/3, 1/4: 분수 읽는 법

분수의 규칙은 두 줄이면 됩니다.

• 분모: 감사 7개 중 '해당 없음'으로 빠지지 않고 채점된 감사의 수
• 분자: 그중 통과한 감사의 수

어떤 감사가 채점되는지는 사이트가 정합니다. 접근성 트리 감사와 CLS는 언제나 채점되니 분모는 적어도 2예요. 나머지는 조건이 맞을 때만 분모에 하나씩 더해집니다.

• llms.txt: /llms.txt를 요청했을 때 404 같은 4xx가 아니면 채점합니다. 통과 조건은 H1 제목(# 이름), [이름](주소) 형태의 링크 하나 이상, 50자 이상 세 가지예요.
• ai-catalog.json: /.well-known/ai-catalog.json도 4xx가 아니면 채점하고, ARD 형식에 맞아야 통과합니다.
• WebMCP 3개: 브라우저가 WebMCP를 지원하고 페이지에 폼이나 등록된 도구가 있을 때 채점합니다.

CLS는 '좋음' 기준인 0.1 이하일 때 통과로 칩니다(Lighthouse 13.5.0 소스로 확인). 뒤에서 다룰 실측 결과에 이 규칙을 대 보면 이렇습니다.

표에서 읽어 낼 것은 세 가지예요.

1. 같은 1/2라도 실패한 곳이 다릅니다. 네이버는 CLS, 국세청은 트리 감사에서 걸렸어요. 분수만 보지 말고 리포트에서 실패 항목을 펼쳐 보세요.
2. 분모가 다르면 분수끼리 비교할 수 없습니다. 3/3이 2/2보다 낫다는 뜻이 아니에요. 채점된 감사가 하나 더 있었을 뿐입니다.
3. 파일을 만들면 분모가 늘어납니다. llms.txt를 두면 채점 항목이 하나 늘고, 형식이 틀리면 실패도 하나 늘어요. 서울특별시와 11번가는 그런 파일을 만든 적도 없는데 분모가 늘었습니다. 이유는 뒤의 소프트 404 절에서 다룹니다.

접근성 트리 감사는 axe 규칙 33개를 봅니다

접근성 트리 감사(아래부터 트리 감사)의 규칙 목록은 구글 문서에 없어서 Lighthouse 소스를 열어 봤습니다. agent-accessibility-tree.js에 axe-core(Lighthouse 접근성 카테고리가 쓰는 자동 검사 엔진) 규칙 33개가 있고, 하나라도 걸리면 실패입니다(13.2.0부터 13.5.0까지 같음). 리포트에 '접근성 트리가 올바르게 구성되지 않음'(영어 화면 'Accessibility tree is not well-formed')이 떴다면 이 중 하나에 걸린 거예요.

제 기준으로 나누면 14개는 버튼·링크·입력창·이미지 버튼·ARIA 위젯·문서 제목 등에 이름이 있는지, 14개는 없는 역할·빠진 필수 속성·aria-hidden 안의 포커스 요소 같은 ARIA 문법, 나머지 5개는 tabindex·autocomplete 같은 구조 규칙입니다.

빠진 쪽에는 명도 대비(color-contrast), 일반 이미지의 대체 텍스트(image-alt), 문서 언어(html-has-lang)가 있어요(이미지 버튼과 SVG 이미지의 대체 텍스트는 봅니다). 에이전트만 놓고 보면 이해되는 선택이지만, 셋 다 사람에게 흔한 장벽입니다. 흐린 글자는 저시력 사용자가, 대체 텍스트 없는 사진은 스크린 리더 사용자가 놓치고, 문서 언어가 없으면 스크린 리더가 발음을 정하지 못하죠. WebAIM Million 2026 6대 오류에 셋 다 들고, 둘은 1·2위입니다.

정리하면 트리 감사는 "누를 수 있는 것에 이름이 있고 ARIA 문법이 맞는가"를 보고, "사람의 눈과 귀에 제대로 전달되는가"는 접근성 카테고리에 맡깁니다. 소스로 읽은 결론은 아직 추측이라, 직접 재 봤습니다.

접근성 결함을 넣은 테스트 페이지 7개로 실측

실험 페이지는 머그컵 하나를 파는 작은 쇼핑 화면입니다(메뉴, 검색창, 상품 카드, '장바구니 담기' 버튼). 시맨틱 HTML로 만든 기준 페이지(01)에서 결함 페이지 7개를 만들었어요. 02는 대체 텍스트·대비·lang 세 곳을 묶었고, 06은 버튼과 메뉴 링크 두 개를 함께 바꿨고, 나머지는 한 곳씩만 바꿨습니다.

결함은 일부러 골랐습니다. 33개 목록 밖의 결함 넷(02·03·05·06)과 목록 안의 결함 셋(04·07·08)을 넣어, 소스에서 읽은 대로 판정되는지 확인하는 설계예요. 목록 밖 결함은 WebAIM 상위 오류(02), 자동 검사가 원래 못 잡는 div 버튼(03), 'AI를 위해 ARIA를 붙이라'는 조언이 퍼질 때 늘기 쉬운 실수(05·06)에서 골랐습니다. 그러니 '7개 중 몇 개'는 이 선택이 정한 숫자이지 검출률이 아닙니다.

재는 방법은 넷입니다.

1. Lighthouse 13.5.0: 접근성·에이전트 브라우징 카테고리, 데스크톱 설정
2. 역할·이름 조회: Playwright role 기반 쿼리(getByRole, 이름은 부분 일치)로 장바구니 버튼과 검색창 찾기. 이름으로 요소를 찾는 자동화·음성 제어와 닮은 방식이고, LLM 에이전트에게 과업을 시킨 건 아닙니다
3. 키보드 조회: Tab으로 장바구니 버튼까지 가서 Enter. 키보드나 키보드처럼 동작하는 스위치로 조작하는 사람의 길을 스크립트로 흉내 냈습니다
4. 도구별 스냅샷 비교: 에이전트용 MCP 서버 두 가지(Playwright MCP, 구글의 Chrome DevTools MCP)가 건네는 스냅샷을 크롬 접근성 트리(보조기술이 받는 쪽)와 나란히. 이 둘은 측정 스크립트가 아니라 제가 직접 찍고 눌러 봤습니다

크롬 154, Playwright 1.63으로 2026년 10월 2일에 쟀고, 스크린 리더로 직접 듣지는 않았습니다.

실측 결과: 트리 감사가 안 보는 결함 넷은 모두 2/2를 받았습니다

2/2는 채점된 두 문항(트리 감사·CLS)을 모두 통과했다는 뜻이고, 이 표의 1/2는 모두 트리 감사(axe 규칙 33개 중 하나라도 걸리면 실패)에서 떨어진 경우입니다. 오른쪽 두 열은 키보드 조회와 역할·이름 조회 결과예요.

트리 감사에서 떨어진 건 04·07·08입니다. 목록 안의 규칙(button-name·aria-hidden-focus·label)에 그대로 걸렸어요. 목록 밖 결함을 넣은 넷(02·03·05·06)은 기준 페이지와 같은 2/2를 받았는데, 그중 03·05·06은 접근성 카테고리도 100점이라 자동 검사 전체의 한계에 가깝습니다. 에이전트 브라우징만 놓친 건 02 하나이고, 이건 접근성 카테고리가 87점으로 잡았어요. 고정된 페이지라 다시 돌려도 결과는 같았습니다.

div 버튼: Lighthouse 접근성 100점·에이전트 브라우징 2/2인데 키보드로 못 누릅니다(03)

마우스로는 눌리지만 Tab으로는 갈 수 없는 버튼입니다. 막히는 건 Tab 키로 움직이는 사람들이에요. 키보드나 키보드처럼 동작하는 스위치로 조작하는 사람은 버튼에 닿지 못하고, 스크린 리더는 이 요소를 버튼으로 알리지 않아 버튼 목록이나 Tab으로 찾을 수 없습니다. 크롬과 함께 쓰는 NVDA처럼 클릭 이벤트가 붙은 요소를 '클릭 가능'이라고만 알려 주는 스크린 리더는 있지만(직접 듣지는 않았습니다), 그게 장바구니 버튼인지는 사용자가 짐작해야 하죠.

자동 검사는 <div>에 클릭 핸들러가 붙었는지 HTML만으로 알 수 없고, axe가 이 div를 버튼으로 보지 않으니 '이름 없는 버튼'으로도 못 잡습니다. Lighthouse는 이런 문제를 점수에 들지 않는(가중치 0) '직접 확인할 항목'으로만 남기고, 카테고리 설명에도 직접 테스트하라고 적어 둬요. 구글 문서는 이 감사가 접근성 트리가 빠짐없는지 확인하는 데 도움이 된다고 하지만, 2/2를 받은 이 페이지의 크롬 접근성 트리에서 장바구니는 버튼이 아니라 이름 없는 generic(역할 없는 덩어리) 안의 글자였습니다. 에이전트 도구가 이걸 어떻게 받는지는 뒤에서 표로 보여 드릴게요.

aria-label 이름 불일치(WCAG 2.5.3): 검사하고도 점수에서 뺍니다(05)

화면 글자는 '장바구니 담기', 접근 가능한 이름은 '상품을 카트에 추가'인 버튼입니다. 손 대신 목소리로 컴퓨터를 다루는 음성 제어 사용자는 보이는 대로 "장바구니 담기 클릭"이라고 말하는데, 프로그램이 그 말을 접근 가능한 이름과 맞춰 보므로 버튼을 못 찾을 수 있어요. 화면 요소마다 번호를 띄워 그 번호를 부르는 우회로는 한 번이면 될 말을 두세 번 하게 만들고요. WCAG(웹 접근성 국제 지침) 2.5.3 Label in Name(한국형 지침 KWCAG 2.2의 '레이블과 네임')이 화면 글자를 이름에 넣으라고 요구하는 이유입니다.

역할·이름 조회로는 버튼을 찾지 못했지만, Playwright MCP 스냅샷에는 button "상품을 카트에 추가": 장바구니 담기처럼 이름(따옴표 안)과 화면 글자(콜론 뒤)가 함께 있어 스냅샷을 읽는 에이전트라면 찾았을 가능성이 큽니다. Chrome DevTools MCP는 이름만 건넸고요.

Lighthouse도 이 문제를 검사는 합니다. label-content-name-mismatch 감사가 실패로 기록되는데 점수는 100점이에요. axe-core가 이 규칙을 '심각하지만 실험적인' 규칙으로 분류했고, Lighthouse는 실험적 규칙을 모두 가중치 0으로 두고 리포트에서도 빼거든요. 실제 사이트에서도 슬라이드 라이브러리가 기본으로 붙이는 영어 이름(Previous slide)이 한국어 화면 글자를 덮은 사례가 이 감사에 걸렸습니다.

aria-label 키워드 채우기도 통과: SEO 요령을 막지 못합니다(06)

aria-label에 검색 키워드를 덧붙인 케이스는 모든 측정을 통과했습니다. 화면 글자가 이름 맨 앞에 있으니 2.5.3도 형식상 만족하고, 이름 있는 버튼이니 트리 감사도 통과예요.

하지만 스크린 리더 사용자에게는 이 버튼에 닿을 때마다 "장바구니 담기 최저가 무료배송 오늘출발 한정특가 쿠폰할인, 버튼"이 흘러나옵니다. 말을 끊고 넘길 수는 있어도 어디까지가 버튼 이름인지 알려면 결국 들어야 하죠. 버튼 하나에 홈쇼핑 광고 한 꼭지를 붙여 둔 셈입니다. '무료배송'·'쿠폰할인'은 화면에 없는 말이라 스크린 리더 사용자만 사실인지 모를 약속을 듣게 되고요. Roselli가 걱정한 게 이 장면이에요. "ARIA를 붙이면 AI가 잘 읽는다"가 SEO 요령처럼 퍼져도 점검 도구는 막아 주지 않습니다.

대체 텍스트·명도 대비·lang이 다 깨져도 에이전트 브라우징 2/2(02)

접근성 카테고리는 세 문제를 모두 잡아 87점을 줬고, 같은 리포트의 에이전트 브라우징은 2/2입니다. 그렇다고 에이전트에게 문제없는 페이지도 아니었어요. 대체 텍스트를 뺀 상품 사진은 두 MCP 도구의 스냅샷 모두에서 통째로 사라졌습니다. 사진 정보를 잃는 건 스크린 리더 사용자도 에이전트도 같았는데, 트리 감사는 이걸 보지 않습니다.

트리 감사가 잡은 셋: 이름과 ARIA 문법(04·07·08)

04는 button-name, 08은 label, 07은 aria-hidden-focus에 걸렸습니다. 07은 카드 전체가 크롬 접근성 트리에서 빠져, 스크린 리더로 읽어 내려가면 상품이 있다는 사실조차 알 수 없어요. 그런데 Tab으로 그 안의 버튼에 포커스가 가면 크롬은 이 aria-hidden을 무시하고 카드를 트리에 되돌립니다(크롬 154에서 확인). 읽을 때는 없던 상품이 Tab을 누르면 나타나니, 숨긴 건지 아닌지 알 수 없는 페이지가 되죠. 이런 실수를 잡는 건 분명 쓸모 있습니다. 07은 에이전트 도구에 따라서도 결과가 갈렸어요.

에이전트 도구마다 받는 트리가 다릅니다: Playwright MCP와 Chrome DevTools MCP

같은 케이스를 에이전트용 MCP 서버 두 가지, Playwright MCP와 구글 크롬 팀의 Chrome DevTools MCP로 찍어 봤습니다. 테스트 코드의 Playwright 기본 스냅샷, 보조기술이 받는 크롬 접근성 트리와 나란히 놓으면 이렇습니다.

Playwright MCP는 화면에 보이는 요소라면 aria-hidden이어도 남깁니다. 의도된 동작이고(Playwright PR #42268), Playwright 1.63·Playwright MCP 0.0.80부터는 [aria-hidden] 표시도 붙여요. 마우스 커서가 손가락 모양인 요소(CSS cursor: pointer)에는 cursor=pointer를 붙입니다. Chrome DevTools MCP는 크롬 접근성 트리를 바탕으로 해서 03은 그냥 글자, 07은 카드 자체가 없습니다. 02의 사진이 사라지고 04가 이름 없는 button인 건 두 도구가 같았어요.

트리 감사 판정과 도구에서의 모습도 엇갈렸습니다. 트리 감사에서 떨어진 04·07은 Playwright MCP에서 번호표(ref)를 골라 누르면 장바구니에 담겼고, 통과한 03은 Chrome DevTools MCP에서 누를 수 있다는 표시 없는 글자로 나왔어요(그 글자를 골라 누르면 담기긴 했습니다). 누른 건 제가 MCP 서버로 직접 한 일이고, LLM이 이름 없는 04나 표시 없는 03을 고를지는 별개입니다. 구글 문서가 전제한 건 접근성 트리를 주 데이터로 쓰는 에이전트라, 2/2가 '내 에이전트가 이 페이지를 잘 다룬다'는 뜻인지는 그 에이전트가 무엇을 입력으로 받느냐에 달렸어요. 도구 두 가지·케이스 다섯 개(02·03·04·05·07)의 기록이라 '에이전트 일반'을 말하지는 못합니다.

에이전트가 누를 수 있다고 장애인 사용자가 쓸 수 있는 건 아닙니다. 에이전트가 07의 버튼을 눌러 준다 해도, 스크린 리더로 페이지를 읽어 내려가는 사람에게 그 상품은 여전히 없는 상품이에요.

국내 홈페이지 10곳 실측: 트리 감사를 통과해도 명도 대비 감점은 남았습니다

테스트 페이지는 결함을 골라 넣은 작은 화면이니 결과가 깔끔할 수밖에 없죠. 실제 사이트는 어떨까요.

표를 보기 전에 짚어 둘 게 있습니다. 홈페이지 한 장을 자동 검사 엔진으로 잰 결과라 사이트 전체의 접근성을 말하지 않습니다. 공공기관과 포털·쇼핑 사이트를 제가 골랐을 뿐 대표 표본이 아니고, 순위나 공공·민간 비교로 읽을 표도 아니에요. 공공 네 곳은 모두 웹 접근성 품질인증 마크를 게시하고 있습니다(측정일 기준). 전문가의 KWCAG 심사에 장애인 사용자의 과업 심사까지 거치는 인증이라, 홈페이지 한 장을 자동으로 잰 이 표와는 잣대가 다릅니다. 헤드리스(화면 없이 띄운) 크롬으로 2026년 10월 2일 오후 2시 34분까지 10여 분 동안 세 번 재서 두 번 이상 나온 값을 적었습니다.

규칙 이름을 다 알 필요는 없습니다. 자주 나온 것만 풀면 color-contrast는 명도 대비, target-size는 누를 영역 크기, landmark-one-main은 본문 영역 표시, heading-order는 제목 순서, link-name은 링크 이름입니다. 트리 감사가 '통과'인데 마지막 열이 비어 있지 않은 줄을 보세요.

표는 가나다순이고, 이 블로그는 맨 끝에 두었습니다.

원래는 정부24까지 열한 곳을 쟀지만, 최종 주소의 호스트가 요청과 다르면 다른 페이지를 쟀을 수 있어 뺐습니다. 걸린 곳은 측정 브라우저가 접속 차단 안내 페이지로 넘어간 정부24 하나였고, 자동 접속을 막는 보안 조치라 결함은 아닙니다.

트리 감사를 통과한 외부 사이트 세 곳(네이버·11번가·무신사)은 모두 명도 대비에서 감점이 있었습니다. 테스트 페이지 02와 같은 모양이에요.

트리 감사에서 떨어진 여섯 곳 중 다섯 곳은 ARIA 규칙에 걸렸습니다. 국민건강보험공단·국세청·서울특별시는 ARIA 규칙만으로, G마켓은 이름 없는 링크와, 다음은 이름 없는 링크·tabindex와 함께요. 출처는 두 갈래였어요. 국세청·서울특별시는 슬라이드 라이브러리가 기본으로 붙이는 ARIA(보이지 않는 슬라이드의 aria-hidden, 국세청은 슬라이드 트랙의 role="listbox"까지)에서, 국민건강보험공단·다음·G마켓은 탭과 버튼 등에 직접 붙인 ARIA에서 나왔습니다.

라이브러리 기본값이라도 고칠 몫은 배포한 쪽에 있고, ARIA가 없어서 떨어진 곳은 없었습니다. OpenAI가 가리킨 WAI-ARIA 권장사항(APG)의 'Read Me First'도 '나쁜 ARIA보다 ARIA가 없는 편이 낫다'는 절로 시작하죠.

판정이 통과·실패 둘뿐이라 결과가 극단적이고 흔들리기도 합니다. 한국장애인고용공단은 접근성 96점인데 이름 없는 링크 규칙(link-name) 하나로 떨어졌어요. 스크린 리더 사용자에게는 어디로 가는지 모를 링크라 고칠 이유는 충분하지만, 결함 하나로 판정이 갈리니 점수로 사이트를 비교하긴 어렵습니다. 무신사는 10여 분 사이 세 번 중 한 번 이름 없는 링크가 잡혀 실패했고(요소는 기록하지 못함), 점수(G마켓)와 CLS(한국장애인고용공단)까지 치면 무신사를 포함해 세 곳이 흔들렸습니다.

분수 읽는 법에서 본 것처럼 같은 1/2라도 실패한 곳이 다릅니다. 트리 감사를 통과한 외부 세 곳은 모두 CLS에서 떨어졌어요.

llms.txt를 만든 적 없는데 실패? 소프트 404 때문입니다

서울특별시의 분모가 4, 11번가가 3인 건 리포트의 'llms.txt가 권장사항을 준수하지 않음', 'ai-catalog.json 스키마가 유효하지 않음' 때문입니다. 두 사이트 모두 그런 파일이 없는데도요. 서울특별시는 두 주소를 요청하면 404 대신 오류 안내 페이지(/common/errorAccess.html)로 넘긴(302) 뒤 200을 주고, 11번가는 ai-catalog.json만 그렇습니다(llms.txt는 제대로 404, 2026년 10월 2일 확인). Lighthouse는 4xx면 '해당 사항 없음'으로 빼지만, 200이면 응답 형식을 확인하지 않고 그 HTML을 검사하다 실패시켜요. 없는 주소에 오류 페이지를 200으로 주는 이런 응답을 소프트 404라고 하는데, Lighthouse 판정 방식과 겹치면 만든 적도 없는 파일로 감점됩니다. 없는 주소에는 404를 돌려주면 됩니다.

제 블로그의 3/3도 다시 봐야 했습니다

제 블로그의 3/3과 100점도 같은 조건의 숫자입니다. 분모가 3인 건 llms.txt를 둬서이고(무신사도 같은 이유), 점수에 들지 않는 숨은 감사 label-content-name-mismatch는 세 번 모두 실패였어요. 글 카드는 화면에 제목과 요약을 함께 보여 주는데 aria-label은 '글 이동: 제목'뿐이라, 화면 글자가 이름에 다 들어 있지 않아서입니다. 글자가 있는 링크에 aria-label을 덧씌운 셈이라 아래 권고 5를 제가 어겼고, 고칠 목록에 올렸습니다.

Lighthouse 에이전트 브라우징 점수, 이렇게 읽고 이렇게 고치세요

트리 감사는 "누를 수 있는 것에 이름이 있고 ARIA 문법이 맞는가"를 보는 최소선 점검입니다. 실제 사이트 여섯 곳에서 진짜 결함을 찾았으니 쓸모는 충분해요. 다만 이렇게 읽고 고치세요.

1. 2/2는 접근성 통과가 아닙니다. 명도 대비, 일반 이미지의 대체 텍스트, 문서 언어는 보지 않습니다. 접근성은 늘 켜 두고, 에이전트 브라우징은 그 옆에서 함께 보세요.
2. 접근성 100점도 끝이 아닙니다. Tab 키로 페이지를 한 바퀴 돌며 누를 수 있는 걸 전부 눌러 보세요(키보드 접근성 A to Z).
3. 이름을 직접 확인하세요. 개발자 도구 Elements 패널의 Accessibility 탭에서 Name 항목에 나온 접근 가능한 이름을 보거나, 스크린 리더(Windows는 무료인 NVDA, Mac은 Command+F5로 켜는 VoiceOver)로 주요 버튼 몇 개만 들어 보세요. 이름이 화면 글자와 다르거나(05) 홍보 문구가 붙은(06) 문제는 여기서 드러납니다.
4. 에이전트를 위해 ARIA를 덧바르지 마세요. 문제는 ARIA가 없어서가 아니라 HTML을 안 쓰거나 ARIA를 잘못 써서 생겼습니다. 시맨틱 HTML(<button>, <label>, alt)은 장애인 사용자가 처음부터 필요로 하던 것이고, 에이전트가 덕을 보는 건 그다음 일이에요. ARIA가 꼭 필요한 자리는 ARIA 실전 가이드를 참고하세요.
5. 화면 글자를 그대로 이름으로 쓰세요. 글자가 있는 버튼에 aria-label은 대개 필요 없습니다. 꼭 쓴다면 화면 글자로 시작하고, 화면에 없는 홍보 문구는 덧붙이지 마세요.

에이전트 브라우징 직접 재 보기: PageSpeed Insights부터 측정 스크립트까지

내 사이트 한 장만 보려면 PageSpeed Insights가 가장 빠릅니다(기본이 모바일이니 이 글과 비교하려면 데스크톱 탭). 크롬 150 이상이면 개발자 도구의 Lighthouse 패널로도 되는데, 그 버전은 크롬을 따라가니 리포트 맨 아래에서 확인하세요.

크롬 150은 13.3.0, 151은 13.4.0, 152부터 155까지는 13.4.1, 156부터는 13.5.0입니다. 케이스 판정은 13.3.0·13.4.1에서도 같았어요.

테스트 페이지는 실측 데모에서 열어 볼 수 있고, 측정 스크립트는 GitHub 데모 폴더에 있습니다(Node.js 22.19 이상, 설치된 크롬 필요).

git clone https://github.com/IsaacEryn/isaaceryn.github.io.git
cd isaaceryn.github.io/demo_codes/lighthouse-agentic-browsing/measure
npm ci
npm run measure              # 테스트 페이지 8개: Lighthouse + 역할·이름 조회 + 키보드 + 스냅샷
npm run sites -- --runs 3    # sites.txt의 사이트를 세 번 재고 다수결로 요약

케이스 결과는 results/summary.md, 스냅샷은 results/snapshots/에 쌓입니다. 글의 사이트 표 원자료는 results/sites-2026-10-02/, 두 MCP 서버로 직접 찍고 눌러 본 기록은 results/tool-snapshots.md에 있어요. 원측정이 기록하지 않은 실패 요소는 50분 뒤 재측정해 results/sites-2026-10-02/recheck-nodes.md에 따로 적었습니다. sites.txt 기본값은 이 블로그와 example.com뿐이고, 남의 사이트를 잴 때는 접속 차단 정책과 이용약관을 지켜 주세요.

이 실험이 말해주지 않는 것

• AI 에이전트에게 과업을 시킨 실험이 아닙니다. 역할·이름 조회는 측정 스크립트가, ref 클릭은 제가 MCP 서버로 한 일이고, 실제 LLM 에이전트는 더 유연할 수도, 엉뚱한 걸 누를 수도 있습니다.
• 스크린 리더로 듣거나 장애인 사용자가 써 본 실험이 아닙니다. 스크린 리더가 무엇을 알릴지는 접근성 트리와 문서로 추론했고, 음성 제어도 재지 않았어요. 키보드 조회의 '성공'을 '사람 성공'으로 읽지 마세요(07이 그 예입니다).
• 도구 버전에 따라 결과가 바뀔 수 있습니다. 에이전트 브라우징은 구글이 개발 중이라고 밝힌 카테고리이고, Playwright MCP의 스냅샷 규칙도 최근 여러 번 바뀌었어요. 감사 목록이 바뀌면 다시 재겠습니다.
• 실제 사이트는 제가 고른 열 곳의 홈페이지 한 장을 10여 분 사이 세 번 잰 결과입니다. 다른 페이지나 로그인 뒤 화면은 다를 수 있고, 자동 측정을 막는 사이트는 잴 수 없었습니다.

한 장 요약

• 보통 사이트에서 Lighthouse 에이전트 브라우징(에이전트형 브라우징)은 트리 감사와 CLS 두 문항이고, 트리 감사는 axe 규칙 33개(이름·ARIA 문법 중심)를 봅니다
• 명도 대비·일반 이미지 대체 텍스트·문서 언어는 안 봅니다. 키보드로 못 누르는 div 버튼이 접근성 100점과 2/2를 받았어요
• 에이전트 도구마다 받는 트리가 달라, 2/2가 내 에이전트의 성공을 뜻하지는 않습니다
• 국내 홈페이지 10곳에서 트리 감사를 통과한 외부 세 곳은 모두 명도 대비 감점, 떨어진 여섯 곳 중 다섯 곳은 ARIA 규칙 위반이었습니다
• 2/2를 접근성 통과로 읽지 말고 접근성 카테고리·키보드·스크린 리더 확인을 함께 하세요
• W3C에 'ARIA-AI 프레임워크'는 없습니다(AI와 ARIA를 두고 오간 논의는 있습니다)

에이전트 브라우징 점수는 이름 그대로 등대 불빛이라 빛이 닿는 곳만 밝아요. 03의 div 버튼은 접근성 100점과 2/2를 받고도 Tab 키 한 번에 막혔습니다. 그 불빛 밖은 결국 Tab 키와 스크린 리더로 직접 걸어 봐야 보여요.

참고 자료

• 게시자 및 개발자 FAQ (OpenAI, ChatGPT Atlas 한국어판) · 영어판
• OpenAI, ARIA, and SEO: Making the Web Worse (Adrian Roselli)
• ChatGPT sez Build with semantics first (Steve Faulkner)
• Lighthouse v13.3.0 릴리스 노트 · v13.5.0
• agent-accessibility-tree.js (Lighthouse 13.5.0 소스, 규칙 33개)
• Lighthouse agentic browsing scoring (Chrome for Developers)
• Accessibility for agents (Chrome for Developers)
• llms.txt audit (Chrome for Developers) · llmstxt.org · Agentic Resource Discovery(ARD) 사양 발표 (Google, 2026-06-17)
• PageSpeed Insights
• Playwright MCP (Microsoft) · Playwright PR #42268 (AI 스냅샷의 aria-hidden 처리)
• Chrome DevTools MCP (Google)
• Computer-Using Agent (OpenAI) · Gemini API Computer Use (Google)
• Understanding SC 2.5.3: Label in Name (W3C)
• Read Me First: ARIA Authoring Practices Guide (W3C)
• NVDA User Guide (NV Access)
• ARIA Working Group Charter (W3C) · APA Working Group Charter (W3C)
• Accessibility of machine learning and generative AI (W3C 편집자 초안) · RQTF 회의록(2026-08-12)
• TPAC 2025 브레이크아웃: Semantics for the Agentic Web · 회의록
• ARIA 작업 그룹 이슈 #2796 · ARIA 작업 그룹 회의록(2026-07-02)
• W3C Process Document
• WebMCP (W3C Web Machine Learning Community Group)
• The WebAIM Million (WebAIM)