Cloudflare의 Bot Trust 업데이트: 2026년 AI 기반 크롤러를 위한 다섯 가지 테스트

자동화 시스템은 자신을 올바르게 소개하고, 로그인 상태를 유지하면서도 웹사이트에서 최악의 방문자가 될 수 있습니다.

Cloudflare는 10월 16일 검증된(Verified) 봇에 대한 지속적인 평가 시스템을 설명했습니다. 이 초기 신호에는 트래픽이 게시된 robots 선호도(robots preferences)를 따르는지, 그리고 사이트가 HTTP 429 응답을 반환한 후 적응하는지가 포함됩니다. 회사는 먼저 내부적으로 시스템을 사용하고 있으며, 공개 점수와 고객 선택 가능한 신뢰 임계값은 계획 단계이며 오늘 모든 고객이 구성할 수 있는 것은 아니라고 밝히고 있습니다.

가장 유용한 초보자 교훈은 인프라 발표보다 작습니다: 자신의 소프트웨어가 무엇인지 아는 것이 그것이 경청한다는 것을 증명하지 못합니다.

AI에게 크롤러, 리서치 어시스턴트 또는 예약 가져오기(scheduled importer)를 구축하도록 요청했다면, 첫 페이지를 다운로드한 후 테스트를 멈추지 마십시오. 목적지가 답변을 변경하는 순간까지 테스트해야 합니다.

저는 그 행동에 큐(queue)를 확장하기 전에 별도의 체크리스트를 부여하고 싶습니다.

작고 가상의 작업으로 시작하기

접근 권한이 있는 사이트에서 문서 페이지 10개를 가져오는 데모 앱을 상상해 보세요.

이 앱에는 두 개의 워커가 있습니다. 각 워커는 대기열에 있는 페이지를 받아 다운로드하고 결과를 기록합니다. 프로세스를 일시 중지했다가 다시 시작할 수 있습니다.

그것만으로도 중요한 문제를 노출하기에 충분한 장치입니다. 워커 1은 속도 저하 신호를 받을 수 있는 반면, 워커 2는 계속해서 요청을 보낼 수 있습니다. 재시작 시 일시 중지 상태를 잊어버릴 수 있습니다. 오래된 대기열에는 더 이상 적격하지 않은 페이지가 포함될 수 있습니다.

이러한 실수들을 다른 사람의 운영 웹사이트에 대해 테스트할 필요는 없습니다. 로컬 테스트 서버나 합성 페이지와 요청 로그를 가진 제어된 장치(controlled fixture)를 사용하십시오.

만약 아이디어를 경계가 있는 첫 번째 프로젝트로 전환하는 것이 어려운 부분이라면, 저의 $3 AI 앱 빌더 스타터 프롬프트가 안내되는 시작점이 될 수 있습니다. 이 연습을 위해 프로젝트를 하나의 대기열과 다섯 가지 관찰 가능한 테스트로 제한하십시오.

테스트 1: 금지된 경로는 다운로더에 도달하지 않는다

허용된 데모 경로 하나와 fixture의 robots 규칙에 의해 제외되는 경로 하나를 만드세요. 둘 다 대기열(queue)에 넣으세요.

원하는 결과는 제외된 페이지를 다운로드한 후 오류가 발생하는 것이 아닙니다. 해당 경로에 대한 콘텐츠 요청이 전혀 없으며, 건너뛴 이유가 명확하게 표시되어야 합니다.

RFC 9309는 Robots Exclusion Protocol을 정의하며, 이를 접근 권한 부여와 명시적으로 분리합니다. robots 파일은 로그인 시스템이나 보편적인 허가증이 아닙니다. 사용자의 앱은 여전히 목적지에 접근하기 위한 적절한 근거를 필요로 하며, 그곳의 다른 제어 사항들을 존중해야 합니다.

AI에게 몇 가지 문자열 검사를 발명하는 것보다 프로토콜에 대한 확립된 파서(parser)를 사용하도록 요청하세요. 그런 다음 fixture의 실제 요청 로그를 검사하십시오.

제가 받아들일 수 있는 기준은 다음과 같습니다: "제외된 콘텐츠 URL은 요청이 0건이었으며, 대기열에서 그 이유를 설명하고 있다."

