AI 에이전트가 고객의 첫 접점을 바꾸고 있습니다.
이제 사용자는 검색 결과보다 먼저 AI 비서에게 묻고, 그 답변 안에서 어떤 브랜드를 만나는지가 선택을 좌우합니다.
이 글에서는 사이트가 AI 에이전트에게 읽히는지 확인하는 방법과, 실제로 추천까지 받는지 점검하는 AEO 관점의 기준을 정리합니다.
기존의 클릭과 페이지뷰만으로는 더 이상 전체 상황을 보기 어렵습니다.
Cloudflare가 대시보드에 통합한 Agent Readiness와 AEO는 바로 이 빈틈을 메우기 위한 도구입니다.
사이트 소유자는 이제 “내 사이트를 에이전트가 사용할 수 있는가?”와 “AI 에이전트가 나를 추천하는가?”를 분리해서 확인할 수 있습니다.
AI 에이전트 시대에 달라진 발견 방식
예전에는 검색 결과 페이지에서 순위가 곧 발견 가능성을 의미했습니다.
하지만 지금은 질문의 출발점이 검색엔진이 아니라 AI 어시스턴트가 되는 경우가 늘고 있습니다.
사용자는 “어떻게 해야 하나요”, “어떤 옵션이 가장 좋은가요”, “대신 처리해 주세요”처럼 묻고, 에이전트가 답을 찾고 비교한 뒤 행동까지 이어갑니다.
이 변화에서 중요한 것은 사람이 홈페이지를 직접 보기도 전에, 모델의 응답 안에서 이미 선택이 일어난다는 점입니다.
그래서 발견 가능성은 단순한 노출이 아니라, 읽히고, 이해되고, 신뢰되어 추천되는 것 까지 포함하게 됩니다.
AI 에이전트가 고객의 판단 과정에 들어오는 순간, 사이트 성능의 기준도 함께 바뀝니다.
또 하나의 변화는 트래픽의 성격입니다.
원문은 전체 HTML 페이지 요청 중 인간이 아닌 요청의 비중이 이미 상당하다고 설명합니다.
물론 그 모두가 사람을 대신해 행동하는 에이전트는 아니지만, 답변 엔진과 쇼핑 도우미, 리서치 도구가 점점 더 중요한 중간 관문이 되는 것은 분명합니다.
Agent Readiness가 보는 첫 번째 질문
Cloudflare의 Agent Readiness는 기술적인 적합성을 점검하는 진단 도구입니다.
핵심 질문은 단순합니다.
AI 에이전트가 내 사이트를 실제로 사용할 수 있는가?
진단은 에이전트가 페이지를 읽는 방식에 맞춰 사이트를 검사합니다.
접근이 허용되는지, 콘텐츠를 발견할 수 있는지, 기계가 읽기 쉬운 복사본을 가져올 수 있는지, 그리고 호출 가능한 인터페이스가 있는지를 살펴봅니다.
사람이 단순히 홈페이지만 보는 것과 달리, 에이전트는 여러 신호를 종합해 사이트를 판단합니다.
검사에 활용되는 대표 신호는 다음과 같습니다.
- robots.txt
- XML 사이트맵
- 응답 헤더
- Markdown 버전의 콘텐츠
- 인증과 도구 관련 공개 메타데이터
진단 결과는 하나의 상태로 합쳐져 “Not Ready”부터 완전한 agent-native 상태까지 이어지는 형태로 표시됩니다.
각 항목은 통과, 실패, 보류로 나뉘며, 왜 중요한지에 대한 설명과 함께 실제 요청과 응답을 보여주는 근거도 제공합니다.
즉, 단순 경고가 아니라 어떤 지점이 문제인지 확인할 수 있도록 설계되어 있습니다.
목차
우선순위가 다른 개선 항목
Agent Readiness의 점검 항목은 작업 난이도에 따라 묶여 있습니다.
이를 보면 어디서부터 손대야 하는지 훨씬 분명해집니다.
Quick wins
– crawler가 읽을 수 있는 robots.txt
– XML 사이트맵
– AI crawler 규칙
– 에이전트용 clean Markdown 제공Technical groundwork
– 콘텐츠 사용 방식을 명시하는 Content Signals
– API 카탈로그
– link header
– agent 로그인 안내Advanced integration
– OAuth discovery
– MCP(Model Context Protocol)와 A2A(Agent2Agent) agent card
– skills index
– Web Bot Auth
– WebMCPCommerce
– x402
– ACP(Agent Commerce Protocol)
– UCP(Universal Commerce Protocol)
– AP2(Agent Payments Protocol)
여기서 Commerce 항목은 정보 제공용으로만 다뤄지며, 현재 점수 계산에는 포함되지 않습니다.
즉, 지금 당장 점수에 직접 영향을 주는 영역과 미래 확장 영역을 구분해 볼 수 있습니다.
AI 에이전트가 읽기 쉬운 사이트를 만드는 방법
Agent Readiness의 실질적 가치는 단순한 진단이 아니라 다음 행동을 바로 연결해 준다는 점입니다.
Cloudflare 기능으로 해결 가능한 경우에는 설정 화면으로 바로 이동하는 링크가 제공됩니다.
그 외의 경우에는 코드 에이전트가 무엇을 만들어야 하는지 제안하는 프롬프트를 복사할 수 있습니다.
고친 뒤 다시 스캔하면 체크가 녹색으로 바뀌는 구조입니다.
이 방식은 사이트를 “사람용”과 “에이전트용”으로 이분법적으로 나누려는 것이 아닙니다.
오히려 기존 웹의 공개 신호를 더 명확하게 정리해, AI 에이전트가 콘텐츠를 해석하는 데 장애가 없도록 만드는 쪽에 가깝습니다.
읽기 가능성이 높아질수록 추천 가능성을 논의할 기반도 생깁니다.
실무적으로는 다음 순서가 유용합니다.
- 접근 차단 여부부터 확인한다
- 기계가 읽을 수 있는 콘텐츠 형태를 제공한다
- 콘텐츠 사용 방식과 인터페이스 정보를 명확히 둔다
- 필요한 경우 에이전트 로그인과 호출 구조를 정리한다
- 변경 후 재스캔해 결과 변화를 본다
이 흐름은 단순히 체크리스트를 끝내는 것이 아니라, AI 에이전트가 사이트를 처리하는 과정에서 막히는 지점을 줄이는 작업입니다.
특히 사람 방문자와 달리 에이전트는 요청과 응답의 형식에 민감하기 때문에, 작은 설정 차이도 읽기 가능성에 큰 영향을 줄 수 있습니다.
AEO로 보는 추천과 노출의 차이
Agent Readiness가 “읽을 수 있는가”를 본다면, AEO는 “실제로 추천되는가”를 봅니다.
이 둘은 비슷해 보이지만 완전히 다릅니다.
한쪽은 기술적 접근성이고, 다른 한쪽은 응답 안에서의 시장 포지션입니다.
AEO 탭은 사용자가 특정 분야에서 AI 어시스턴트에게 질문했을 때, 해당 사이트가 추천되는지 아니면 경쟁사가 먼저 등장하는지를 점검합니다.
검색엔진처럼 노출 수나 미노출 클릭을 확인할 수 있는 구조가 아니기 때문에, 경쟁사가 언급되는 순간의 기회손실은 따로 드러나지 않습니다.
응답 기반의 측정이 더 중요해집니다.
Cloudflare는 사이트를 보고 산업과 카테고리를 추론한 뒤, Claude와 GPT 같은 주요 어시스턴트에 카테고리별 프롬프트를 던져 결과를 확인합니다.
프롬프트는 실제 탐색 상황을 흉내 내도록 구성되며, 추천, 제품 비교, 일반 조언 같은 질문을 포함합니다.
이 과정에서 다음 지표를 확인합니다.
- Citation Rate: 내 사이트가 출처로 인용된 비율
- Prominence: 인용되었을 때 답변에서 얼마나 앞부분에, 얼마나 많이 반영되는지
- Mention Rate: 브랜드명이 답변에 얼마나 자주 등장하는지
- Share of Voice: 경쟁사 대비 인용 비중이 얼마나 되는지
이 지표들은 서로 같은 의미가 아닙니다.
예를 들어 브랜드명은 자주 나오지만 출처로는 거의 인용되지 않는다면, 인지도는 있지만 근거로 채택되지는 않은 상태일 수 있습니다.
AEO는 이런 차이를 분리해서 보여줍니다.
카테고리 기준 벤치마크를 먼저 만드는 이유
AEO는 사이트별 질의를 매번 처음부터 다시 돌리지 않습니다.
대신 산업과 카테고리별 벤치마크를 먼저 만들고, 그 기준을 여러 계정에 재사용합니다.
이렇게 하면 결과가 빠르게 로드되고, 불필요한 모델 호출도 줄어듭니다.
원문이 강조하는 장점은 세 가지입니다.
- Zero latency: 라이브 호출을 기다리지 않고 스냅샷에서 즉시 결과를 불러옴
- Lower compute overhead: 카테고리 단위로 쿼리를 모아 중복 호출을 줄임
- Industry Fit scoring: 어떤 브랜드가 함께 등장하는지 파악해, 실제 경쟁 구도와 맞는지 평가
즉, AEO는 단순히 한 번의 답변을 보는 도구가 아닙니다.
같은 산업 안에서 어떤 브랜드가 AI 에이전트의 응답 구조 안에 자주 들어오는지 보는 방식입니다.
이것이 추천 경쟁을 더 현실적으로 이해하게 해 줍니다.
결과를 더 신뢰할 수 있게 만드는 측정 방식
AI 어시스턴트는 같은 질문에도 늘 같은 답을 내지 않습니다.
원문은 이 변동성을 고려하기 위해 여러 모델과 여러 차례의 프롬프트를 사용한다고 설명합니다.
Cloudflare AI Gateway를 활용해 각 어시스턴트를 반복 질의합니다.
응답 본문과 출처를 함께 읽어 여러 신호를 추출합니다.
이때 중요한 것은 모델이 스스로 점수를 매기는 방식이 아니라는 점입니다.
Workers AI가 응답을 해석하고, 실제 텍스트를 바탕으로 인용과 언급의 패턴을 판별합니다.
이런 방식은 평가 파이프라인을 직접 구축하지 않아도 되게 해 주며, 응답 품질의 흔들림을 줄여 더 실용적인 지표를 제공합니다.
또 하나의 정보는 AI Operator Activity입니다.
이 항목은 OpenAI, Google 같은 오퍼레이터별 실제 크롤링과 추천 트래픽을 보여줍니다.
누가 콘텐츠를 읽었고 누가 방문자를 돌려보냈는지, 그리고 어디서 403이나 404 같은 오류가 났는지 확인하게 합니다.
특히 수천 페이지를 읽지만 누구도 데려오지 않는 오퍼레이터는 주의 깊게 봐야 합니다.
AI 에이전트가 콘텐츠를 소비하기만 하고 연결을 만들지 않는다면, 그 흐름은 조정이 필요합니다.
무엇을 확인하고, 무엇을 바꿔야 하나
이 도구들의 핵심은 추측을 줄이는 데 있습니다.
예전에는 로그를 뒤져 방문자 정체를 추정하거나, 챗봇에 직접 물어본 뒤 눈으로 확인하는 수준에 머무는 경우가 많았습니다.
이제는 Agent Readiness와 AEO를 통해 실제로 관측 가능한 범위를 넓힐 수 있습니다.
바로 실행해 볼 수 있는 확인 포인트는 다음과 같습니다.
- AI 에이전트가 robots.txt와 사이트맵을 통해 콘텐츠를 찾을 수 있는지
- Markdown이나 메타데이터처럼 읽기 쉬운 형식이 제공되는지
- 인증과 호출 방법이 공개적으로 정리되어 있는지
- 내 카테고리의 질문에서 브랜드가 인용되는지
- 언급은 되지만 출처로는 채택되지 않는 구간이 있는지
- 경쟁사와 비교했을 때 점유하는 답변 비중이 어떤지
이런 확인은 한 번으로 끝나지 않습니다.
사이트를 바꾸고 다시 스캔하면 결과도 달라질 수 있기 때문입니다.
해당 주제 시대에는 콘텐츠를 만드는 것만큼이나, 그 콘텐츠가 모델의 응답 안에서 어떻게 보이는지 점검하는 일이 중요합니다.
핵심 정리
해당 주제가 고객의 발견 경로를 바꾸면서, 사이트는 더 이상 사람만을 기준으로 설계할 수 없게 되었습니다.
Agent Readiness는 읽기 가능성을, AEO는 추천 가능성을 보여 줍니다.
두 도구를 함께 보면 사이트가 실제로 에이전트에게 선택받을 준비가 되어 있는지 판단할 수 있습니다.
결국 중요한 것은 노출 자체가 아니라, 읽히고 신뢰되고 추천되는 흐름입니다.
지금 필요한 것은 검색순위만 보는 관점이 아니라, 해당 주제가 내 사이트를 어떻게 해석하는지까지 확인하는 일입니다.