Agent-ready 웹의 출발점은 llms.txt가 아니라 접근성이다
AI Agent가 웹에서 항공권을 찾고, 회의 일정을 잡고, 상품을 주문하는 장면이 가까워지면서 새로운 최적화 시장도 열리고 있다. 검색엔진에 잘 보이는 웹을 넘어 Agent가 잘 읽고 사용할 수 있는 웹을 만들어야 한다는 주장이다.
그러자 익숙한 처방이 반복된다. 사이트 루트에 llms.txt를 놓고, AI가 읽기 좋은 요약을 만들고, Agent 전용 인터페이스를 붙이라는 조언이다. 모두 쓸모가 있을 수 있다. 하지만 파일 하나를 추가한다고 사람이 쓰기 어려운 웹이 Agent에게 갑자기 명확해지는 것은 아니다.
Agent-ready 웹의 출발점은 AI를 위한 새 문서가 아니라, 이미 화면에 있는 요소의 이름과 역할과 상태를 기계가 정확히 알 수 있게 만드는 접근성이다.
Agent는 화면을 보면서도 우리처럼 보지 않는다
사람은 픽셀 사이의 관계를 빠르게 추론한다. 돋보기 모양은 검색이고, 오른쪽 위의 작은 엑스는 창을 닫으며, 회색 버튼은 지금 누를 수 없다고 짐작한다. 입력창 옆에 글자가 놓여 있으면 별도 연결 정보가 없어도 그 글자를 입력 항목의 이름으로 받아들인다.
브라우저 Agent는 이런 시각적 단서만 이용하지 않는다. Chrome의 Lighthouse Agentic Browsing 문서는 Agent가 접근성 트리를 주된 데이터 모델로 사용한다고 설명한다. 브라우저는 HTML을 바탕으로 각 요소의 이름, 역할, 상태와 관계를 별도의 구조로 만든다. 스크린리더가 화면을 이해하는 바로 그 구조다.
따라서 화면에는 그럴듯해 보여도 접근성 트리에는 뜻이 없는 인터페이스가 문제가 된다. 클릭 이벤트만 붙인 div, 이름 없는 아이콘 버튼, placeholder에만 의존한 입력창, 키보드로 도달할 수 없는 메뉴, 상태 변화를 기계에 알리지 않는 알림창이 대표적이다. 사람은 주변 문맥으로 빈칸을 채우지만 Agent는 여러 행동 후보 중 하나를 추측해야 한다.
이 지점에서 접근성은 별도의 복지 항목이 아니라 인터페이스의 진실성 문제가 된다. 버튼은 버튼이어야 하고, 입력 항목에는 연결된 이름이 있어야 하며, 선택 여부와 오류 상태가 프로그램적으로 드러나야 한다. W3C도 가능한 경우 네이티브 HTML의 label 같은 의미 구조를 먼저 사용하라고 권한다. 이런 표시는 스크린리더 사용자와 음성 입력 사용자뿐 아니라 화면을 기계적으로 해석하는 Agent에게도 같은 단서를 제공한다.
llms.txt는 안내판이지 조작 장치가 아니다
Lighthouse 13.3에는 Agentic Browsing 범주가 기본 설정에 추가됐다. 현재 이 범주는 0점부터 100점까지의 성숙도 점수를 매기지 않는다. 관련 표준이 아직 형성 중이기 때문에 접근성 트리, 화면 안정성, llms.txt, WebMCP 도구 등록 같은 결정적 검사를 통과했는지 보여주는 실험적 신호에 가깝다. Chrome 150 이상이 필요하고 WebMCP 검사에는 origin trial 등록도 필요하다.
이 검사 항목을 같은 층의 기능으로 보면 안 된다. llms.txt는 사이트가 무엇이고 어떤 자료가 중요한지 알려주는 정리된 안내판이다. 접근성 트리는 현재 페이지에서 무엇을 읽고 누를 수 있는지 보여주는 기계의 시야다. WebMCP는 웹 애플리케이션의 기능을 이름, 설명, 입력 schema를 가진 도구로 노출하려는 실행 인터페이스다.
즉 Agent-ready 웹에는 적어도 세 단계가 있다. 사이트를 발견하고 방향을 잡는 것, 화면의 의미를 이해하는 것, 사용자를 대신해 행동하는 것이다. 첫 단계의 파일을 잘 만들었다고 나머지 두 단계가 해결되지는 않는다. 메뉴 이름이 모호하고 폼의 오류를 찾을 수 없다면 Agent는 사이트 소개를 읽은 뒤에도 일을 끝내지 못한다.
그래서 가장 오래가는 투자는 화려한 Agent 전용 기능보다 의미 있는 HTML, 정확한 라벨, 예측 가능한 포커스, 명시적인 상태와 오류다. 이것은 특정 모델이나 새 표준이 사라져도 사람과 자동화 모두에게 남는다. AI 시대의 웹 최적화가 접근성에서 시작한다는 말은 Agent를 위해 인간을 뒤로 미루자는 뜻이 아니다. 인간을 위해 정직하게 만든 인터페이스가 기계에도 가장 덜 모호하다는 뜻이다.
하지만 Agent가 화면을 정확히 이해하게 된 다음에는 더 어려운 질문이 생긴다. 이해할 수 있다는 사실만으로, 사용자를 대신해 행동해도 되는가.
그 질문이 중요한 이유는 웹을 읽는 순간과 웹에서 상태를 바꾸는 순간의 책임이 완전히 다르기 때문이다. 가격을 잘못 읽으면 비교 결과가 틀린다. 반면 주문 버튼을 잘못 해석하면 결제가 일어나고, 공개 범위를 잘못 이해하면 비공개 자료가 외부로 나간다.
Agent-ready의 진짜 난제는 인식보다 의도다
사람이 웹을 사용할 때 클릭은 어느 정도 의도의 증거로 취급된다. 결제 화면을 보고 마지막 버튼을 직접 누르면 서비스는 사용자가 거래를 승인했다고 판단한다. Agent가 끼어들면 이 연결이 느슨해진다. 사용자가 “가장 싼 옵션을 알아봐”라고 말했는데 Agent가 비교만 해야 하는지, 장바구니에 담아도 되는지, 실제 결제까지 해도 되는지는 화면 요소만으로 결정할 수 없다.
WebMCP는 이런 웹 기능을 자연어 설명과 구조화된 입력을 가진 도구로 노출하려는 제안이다. Agent가 픽셀 위치를 추측해 버튼을 누르는 대신 search-products나 reserve-seat처럼 이름 붙은 기능을 호출할 수 있다. 실행 가능성을 높이는 방향이지만, 도구의 이름이 실제 효과를 보증하지는 않는다.
2026년 7월 현재 WebMCP 문서는 W3C 표준이나 Standards Track 문서가 아닌 Community Group 초안이다. 초안 자체도 도구의 설명과 실제 동작이 일치하는지 Agent가 실행 전에 검증할 장치가 없다고 지적한다. 예를 들어 “장바구니를 최종화한다”는 도구가 단순히 최종 화면을 보여주는지 실제 구매를 일으키는지 자연어만으로는 모호할 수 있다. 로그인된 브라우저 세션을 그대로 사용하는 도구라면 구매, 계정 변경, 데이터 공유와 삭제까지 높은 권한의 행동으로 이어질 수 있다.
따라서 Agent용 도구를 많이 공개하는 것보다 행동의 경계를 정확히 설계하는 일이 먼저다. 검색과 조회처럼 상태를 바꾸지 않는 행동, 임시 저장처럼 되돌릴 수 있는 행동, 결제와 발행처럼 외부 효과가 생기는 행동은 같은 호출로 뭉치면 안 된다. 사용자의 넓은 요청을 Agent가 곧바로 최종 실행 권한으로 해석하지 않도록, 미리보기와 확정 사이에 명시적인 경계가 필요하다.
좋은 도구 설명보다 실제 효과의 일치가 중요하다
Agent 인터페이스는 기존 UI 위에 친절한 자연어 설명을 붙이는 작업으로 끝나지 않는다. 설명, 입력 schema, 권한, 검증 로직, 실제 부작용이 하나의 계약처럼 일치해야 한다. 읽기 전용이라고 표시한 도구가 로그를 남기는 수준을 넘어 외부 상태를 바꾸거나, 선택 사항처럼 보이는 입력값으로 개인정보를 과도하게 요구한다면 Agent가 이해하기 쉬울수록 오히려 위험은 커진다.
WebMCP 초안은 이 문제를 과도한 매개변수를 통한 개인정보 유출 위험으로도 다룬다. 사이트가 세분된 입력값을 많이 요구할수록 도움이 되려는 Agent는 개인화 맥락, 방문 기록, 다른 사이트에서 얻은 정보까지 채워 넣을 수 있다. 사람에게 긴 폼을 보여주면 수상함을 느낄 항목도 Agent 호출 안에서는 편의를 위한 schema처럼 보일 수 있다.
여기서 좋은 Agent 인터페이스의 기준이 드러난다. 일을 끝내는 데 필요한 최소 정보만 받고, 실행 전에 바뀔 상태를 보여주며, 결과에는 무엇이 실제로 일어났는지 확인할 수 있는 식별자와 영수증을 돌려줘야 한다. 실패도 “오류가 발생했습니다”가 아니라 어떤 전제조건이 맞지 않았고 상태가 바뀌었는지 아닌지를 구분해 알려야 한다. 그래야 Agent가 재시도할지, 사람에게 넘길지, 이미 끝난 일을 중복 실행하지 않을지 판단할 수 있다.
전용 도구는 두 번째 권한 경로가 될 수 있다
“어차피 브라우저 Agent는 기존 버튼도 누를 수 있으니 전용 도구를 제공하는 편이 더 안전하지 않은가”라는 반론은 타당하다. 실제로 명확한 이름과 schema를 가진 도구는 좌표 기반 조작보다 예측 가능할 수 있다. WebMCP 초안도 웹 기능 자체가 이미 UI에 존재한다면 도구가 완전히 새로운 기능을 만드는 것은 아니라고 설명한다.
다만 UI 조작과 도구 호출이 서로 다른 코드 경로를 지나면 검증 규칙도 달라질 수 있다. 사람용 결제 화면에는 금액 확인과 재인증이 있는데 Agent용 호출에는 빠져 있다면, 편의를 위해 만든 지름길이 더 높은 권한의 우회로가 된다. Agent용 표면은 기존 보안과 승인 절차를 생략하는 API가 아니라, 같은 규칙을 더 명시적으로 표현하는 또 하나의 인터페이스여야 한다.
이 때문에 모든 사이트가 지금 WebMCP를 붙여야 한다는 결론도 성급하다. 정보 제공 사이트라면 먼저 의미 있는 문서 구조와 접근성, 안정적인 URL, 정확한 원문을 갖추는 편이 낫다. 예약·구매·업무처리처럼 Agent가 실제 상태를 바꿀 가치가 큰 서비스라면 제한된 읽기 기능부터 실험하고, 권한과 확인, 중복 실행 방지, 감사 기록이 준비된 행동만 단계적으로 열어야 한다.
AI SEO와 Agent-ready 웹은 다른 사업 문제다
AI SEO의 질문은 “답변을 만드는 모델이 우리 사이트를 발견하고 인용할까”에 가깝다. Agent-ready 웹의 질문은 “사용자의 목적을 정확히 이해하고, 허용된 범위 안에서 일을 끝내며, 결과를 증명할 수 있을까”다. 전자는 유통과 발견의 문제이고 후자는 제품과 운영, 보안의 문제다.
이 차이를 놓치면 마케팅팀이 llms.txt를 만든 뒤 사이트가 Agent-ready가 됐다고 선언한다. 그러나 Agent는 회사 소개를 잘 읽으면서도 이름 없는 버튼 앞에서 멈추고, 오류 상태를 놓치고, 모호한 확정 기능으로 원치 않는 거래를 만들 수 있다. 안내판은 생겼지만 건물의 문과 엘리베이터와 비상구는 여전히 알 수 없는 셈이다.
앞으로 웹사이트의 품질은 사람에게 얼마나 설득력 있게 보이는지만으로 평가되지 않을 것이다. 기계가 의미를 오해하지 않는지, 행동의 부작용이 명시됐는지, 사용자의 권한을 넘지 않는지, 실행 뒤 무엇이 일어났는지 증명할 수 있는지가 함께 제품 품질이 된다.
llms.txt는 Agent에게 현관의 위치를 알려줄 수 있다. 그러나 문손잡이의 의미를 만들고, 들어갈 권한을 확인하고, 안에서 벌어진 일을 책임지는 것은 결국 웹 제품의 설계다.
주요 출처: TLDR Marketing 2026-06-03; Chrome for Developers의 Lighthouse Agentic Browsing scoring; GoogleChrome Lighthouse v13.3.0 release; W3C Web Machine Learning Community Group의 WebMCP Draft Community Group Report; W3C WAI의 Labeling Controls. Lighthouse Agentic Browsing과 WebMCP는 2026년 7월 현재 실험적 기능 및 제안 단계입니다. 접근성·행동 경계·승인·감사 기록을 하나의 Agent-ready 제품 설계로 연결한 부분은 이 글의 분석입니다.
