Chiko IT
AI 코딩 도구

Publisher AI Search 거부권 규제, SEO 전략을 다시 짜야 하나

Chiko
14min read

목차

이 글에서 다루는 도구는 세 가지다. AI Search 크롤러를 거르는 robots.txt 확장, 학습·요약 용도 명시 opt-out을 위한 llms.txt, 그리고 마지막 안전망인 Nginx/Cloudflare WAF 룰. Publisher가 AI Search 거부권을 행사할 때 실제로 손에 쥐는 게 이 세 개다. 신입한테 "이거 어떻게 해요?" 질문이 들어왔을 때 따라 할 수 있게 단계별로 정리한다.

물론, 전제는 단순하다. 사이트는 검색 엔진(Google, Bing, Naver) 노출은 유지하고, AI Overviews·AI Answer·LLM 학습용 크롤링만 선택적으로 막고 싶다. 둘은 봇이 다르고 헤더가 다르고 동작 방식도 다르기 때문에 분리해서 다룰 수 있다.

AI Search 거부권 규제, 뭐가 바뀌었나

예를 들어, EU AI Act의 텍스트·데이터 마이닝(TDM) opt-out 조항이 2024년부터 발효되면서, Publisher가 "내 콘텐츠를 학습에 쓰지 마라"라고 명시할 권리가 법으로 보장됐다. 미국은 입법보다는 NYT-OpenAI 소송 같은 판례와 개별 라이센스 계약 흐름이 강한 편이고, 한국도 문체부·과기정통부가 저작권법 개정 논의를 끌고 가는 중이다(작성 시점 2026년 6월 기준).

실제로, 규제 자체가 신경 쓰이는 건 두 가지다. 첫째, opt-out 의사 표시를 기술적으로 식별 가능한 형태로 남겨야 한다. "사이트 어딘가에 적어뒀다"는 효력이 없다. 둘째, AI 사업자가 opt-out을 무시하고 학습했을 경우의 입증 책임 분배가 점차 Publisher에게 유리해지는 추세다. 다만 이건 어디까지나 분쟁 상황의 이야기고, 실무에서는 일단 "내가 막았다는 사실이 로그로 남는다" 정도가 최소 요건이다.

Publisher 입장에서 손해와 이득

그런데, AI Overviews에 콘텐츠가 인용되면 클릭률(CTR)이 떨어진다는 보고가 누적되고 있다. Similarweb, Sistrix 같은 분석 도구들이 발표한 데이터를 보면 정보성 쿼리에서 상위 페이지 CTR이 눈에 띄게 빠지는 패턴이 관찰된다(출처: Sistrix 블로그, 2025년 리포트 다수). 반대로 차단을 하면 그나마 남아있던 인용 트래픽도 사라진다는 반론도 있다. 결국 사이트 성격에 따라 다르다. 뉴스·매거진처럼 원문 방문이 비즈니스의 본진인 곳은 차단으로 기우는 경향이 있고, 제품 도큐먼트·기술 블로그처럼 인용 노출 자체가 마케팅인 곳은 허용 쪽이 더 흔하다.

차단 대상 — 봇 user-agent부터 정리

먼저 누가 들어오는지를 정확히 알아야 막을 수 있다. 2026년 6월 시점에서 실무적으로 관리할 가치가 있는 AI 관련 user-agent를 표로 정리했다.

User-Agent 운영 주체 목적
GPTBot OpenAI 모델 학습용 크롤링
OAI-SearchBot OpenAI ChatGPT Search 인덱싱
ChatGPT-User OpenAI 사용자 요청 시 실시간 페치
Google-Extended Google Gemini/Bard 학습용
ClaudeBot Anthropic Claude 학습/검색용
PerplexityBot Perplexity Perplexity 검색 인덱싱
Applebot-Extended Apple Apple Intelligence 학습
meta-externalagent Meta Llama 학습
CCBot Common Crawl 공개 크롤 데이터셋
Bytespider ByteDance Doubao 등 모델 학습

그래서, 여기서 헷갈리는 게 OpenAI의 봇이 세 종류라는 점이다. GPTBot은 학습용이라 막아도 ChatGPT의 답변 품질에는 영향이 거의 없다. OAI-SearchBot은 ChatGPT Search 결과에 노출되려면 허용해야 하고, ChatGPT-User는 사용자가 "이 페이지 요약해줘" 같은 명시적 요청을 했을 때 발생한다. 이걸 한 줄로 막으면 ChatGPT Search에서 사이트 자체가 사라진다. Google-Extended도 비슷한 구조다. 막아도 Google 검색 색인에는 영향이 없고 Gemini 학습에서만 빠진다.

1단계 robots.txt 확장

가장 먼저 손대는 곳이다. 효과는 가장 약하지만 합의된 표준이고 "내가 거부 의사를 명시했다"는 증거가 되기 때문에 법적으로도 의미가 있다.

# /robots.txt

# 학습용 크롤러만 차단, 검색 노출은 유지
User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: meta-externalagent
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

# AI 검색 인덱싱은 허용
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# 기존 검색 엔진은 그대로
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

