크롬 Agentic Browsing으로 무얼 체크할 수 있을까요?

요즘 크롬 라이트하우스 보고서 맨 아래에 못 보던 카테고리가 떠 있는 분들이 계실 거예요. Performance, Accessibility, Best Practices, SEO 다음에 "Agentic Browsing"이라는 영역이 하나 더 생겼습니다. 처음 봤을 땐 GEO 점수인가 싶었는데, 열어보니 결이 좀 달랐어요. AI 검색에 잘 보이게 만드는 도구가 아니라, AI 에이전트가 와서 실제로 무언가를 실행할 수 있게 준비됐는지 보는 도구였습니다. 이 글은 그 차이부터, 공식 감사 항목 4개가 어떻게 구성됐는지, 왜 점수가 아니라 통과/미통과 비율로 표시되는지까지 한 번에 풀어봅니다.

Lighthouse 13.3.0은 정확히 언제 어떻게 풀린 버전인가

크롬 라이트하우스 13.3.0은 2026년 5월 7일에 정식 릴리스됐어요. 이 버전의 핵심 변화는 새 기능 추가가 아니라 분류 이동입니다. Agentic Browsing 카테고리는 2026년 초부터 `--preset=experimental` 플래그로 켜야만 보였는데, 13.3.0부터는 GoogleChrome/lighthouse 공식 changelog에 따르면 default config에 편입돼서 별도 옵션 없이 모든 라이트하우스 실행에서 자동으로 돌아갑니다.

DebugBear의 May 2026 릴리스 노트에 따르면, PageSpeed Insights(PSI)에도 약 2주 시차로 같은 카테고리가 반영됐어요. Chrome 150의 DevTools Lighthouse 패널에도 같은 카테고리가 떠 있습니다. 즉 5월 중순 이후 사이트에 라이트하우스를 실행했다면, 별도 설정 없이도 자동으로 Agentic Browsing 점수를 받게 된 셈이에요.

여기서 한 가지 짚고 갈 게 있어요. 같은 시기에 Google이 공식 "AI 검색 최적화 가이드"를 게재하면서 "AI 검색 노출을 위해 별도의 AI 텍스트 파일·마크다운·마크업이 필요하지 않다"고 못 박았습니다. 라이트하우스는 llms.txt를 감사 항목으로 추가했는데, 같은 회사가 다른 입장을 낸 것처럼 보였어요. Search Engine Land이 정리한 바로는, 구글의 John Mueller가 "llms.txt는 검색 랭킹용 신호가 아니라 에이전트가 사이트를 탐색할 때의 기능적 보조"라고 설명하면서 모순 논란을 정리했습니다. 즉 Agentic Browsing 카테고리는 처음부터 SEO·GEO 점수가 아니라 에이전트 작동성 카테고리로 설계됐다는 거예요.

Agentic Browsing이라는 카테고리는 왜 갑자기 생겼을까

배경은 한 사람의 발표에서 시작됩니다. 2026년 4월, Google Cloud AI 디렉터 Addy Osmani가 자신의 블로그에 "Agentic Engine Optimization(AEO)"라는 글을 올렸고, 이를 Search Engine Land이 "Google AI Director outlines new content playbook"이라는 제목으로 정리하면서 업계가 주목하기 시작했어요. Osmani의 주장은 단순합니다. AI 코딩 에이전트(Claude Code, Cursor, Devin 등)가 이제 사람·검색엔진 다음의 "세 번째 1차 독자"가 됐다는 거예요.

Osmani가 짚은 핵심은 다섯 가지였습니다. 발견 가능성(discoverability), 파싱 가능성(parsability), 토큰 효율성(token efficiency), 능력 신호(capability signaling), 접근 제어(access control). 사람용으로 길고 화려하게 쓴 페이지는 에이전트의 좁은 컨텍스트 윈도우 안에서 잘리거나 통째로 스킵되고, 그러면 환각(hallucination)이 늘어난다는 거예요. "토큰 카운트가 이제 문서의 1차 메트릭이 됐다"는 문장이 가장 자주 인용됐어요.

