검증된 AI 봇은 무조건 허용해도 될까? Cloudflare의 신원·행동 평가

공개 문서를 찾아 주는 봇이 서버를 바쁘게 만든다면

개발자 문서 사이트를 운영한다고 하자. 검색을 통해 문서가 발견되기를 원하지만, 큰 내보내기 파일까지 계속 내려받거나 같은 페이지를 짧은 간격으로 반복 조회하면 운영 비용이 커진다. 접속 기록에는 익숙한 봇 이름이 보인다. 이 이름이 진짜라는 확인을 마치면 예외 허용 목록에 넣어도 될까?

결정하려면 세 질문이 남는다. 누가 보냈는가, 무엇을 허용했는가, 그 뒤 어떻게 행동했는가. 검색에 도움이 되는 운영자의 봇이라도 특정 경로에 대한 수집을 원하지 않을 수 있다. 허용한 경로만 방문하면서 요청량을 과도하게 만들 수도 있다. 반대로 요청 한 건이 정책과 어긋나 보인다는 이유만으로 의도적인 회피라고 단정하면 정상 봇을 잘못 제한할 수 있다.

이 글은 사이트 운영자의 관점에서 세 질문을 분리한다. 아래 문서 사이트와 트래픽 수치는 직접 만든 가상 사례다. 실제 서비스 로그를 수집하거나 Cloudflare 계정에서 기능을 실행한 결과가 아니다.

10월 16일 발표에서 현재인 것과 계획인 것

Cloudflare는 2026년 10월 16일 Verified bots의 지속 평가 체계를 발표했다. robots.txt의 사이트 선호를 따르는지, HTTP 429를 받은 뒤 요청을 줄이거나 쉬는지를 관찰해 설명 가능한 신뢰 구간(trust band)으로 연결한다는 내용이다. 한 번의 이탈보다 반복되는 행동을 보겠다는 방향이다.

발표 본문은 이미 내부 평가에 사용 중이라고 밝힌다. Radar에서 점수를 공개하고, 모든 Cloudflare 고객에게 제공해 봇 처리에 사용할 임계값을 선택하게 하는 것은 향후 계획이다. 10월 19일 확인한 발표만으로 지금 설정할 수 있는 점수 필드·대시보드 메뉴·제공일·가격을 확정할 수는 없다.

따라서 지금 가져갈 수 있는 것은 새로운 숫자의 설정법보다 관측 구조다. 신원, 공개 정책, 피드백 이후 행동을 연결하면 허용한 봇에도 지속적인 판단 근거를 붙일 수 있다. 이 구조가 자동으로 색인이나 검색 유입을 늘려 준다는 근거는 아니다.

Verified의 의미와 사이트의 허용 결정

현재 Verified bots 문서는 정직한 자기 식별과 비남용 행동을 요건으로 설명한다. 신원 확인에는 암호학적 서명, 공개 IP 목록과 안정된 User-Agent, 역방향 DNS 같은 방법이 쓰인다. Verified를 단순히 이름만 대조한 상태로 축소해서도 안 된다.

그래도 프로그램의 인정과 개별 사이트의 허용 범위는 다르다. 같은 문서는 Search·Training·Agent 등 행동을 구분하고, 한 봇이 여러 행동에 속할 수 있다고 설명한다. 검색 색인을 위한 방문과 학습용 수집, 사람 요청을 대신한 방문은 사이트 소유자에게 같은 선택이 아닐 수 있다. 새 분류가 모두 WAF 사용자 정의 규칙의 개별 필드인 것도 아니다. 현재 문서가 구분하는 분류와 기존 규칙 범주를 대조해야 한다.

다음 표는 이 차이를 업무 결정으로 옮긴 편집 기준이다. Cloudflare의 실제 점수 산식이나 기본 설정표는 아니다.