여기서 자주 놓치는 함정 두 개. Disallow: /는 해당 봇에만 적용되고 User-agent: * 블록은 별개로 동작한다. 그래서 "전체를 막고 일부만 허용"하는 식으로 짜면 의도와 다르게 동작하는 경우가 많다. 실제로는 봇별로 명시적으로 적는 게 안전하다. 그리고 robots.txt는 권고다. 무시하는 봇은 무시한다. 그래서 다음 단계가 필요하다.

적용 후 확인 방법

서버 배포 후 다음을 확인한다.

# 1. 파일이 정상적으로 서빙되는지
curl -I https://example.com/robots.txt

# 2. 응답 본문이 의도대로인지
curl https://example.com/robots.txt | head -50

# 3. Google Search Console > robots.txt 테스터로 검색 봇 영향 없는지 확인

특히 세 번째가 중요하다. 정규 검색 봇에 영향이 없는지 반드시 더블 체크해야 한다.

2단계 llms.txt로 명시적 opt-out 선언

llms.txt는 robots.txt보다 늦게 등장한 제안 표준이다. AI 사업자가 "학습 가능한 콘텐츠"를 인식할 수 있도록 사이트 루트에 마크다운 형태로 두는 파일이다. 강제력은 robots.txt와 비슷하게 약하지만, 의도의 명시성은 더 높다. 분쟁 시 "Publisher가 학습 거부를 분명히 표시했다"는 근거로 쓰기 좋은 형식이다.

# Example Publisher

> 본 사이트의 모든 콘텐츠는 자체 저작물이며, AI 모델 학습 및 요약 용도의 자동 수집을 거부한다.

## Policy

- AI 학습 수집: 거부 (TDM opt-out, EU AI Act 53조 1항 c)
- 검색 인덱싱: 허용
- 라이센스 문의: contact@example.com

## Allowed

- 일반 검색 엔진 인덱싱
- 사용자가 명시적으로 요청한 단발성 페치 (예: ChatGPT-User)

## Disallowed

- 학습 데이터셋 구축 목적의 대량 크롤링
- 동의 없는 RAG 인덱싱
- 재배포를 동반한 캐시

실무에서 보면 llms.txt를 읽는 봇은 아직 일부다. 그래도 두는 비용은 거의 없고, 향후 표준 채택이 늘 가능성이 있어서 미리 깔아두는 쪽이 안전하다는 게 개인적인 판단이다.

3단계 Nginx/Cloudflare에서 강제 차단

한편, robots.txt와 llms.txt를 무시하는 봇이 있을 때 실제로 막는 단계다. 잘 되고 있는 시스템을 굳이 안 건드리는 편이지만, 이 단계만큼은 한 번은 깔아두는 게 좋다. 차단 로그가 남아야 분쟁 시 "기술적 조치를 했다"는 증거가 된다.

Nginx로 user-agent 기반 차단

# /etc/nginx/conf.d/ai-bots.conf

map $http_user_agent $is_ai_bot {
    default 0;
    "~*GPTBot"              1;
    "~*Google-Extended"     1;
    "~*ClaudeBot"           1;
    "~*Applebot-Extended"   1;
    "~*meta-externalagent"  1;
    "~*CCBot"               1;
    "~*Bytespider"          1;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    # AI 봇 차단 및 별도 로그
    if ($is_ai_bot) {
        access_log /var/log/nginx/ai-bots-blocked.log;
        return 403;
    }

    # 이후 일반 설정
    location / {
        proxy_pass http://upstream;
    }
}

if를 location 바깥에서 쓰는 게 권장 패턴이고, 안에서 쓸 거면 동작 함정이 많아서 가급적 피하는 편이 낫다. 차단 로그를 별도 파일로 빼는 이유는 분석과 분쟁 대응 양쪽에 쓰기 위해서다.

Cloudflare WAF 룰

그러나, Cloudflare를 쓴다면 대시보드에서 더 간단하다. Security > WAF > Custom rules에서 표현식으로 처리한다.

(http.user_agent contains "GPTBot") or
(http.user_agent contains "Google-Extended") or
(http.user_agent contains "ClaudeBot") or
(http.user_agent contains "Applebot-Extended") or
(http.user_agent contains "meta-externalagent") or
(http.user_agent contains "Bytespider")

Action을 Block으로 설정한다. Cloudflare는 2024년 7월부터 "AI Scrapers and Crawlers" 카테고리 기반의 원클릭 차단 기능을 무료 플랜에도 제공하고 있다(출처: Cloudflare 블로그, 2024-07 발표). 이쪽이 더 간단하면 이걸 켜는 게 낫다.

헷갈리는 케이스 — user-agent 위조

문제는 user-agent를 속이는 봇이다. 일반 브라우저인 척하면서 대량 크롤링을 도는 경우가 종종 있다. 이건 user-agent 매칭으로는 못 잡는다. 보통 이런 식으로 다단계 방어를 한다.

  1. user-agent 화이트리스트(검색 봇)는 IP 역방향 조회로 검증
  2. 그 외 트래픽은 rate limiting (예: IP당 분당 60 req)
  3. 의심 패턴(특정 URL 패턴, 시퀀스)에 challenge

