측정 항목
22개 항목을 잽니다. 각 항목마다 그 값이 무엇을 뜻하는지, 어떤 요청을 보내 어떻게 정하는지, 개선하면 무엇이 달라지는지를 적었습니다. 배점과 계산식은 실제로 실행되는 코드에서 가져온 값입니다.
에이전트는 왼쪽에서 오른쪽으로 나아갑니다. 앞 단계에서 막히면 뒤 단계는 측정 자체가 되지 않습니다 — 못 들어온 사이트의 완수율을 재는 일은 성립하지 않기 때문입니다.
Meta는 2026년 9월 8일 개인 에이전트 Muse를 내놓았습니다. 먼저 Meta가 공식 발표에서 직접 보여 준 장면을 보고, 이어서 출시 뒤 2주 동안 나온 실사용 리뷰에서 그 장면이 실제로 어디서 끝나고 어디서 막혔는지를 봅니다. 일이 끝나느냐 막히느냐는 모델보다 웹사이트 쪽에서 갈렸습니다.
AI 안경을 쓰고 진열대의 상품, 벽의 전단지, 긴 학교 준비물 목록을 보며 물으면 Muse가 “행동한다”고 Meta는 소개했습니다. 같은 무대에서 월마트 · 베스트바이 · 세포라 · 웨이페어 등 제휴 매장과 Shopify 전체 카탈로그, Shop Pay · PayPal 결제를 발표했습니다.
목록의 “3공 바인더 1인치”를 수백 개 상품에서 골라 가격 · 재고 · 도착일을 비교합니다. 상품 페이지가 원문 HTML과 Product 구조화 데이터로 이 값을 내놓아야 후보에 듭니다.
인스타그램에 저장한 레시피 릴스를 장보기 목록으로 바꾸고, 저녁 파티 메뉴를 제안하고, 친구들의 식이 제한을 기억했다가 초대장을 보냅니다. 결제는 Stripe의 Link로 하며, Meta는 Muse가 Link의 구매자 보호를 받는 첫 AI 에이전트라고 설명합니다.
재료마다 “이 가게에 있나, 얼마인가, 글루텐이 들었나”를 확인합니다. 원재료 · 알레르기 정보 · 가격이 이미지가 아니라 본문 텍스트에 있어야 친구의 식이 제한을 지킬 수 있습니다.
Meta는 Muse가 브라우저를 열고 양식을 채우며 사용자를 대신해 협상한다고 밝혔습니다. 예로 든 일은 차를 더 좋은 값에 팔기, 청구서 금액 낮추기, 생활이 바뀔 때마다 운동 계획 고치기입니다. Muse는 사용자마다 따로 둔 가상 머신(Muse Secure VM) 안에서 일합니다.
견적 · 문의 · 해지 양식이 “사람인지 확인” 화면 없이 열려 있어야 하고, 예약 · 견적 같은 기능을 MCP나 API로 열어 두면 양식을 한 칸씩 흉내 낼 필요가 없습니다.
그림은 AOO가 발표 내용을 설명하려고 그린 일러스트이며 Meta의 이미지나 실제 Muse 화면이 아닙니다.
CNN 기자가 여러 쇼핑몰에서 물건 구매를 맡김
에이전트를 막는 것은 사이트의 정책 선택입니다. 다만 막는 순간 그 에이전트를 쓰는 고객의 구매도 함께 막히고, 에이전트는 사이트 밖에서 답을 찾습니다. AOO는 이 문을 robots.txt · AI 크롤러 · 방화벽 · 확인 화면으로 나눠 보여 줍니다.
“근처에 글루텐프리 맥주 파는 식당 찾아 줘”
에이전트는 사이트에 적힌 만큼만 정확합니다. 메뉴 · 영업 여부 · 전화번호가 사이트 본문과 구조화 데이터에 있으면 추측할 이유가 없습니다. AOO가 “답에 나온 값이 사이트에도 있어야 완수”로 판정하는 이유입니다.
“데이트할 저녁 자리 예약해 줘” · “이사업체 견적 비교해 줘”
예약 · 견적 · 결제처럼 기능이 열려 있으면 에이전트는 읽기를 넘어 일을 끝냅니다. Meta는 Stripe Link(100만 곳 이상)와 Shopify Shop Pay로 결제 길을 넓히는 중입니다. 다음 경쟁은 “에이전트가 호출할 수 있는 사이트”인지입니다.
화면은 기사 내용을 바탕으로 다시 그린 것이며 실제 Muse 화면이 아닙니다.
아마존은 Muse의 접속에 “허가받지 않은 AI 에이전트” 경고를 띄웠고, 타깃은 둘러보기는 허용하되 결제 클릭을 막았습니다. 어디서 막히든 사용자는 “여기서는 안 된다”는 답을 듣고, 사이트는 손님이 왔었다는 사실조차 모릅니다.
아마존에 들어가지 못한 Muse는 검색엔진에서 상품 링크를 찾아왔습니다. 사이트 안을 걷지 못한 에이전트는 사이트 밖의 정보로 답을 만듭니다. 원문 HTML의 링크와 사이트 내 체류율을 재는 이유입니다.
글루텐프리 맥주 식당을 찾던 Muse는 몇 년 전 문 닫은 식당을 추천했습니다. 영업 여부 · 메뉴 · 위치를 사이트가 기계용 안내와 구조화 데이터로 알려 주지 않으면, 에이전트는 오래된 외부 데이터를 믿습니다.
식당 웹사이트에 해당 메뉴가 없자 Muse는 확인하지 않은 전화번호를 지어냈습니다. AOO는 답에 나온 금액 · 기간 · 전화번호가 사이트 본문에도 있을 때만 “완수”로 칩니다.
OpenTable 예약과 이사업체 견적 양식은 끝까지 처리됐습니다. 예약 · 견적 · 결제 같은 기능을 열어 둔 사이트에서 에이전트는 읽기를 넘어 일을 끝냅니다.
100점은 작업 완수율 35 · 자체 출처 인용 20 · 안내 따라가기 20 · 자체 발견 15 · 응답 신뢰도 10으로 계산합니다. 카드 오른쪽 위의 배점은 그 항목이 어디에 얼마만큼 들어가는지를 뜻하고, “보고 전용”은 점수에 넣지 않고 리포트에만 보여 주는 항목입니다. 앞 단계에서 막히면 뒤 단계는 잴 수조차 없다는 점이 가장 중요합니다 — 못 들어온 사이트의 완수율은 존재하지 않습니다.
사람은 주소창에 도메인만 쳐도 브라우저가 알아서 www로, https로 넘어가 줍니다. 에이전트는 같은 요청을 보내도 리디렉션이 꼬여 있거나 응답이 없으면 거기서 포기합니다. 모든 측정의 출발점이라, 이 문이 열리지 않으면 나머지 항목은 잴 수조차 없습니다.
에이전트가 홈페이지 응답을 받아낼 수 있는가. 리디렉션을 몇 번 거치는가.
example.com → https://www.example.com/ 으로 한 번 넘어가 200 응답. 90점.
example.com → /ko → /ko/main → /ko/main?lang=ko → 다시 /ko 로 도는 순환. 사람의 브라우저는 쿠키 덕분에 빠져나오지만, 쿠키를 들고 다니지 않는 에이전트는 끝없이 돕니다. 0점.
여기서 0점이면 나머지 세 영역이 전부 0이 됩니다. 콘텐츠 품질과 무관하게 진단이 성립하지 않습니다.
주의 apex(example.com)만 두고 www로만 서비스하는 경우가 흔합니다. AOO는 apex와 www를 모두 시도해 실제 서비스되는 쪽을 씁니다.
검색 크롤러나 스크래퍼를 막으려고 넣은 robots.txt 규칙과 방화벽 설정이, 사용자를 대신해 온 AI 에이전트까지 막는 경우가 많습니다. 사이트 주인은 막았다는 사실조차 모르는 경우가 대부분입니다.
robots.txt나 방화벽이 에이전트를 걸러내는가.
robots.txt에서 /admin/ 같은 관리 경로만 Disallow하고, 공개 페이지는 모두 열어 둔 사이트.
User-agent: * 아래 Disallow: / 한 줄. 개발 서버용 설정이 운영 서버에 그대로 올라간 경우가 흔합니다. AOO는 이 사이트를 진단하지 않고 “robots.txt 차단”으로 기록합니다.
차단을 풀면 진단이 시작됩니다. 지금은 점수가 아니라 존재 자체가 없는 상태입니다.
* 그룹에 Disallow: /가 있는지 확인하세요.실측 진단 자체가 막힌 36곳 중 27곳이 robots.txt로 스스로 막고 있었습니다. 대개 크롤러를 막으려다 에이전트까지 막은 경우입니다.
주의 403·429는 신뢰도 계산에서 아예 빼냅니다. 포함시키면 사이트 품질이 아니라 WAF 정책을 재게 되기 때문입니다.
이제 “AI 에이전트”는 하나가 아닙니다. Meta, OpenAI, Google, Anthropic, Perplexity가 각각 모델 학습용 · AI 검색용 · 사용자 요청용 크롤러를 따로 운영하고, robots.txt도 이름별로 따로 해석됩니다. 학습을 막으려고 GPTBot을 막은 것은 괜찮지만, 같은 줄에 OAI-SearchBot까지 넣으면 ChatGPT 검색 답변에서 사이트가 빠집니다.
robots.txt가 AI 회사별 크롤러 16종을 각각 허용하는지, 일부 제한하는지, 차단하는지. Meta(Muse) · OpenAI · Google · Anthropic · Perplexity · Apple · Common Crawl.
* 묶음을 적용User-agent: GPTBot과 User-agent: meta-externalagent만 Disallow: /, 나머지는 허용. 모델 학습에는 쓰이지 않으면서 ChatGPT와 Meta AI의 답변에는 출처로 인용됩니다.
보안 솔루션이 권한 “AI 봇 전체 차단” 목록을 그대로 붙여 meta-webindexer, OAI-SearchBot, PerplexityBot까지 막은 사이트. Muse 이용자가 이 브랜드를 물으면 다른 사이트의 설명이 답이 됩니다.
Meta AI, ChatGPT, Gemini, Claude, Perplexity가 “이 사이트를 읽어도 되는가”를 판단하는 첫 관문입니다. 학습은 막고 답변용 읽기는 허용하는 식의 세밀한 설정을 리포트에서 바로 확인할 수 있습니다.
주의 robots.txt는 요청일 뿐 강제력은 없습니다. Meta 문서에 따르면 사용자가 직접 요청한 가져오기와 링크 미리보기는 robots.txt를 따르지 않을 수 있습니다. 점수에는 넣지 않습니다 — 학습 거부는 정당한 정책 선택입니다.
에이전트는 작업 하나에 페이지를 10~30번 엽니다. 그중 몇 번이 404나 500을 받으면 그만큼 헛걸음을 하고, 정해진 시간 안에 답을 못 찾을 확률이 올라갑니다.
에이전트가 보낸 요청 중 2xx로 정상 응답한 비율.
작업 10개를 하는 동안 보낸 요청 180건 중 176건이 200. 신뢰도 98%.
메뉴의 “고객센터” 링크가 개편 전 주소(/cs/main.do)를 가리켜 매번 404. 에이전트가 여러 작업에서 같은 링크를 반복해 누르며 신뢰도가 60%대로 떨어집니다.
404·500이 줄면 에이전트가 헛걸음에 쓰는 단계가 줄고 완수율이 함께 오릅니다.
에이전트는 구조를 모르는 사이트에서 흔한 주소(/pricing, /support, /faq)를 먼저 찍어 봅니다. 없는 주소에 “페이지를 찾을 수 없습니다” 화면을 200 상태로 돌려주면, 에이전트는 그 페이지가 있다고 믿고 엉뚱한 내용으로 답을 만듭니다.
존재하지 않는 URL에 무엇을 돌려주는가.
/pricing이 없으면 404, API 경로에서는 {"title":"Not Found","status":404} 형식의 problem+json.
없는 모든 주소가 홈 화면을 200으로 돌려주는 사이트. 에이전트가 /refund-policy를 열고, 홈의 이벤트 배너 문구를 환불 규정이라며 답합니다.
404를 제대로 돌려주는 것만으로 오답이 줄어듭니다. 에이전트는 주소를 자주 헛짚는데, 200을 받으면 자기가 틀렸다는 걸 알 방법이 없어 엉뚱한 페이지 내용으로 답을 만듭니다.
실측 측정된 230곳 중 56곳(24%)이 없는 URL에 200 OK를 돌려줍니다.
대부분의 AI 에이전트는 브라우저를 띄우지 않고 서버가 보낸 HTML 원문만 읽습니다. 메뉴와 링크가 자바스크립트로만 그려지면 에이전트 눈에는 빈 페이지이고, 다음으로 갈 길이 없습니다.
자바스크립트를 실행하지 않은 상태의 HTML에 따라갈 링크가 몇 개 있는가.
원문 HTML에 <a href="/support">고객센터</a>, <a href="/pricing">요금</a> 같은 링크가 60개. 홈에서 바로 목적 페이지로 갑니다.
원문 HTML이 <div id="root"></div>와 스크립트 태그뿐. 링크 0개 — 에이전트는 외부 검색에 기댈 수밖에 없습니다.
가장 비용 대비 효과가 큰 항목입니다. 주요 경로를 원문 HTML의 링크로 남기면 에이전트가 홈에서 다음 단계로 나아갈 수 있습니다.
<a href>를 쓰세요.실측 항공사 20곳 평균이 39점인 이유가 이것입니다. 예약 엔진이 전부 자바스크립트 뒤에 있어 에이전트가 홈에서 한 발짝도 못 나갑니다.
주의 사람이 브라우저에서 보는 화면과 다릅니다. 그 차이 자체가 진단 대상입니다.
에이전트가 답을 찾는 동안 당신 사이트를 읽었는지, 검색 결과와 다른 사이트를 떠돌았는지를 보여줍니다. 밖에서 찾은 답은 당신이 통제할 수 없는 정보(오래된 블로그, 비교 사이트, 커뮤니티 글)가 됩니다.
에이전트가 보낸 요청 중 이 도메인(또는 서브도메인)을 향한 비율.
요청 20건 중 18건이 자사 도메인. 체류율 90%.
요청 20건 중 12건이 검색 엔진과 커뮤니티 글. 에이전트가 3년 전 블로그의 요금표로 답합니다.
이 값이 낮으면 에이전트가 답을 외부 검색에서 찾고 있다는 뜻입니다. 즉 당신 사이트는 읽히는 게 아니라 지나쳐지고 있습니다.
주의 이 항목이 있기 때문에, 아무도 따라가지 않는 llms.txt를 올려두는 것만으로 가로축을 살 수 없습니다.
같은 페이지에 도착해도 어떻게 찾았는지가 다릅니다. 사이트 링크를 따라왔다면 사이트가 길을 안내한 것이고, 모델이 “보통 /faq에 있겠지” 하고 찍어서 맞혔다면 운이 좋았던 것입니다. 운은 모델이 바뀌거나 사이트가 개편되면 사라집니다.
에이전트가 각 URL을 어떻게 알아냈는가를 8종으로 분류한 것.
홈 →(링크) 고객센터 →(링크) 환불 정책. 모든 단계가 “사이트가 안내한 경로”로 기록됩니다.
첫 요청부터 /en/terms/refund.html을 직접 입력(model_recall). 이번엔 맞았지만 다음 개편 때는 404입니다.
model_recall와 web_search 비중이 높다면, 지금 에이전트는 당신 사이트가 아니라 자기 짐작과 검색 결과로 답하고 있습니다. 사이트가 통제할 수 없는 경로입니다.
사람에게 메뉴가 있다면 기계에게는 llms.txt와 사이트맵이 있습니다. 에이전트가 사이트에 들어와 “어디부터 읽어야 하지?”를 푸는 가장 빠른 방법입니다.
llms.txt · sitemap.xml · robots.txt의 존재 여부.
/llms.txt에 사이트 한 줄 소개와 “- [환불 정책](https://example.com/policy/refund): 수령 후 7일 이내 신청” 같은 목록 20줄, 그리고 자동 생성되는 sitemap.xml.
llms.txt는 없고, sitemap.xml은 3년 전에 만들어져 절반이 404.
llms.txt는 "여기부터 읽어라"를 알려주는 가장 직접적인 수단이고 파일 하나면 됩니다. 다만 실제 주요 경로를 담아야 체류율까지 함께 오릅니다.
Sitemap: 줄을 넣으세요.주의 사이트맵을 여러 개로 쪼개 인덱스로 묶은 경우도 사이트맵으로 인정합니다.
“이 사이트는 무엇을 하는 어느 회사인가”를 기계가 읽는 형식으로 밝혀 두는 것입니다. 에이전트가 이름이 비슷한 다른 회사와 헷갈리거나, 공식 사이트인지 추측하는 일을 줄여 줍니다.
홈페이지의 schema.org JSON-LD — 이 사이트가 무엇인지 기계가 읽을 수 있는 형태로 밝힌 것.
<script type="application/ld+json">에 Organization(회사명, 공식 주소, 연락처), 상품 페이지에는 Product와 Offer(가격).
JSON-LD가 있지만 쉼표 하나가 빠져 파싱에 실패 — 기계에게는 없는 것과 같습니다.
에이전트가 "이 도메인이 무엇을 하는 곳인지" 추측하지 않고 확인할 수 있습니다.
실측 측정된 사이트 대부분이 이미 갖고 있습니다 — 변별력이 낮은 항목입니다.
AOO의 핵심 질문은 “에이전트가 일을 끝냈는가”입니다. 그럴듯한 문장이 아니라 사용자가 실제로 쓸 수 있는 값 — 금액, 기간, 날짜, 연락처, 주소, 파일 — 이 답에 있고, 그 값이 사이트에도 적혀 있을 때만 끝난 것으로 봅니다.
시킨 일이 실제로 끝났는가. 완수(full) · 부분(partial) · 실패(failed).
“환불은 상품 수령 후 7일 이내에 신청할 수 있습니다 (출처: example.com/policy/refund)” — “7일 이내”가 그 페이지 본문에도 있으므로 완수.
“환불 정책은 고객센터 페이지에서 확인하실 수 있습니다”는 값이 없어 완수가 아닙니다. “14일 이내”라고 답했는데 사이트 어디에도 그 문구가 없다면, 모델이 지어낸 값으로 보고 인정하지 않습니다.
세로축의 절반 이상이 여기서 결정됩니다. 요금 페이지에 "문의 바랍니다"만 있으면 완수가 되지 않습니다 — 대조 가능한 값이 본문에 있어야 합니다.
주의 초기 버전은 "답변이 비어 있지 않으면 성공"으로 처리했고, 그 결과 에이전트가 검색 결과에서 끌어온 전화번호로도 만점이 나왔습니다. 그건 사이트의 성과가 아닙니다.
에이전트가 사용자에게 답하면서 “출처: 당신 사이트”를 붙이는 것은, AI 시대의 검색 결과 노출과 같습니다. 출처가 다른 사이트라면 사용자는 그 사이트로 갑니다.
최종 답변이 이 사이트의 URL을 근거로 댄 작업의 비율.
답변 끝에 example.com/pricing 링크가 붙어 있습니다.
답은 맞았는데 출처가 가격 비교 사이트입니다. 사용자는 비교 사이트에서 결제합니다.
같은 완수라도 자체 출처로 답한 쪽이 높게 평가됩니다. 에이전트가 당신 사이트를 출처로 인용하면 최종 사용자에게도 브랜드가 노출됩니다.
점수가 같아도 원인은 다릅니다. “자력 성공”과 “무거운 우회로 성공”은 둘 다 완수지만, 뒤쪽은 에이전트가 검색과 추측으로 겨우 찾은 것이라 모델이나 검색 결과가 바뀌면 실패로 바뀝니다.
작업이 어떤 방식으로 끝났거나 막혔는지의 분류.
작업 10개 중 8개가 자력 성공.
“이메일 벽에 막힘” — 요금표를 보려면 이메일을 입력해야 하는 폼이 앞을 막고 있습니다.
점수에는 들어가지 않지만 원인 진단에 쓰입니다. "무거운 우회로 성공"이 많다면 사이트가 답을 갖고는 있으나 도달 경로가 없다는 뜻입니다.
앞의 항목들은 에이전트가 사람처럼 페이지를 “읽는” 능력입니다. MCP는 에이전트가 사이트의 기능 — 재고 조회, 예약 가능 시간, 주문 상태 — 을 “직접 호출”하게 해 줍니다. 읽기에서 실행으로 넘어가는 단계입니다.
에이전트가 도구처럼 호출할 수 있는 살아 있는 JSON-RPC 서버.
/mcp에 initialize 요청 → 서버 이름과 search_products, get_order_status 같은 도구 목록이 돌아옵니다.
/.well-known/mcp.json 문서 파일만 있고 실제 엔드포인트는 응답이 없는 경우 — 준비된 척만 하는 상태입니다.
에이전트가 HTML을 읽는 대신 기능을 직접 호출합니다. 읽기에서 실행으로 넘어가는 유일한 항목입니다.
실측 230곳 중 10곳. 그중 9곳은 브랜드가 만든 것이 아니라 입점한 쇼핑몰 플랫폼이 딸려 보낸 것이고, 대부분 그 사실을 모르고 있습니다.
주의 문서 파일(mcp.json)이 아니라 살아 있는 엔드포인트를 찾습니다. Streamable HTTP 엔드포인트는 확장자가 없고 POST만 받기 때문에, GET으로만 찾으면 규격대로 만든 서버일수록 놓칩니다.
HTML에는 메뉴·광고·스크립트가 섞여 있어 에이전트가 본문을 골라내는 데 비용을 씁니다. 같은 주소에서 마크다운을 요청할 때 깔끔한 본문만 돌려주면, 읽기 비용과 잘못 읽을 위험이 함께 줄어듭니다.
Accept: text/markdown 요청에 마크다운으로 응답하는가.
Accept: text/markdown으로 /pricing을 요청하면 “# 요금 / - 베이직 월 9,900원 …” 같은 마크다운이 오고, 헤더에 Content-Type: text/markdown과 Vary: Accept가 있습니다.
헤더는 text/markdown인데 본문은 그대로 HTML — 인정하지 않습니다.
요청 헤더 한 줄로 에이전트가 HTML 파싱을 통째로 건너뜁니다. 적은 작업으로 읽기 비용을 가장 크게 줄이는 방법입니다.
Vary: Accept를 붙여 캐시가 HTML과 마크다운을 섞지 않게 하세요.실측 230곳 중 3곳.
API가 있어도 에이전트가 어떤 기능이 있고 무엇을 넣어야 하는지 모르면 쓰지 못합니다. OpenAPI 문서는 기능 목록과 사용법을 기계가 읽는 설명서입니다.
어떤 기능을 어떻게 호출하는지 적힌 기계 판독 문서.
/openapi.json에 오퍼레이션 24개, 모두 operationId(예: getOrderStatus)와 설명이 있습니다.
오퍼레이션 80개 중 설명이 있는 것은 5개 — 에이전트가 어느 것을 불러야 할지 고를 수 없습니다.
파일이 있는 것과 에이전트가 어느 기능을 부를지 고를 수 있는 것은 다릅니다. operationId와 설명이 그 차이를 만듭니다.
주의 "openapi"라는 문자열만 확인하던 시절, 4바이트짜리 응답을 주는 사이트가 100점을 받은 적이 있습니다. 지금은 실제 오퍼레이션을 셉니다.
상태 코드만 보면 정상(200)이지만, 실제로는 “로봇이 아닙니다” 확인, 로그인 화면, 본문을 가린 쿠키 동의창만 돌려주는 경우입니다. 사람은 클릭 한 번이면 지나가지만 에이전트는 거기서 멈춥니다.
상태 코드는 200인데 에이전트가 통과하지 못하는 것들 — CAPTCHA 챌린지, 로그인 리디렉션, 동의 전 본문을 가리는 쿠키 배너.
가입 폼에만 Turnstile을 붙이고 공개 페이지는 그대로 보여주는 사이트. 지문은 보이지만 차단으로 세지 않습니다.
모든 페이지에 들어갈 때마다 Cloudflare 챌린지가 먼저 뜨는 사이트. 에이전트는 “Just a moment…” 페이지만 읽고 작업 10개를 모두 실패합니다.
차단 벽 하나가 나머지 모든 개선을 무의미하게 만듭니다. 에이전트 User-Agent를 허용 목록에 넣거나 챌린지 대상에서 빼는 것만으로 진단이 성립합니다.
실측 222곳 중 CAPTCHA 스크립트가 있는 곳이 18곳, 그중 실제로 본문을 막은 곳이 12곳이었습니다. 진에어·에어부산·에어로케이·에어서울은 재진단에서 점수가 절반 이하로 내려갔습니다 (진에어 50 D → 18 F).
주의 구현 첫 판에서 이 구분을 하지 않아, 가입 폼에 Turnstile을 붙인 정상 사이트를 차단된 것으로 보고했습니다. 지문이 있는 것과 막고 있는 것은 다릅니다.
주의 차단은 상시가 아닙니다. 같은 사이트를 몇 분 뒤 다시 재면 정상 페이지를 주는 경우가 있습니다 — 유한킴벌리는 스캔에서 챌린지를 내밀었지만 재진단 때는 71KB 정상 페이지를 줘 93 A를 유지했습니다. 진단서의 차단 표시는 "그 시점에 관측됨"이지 "항상 막힌다"가 아닙니다. 진단 쪽 동시 요청이 스스로 챌린지를 유발할 수도 있어 프로브 동시성을 3으로 낮춰 두었습니다.
사람은 2초쯤 기다려 주지만, 에이전트는 작업 하나에 수십 번 요청하므로 지연이 곱해집니다. 페이지당 2초면 작업 하나에 1분이 넘고, 시간 제한에 걸려 중간에 끊깁니다.
요청을 보내고 첫 응답 헤더가 돌아오기까지의 시간.
첫 바이트까지 250ms. CDN 캐시가 적용된 정적 페이지.
홈페이지 첫 응답 2.4초. 방문자별 추천을 서버에서 매번 계산하느라 늦습니다.
에이전트는 한 작업에 수십 번 요청합니다. 지연이 쌓이면 작업이 시간 초과로 끊기고, 완수율이 그대로 떨어집니다.
주의 실패가 아니라 비용이라 감점 폭을 작게 잡았습니다. 임계값은 AgentSpeed가 공개한 기준을 따랐습니다 — 이 값을 공개한 유일한 도구입니다.
에이전트는 읽은 글자 수만큼 비용(토큰)을 씁니다. 스크립트와 스타일이 대부분인 페이지는 같은 정보를 얻는 데 몇 배 비싸고, 너무 길면 중간에 잘려 뒤쪽 정보를 놓칩니다.
script·style을 걷어낸 뒤 남는 본문 텍스트가 전체 HTML 바이트에서 차지하는 비율.
40KB HTML 중 본문 텍스트 30%.
600KB HTML 중 본문 2% — 인라인 스크립트와 추적 코드가 대부분입니다.
에이전트가 한 페이지를 이해하는 데 드는 토큰을 좌우합니다. 밀도가 낮으면 같은 답을 얻는 데 더 비싼 사이트가 됩니다.
실측 측정해 보면 격차가 큽니다 — 118KB를 보내면서 본문이 3%인 사이트가 있고, 11KB를 보내면서 본문이 0%인 자바스크립트 껍데기도 있습니다.
주의 조사한 어떤 도구도 이 값을 재지 않습니다. 아직 점수에 넣지 않고 관찰만 합니다 — 적정 구간을 정하려면 표본이 더 필요합니다.
에이전트 생태계의 새 표준들입니다. 지금은 거의 쓰이지 않지만, 쓰고 있는 플랫폼이 자동으로 붙여 준 경우가 있어 알고 있으면 좋습니다.
2026년에 실존하지만 아직 거의 아무도 쓰지 않는 에이전트용 표준들의 존재 여부.
/.well-known/api-catalog에 API 목록, /.well-known/agent-card.json에 에이전트 카드가 있습니다.
해당 경로에 아무 HTML이나 200으로 응답 — 필수 키가 없어 soft-404로 걸러집니다.
이미 갖고 있는데 모르는 경우가 있습니다. 진단서에 표시되니 확인해 보시기 바랍니다.
주의 배점을 작게 잡은 이유가 있습니다. 채택률이 0%에 가까워(Cloudflare 20만 도메인 조사에서 MCP 카드 15곳 미만) 크게 배점하면 전원이 똑같이 0점을 받아 축의 변별력만 사라집니다.
“크롤링은 허용하지만 학습은 거부한다”처럼 허용과 차단 사이의 입장을 기계가 읽는 형태로 밝히는 방법입니다. 전부 막아 버리는 것보다 원하는 것만 정확히 막을 수 있습니다.
robots.txt에서 크롤링 허용과 별개로 "학습에 써도 되는가", "AI 답변의 입력으로 써도 되는가"를 따로 밝히는 지시자.
Content-Signal: search=yes, ai-input=yes, ai-train=no — 검색과 답변 인용은 허용, 학습은 거부.
신호 없이 AI 크롤러를 모두 Disallow로 막음 — 학습뿐 아니라 AI 답변에 나올 기회까지 잃습니다.
허용과 차단 사이의 중간 지대를 표현할 수 있습니다. 크롤링은 열되 학습은 막는 식의 의사를 기계가 읽는 형태로 남깁니다.
주의 점수에 넣지 않습니다. 이것은 사이트의 정책 선언이지 품질이 아니며, 학습을 막는 선택을 감점하는 것은 측정이 아니라 편들기입니다.
연동 수단이 여러 개여도 에이전트는 가장 쓸 만한 하나를 씁니다. 약한 힌트를 여러 개 쌓는 것보다 제대로 된 하나가 낫다는 점을 점수에 반영했습니다.
위 계약 항목들을 하나로 합친 0–100 값.
제대로 응답하는 MCP 엔드포인트 하나 — 기본 100점.
껍데기 swagger.json, 빈 ai-plugin.json, 방치된 agents.json — 모두 약해 합쳐도 연동이라 보기 어렵습니다.
가장 강한 것 하나가 지배하는 구조입니다. MCP가 있으면 swagger.json이 있든 없든 연동된 사이트이고, 약한 힌트 다섯 개는 연동이 아니기 때문입니다.
조사한 상용 도구 — Vercel·Ora의 is-agentic(118개 체크), Cloudflare Agent Readiness(20만 도메인), AgentSpeed, AgentGrade — 은 모두 사이트의 정적 표면만 채점합니다. 반대로 학계 벤치마크(WebArena·Mind2Web·WebVoyager·WebCanvas)는 에이전트를 채점하지 사이트를 채점하지 않습니다. 에이전트를 실제로 붙여 작업 완수율을 내고 그것을 사이트 점수로 환산하는 방식은 조사 범위에서 AOO뿐이었습니다.
| 다른 도구 | AOO | |
|---|---|---|
| 무엇을 근거로 점수를 내는가 | 파일 존재 여부와 HTML 검사 — 실제 작업은 시켜보지 않음 | 10개 작업을 실제로 시키고, 답의 근거가 사이트 바이트에 있는지 대조 |
| 차단 요인 | AgentSpeed만 CAPTCHA·쿠키벽·로그인벽을 보며, 여기에 가중치 70%를 검 | 2026년 8월 도입. 지문 존재와 실제 차단을 구분해 판정 |
| 프로토콜 디스커버리 배점 | 일부 도구가 크게 배점 — 채택률이 0%에 가까워 전원이 같이 실패 | 탐지는 하되 최대 9점. 변별력을 지키기 위해 의도적으로 작게 |
| 응답 지연 | AgentSpeed만 측정 (<800ms 통과 / >1800ms 실패) | 같은 임계값을 채택. 실패가 아니라 비용이므로 감점 폭은 작게 |
| 본문 밀도 | 측정하는 도구 없음 | 측정해 보고. 표본이 쌓이기 전까지 점수에는 넣지 않음 |
| 차단된 사이트 처리 | 대부분 표본에서 제외 | 차단 자체를 결과로 보고 차트에 남김 (현재 36곳) |
조사 출처 · AgentReady 공개 표준 (Ora · Vercel) · Cloudflare Agent Readiness · AgentSpeed 채점 방식 · UCP 명세 · A2A 명세 v0.3 · WebCanvas / Mind2Web-Live
측정하지 않는 것. 로그인 뒤 화면, 지역별 차이, 일시적 장애는 관찰되지 않습니다. 높은 점수는 보안·접근성·법적 준수의 인증이 아니며, 에이전트가 읽고 일할 수 있다는 것만 말합니다.
재현성. 에이전트는 확률적으로 움직여 같은 사이트를 다시 재면 몇 점 차이가 날 수 있습니다. 1~2점 차이를 순위로 읽지 마십시오. 반면 사분면의 경계는 표본 백분위가 아니라 고정값 50이라, 사이트가 추가돼도 기존 위치는 움직이지 않습니다.
미측정 처리. 진단이 돌지 못한 항목은 0점이 아니라 미측정으로 기록하고 가중치를 재분배합니다. 재보지 않은 것을 나쁘다고 적는 것은 틀린 보고이기 때문입니다.