테스트 2: 한 번의 지연이 두 워커 모두에게 도달하는 경우

fixture가 첫 번째 콘텐츠 요청 시 HTTP 429와 짧은 대기 지침을 반환하도록 만드세요.

RFC 6585는 429를 속도 제한(rate limiting)으로 정의하며 Retry-After 헤더를 허용합니다. 이 프로토콜은 사용자 앱에게 보편적인 할당량(quota)을 제공하지 않습니다. 제공업체들은 요청을 다양한 방식으로 계산할 수 있습니다.

이 작은 데모의 경우, 저는 보수적인 목적지 전체 일시 중단(pause)을 선택할 것입니다. 두 워커 모두 다른 요청을 시작하기 전에 동일한 다음 적격 시간(next-eligible time)을 확인합니다. 이것은 예시를 위한 설계 선택일 뿐이며, 모든 API가 사이트 전체 제한을 사용한다는 주장은 아닙니다.

이제 일시 중단 기간 동안 로그를 확인해 보세요. 만약 워커 2가 여전히 동일한 목적지에 요청을 보내고 있다면, "워커 1이 기다리고 있다"는 메시지만으로는 불충분합니다.

또한 이미 진행 중인(in flight) 요청들을 고려해야 합니다. 각 요청이 언제 시작했는지 기록하여, 일시 중단 기간이 알려진 후 새로 전송된 작업과 구별할 수 있도록 하세요.

테스트 3: 재시작이 일시 중단을 지우지 않는 경우

대기하는 동안 데모를 중지시키세요. 그 기간이 끝나기 전에 다시 시작하세요.

큐는 목적지의 다음 이용 가능 시간을 유지해야 합니다. 앱이 즉시 다시 시작하는 경우, 일시 정지(pause)는 단 하나의 프로세스 메모리에만 존재했을 뿐입니다.

여기서 저는 AI에게 단순히 sleep 호출을 포함하는 함수가 아니라 저장된 상태를 보여달라고 요청할 것입니다.

유용한 테스트 기록에는 목적지, 받은 피드백, 결과로 발생한 일시 정지 시간, 그리고 다음 요청 시작 시간이 포함되어야 합니다. 자격 증명(credentials)과 응답 본문은 실제로 필요하고 보관해도 안전하지 않은 경우가 아니라면 해당 기록에서 제외하세요.

테스트 4: 변경된 환경 설정이 대기 중인 작업에 영향을 미치는 경우

여러 데모 페이지를 대기 상태로 남겨둔 다음, 다음 배치(batch)가 시작되기 전에 피처(fixture)의 정책을 변경해 보세요.

앱이 해당 정책을 언제 새로 고치는지, 그리고 대기 중인 작업이 새로 고쳐진 결과와 어떻게 비교되는지 정의하세요. 프로토콜의 캐싱 규칙과 목적지의 문서화된 요구 사항을 사용하고; 설치 시 한 번 조회한 것이 영원히 지속된다고 가정하지 마세요.

중요한 제품 결정은 오래된 작업에 무슨 일이 일어나는가입니다. 저는 제외된 항목을 조용히 삭제하거나 다른 식별자를 시도하는 대신, 그 이유와 함께 건너뛴(skipped) 것으로 보존할 것입니다.

다른 계정, 주소 또는 브라우저로 거부(refusal)를 우회해서는 안 됩니다. 기술적으로 성공적인 다운로드는 당신이 지켜야 할 경계를 회피했다면 성공적인 테스트가 아닙니다.

테스트 5: 사용자에게 불완전한 작업 결과를 정직하게 보여주는 경우

10페이지 중 4페이지가 완료된 후 데모를 일시 중지하세요.

인터페이스는 프로세스가 정상적으로 종료되었기 때문에 '조사 완료'라고 말해서는 안 됩니다. 완료된 4개 페이지, 남아 있는 항목들, 목적지의 일시 정지 시간, 그리고 어떤 결과가 오래되었거나(stale) 이용 불가능한지 여부를 보여주어야 합니다.

