PageSpeed Insights는 오랫동안 성능, 접근성, 권장사항, SEO 네 항목을 채점해 왔습니다. 2026년, 그 줄에 다섯 번째 항목이 조용히 합류했습니다. 에이전트 브라우징(Agentic Browsing) 입니다. 이 항목은 나머지 네 카테고리가 외면해 온 한 가지 질문에 답합니다. AI 에이전트가 이 페이지를 실제로 다룰 수 있는가?
이 글은 그 체크를 여러분의 사이트에서 실제로 활용하는 방법을 다룹니다. 실행하고, 각 감사가 실제로 무엇을 말하는지 읽어내고, 수정 목록을 들고 돌아오는 것까지입니다.
이 글을 끝내면 얻게 되는 것
누구를 위한 글인가: 사람이 아니라 AI 에이전트가 페이지를 방문했을 때의 동작을 알고 싶은 SEO 담당자, 개발자, 사이트 운영자.
끝나면 손에 남는 것: 내 사이트의 실제 에이전트 브라우징 결과, 통과·실패·해당 없음을 감사별로 읽어낸 기록, 우선순위가 정리된 수정 목록.
사전 준비: 공개된 URL, 첫 실행에 약 10분, 당일에 수정할 계획이라면 코드 접근 권한.
완료 기준: 분수 점수를 감사 단위로 설명할 수 있고, 어떤 실패가 실제로 에이전트의 작업 완료를 막는지 구분할 수 있는 상태.
이 체크가 나온 배경과 지금 주목받는 이유
에이전트 브라우징 카테고리는 1년 전에는 존재하지 않았습니다. 도입은 세 단계로 진행됐고, 모두 Google이 문서로 남겼습니다.
- 2026년 5월 7일: Lighthouse 13.3이 이 카테고리를 기본 설정에 추가해 표준 실행에 포함시켰습니다.
- 2026년 6월 22일: Chrome for Developers 블로그가 "A developer toolkit to make your website agent-ready" 글에서 이 카테고리를 소개했습니다. 에이전트용 DevTools와 WebMCP 가이드도 함께 다뤘습니다.
- 2026년 7월 20일: Lighthouse 13.4.1이 PageSpeed Insights API 경로에서 이 카테고리를 활성화했고, 릴리스 노트에는 "2주 안에 PageSpeed Insights에 반영될 것"이라고 적었습니다. 이에 따라 공개 적용 시점은 2026년 8월 초가 됩니다.
2026년 9월 11일에 이 체크를 실행했을 때, 리포트 하단에는 Lighthouse 13.4.1 기반 에뮬레이션 실행이라고 표시됐고 에이전트 브라우징은 SEO 바로 옆에 자리했습니다. 즉 이 기능은 Canary 전용이 아니라 실제로 배포된 상태입니다. 동시에 분명히 미완성입니다. 리포트의 카테고리 설명에도 이 카테고리는 개발 중이며 변경될 수 있다고 명시돼 있습니다.
시작하기 전 실무 팁 하나. PSI는 이 카테고리를 Google 서버에서 실행합니다. 페이지 단위 체크에 Chrome 150이나 오리진 트라이얼은 필요하지 않습니다. 버전 요구 사항은 Chrome DevTools에서 로컬로 실행할 때 적용됩니다.
내 사이트에서 체크 실행하기
- pagespeed.web.dev를 열고 URL을 붙여넣습니다. 먼저 모바일로 실행하고, 데스크톱으로 다시 반복합니다. 두 랩 실행은 각각 채점되기 때문입니다.
- 랩 데이터가 끝날 때까지 기다립니다. 상단의 필드 데이터는 Chrome UX Report에서 오며 빠르게 표시됩니다. 그 아래 Lighthouse 실행은 더 오래 걸리고, 카테고리는 그쪽에 있습니다.
- 점수 줄을 확인합니다. 성능, 접근성, 권장사항, SEO, 그리고 0~100 점수가 아닌 분수로 표시되는 에이전트 브라우징이 나옵니다.
- 카테고리를 펼칩니다. 감사 목록은 Agent Accessibility, WebMCP, 그리고 일반적인 통과·해당 없음 묶음으로 그룹화됩니다.
- 실패한 감사를 각각 엽니다. 각 행을 펼치면 실패 원인이 된 구체적인 규칙, 요소, 파일이 표시됩니다. 수정 티켓에 필요한 정보입니다.
다섯 번째 카테고리는 SEO 팀이 매일 확인하는 점수와 같은 줄에 있습니다. 2026년 9월 11일 PageSpeed Insights에서 캡처.
품질 점검: 동료와 결과를 비교하기 전에 실행 세부 정보에서 Lighthouse 버전을 확인하세요. PSI는 자체 일정에 따라 Lighthouse를 업데이트하며, 이 카테고리는 버전마다 계속 바뀌고 있습니다.
문제가 생기면: PSI는 무거운 페이지에서 RPC 타임아웃을 반환할 때가 있습니다. 저도 조사 중에 큰 사이트에서 겪었습니다. 다시 시도하거나 로컬 Lighthouse로 테스트하세요.
분수 점수를 정확하게 읽는 법
에이전트 브라우징에는 가중치가 적용된 0~100 점수가 없습니다. 이는 의도된 설계입니다. Lighthouse 문서에 따르면 에이전트를 위한 웹의 표준은 아직 형성 중이므로, 순위가 아니라 실행 가능한 신호에 초점을 맞춥니다.
실제로 중요한 계산은 이것입니다.
표시 | 의미 |
|---|---|
3/3 | 채점 대상 감사가 모두 통과했습니다. 해당 없음 감사는 제외됩니다. |
1/3 | 1개 통과, 2개 실패. 분모는 통과 + 실패 감사만입니다. |
0/3 | 아직 채점 대상 중 통과한 항목이 없습니다. 광고가 많은 무거운 페이지의 첫 실행에서 흔합니다. |
분수 없음 | 모든 감사가 해당 없음이거나 카테고리가 실행되지 않았습니다. 실행 세부 정보를 확인하세요. |
함정은 1/3을 "에이전트 대응도 33퍼센트"로 읽는 것입니다. 이것은 어떤 비율도 아닙니다. 개수입니다. 해당 페이지에서 채점 가능했던 세 가지 체크 중 하나가 통과했고, 적용되지 않은 감사는 계산에서 완전히 빠졌습니다. 제가 캡처한 리포트에서는 감사 6개가 실행되고 3개가 해당 없음이었으며, 나머지 3개가 1/3을 만들었습니다.
같은 페이지에서도 실행마다 점수가 달라집니다. Lighthouse가 제시하는 세 가지 원인은 동적 도구 등록(JavaScript로 등록된 WebMCP 도구는 타이밍에 따라 잡히기도 하고 놓치기도 합니다), 접근성 트리를 바꾸는 DOM 변경, 광고·크기 미지정 이미지·삽입된 콘텐츠로 인한 레이아웃 시프트입니다. 숫자가 흔들리면 대개 이 때문입니다.
여섯 가지 감사 항목 훑어보기
현재 PSI 빌드는 여섯 가지 감사를 실행합니다. 하나가 더 예정되어 있습니다. Lighthouse 개발 브랜치에는 이미 새로운 Agent Discoverability 그룹 아래 ai-catalog.json(Agent Resource Discovery) 검사가 추가되어 있으므로, 이 목록은 버전에 따라 달라진다고 보면 됩니다.
감사 | 확인하는 내용 | "해당 없음"의 의미 |
|---|---|---|
접근성 트리가 올바르지 않음 | 에이전트에 초점을 맞춘 접근성 규칙의 하위 집합: 프로그램상의 이름과 라벨, 유효한 ARIA 구조, 트리에서 숨겨져 있어도 상호작용 가능한 요소 | 없음. 항상 채점됩니다 |
llms.txt가 권장사항을 따르지 않음 |
| 파일이 404를 반환했습니다. llms.txt 부재는 실패가 아니라 선택 사항으로 취급됩니다 |
누적 레이아웃 시프트 | 요소 위치를 기준으로 동작하는 에이전트가 시프트 중에 엉뚱한 것을 클릭하지 않도록 하는 시각적 안정성 | 없음. 항상 채점됩니다 |
WebMCP 도구 등록됨 | 페이지가 선언형 또는 명령형 API로 WebMCP 도구를 등록하는지 | WebMCP 도구가 감지되지 않았습니다 |
WebMCP 폼 적용 범위 | 도구 주석이 빠진 선언형 폼 | 위와 같음 |
WebMCP 스키마 유효성 | 등록된 도구가 유효한 입력·출력 스키마를 게시하는지 | 위와 같음 |
펼친 카테고리 보기: 실패 2건, 통과 1건, 해당 없음 3건. 실패 목록이 가장 짧은 작업 목록입니다.
세 가지 WebMCP 감사가 "해당 없음"으로 표시되는 것은 2026년에는 정상입니다. WebMCP는 제안 단계의 표준으로 오리진 트라이얼과 초기 프리뷰 단계에 있고, 두 가지 API를 갖습니다. 표준 HTML 폼에 주석을 다는 선언형 API와 JavaScript에서 도구를 등록하는 명령형 API입니다. 대부분의 사이트는 아직 둘 다 구현하지 않았으므로 리포트에는 회색 원 세 개가 표시됩니다. 회색은 빨간색이 아닙니다. 실패로 취급하지 마세요.
체크가 지적한 항목 수정하기
네 가지 수정 테마가 여섯 가지 감사를 아우릅니다. 세 가지 WebMCP 항목은 실제로 에이전트 도구를 제공하는 경우에만 신경 쓰면 됩니다.
접근성 트리를 에이전트가 읽을 수 있게 만들기
에이전트는 페이지의 주요 지도로 접근성 트리에 의존합니다. 여기에는 역할, 이름, 상태가 나열됩니다. 접근 가능한 이름이 없는 버튼은 에이전트에게도, 스크린 리더 사용자에게도 막다른 길입니다.
할 일: 펼친 감사에 표시된 실패 규칙을 하나씩 정리합니다. 흔한 원인은 아이콘만 있는 버튼, 라벨 없는 폼 필드, 텍스트가 "여기를 클릭"뿐인 링크, 잘못된 ARIA 역할 조합, ARIA가 참조하는 중복 ID입니다. 시맨틱 HTML을 우선하고, 라벨에는 for 속성을 붙이고, 네이티브 요소로 불가능한 커스텀 위젯에는 명시적인 role과 tabindex를 부여하세요.
기대 결과: 감사가 통과로 바뀌고, 보통 접근성 점수도 함께 오릅니다. 에이전트 브라우징 버전은 같은 검사의 초점을 좁힌 하위 집합이기 때문입니다.
막혔을 때: 수정 대상이 수백 개 요소에 달한다면 하나씩 쫓지 마세요. 헤더의 아이콘 전용 버튼 같은 공통 컴포넌트를 고친 뒤 다시 실행하세요. 컴포넌트 하나로 수십 행이 정리되는 경우가 많습니다.
형식 검사를 통과하는 llms.txt 게시하기
여기에는 꼼꼼한 사람이 걸리는 함정이 있습니다. 이 감사는 /llms.txt가 존재하는지만 보지 않습니다. 파일 내용을 검사하며, URL만 나열한 파일은 실패합니다. 검사가 Markdown 형식 링크를 찾기 때문입니다.
할 일: 루트 도메인에 H1 제목과 실제 Markdown 링크가 있는 /llms.txt를 만듭니다.
# 회사명
사이트가 다루는 내용과 어떻게 사용하면 좋은지 짧게 설명합니다.
## 주요 페이지
- [제품 개요](https://example.com/product)
- [가격](https://example.com/pricing)
- [문서](https://example.com/docs)기대 결과: 감사가 초록색이 됩니다. 반면 404는 해당 없음으로 표시되며 현재로선 허용됩니다. 500번대 응답이나 가져오기 오류는 실제 실패이며 서버 수정이 필요합니다.
품질 점검: 터미널에서 직접 /llms.txt를 가져와 링크 수를 세어보세요. https://example.com/pricing처럼 괄호 없이 나열되어 있다면 파일이 공개되어 사람이 읽을 수 있어도 감사는 실패합니다.
솔직한 단서 하나. Google 검색은 llms.txt를 사용하지 않습니다. Google의 AI 최적화 가이드에도 "Google 검색은 llms.txt를 무시하므로 사이트의 검색 노출이나 순위에 도움이 되지도, 해가 되지도 않습니다"라고 적혀 있습니다. 순위가 아니라 이 관례를 읽는 에이전트 도구를 위해 작성하세요.
에이전트가 조준할 수 있도록 레이아웃 안정화하기
레이아웃 시프트는 예전보다 더 중요해졌습니다. 버튼을 찾은 뒤 좌표를 클릭하는 에이전트는 그 사이에 광고, 배너, 늦게 로드되는 이미지가 버튼을 200픽셀 아래로 밀어내면 클릭을 놓칩니다.
할 일: 이미지와 임베드에 명시적인 width와 height(또는 aspect-ratio)를 지정하고, 광고 슬롯과 동의 배너에 고정 공간을 확보하고, 로드 후 기존 콘텐츠 위에 콘텐츠를 삽입하지 말고, 레이아웃을 유발하는 속성 대신 transform으로 애니메이션하세요.
기대 결과: 랩 실행에서 누적 레이아웃 시프트가 0.1 미만이 됩니다. Core Web Vitals와 같은 임계값입니다.
품질 점검: 리포트의 성능 섹션에 있는 레이아웃 시프트 원인 인사이트가 책임 요소를 정확히 알려줍니다. 추측하지 말고 거기서 시작하세요.
WebMCP는 나중에 결정하기
세 가지 WebMCP 감사는 사이트가 도구를 등록할 때만 채점됩니다. 예약, 결제, 지원 양식 등 에이전트가 완료할 수 있는 구조화된 작업이 있다면 WebMCP는 프로토타입을 만들어 볼 가치가 있습니다. DOM에서 추측하게 하는 대신 호출할 도구를 정확히 알려주기 때문입니다. Chrome은 이 기능을 오리진 트라이얼과 로컬 테스트 플래그 뒤에서 제공하므로 사고 실험이 아니라 현실적인 선택지입니다.
자동화할 만한 작업이 없다면 WebMCP는 건드리지 마세요. 회색 원 세 개는 아무 문제가 아닙니다. 하지 말아야 할 한 가지는 분수를 좋아 보이게 하려고 장식용 도구를 등록하는 것입니다. 이 카테고리는 준비 상태 신호이며, 눈속임은 목적을 무너뜨립니다.
수정 결과 검증하기
같은 URL을 PSI에서 다시 실행하고 하나가 아니라 세 가지를 비교합니다. 분수, 개별 감사 상태, 기기 유형입니다. 수정이 관심 있던 문제가 아닌 다른 감사를 움직여 분수만 바꿀 수 있고, 모바일과 데스크톱은 각각 다른 랩 결과를 냅니다.
반복을 빠르게 하려면 PSI를 기다리지 말고 로컬에서 Lighthouse를 실행하세요. 이 카테고리는 Lighthouse 13.3 이상에 들어 있으므로 로컬 설치로 사용할 수 있습니다. DevTools 패널 버전을 원한다면 Google 문서 기준으로 카테고리 테스트에 Chrome 150 이상이 필요하고, WebMCP 감사에는 오리진 트라이얼 등록도 필요합니다.
수정 전후를 짧게 기록하세요. "2026-09-11: 모바일 1/3, 접근성 트리와 llms.txt 실패" 같은 날짜 한 줄이면 충분합니다. 나중에 생긴 회귀가 실제인지 실행 간 흔들림인지 판단할 수 있습니다.
이 체크가 의미하지 않는 것
혼동이 널리 퍼져 있어서, 하지 않는 일 세 가지를 짚습니다.
- 순위 요인이 아닙니다. Chrome의 발표는 이 카테고리를 정보 제공용이며 벤치마크되지 않았다고 설명합니다. Google 검색 순위는 에이전트 브라우징 분수의 영향을 받지 않습니다.
- AI 가시성 점수가 아닙니다. 에이전트가 페이지를 조작할 수 있는지를 측정할 뿐, ChatGPT나 Perplexity가 답변에서 여러분을 인용하는지는 말해주지 않습니다.
- 사이트의 합격·불합격 판정이 아닙니다. 단순한 마케팅 페이지에서 낮은 분수는 대개 채점할 것이 적었다는 뜻이며, 에이전트가 차단됐다는 뜻이 아닙니다.
도움이 되는 관점은 이것입니다. 이 카테고리는 방문자가 사람이 아닐 때 사이트가 버티는지를 확인합니다. 여기서 좋은 평가를 받는 요소는 어차피 할 가치가 있는 것들입니다. 시맨틱 HTML, 안정적인 레이아웃, 라벨이 붙은 컨트롤. Google의 에이전트 친화 가이드도 같은 결론으로 끝맺습니다. 사이트를 에이전트에 맞게 만드는 일은 사람에게도 더 나은 사이트를 만드는 일이라는 점입니다.
검토 루틴에 넣기
에이전트 준비성은 체크리스트보다 플랫폼이 빠르게 움직이는 영역입니다. 프로젝트로 만들지 않고 최신 상태를 유지하는 두 가지 습관이 있습니다.
- 템플릿, 내비게이션, 폼, 결제 흐름을 바꾼 뒤에는 이 체크를 다시 실행합니다. 접근성 트리와 레이아웃 안정성을 움직이는 변경이기 때문입니다.
- 분수는 URL이 아니라 템플릿 단위로 추적합니다. 제품 페이지 10개가 모두 같은 결과라면 템플릿 문제이고, 한 번의 수정으로 전부 해결됩니다.
PSI 체크는 의도적으로 좁습니다. 감사 여섯 개를 한 페이지씩 볼 뿐입니다. 더 넓은 그림, 즉 robots 규칙, MCP 서버 카드, OAuth 디스커버리, 에이전트 커머스 신호가 갖춰졌는지까지 알고 싶다면 Auspia가 무료 Agent Readiness 체크를 제공합니다. URL을 프로토콜 수준 표준에 비추어 스캔하고 비교용 리더보드도 보여줍니다.
자주 묻는 질문
에이전트 브라우징 점수가 Google 순위에 영향을 주나요? 아니요. Google은 이 카테고리를 정보 제공용으로 설명하며 검색 순위 시스템의 일부가 아닙니다. SEO 점수가 아니라 에이전트를 위한 준비 상태 체크로 다루세요.
같은 페이지에서 두 번 실행했는데 분수가 달라진 이유는 무엇인가요? 동적 도구 등록, 접근성 트리를 바꾸는 DOM 변경, 늦게 발생하는 레이아웃 시프트가 실행 간 변동을 만듭니다. 다시 테스트하고 분수만이 아니라 감사 목록을 비교하세요.
세 가지 WebMCP 감사가 모두 해당 없음으로 나오는 이유는 무엇인가요? 페이지가 WebMCP 도구를 등록하지 않았기 때문입니다. 2026년 대부분 사이트에서 예상되는 상태이며 실패가 아닙니다.
llms.txt가 없으면 문제인가요? 이 감사에서는 아닙니다. 404는 해당 없음으로 처리됩니다. 다만 존재하지만 형식이 잘못된 파일은 실패하므로, 게시한다면 올바르게 게시하세요.
CI에서 실행할 수 있나요? 네, 사용하는 Lighthouse 버전에 이 카테고리가 들어 있으면 가능합니다. 감사는 설계상 결정적이어서 파이프라인 검사에 적합합니다. 다만 WebMCP 부분은 브라우저 지원과 오리진 트라이얼 등록에 의존하므로 대부분의 CI 환경에서는 해당 없음으로 표시될 것으로 예상하세요.
이 기능을 쓰려면 Chrome 150이 필요한가요? 아니요. PageSpeed Insights는 서버 측에서 실행합니다. Chrome 150 요구 사항은 DevTools에서 로컬로 이 카테고리를 실행할 때 적용됩니다.
작성자: Alice Monroe. Auspia에서 150개 이상의 도구를 다루는 AI SEO 도구 분석가. SEO와 AI 검색 도구, 어떤 체크에 시간을 쓸 가치가 있는지, 일상 업무에 어떻게 녹여낼지 씁니다.
