웹은 항상 새로운 표준에 적응해 왔습니다. 웹 브라우저와 소통하는 법을 배웠고, 그 다음에는 검색 엔진과 소통하는 법을 배웠습니다. 그리고 이제는 AI 에이전트와 소통해야 합니다.
오늘은 사이트 소유자가 자신의 사이트를 에이전트에 맞게 최적화하는 방법을 이해할 수 있도록 돕는 새로운 도구인 isitagentready.com을 소개하게 되어 매우 기쁩니다. 이 도구는 에이전트가 인증하는 방법을 안내하는 것부터, 에이전트가 볼 수 있는 콘텐츠와 이를 전달받는 형식, 그리고 비용을 지불하는 방식까지 제어할 수 있도록 지원합니다. 또한 인터넷 전반에서 각 에이전트 표준의 채택 현황을 추적하는 새로운 데이터세트를 Cloudflare Radar에 도입합니다.
우리는 모범을 통해 앞서 나가고자 합니다. 그래서 최근 Cloudflare의 개발자 문서를 전면 개편하여 가장 에이전트 친화적인 문서 사이트로 만든 방법도 함께 공유합니다. 이를 통해 AI 도구가 질문에 더 빠르게, 그리고 훨씬 더 저렴하게 답변하도록 할 수 있습니다.
오늘날 웹의 에이전트 준비도 수준은 어느 정도일까요?
짧게 대답하자면 별로입니다. 이는 예상된 결과이지만, 표준이 채택된다면 에이전트가 현재보다 훨씬 더 효과적으로 작동할 수 있음을 보여주는 것이기도 합니다.
이를 분석하기 위해 Cloudflare Radar는 인터넷에서 가장 많이 방문된 도메인 200,000개를 가져왔습니다. 그리고 리디렉션, 광고 서버, 터널링 서비스처럼 에이전트 준비도가 중요하지 않은 카테고리는 제외하여, AI 에이전트가 실제로 상호작용할 가능성이 있는 기업, 퍼블리셔, 플랫폼에 집중했고, 새로운 도구를 사용해 이를 스캔했습니다.
그 결과, 이제 Cloudflare Radar AI Insights 페이지에서 확인할 수 있는 새로운 “AI 에이전트 표준 채택” 차트를 만들었으며, 이를 통해 여러 도메인 카테고리 전반에 걸쳐 각 표준의 채택 현황을 측정할 수 있습니다.
개별 점검 결과를 보면 몇 가지 눈에 띄는 점이 있습니다.
robots.txt 는 거의 보편적입니다(78%의 사이트가 사용 중). 하지만 대부분의 텍스트는 AI 에이전트가 아닌 기존의 검색 엔진 크롤러용으로 작성되었습니다.
콘텐츠 신호: 사이트의 4%만이 robots.txt에서 AI 사용 관련 선호를 명시하고 있습니다. 이는 현재 빠르게 확산되고 있는 새로운 표준입니다.
Markdown 콘텐츠 협상(Accept: text/markdown 요청 시 text/markdown으로 응답 제공)은 전체 사이트의 3.9%에서만 충족됩니다.
MCP 서버 카드와 API 카탈로그(RFC 9727) 같은 새로운 신흥 표준은 전체 데이터세트에서 합쳐도 15개 미만의 사이트에서만 확인됩니다. 아직은 초기 단계이므로 새로운 표준을 먼저 도입하고 에이전트와 잘 작동하는 사이트가 됨으로써 차별화할 수 있는 기회가 충분히 있습니다.
이 차트는 매주 업데이트되며, 해당 데이터는 Data Explorer나 Radar API에서도 확인할 수 있습니다.
isitagentready.com을 방문하여 사이트 URL을 입력하면 웹사이트의 에이전트 준비도 점수를 확인할 수 있습니다.
실행 가능한 피드백을 제공하는 점수와 감사는 이전에도 새로운 표준 채택을 촉진하는 데 도움을 주었습니다. 예를 들어, Google Lighthouse는 웹사이트의 성능과 보안 모범 사례를 기준으로 점수를 매기고, 사이트 소유자가 최신 웹 플랫폼 표준을 도입하도록 안내합니다. 우리는 사이트 소유자가 에이전트를 위한 모범 사례를 채택하도록 돕는 유사한 도구가 필요하다고 생각합니다.
사이트를 입력하면 Cloudflare가 해당 사이트에 요청을 보내 어떤 표준을 지원하는지 확인하고, 네 가지 기준에 따라 점수를 제공합니다.
예시 웹사이트의 에이전트 준비도 점검 결과 스크린샷입니다.
또한 x402, Universal Commerce Protocol, Agentic Commerce Protocol을 포함한 에이전트 기반 커머스 표준 지원 여부도 확인하지만, 현재 점수에는 반영되지 않습니다.
각 점검에서 실패한 항목에 대해서는 코딩 에이전트에 전달할 수 있는 프롬프트를 제공하며, 이를 통해 해당 지원을 대신 구현하도록 할 수 있습니다.
해당 사이트 자체도 에이전트 준비도를 갖추고 있으며, 스스로 주장하는 바를 실제로 구현하고 있습니다. Streamable HTTP를 통해 scan_site 도구를 제공하는 스테이트리스 MCP 서버(https://isitagentready.com/.well-known/mcp.json)를 노출하여 모든 MCP 호환 에이전트가 웹 인터페이스를 사용하지 않고도 프로그래밍 방식으로 웹사이트를 스캔할 수 있도록 합니다. 또한 Agent Skills 인덱스(https://isitagentready.com/.well-known/agent-skills/index.json)를 게시하여, 점검하는 모든 표준에 대한 스킬 문서를 제공함으로써 에이전트가 무엇을 수정해야 하는지뿐만 아니라 어떻게 수정해야 하는지도 알 수 있도록 합니다.
각 카테고리별 점검 항목과 그것이 에이전트에 왜 중요한지 자세히 살펴보겠습니다.
robots.txt는 1994년부터 사용되어 왔으며, 대부분의 사이트에 존재합니다. 이 파일은 에이전트를 대상으로 크롤링 규칙(누가 어떤 콘텐츠에 접근할 수 있는지)을 정의하고, 사이트맵의 위치를 알려주는 두 가지 역할을 합니다. 사이트맵은 웹사이트의 모든 경로를 나열한 XML 파일로, 모든 링크를 하나하나 크롤링하지 않고도 에이전트가 전체 콘텐츠를 발견할 수 있도록 하는 일종의 지도 역할을 합니다. robots.txt는 에이전트가 가장 먼저 확인하는 곳입니다.
사이트맵 외에도, 에이전트는 HTTP 응답 헤더를 통해 중요한 리소스를 직접 발견할 수 있으며, 특히 Link 응답 헤더(RFC 8288)를 사용합니다. HTML 내부에 묻혀 있는 링크와 달리, Link 헤더는 HTTP 응답 자체의 일부이므로 에이전트는 어떤 마크업도 파싱할 필요 없이 리소스에 대한 링크를 찾을 수 있습니다.
HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"
에이전트를 사이트로 유입시키는 것은 한 가지 문제일 뿐, 실제로 콘텐츠를 읽을 수 있도록 만드는 것은 또 다른 문제입니다.
AI 발전 속도를 감안하면 이미 한참 전처럼 느껴지는 2024년 9월, llms.txt가 웹사이트를 LLM 친화적인 형태로 제공하고 모델의 컨텍스트 윈도우에 맞출 수 있는 방법으로 제안되었습니다. llms.txt는 사이트 루트에 위치한 일반 텍스트 파일로, 에이전트에게 구조화된 읽기 목록을 제공하여, 사이트가 무엇인지, 어떤 콘텐츠가 있는지, 그리고 중요한 콘텐츠가 어디에 위치하는지를 알려줍니다. 크롤러가 색인하기 위한 사이트맵이 아니라, LLM이 읽도록 작성된 사이트맵이라고 생각하면 됩니다.
# My Site
> A developer platform for building on the edge.
## Documentation
- [Getting Started](https://example.com/docs/start.md)
- [API Reference](https://example.com/docs/api.md)
## Changelog
- [Release Notes](https://example.com/changelog.md)
Markdown 콘텐츠 협상은 한 단계 더 나아갑니다. 에이전트가 어떤 페이지를 요청하면서 Accept: text/markdown 헤더를 보내면, 서버는 HTML 대신 깔끔한 Markdown 버전으로 응답합니다. Markdown 버전은 훨씬 적은 토큰을 사용합니다(일부 경우 최대 80%까지 토큰이 줄어드는 것을 확인했습니다). 이는 대부분의 에이전트 도구가 기본적으로 갖는 컨텍스트 윈도우 제한을 고려할 때, 응답을 더 빠르고 저렴하게 만들고 전체 내용을 끝까지 활용할 가능성을 높여줍니다.
기본적으로는 사이트가 Markdown 콘텐츠 협상을 올바르게 처리하는지만 확인하며, llms.txt는 확인하지 않습니다. 필요에 따라 스캔 설정을 변경하여 llms.txt를 포함하도록 할 수 있습니다.
이제 에이전트가 사이트를 탐색하고 콘텐츠를 소비할 수 있게 되었다면, 다음 질문은 이것입니다. 모든 봇이 이를 수행하도록 허용하시겠습니까?
robots.txt는 단순히 사이트맵 위치를 알려주는 것 이상의 역할을 하여, 접근 규칙을 정의하는 곳이기도 합니다. 어떤 크롤러를 허용할지, 그리고 어떤 경로까지 접근할 수 있는지를 명시적으로 지정할 수 있습니다. 이 관례는 잘 확립되어 있으며, 예의 바른 모든 봇이 크롤링을 시작하기 전에 가장 먼저 확인하는 위치이기도 합니다.
콘텐츠 신호를 사용하면 더 세밀하게 제어할 수 있습니다. 단순히 허용하거나 차단하는 것을 넘어, AI가 콘텐츠로 무엇을 할 수 있는지 정확히 선언할 수 있습니다. robots.txt에서 Content-Signal 지시자를 사용하면 세 가지를 각각 독립적으로 제어할 수 있습니다. 콘텐츠를 AI 학습에 사용할 수 있는지(ai-train), 추론 및 그라운딩을 위한 AI 입력으로 사용할 수 있는지(ai-input), 그리고 검색 결과에 노출될 수 있는지(search)입니다.
User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes
반대로, Web Bot Auth IETF 초안 표준은 신뢰할 수 있는 봇이 스스로를 인증할 수 있도록 하고, 봇으로부터 요청을 받는 웹사이트가 이를 식별할 수 있도록 합니다. 봇은 자신의 HTTP 요청에 서명을 추가하고, 요청을 받는 사이트는 봇이 공개한 공개 키를 사용해 해당 서명을 검증합니다.
해당 공개 키는 well-known 엔드포인트인 /.well-known/http-message-signatures-directory에 위치하며, 우리는 스캔 과정에서 이를 확인합니다.
모든 사이트에서 이를 구현할 필요는 없습니다. 사이트가 콘텐츠만 전송하고 다른 사이트에 요청을 보내지 않는 경우에는 필요하지 않습니다. 하지만 인터넷의 더 많은 사이트에서 다른 사이트에 요청을 하는 에이전트를 자체적으로 실행하면서 시간이 지남에 따라 점점 더 중요해질 것으로 예상됩니다.
수동적인 콘텐츠 소비를 넘어, 에이전트는 API를 호출하고, 도구를 실행하며, 작업을 자율적으로 수행하는 방식으로 사이트와 직접 상호작용할 수도 있습니다.
서비스에 하나 이상의 공개 API가 있는 경우, API 카탈로그(RFC 9727)는 에이전트가 이를 모두 발견할 수 있는 단일 well-known 위치를 제공합니다. /.well-known/api-catalog에 호스팅되며, 에이전트가 개발자 포털을 스크래핑하거나 문서를 직접 읽지 않아도 되도록, API 목록과 각 API의 사양, 문서, 상태 엔드포인트로의 링크를 제공합니다.
에이전트를 이야기하면서 MCP를 빼놓을 수는 없습니다. 모델 컨텍스트 프로토콜은 AI 모델이 외부 데이터 소스와 도구에 연결할 수 있도록 하는 개방형 표준입니다. 모든 AI 도구마다 개별 통합을 구축하는 대신, 하나의 MCP 서버만 구축하면 호환되는 모든 에이전트가 이를 사용할 수 있습니다.
에이전트가 MCP 서버를 찾을 수 있도록 돕기 위해 MCP Server Card(현재 초안 단계인 제안)를 게시할 수 있습니다. 이는 /.well-known/mcp/server-card.json에 위치한 JSON 파일로, 에이전트가 연결하기 전에도 어떤 도구를 제공하는지, 어떻게 접근하는지, 그리고 인증 방법은 무엇인지 등 서버에 대한 정보를 설명합니다. 에이전트는 이 파일을 읽고 서버를 사용하기 위해 필요한 모든 정보를 파악할 수 있습니다.
{
"$schema": "https://static.modelcontextprotocol.io/schemas/mcp-server-card/v1.json",
"version": "1.0",
"protocolVersion": "2025-06-18",
"serverInfo": {
"name": "search-mcp-server",
"title": "Search MCP Server",
"version": "1.0.0"
},
"description": "Search across all documentation and knowledge base articles",
"transport": {
"type": "streamable-http",
"endpoint": "/mcp"
},
"authentication": {
"required": false
},
"tools": [
{
"name": "search",
"title": "Search",
"description": "Search documentation by keyword or question",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string" }
},
"required": ["query"]
}
}
]
}
에이전트는 특정 작업을 수행하는 데 도움이 되는 Agent Skills를 갖추고 있을 때 가장 잘 작동합니다. 하지만 에이전트는 사이트가 어떤 스킬을 제공하는지 어떻게 발견할 수 있을까요? 우리는 사이트가 이 정보를 .well-known/agent-skills/index.json에서 제공할 수 있도록 제안했습니다. 이 엔드포인트는 어떤 스킬을 사용할 수 있는지와 이를 어디에서 찾을 수 있는지를 에이전트에 알려줍니다. .well-known 표준(RFC 8615)이 다른 많은 에이전트 및 인증 표준에서도 사용된다는 점을 눈치채셨을 수 있습니다. 이 표준을 작성한 Mark Nottingham과 Cloudflare, 그리고 다른 IETF 기여자들에게 감사드립니다!
많은 사이트는 접근하기 위해 먼저 로그인해야 합니다. 이로 인해 사용자가 에이전트에게 자신을 대신해 해당 사이트에 접근할 권한을 부여하기가 어려워지며, 일부에서는 다소 안전하지 않은 우회 방식으로 로그인된 세션이 유지된 사용자의 웹 브라우저에 에이전트 접근 권한을 부여하기도 합니다.
사람이 명시적으로 액세스를 부여할 수 있는 더 나은 방법이 있는데, OAuth를 지원하는 사이트는 에이전트에게 인증 서버의 위치(RFC 9728)를 알려줄 수 있으며, 이를 통해 에이전트는 사용자를 OAuth 흐름으로 안내하고, 사용자가 에이전트에 적절하게 액세스를 부여할 수 있도록 합니다. Agents Week 2026에서 발표된 것처럼, Cloudflare Access는 이제 이 OAuth 흐름을 완전히 지원합니다. 그리고 OpenCode와 같은 에이전트가 사용자가 보호된 URL을 제공했을 때 이 표준을 활용해 자연스럽게 작동하도록 만드는 방법도 함께 보여주었습니다.
에이전트는 사용자를 대신해 물건을 구매할 수도 있습니다. 하지만 웹의 결제 방식은 사람을 기준으로 설계되었습니다. 장바구니에 담고, 신용카드를 입력하고, 결제 버튼을 누르는 방식입니다. 구매자가 AI 에이전트일 경우 이 흐름은 완전히 무너집니다.
x402는 1997년부터 명세에 존재했지만 널리 사용되지는 않았던 HTTP 402 Payment Required 상태 코드를 다시 활용함으로써 프로토콜 수준에서 이를 해결합니다. 흐름은 간단합니다: 에이전트가 리소스를 요청하면 서버는 결제 조건을 설명하는 기계 판독 가능한 페이로드와 함께 402로 응답하고, 에이전트는 결제를 수행한 뒤 다시 요청합니다. Cloudflare는 Coinbase와 협력하여 x402 Foundation을 출범했으며, 그 목표는 인터넷 결제를 위한 개방형 표준으로 x402의 채택을 확대하는 것입니다.
또한 Universal Commerce Protocol과 Agentic Commerce Protocol도 확인하는데, 이는 사람이 일반적으로 전자 상거래 스토어프론트와 결제 흐름을 통해 구매하는 제품을 에이전트가 발견하고 구매할 수 있도록 설계된 두 가지 신흥 에이전트 기반 커머스 표준입니다.
Cloudflare URL Scanner에 에이전트 준비도 통합
Cloudflare의 URL Scanner를 사용하면 어떤 URL이든 제출하고 HTTP 헤더, TLS 인증서, DNS 레코드, 사용된 기술, 성능 데이터, 보안 신호 등이 포함된 상세한 보고서를 받을 수 있습니다. 이는 URL이 내부적으로 실제로 무엇을 수행하는지 이해하고자 하는 보안 연구자와 개발자에게 기본적인 도구입니다.
우리는 isitagentready.com의 동일한 점검 항목을 가져와 URL Scanner에 새로운 Agent Readiness 탭으로 추가했습니다. 이제 어떤 URL이든 스캔하면 기존 분석과 함께 전체 에이전트 준비도 보고서를 확인할 수 있으며, 여기에서 어떤 점검 항목을 통과했는지, 사이트의 수준은 어느 정도인지, 그리고 점수를 개선하기 위한 실행 가능한 가이드도 참고할 수 있습니다.
이 통합 기능은 URL Scanner API를 통해 프로그래밍 방식으로도 사용할 수 있습니다. 스캔 결과에 에이전트 준비도 정보를 포함하려면, 스캔 요청에 agentReadiness 옵션을 전달하세요.
curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/urlscanner/v2/scan \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
-d '{
"url": "https://www.example.com",
"options": {"agentReadiness": true}
}'
솔선수범: Cloudflare Docs 업그레이드
웹의 준비도를 측정하는 도구를 구축하면서, 우리 스스로도 준비가 되어 있어야 한다는 점을 분명히 인식했습니다. 고객이 사용하는 에이전트가 쉽게 이해할 수 있도록 문서를 구성해야 합니다.
우리는 위에서 언급한 관련 콘텐츠 사이트 표준을 자연스럽게 도입했으며, 점수는 여기에서 확인할 수 있습니다. 하지만 거기서 멈추지 않았습니다. 다음은 Cloudflare의 Developer Docs를 웹에서 가장 에이전트 친화적인 리소스로 개선한 방법입니다.
안타깝게도 2026년 2월 기준, 테스트한 7개의 에이전트 중 기본적으로 Accept: text/markdown 헤더로 콘텐츠를 요청하는 것은 Claude Code, OpenCode, Cursor뿐입니다. 나머지에 대해서는 URL 기반의 자연스러운 폴백이 필요했습니다.
이를 위해 모든 페이지를 해당 URL을 기준으로 /index.md 경로에서 Markdown으로 별도로 제공하도록 했습니다. 정적 파일을 복제하지 않고도 이를 동적으로 처리하기 위해, 두 가지 Cloudflare 규칙을 조합했습니다.
URL Rewrite Rule을 사용하여 /index.md로 끝나는 요청을 매칭하고, regex_replace를 사용해 /index.md를 제거하여 기본 경로로 동적으로 재작성합니다.
Request Header Transform Rule을 사용하여 재작성 이전의 원래 요청 경로(raw.http.request.uri.path)를 기준으로 매칭하고, Accept: text/markdown 헤더를 자동으로 설정합니다.
이 두 가지 규칙을 통해, 어떤 페이지든 URL 뒤에 /index.md 경로를 추가하면 Markdown으로 가져올 수 있습니다.
우리는 llms.txt 파일에서 이러한 /index.md URL을 가리킵니다. 결과적으로 이러한 /index.md 경로에 대해서는 클라이언트가 어떤 헤더를 설정하든 항상 Markdown을 반환합니다. 그리고 이 모든 과정을 별도의 빌드 단계나 콘텐츠 중복 없이 수행합니다.
대규모 사이트를 위한 효과적인 llms.txt 파일 생성
llms.txt는 에이전트에게 “홈 베이스” 역할을 하며, LLM이 콘텐츠를 찾을 수 있도록 페이지 디렉터리를 제공합니다. 그러나 5,000개 이상의 문서를 하나의 파일에 담으면 모델의 컨텍스트 윈도우를 초과하게 됩니다.
하나의 거대한 파일 대신, 문서의 각 최상위 디렉터리마다 별도의 llms.txt 파일을 생성하고, 루트 llms.txt에서는 이러한 하위 디렉터리를 가리키도록 구성했습니다.
또한 LLM에 거의 의미 있는 정보를 제공하지 않는 수백 개의 디렉터리 목록 페이지를 제거하고, 각 페이지가 풍부한 설명적 컨텍스트(제목, 의미 있는 이름, 설명)를 갖도록 했습니다.
예를 들어, https://developers.cloudflare.com/workers/databases/와 같이 단순히 지역화된 디렉터리 목록 역할만 하는 약 450개의 페이지는 제외합니다.
이러한 페이지는 사이트맵에는 포함되지만 LLM에 제공할 수 있는 정보는 매우 제한적입니다. 모든 하위 페이지는 이미 llms.txt에 개별적으로 연결되어 있기 때문에 디렉터리 페이지를 가져오는 것은 단순히 중복된 링크 목록만 제공하게 되며, 실제 콘텐츠를 찾기 위해 에이전트가 추가 요청을 하도록 만들게 됩니다.
에이전트가 효율적으로 탐색할 수 있도록 각 llms.txt 항목은 풍부한 컨텍스트를 제공하면서도 토큰 사용은 최소화해야 합니다. 사람은 프론트매터나 필터링 레이블을 무시할 수 있지만, AI 에이전트에게 이러한 메타데이터는 방향을 결정하는 핵심 요소입니다. 그렇기 때문에 Product Content Experience(PCX) 팀은 에이전트가 어떤 페이지를 가져와야 하는지 정확히 알 수 있도록 페이지 제목, 설명, URL 구조를 정교하게 개선했습니다.
루트 llms.txt의 한 섹션을 살펴보세요.
각 링크는 의미 있는 이름, 이에 대응하는 URL, 그리고 높은 가치의 설명을 갖고 있습니다. 이 모든 작업은 llms.txt 생성을 위해 별도의 추가 작업을 요구하지 않았습니다. 이 모든 정보는 이미 문서의 프론트매터에 포함되어 있었습니다. 최상위 디렉터리의 llms.txt 파일에 포함된 페이지들도 마찬가지입니다. 이 모든 컨텍스트는 에이전트가 관련 정보를 더욱 효율적으로 찾을 수 있도록 합니다.
또한 우리는 콘텐츠 탐색 및 내비게이션과 같은 항목에 대해 문서 사이트를 테스트할 수 있도록 해주는 신흥 에이전트 친화적 문서 사양이자 오픈소스 프로젝트인 afdocs를 사용해 문서를 검증합니다. 이 사양을 통해 우리만의 맞춤형 감사 도구를 구축할 수 있었습니다. 사용 사례에 맞는 몇 가지 의도적인 패치를 추가하여, 손쉽게 평가할 수 있는 대시보드를 만들었습니다.
우리는 에이전트(OpenCode를 통한 Kimi-k2.5)를 다른 대규모 기술 문서 사이트의 llms.txt 파일에 연결하고, 매우 구체적인 기술 질문에 답하도록 했습니다.
평균적으로 Cloudflare 문서를 대상으로 한 에이전트는 에이전트에 최적화되지 않은 일반 사이트 대비 31% 적은 토큰을 사용했고, 66% 더 빠르게 정답에 도달했습니다. 제품 디렉터리를 하나의 컨텍스트 윈도우에 맞출 수 있기 때문에, 에이전트는 필요한 정확한 페이지를 식별하고 단일 선형 경로로 가져올 수 있습니다.
LLM 응답의 정확성은 종종 컨텍스트 윈도우 효율성의 부산물입니다. 테스트 과정에서 우리는 다른 문서 세트에서 반복적으로 나타나는 패턴을 관찰했습니다.
grep 루프: 많은 문서 사이트는 에이전트의 즉시 사용 가능한 컨텍스트 윈도우를 초과하는 하나의 거대한 llms.txt 파일을 제공합니다. 에이전트가 파일 전체를 “읽을” 수 없기 때문에, 키워드를 기준으로 grep을 수행하기 시작합니다. 첫 번째 검색에서 특정 세부 정보를 찾지 못하면, 에이전트는 다시 생각하고 검색어를 다듬은 뒤 재시도해야 합니다.
좁아진 컨텍스트와 낮은 정확도: 에이전트가 전체 파일을 읽는 대신 반복적인 검색에 의존하면 문서의 전체적인 맥락을 잃게 됩니다. 이처럼 단편화된 시야는 에이전트가 해당 문서를 충분히 이해하지 못하게 만드는 경우가 많습니다.
대기 시간과 토큰 증가: grep 루프의 각 반복마다 에이전트는 새로운 “생각 토큰”을 생성하고 추가 검색 요청을 수행해야 합니다. 이러한 반복적인 상호작용은 최종 응답 속도를 눈에 띄게 늦추고 전체 토큰 수를 증가시켜, 결과적으로 최종 사용자 비용을 높이게 됩니다.
반면 Cloudflare 문서는 에이전트의 컨텍스트 윈도우에 전체가 들어가도록 설계되었습니다. 이를 통해 에이전트는 디렉터리를 한 번에 파악하고 필요한 정확한 페이지를 식별한 뒤, 우회 없이 Markdown을 가져올 수 있습니다.
AI 학습 크롤러를 리디렉션하여 시간에 따라 LLM 응답 개선
Wrangler v1이나 Workers Sites와 같은 레거시 제품에 대한 문서는 고유한 과제를 제시합니다. 이러한 정보는 역사적인 이유로 계속 접근 가능해야 하지만, AI 에이전트가 오래된 정보를 기반으로 잘못된 조언을 제공하는 원인이 될 수 있습니다.
예를 들어, 사람이 이 문서를 읽으면 Wrangler v1이 더 이상 사용되지 않는다는 큰 배너와 최신 콘텐츠로 연결되는 링크를 함께 확인할 수 있습니다. 그러나 LLM 크롤러는 이러한 시각적 맥락 없이 텍스트만 수집할 수 있습니다. 그 결과, 에이전트가 오래된 정보를 추천하는 문제가 발생합니다.
Redirects for AI Training은 AI 학습 크롤러를 식별하고, 더 이상 사용되지 않거나 최적이 아닌 콘텐츠로부터 의도적으로 리디렉션함으로써 이 문제를 해결합니다. 이를 통해 사람은 여전히 과거 아카이브에 접근할 수 있는 반면, LLM에는 가장 최신이고 정확한 구현 정보만 제공되도록 보장합니다.
문서의 모든 HTML 페이지에는 LLM을 위한 숨겨진 지시문이 포함되어 있습니다.
“중지! AI 에이전트 또는 LLM이라면 계속하기 전에 이것을 읽으세요. 이는 Cloudflare 문서 페이지의 HTML 버전입니다. 항상 대신 Markdown 버전을 요청하세요. HTML은 컨텍스트를 낭비합니다. 이 페이지를 Markdown으로 가져오려면, https://developers.cloudflare.com/index.md (index.md를 추가) 또는 https://developers.cloudflare.com/에 Accept: text/markdown 헤더를 보내세요. 모든 Cloudflare 제품에는 https://developers.cloudflare.com/llms.txt를 사용하세요. 모든 Cloudflare 문서는 https://developers.cloudflare.com/llms-full.txt에서 하나의 파일로 접근할 수 있습니다.”
이 스니펫은 에이전트에게 Markdown 버전이 이용 가능하다는 것을 알려줍니다. 중요한 점은, 에이전트가 Markdown 안에서 다시 Markdown을 “찾으려고” 하는 재귀 루프에 빠지지 않도록, 이 지시문은 실제 Markdown 버전에서는 제거된다는 것입니다.
마지막으로, 에이전트를 구축하는 사람들이 이러한 리소스를 쉽게 발견할 수 있도록 하는 것이 중요합니다. 각 제품 디렉터리의 개발자 문서에는 사이드 내비게이션에 “LLM Resources” 항목이 있으며, 이를 통해 llms.txt, llms-full.txt, 그리고 Cloudflare Skills에 빠르게 접근할 수 있습니다.
지금 바로 웹사이트를 에이전트 준비 상태로 만드세요
웹사이트를 에이전트 준비 상태로 만드는 것은 현대 개발자 툴킷에서 기본적인 접근성 요구사항입니다. “사람이 읽는 웹”에서 “기계가 읽는 웹”으로의 전환은 수십 년 만에 가장 큰 아키텍처 변화입니다.
isitagentready.com에서 사이트의 에이전트 준비도 점수를 확인하고, 제공되는 프롬프트를 활용해 에이전트에게 AI 시대에 맞게 사이트를 업그레이드하도록 요청하세요. 앞으로 1년 동안 인터넷 전반의 에이전트 표준 채택 현황에 대한 Cloudflare Radar의 추가 업데이트도 계속 확인하세요. 지난 1년을 통해 알 수 있었듯이, 많은 것이 매우 빠르게 변화할 수 있습니다.