에이전트 준비도 점수, 그대로 쫓아야 할까 — 레벨 1에서 Agent-Native까지

Cloudflare가 Agents Week에 내놓은 isitagentready.com은 사이트가 AI 에이전트를 맞을 준비가 됐는지 20개 체크로 점수를 매긴다. 프레이밍이 인상적이다. "웹은 브라우저에게, 다음엔 검색엔진에게 말하는 법을 배웠다. 이제 AI 에이전트에게 말하는 법을 배워야 한다."¹ 우리 사이트를 돌려보니 결과가 썩 좋지 않았다. 29점, 레벨 1 "Basic Web Presence". 미비 항목이 10개였다.

Lighthouse가 그랬듯 점수는 사람을 움직인다. 그래서 채우기 전에 먼저 물었다. 이 점수는 무엇을 측정하는가.

점수는 세 가지를 섞어서 잰다

에이전트 준비도 점수 도구들은 하나의 축이 아니라 서로 다른 세 차원을 측정한다.²

세 차원은 서로를 보상하지 않는다. AFDocs 스펙 저자 Dachary Carey가 자기 사이트를 두 도구로 스캔한 사례가 이 차이를 보여준다. 코딩 에이전트 대상 평가에서 AFDocs 100/100을 받은 사이트가 Cloudflare 기준으로는 33점, "Level 1: Basic Web Presence"였다.²

실트래픽 쪽 근거도 제한적이다. Carey가 살펴본 자료에서 MCP Server Card와 API Catalog의 채택은 상위 20만 도메인 합계 15곳 미만이었고, 에이전트 트래픽이 많은 한 사이트의 서버 로그에서는 이 .well-known 엔드포인트를 찾는 요청이 관찰되지 않았다.² robots.txt와 sitemap은 GPTBot 같은 크롤러를 위한 표준이지 코딩 에이전트의 직접 사용을 보장하지도 않는다. 점수의 큰 몫은 아직 오지 않은 미래에 대한 준비도를 잰다.

그렇다고 점수가 무의미하냐면, 그것도 아니다. Cloudflare Radar 데이터셋 기준 상위 20만 도메인에서 robots.txt는 78%가 갖췄지만 Content Signals는 4%, 마크다운 협상은 3.9%다.¹ 표준이 채택 초기라는 뜻이고, 채택 추이는 "언제 프로토콜 계층에 투자할지"를 알려주는 신호로 쓸 수 있다.

우리 기준: 실체가 있는 것만

10개 항목을 하나씩 검토하며 원칙을 하나 세웠다. 존재하지 않는 서비스의 메타데이터를 게시하지 않는다. 보호된 API가 없는데 OAuth 디스커버리 문서를 올리고, 서버가 없는데 MCP 카드를 게시하면 점수는 오르지만 에이전트에게는 거짓 신호를 준다.

절반은 채우고 절반 가까이는 의도적으로 비워뒀다. 다만 우리는 AX 컨설팅 회사다. 고객에게 "에이전트 대응"을 말하려면 우리 사이트가 먼저 실증이어야 한다. 그래서 프로토콜 계층도 트래픽이 나타나길 기다리는 대신, 실체를 만들어서 앞당겨 채우기로 했다.

실제로 만든 것들

에이전트가 사이트와 만나는 접점은 세 층이다. 발견하고, 읽고, 행동한다.

읽기: 마크다운 협상

같은 URL에 Accept: text/markdown 헤더를 보내면 HTML 대신 마크다운을 받는다. 브라우저는 이 헤더를 보내지 않으니 사용자 경험은 그대로다. Cloudflare 자체 벤치마크로는 마크다운 협상이 토큰을 최대 80%까지 줄인다(자체 측정이라 수치는 참고만).¹

구현은 미들웨어 분기 하나와 라우트 하나로 끝났다. 인사이트 아티클은 원본이 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 초안이다.³ MCP 서버가 생겼으니 가리킬 대상이 생겼다. 아래 두 SVCB 레코드는 당시 draft-00을 기준으로 Route 53에 올렸던 구현 기록이다.

_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"

이후 공개된 draft-02는 조직 인덱스의 _index._agents는 유지하지만, 알려진 개별 에이전트의 주 소유자 이름은 일반 FQDN으로 두고 _agents 아래 이름은 AliasMode 인벤토리로 다룬다. MCP 신호도 alpn의 프로토콜 조합이나 실험적 bap 파라미터로 표현한다.³ 따라서 위의 _mcp._agents와 alpn="h2" 조합은 최신 초안 준수 예시가 아니다.

draft-00은 공개 권위 존에 DNSSEC를 요구했지만, draft-02는 일반 레코드 서명을 SHOULD로 바꿨다. TLSA 레코드를 쓰는 경우에는 그 레코드를 반드시 서명해야 한다.³ 우리는 도메인을 Route 53 Domains에 등록해 KMS 키 생성부터 KSK, 존 서명, 레지스트라 DS 등록까지 한 계정에서 처리했다. 존과 레지스트라를 한곳에서 관리하면 두 시스템 사이의 조정 누락과 불일치 위험을 줄일 수 있다.

왜 draft-02로 바로 교체하지 않았나

