TL;DR: 작은 단어 하나가 가리킨 큰 방향
- 구글 공식 가이드(2026-05-15)의 한 줄 요약 — "generative AI search 최적화 = 결국 SEO 하나다"
- 명시적으로 거절된 것 — llms.txt, 콘텐츠 청킹, AI 전용 리라이팅
- 그런데 마지막 섹션 'Explore agentic experiences'에 흘린 단서 — accessibility tree
- 더 흥미로운 건 — 같은 트리를 OpenAI Computer-Using Agent와 Anthropic Claude AI 에이전트도 보고 있다는 점
- 결론 — 사람을 위한 최적화가 사람도 AI도 위한 최적화였습니다
구글이 못 박은 것: "그냥 SEO다"
며칠 전(2026-05-15) 구글이 'Generative AI Search Optimization Guide'를 공식 문서로 냈습니다. 핵심 메시지부터 거의 단정적입니다.
출처: Generative AI Search Optimization Guide — Google Search Central
"From Google Search's perspective, optimizing for generative AI search is optimizing for the search experience, and thus still SEO."
AEO(Answer Engine Optimization)도 GEO(Generative Engine Optimization)도 따로 있는 게 아니라, 결국 SEO 하나라는 입장입니다. 검색 경험 최적화 하나로 통합된다는 거죠.
그리고 'Mythbusting' 섹션에서 시장에 떠도는 'AI 시대 SEO 신무기'들을 차례로 거절합니다.
llms.txt에 대해: "You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in generative AI search."
콘텐츠 청킹에 대해: "There's no requirement to break your content into tiny pieces for AI to better understand it."
AI 전용 리라이팅에 대해: "You don't need to write in a specific way just for generative AI search."
작년부터 GEO 컨설팅 시장에서 '필수'라며 팔리던 것들이 한 번에 정리됐습니다. 좀 시원하기도 하고, 그 솔루션들을 도입한 분들 입장에선 좀 야속하기도 한 입장 발표입니다.
그런데 마지막 섹션이 묘합니다
가이드는 'Mythbusting'으로 끝나지 않습니다. 'Explore agentic experiences'라는 짧은 마지막 챕터가 하나 더 있고, 거기서 다음 문장이 나옵니다.
"such as analyzing visual renderings (like screenshots), inspecting the DOM structure, and interpreting the accessibility tree."
브라우저 에이전트가 사이트를 이해하는 방식 세 가지로 스크린샷 분석, DOM 구조 검사, 그리고 접근성 트리 해석(accessibility tree)을 꼽고 있습니다.
앞 두 개는 익숙합니다. 그런데 마지막의 'accessibility tree'는 좀 묘하지 않나요. 원래 시각장애인용 스크린리더가 쓰던 그 트리. 시맨틱 HTML, ARIA 속성, label-input 연결, 헤딩 위계 같은 거 잘 챙기면 자동으로 만들어지는 의미론적 구조. 그게 이제 AI 에이전트가 "이 페이지에서 결제 버튼이 어디 있지?" 찾을 때의 핵심 입력값이 됐다는 얘기입니다.
접근성 트리가 뭐길래
브라우저는 페이지를 로드하면 두 개의 트리를 만듭니다. 하나는 우리가 잘 아는 DOM 트리. 다른 하나는 그 DOM에서 '의미'만 추출한 접근성 트리(accessibility tree)입니다. DOM의 의미론적 쌍둥이라고 생각하시면 됩니다.
이 트리에는 다음과 같은 정보가 담깁니다.
- 역할(role) — 이건 버튼인가, 링크인가, 입력 필드인가
- 이름(accessible name) — 이 요소를 어떻게 부르는가 ("결제하기", "장바구니로 이동")
- 상태(state) — 비활성화됐는지, 선택됐는지, 펼쳐졌는지
- 구조(hierarchy) — 헤딩 위계, 랜드마크, 그룹 관계
스크린리더는 이 트리를 읽어 시각장애인 사용자에게 "결제 버튼"이라고 소리내어 알려줍니다. 그리고 이제 AI 에이전트도 같은 트리를 읽고 "결제 버튼은 여기 있구나, 클릭해야겠다" 하고 행동합니다.
시각장애인용 도구가 AI의 입력값이 된 이유
좀 곱씹어볼 만한 지점입니다. 왜 하필 접근성 트리일까요.
생각해 보면, 시각이 없는 사용자(스크린리더 사용자)와 시각은 있지만 의도를 파악해야 하는 AI 에이전트의 인지 메커니즘은 닮은 구석이 많습니다. 둘 다 픽셀이 아니라 "무엇이 무엇인지"를 알아야 행동 가능합니다. 둘 다 페이지의 '의미 구조'를 필요로 합니다. 둘 다 "이건 버튼처럼 생긴 것"이 아니라 "이건 버튼이다"라는 선언이 필요합니다.
그래서 KWCAG가 20년 넘게 외쳐온 원칙들 — 시맨틱 HTML 쓰기, 모든 인터랙티브 요소에 명확한 이름 붙이기, 헤딩 위계 지키기, 폼 필드 label과 input 연결하기, 이미지에 alt 텍스트 달기 — 이 그대로 AI 친화성의 답안지가 됐습니다.
2026년에 새로 만든 GEO 규칙이 아니라, 2010년에 정리된 KWCAG 2.0 규칙으로 돌아온 거죠. 이게 이렇게 돌아오나 싶고, 한편으론 다행이기도 하고요.
"버튼처럼 생긴 div"의 비극
이 관점에서 보면 한국 사이트들의 흔한 풍경이 갑자기 다르게 보입니다.
<!-- AI 에이전트가 못 찾는 결제 버튼 -->
<div class="btn-primary" onclick="checkout()">
결제하기
</div>
<!-- AI 에이전트가 명확하게 인식하는 결제 버튼 -->
<button type="submit" aria-label="주문 결제하기">
결제하기
</button>
위쪽 코드는 화면상 똑같이 보입니다. 디자이너가 봤을 때 같고, 마우스 클릭도 똑같이 됩니다. 하지만 접근성 트리에 노출되는 정보가 완전히 다릅니다. 위쪽은 그냥 "텍스트가 있는 박스"입니다. 아래쪽은 "결제하기라는 이름을 가진 버튼"입니다.
스크린리더 사용자에게도, AI 에이전트에게도 차이는 명확합니다. 그리고 이 차이는 단순한 시맨틱 호불호가 아니라, AI 시대 전환율 격차가 됩니다.
구글이 청킹을 거절한 진짜 이유
가이드를 다시 보면 또 하나 흥미로운 연결이 보입니다. 구글이 "콘텐츠를 잘게 청킹하지 마세요"라고 했는데, 그러면 AI는 우리 콘텐츠를 어떻게 단위로 나눠 이해할까요.
답은 이미 시맨틱 HTML에 들어 있습니다.
<article>— 독립적으로 의미 있는 콘텐츠 단위<section>— 주제 단위의 그룹<nav>— 네비게이션 영역<main>— 페이지의 주 콘텐츠<h1>–<h6>— 구조의 위계<figure>+<figcaption>— 이미지와 설명의 묶음
이미 시맨틱 HTML이 콘텐츠를 자연스럽게 청킹해 줍니다. 별도 청킹 파일이나 마크다운 더미를 만들 필요가 없는 게 아니라, 이미 만들 수 있는데 그걸 안 쓰고 있을 뿐입니다.
구글의 "청킹 하지 마세요"는 게으르라는 뜻이 아니라, "이미 표준이 있는데 굳이 새 표준 만들지 마세요"에 가깝습니다.
그런데 구글만의 얘기일까
여기서 솔직히 한 번 멈춰 서야 합니다. AI 검색은 구글이 90% 점유율로 독식하던 시장이 아닙니다. ChatGPT 검색, Perplexity, Claude, Bing Copilot이 동시에 자기만의 인용 알고리즘을 굴리고 있습니다. 구글이 "접근성 트리 보세요"라고 한다고 다른 플레이어들도 같은 걸 본다는 보장은 없는 거죠.
그래서 다른 플레이어들이 실제로 뭘 보고 있는지 찾아봤습니다. 결과가 좀 놀라웠습니다.
Anthropic Claude AI 에이전트
출처: The Cyborg Session: Reversing & Detecting Claude AI Agent Chrome Extension — CHEQ
Claude AI agent 크롬 확장은 chrome.debugger API를 통해 Chrome DevTools Protocol에 직접 접근하며, 이를 통해 accessibility tree에 대한 가시성을 확보한다.
Anthropic Claude의 브라우저 에이전트는 페이지를 픽셀로 캡처하는 게 아니라, 크롬 디버거 프로토콜로 접근성 트리를 직접 읽습니다. 구글이 가이드에 적은 그 트리, 동일한 트리입니다.
OpenAI Computer-Using Agent
출처: How AI Agents See Your Website — No Hacks
OpenAI의 Computer-Using Agent는 스크린샷 분석과 DOM 처리, 그리고 accessibility tree 파싱을 함께 사용하며, ARIA label과 role을 우선적으로 활용한다.
구글이 'agentic experiences'에서 언급한 세 가지(스크린샷, DOM, 접근성 트리)와 정확히 같은 조합입니다. 우선순위가 ARIA에 있다는 디테일까지 일치합니다.
Perplexity
Perplexity는 좀 다른 결을 보여줍니다. 페이지 전체보다 개별 패시지 단위로 인용하는 모델이고, 핵심은 파서가 콘텐츠를 얼마나 깔끔하게 추출할 수 있는가입니다.
출처: How Perplexity AI Answers Work — ZipTie.dev
정적 HTML의 파싱 성공률은 약 94%인 반면, JS로 렌더링된 콘텐츠는 약 23%에 그친다.
여기서도 결국 의미가 명확한 HTML 구조가 결정적입니다. 시맨틱 마크업, 헤딩 위계, 명확한 텍스트 노드 — 접근성 트리에 기여하는 그 요소들이 그대로 인용 적합성으로 이어집니다.
정리하면
| 플레이어 | 페이지 이해 방식 | 접근성 트리 활용 |
|---|---|---|
| Google (생성형 AI 검색) | 스크린샷 + DOM + accessibility tree | 공식 가이드에 명시 |
| Anthropic Claude 에이전트 | Chrome DevTools Protocol로 직접 접근 | 핵심 입력값 |
| OpenAI Computer-Using Agent | 스크린샷 + DOM + accessibility tree | ARIA 우선 |
| Perplexity | 정적 HTML 패시지 추출 | 간접 기여 (구조적 명확성) |
| Microsoft Copilot | Bing 인덱스 + AI 레이어 | DOM/시맨틱 기반 |
AI 검색의 인용 알고리즘은 각 플레이어가 다 다릅니다. 누구는 패시지 단위로 인용하고, 누구는 페이지 전체를 평가하고, 누구는 도메인 권위를 더 보고, 누구는 신선도를 더 봅니다. 그건 벤더마다 달라요.
하지만 에이전트가 페이지를 '이해'하는 단계에서는 다들 같은 보편 표준에 수렴합니다. 시맨틱 HTML, ARIA, 접근성 트리. 웹 표준이라는 공약수입니다.
이게 좀 안심이 됩니다. 단일 벤더에 락인되지 않는 베팅이 가능한 거죠. llms.txt를 따로 만드는 건 구글이 거절했고 OpenAI/Anthropic도 명시한 적 없습니다. 하지만 시맨틱 HTML과 ARIA는 모든 플레이어가 공통으로 활용하는 자산입니다.
한국 사이트들의 현실
여기서 좀 마음이 쓰리는 대목은, 한국 웹의 현실이 이 표준과 꽤 멀다는 점입니다. 국내 주요 사이트들을 접근성 도구로 돌려보면 div 범벅, 의미 없는 클래스 이름, 빈 alt, 잘못된 헤딩 위계 — 익숙한 풍경이 펼쳐집니다.
솔직히 "alt 좀 채워 주세요", "h1 하나만 제대로 써 주세요"는 저희 업계가 십수 년째 해 온 잔소리입니다. 한국형 웹 콘텐츠 접근성 지침(KWCAG)이 2005년 1.0으로 처음 제정된 뒤 2022년 2.2까지 네 번 개정됐고, 장애인차별금지법이 2008년부터 웹 접근성 의무를 명시한 지도 18년이 됐습니다. 그동안 풍경은 크게 바뀌질 않았어요. 접근성 트리 같은 작은 단어에는 아무도 관심을 주지 않았고, 컴플라이언스가 미달이면 벌금으로 정산하는 쪽이 더 합리적이라는 계산이 어디엔가 깔려 있었던 것 같습니다.
그러던 흐름이 영어권에서는 슬슬 흔들리는 중입니다. SitePoint는 최근 "AI 에이전트가 접근성을 비즈니스 크리티컬 우선순위로 만든다"는 글을 올렸고, UC Berkeley와 미시간대 연구진은 CHI 2026에서 AI 에이전트의 접근성 환경별 태스크 성공률을 측정한 A11y-CUA 데이터셋을 공개했습니다. "AI가 결제 버튼을 못 본다"는 게 빈말이 아니라 점점 측정 가능한 비즈니스 리스크가 되어 가는 거죠.
한국에서는 이 흐름이 어디까지 올지 솔직히 잘 모르겠습니다. 의무로는 움직이지 않던 곳들이 GEO 인용률이라는 비즈니스 동기 앞에서는 어떻게 반응할지 — 그게 좀 궁금합니다. 박수칠 일은 아니지만, 이번을 계기로 접근성 인식이 한 단계 올라설 기회가 되면 좋겠다는 바람이 있습니다.
그런데 이게 이제 GEO 격차가 됩니다. ARIA가 0%인 사이트는 AI 에이전트가 결제 버튼을 못 찾는 사이트입니다. 헤딩이 시각 스타일링용으로 쓰인 사이트는 AI가 콘텐츠 구조를 파싱하지 못하는 사이트입니다. 시맨틱 태그를 안 쓴 사이트는 AI 청킹의 자연스러운 단위를 제공하지 못하는 사이트입니다.
자가 점검부터 해보고 싶으시면 줍줍분석기로 SEO·GEO·A11y를 한 번에 진단해 볼 수 있고, 자동 반영까지 가고 싶으시면 theXEO에서 자동화 흐름을 확인하실 수 있습니다.
SEOX 시각: 통일장 이론
저희가 작년 내내 "SEO와 GEO와 A11y는 결국 한 몸"이라고 얘기해 왔는데, 이번 구글 가이드가 그 통일장을 좀 명시적으로 만들어 줬다고 봅니다.
- SEO — 검색엔진을 위한 의미 구조
- GEO — 생성형 AI를 위한 의미 구조
- AEO — 답변 엔진을 위한 의미 구조
- A11y — 보조 기술 사용자를 위한 의미 구조
- XEO — 위 모두를 통합하는 X(eXperience) 최적화
다 같은 걸 가리킵니다. 사람이 잘 쓰는 사이트의 기본기입니다. 구글이 명시적으로 "이건 SEO다"라고 했고, 그 SEO의 핵심 입력값에 접근성 트리가 들어왔습니다.
그래서 묘하게 즐거운 부분이 있습니다. 접근성 작업은 ROI가 안 나온다고 평가절하받아 온 영역이었습니다. "장애인을 위한 추가 작업"이라는 프레임 안에 갇혀 있었습니다. 그게 이제 AI 인용률과 직결되는 작업으로 재평가되는 중입니다.
마무리: 결국 사람이었습니다
가이드 전체를 다시 읽어보면 메시지가 단순합니다.
별도 파일 만들지 마세요. 별도 글쓰기 방식 만들지 마세요. AI를 위한 새 표준에 시간 쓰지 마세요. 대신 사람이 잘 쓰는 사이트를 만드세요. 의미 있는 HTML을 쓰세요. 명확하게 표시하세요. 헤딩 위계 지키세요.
결국 돌고 돌아 답은 하나였습니다. 사람(고객)을 위한 최적화가 정답이라는 것. 검색엔진이든 AI든, 결국 사람이 쓰기 좋게 만든 사이트를 찾아내고 인용합니다.
이번 가이드를 계기로 접근성에 대한 인식이 한 번 바뀌면 좋겠습니다. "장애인을 위한 추가 작업"이 아니라, "모든 사용자(사람도 AI도)를 위한 기본기"로. 벌금으로 정산하고 넘어갈 수 있는 영역이 아니라, 꼭 해야 하는 일로 자리잡았으면 합니다.
이 주제에 대해 더 논의하고 싶으시면 문의하기로 의견을 보내주세요. 우리 사이트가 AI 에이전트에게 어떻게 보이는지 궁금하시면 줍줍분석기에서 자가 진단도 가능합니다.