라이트하우스 13.3.0의 Agentic Browsing 카테고리는 이 AEO 담론을 측정 가능한 감사 항목으로 표준화한 첫 도구입니다. Semrush의 분석은 이걸 "구글이 시스템적으로 agentic web을 향해 가고 있다는 신호"로 읽었어요. 별도 크롤러 식별자(Google-Extended), 프로토콜 표준(WebMCP), 그리고 이제 평가 도구(Lighthouse)까지 갖춰진 셈이에요.

공식 감사 항목은 9개가 아니라 4개로 좁혀집니다

여기가 이 글의 핵심이에요. 매체별로 4·5·9개로 다르게 정리하는 경우가 많은데, 공식 출처는 Chrome for Developers의 Lighthouse Agentic Browsing Scoring 문서이고, 이 문서는 4개 핵심 평가 영역으로 명시합니다. BridgeToAgent 등 일부 매체가 9개 ID로 풀어 정리한 건 비공식 정리예요. 그래서 라이트하우스 13.3.0이 실제로 점검하는 4개는 이렇습니다.

위 4개는 모두 "에이전트가 사이트에서 실제로 작동할 수 있는가"를 본다는 점에서 한 줄로 묶입니다. 사이트맵·schema.org·agents.json·agent-runbook 같은 항목은 accessiBe·Lucid Media·BridgeToAgent 같은 외부 분석에서 AEO 담론의 부가 신호로 거론되지만, 라이트하우스 13.3.0이 카테고리 점수에 반영하는 공식 항목엔 포함되지 않았어요. 같은 회사가 다른 표준 단계를 거치고 있어서 헷갈리기 쉬운 지점입니다.

WebMCP의 점검 결과가 자주 흔들리는 이유도 공식 문서가 짚어줘요. 자바스크립트로 등록하는 imperative tool은 등록 타이밍에 따라 라이트하우스가 캡처에 실패할 수 있어서, 같은 사이트를 두 번 돌려도 결과가 다를 수 있어요. 안정적으로 잡으려면 declarative 등록(HTML 속성)을 우선 쓰는 게 좋습니다.

4개 신호가 각각 어떻게 생긴 파일·코드인가

신호 4개의 역할 차이만 잡으면 나머지는 이해하기 쉬워요. 한 줄로 비교하면 이렇습니다. llms.txt는 지도, WebMCP는 라벨, Accessibility Tree는 이름표, CLS는 떨림 측정이에요. 각 신호가 실제로 어떻게 생긴 파일·코드인지 한 번 보면 적용 감이 잡혀요.

llms.txt — 마크다운 한 장으로 사이트 색인 제공

도메인 루트(`https://example.com/llms.txt`)에 마크다운 한 장으로 사이트의 핵심 페이지와 주제 구조를 정리하는 파일이에요. 본문을 대체하거나 숨겨진 AI 전용 사본이 되면 안 되고, 공개 콘텐츠로 가는 안내 지도 역할만 해야 합니다. 가장 간단한 예시는 이렇게 생겼어요.

`# Cowork Makers`

>

`> 1인 빌더·AI 창업가를 위한 뉴스레터`

>

`## 핵심 페이지`

>

`- [/about](/about): 사이트 소개와 운영 원칙`

>

`- [/newsletters](/newsletters): 전체 뉴스레터 아카이브`

H1 헤더 1개, 짧은 설명 1줄, 의미 단위로 묶인 H2 섹션 + 마크다운 링크 목록만 갖추면 `llms-txt-well-formed` 점검을 통과합니다.

WebMCP — HTML 요소에 능력 주석

페이지에 별도 파일을 만드는 대신, HTML의 버튼·폼·입력 요소에 직접 "이 버튼은 결제를 실행한다", "이 폼은 회원가입을 처리한다" 같은 주석을 다는 방식이에요. Chrome 팀이 W3C에 제안 중인 신규 프로토콜이고, 현재는 declarative 등록(HTML 속성)과 imperative 등록(JS)을 둘 다 지원합니다. declarative 등록 예시는 이렇게 생겼어요.

