당신의 사이트가 Lighthouse의 새로운 Agentic Browsing 심사를 통과하지 못했습니다 — 각 항목별 해결 방법

최근 Chrome DevTools를 열고 Lighthouse를 실행했다면, Performance, Accessibility, SEO 등과 함께 새로운 카테고리가 추가된 것을 발견했을 수도 있습니다: 바로 Agentic Browsing입니다.

이 기능은 Lighthouse 13.3 (2026년 5월)에 출시되었습니다. 아직 실험적(experimental) 단계로 표시되어 있어 0~100점의 점수를 제공하지는 않으며, 각 항목별로 통과/실패(pass/fail) 여부만 알려줍니다. 하지만 Lighthouse에서 "실험적"이라는 말은 곧 "기본값"이 될 가능성이 높으며, 그때가 되면 고객이 왜 빨간색(경고)인지 물어보게 됩니다. 따라서 비용이 적게 드는 지금 미리 이해해 두는 것이 가치가 있습니다.

이 카테고리는 한 가지 질문에 답합니다: AI 에이전트가 실제로 이 페이지를 이해하고 조작할 수 있는가? 이 질문은 네 가지 검사 항목을 통해 확인됩니다. 각 항목이 무엇을 테스트하는지, 그리고 어떻게 하면 정확히 통과할 수 있는지 알아보겠습니다.

1. llms.txt

검사 내용: 도메인 루트에서 /llms.txt를 제공하는지, 그리고 — 사람들이 놓치는 부분인데 — 해당 파일이 실제로 유용한지를 확인합니다. H1이 없거나, 너무 짧거나, 링크가 포함되어 있지 않으면 해당 파일에 플래그를 표시합니다.

통과 방법: https://yourdomain.com/llms.txt 경로에 일반 텍스트(정확히는 Markdown) 파일을 추가하세요. 최소한의 실행 가능한 버전은 다음과 같습니다:

# Acme Tools

> Acme는 정밀 수공구를 판매합니다. 이 파일은 AI 에이전트가 적절한 페이지를 찾는 데 도움을 줍니다.
...

하나의 H1, 한 줄 요약, 그리고 중요한 페이지로 연결되는 실제 링크가 필요합니다. 이것이 검사의 전부입니다. 사이트맵(sitemap)을 통째로 들이붓지 마세요. 에이전트가 알아야 할 소수의 진입점(entry points)을 큐레이션하세요.

2. Accessibility tree (접근성 트리)

검사 내용: 모든 상호작용 가능한 요소가 프로그래밍 방식의 이름(programmatic name)을 가지고 있는지, 역할(roles)과 부모/자식 관계가 유효한지, 그리고 상호작용이 가능함에도 접근성 트리(a11y tree)에서 숨겨진 요소는 없는지를 확인합니다.

통과 방법: 이것은 단순한 접근성 위생(accessibility hygiene)의 문제이며, 네 가지 항목 중 가장 중요한 점검 사항입니다. 왜냐하면 접근성 트리(accessibility tree)는 에이전트(agent)가 페이지를 읽는 주된(primary) 방식이기 때문입니다. 클릭 핸들러(click-handler)가 달린 <div> 대신 실제 <button>, <a>, <label>/<input> 쌍을 사용하세요. 아이콘만 있는 버튼에는 aria-label을 부여하세요. 어쩔 수 없이 사용하게 된 <div role="button">은 포커스(focusable)가 가능하고 이름이 지정되어 있는지 확인하세요.

만약 접근성(a11y) 백로그를 미뤄왔다면, 에이전트 시대는 이를 실행해야 할 두 번째이자 무시하기 어려운 이유를 제공했습니다. 스크린 리더(screen-reader) 사용자를 돕는 바로 그 수정 사항들이 방문하는 모든 에이전트를 돕게 될 것이기 때문입니다.

3. 누적 레이아웃 이동 (Cumulative Layout Shift, CLS)

점검 내용: 이미 코어 웹 바이탈(Core Web Vitals)을 통해 알고 계시는 것과 동일한 CLS를 점검합니다.

