2026년 웹사이트의 트래픽 구성은 몇 년 전과 다르다. 사람, 검색 크롤러, 학습 데이터 수집기, 그리고 사용자 요청을 대신 수행하는 에이전트가 뒤섞여 있다. 이들을 같은 규칙으로 다루면 두 가지 문제가 생긴다. 서버 비용이 새고, 콘텐츠가 대가 없이 쓰인다.
먼저 명확히 해 둘 것이 있다. robots.txt는 요청이지 강제가 아니다. 준수는 자발적이며 법적 구속력도 없다. 실제로 막으려면 서버나 엣지에서 차단해야 한다.
나는 한동안 robots.txt만 걸어 두고 안심했다. 로그를 제대로 본 건 대역폭 청구서가 이상해진 뒤였다. 하루 요청의 상당수가 자동화 트래픽이었고, 그중 일부는 robots.txt를 아예 읽지 않았다. 그때부터 "요청하는 것"과 "강제하는 것"을 구분하기 시작했다.
봇의 종류와 대응 방향
| 유형 | 목적 | 대응 기본값 |
|---|---|---|
| 검색 크롤러 | 색인 — 트래픽을 되돌려 준다 | 허용 (막으면 유입 손실) |
| AI 학습 수집기 | 모델 학습 데이터 확보 | 정책에 따라 선택 |
| AI 답변용 조회 | 사용자 질문에 답하기 위한 실시간 조회 | 출처 표기 여부로 판단 |
| 에이전트 실행 | 사용자 대신 사이트를 조작·조회 | 인증 경로로 유도 |
| 스크래퍼·복제 | 콘텐츠 무단 복제 | 차단 |
| 취약점 스캐너 | 공격 준비 | 차단·차단 목록 등록 |
1단계 — robots.txt로 의사 표시
구속력이 없어도 robots.txt는 필요하다. 준수하는 봇이 실제로 많고, 정책을 공개적으로 선언하는 의미도 있다.
# /robots.txt
# 검색 크롤러는 허용 (트래픽이 돌아온다)
User-agent: Googlebot
Allow: /
User-agent: Bingbot
Allow: /
# 학습 목적 수집기는 차단 (이름은 각 사업자 문서에서 확인)
User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /
# 그 외 기본 정책
User-agent: *
Disallow: /admin/
Disallow: /api/
Crawl-delay: 5
Sitemap: https://example.com/sitemap.xml봇 이름은 사업자마다 다르고 바뀐다. 주기적으로 각 사업자의 공개 문서를 확인해 갱신해야 한다. 이름을 모르는 새 봇은 어차피 이 파일로 막히지 않는다.
2단계 — 실제 차단은 엣지에서
차단 규칙은 애플리케이션이 아니라 앞단(CDN·리버스 프록시)에 두는 게 좋다. 애플리케이션까지 요청이 도달하면 이미 비용이 발생한 뒤다.
# nginx 예시: User-Agent 기반 기본 차단 + 레이트 리밋
# 1) 요청 속도 제한 (IP 단위)
limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/m;
map $http_user_agent $blocked_ua {
default 0;
"~*(SomeScraperBot)" 1;
"~*(python-requests)" 1; # 기본 UA 그대로 오는 스크립트
"" 1; # UA 없는 요청
}
server {
if ($blocked_ua) { return 403; }
location / {
limit_req zone=perip burst=20 nodelay;
limit_req_status 429;
...
}
# 무거운 경로는 더 엄격하게
location /search {
limit_req zone=perip burst=5 nodelay;
...
}
}Retry-After를 붙인다 (예의 있는 봇은 물러난다)3단계 — 행동 기반 판별
User-Agent를 신뢰할 수 없으므로, 실제 행동에서 신호를 얻어야 한다. 완벽하지는 않지만 유용한 지표들이 있다.
- 요청 간격의 규칙성 — 사람은 불규칙하고 봇은 일정하다.
- 정적 자산 요청 여부 — 사람의 브라우저는 CSS·이미지·폰트를 함께 요청한다. HTML만 연속으로 가져가면 봇일 가능성이 높다.
- 순회 패턴 — 사이트맵 순서대로 또는 링크를 폭넓게 훑으면 크롤러다.
- 세션 유지 — 쿠키를 보존하지 않고 매번 새로 요청하는 패턴.
- Accept 헤더 — 브라우저가 보내는 일반적인 조합과 다른 경우.
4단계 — 열어 두되 조건을 붙이기
전면 차단이 늘 최선은 아니다. AI 답변에서 출처로 인용되며 유입이 생기는 경우도 있다. 그래서 요즘 자주 쓰는 절충은 이렇다.
SEO를 해치지 않으려면
봇 차단에서 가장 흔한 사고는 검색 크롤러를 함께 막는 것이다. 트래픽이 며칠 뒤부터 조용히 줄고, 원인을 찾는 데 몇 주가 걸린다.
# 검색 크롤러 검증 (구글봇 예)
# 1) 역방향 DNS
host 66.249.66.1
# → crawl-66-249-66-1.googlebot.com
# 2) 정방향 확인 (역방향 결과를 다시 조회해 IP가 일치하는지)
host crawl-66-249-66-1.googlebot.com
# → 66.249.66.1
# 두 방향이 일치해야 진짜다. UA 문자열만으로 판단하지 말 것.현실적인 결론
완전한 차단은 불가능하다. 결정한 만큼만 막을 수 있고, 막는 만큼 다른 비용을 치른다. 그래서 목표를 먼저 정해야 한다. 비용 통제가 목적인가, 콘텐츠 보호가 목적인가. 전자라면 속도 제한과 캐싱으로 충분한 경우가 많고, 후자라면 공개 범위 자체를 다시 설계해야 한다.
나는 대부분의 사이트에 이 순서를 권한다. 먼저 로그를 보고, 비싼 경로에 속도 제한을 걸고, robots.txt로 정책을 밝히고, 그래도 문제가 남으면 그때 차단을 검토한다. 첫 단계에서 끝나는 경우가 생각보다 많다.
자주 묻는 질문
robots.txt로 AI 크롤러를 막을 수 있나요?
준수하는 봇에게는 효과가 있지만 강제력은 없습니다. 무시하거나 이름을 바꿔 오는 경우가 있어, 실제 차단이 필요하면 서버나 엣지에서 규칙을 적용해야 합니다. 그래도 정책 선언 의미가 있으므로 함께 유지하는 것이 좋습니다.
검색 노출을 잃지 않으면서 학습 수집만 막을 수 있나요?
봇 이름 단위로 구분하면 어느 정도 가능합니다. 검색 크롤러는 허용하고 학습 목적 수집기는 차단하는 방식이며, 봇 이름은 각 사업자 문서에서 주기적으로 확인해 갱신해야 합니다. 다만 이름을 밝히지 않는 수집은 이 방법으로 걸러지지 않습니다.
User-Agent만으로 봇을 판별해도 되나요?
User-Agent는 자기 신고라 위장이 쉽습니다. 검색 크롤러 검증에는 역방향 DNS와 정방향 재확인을 함께 쓰고, 나머지는 요청 간격·정적 자산 동반 요청 여부·순회 패턴 같은 행동 신호로 판단하세요.
차단과 속도 제한 중 무엇을 먼저 적용해야 하나요?
속도 제한이 먼저입니다. 오탐이 발생해도 피해가 작고, 429와 Retry-After를 제대로 반환하면 예의 있는 자동화는 스스로 물러납니다. 차단은 반복적으로 규칙을 무시하는 대상에 한정하는 편이 안전합니다.
정상 사용자가 차단되는 문제는 어떻게 줄이나요?
속도 제한 → 지연 → 챌린지 → 차단으로 단계를 두고, 접근성 도구나 저사양 환경을 고려해 임계값을 여유 있게 잡으세요. 차단 페이지에 오탐 신고 경로를 남기고, 공유 IP 환경(회사 NAT, 모바일 캐리어)에서의 영향도 확인해야 합니다.
비용 절감이 목적이라면 무엇부터 해야 하나요?
캐싱과 속도 제한이 먼저입니다. 정적 자산과 자주 조회되는 동적 응답을 엣지에서 캐싱하면 원본 부하가 크게 줄고, 비싼 경로에만 엄격한 제한을 걸면 대부분의 비용 문제가 해결됩니다.
댓글 0