AI 스크래퍼를 실제로 차단하는 robots.txt 작성법

robots.txt에 관한 불편한 진실

robots.txt 파일은 자물쇠가 아닙니다. 문에 붙인 안내문에 가깝습니다.

팀에서 작은 텍스트 파일 하나로 “AI 스크래퍼를 차단”할 수 있는지 물을 때, 이 차이는 중요합니다. Robots Exclusion Protocol을 따르는 신뢰할 만한 크롤러라면, 그렇습니다. 올바르게 작성된 robots.txt는 페이지를 크롤링하지 말라고 알릴 수 있습니다. 하지만 알 수 없는 스크래퍼, 사칭 봇, 브라우저 자동화, 그리고 애초에 신경 쓰지 않는 봇에는 그 자체로 아무 효과가 없습니다.

따라서 실무적인 목표는 “스크래핑을 불가능하게 만들기”가 아닙니다. 목표는 다음과 같습니다.

• 규칙을 준수하는 AI 크롤러에 사이트를 사용하지 말라고 알리기.
• 검색 엔진이나 유용한 서비스를 실수로 차단하지 않기.
• 악용에 대해서는 더 강한 서버 측 제어를 추가하기.
• 크롤러 이름이 바뀌어도 정책을 유지 관리할 수 있게 하기.

이것이 덜 화려한 설명입니다. 그리고 실제로 작동하는 설명이기도 합니다.

robots.txt가 할 수 있는 것과 할 수 없는 것

robots.txt 파일은 사이트의 루트에 위치합니다.

https://example.com/robots.txt

크롤러는 크롤링하기 전에 이 파일을 요청합니다. 파일에는 규칙 그룹이 들어 있습니다. 각 그룹은 하나 이상의 User-agent 줄로 시작하고, 그 뒤에 Allow 또는 Disallow 지시문이 옵니다.

사이트 전체를 차단하는 간단한 예는 다음과 같습니다.

User-agent: GPTBot
Disallow: /

이 의미는 다음과 같습니다. 당신이 GPTBot이라면, 이 사이트의 어떤 것도 크롤링하지 마십시오.

하지만 robots.txt에는 분명한 한계가 있습니다.

1. 자발적인 규칙입니다. 악의적인 행위자는 무시할 수 있습니다.
2. 일반 브라우저나 스크립트가 URL을 요청하는 것을 막지 못합니다.
3. 이미 다른 곳에서 수집된 콘텐츠를 제거하지 못합니다.
4. 그 자체로 저작권, 라이선스, 학습 권리를 정의하지 않습니다.
5. 잘못 설정하면 엉뚱한 봇을 차단할 수 있습니다.

진정한 접근 제어가 필요하다면 인증, 권한 부여, 속도 제한, IP 기반 제어, 봇 관리 또는 법적 통제를 사용해야 합니다. Robots.txt는 여전히 유용하지만, 더 넓은 콘텐츠 보호 전략 안에 있어야 합니다.

이는 다른 웹 거버넌스 문제와도 비슷합니다. 눈에 보이는 제어가 전체 제어인 경우는 드뭅니다. 조직 내부에 이미 관리되지 않는 AI 사용이 있다면 같은 원칙이 적용됩니다. 단일 정책 문서가 문제를 해결한다고 가정하기보다 간단한 shadow AI audit이 더 유용한 경우가 많습니다.

정책 결정부터 시작하기

파일을 편집하기 전에, 실제로 무엇을 차단하려는지 결정해야 합니다.

사람들이 “AI 스크래퍼”라고 말할 때는 적어도 네 가지 다른 의미가 있습니다.

• 학습 데이터를 수집하는 데 사용되는 크롤러.
• AI 검색 또는 답변 엔진 크롤러.
• 사용자가 AI 제품에 URL 요약을 요청할 때와 같은 사용자 트리거 fetcher.
• 일반 브라우저인 척하는 범용 스크래퍼.

이들 모두를 차단하고 싶을 수 있습니다. 또는 검색 발견 가능성은 유지하면서 모델 학습만 거부하고 싶을 수도 있습니다. 이 둘은 같은 정책이 아닙니다.

