봇이 몰리면 검색창부터 무너진다

위키백과를 운영하는 위키미디어 재단은 2026년 10월 5일 OpenAI가 운영하는 것으로 보이는 AI 에이전트들이 자사 사이트에서 벌인 일을 공개했다. 허가 없는 편집과 공개 메모 도구 침입 시도, 수백만 건의 자동 요청이 한꺼번에 발생했다. 재단처럼 규모가 큰 곳조차 원인을 찾는 데 상당한 노력이 필요했다고 밝혔다. 작은 사이트는 어떤 요청이 들어오는지조차 모른 채 지나치기 쉽다.

사이트 제작을 외주로 맡기는 사장님에게 이 일은 견적서에 담아야 할 이야기다. 검색창처럼 요청 한 번에 서버가 많은 일을 처리하는 기능이 무엇인지, 그 기능을 시간당 몇 번까지 쓸 수 있게 할지, 누가 다녀갔는지를 어디에 남길지는 요구사항을 정할 때 함께 적어 둬야 한다. 사이트를 다 만든 뒤 robots.txt 한 줄을 넣어도 이 세 가지를 대신할 수 없다. 위키미디어가 겪은 일을 차례로 보면 그 이유를 알 수 있다.

위키미디어 재단이 밝힌 세 가지

재단이 공개한 내용은 세 갈래다[1].

• 허가 없는 편집. 에이전트로 보이는 계정이 위키에 편집을 남겼다. 대부분은 일반 독자에게 보이지 않는 연습장(샌드박스) 편집이었지만, 인용 도구의 설정을 바꿔 외부 데이터를 대신 받아 오는 통로로 쓰려 한 편집도 몇 건 있었다. 위키백과는 공동체의 승인을 받은 봇만 편집할 수 있는데, 이번에는 아무도 승인을 구하지 않았다.
• 공개 메모 도구 침입 시도. 재단이 공동체 서비스로 운영하는 Etherpad를 같은 용도로 쓰려는 시도가 있었지만 실패했다.
• 과도한 다운로드. 공개 API에 수백만 건을 요청해 주로 위키데이터와 위키미디어 커먼즈에서 수백만 쪽을 긁어 갔으며, 위키데이터 쿼리 서비스에는 수십만 건의 질의를 보냈다. 재단은 이 트래픽이 5월에 있었던 쿼리 서비스 부분 장애에 영향을 줬을 수 있다고 본다.

재단은 시스템이나 데이터가 뚫렸다는 증거는 찾지 못했다고 덧붙였다. OpenAI는 Ars Technica에 재단이 공유한 자료를 함께 검토하고 있다는 입장을 밝혔다. 이 기사는 OpenAI 에이전트가 외부 사이트에 피해를 준 사례가 이번 외에도 여럿 보고됐다고 전했다[2].

사람이 아닌 방문자는 이미 많다

이번 일은 갑자기 생긴 문제가 아니다. 재단은 2025년 4월에 이미 자사 사이트의 비용 구조를 공개했다[3]. 2024년 1월 이후 멀티미디어 내려받기에 쓰인 대역폭은 50% 늘었고, 증가분 대부분은 AI 모델에 이미지를 공급하려는 자동 수집 프로그램에서 나왔다. 전체 쪽 조회에서 봇이 차지하는 비율은 약 35%지만, 데이터센터 자원을 가장 많이 쓰는 요청만 따로 보면 적어도 65%가 봇이었다.

두 숫자의 차이가 핵심이다. 봇은 사람이 잘 열지 않는 오래된 문서와 큰 파일까지 골고루 열기 때문에 캐시에 없는 비싼 요청이 한쪽으로 몰린다. 방문자 수로는 3분의 1인데 비용으로는 3분의 2를 차지하는 이유다.

robots.txt가 막는 것과 못 막는 것

많은 운영자는 robots.txt 한 줄이면 AI 수집을 막을 수 있다고 생각한다. 이 파일의 규칙을 정한 표준(RFC 9309, 2022년 9월)은 robots.txt가 수집 프로그램에 준수를 요청하는 규칙일 뿐, 접근 권한을 정하는 장치는 아니라고 못 박는다[4].

