# isitagentready.com과 AgentReady.md: 각자 무엇을 재는가

Cloudflare는 [isitagentready.com](https://isitagentready.com)에서 사이트가 AI 에이전트에 대비되어 있는지 알려주는 스캐너를 운영합니다. 우리도 agentready.md에서 같은 이야기를 하는 것을 운영합니다. 둘 다 무료이고, URL을 받고, 점수를 냅니다.

같은 도구는 아닙니다. 어느 쪽 조언이든 따르기 전에 그 차이를 이해해 둘 가치가 있습니다.

## Cloudflare의 스캐너가 확인하는 것

자체 페이지에 따르면 다섯 범주에서 검사합니다.

- **발견 가능성**: robots.txt, 사이트맵, `Link` 응답 헤더, DNS for AI Discovery
- **콘텐츠 접근성**: Markdown 콘텐츠 협상
- **봇 접근 제어**: robots.txt의 AI 봇 규칙, Content Signals, Web Bot Auth
- **프로토콜 발견**: MCP Server Card, Agent Skills, WebMCP, API Catalog, OAuth discovery, OAuth Protected Resource, Auth.md, ARD 매니페스트
- **커머스**: x402, MPP, UCP, ACP

사이트 유형으로 검사 범위를 좁힐 수 있고, 끝나면 코딩 에이전트에 붙여넣어 수정을 맡길 수 있는 지시문 묶음을 줍니다.

신흥 프로토콜 커버리지는 우리가 본 어떤 것보다도 넓습니다. 특히 x402, UCP, ACP 같은 에이전트 커머스 표준은 다른 곳에서 거의 확인하지 않고, Cloudflare는 그 작업에 충분히 가까이 있어 목록을 최신으로 유지할 수 있습니다. 에이전트가 거래할 API나 상점을 만들고 있다면, 그 스캔은 우리 것이 말해 주지 않는 것을 알려줍니다.

## 우리 것이 확인하는 것

그중 열 개의 `well-known` 디스크립터는 우리도 확인합니다. MCP, A2A 에이전트 카드, Agent Skills, OAuth discovery와 protected resource, API 카탈로그입니다. 프로토콜 발견에서는 실제로 겹치고, 저쪽이 더 넓습니다.

나머지는 완전히 다른 질문에 답합니다. **사이트가 무엇을 선언하는가가 아니라, 에이전트가 당신을 읽고 난 뒤 손에 무엇이 남는가.**

- **콘텐츠 효율**: 페이지에서 실제 내용과 구조물의 비율, 토큰 단위 측정
- **시맨틱 HTML**: 말이 되는 제목 구조, 진짜 `<article>`과 `<main>`, 대체 텍스트, 중첩 깊이
- **구조화 데이터**: Schema.org, Open Graph, canonical, 선언된 언어
- **기계를 위한 접근성**: JavaScript 없이 동작하는지, 페이지 무게, 소스에서 콘텐츠의 위치

그리고 에이전트가 나머지를 버린 뒤 남길 그대로, Markdown으로 변환한 페이지를 돌려드립니다.

## 두 질문 사이의 거리

Cloudflare 목록의 모든 프로토콜을 선언하고도, 그것을 가져간 에이전트에게는 쓸모없는 사이트가 있을 수 있습니다.

잘 만든 React 상점을 떠올려 보세요. 유효한 `mcp.json`, 에이전트 카드, OAuth discovery, x402까지 연결돼 있습니다. 프로토콜 발견은 만점입니다. 이제 JavaScript 없이 상품 페이지를 가져오면 빈 껍데기가 옵니다. 읽을 것도, 인용할 것도, 고객이 어시스턴트에게 어느 공급처가 좋냐고 물었을 때 추천할 것도 없습니다.

반대도 있고, 오히려 더 흔합니다. 서버에서 렌더링된 평범하고 깔끔하고 온전한 페이지인데, 크롤러를 들여보내는 robots.txt 규칙이 없어서 어떤 에이전트도 찾지 못합니다.

**프로토콜 선언은 약속이고, 콘텐츠는 그 이행입니다.** 두 스캐너는 각각 다른 절반을 봅니다.

## 저쪽 스캐너가 우리 버그를 찾아냈다

가정이 아닙니다. 우리 robots.txt는 몇 달 동안 오리진에서 `404`를 반환하고 있었고 아무도 몰랐습니다. Cloudflare의 관리형 Content Signals Policy가 엣지에서 우리를 대신해, 우리가 쓴 적 없는 그럴듯한 파일로 답하고 있었기 때문입니다. 그리고 우리 채점기가 그 `200`을 읽고 스스로에게 합격을 줬습니다.

isitagentready.com은 분명히 말했습니다. robots.txt를 찾을 수 없다고. 저쪽 도구가 우리 도구가 덮고 있던 진짜 문제를 잡아낸 겁니다. 고치고 나니 점수는 93에서 90으로 내려갔고, 낮은 쪽이 정직한 숫자였습니다.

여기서 두 가지가 따라옵니다. 하나, 두 번째 의견은 값어치가 있습니다. 특히 첫 번째 의견이 자기 것일 때는요. 둘, CDN을 거쳐 읽는 스캐너는 그 CDN에게 이야기를 들을 수 있습니다. 저쪽 것도, 우리 것도.

## 어느 쪽을 쓸까

둘 다요. 무료이고 몇 초면 끝납니다.

**Cloudflare 것부터** 쓰세요. 질문이 "에이전트가 나와 일하는 데 필요한 프로토콜을 내가 내놓고 있는가"라면요. API, MCP 서버, 거래가 걸린 모든 것. 저쪽 목록이 더 길고 표준화 기구에 더 가깝습니다.

**우리 것부터** 쓰세요. 질문이 "어시스턴트가 내 페이지를 읽을 때 실제로 무엇을 가져가는가"라면요. 콘텐츠 사이트, 문서, 무엇을 파는지 설명하는 사업. 답이 기대보다 나쁜 쪽은 대개 이쪽이고, 자기 페이지를 Markdown으로 보는 순간 이해가 됩니다.

건강한 결과는 둘 다 통과하는 것입니다. 흔한 결과는 하나를 통과하고 다른 하나는 끝내 열어보지 않는 것입니다.

[페이지 분석하기](/ko) · [무엇을 재는가](/ko/about) · [도구](/ko/tools)