`<button data-mcp-tool="checkout" data-mcp-description="장바구니 결제 진행">결제하기</button>`

>

`<form data-mcp-tool="search" data-mcp-input="query"><input name="query" /></form>`

`webmcp-annotations` 점검은 페이지에 이런 데이터 속성이 달린 인터랙티브 요소가 하나라도 있는지 확인해요. imperative 등록(JS)은 등록 타이밍 문제로 점검 결과가 일관되지 않을 수 있어서, declarative 우선이 안전합니다.

Accessibility Tree — 모든 버튼·폼에 이름표

에이전트가 페이지 구조를 읽는 1차 데이터 모델이 접근성 트리예요. 라이트하우스는 기존 Accessibility 카테고리에서 한 부분집합을 다시 가져와 Agentic Browsing 관점에서 평가합니다. 핵심은 모든 인터랙티브 요소에 programmatic name이 붙어 있는가예요. 잘 안 되어 있는 페이지는 이렇게 생겼어요.

`<button>` 이름 없음

>

`<img src="cart.png">` alt 없음

>

`<input type="text">` label 연결 없음

같은 요소를 다음처럼 고치면 통과해요.

`<button aria-label="장바구니에 담기">`

>

`<img src="cart.png" alt="장바구니">`

>

`<label for="email">이메일</label><input id="email" type="text">`

에이전트는 시각적 텍스트가 아니라 접근성 트리의 이름을 읽어 액션을 결정하므로, programmatic name이 없으면 "Submit"인지 "Cancel"인지 구분 못 해서 잘못된 버튼을 누를 위험이 있습니다.

CLS — 클릭 직전에 안 움직이게

Cumulative Layout Shift는 페이지를 로딩하는 동안 요소들이 얼마나 움직이는지 측정한 지표예요. 사람한테는 단순 가독성 문제지만, 에이전트한테는 더 심각합니다. 에이전트가 "결제" 버튼 좌표를 측정한 직후 광고가 inject되어 버튼 위치가 바뀌면, 에이전트는 그 자리에 새로 들어온 다른 요소를 누르게 돼요. 라이트하우스 기준 CLS는 0.1 미만이 권장입니다. 자주 걸리는 원인은 사이즈 미지정 이미지, 동적 inject 광고, FOIT 웹폰트 세 가지예요. 이미지는 `width`·`height` 명시, 광고는 reserve 영역 미리 잡기, 웹폰트는 `font-display: optional` 정도가 1차 처방입니다.

Experimental 단계라는 게 정확히 무슨 뜻인가

라이트하우스 다른 카테고리(Performance·Accessibility·SEO 등)는 0~100 가중 평균 점수가 나오는데, Agentic Browsing은 다르게 동작해요. Chrome for Developers 문서에 명시된 표현은 "현재 카테고리는 단일 가중 점수 대신, 통과한 readiness 체크의 비율(예: 3/4)을 표시한다. agentic web을 위한 표준이 아직 형성 중이기 때문에, 단일 랭킹보다 실행 가능한 신호를 모으는 데 우선순위를 둔다"입니다.

이 문장이 중요한 이유가 있어요. 점수가 없다는 건 두 가지 의미예요. 첫째, 가중치가 아직 정해지지 않았다는 뜻입니다. WebMCP 통과 1개와 llms.txt 통과 1개가 같은 무게인지 다른 무게인지 구글이 아직 결정하지 않았어요. 둘째, 항목이 추가·삭제될 가능성이 열려 있다는 뜻이에요. 현재 4개지만 토큰 효율성·접근 제어 관련 감사 항목이 추가될 수 있고, 표준이 정착하지 못한 항목은 빠질 수도 있어요.

그래서 "라이트하우스 Agentic Browsing 100점 만들기" 같은 표현은 현재로선 의미가 모호해요. 만점이 정의되지 않았기 때문입니다. 단일 점수를 보류한 자리에 남은 것은 4개의 개별 신호이고, 카테고리를 정확히 읽으려면 그 신호들을 사이트 유형별로 다르게 해석해야 한다는 점이 Experimental 단계가 의도한 구조예요.

