웹사이트를 사람이 읽기 좋게 만드는 일과 AI 에이전트가 다루기 좋게 만드는 일은 겹치지만 같지는 않다. 사람은 화면을 보며 메뉴를 찾고, 애매한 문맥도 추론한다. 반면 에이전트는 robots.txt, 사이트맵, HTTP 응답, HTML 구조, API 설명처럼 기계가 확인할 수 있는 신호에 크게 의존한다. 문서 사이트나 SaaS 제품 페이지를 운영한다면 이제 이 차이를 한번은 확인해 볼 만하다.
최근 공개된 is-agentic은 URL 하나를 입력해 에이전트가 사이트를 발견하고, 접근하고, 이해하고, 활용할 수 있는지를 살피는 도구다. 스캔은 Ora가 수행한다. Ora는 Vercel과 함께 만든 이 도구가 콘텐츠 중심 사이트에는 기본 항목을, API나 결제 흐름이 있는 제품에는 추가 항목을 다르게 보도록 설계했다고 설명한다. 독립 매체 MarkTechPost도 이 도구가 공개 웹사이트의 에이전트 접근성을 점검하고 결과와 개선 권고를 제공한다고 소개했다.
여기서 조심할 점이 있다. 높은 점수가 곧 좋은 제품, 안전한 서비스, 검색 노출 보장을 뜻하지는 않는다. 이 평가는 보안 감사나 접근성 감사의 대체재도 아니다. 다만 사람이 아니라 에이전트가 먼저 만나는 웹의 표면을 드러내는 진단 도구로는 쓸모가 있다.
점수보다 먼저 봐야 할 네 가지 질문
Ora의 전체 랭커는 발견성, 접근성, 사용성, 결제라는 네 층을 살핀다. is-agentic은 사이트 성격에 맞춰 필수 항목, 권장 항목, 보너스 신호로 결과를 보여 준다. 이 구분이 중요한 이유는 단순한 회사 소개 페이지에 결제 API가 없다는 이유로 감점하는 것은 의미가 없기 때문이다.
실무에서는 숫자 하나보다 아래 질문으로 결과를 읽는 편이 낫다.
- 발견할 수 있는가. 에이전트가 중요한 페이지를 sitemap.xml, llms.txt, 내부 링크 같은 경로에서 찾을 수 있는가.
- 막히지 않고 읽을 수 있는가. robots.txt나 응답 헤더가 의도치 않게 접근을 막지 않는가. 긴 리다이렉트 체인이나 자바스크립트만으로 구성된 본문도 마찰이 될 수 있다.
- 문맥을 구분할 수 있는가. 제목과 헤딩, canonical URL, 메타 설명, 구조화 데이터가 있어 문서의 주제와 최신성을 파악할 수 있는가.
- 작업에 쓸 인터페이스가 있는가. 제품이 API나 개발자 문서를 제공한다면 OpenAPI 같은 기계 판독 가능한 계약과 명확한 인증 안내가 있는가.
Vercel의 Agent Readability 가이드도 비슷한 구성을 제안한다. llms.txt, robots.txt, XML 및 Markdown 사이트맵은 발견성을 돕고, 페이지의 canonical 태그와 구조화 데이터, 적절한 헤딩은 문서 구조를 설명한다. HTML만 제공하는 페이지라면 Markdown 미러나 Accept: text/markdown 콘텐츠 협상을 추가하는 방법도 제시한다. 이 항목들은 새 표준을 맹신하라는 뜻이 아니라, 에이전트가 추측하지 않아도 되는 정보를 늘리자는 제안으로 읽는 편이 맞다.
AI 검색 최적화와는 다른 문제
요즘은 llms.txt 하나를 두면 AI 검색에 잘 노출된다는 식의 설명도 많다. 하지만 파일 하나로 해결되는 문제는 아니다. 사이트맵이 있어도 핵심 문서가 내부 링크에서 끊겨 있으면 발견되지 않을 수 있다. HTML에 보기 좋은 카드만 있고 본문 텍스트가 빈약하면 에이전트는 내용을 정확히 뽑기 어렵다. API 설명이 있어도 인증 방식, 오류 응답, 사용 제한이 빠져 있으면 실제 연동 단계에서 멈춘다.
is-agentic의 장점은 이런 문제를 한 장의 성적표로 보여 주는 데 있다. 하지만 성적표의 항목과 가중치는 도구 제공자의 설계다. Ora는 전체 랭커에서 실제 에이전트 실행에 따라 항목 중요도를 조정한다고 밝히고, is-agentic은 콘텐츠 사이트에 맞춘 단순화된 점수라고 구분한다. 따라서 결과를 외부 인증서처럼 받아들이기보다, 어떤 요청이 실패할 수 있는지 찾는 출발점으로 쓰는 것이 안전하다.
특히 공개 웹과 로그인 뒤의 제품 경험은 다르다. 공개 문서는 에이전트가 잘 읽어도 실제 작업에 필요한 계정 권한, 결제 승인, 개인정보 처리, 속도 제한은 별도 설계가 필요하다. 에이전트 친화성과 무단 접근 허용을 혼동해서도 안 된다. 공개할 정보와 인증 뒤에만 둘 정보를 구분한 다음, 허용된 경로에서 필요한 작업만 가능하게 해야 한다.
작은 사이트에서 해 볼 수 있는 점검 순서
처음부터 모든 권고를 적용할 필요는 없다. 블로그나 개인 문서 사이트라면 먼저 대표 문서 몇 개를 기준으로 진단해도 충분하다.
- 현재 상태를 기록한다. is-agentic에서 도메인을 검사하고, 점수보다 실패한 항목과 근거를 저장한다. 배포 전후 비교를 하려면 검사 날짜와 대상 URL도 함께 남겨 둔다.
- 발견 경로를 하나씩 확인한다. sitemap.xml에 중요한 글과 문서가 있는지, robots.txt가 의도와 다르게 막고 있지 않은지, 내부 링크만으로도 핵심 페이지에 도달할 수 있는지 본다. 새 파일을 만들기 전에 기존 경로의 오류부터 고치는 편이 효과가 크다.
- 대표 페이지의 원문을 줄인다. 브라우저 화면은 화려하지만 본문이 스크립트 뒤에서만 생성되는 페이지가 있다. 제목, 요약, 헤딩, 본문 텍스트, 업데이트 날짜가 초기 응답에 충분히 들어가는지 확인한다. API 문서라면 사람이 읽는 설명과 기계가 읽는 스키마가 서로 어긋나지 않는지도 본다.
이 순서에서 llms.txt는 선택지 중 하나다. 기술 문서가 많다면 Markdown 인덱스와 함께 도움이 될 수 있다. 반대로 짧은 소개 페이지라면 정확한 제목, 본문, 메타데이터, 사이트맵을 정리하는 것이 먼저일 가능성이 크다. 필요한 기능보다 유행하는 파일을 먼저 추가하면 관리 대상만 늘어난다.
운영 지표로 쓰려면 작업 성공률과 나란히 둬야 한다
에이전트 친화성 점수는 배포 품질 지표의 보조 수단으로는 쓸 수 있다. 예를 들어 문서 개편 뒤에 점수가 떨어졌다면, 누락된 canonical 태그나 깨진 사이트맵처럼 반복 가능한 문제를 조기에 찾을 수 있다. CI에서 JSON 결과를 비교하는 방식도 가능하다.
다만 제품 의사결정은 실제 과제로 검증해야 한다. 에이전트에게 공개 문서에서 설치 방법을 찾아 요약하게 하거나, API 문서만으로 샘플 호출을 구성하게 한 뒤 어디서 멈췄는지 기록하는 식이다. 점수는 개선됐는데 이 과제가 계속 실패한다면, 체크리스트에 없는 문맥이나 인증 안내가 병목일 수 있다. 반대로 점수가 평범해도 목표 작업이 안정적으로 끝난다면 당장 큰 공사를 할 이유는 약하다.
이번 도구가 보여 주는 변화는 웹사이트도 에이전트의 입력과 작업 환경이 되고 있다는 점이다. 그렇다고 모든 사이트를 에이전트용으로 바꿔야 하는 것은 아니다. 공개 정보의 정확한 전달이 중요한 곳부터, 사람이 읽는 경험을 해치지 않는 범위에서 기계가 확인할 수 있는 구조를 보강하면 된다. 점수를 올리는 것보다 에이전트가 무엇을 찾아야 하고 어디에서 멈춰야 하는지를 분명히 하는 일이 먼저다.
참고 자료
- Is Agentic: AI Agent Readiness Score for your Site and App
- We partnered with Vercel to launch is-agentic.com | Ora
- Agent Readability: A Specification for AI-Optimized Websites | Vercel Knowledge Base
- Vercel Introduces 'Is Agentic', a Free Agent-Readiness Scoring Tool That Audits Public Websites Using Ora's 100+ Checks