이것은 또한 부분적인 출력이 유용한지 여부를 결정하는 곳입니다. 문서 검색은 자신이 가진 페이지와 명확한 커버리지를 보여줄 수 있습니다. 하지만 10개 소스 전체가 필요한 비교 작업은 불완전하게 남아 있어야 할 수도 있습니다.

어떤 결정도 다운로더 내부에 숨겨져서는 안 됩니다.

행동을 요청하는 프롬프트, 안심시키는 것을 요청하는 것이 아닌

저는 AI에게 다음과 같은 프롬프트를 줄 것입니다:

로컬 전용 테스트 하네스(test harness)를 문서 임포터에 구축하세요. 합성 페이지와 외부 요청 없이 사용해야 합니다. 제외된 경로, HTTP 429 피드백, 목적지 일시 중단 공유 작업자 두 개, 일시 중단 중 재시작, 그리고 작업이 대기열에 있는 동안 정책 변경을 위한 테스트 케이스(fixture)를 추가하세요. 구현하기 전에 예상되는 모든 요청 시퀀스를 명시하세요. 요청 시작 시간과 대기열 전환을 기록하세요. 발생하지 않은 요청은 무엇인지 증명하세요. 불완전한 커버리지도 정직하게 보여주세요. 테스트가 통과하도록 신원이나 제어 장치를 변경하거나 우회해서는 안 됩니다.

프롬프트가 요구하지 않는 것을 주목하세요: '크롤러를 견고하게(robust) 만드세요.'

이 형용사는 해석의 여지를 너무 많이 남깁니다. 요청 시퀀스, 지속적인 일시 중단, 그리고 눈에 보이는 미완성 대기열은 검사할 무언가를 제공합니다.

첫 번째 구현은 소박하게 유지하세요

목적지 전체에 걸친 일시 중단(pause)은 별도의 문서화된 제한 사항이 있는 API에는 지나치게 신중할 수 있습니다. 다중 머신 배포는 작은 로컬 데모보다 더 강력한 조정이 필요합니다. 테스트 케이스만으로는 외부 서비스가 시뮬레이션과 정확히 동일하게 작동할 것이라고 증명할 수 없습니다.

이것들은 테스트를 건너뛸 이유가 아니라, 테스트의 한계를 명시해야 할 이유입니다.

하나의 목적지와 하나의 명확한 정책으로 시작하세요. 작업자나 목적지를 추가할 때마다 그 경계에서 테스트를 반복하세요.

$3 Starter Prompts는 제한된 프로젝트를 시작하는 데 도움을 줍니다. 계획, 구현, QA(품질 보증), 출판에 이르는 체계적인 과정을 위해 AI App Builder From Zero가 $9 단독 전자책으로 제공됩니다. 별도의 40개 프롬프트 워크북은 포함되어 있지 않습니다. $10 학습 번들에는 전체 책과 모든 40개의 Starter Prompts가 포함됩니다.

적격 구매 시 미래의 Bootcamp Bundle 혜택을 받습니다: $3 프롬프트와 함께 $20, 단독 도서와 함께 $30, 또는 학습 번들과 함께 $70입니다. 인증된 Apple Books 및 Kindle 결합 에디션은 $70에 해당하며, 각 스토어는 자체 가격을 표시합니다. 구매자당 하나의 인증 혜택이 제공되며, 체크아웃 시 두 패키지 중 하나에 한 번 사용됩니다. 이 혜택은 중복 적용되지 않으며 현금 가치가 없고, 환불되거나 분쟁이 발생한 구매는 제외됩니다. 이전에 발급된 혜택은 원래의 약관을 유지합니다.

[Bootcamp Bundle (Review Radar)]가 곧 출시될 예정이며(https://marcusykim.com/review-radar/), 하나의 앱 프로젝트에 $399, 세 개의 앱 프로젝트에 $999로 계획되어 있습니다. 여기에 포함된 계획 연구, 사양, 화면 디자인 및 가이드 커리큘럼은 완성된 앱이 아닙니다. 기존 페이지를 통해 대기 목록 업데이트를 요청할 수 있으며, 결제는 여전히 마감되었습니다.

마지막 확인은 간단합니다: 목적지가 답변을 변경했을 때, 모든 작업자가 그 행동 변화를 보여줄 수 있습니까?

저를 다음에서도 찾으실 수 있습니다:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim