AI 크롤러 허용·차단 운영: robots.txt·WAF·로그 점검표
User-Agent 한 줄만 추가하는 방식에서 벗어나 AI 크롤러 정책을 검증·관찰·되돌릴 수 있는 운영 체계로 만드는 가이드입니다.
AI 크롤러를 허용하거나 차단하는 일은 robots.txt에 User-Agent 한 줄을 추가하는 것으로 끝나지 않습니다. 운영사마다 검색 결과 노출, 모델 학습, 사용자 요청 대행처럼 봇의 목적과 제어 방법이 다를 수 있고, 같은 이름을 흉내 낸 비정상 요청도 존재합니다. robots.txt, CDN 캐시, WAF, 서버 속도 제한과 로그를 하나의 정책으로 관리해야 합니다.
또한 robots.txt 허용은 인용, 추천, 검색 노출이나 트래픽을 보장하지 않습니다. 차단 역시 비공개 데이터를 보호하는 접근 통제 수단이 아닙니다. 로그인·권한·네트워크 제한이 필요한 콘텐츠는 인증으로 보호하고, robots.txt는 협조적인 크롤러에게 공개 URL의 수집 지침을 전달하는 용도로 사용해야 합니다.
1. 먼저 크롤러의 목적과 데이터 범위를 구분합니다
정책 문서에는 봇 이름보다 어떤 콘텐츠를 어떤 목적으로 제공할지 적습니다. 공개 마케팅 페이지, 문서, 사용자 생성 콘텐츠, 회원 전용 영역과 개인 데이터는 위험과 사업 가치가 다릅니다.
- 검색·발견: AI 검색 결과에서 공개 페이지를 찾고 연결하거나 인용하기 위한 수집
- 모델 학습: 모델 개선을 위한 데이터 수집
- 사용자 요청: 사용자의 명시적 요청에 따라 페이지를 불러오는 에이전트 또는 브라우저형 접근
- 일반 검색봇: 전통적인 검색 색인과 검색 결과 생성을 위한 수집
서비스마다 이름과 정책이 변경될 수 있으므로 현재 공식 게시자 문서에서 User-Agent, IP 검증 방법과 제어 범위를 확인합니다. 커뮤니티 목록이나 오래된 블로그 표를 운영 정책의 유일한 근거로 사용하지 않습니다.
2. robots.txt 규칙은 호스트별 실제 응답으로 검증합니다
robots.txt는 프로토콜과 호스트별로 적용됩니다. https://example.com/robots.txt를 수정해도 다른 서브도메인이나 별도 호스트에 자동으로 같은 규칙이 적용되는 것은 아닙니다. 배포 뒤에는 저장소 파일이 아니라 공개 URL의 응답을 확인해야 합니다.
- HTTP 상태가 200인지, 예상한 Content-Type과 본문을 반환하는지 확인합니다.
- CDN·리버스 프록시의
Age나 캐시 상태를 보고 이전 규칙이 남아 있는지 확인합니다. - User-Agent 그룹 병합과 wildcard 규칙이 의도한 결과를 만드는지 테스트합니다.
- 사이트맵 선언과 중요한 공개 경로가 실수로 차단되지 않았는지 확인합니다.
- 배포 전후 원본을 보관하고 잘못된 규칙을 즉시 되돌릴 수 있게 합니다.
robots.txt로 차단한 URL이 검색 결과에서 반드시 사라지는 것은 아닙니다. 크롤링을 막으면 페이지 안의 noindex를 읽지 못할 수 있습니다. 검색 색인 제외가 목적이라면 해당 검색엔진의 공식 지침에 맞는 noindex 또는 접근 통제를 사용해야 합니다.
3. User-Agent만으로 WAF를 우회시키지 않습니다
User-Agent 헤더는 요청자가 임의로 작성할 수 있습니다. 이름에 GPT, AI, Google 또는 특정 회사명이 들어갔다는 이유만으로 방화벽을 우회하거나 요청 제한을 해제하면 사칭 트래픽에 취약해집니다.
- 운영사가 공식 IP 범위 또는 검증 절차를 제공하는지 확인합니다.
- IP 정보가 있다면 공식 출처에서 자동 갱신하고 변경 실패 시 이전 안전 정책을 유지합니다.
- User-Agent, 검증된 네트워크, 요청 패턴과 대상 경로를 함께 평가합니다.
- 관리자·로그인·검색·고비용 API는 정상 봇이라도 별도 보호 규칙을 적용합니다.
- 예외 규칙에는 만료일과 담당자를 지정하고 정기적으로 재검토합니다.
공식 IP 목록이 없는 봇은 무조건 허용하거나 무조건 차단하기보다 공개 정적 페이지에 제한된 속도로 접근하도록 하고, 고비용 동적 경로와 민감 경로는 일반 사용자와 동일한 보호를 유지하는 방식이 현실적입니다.
4. 속도 제한은 서버 보호와 크롤링 가능성을 함께 봅니다
robots.txt의 Crawl-delay 지원 여부는 크롤러마다 다릅니다. 지원하지 않는 봇에 규칙을 적어도 서버 부하가 제어되지 않을 수 있으므로 CDN·WAF·웹서버의 요청 제한을 함께 사용합니다. 다만 모든 요청을 하나의 IP 기준으로 강하게 제한하면 공유 네트워크나 정상 크롤러를 잘못 차단할 수 있습니다.
- 등록 가능 도메인과 고비용 경로별 요청량을 분리합니다.
- 429, 403, 5xx와 연결 종료를 User-Agent 및 경로와 함께 기록합니다.
- HTML, 이미지, API, 사이트맵의 비용 차이를 고려합니다.
- 트래픽 급증 시 자동 차단뿐 아니라 수동 되돌림과 예외 승인 절차를 둡니다.
5. 로그에서 허용 정책이 실제로 작동하는지 확인합니다
서버·CDN 로그에서 다음 항목을 최소한 집계합니다. 원문 IP와 전체 URL에 민감 정보가 포함될 수 있으므로 보존 기간, 마스킹과 접근 권한도 함께 설계합니다.
- User-Agent와 검증 상태
- 요청 경로·상태 코드·전송량·응답 시간
- robots.txt와 사이트맵 요청 시각
- 429·403·5xx 비율과 재시도 패턴
- 캐시 적중률과 원본 서버 요청량
방문 로그, 추천 유입과 AI 서비스의 인용은 서로 다른 데이터입니다. 크롤러 요청이 늘었다고 추천 트래픽이 증가했다고 단정하지 말고, 분석 도구의 referral, 서버 로그와 서비스별 게시자 도구가 제공하는 데이터를 분리해서 봅니다.
6. 정책 변경은 배포·관찰·복구의 세 단계로 운영합니다
- 배포 전: 대상 봇, 경로, 목적, 기대 효과와 위험을 기록합니다.
- 배포 후: 공개 robots.txt, 캐시, WAF 적중, 요청량과 오류를 확인합니다.
- 복구: 원본 규칙과 WAF 설정을 보존하고 부하·오탐·민감 경로 접근 시 되돌립니다.
월 1회 또는 운영사 정책 변경 시 User-Agent와 공식 문서를 다시 확인하세요. 좋은 AI 크롤러 정책은 많이 허용하거나 많이 차단하는 정책이 아니라, 공개 범위와 사업 목적을 명확히 하고 실제 요청을 검증하면서 안전하게 조정할 수 있는 정책입니다.