통과 방법: 여기에는 에이전트 전용의 특별한 사항은 없습니다. 이미지와 임베드(embed)를 위해 공간을 확보하고(width/height 또는 aspect-ratio 사용), 기존 콘텐츠 위에 새로운 콘텐츠를 주입하는 것을 피하며, 폰트를 프리로드(preload)하세요. 왜 에이전트(agentic) 카테고리에서 시각적 안정성을 신경 써야 할까요? 실제 브라우저를 구동하는 에이전트는 클릭 좌표를 사용하고 스냅샷을 읽기 때문입니다. 에이전트가 작동하는 도중 페이지 레이아웃이 재배치(reflow)되면, 인간이 겪는 것과 똑같이 잘못된 곳을 클릭하게 됩니다. 안정적인 레이아웃은 곧 신뢰할 수 있는 자동화(automation)를 의미합니다.

4. WebMCP

이것은 새로운 항목이며, 여러분이 이미 수행하고 있어야 할 위생 관리 차원이 아닌, 진정으로 에이전트 웹(agentic web)에 관한 유일한 점검 항목입니다.

점검 내용: Lighthouse는 선언적 HTML API를 통해서든, 혹은 navigator.modelContext.registerTool()을 통한 명령형(imperative) 방식이든, 페이지에 등록된 모든 WebMCP 도구를 노출하여 선언된 모든 inputSchema가 구문론적(syntactically) 및 의미론적(semantically)으로 유효한지 검증합니다. 어노테이션(annotated)이 적용된 폼(form)의 경우, 해당 어노테이션이 예상되는 스키마와 일치하는지 확인합니다.

통과 방법: 실제로 도구를 노출해야 하며, 해당 도구의 스키마는 유효해야 합니다. 명령형 방식의 예시는 다음과 같습니다:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "search_products",
...

팀들이 실수하는 부분이기 때문에, 명확히 짚고 넘어가야 할 두 가지 사항이 있습니다:

• 기능 감지 (Feature-detect). 대부분의 브라우저는 아직 navigator.modelContext를 탑재하지 않았습니다 (현재 Chrome 149 오리진 트라이얼(origin trial) 단계이며, WebKit은 이에 대해 공식적으로 반대해 왔습니다). if ("modelContext" in navigator)와 같은 가드(guard)를 사용하면 스펙 도입이 지연되더라도 손해를 보지 않습니다. 이는 점진적 향상 (progressive enhancement) 방식입니다.
• 기존 핸들러 (handlers) 재사용. 당신의 search_products 도구는 이미 검색 UI가 호출하고 있는 바로 그 함수로 귀결되어야 합니다. 만약 도구가 UI에서 할 수 없는 일을 수행한다면, 당신은 결국 서로 어긋나게 될 두 번째 진실의 원천 (source of truth)을 만든 셈입니다. 이는 바로 WebKit이 제기한 중복성 비판 (redundancy critique)과 정확히 일치합니다. 도구는 이미 배포된 동작에 대한 얇고 타입이 지정된 (typed) 프런트 도어 (front doors)로 유지하십시오.

솔직한 우선순위 설정

이 네 가지 체크리스트 중 세 가지 — llms.txt, 접근성 (accessibility), CLS — 는 에이전트 기반 웹 (agentic web)을 믿든 아니든 상관없이 수행해야 하는 작업들입니다. 이것들을 먼저 처리하십시오. 이는 오늘날 사용자들과 검색 엔진에 즉각적인 보상을 제공합니다.

네 번째인 WebMCP는 브라우징이 나아갈 방향에 대한 진정한 베팅입니다. 또한 무언가를 판매하고 있다면 가장 큰 레버리지 (leverage)를 가질 수 있는 항목이기도 합니다. "에이전트가 내 페이지를 읽을 수 있다"와 "에이전트가 내 페이지에서 구매를 완료할 수 있다" 사이의 간극이 바로 WebMCP 도구가 채워주는 간극이기 때문입니다.

공지: 저는 여러분을 대신해 WebMCP 체크(#4)를 수행해 주는 오픈 소스 (MIT) 한 줄 스크립트인 Latch에서 일하고 있습니다. Latch는 사이트의 기존 검색/장바구니/폼을 유효한 스키마 (schemas)를 가진 WebMCP 도구로 노출하며, 기능 감지 (feature-detected)를 수행하고 기존 핸들러를 재사용합니다. 도구를 채택하기보다 표준을 직접 이해하고 싶다면, WebMCP 가이드가 벤더 중립적인(vendor-neutral) 정보를 제공할 것입니다. 댓글을 통해 트레이드오프 (trade-offs)에 대해 이야기 나누는 것을 환영합니다.