기술 운영
robots.txt에서 AI 크롤러를 구분하는 법
크롤러는 이름보다 목적을 먼저 구분합니다
robots.txt를 운영할 때는 모든 AI 관련 자동 방문자를 하나로 묶지 말고, 검색 노출·사용자 요청·모델 학습처럼 공개 문서에 명시된 목적별 사용자 에이전트를 구분해야 합니다. 같은 회사가 여러 사용자 에이전트를 제공할 수 있으므로 이름의 일부만 보고 정책을 추정하면 의도와 다른 접근을 허용하거나 막을 수 있습니다.
먼저 우리 사이트가 공개 검색, 학습, 사용자 요청형 접근에 대해 어떤 정책을 가질지 문서로 결정합니다. 그다음 각 제공자의 현재 공식 안내와 대조해 robots.txt 규칙으로 옮기고, 담당자와 검토일을 남깁니다.
공식 문서에서 사용자 에이전트를 확인합니다
OpenAI의 현재 게시자와 개발자 FAQ는 검색 관련 접근에 OAI-SearchBot을, 잠재적 학습 제외에는 GPTBot을 구분해 안내합니다. 이 구분은 다른 제공자나 미래의 명칭에 그대로 일반화할 수 없으므로 사용자 에이전트 이름, 목적, 공식 문서 URL, 확인 날짜를 한 행으로 기록합니다.
Robots Exclusion Protocol 표준도 함께 읽어 규칙 그룹과 매칭 방식을 확인합니다. 블로그 글이나 제3자 목록이 아니라 실제 요청을 보내는 주체의 문서를 기준으로 삼아야 변경을 추적할 수 있습니다.
구체적인 규칙부터 작성합니다
정책표가 준비되면 가장 구체적인 사용자 에이전트 그룹부터 작성하고, 공개해도 되는 경로와 제한할 경로를 분리합니다. 결제, 계정, 내부 검색 결과처럼 공개 대상이 아닌 URL은 robots.txt 하나에 기대지 말고 인증과 접근 제어로 보호합니다.
- 현재 robots.txt와 사이트의 공개 URL 목록을 함께 검토합니다.
- 사용자 에이전트별 허용 목적과 책임자를 승인받습니다.
- 스테이징 문자열을 표준 매칭 규칙에 따라 점검합니다.
- 배포 시각과 이전 규칙을 변경 이력에 보존합니다.
설정과 실제 접근을 함께 검증합니다
배포 후에는 robots.txt가 200으로 제공되는지, 운영 CDN이나 방화벽이 다른 내용을 반환하지 않는지 확인합니다. 서버 로그에서는 선언된 사용자 에이전트의 요청 경로와 응답 상태를 관찰하되, 사용자 에이전트 문자열은 요청자가 임의로 보낼 수 있다는 점을 전제로 해석합니다.
정기 검토에서는 공식 문서의 변경 여부, 새 사용자 에이전트 등장, 로그의 예상 밖 경로를 확인합니다. 설정 파일과 관측 결과를 함께 남기면 정책 의도와 실제 동작의 차이를 찾기 쉽습니다.
robots.txt의 한계를 구분합니다
robots.txt는 접근 정책을 알리는 공개 규약이지 비밀정보를 보호하는 권한 시스템이 아닙니다. 준수하지 않는 클라이언트를 기술적으로 차단하지 못하며, 크롤링 제한이 URL의 모든 형태의 발견이나 표시를 반드시 막는다고 단정해서도 안 됩니다.
크롤러 허용은 검색 노출이나 인용을 보장하지 않고, 차단은 인증을 대신하지 않습니다.
따라서 목표를 노출 보장으로 쓰지 말고 정책 일치, 설정 전달, 실제 요청 관찰처럼 검증 가능한 운영 결과로 정의합니다.
크롤러 정책 체크리스트
- 자동 방문자의 목적별 공개 정책이 승인되어 있나요?
- 각 사용자 에이전트의 이름과 목적을 현재 공식 문서에서 확인했나요?
- 민감한 경로가 인증과 접근 제어로 별도 보호되나요?
- 배포된 robots.txt 응답과 변경 이력을 확인했나요?
- 로그 관측과 정기 문서 재검토 일정을 정했나요?