게다가, Cloudflare의 Bot Management(유료)나 자체 fail2ban 규칙으로 처리한다. 이 부분은 사이트 규모와 트래픽 특성에 따라 너무 다르기 때문에 일반화된 가이드를 주기 어렵다.

SEO 손실은 어떻게 측정하나

결국, 차단을 켠 후가 더 중요하다. AI Search 거부권을 행사했을 때 실제로 어떤 트래픽이 빠지는지 측정해야 다음 의사결정이 가능하다.

기본적으로 보는 지표는 셋이다.

지표 도구 어떻게 보나
검색 노출/CTR Google Search Console 차단 전후 2주 비교
AI Referral GA4 + Custom Channel chatgpt.com, perplexity.ai, gemini.google.com 등 referrer 그루핑
봇 차단 로그 Nginx 로그 + 집계 스크립트 일별 차단 건수, user-agent 분포

따라서, GA4에서 AI referral을 잡으려면 Acquisition > Traffic acquisition에서 Source/Medium 필터를 직접 만들어야 한다. 기본 채널 그룹에는 AI 참조 채널이 없기 때문에 Custom Channel Group을 한 번 만들어두는 게 편하다.

실제로, 봇 차단 로그 집계는 간단한 awk 한 줄로도 시작할 수 있다.

# 일별 차단 봇 분포
awk '{print $1, $12}' /var/log/nginx/ai-bots-blocked.log \
  | sort | uniq -c | sort -rn | head -20

체감상 차단 후 1~2주는 referral이 들쭉날쭉하기 때문에, 최소 4주 데이터를 모아 보고 판단하는 편이 안전하다.

주의사항 체크리스트

그래서, 도입 전후로 한 번씩 확인하는 항목들이다. 신입한테 그대로 넘겨도 되도록 단계별로 적었다.

  • [ ] robots.txt에 User-agent: * 블록과 봇별 블록을 혼동하지 않았는가
  • [ ] OAI-SearchBot, PerplexityBot 등 검색 노출용 봇을 같이 막지 않았는가
  • [ ] Google-Extended 차단이 일반 Googlebot에 영향이 없는지 GSC에서 확인했는가
  • [ ] Nginx if 디렉티브는 server 블록 안, location 바깥에 두었는가
  • [ ] 차단 로그가 별도 파일로 분리되어 있는가 (분쟁 대응용)
  • [ ] llms.txt에 라이센스 문의 채널을 명시했는가 (수익화 가능성)
  • [ ] GA4 Custom Channel Group에 AI Referral 그룹을 만들어두었는가
  • [ ] CDN(Cloudflare 등)을 쓰는 경우 origin 직접 접근 경로가 노출되지 않는가
  • [ ] 사내 위키/뉴스레터 등 외부에 노출 안 되는 URL도 같은 정책으로 보호되는가

마지막 항목이 의외로 자주 빠진다. 사내 도큐먼트 사이트가 인증 없이 열려 있는 경우, robots.txt만 깔아도 막힐 거라고 착각하기 쉬운데 실제로는 그냥 통과된다. 인증을 거는 게 정답이다.

정책 운영 — 분기마다 한 번씩

그래서, 봇 user-agent는 의외로 자주 바뀐다. 새로운 사업자가 등장하고, 기존 사업자가 봇을 분리하기도 한다(OpenAI의 OAI-SearchBot이 그런 예다). 분기에 한 번 정도는 darkvisitors.com이나 각 사업자의 공식 문서를 다시 보고 목록을 갱신하는 루틴이 필요하다.

참고할 만한 공식 문서는 두 군데다.

여기에 적힌 user-agent가 정본이라고 보면 된다.

한 번 적용한 뒤 보이는 것들

반면, 차단을 실제로 켜본 사이트들의 공통된 보고가 있다. 첫째, GPTBot 같은 학습용 봇 트래픽은 생각보다 양이 많다(서버 비용 절감 효과가 작지 않게 잡힌다). 둘째, 차단 후 AI Referral은 즉시 빠지지 않고 점진적으로 감소한다. AI 사업자 쪽에 이미 캐시된 인덱스가 남아있기 때문이다. 셋째, 매출 영향은 사이트 성격에 따라 정말 다르다. 인용이 트래픽으로 안 이어지던 사이트는 무손실이고, 반대로 인용이 마지막 referral 줄기였던 곳은 체감되는 손실이 있다.

규제 자체는 시간이 갈수록 Publisher 쪽으로 기울고 있고, 기술적 조치 비용은 점점 낮아지는 중이다(Cloudflare 원클릭 차단처럼). "잘 되면 안 건드린다"가 원칙이지만, opt-out 기본값을 잡아두는 건 이제 안 건드릴 수 없는 영역에 들어왔다는 게 결론이다.

예를 들어, 다음엔 차단 로그를 BigQuery로 적재해서 user-agent별 트래픽 추이와 referrer 변화를 같은 대시보드에서 보는 셋업을 해볼 생각이다.

관련 글

More posts