2026년 7월 16일에 두 공개 소비자로 다시 검증해보니 전환 기준이 선명해졌다. Cloudflare의 isitagentready.com은 현재 레코드 두 개와 DNSSEC를 정상으로 판정했다. 반면 최신 dns-aid-core의 discover는 개별 에이전트의 일반 FQDN과 TXT 인덱스를 기대하므로 0개를 발견했고, verify로 _mcp._agents를 직접 지정했을 때만 레코드와 DNSSEC를 통과시켰다. 한 구현에 맞춰 기존 인덱스를 교체하면 다른 구현의 발견 경로가 깨지는 상태다.⁴

초안 자체에도 아직 확정되지 않은 부분이 있다. bap, cap, well-known 같은 SvcParamKey 번호와 MCP용 ALPN 식별자는 IANA 배정 전이고, Route 53은 문서에 열거된 SVCB 파라미터만 받아 임의의 keyNNNNN 표현을 지원하지 않는다.⁴ 그래서 최신 초안이라는 이유만으로 운영 레코드를 덮어쓰지 않았다. 일반 FQDN의 인증서와 라우팅, 기존·신규 소비자의 병행 통과를 먼저 확보한 뒤 추가 게시하는 것이 전환 조건이다.

대신 유예를 방치로 두지 않았다. Route 53이 권고하는 DNSSECInternalFailure와 DNSSECKeySigningKeysNeedingAction CloudWatch 알람을 만들고, DS 신뢰 체인과 두 SVCB 레코드, MCP Server Card를 매일 외부 리졸버에서 확인하는 회귀 검사를 배포했다.⁵ 초안이 안정되면 같은 검사에 새 일반 FQDN을 먼저 추가하고, 관찰 기간을 거쳐 구형 이름을 걷어내면 된다.

전환 과정에서 배운 것 하나. DS가 부모 존에 게시된 직후 Cloudflare 리졸버가 잠시 SERVFAIL을 반환했다. 서명 전에 캐시된 응답과 새 신뢰 체인이 충돌하는 전환기 현상으로, 존 서명을 먼저 하고 DS를 나중에 넣는 순서가 이 창을 최소화한다. 해제할 일이 생기면 반드시 역순이다. DS를 먼저 빼고, 전파를 기다린 뒤에 서명을 끈다. 순서를 어기면 도메인 전체가 해석 장애를 겪는다.

당시 재스캔 결과는 71점, 레벨 5 "Agent-Native"였다. Discoverability·Content·Bot Access Control이 100점이 됐고, Discovery 카테고리에 남은 미비 항목은 전부 의도적으로 비워둔 것들이었다(OAuth 계열과 WebMCP). 이후 검사 기준이 바뀌어 2026년 7월 16일 공개 결과는 레벨 4 "Agent-Integrated"지만, DNS-AID 자체는 계속 통과한다. 숫자를 장기 KPI로 쓰기 어려운 이유이기도 하다.⁴

SEO에도 도움이 될까

부분적으로만 겹친다. 콘텐츠 접근성 층(마크다운 제공, AI 크롤러 허용)은 생성 엔진이 콘텐츠를 수집하고 처리하기 쉽게 만들 수 있지만, 그 자체가 인용을 보장하지는 않는다. 점수의 큰 몫인 프로토콜 층도 검색 가시성과 직접 연결되지 않는다. 생성 엔진이 답변을 만들 때 MCP 카드나 OAuth 메타데이터를 조회한다는 근거는 아직 없다.

주의할 점도 있다. 30만 도메인을 분석한 한 관찰 연구는 llms.txt 보유 여부와 LLM 인용 빈도 사이에서 유의미한 상관을 찾지 못했다.⁶ 이 결과는 인과관계나 모든 엔진의 동작을 증명하지 않는다. Content Signals나 robots.txt 정책이 실제로 크롤러의 접근을 막는다면 인용 기회도 줄어들 수 있지만, 신호를 게시했다는 사실만으로 그런 결과를 단정할 수는 없다. 검색·인용이 목적이라면 점수가 아니라 겹치는 층만 선별해서 실행하는 편이 낫다.

판단

에이전트 준비도 점수는 성적표가 아니라 로드맵 신호로 읽는 게 맞다. 콘텐츠 접근성 층은 전달 비용과 파싱 복잡도를 줄이므로 먼저 하고, 프로토콜 층은 서버 로그와 실제 사용 사례를 근거로 투자 시점을 정하는 편이 안전하다.² 우리는 브랜드 실증 가치 때문에 그 시점을 앞당겼지만, 그 경우에도 순서는 같다. 실체를 먼저 만들고 메타데이터를 붙이는 방식은 AI PoC를 운영 시스템으로 넘길 때의 게이트와도 같다.

점수보다 나은 검증도 있다. 실제 에이전트에게 사이트를 쓰게 해보는 것이다. Claude Code 같은 코딩 에이전트로 30분만 돌려보면, 어떤 점수도 알려주지 않는 것들이 보인다.

발견과 읽기 이후 원격 MCP를 어떻게 운영할지는 MCP 2026-07-28이 AgentCore 운영을 바꾸는 지점에서 이어서 다뤘다.

에이전트 대응을 포함한 AI 전환의 방향이 고민이라면 AX 컨설팅에서, 이런 인프라를 직접 구축할 팀이 필요하다면 클라우드 & 인프라에서 시작할 수 있다.

참고 자료