웹사이트를 채점하던 기준이 조용히 바뀌고 있습니다. "사람이 보기 편한가"를 넘어 "AI 비서가 쓰기 편한가"가 새로운 평가 항목으로 들어왔기 때문입니다. 이번 글에서는 구글이 Lighthouse, PageSpeed Insights에 추가한 '에이전트형 브라우징(Agentic Browsing)'이 무엇을 검사하는지 살펴봅니다. 이 중 새롭게 보인 개념인 WebMCP가 무엇인지, 그리고 이 변화가 우리의 웹 사용 방식을 어떻게 바꿀지를 이야기합니다.
1. 웹의 손님이 '사람'에서 'AI'로 바뀌고 있다
지난 2년간 브라우저 속 AI 에이전트는 사실상 '사람 흉내'로 동작해 왔습니다. 화면을 스크린샷으로 찍어 모델에게 보여주고, "결제 버튼이 어디쯤 있을까?" 추론한 뒤, 좌표를 계산해 클릭하고, 다시 화면을 캡처해 결과를 확인하는 식이었죠. 느리고, 비싸고, 디자이너가 클래스 이름 하나만 바꿔도 곧장 망가지는 방식이었습니다.
그런데 이제 웹을 찾는 손님 중 상당수가 사람이 아니라 기계입니다. OpenAI의 Operator, 앤트로픽의 Computer Use, 구글의 Project Mariner, 퍼플렉시티 등 '나 대신 작업을 끝까지 수행하는' 에이전트들이 늘어나고 있습니다. 이들은 검색어를 던지고 링크 열 개를 읽는 데 그치지 않습니다. "이 세 제품을 비교해서 금요일까지 도착하는 가장 싼 걸 주문해 줘" 같은 과업을 받아 여러 사이트를 오가며 직접 처리합니다.
웹사이트도 마침내 이 현실에 따라 변하기 시작했습니다. 그 첫 신호가 바로 구글이 자사 웹 품질 측정 도구에 추가한 '에이전트형 브라우징'입니다.
2. Lighthouse와 PageSpeed Insights에 등장한 '에이전트형 브라우징'
웹 개발자라면 한 번쯤 돌려봤을 PageSpeed Insights. 그 채점 엔진인 Lighthouse에 2026년 5월, 익숙한 네 가지 카테고리(성능·접근성·권장사항·SEO) 옆에 다섯 번째 항목이 조용히 추가됐습니다. 바로 에이전트형 브라우징(Agentic Browsing)입니다.
그동안 구글은 웹사이트를 평가할 때 오직 사람만 신경 썼습니다. "스마트폰에서 화면이 얼마나 빨리 뜨는가?", "글씨가 읽기 편한가?" 같은 것들이었죠. 그런데 에이전트형 브라우징은 누구도 묻지 않던 질문을 던집니다.
"AI 에이전트가 이 페이지를 읽고, 구조를 이해하고, 추측 없이 과업을 끝낼 수 있는가?"
인터넷 쇼핑몰로 비유하면 이렇습니다. 기존 평가가 "손님이 둘러보기 좋은 매장인가?"였다면, 에이전트형 브라우징은 "심부름 온 로봇이 물건을 찾아 결제까지 마치기 편한 매장인가?"를 보기 시작한 것입니다.
3. 에이전트형 브라우징은 무엇을 검사하나? — 4가지 항목
그렇다면 AI 비서에게 좋은 점수를 받으려면 구체적으로 무엇을 해야 할까요? 크게 네 가지를 봅니다. 앞의 세 가지는 PSI 기본 점수에 포함되고, 네 번째(WebMCP)는 아직 실험적 항목으로 분리돼 있습니다.
기계용 안내 표지판 달기 — 접근성 트리
화려한 디자인과 이미지를 모두 걷어내도, 버튼과 메뉴마다 눈에 보이지 않는 '기계용 이름표'가 명확히 붙어 있어야 합니다. 흥미로운 점은 AI 에이전트가 페이지를 이해할 때 의존하는 1차 자료가 사람이 보는 화면이 아니라 접근성 트리(Accessibility Tree)라는 사실입니다. 시각장애인을 위한 보조 기술이 읽던 바로 그 구조를 이제는 AI가 똑같이 읽습니다.
💡 기술적 접근: 시맨틱 HTML(Semantic HTML)을 올바르게 사용하고, 클릭 가능한 모든 요소에 프로그래매틱 이름(programmatic name)과 적절한 역할(role)을 부여해 깨끗한 접근성 트리를 만듭니다. Lighthouse는 기존 접근성 감사 중 '이름·라벨'과 '트리 구조의 무결성'처럼 기계 조작에 결정적인 항목만 추려서 평가합니다. 결국 접근성을 잘 챙긴 사이트가 AI 친화적인 사이트이기도 합니다.
흔들리지 않는 화면 만들기 — CLS
AI가 '구매하기' 버튼을 누르려는 찰나, 위에서 광고 배너가 뜨며 화면이 밀려 버리면 안 됩니다. 사람이라면 눈으로 다시 찾겠지만, 좌표를 미리 계산해 클릭하는 에이전트는 엉뚱한 곳을 누르고 작업이 깨집니다. 게다가 에이전트는 사람보다 훨씬 빠르게 움직이기 때문에, 콘텐츠가 로딩되며 생기는 미세한 밀림조차 더 치명적입니다.
💡 기술적 접근: 기존 핵심 웹 성능 지표(Core Web Vitals)인 CLS(Cumulative Layout Shift)를 최소화하는 작업과 동일합니다. 이미지에 width, height를 명시하고, 비동기로 들어올 광고나 동적 콘텐츠의 자리를 CSS 그리드/플렉스 박스로 미리 확보해 둬 화면이 점프하지 않게 합니다. 이상적인 목표치는 CLS 0입니다.
AI 전용 핵심 요약본 제공하기 — llms.txt
사람이 읽는 장황한 소개글 대신, AI가 사이트 전체를 다 뒤지지 않고도 단번에 구조를 파악할 수 있는 'AI 전용 색인 문서'를 제공하자는 발상입니다.
💡 기술적 접근: 웹사이트 최상위 경로(루트)에 마크다운 형식의 llms.txt 파일을 두어, 주요 페이지와 설명을 거대 언어 모델(LLM)에 간결히 안내합니다. Lighthouse는 이 파일의 존재 여부뿐 아니라 H1 헤더 유무, 내용이 너무 짧지 않은지, 링크가 들어 있는지까지 점검합니다.
📌 단, llms.txt는 제안된 지 몇 년이 지났지만 실제로 이를 읽는 AI 시스템은 아직 드뭅니다. 구글의 존 뮬러(John Mueller)조차 2026년 6월 "현재로선 다소 추측에 기댄 형식"이라며, 오히려 WebMCP처럼 목표와 절차가 분명한 접근을 더 선호한다고 밝혔습니다. 점수를 위해 만들어 두되, 지금 당장 마법 같은 효과를 기대하긴 이릅니다.
AI 전용 직통 통로 열어두기 — WebMCP (실험적 항목)
AI가 사람처럼 화면을 더듬지 않고도 기능을 곧장 실행하도록, 사이트가 명시적인 '실행 규칙'을 제공하는 것입니다. 이것이 최근 가장 주목받는 WebMCP입니다.
💡 기술적 접근: 선언적(declarative) 방식으로 HTML <form>에 도구임을 알리는 주석을 달거나, 명령형(imperative) 방식으로 자바스크립트 API를 호출해 사이트 기능을 AI에게 명시적으로 노출합니다.
📌 단, 이 WebMCP 감사는 PSI 기본 점수에서 빠져 있습니다. Chrome 150 이상에서, 그것도 공식 WebMCP 오리진 트라이얼에 등록해야만 실제로 동작하기 때문입니다. 표준이 안정될 때까지는 가중치를 낮게 두거나 정보성 항목으로만 표시됩니다.
4. 낯선 개념 WebMCP, 도대체 무엇인가?
이름은 어렵지만 원리는 간단합니다. WebMCP(Web Model Context Protocol)는 "웹사이트가 AI 에이전트에게만 건네는 전용 메뉴판"을 만드는 규칙입니다. 화면을 보고 추측하게 하는 대신, "내가 할 수 있는 일은 이것들이고, 각각에 필요한 입력값은 이렇다"는 목록을 사이트가 먼저 내미는 방식이죠.
과거에는 AI가 항공권을 예매하려면 사람처럼 화면을 훑어야 했습니다. '출발지'라 적힌 네모 칸을 눈치껏 찾아내고, 파란색 '결제' 버튼의 위치를 파악해 가상으로 눌러 보는 식이었죠. 홈페이지 디자인이 조금만 바뀌어도 AI는 엉뚱한 곳을 누르고 고장 나기 일쑤였습니다.
WebMCP를 따르는 사이트는 이 눈치 게임을 끝냅니다. 화면 뒤편에서 AI에게 조용히 이렇게 건네는 셈입니다.
"AI야, 복잡한 화면에서 헤맬 필요 없어. 우리 사이트가 할 수 있는 기능은 항공권 예약이고, 필요한 건 출발지와 날짜야. 그것만 알려주면 내가 알아서 처리할게."
참고로 이 WebMCP는 구글과 마이크로소프트의 엔지니어들이 W3C 산하 커뮤니티 그룹을 통해 제안한 개방형 웹 표준 후보입니다. 크롬 전용 라이브러리가 아니라 공개 표준으로 추진된다는 건, 파이어폭스, 사파리, 브레이브 등 다른 브라우저도 같은 방식을 구현해 AI가 웹 전체에서 일관되게 동작하기를 노린다는 뜻입니다.
5. WebMCP는 어떻게 작동하나? — 두 갈래의 길
WebMCP에는 난이도가 다른 두 가지 구현 방식이 있습니다.
선언적(Declarative) 방식 — 가장 쉬운 첫걸음
이미 잘 만들어진 HTML <form>에 'AI가 쓸 수 있는 도구'라는 주석만 달면, 크롬이 이를 자동으로 호출 가능한 도구로 등록해 줍니다. 시맨틱 HTML이 잘 갖춰진 사이트라면, 주요 동작 하나를 노출하는 데 폼당 몇 분이면 충분할 정도로 진입 장벽이 낮습니다. 그래서 대부분의 사이트에 권장되는 출발점입니다.
명령형(Imperative) 방식 — 복잡한 흐름을 위한 길
자바스크립트 navigator.modelContext.registerTool로 도구를 직접 등록하고, 입력·출력·부수효과를 JSON 스키마로 명세하는 방식입니다. 다단계·다구간 예약처럼 단순 폼으로 표현하기 어려운 복잡한 흐름에 적합합니다.
정리하자면, 폼 주석으로 가볍게 시작(선언적)하고, 복잡한 흐름에서만 코드를 직접 짜는 것(명령형)이 WebMCP를 효율적으로 구축하는 방법입니다.
6. WebMCP가 그리는 미래의 웹 경험
이런 규칙이 보편화되면 우리의 일상은 어떻게 바뀔까요? 지금까지 챗GPT나 제미나이에게 "제주도 가는 비행기 표 좀 알아봐 줘"라고 하면, AI는 여행사 링크 몇 개를 추천하는 데 그쳤습니다. 링크를 클릭하고, 날짜를 누르고, 카드로 결제하는 건 결국 사람의 노동이었죠.
WebMCP가 자리 잡은 미래는 다릅니다. AI는 웹사이트를 '찾아주는 것'을 넘어, 사이트 안에서 내가 할 일(쇼핑·문의·예약·결제)을 '대신' 수행합니다.
"지니야, 다음 주 수요일 저녁 7시, 강남역 근처 이탈리안 레스토랑 4명 예약해 줘."
이 한마디면 끝입니다. AI는 예약 사이트에 접속해 WebMCP 메뉴판에서 '예약 도구'를 찾아 곧장 실행하고, 내 스마트폰에는 "예약 완료" 알림만 뜹니다. 그 식당 예약 페이지가 어떻게 생겼는지는 평생 구경조차 할 필요가 없어집니다.
이 변화는 SEO의 문법도 바꿉니다. 웹사이트를 검색 결과 상위에 노출시키는 SEO에 더해, AI 엔진에서 내 사이트가 더 잘 노출되도록 하는 AEO(Agent Engine Optimization) 와 GEO(Generative Engine Optimization)가 새로운 경쟁 축으로 떠오릅니다.
AI에게 레스토랑 추천을 부탁하면 AI는 레스토랑 목록을 건네는 동시에 물을 겁니다. ‘레스토랑 예약까지 도와드릴까요?’ AI가 직접 예약할 수 없는 웹사이트는 추천 목록에서 누락될 수밖에 없습니다. AI는 사용자를 위해 더 많은 걸 해주고 싶어하니까요.
🎬 나가는 말: 거대한 변화에 재빠르게 올라타기
현재 WebMCP 오리진 트라이얼은 크롬 버전 149부터 156까지 진행됩니다. 이 체험판 기간이 끝난 뒤 곧바로 정식 표준이 될지는 아직 미지수입니다. 에이전트형 브라우징 카테고리 역시 '개발 중'이라는 꼬리표를 달고 있어, 검사 항목과 채점 방식은 더 바뀔 수 있습니다.
하지만 한 가지는 분명합니다. 핵심 웹 성능 지표(Core Web Vitals)와 접근성이 그랬듯, Lighthouse가 한 카테고리를 기본값으로 채택하면 머지않아 그것은 표준이 됩니다. 화려한 팝업이나 배너보다 기계와 얼마나 매끄럽게 대화하느냐가 경쟁력이 되는 시대가 오고 있습니다.
다행인 점은 이 준비가 거창한 재작성을 요구하지 않는다는 사실입니다. 시맨틱 HTML로 접근성 트리를 깨끗이 정리하고, CLS를 잡아 화면을 고정하고, llms.txt를 갖추고, 핵심 폼 한두 개에 WebMCP를 얹는 것 — 대부분의 좋은 개발자가 해 오던 일의 연장선입니다. 차이는 그것을 남들보다 먼저 하느냐에 있습니다.
인간은 한 걸음 물러나고, 우리를 대신한 AI 비서들이 바쁘게 웹사이트를 오가며 일을 처리하는 인터넷. 여러분은 이런 미래가 상상되시나요?
마치며
에이전트형 브라우징과 WebMCP를 한 문장으로 요약하면 이렇습니다.
이제 웹사이트는 사람와 AI 모두를 위해 존재해야 합니다. AI 손님이 헤매지 않는 웹사이트를 만들어주세요.
지금 당장 할 수 있는 일은 의외로 소박합니다.
- 접근성: 모든 인터랙티브 요소에 명확한 이름과 역할을 부여해 접근성 트리를 정돈하기
- 안정성: 이미지·광고 자리를 미리 확보해 CLS를 0에 가깝게 만들기
- 발견성: 루트에 잘 구성된
llms.txt(헤더·내용·링크 포함) 배치하기 - 실행성: 가장 가치 있는 폼 한두 개부터 WebMCP로 선언적 노출 시도하기
PageSpeed Insights에 내 사이트 주소를 한 번 넣어보세요. 다섯 번째 점수가 다가올 미래에 AI의 선택을 받을 수 있을지 가장 먼저 알려줄 것입니다.
참고 자료
https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring
https://developer.chrome.com/docs/ai/webmcp
https://www.w3.org/2025/11/11-webmachinelearning-minutes.html