판단	필요한 근거	확인해도 남는 질문
신원	제공자가 검증한 운영자 정보, 검증 방법과 성공 여부	이 운영자의 모든 목적을 우리 사이트가 허용하는가?
정책	대상 봇·목적·경로별 허용 범위와 실제 적용 규칙	설정과 외부에 게시한 안내가 일치하는가?
행동	해당 정책이 유효했던 시간의 요청, 응답 뒤 변화	관측 공백이나 이미 진행 중인 요청으로 설명되는가?

예를 들어 문서 본문 열람은 허용하되 비용이 큰 묶음 내보내기는 제한할 수 있다. 이런 결정을 먼저 써 두어야 “검증된 봇이니 모두 통과”와 “자동 요청이니 모두 거절” 사이에서 실제 업무에 맞는 선택을 할 수 있다.

서명이 증명하는 범위도 한정돼 있다

Web Bot Auth 문서의 방식은 등록한 공개 키와 HTTP 메시지 서명을 연결해 요청의 신원을 검증하는 것이다. 현재 Cloudflare 통합은 Ed25519 키와 키 디렉터리 등록 절차를 안내하며, 기반 프로토콜 일부는 IETF 초안이다. 모든 구현이 같은 규격 전체를 지원한다고 가정하면 안 된다.

서명 성공을 고객 계정의 로그인이나 자료 접근 권한으로 사용해서는 안 된다. “등록된 운영자의 서명으로 확인됐다”에서 “이 사용자가 비공개 파일을 읽어도 된다”로 넘어가려면 별도의 권한 검사가 필요하다는 설계 판단이다.

재전송 방지 역시 자동 보장으로 읽으면 곤란하다. 확인한 문서는 현재 nonce 검증과 사용한 nonce 데이터베이스를 통한 재전송 차단을 하지 않으며, 짧은 만료 시각을 권고한다고 명시한다. 이 글은 서명 코드를 제공하거나 보안성을 시험하지 않았다. 도입 시에는 사용 중인 구현의 서명 대상·만료·재전송 처리까지 따로 검토해야 한다.

robots.txt: 현재 파일만 보고 과거 요청을 판정하지 않는다

가상 문서 사이트가 다음 정책을 게시했다고 하자. ExampleDocsBot은 설명용 봇 이름이다.

User-agent: ExampleDocsBot
Disallow: /exports/
Allow: /docs/

이 파일은 해당 봇에게 크롤링 경로에 관한 규칙을 알린다. RFC 9309 §1·§3은 robots 규칙이 접근 권한 부여나 콘텐츠 보안 장치가 아니라고 구분한다. 민감한 내보내기 파일은 인증·권한 검사로 보호해야 한다. 파일에 경로를 적었다는 이유로 서버가 요청을 차단하는 것도 아니다.

가상 운영 일지를 보자.

시각	사이트와 봇의 상태	운영자의 다음 확인
09:00	봇이 정책 v1을 받음. 내보내기 제한 없음	실제로 전달한 본문·캐시 안내를 남긴다
09:10	사이트가 v2에 /exports/ 제한 추가	적용 시점과 공개 파일이 같은지 확인한다
09:11	같은 봇의 내보내기 요청 한 건 관측	v2 수신 여부와 캐시·진행 중 요청을 먼저 확인한다
10:00 이후	봇이 v2를 받아 적용한 사실을 확인한 뒤에도 제한 경로 요청 반복	예외 규칙·식별 오류를 제외하고 지속 이탈로 조사한다

RFC 9309 §2.4는 robots.txt 캐시를 허용하며, 파일에 접근할 수 없는 경우를 제외하면 24시간 넘게 캐시를 사용하지 않도록 권고한다. 정책을 바꾼 즉시 모든 봇의 판단이 바뀌었다고 가정할 수 없다. 이 권고를 무조건 24시간 유예해 줘야 한다는 운영 규칙으로 바꿀 필요도 없다. 즉시 막아야 할 접근은 서버에서 별도로 제어한다.