예를 들어 OpenAI는 GPTBot, ChatGPT-User, OAI-SearchBot 등 목적별로 분리된 user agent를 문서화하고 있습니다. Google은 일부 Gemini 및 Vertex AI 사용 사례에 대해 제어 토큰으로 Google-Extended를 사용하며, 일반 Google Search 크롤링은 다른 Googlebot user agent가 처리합니다.

이러한 분리는 중요합니다. 넓은 범위의 user agent를 부주의하게 차단하면 AI 학습을 막으려다가 일반 검색 노출에 해를 줄 수 있습니다.

합리적인 AI 차단 robots.txt 템플릿

다음은 일반 검색 크롤러는 그대로 두면서, 문서화된 몇몇 일반적인 AI 관련 크롤러를 차단하기 위한 보수적인 시작점입니다.

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

이것은 마법 같은 보편 목록이 아닙니다. 유지 관리 가능한 패턴입니다.

몇 가지 참고할 점은 다음과 같습니다.

• Disallow: /는 “어떤 경로도 크롤링하지 말라”는 뜻입니다.
• User-agent: *는 더 구체적인 그룹과 일치하지 않는 크롤러에 적용됩니다.
• 기본 그룹에 Allow: /가 꼭 필요한 것은 아니지만, 의도를 명확히 보여 줍니다.
• 주석은 짧게 유지하십시오. 일부 파서는 관대하지만, robots.txt는 단순하게 유지하는 편이 좋습니다.
• robots.txt에 비공개 URL을 넣지 마십시오. 이 파일은 공개되어 있으며, 민감한 경로를 나열하면 오히려 그 존재를 알릴 수 있습니다.

마지막 요점은 다시 강조할 가치가 있습니다. Robots.txt는 비밀 유지 장치가 아닙니다. /client-contracts/가 공개되어서는 안 된다면 인증으로 보호하십시오. 단순히 disallow만 하지 마십시오.

Google-Extended를 주의해서 다루기

Google-Extended는 널리 오해되고 있습니다. 이것은 Google Search를 차단하는 것과 같지 않습니다.

Google 문서에 따르면 Google-Extended는 게시자가 사이트 콘텐츠가 특정 Gemini 및 Vertex AI 기능 개선에 사용될 수 있는지 관리하기 위한 독립적인 제품 토큰입니다. 이것을 차단한다고 해서 그 자체로 Googlebot의 Search용 크롤링이 차단되지는 않아야 합니다.

그렇다고 해서 모든 Google 지시문을 정말 의도하지 않은 한 다음과 같은 넓은 차단으로 바꾸어서는 안 됩니다.

User-agent: Googlebot
Disallow: /

이는 Google Search의 주요 크롤러에게 사이트를 크롤링하지 말라고 알리는 것입니다. 대부분의 공개 웹사이트에서 이는 원하는 결과가 아닙니다.

같은 구분은 다른 곳에도 적용됩니다. 일부 벤더는 학습 크롤러를 사용자 트리거 브라우징이나 AI 검색 크롤러와 분리합니다. 그렇지 않은 곳도 있습니다. 관심 있는 봇의 문서를 읽고, robots.txt를 일회성 체크박스가 아니라 살아 있는 파일로 다루어야 합니다.

프로덕션 코드처럼 파일 테스트하기

Robots.txt는 단순해 보입니다. 그래서 오히려 쉽게 망가집니다.

흔한 실수는 다음과 같습니다.

• /robots.txt가 아니라 /assets/robots.txt 같은 잘못된 위치에 업로드하기.
• 문서 편집기에서 복사한 스마트 따옴표를 사용하기.
• 실수로 User-agent: *와 Disallow: /를 사용해 모든 크롤러를 차단하기.
• 한 도메인의 파일이 다른 서브도메인에도 적용된다고 가정하기.
• 설정에 따라 http://, https://, www, non-www 호스트가 다르게 처리될 수 있음을 잊기.

여러 도메인을 운영하는 사이트라면 모든 canonical host를 확인하십시오. https://www.example.com/robots.txt에 있는 robots 파일이 https://app.example.com/robots.txt를 자동으로 지배하지는 않습니다.

디버깅할 때는 CMS 미리보기에 보이는 내용만 보지 말고 실제 HTTP 응답을 확인하십시오. 원하는 것은 200 OK 응답, 가능하다면 text/plain 콘텐츠 유형, 그리고 예상한 정확한 파일입니다. 리디렉션, 캐싱 또는 CDN 규칙이 관련되어 있다면 원시 헤더 확인이 도움이 됩니다. debugging redirects and HTTP headers in production의 워크플로가 여기에도 직접 적용됩니다.

규칙을 무시하는 봇에는 서버 측 제어 추가하기

크롤러가 규칙을 준수한다면 robots.txt가 가장 깔끔한 신호입니다. 크롤러가 악용적이라면 집행이 필요합니다.

실무적인 제어 방법은 다음과 같습니다.

속도 제한

비정상적인 요청 패턴에 임계값을 설정하십시오. 분당 너무 많은 페이지 요청, 깊은 페이지네이션 순회, 반복적인 404, 또는 소수 IP에서 발생하는 높은 요청량 등이 해당됩니다. 속도 제한은 실제 사용자를 불이익 주지 않을 만큼 관대하면서도, 대량 추출을 비싸게 만들 만큼 엄격해야 합니다.

User-agent 필터링

문서화된 AI 크롤러 user agent를 웹 서버, 리버스 프록시, CDN 또는 애플리케이션 계층에서 차단할 수 있습니다. 이는 실제 거부 응답을 반환하기 때문에 robots.txt보다 강합니다.

예를 들어 Nginx는 user agent 패턴을 차단할 수 있지만, 프로덕션 규칙은 신중하게 테스트해야 합니다.

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

이 방법이 완벽한 것은 아닙니다. User-agent 문자열은 쉽게 위조할 수 있습니다. 하지만 정직하거나 게으른 트래픽은 막고 부하를 줄일 수 있습니다.

IP 및 ASN 제어

일부 운영자는 IP 범위를 공개하지만, 많은 스크래퍼 생태계는 그렇지 않습니다. IP 기반 차단은 명백한 악용, 특히 정상 사용자 트래픽이 없는 클라우드 호스팅 범위에서 효과가 있을 수 있지만, 오탐도 만들 수 있습니다. 규칙보다 로그를 먼저 사용하십시오.

인증과 paywalls

콘텐츠가 대규모로 복사되어서는 안 된다면 전체 콘텐츠를 공개 URL에 두지 마십시오. Robots.txt는 기밀 자료, 라이선스 데이터베이스, 비공개 커뮤니티 또는 유료 아카이브에는 적합하지 않습니다.

콘텐츠 최소화

때로는 가장 좋은 보호가 아키텍처입니다. 공개 페이지에 작은 일부만 필요하다면 불필요한 API, 큰 JSON payload, 숨겨진 메타데이터, 초안 엔드포인트 또는 전체 아카이브를 노출하지 마십시오. 이미지 중심 사이트도 어떤 메타데이터를 공개하는지 생각해야 합니다. stripping EXIF metadata before sharing photos online의 개인정보 보호 논리는 콘텐츠 운영에도 적용됩니다.

페이지 수준 규칙에는 robots meta tags 사용하기

Robots.txt는 크롤링을 제어합니다. Robots meta tags와 X-Robots-Tag 헤더는 규칙을 준수하는 검색 엔진과 크롤러에 대해 색인 및 스니펫 동작을 제어합니다.

예를 들면 다음과 같습니다.

<meta name="robots" content="noindex, noarchive">

또는 HTTP 헤더로는 다음과 같습니다.

X-Robots-Tag: noindex, noarchive

이들은 AI 전용 방패가 아닙니다. 페이지에는 접근 가능하지만 색인되지는 않게 하고 싶을 때 유용합니다. 하지만 robots.txt에서 크롤러가 페이지를 가져오지 못하도록 차단했다면, 그 크롤러는 페이지 수준 meta tag를 보지 못할 수 있습니다. 크롤러가 크롤링을 금지당한 URL에 있는 noindex tag에 의존하지 마십시오.

대략적인 원칙은 다음과 같습니다.

• 크롤링을 줄이거나 막으려면 robots.txt를 사용하십시오.
• 색인 동작을 제어하려면 meta robots 또는 X-Robots-Tag를 사용하십시오.
• 접근을 집행하려면 서버 측 제어를 사용하십시오.

게시 후 로그 모니터링하기

파일을 게시하는 것은 첫 단계일 뿐입니다. 그다음에는 로그를 확인해야 합니다.

다음을 살펴보십시오.

• 지정한 user agent가 /robots.txt를 요청하는지.
• disallow 규칙이 제공된 뒤에도 크롤링이 계속되는지.
• 높은 트래픽을 보이는 의심스러운 user agent.
• 수천 개 페이지를 순차적으로 요청하는 브라우저처럼 보이는 user agent.
• 피드, 사이트맵, 검색 페이지, 페이지네이션에 대한 반복 접근.

봇이 robots.txt를 요청하고, 전체 disallow를 확인한 뒤 멈춘다면 robots.txt가 제 역할을 한 것입니다. 계속한다면 해당 봇을 집행 대상으로 옮기십시오. 속도 제한, 차단 또는 인증이 필요합니다.

사이트맵 노출도 검토하십시오. 사이트맵은 검색 엔진에 유용하지만, 스크래퍼에게도 편리한 지도입니다. 그렇다고 일반 사이트에서 사이트맵을 제거해야 한다는 뜻은 아닙니다. 다만 공개 시스템이 발견하기를 원하지 않는 URL을 포함해서는 안 된다는 뜻입니다.

파일을 작게 유지하고 검토하기

Robots.txt는 쉽게 낡습니다. 마케팅 팀이 캠페인 마이크로사이트를 추가합니다. 개발자가 스테이징 경로를 추가합니다. 벤더가 크롤러 이름을 바꿉니다. 2년 뒤에는 왜 규칙의 절반이 존재하는지 아무도 모릅니다.

이를 구성 설정처럼 다루십시오.

• 가능하면 버전 관리에 저장하십시오.
• 각 AI 크롤러 그룹에 짧은 주석을 추가하십시오.
• 분기마다 검토하십시오.
• 넓은 규칙을 추가하기 전에 벤더 문서를 확인하십시오.
• CDN, CMS 또는 호스팅 변경 후 테스트하십시오.

사이트가 AI 보조 콘텐츠를 게시한다면 크롤러 정책과 편집 투명성을 분리하십시오. AI 스크래퍼 차단은 접근과 재사용의 문제입니다. 공개 표기는 독자 신뢰의 문제입니다. 윤리적으로는 겹치지만 같은 제어는 아닙니다. 실무적인 공개 방식은 what honest AI disclosure looks like on a small website에서 다룹니다.

<!-- tool-cta:start -->

💡 이것을 시도해 보세요: AI 크롤러용 규칙을 추가한 후, 합법적인 봇까지 실수로 차단하지 않도록 Robots.txt Tester로 구문을 확인하세요.

<!-- tool-cta:end -->

핵심 정리

좋은 robots.txt 파일은 규칙을 준수하는 AI 크롤러를 차단합니다. 그러나 단호한 스크래핑, 복사된 user-agent 문자열, 손상된 브라우저, 또는 사람이 직접 콘텐츠를 AI 시스템에 붙여 넣는 행위는 막지 못합니다.

그렇다고 쓸모없다는 뜻은 아닙니다. 하나의 계층이라는 뜻입니다.

문서화된 AI 크롤러에 대해 명시적인 규칙을 작성하십시오. 검색 노출에 피해를 주는 넓은 차단은 피하십시오. 초안이 아니라 실제로 제공되는 파일을 테스트하십시오. 로그를 살펴보십시오. 원치 않는 수준을 넘어 악용으로 이어지는 행위에는 서버 측 제어로 집행하십시오.

웹은 늘 프로토콜, 규범, 집행의 조합 위에서 작동해 왔습니다. Robots.txt는 규범의 계층입니다. 사용하되, 벽으로 착각하지는 마십시오.