웹사이트의 방문자가 두 부류로 나뉘기 시작했다. 하나는 우리가 늘 상정해온 '사람', 그리고 또 하나는 조용히 마크업을 긁어가는 '기계'. ChatGPT나 Perplexity에 질문을 던지면, 그 뒤에서 retrieval crawler가 해당 페이지를 fetch하고 응답 본문을 파싱한다. 브라우저가 렌더링한 아름다운 화면이 아니라, 날 것의 마크업을. 이 관점을 처음 제시한 건 you.com의 한 담당자였다고 한다. "웹에는 이제 두 번째 독자가 생겼다." 이 문장 하나가 프론트엔드 개발자로서의 설계 기준을 다시 쓰게 만든다.
에이전트는 무엇을 '읽는가'
dev.to에 올라온 한 개발자의 회고는 이 질문을 아주 구체적으로 파고든다. 그는 'Hermes Clew'와 'Agentis Lux'라는 두 개의 도구를 직접 만들고 해커톤에 두 번 출품했다. 두 번 모두 수상하지 못했다. 그리고 얼마 후 Google과 Vercel이 사실상 같은 질문에 대한 답을 각자의 방식으로 출시했다 — Google은 Lighthouse 13.3에 'Agentic Browsing' 카테고리를, Vercel과 Ora는 is-agentic.com을. 패배의 씁쓸함이 아니라, 이 시장이 실제로 수렴하고 있다는 신호로 이 이야기를 읽어야 한다.
핵심 질문은 하나다. 에이전트가 내 사이트를 사용할 수 있는가? 그런데 이 질문에 대한 답이 도구마다 전혀 다르다. Lighthouse는 Chrome DevTools Protocol을 통해 JavaScript를 실행하고 런타임에 등록된 tool을 감지한다. 반면 retrieval crawler는 그냥 HTTP fetch다. JavaScript 없음, hydration 없음. 같은 URL을 보고도 두 도구는 완전히 다른 아티팩트를 읽고 있는 셈이다. '에이전트'라는 단어 하나 아래 사실은 완전히 다른 두 가지 실체가 존재한다.
Lighthouse의 신중한 선택, Vercel의 과감한 공개
Google이 Lighthouse에 추가한 Agentic Browsing 카테고리는 네 가지를 체크한다. llms.txt 파일 존재 여부, WebMCP를 통한 tool 등록, 에이전트에 관련된 접근성 트리 슬라이스, 그리고 Cumulative Layout Shift. 흥미로운 건 점수 방식이다. 0에서 100 사이의 가중 평균을 내지 않는다. 대신 pass 비율만 제공하고, 카테고리 전체를 '실험적'으로 표기했다. "에이전트 웹의 표준이 아직 형성 중이기 때문"이라는 이유로.
이건 꽤 의미 있는 태도다. Core Web Vitals로 전 세계 개발자를 0~100 점수에 집착하게 만든 Google이 이번엔 일부러 숫자를 내지 않기로 했다. 불확실성을 인정한 것이다. 반면 Vercel과 Ora의 is-agentic.com은 정반대 방향을 택했다. 127개 이상의 체크, discovery·access·usability·payments 4개 레이어, 그리고 공개 점수판. Vercel 자신의 도메인이 310개 사 중 2위, 상위 1%라는 사실까지 공개한다. 두 접근 모두 틀리지 않았다. 믿음이 다를 뿐이다 — 보고서가 누구의 것인가, 그리고 불확실성을 어떻게 다룰 것인가에 대해.
llms.txt는 '선언'이고, 시맨틱 HTML은 '존재'다
이 논의에서 가장 날카로운 통찰 중 하나는 체크 항목들의 성격을 나누는 방식이다. llms.txt와 WebMCP는 당신이 추가하는 것이다. 파일을 올리고, tool을 등록하는 선택. 반면 시맨틱 HTML과 접근성 트리는 사이트가 이미 그렇게 존재하거나 아니거나다. 전자는 새로운 제안에 opt-in했는지를 측정하고, 후자는 사이트가 처음부터 잘 만들어졌는지를 측정한다.
그런데 Ahrefs가 137,210개 도메인을 분석한 결과, llms.txt를 올린 28%의 사이트 중 97%는 2026년 5월 한 달 동안 AI 봇으로부터 단 한 번의 요청도 받지 못했다. 파일을 올렸지만 아무도 보러 오지 않은 것이다. 이 데이터가 말하는 건 간단하다. 지금 당장 에이전트 가독성을 높이고 싶다면, 새로운 파일을 올리는 것보다 이미 존재하는 마크업을 제대로 만드는 게 더 실질적이다.
렌더링 이전의 신뢰성 — 조용히 망가진 두 페이지 이야기
에이전트 가독성 논의와 독립적으로 보이지만, 사실 같은 뿌리를 가진 문제가 있다. '렌더링은 멀쩡해 보이는데 실제로는 망가진 구조'. dev.to의 또 다른 글은 GSAP ScrollTrigger를 WordPress 사이트에 적용하다가 두 페이지를 조용히 망가뜨린 경험을 담고 있다.
문제는 두 가지 방향에서 왔다. 첫째는 CSS transform이 만든 새로운 containing block. .dhsea-page에 transform: translateX(-50%)가 걸려 있었고, ScrollTrigger의 pin 자동 감지는 이 조상 transform을 인식하지 못해 잘못된 좌표 공간에 고정을 시도했다. 결과는 1,260px 드리프트. 눈에 띄기는 했지만, 이 수치가 나오기까지 원인을 특정하기 어려웠다. 해결책은 pinType: 'transform'을 명시적으로 선언하는 것이었다. 자동 감지는 transformed containing block 안에서 안전하지 않다.
두 번째 문제는 더 교묘했다. WordPress REST API로 블록 콘텐츠를 수정할 때, 이미 <!-- wp:html --> 래퍼가 있는 content.raw에 래퍼를 한 번 더 씌워버린 것이다. 길이 체크는 통과했다 — 추가한 바이트 수가 정확히 맞았으니까. 하지만 길이가 맞는다는 건 크기가 맞다는 것이지, 구조가 맞다는 게 아니었다. 렌더링은 멀쩡했다. WordPress가 render 시점에 <!-- wp:* --> 주석을 전부 제거하기 때문이다. 망가진 구조는 저장된 content.raw에만 남아 있었고, 화면을 보는 것만으로는 절대 발견할 수 없었다.
이 사건이 에이전트 가독성과 맞닿는 지점이 여기다. retrieval crawler는 렌더링된 화면이 아니라, 서버가 돌려주는 응답 본문을 읽는다. 화면이 정상으로 보인다고 해서 에이전트도 정상으로 읽는다는 보장이 없다. 시각적 검증은 두 번째 사용자 — 기계 — 를 전혀 커버하지 못한다.
보이지 않는 사용자를 위한 설계 원칙
두 글을 나란히 읽으면 몇 가지 설계 원칙이 자연스럽게 도출된다.
첫째, 렌더링 결과가 아니라 마크업 구조를 검증하라. GSAP 버그를 잡은 방법도, WordPress 구조 오염을 발견한 방법도 모두 '실제 저장된 것'을 다시 fetch해서 비교하는 것이었다. 시각적 QA는 에이전트 관점의 QA를 대체할 수 없다.
둘째, 시맨틱 HTML은 선택이 아니라 기반이다. llms.txt를 올리거나 WebMCP를 등록하기 전에, 헤딩 구조가 올바른지, 이미지에 alt가 있는지, ARIA가 제대로 달렸는지를 먼저 챙겨야 한다. 접근성 트리는 에이전트가 사이트를 이해하는 1차 데이터 모델이다.
셋째, 자동 감지를 맹신하지 마라. ScrollTrigger의 pin 자동 감지가 3단계 위의 transform을 놓쳤듯, 도구의 휴리스틱은 특정 컨텍스트에서 조용히 실패한다. 명시적 선언이 예측 가능한 동작을 보장한다.
넷째, '크기가 맞다'와 '구조가 맞다'는 다른 명제다. 길이 체크, 렌더링 스크린샷, 육안 검토 — 이 모든 것이 구조적 오류를 놓칠 수 있다. 에이전트가 파싱하는 것과 동일한 방식으로 검증하는 단계를 파이프라인에 넣어야 한다.
지금 당장 할 수 있는 것
에이전트 친화적 사이트를 만드는 건 거창한 리팩토링이 아니다. 오히려 오래된 원칙들로의 회귀에 가깝다. 시맨틱한 헤딩, 명확한 alt 텍스트, 논리적인 DOM 순서, 불필요한 JavaScript 의존성 제거. 이것들은 스크린 리더 사용자를 위해 늘 해야 했던 것들이기도 하다. 접근성과 에이전트 가독성은 같은 코드베이스 위에 선다.
Agentis Lux 개발자가 수정 제안을 의도적으로 빼낸 이유도 비슷한 맥락이다. "당신의 코드베이스를 한 번도 본 적 없는 모델이 내놓는 첫 번째 수정안을 바로 배포하는 건 무모하다." 에이전트가 사이트를 읽는다고 해서, 에이전트의 판단을 그대로 실행해야 하는 건 아니다. 진단은 에이전트가, 결정은 개발자가. 그 경계를 명확히 하는 것도 설계의 일부다.
두 번째 사용자는 클릭하지 않고, 스크롤하지 않으며, 애니메이션을 감상하지 않는다. fetch하고 파싱한다. 그 관점에서 내 사이트를 한 번 다시 읽어볼 시간이다.