또한 robots.txt 자체의 404 같은 4xx와 503 같은 서버 오류는 규격상 처리 범위가 다르다. 전자는 파일을 사용할 수 없는 경우로 접근을 허용할 수 있지만, 후자는 도달할 수 없는 경우로 원칙적으로 전체 금지를 가정한다. 캐시와 장기 장애 예외도 있다. 정책을 지키지 않는 것처럼 보이면 파일 내용뿐 아니라 봇이 받은 상태 코드부터 확인할 이유다. 콘텐츠 URL의 429와 robots.txt 조회 실패는 같은 사건으로 합치지 않는다.

여기서 “봇이 v2를 읽었다”는 서버의 성공 응답 기록만으로 완전히 입증되지는 않는다. 수신·파싱·적용 여부가 불명확하면 그 부분은 미확인으로 남긴다. 이 구분이 있어야 잘못된 캐시 배포와 실제 봇의 정책 무시를 구별할 수 있다.

429를 받은 한 작업만 쉬면 전체 요청은 계속된다

RFC 6585 §4의 429는 일정 시간 동안 너무 많은 요청을 보냈다는 응답이다. 기다릴 시간을 알려 주는 Retry-After가 포함될 수 있지만 필수는 아니다. 규격은 사용자를 어떻게 식별하고 요청을 어느 범위로 세는지까지 하나로 정하지 않는다. 경로별·서버 전체·여러 서버에 걸친 한도인지 실제 서비스 정책을 확인해야 한다.

Retry-After의 정수 값은 응답 수신 뒤 기다릴 초 단위 시간이다. HTTP 날짜로도 나타낼 수 있다. 아래 예시의 60은 60초다.

HTTP/1.1 429 Too Many Requests
Retry-After: 60

이제 문서 사이트와 크롤러 사이에 같은 운영자의 이 호스트 요청 전체를 60초 멈춘다는 정책이 명확히 공유됐다고 가정하자. 이는 사례의 계약이지 429의 보편적 기본 범위가 아니다. 크롤러는 네 개 작업 프로세스가 각각 초당 5건을 보내고 있다.

직접 그린 설명도. 일정한 요청 속도와 이미 진행 중인 요청이 없는 구간을 가정한 산술이며 실제 봇·Cloudflare의 측정 화면이 아니다.

같은 조건의 가상 구간	프로세스별 신규 요청률	전체 요청률
응답 전	5 + 5 + 5 + 5	초당 20건
429를 받은 프로세스 하나만 대기	0 + 5 + 5 + 5	초당 15건
네 프로세스가 공통 대기 상태 확인	0 + 0 + 0 + 0	초당 0건

한 프로세스의 로그에는 “60초 대기”가 정확히 남아도 사이트에는 요청이 계속 온다. 전체로는 25% 줄었지만 이 사례의 호스트 공통 중단 조건을 지킨 것은 아니다. 반대로 한 경로에만 걸린 제한이었다면 전체 호스트를 멈추는 쪽이 불필요하게 수집을 지연시킬 수 있다. 어디까지 함께 쉬어야 하는지가 먼저다.

크롤러를 만든다면 같은 범위의 작업이 공유하는 다음 허용 시각을 두고, 응답을 받은 작업이 이를 갱신하며, 새 요청을 보내기 전에 각 작업이 다시 확인하는 설계를 검토할 수 있다. 프로세스마다 자기 타이머만 두면 위 빈틈이 남는다. 이 설명은 설계안이며 분산 저장소·시계 오차·원자적 갱신을 구현한 코드가 아니다.

사이트 운영자는 “429 이후에도 요청이 한 건 왔다”보다 다음을 본다.

• 비교 구간: 응답 전후를 같은 길이로 비교하되, 이미 전송 중인 요청과 피드백 전달 지연을 구분한다.
• 같은 집계 대상: 요청 IP 하나의 감소와 같은 운영자 전체의 감소를 혼동하지 않는다. 검증 근거 없이 여러 IP를 한 봇으로 묶지도 않는다.
• 범위와 재개: 어느 호스트·경로·운영자에 적용된 제한인지, 대기 뒤 요청이 한꺼번에 몰리는지 확인한다.
• 서버 결과: 봇 요청이 줄어도 다른 부하가 남을 수 있으므로 원점의 오류·지연을 함께 본다.

