AI 크롤러 요청이 몰려 서버가 느려질 때 무엇으로 줄이나요?

어느 봇이 몇 번 왔는지 줄 단위로 먼저 셉니다

수단을 고르기 전에 서버 접근 로그(Access Log)에서 사용자 에이전트(User Agent)별 요청 수를 시간 단위로 셉니다. 전체 요청량만 보면 사람이 만든 트래픽과 수집기가 만든 트래픽을 구분할 수 없고, 어느 수단이 통하는 봇인지도 정할 수 없습니다.

한 줄에 최소 네 가지가 남아 있어야 합니다. 사용자 에이전트 문자열, 요청 경로, 응답 상태 코드, 요청 시각입니다. 경로가 기록되지 않는 설정이면 어느 기능이 요청을 만드는지 끝까지 알 수 없으므로 경로 기록을 먼저 켭니다.

사용자 에이전트 문자열은 누구나 위장할 수 있습니다. 실제 그 회사의 요청인지 판정하는 절차는 따로 밟아야 하며, 판정 전의 수치를 특정 회사 책임으로 적지 않습니다.

조절 수단은 봇마다 다르고 표준이 아닙니다

RFC 9309이 정한 robots.txt 문법에는 user-agent, allow, disallow 세 가지만 있습니다. 요청 간격을 지정하는 Crawl-delay는 표준에 없는 확장이라 회사별 문서를 확인해야 합니다.

Google 문서는 지원 필드를 user-agent, allow, disallow, sitemap 으로 적고 crawl-delay 같은 다른 필드는 지원하지 않는다고 밝힙니다(2026-08-31 갱신). Anthropic 지원 문서는 비표준 Crawl-delay 확장을 지원한다며 User-agent: ClaudeBot 아래 Crawl-delay: 1 예시를 제시합니다. OpenAI 크롤러 문서에는 요청 간격이나 요청량 조절에 관한 문장이 없습니다.

문서에 없는 수단은 동작한다고 가정하지 않습니다. 같은 줄을 적어도 한쪽은 따르고 다른 쪽은 무시하므로, 줄을 넣은 사실과 요청량이 줄어든 사실을 따로 확인합니다.

요청 급증의 원인이 사이트 구조인 경우

Google 문서는 요청이 갑자기 늘어나는 흔한 원인으로 사이트의 URL 구성 문제를 먼저 듭니다. 정렬·필터를 조합할 때마다 주소가 생기는 패싯 내비게이션(Faceted Navigation), 날짜마다 주소가 생기는 캘린더, 동적 검색 광고 대상이 예로 적혀 있습니다.

이 경우 전체 요청량을 눌러도 원인은 남습니다. 로그에서 요청이 많은 상위 경로 스무 개를 뽑아 쿼리 문자열이 붙은 주소의 비율을 봅니다. 파라미터 조합이 대부분이면 그 경로만 Disallow 하는 편이 중요한 페이지 수집을 유지합니다.

급할 때 쓰는 오류 응답의 조건과 부작용

Google 문서는 몇 시간에서 1~2일처럼 짧은 기간에 한해 200 대신 500·503·429를 돌려주는 방법을 안내합니다. 이 상태 코드가 상당수 관측되면 수집 속도가 내려가고, 오류가 줄면 자동으로 다시 올라갑니다.

같은 문서가 부작용도 함께 적습니다. 효과는 요청을 받은 호스트 전체(예: subdomain.example.com)에 적용되고, 새 페이지 발견과 기존 페이지 갱신이 늦어지며, 같은 주소에서 며칠 동안 이 코드가 관측되면 해당 주소가 색인에서 빠질 수 있습니다. 그래서 1~2일을 넘기지 말라고 권고합니다.

robots.txt 파일 자체는 이 조치에서 제외합니다. RFC 9309은 robots.txt가 500~599로 응답하면 크롤러가 전체 차단으로 간주해야 한다고 정하므로, 부하 차단을 전체 경로에 걸면 의도보다 넓게 막힙니다.

# 부하 차단을 켠 뒤 robots.txt 만 200 인지 확인합니다 (주소는 예시 값)
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/robots.txt

바꾼 뒤 무엇을 보고 줄었다고 판단하나요

세 가지를 순서대로 확인합니다. 첫째, 조치 전후 같은 요일·같은 시간대의 사용자 에이전트별 시간당 요청 수를 로그에서 비교합니다. 둘째, robots.txt가 200으로 응답하고 의도한 줄이 그대로 보이는지 확인합니다. 셋째, 오류 응답을 켰다면 시작·종료 시각을 기록하고 1~2일 안에 끕니다.

바꾼 직후의 로그로 판단하지 않습니다. RFC 9309은 크롤러가 robots.txt 캐시를 24시간 넘게 쓰지 않도록 권고하고, OpenAI 문서도 검색 쪽 반영에 약 24시간이 걸릴 수 있다고 적습니다.

접근 로그로 확인할 수 없는 것이 하나 남습니다. 요청량을 줄인 뒤에도 검색 결과와 AI 답변에 우리 페이지가 계속 쓰이는지는 로그에 나오지 않습니다. 접근 허용, 실제 방문, 색인과 인용은 서로 다른 단계이므로 노출 쪽은 별도 자료로 봐야 합니다.