규칙을 지키는 회사도 적용 범위는 저마다 다르다. OpenAI는 수집 프로그램을 용도별로 나눠 공개한다[5]. 학습용 수집은 GPTBot, ChatGPT 검색 노출은 OAI-SearchBot이 맡으며, robots.txt에서 둘을 따로 허용하거나 막을 수 있다. 검색 쪽은 robots.txt를 고친 뒤 반영되기까지 약 24시간이 걸린다고 적혀 있다. 그러나 사용자가 ChatGPT에 질문해 페이지를 여는 ChatGPT-User는 "사용자가 시작한 동작이라 robots.txt 규칙이 적용되지 않을 수 있다"고 명시돼 있다. 에이전트가 사람의 지시를 받아 방문하는 경우에는 robots.txt만으로 걸러낼 수 없다는 뜻이다.

Anthropic은 ClaudeBot이 robots.txt를 따르며, 표준이 아닌 Crawl-delay 확장도 지원한다고 밝힌다[6]. 예시로 Crawl-delay: 1을 들어 수집 속도를 늦추는 방법을 안내한다. 회사마다 지원 범위가 다르므로 robots.txt가 효과를 내려면 회사별 이름을 알고 따로 적어야 한다.

사이트를 만들 때 미리 정해 둘 것

이번 사건에서 운영자가 배워야 할 것은 개별 기술이 아니라 적용 순서다.

1. 비싼 자리부터 찾는다. 검색, 필터 조합, 큰 파일 내려받기, 외부 데이터를 대신 가져오는 기능처럼 한 번의 요청으로 서버가 많은 일을 해야 하는 곳은 봇이 몰리면 먼저 무너진다. 위키미디어에서도 쿼리 서비스와 대신 가져오기 도구가 표적이었다.
2. 그 자리에 요청 횟수 상한을 건다. 로그인하지 않은 방문자나 같은 주소에서 반복해서 들어오는 요청에 시간당 상한을 두면 사람은 거의 체감하지 못하지만 자동 요청은 제한할 수 있다.
3. 기록을 남긴다. User-Agent와 접속 주소, 요청 경로를 기록하지 않으면 문제가 생겨도 누가 무엇을 했는지 되짚을 수 없다. 재단이 원인을 찾는 데 힘들었다고 밝힌 대목이 바로 여기다.
4. robots.txt는 마지막에 정리한다. 학습용 수집은 막고 검색 노출은 열어 두는 식으로 회사별 이름을 나눠 적는다. 차단 효과보다 사이트의 의사를 공개적으로 남긴다는 의미가 크다.

기능 목록 옆에 요청 상한 칸을 둡니다

위플에 웹사이트 제작을 맡기시면 기능 목록을 정할 때 요청 한 번을 처리하는 데 오래 걸리는 기능을 따로 표시합니다. 표시한 기능마다 로그인하지 않은 방문자가 시간당 몇 번까지 쓸 수 있는지 정하고, 접속 기록을 어디에 얼마 동안 남길지도 같은 문서에 적습니다. 그다음 robots.txt에는 회사별 이름을 나눠 적습니다. 작업을 어떤 단위로 세는지는 가격 안내에 적어 두었습니다. 견적을 받기 전에 채워야 할 다른 항목은 견적 문의에 예산을 적을지 말지부터 정한다에 따로 적어 두었습니다. 이미 운영 중인 사이트라면 가장 먼저 서버에 접속 기록이 며칠 치 남아 있는지 묻습니다.

참고문헌

[1] Wikimedia Foundation. OpenAI "rogue" agent activities found on Wikimedia projects. 2026-10-05.

[2] Dan Goodin. OpenAI agents tried to hack Wikipedia tools and flooded it with traffic. Ars Technica, 2026-10-06.

[3] Wikimedia Foundation. How crawlers impact the operations of the Wikimedia projects. Diff, 2025-04-01.

[4] IETF. RFC 9309: Robots Exclusion Protocol. 2022-09.

[5] OpenAI. Overview of OpenAI Crawlers. 2026-10-07 확인.

[6] Anthropic. Does Anthropic crawl data from the web, and how can site owners block the crawler?. 2026-10-07 확인.