에이전트 준비도 점수, 그대로 쫓아야 할까 — 레벨 1에서 Agent-Native까지
요약 — isitagentready.com은 우리 사이트를 29점, 레벨 1로 판정했다. 점수표를 그대로 채우는 대신 실체가 있는 것만 골랐다. Content Signals, 마크다운 협상, Agent Skills, 그리고 진짜 MCP 서버와 DNS-AID·DNSSEC까지 구축해 71점, 레벨 5 Agent-Native가 됐다. 스킵한 4개에도 이유가 있다. 없는 서비스의 메타데이터는 에이전트에게 하는 거짓말이다.
Cloudflare가 Agents Week에 내놓은 isitagentready.com은 사이트가 AI 에이전트를 맞을 준비가 됐는지 20개 체크로 점수를 매긴다. 프레이밍이 인상적이다. "웹은 브라우저에게, 다음엔 검색엔진에게 말하는 법을 배웠다. 이제 AI 에이전트에게 말하는 법을 배워야 한다."1 우리 사이트를 돌려보니 결과가 썩 좋지 않았다. 29점, 레벨 1 "Basic Web Presence". 미비 항목이 10개였다.
Lighthouse가 그랬듯 점수는 사람을 움직인다. 그래서 채우기 전에 먼저 물었다. 이 점수는 무엇을 측정하는가.
점수는 세 가지를 섞어서 잰다
에이전트 준비도 점수 도구들은 하나의 축이 아니라 서로 다른 세 차원을 측정한다.2
| 차원 | 질문 | 대표 체크 |
|---|---|---|
| 콘텐츠 접근성 | 에이전트가 페이지를 읽을 수 있나 | 마크다운 제공, llms.txt, SSR |
| 프로토콜 채택 | 신흥 표준을 구현했나 | MCP Server Card, API Catalog, OAuth 디스커버리 |
| 실트래픽 정합 | 실제 에이전트가 그 표준을 쓰나 | 서버 로그의 .well-known 프로브 실측 |
세 차원은 서로를 보상하지 않는다. AFDocs 스펙 저자 Dachary Carey는 자기 사이트를 두 도구로 스캔해 이를 실증했다. 코딩 에이전트가 완벽하게 읽는 사이트(AFDocs 100/100)가 Cloudflare 기준으로는 33점, "Level 1: Basic Web Presence"였다.2
실트래픽 쪽 근거는 더 아프다. Cloudflare가 점수를 주는 표준 중 MCP Server Card와 API Catalog는 상위 20만 도메인에서 채택이 합쳐서 15곳 미만이고, 에이전트 트래픽이 많은 사이트의 서버 로그에서도 이 .well-known 엔드포인트를 찾는 요청은 사실상 없었다.2 robots.txt와 sitemap은 GPTBot 같은 크롤러용이지 코딩 에이전트용이 아니라는 지적도 유효하다. 점수의 큰 몫은 아직 오지 않은 미래에 대한 준비도를 잰다.
그렇다고 점수가 무의미하냐면, 그것도 아니다. Cloudflare Radar 데이터셋 기준 상위 20만 도메인에서 robots.txt는 78%가 갖췄지만 Content Signals는 4%, 마크다운 협상은 3.9%다.1 표준이 채택 초기라는 뜻이고, 채택 추이는 "언제 프로토콜 계층에 투자할지"를 알려주는 신호로 쓸 수 있다.
우리 기준: 실체가 있는 것만
10개 항목을 하나씩 검토하며 원칙을 하나 세웠다. 존재하지 않는 서비스의 메타데이터를 게시하지 않는다. 보호된 API가 없는데 OAuth 디스커버리 문서를 올리고, 서버가 없는데 MCP 카드를 게시하면 점수는 오르지만 에이전트에게는 거짓 신호를 준다.
| 판정 | 항목 | 근거 |
|---|---|---|
| 적용 | Content Signals | robots.txt 몇 줄, AI 크롤러가 파싱 시작한 실표준 |
| 적용 | Markdown for Agents | 콘텐츠 접근성 층, 세 차원 중 효과가 검증된 유일한 층 |
| 적용 | Agent Skills index | 상담 요청·콘텐츠 접근이라는 실체 있는 스킬 |
| 적용 | MCP Server Card + API Catalog | 서버를 실제로 만들어서 실체를 채움 |
| 적용 | DNS-AID + DNSSEC | MCP 엔드포인트가 생겼으니 가리킬 대상이 있음 |
| 스킵 | OAuth 디스커버리 ×2, auth.md | 인증 대상 서비스가 없음 |
| 스킵 | WebMCP | Chrome Early Preview 단계, 표준 안정화 전 |
절반은 채우고 절반 가까이는 의도적으로 비워뒀다. 다만 우리는 AX 컨설팅 회사다. 고객에게 "에이전트 대응"을 말하려면 우리 사이트가 먼저 실증이어야 한다. 그래서 프로토콜 계층도 트래픽이 나타나길 기다리는 대신, 실체를 만들어서 앞당겨 채우기로 했다.
실제로 만든 것들
에이전트가 사이트와 만나는 접점은 세 층이다. 발견하고, 읽고, 행동한다.
읽기: 마크다운 협상
같은 URL에 Accept: text/markdown 헤더를 보내면 HTML 대신 마크다운을 받는다. 브라우저는 이 헤더를 보내지 않으니 사용자 경험은 그대로다. Cloudflare 자체 벤치마크로는 마크다운 협상이 토큰을 최대 80%까지 줄인다(자체 측정이라 수치는 참고만).1
구현은 미들웨어 분기 하나와 라우트 하나로 끝났다. 인사이트 아티클은 원본이 MDX라 사실상 원문을 그대로 내보내고, 나머지 페이지는 HTML을 변환하는 대신 페이지를 만들 때 쓴 구조화 데이터에서 마크다운을 새로 조립한다. HTML과 마크다운이 같은 소스에서 나오므로 어긋날 일이 없다.
발견: Content Signals와 스킬 인덱스
robots.txt에 세 값을 선언했다.
User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /
ai-train=yes는 정책 판단이다. 콘텐츠 수익을 보호해야 하는 미디어라면 no가 맞을 수 있다. 우리는 마케팅 사이트라서 미래 모델이 우리 콘텐츠를 학습하는 것 자체가 브랜드 노출이다. 이 트레이드오프는 사이트마다 답이 다르다.
/.well-known/agent-skills/에는 스킬 인덱스를 올렸다. "상담을 요청하는 법", "콘텐츠를 마크다운으로 읽는 법", "MCP 서버를 쓰는 법" 세 개다. 각 SKILL.md의 sha256 다이제스트를 빌드 시점에 계산해 인덱스와 본문이 어긋나지 않게 했다.
행동: 진짜 MCP 서버
MCP Server Card를 게시하려면 MCP 서버가 있어야 한다. 그래서 만들었다. mcp-handler로 Next.js 라우트 하나에 Streamable HTTP 서버를 올리고 도구 7개를 붙였다. 서비스·케이스·인사이트를 조회하는 콘텐츠 도구 여섯 개와, 상담을 접수하는 request_consultation이다.
상담 도구는 새 백엔드를 만들지 않았다. 웹 폼이 쓰는 서버 액션을 그대로 호출한다. 검증도 메일 발송도 한 벌이고, 에이전트가 접수한 상담은 사람이 폼으로 보낸 것과 같은 채널로 도착한다. 에이전트용 기능이라고 별도 시스템을 세우면 유지보수가 두 배가 된다.
신뢰: DNS-AID와 DNSSEC
DNS-AID는 DNS로 에이전트 엔드포인트를 광고하는 IETF 초안이다.3 MCP 서버가 생겼으니 가리킬 대상이 생겼다. Route 53에 SVCB 레코드 두 개를 올렸다.
_index._agents.801pla.net. 3600 IN SVCB 1 801pla.net. alpn="h2" port="443"
_mcp._agents.801pla.net. 3600 IN SVCB 1 801pla.net. alpn="h2" port="443"
초안은 검증 리졸버가 인증된 답을 받도록 존을 DNSSEC로 서명하라고 요구한다. 도메인이 Route 53 Domains에 등록돼 있어서 KMS 키 생성부터 KSK, 존 서명, 레지스트라 DS 등록까지 한 계정에서 끝났다. 존과 레지스트라가 같은 곳이면 DNSSEC 사고의 주 원인인 둘 사이의 불일치가 구조적으로 사라진다.
전환 과정에서 배운 것 하나. DS가 부모 존에 게시된 직후 Cloudflare 리졸버가 잠시 SERVFAIL을 반환했다. 서명 전에 캐시된 응답과 새 신뢰 체인이 충돌하는 전환기 현상으로, 존 서명을 먼저 하고 DS를 나중에 넣는 순서가 이 창을 최소화한다. 해제할 일이 생기면 반드시 역순이다. DS를 먼저 빼고, 전파를 기다린 뒤에 서명을 끈다. 순서를 어기면 도메인 전체가 해석 장애를 겪는다.
재스캔 결과는 71점, 레벨 5 "Agent-Native". Discoverability·Content·Bot Access Control이 100점이 됐고, Discovery 카테고리에 남은 미비 항목은 전부 의도적으로 비워둔 것들이다(OAuth 계열과 WebMCP).
SEO에도 도움이 될까
부분적으로만 겹친다. 콘텐츠 접근성 층(마크다운 제공, AI 크롤러 허용)은 생성형 검색 인용에 기여하지만, 점수의 큰 몫인 프로토콜 층은 검색 가시성과 무관하다. 생성 엔진은 답변을 만들 때 MCP 카드나 OAuth 메타데이터를 조회하지 않는다.
주의할 점도 있다. llms.txt는 30만 도메인 규모 연구에서 LLM 인용과의 통계적 상관이 확인되지 않았고,4 Content Signals로 AI 봇을 엄격히 차단하면 생성 답변 인용이 줄어 오히려 AI 가시성과 상충한다. 검색·인용이 목적이라면 점수가 아니라 겹치는 층만 선별해서 실행하는 편이 낫다.
판단
에이전트 준비도 점수는 성적표가 아니라 로드맵 신호로 읽는 게 맞다. 콘텐츠 접근성 층은 지금 효과가 있으니 먼저 하고, 프로토콜 층은 원칙적으로는 서버 로그에 그 표준을 찾는 요청이 나타날 때 구현하면 된다.2 우리는 브랜드 실증 가치 때문에 그 시점을 앞당겼지만, 그 경우에도 순서는 같다. 실체를 먼저 만들고, 메타데이터는 그 다음이다.
점수보다 나은 검증도 있다. 실제 에이전트에게 사이트를 쓰게 해보는 것이다. Claude Code 같은 코딩 에이전트로 30분만 돌려보면, 어떤 점수도 알려주지 않는 것들이 보인다.
에이전트 대응을 포함한 AI 전환의 방향이 고민이라면 AX 컨설팅에서, 이런 인프라를 직접 구축할 팀이 필요하다면 클라우드 & 인프라에서 시작할 수 있다.
참고 자료
Footnotes
-
André Jesus, Vance Morrison (Cloudflare), "Introducing the Agent Readiness score. Is your site agent-ready?" (2026-04-17). Radar 채택 통계와 토큰 절감 벤치마크(자체 측정) 포함. https://blog.cloudflare.com/agent-readiness/ ↩ ↩2 ↩3
-
Dachary Carey, "What an Agent Score Can Tell You" (2026-04-18). AFDocs 100/100 대 Cloudflare 33/100 실증,
.well-known실트래픽 로그 분석. https://dacharycarey.com/2026/04/18/what-agent-score-can-tell-you/ ↩ ↩2 ↩3 ↩4 -
IETF Internet-Draft, "DNS for AI Discovery (DNS-AID)". SVCB/HTTPS 레코드 기반 에이전트 엔드포인트 발견. https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/ ↩
-
llms.txt 보유와 LLM 인용 간 상관관계를 다룬 30만 도메인 연구 인용. 도구 벤더 주장과 실측이 엇갈려 낮은 신뢰도로 취급한다. ↩