가령 이미 전송 중이던 요청 다섯 건이 늦게 도착한 경우와 60초 내내 초당 15건을 새로 보내는 경우는 다르다. 로그가 두 상태를 구분하지 못한다면 단정 대신 봇 운영자에게 응답 수신·대기 적용 시각을 대조할 수 있는 최소 기록을 요청한다. 전체 요청 본문이나 개인정보를 복제할 필요는 없다.

허용·제한·미확인을 나누는 운영 기록

사이트에는 검색 발견, 서비스 비용, 문서 최신성 같은 서로 다른 목적이 있다. 이 중 하나만으로 모든 봇의 처리를 정하지 않는다. 다음 표는 앞 사례를 검토할 때 사용할 수 있는 판단 순서다.

관측	가능한 결정	결정을 바꿀 조건
신원 확인, 허용 경로, 피드백 뒤 적절히 감소	현재 범위의 허용 유지·다음 관측일 지정	요청 목적·경로·부하가 달라짐
신원 확인, 게시 정책과 실제 차단 규칙이 불일치	우리 설정부터 정리하고 같은 조건으로 재관측	봇이 받은 정책이 일치했다는 자료 확보
신원 확인, 같은 제한 범위에서 반복적으로 새 요청 지속	해당 범위 제한·운영자 확인·해제 조건 기록	적용 오류 수정 후 충분한 관측에서 정상 확인
User-Agent 이름만 같고 신원 미확인	확인된 운영자에게 곧바로 책임을 돌리지 않음	신뢰할 검증 방법으로 동일 운영자 연결
요청이 적거나 관측 구간이 비어 있음	행동 평가는 미확인	판단 가능한 요청과 피드백 사례 확보

HTTP 200은 요청을 처리했다는 기록이고, 429는 제한 신호다. 어느 것도 검색엔진이 URL을 색인했거나 AI 답변에 인용했다는 증거는 아니다. 사이트의 발견 성과를 보려면 해당 시스템의 색인·노출·유입 자료를 별도로 확인한다. 봇 트래픽 증가 자체를 독자 증가로 세지 않는 이유다.

봇 정책·행동 관측표 내려받기

대상 사이트 / 관측 기간:
봇 운영자 / 식별 근거 / 미확인 항목:
허용 목적·경로 / 제한 범위:
게시 정책 버전·시각 / 실제 적용 규칙:
정책 조회 응답·캐시 / 봇 적용 여부:
429 시각·Retry-After / 응답 수신 여부:
전후 비교 구간·신규 요청 수 / 진행 중 요청:
다른 작업·IP의 집계 근거 / 재개 후 부하:
판정: 허용 유지 / 범위 제한 / 설정 정리 / 미확인
반대 설명 / 해제 조건 / 다음 관측일:

처음부터 정교한 신뢰 점수를 자체 제작할 필요는 없다. 가장 비싼 공개 경로 하나에서 정책과 로그의 시간 기준을 맞추고, 정상 감속과 분산 작업의 대기 누락을 구분할 수 있는지부터 확인하면 된다. 요청량이 작고 문제가 없다면 관측·검증 체계의 비용이 편익보다 클 수도 있다. 자료가 없는 봇을 낮은 점수로 채우는 방식은 피한다.

클라이언트의 재시도 구현까지 다루려면 마감 시간과 재시도 예산으로, 정책 변경 전후의 캐시 응답을 이해하려면 HTTP 신선도와 재검증으로 이어 읽을 수 있다. 운영 검토 때 이 표를 다시 쓰려면 글 저장 기능을, 다음 분석을 받아보려면 RSS를 이용할 수 있다.