Lighthouse 13.3이 조용히 새 카테고리를 추가했다. Performance, Accessibility, SEO 옆에 Agentic Browsing이 생겼다. 아직 실험적(experimental) 딱지가 붙어 있고 0~100 점수 대신 항목별 pass/fail만 표시된다. 그런데 Lighthouse의 '실험적'은 역사적으로 '곧 클라이언트가 왜 빨간불이냐고 물어보는 것'으로 이어졌다. 지금 이해해두는 게 나중에 불끄는 것보다 훨씬 싸다.
이 카테고리가 던지는 질문은 하나다. AI 에이전트가 이 페이지를 실제로 이해하고 조작할 수 있는가? 네 가지 체크항목이 그 질문에 답한다. llms.txt 파일 유무, 접근성 트리(Accessibility Tree) 품질, CLS(누적 레이아웃 이동), 그리고 WebMCP. 처음 셋은 이미 알던 것들이고, 넷째가 진짜 새로운 판돈이다.
llms.txt는 사이트 루트에 놓는 마크다운 파일로, AI 에이전트에게 '여기서 뭘 할 수 있는지'를 설명하는 일종의 안내판이다. H1 하나, 한 줄 요약, 핵심 페이지 링크 몇 개면 충분하다. 사이트맵을 통째로 붓는 게 아니라, 에이전트가 진짜 진입해야 할 지점을 큐레이션하는 것이 핵심이다. 이건 SEO의 robots.txt가 크롤러에게 범위를 알려줬던 것과 정확히 같은 논리다—대상이 크롤러에서 에이전트로 바뀌었을 뿐.
접근성 트리 체크는 사실상 우리가 미뤄온 a11y 숙제다. 에이전트는 화면을 눈으로 보지 않는다. 클릭 가능한 <div>는 에이전트에게 아무 의미가 없다. 시맨틱 <button>, 올바른 aria-label, 유효한 role 계층—이것이 에이전트가 페이지를 '읽는' 방식이다. 스크린리더 사용자에게 의미있는 구조가 AI 에이전트에게도 의미있는 구조다. 두 번째 이유가 생긴 셈이니, 이제 a11y 백로그를 더 이상 뒤로 미루기 어렵다.
CLS가 Agentic Browsing 감사에 포함된 이유는 처음엔 의아하게 느껴질 수 있다. 그런데 생각해보면 당연하다. 에이전트가 실제 브라우저를 구동해 좌표를 기반으로 클릭할 때, 레이아웃이 흔들리면 정확히 사람이 오클릭하는 것과 같은 일이 일어난다. 안정적인 레이아웃은 사용자 경험의 문제이기도 하고, 이제는 자동화 신뢰성의 문제이기도 하다.
그리고 WebMCP. 이것이 나머지 셋과 결이 다른 이유는, 단순한 위생 점검이 아니라 에이전트 웹을 향한 실질적인 배팅이기 때문이다. navigator.modelContext.registerTool()을 통해 페이지가 직접 도구(tool)를 노출하면, 에이전트는 UI를 읽고 추측하는 대신 명시적인 인터페이스를 통해 작업을 수행한다. 검색, 장바구니 추가, 폼 제출—이런 행위들이 에이전트에게 타입이 정의된 API로 열리는 것이다.
여기서 놓치면 안 되는 설계 원칙이 있다. WebMCP 툴은 UI가 이미 호출하는 함수를 얇게 감싸야 한다. 툴이 UI가 할 수 없는 무언가를 한다면, 그 순간 두 개의 진실 공급원이 생기고 그 둘은 반드시 어긋난다. WebKit이 이 스펙에 공식 반대 의견을 낸 이유 중 하나도 바로 이 중복성의 위험이다. 그러니 툴은 새로운 능력을 추가하는 게 아니라, 기존 능력에 에이전트가 접근할 수 있는 문을 여는 것이어야 한다.
어도비가 파이어플라이와 크리에이티브 클라우드 앱 전반에 AI 어시스턴트를 확대 적용한 사례는 이 흐름의 실제 규모를 보여준다. 포토샵, 프리미어, 일러스트레이터, 인디자인—사용자가 원하는 결과를 말로 설명하면 에이전트가 여러 단계 워크플로우를 조율해 실행한다. 크리에이터가 '배경 교체하고 플랫폼별로 크기 조정해줘'라고 말할 때, 에이전트는 포토샵 UI를 '읽고' 조작하거나 혹은 노출된 도구를 직접 호출한다. 어도비가 챗GPT, 클로드, 마이크로소프트 코파일럿 같은 외부 AI 플랫폼으로 크리에이티브 툴을 확장하고 있다는 사실은 이 구조가 단일 앱의 내부 기능이 아니라 범용 에이전트가 다루는 인터페이스가 되어가고 있음을 방증한다.
두 흐름을 겹쳐 읽으면 하나의 방향이 선명해진다. 에이전트는 이미 UI를 읽고 있고, 곧 조작한다. Lighthouse 13.3의 Agentic Browsing 감사는 그 준비가 됐는지를 측정하는 첫 번째 공식 도구다. llms.txt와 접근성 트리, CLS는 당장 해야 할 위생이고, WebMCP는 그 다음 단계의 계약서다. '에이전트가 내 페이지를 읽을 수 있는가'와 '에이전트가 내 페이지에서 구매를 완료할 수 있는가' 사이의 간극을 채우는 것이 WebMCP의 역할이고, 그 계약을 설계하는 것이 이제 프론트엔드의 일이다.
당분간 WebMCP는 Chrome 149 오리진 트라이얼 단계고, WebKit은 공식 반대 입장이다. 스펙이 바뀌거나 지연될 수 있다. 하지만 if ("modelContext" in navigator) 가드를 달면 지는 게 없다—이건 프로그레시브 인핸스먼트의 고전적인 적용이다. 지금 당장 WebMCP에 배팅하지 않더라도, 접근성 트리를 정비하고 시맨틱 마크업을 갖추는 일은 에이전트 웹이 오든 안 오든 해야 할 일이다. 에이전트가 읽기 좋은 UI는 결국 사람도 쓰기 좋은 UI다.