두 사이트 유형에 따라 4개 신호의 의미가 어떻게 갈리나

같은 4개 신호를 보더라도, 사이트 유형에 따라 신호가 가리키는 의미가 완전히 달라져요. 카테고리를 정확히 읽으려면 두 그룹을 분리해서 봐야 합니다.

콘텐츠 사이트(블로그·미디어·뉴스레터·문서)

이 유형은 llms.txt + Accessibility Tree + CLS 세 신호가 의미를 거의 다 담습니다. llms.txt는 LLM이 사이트 구조를 빠르게 파악할 수 있게 해주고, Accessibility Tree와 CLS는 사람과 에이전트 모두에게 좋은 페이지 품질 신호예요. WebMCP는 측정 대상이 되는 인터랙티브 액션이 거의 없는 콘텐츠 사이트 입장에선 fail로 표시되는 게 자연스러운 결과입니다.

작업형 사이트(SaaS·이커머스·예약·금융·헬스케어 등)

이 유형은 4개 신호의 무게중심이 WebMCP와 Accessibility Tree로 이동합니다. 에이전트가 사용자 대신 시간 조회·예약·취소·결제 같은 액션을 실행하려면 4개 모두 의미가 있지만, 특히 WebMCP가 실제 작업 자동화의 핵심 신호로 작동해요. 접근성 트리는 에이전트가 "결제하기" 버튼을 찾을 수 있게 해주고, CLS는 그 버튼이 클릭 순간에 안 움직이게 해줍니다.

같은 4개 신호가 두 유형에서 다른 의미를 가진다는 점이 Agentic Browsing 카테고리를 읽을 때 가장 자주 헷갈리는 지점이에요. 통과 비율 3/4 자체보다, 내 사이트가 어떤 유형에 속하는지에 따라 "어떤 3개가 통과했는가"가 진짜 신호입니다.

사이트 유형별로 오늘부터 무엇을 챙길 수 있을까

위 분류를 그대로 액션으로 옮기면 두 트랙이 됩니다. 사이트 유형에 맞춰 하나 골라서 적용해보세요.

콘텐츠/블로그/뉴스레터 운영자 — 10분이면 시작

세 단계로 끝나요. (1) 도메인 루트에 `llms.txt` 한 장을 올려요. 위에서 보여드린 형식대로 H1 + 짧은 설명 + H2 섹션별 마크다운 링크만 챙기면 됩니다. (2) 본문 안 이미지에 `alt`, 버튼에 `aria-label`이 빠진 곳이 있는지 라이트하우스 Accessibility 카테고리로 한 번 확인해요. (3) `width`·`height` 안 적힌 이미지가 있으면 추가해서 CLS를 0.1 미만으로 잡아둡니다. WebMCP는 작업형 액션이 없으면 fail로 두고 가도 괜찮아요.

SaaS·이커머스·예약 개발자 — declarative 등록부터

순서가 중요해요. (1) 결제·예약·검색·회원가입 같은 핵심 액션을 식별합니다. (2) 각 액션의 HTML 요소(버튼·폼)에 `data-mcp-tool`, `data-mcp-description`, `data-mcp-input` 같은 declarative 속성을 추가해요. imperative(JS) 등록보다 declarative 우선이 라이트하우스 점검 결과가 안정적이에요. (3) 같은 요소에 `aria-label`도 추가해서 접근성 트리가 비어 있지 않게 해요. (4) 결제 버튼 영역의 CLS를 0.05 미만으로 잡습니다. 결제 직전 광고 inject 같은 패턴이 가장 위험합니다.

두 트랙 모두 한 번에 100점을 노릴 필요는 없어요. Experimental 단계라 단일 점수도 없습니다. 4개 중 내 사이트 유형에 의미 있는 신호부터 통과시키고, 표준이 더 안정화된 다음에 나머지를 챙기는 게 현실적입니다.

코냥이의 시선

Agentic Browsing 카테고리에서 가장 흥미로운 지점은 점수가 없다는 사실 자체예요. 구글은 SEO·Performance에서는 늘 점수를 먼저 줬어요. 점수가 있으면 시장이 점수에 맞춰 움직이기 때문이에요. 그런데 이번엔 점수를 일부러 보류했어요. 표준이 아직 형성 중이라는 솔직한 인정이며, 동시에 "단일 랭킹을 만드는 순간 4개 신호가 한 덩어리로 묶여 의미가 흐려진다"는 판단으로도 읽혀요.

그래서 13.3.0은 "이 사이트의 점수"가 아니라 이 사이트가 받은 4개의 개별 신호로 봐야 의미가 살아나요. 같은 통과 비율 2/4라도 미디어 사이트의 2/4와 SaaS의 2/4는 가리키는 의미가 완전히 달라요. llms.txt·WebMCP·Accessibility Tree·CLS 네 신호의 역할 차이를 정확히 잡아두는 게 13.3.0이 무엇인지 이해하는 출발점이에요. 13.3.0의 개념을 잡았다면, 실제 사이트에 어떻게 적용할지는 "AI 검색에 잡히기 위한 GEO 세팅 기준은 결국 사람이 잡아줘야해요"에서 단계별로 정리하고 있어요.

한 번 더, 빠르게 짚고 갈게요

Q. Agentic Browsing 카테고리는 GEO 점수랑 같은 건가요? A. 다른 영역이에요. GEO(Generative Engine Optimization)는 "내 콘텐츠가 AI 답변에 인용되는 것"이 목표인 반면, Agentic Browsing은 "AI 에이전트가 내 사이트에서 작업을 실행할 수 있는가"를 봅니다. 둘이 겹치는 부분(llms.txt)이 있지만, WebMCP·Accessibility Tree·CLS는 GEO와 무관한 작업 자동화 신호예요.

Q. llms.txt를 만들면 구글 검색 순위가 올라가나요? A. 아니에요. 구글의 John Mueller가 명확히 답한 부분인데, llms.txt는 검색 랭킹 신호가 아니라 에이전트가 사이트를 탐색할 때의 기능적 보조예요. 구글 AI 검색에 노출되기 위해 llms.txt가 필수인 건 아니지만, 비Google LLM(ChatGPT·Claude·Perplexity)이 사이트 구조를 빠르게 파악하는 데는 도움이 될 수 있어요.

Q. Agentic Browsing 점수는 검색 순위에 영향을 주나요? A. 영향이 없어요. llms.txt를 포함한 Agentic Browsing 신호들은 검색 랭킹용이 아니라 에이전트가 사이트에서 작업을 수행할 때의 기능적 보조예요. SEO·GEO 점수와 Agentic Browsing 점수는 평가 대상이 다른 독립 카테고리로 봐야 합니다.

Q. AEO(Agentic Engine Optimization)는 GEO·SEO와 어떻게 다른가요? A. AEO는 Google Cloud AI 디렉터 Addy Osmani가 2026년 4월 제안한 개념으로, "AI 코딩 에이전트가 사람·검색엔진 다음의 세 번째 1차 독자가 됐다"는 관점에서 출발해요. GEO가 "AI가 본문을 인용하는 영역"이라면 AEO는 "AI가 사이트를 읽고 실행하는 영역" 전체를 가리키고, 라이트하우스 13.3.0의 Agentic Browsing 카테고리는 AEO 담론을 4개 감사 영역으로 표준화한 첫 도구예요.

Q. WebMCP를 declarative와 imperative 둘 다 등록해도 되나요? A. 둘 다 등록해도 되지만, 라이트하우스 점검 안정성 측면에선 declarative(HTML 속성) 등록을 우선하는 게 좋아요. imperative(JS) 등록은 페이지 로드 후 자바스크립트 실행 타이밍에 따라 라이트하우스 측정 시점에 캡처되지 않을 수 있어서, 같은 사이트를 두 번 돌려도 결과가 다르게 나올 수 있습니다. declarative 등록은 페이지 로드 시점에 이미 HTML에 박혀 있어서 결과가 일관돼요.