AI 크롤러와 스팸봇 차단 방법 정리: 클라우드플레어 봇 차단과 DDoS 방어 순서

AI 크롤러 차단은 robots.txt에 적어 두는 부탁을 넘어, 사이트 앞단에서 접속 자체를 끊는 설정입니다. 사이트를 운영해 본 분이라면 사람이 아닌 봇과 AI 트래픽이 최근 크게 늘고 있다는 것을 눈치채셨을 겁니다. 검색 엔진 크롤러가 페이지를 가져가고, 문의 폼에 광고 문구가 들어오고, 로그에 낯선 사용자 에이전트가 찍힙니다.

그런데 그 접속이 얼마나 되는지까지 확인해 본 경우는 많지 않습니다. 무엇을 막아야 하고 무엇을 열어 둬야 하는지도 마찬가지입니다. 클라우드플레어 레이더가 공개한 2026년 8월 20일 기준 수치를 보면, 최근 7일 동안 전 세계 HTTP 요청의 35.3%가 봇에서 나왔습니다.

이런 접속을 그대로 두면 서버 비용이 먼저 오릅니다. 애써 쓴 콘텐츠는 AI 답변으로 들어가는데 방문으로 돌아오는 몫은 거의 없고, 문의 폼은 광고 문구로 채워집니다. 이 글에서는 봇을 보내는 쪽이 무엇을 노리는지 사례로 먼저 확인하고, 늘어난 규모를 수치로 봅니다. 이어서 클라우드플레어의 차단 기능과 대안 솔루션을 비교한 뒤, VPN으로 우회하는 봇에 어떻게 대응하는지까지 정리합니다.

봇을 보내는 쪽이 노리는 것

대응을 정하기 전에 상대의 목적부터 나눠 봐야 합니다. 같은 문으로 들어와도 물건을 사러 온 손님과 진열을 베끼러 온 사람은 대하는 방식이 다르듯, 봇도 목적에 따라 막을 것과 열어 둘 것이 달라집니다. 가져가려는 쪽부터 보면 크게 다섯 가지로 나뉩니다.

1. 모델을 학습시킬 자료 확보. 사람이 쓴 원본 문서에 학습 자료로서 값이 붙다 보니, 계약을 맺고 사는 대신 공개된 웹에서 가져가는 쪽이 늘었습니다. 레딧은 2025년 10월 퍼플렉시티와 데이터 수집 업체 세 곳을 상대로 소송을 냈습니다. 소장에는 이들이 신원을 감추고 기술적 제한을 우회해 대규모로 자료를 모아 갔다는 주장이 담겼다고 합니다. 앞서 같은 해 6월에는 앤트로픽을 상대로도 소송을 냈습니다.

2. 모은 자료의 재판매. 레딧이 소장에서 설명한 구조를 보면, 자료를 모으는 회사와 쓰는 회사가 따로 있습니다. 검색 결과를 훑어 되파는 업체가 중간에 끼어들고, AI 서비스는 그 자료를 사서 씁니다. 어느 회사의 크롤러인지 알 수 없는 접속이 늘어나는 이유가 여기에 있습니다.

3. 가격과 재고 추적, 콘텐츠 복제. AI가 나오기 전부터 있던 목적입니다. 이런 봇은 경쟁사 가격을 실시간으로 받아 가거나, 글과 이미지를 통째로 옮겨 광고를 붙인 복제 사이트를 만듭니다. 검색 크롤러의 사용자 에이전트를 흉내 내는 경우가 있어서 로그만 봐서는 구분이 어렵습니다.

4. 폼에 링크 심기와 주소 수집. 문의 폼에 들어오는 광고 문구의 목적은 대체로 네 가지입니다.

• 검색 순위 올리기: 스팸을 보낸 쪽의 사이트 주소를 본문에 남깁니다. 그 내용이 사이트에 그대로 올라가면 링크를 하나 얻는 셈입니다.
• 피싱 링크 전달: 담당자가 링크를 눌러 주기를 노리고 보냅니다. 문의를 확인하는 사람은 회사 계정을 쓰는 경우가 많아 표적이 됩니다.
• 알림 주소 수집: 폼 알림이 어느 메일로 가는지 확인해 스팸 목록에 넣습니다. 실제 사람이 쓰는 주소라서 값이 매겨집니다.
• 훔친 카드 확인: 결제 폼이 있으면 소액 결제를 반복합니다. 카드가 아직 살아 있는지 시험하는 것입니다.

2026년에는 브라우저처럼 화면을 그리고 마우스 움직임까지 흉내 내는 스팸 봇이 늘었다고 합니다.

5. 유출된 비밀번호 대입과 계정 탈취. 다른 서비스에서 유출된 아이디와 비밀번호 목록을 로그인 화면에 자동으로 넣어 보는 방식입니다. 같은 비밀번호를 여러 곳에 쓰는 사람이 있으니 계정 가운데 일부가 열립니다. 성공률이 낮아도 시도 비용이 거의 없어서 계속 들어옵니다.

앞의 다섯 가지가 무언가를 가져가려는 쪽이라면, DDoS는 서비스를 멈춰 세우는 쪽입니다. 목적은 대체로 돈입니다. 미국 법무부는 2026년 3월 국제 공조로 Aisuru, KimWolf, JackSkid, Mossad라는 사물인터넷 봇넷 네 곳의 지휘 서버(C2)를 무력화했다고 발표했습니다. 발표에 따르면 이들이 장악한 기기가 300만 대를 넘었고, 일부 공격은 초당 30테라비트 수준이었습니다. 공유기, 웹캠, 영상 녹화기처럼 집과 사무실에 있는 기기가 주인 모르게 동원된 결과입니다.

운영자들이 돈을 버는 방식은 두 가지입니다. 공격을 대신 해 주는 대행 서비스로 팔거나, 공격을 걸어 놓고 멈추는 대가를 요구합니다. 캐나다에서는 KimWolf 봇넷을 운영한 혐의로 20대 한 명이 기소됐습니다. 대형 공격의 상당수는 원한보다 돈벌이에 가깝다고 볼 수 있습니다.

정리하면 목적에 따라 대응도 달라집니다. 학습 크롤러는 열어 둘지 막을지 정책으로 정할 문제이고, 복제 봇과 폼 스팸은 걸러 내는 쪽입니다. 계정 대입과 DDoS는 규모를 견디는 준비에 가깝습니다.

봇 트래픽이 늘어난 규모

수치부터 놓고 보겠습니다. 봇이라는 말이 넓게 쓰이는 탓에, 어떤 봇이 얼마나 늘었는지 구분하지 않으면 대응 순서를 정하기 어렵습니다.

• 전체 요청에서 봇이 차지하는 비중: 클라우드플레어 레이더 기준 35.3%입니다. HTML 요청만 따로 보면 자동 접속이 사람을 넘어섰다는 발표가 2026년 6월에 나왔다고 합니다.
• 검증된 봇 안에서 AI가 차지하는 비중: 2026년 5월 기준 AI 크롤러가 20.3%, AI 검색 봇이 6.5%를 차지했다는 집계도 있습니다.
• 가져가는 양과 돌려주는 방문의 격차: AI 회사별로 수백에서 수천 페이지를 가져가는 동안 방문은 한 번 돌아오는 수준이라는 조사가 여럿 나왔다고 합니다.

마지막 항목이 사이트 운영자에게 가장 직접적인 손해로 돌아옵니다. 검색 엔진 크롤러는 색인을 만들고 검색 결과에 링크를 걸어 방문을 돌려보냈는데, 학습이나 답변 생성을 목적으로 하는 크롤러에서는 그런 대가가 없거나 아주 적습니다.

규모가 큰 곳에서는 이 격차가 비용으로 먼저 드러납니다. 위키미디어 재단은 2025년 4월 공식 블로그에서 위키미디어 공용의 멀티미디어 대역폭이 2024년 초부터 50% 늘었다고 밝혔습니다. 비용이 가장 많이 드는 트래픽의 65%가 봇에서 나왔는데, 전체 조회수에서 봇이 차지하는 비중은 35% 수준이었습니다. 사람들이 잘 찾지 않는 파일까지 봇이 훑어 가느라 캐시가 듣지 않았기 때문입니다.

robots.txt가 문에 붙인 안내문에 그치는 이유

이 상황에서 대부분의 사이트가 가장 먼저 하는 조치는 robots.txt 수정입니다. 이 파일이 무엇인지부터 짚고 가겠습니다.

이 파일은 1994년 마르테인 코스터(Martijn Koster)가 제안한 규칙에서 출발했습니다. 검색 로봇이 서버를 무겁게 만들자 웹 관리자들 사이에서 합의가 이뤄졌고, 2022년에는 RFC 9309이라는 인터넷 표준 문서로 정리됐습니다. 다만 처음부터 자발적으로 지키자는 약속이었고, 표준이 된 뒤에도 그 성격은 그대로입니다.

robots.txt는 사이트 최상단에 두는 텍스트 파일입니다. 가게 문에 "촬영을 삼가 주세요"라고 안내문을 붙여 두듯, 어느 크롤러가 어디를 가져가지 않았으면 하는지 여기에 적어 둡니다. 안내문을 보고 카메라를 내리는 손님이 대부분이듯, 주요 검색 엔진과 여러 AI 회사의 크롤러는 이 파일을 읽고 규칙을 지킵니다.

문제는 안내문에 강제력이 없다는 점입니다. 클라우드플레어는 2025년 8월 공식 블로그에서 퍼플렉시티가 차단된 사이트에 접속하려고 공개하지 않은 크롤러를 썼다고 밝혔습니다. 공개 문서에 없는 IP 주소를 돌려 쓰고 네트워크 식별 번호를 바꾸는 방식도 함께 지목했습니다. 클라우드플레어는 이후 퍼플렉시티를 검증된 봇 목록에서 뺐습니다.

정리하면 robots.txt는 지키는 상대에게만 통하는 부탁입니다. 안내문을 무시하는 손님을 막으려면 문 앞에 사람이 서 있어야 하듯, 실제로 접속을 끊으려면 서버 앞단 설정이 따로 필요합니다.

클라우드플레어가 AI 봇을 나누는 세 가지 분류

클라우드플레어는 2026년 7월 1일 AI 봇을 목적별로 나눠 관리하는 기능을 공개했습니다. 무료 플랜을 포함한 모든 고객에게 열려 있습니다. 대시보드에서 Security, Bots, AI Crawl Control 순서로 들어가면 설정 화면이 나옵니다.

세 가지 분류를 무엇을 하는 크롤러인지와 막았을 때 무엇이 달라지는지로 놓고 보면 이렇습니다.

분류마다 고를 수 있는 선택지는 전면 차단, 광고가 붙은 페이지에서만 차단, 차단하지 않음 이렇게 셋입니다.

날짜를 하나 기억해 둬야 합니다. 2026년 9월 15일부터 새 기본값이 적용됩니다. 클라우드플레어에 새로 올라오는 도메인은 광고가 붙은 페이지에서 Training과 Agent가 기본 차단되고, Search는 허용으로 남습니다. 여러 목적을 겸하는 크롤러에는 가장 제한적인 규칙이 적용되는데, Training을 막으면 검색과 학습을 겸하는 크롤러까지 막힌다는 뜻입니다. 기본값을 원하지 않으면 그전에 설정에서 바꿔 두면 됩니다.

실무에서 가장 자주 어긋나는 대목이 여기입니다. AI 봇을 막겠다고 한 번에 전부 차단하면 검색 노출까지 함께 떨어지기도 합니다. 클라우드플레어가 분류를 나눠 놓은 것도 그래서입니다.

무료 플랜에서 지금 켤 수 있는 기능

돈을 들이지 않고 켤 수 있는 항목부터 정리하겠습니다. 2026년 8월 기준입니다.

1. 관리형 robots.txt. 클라우드플레어가 robots.txt 파일을 만들거나 기존 파일을 갱신합니다. 콘텐츠가 AI 학습에 쓰이는 것을 원하지 않는다는 표시를 대신 넣어 줍니다. 설정 화면에는 이 기능이 검색 최적화에 영향을 주지 않는다는 설명이 붙어 있습니다.

2. AI 크롤러 분류별 차단. 앞에서 본 세 가지 분류 설정입니다. 안내문을 무시하는 크롤러도 여기서는 접속 단계에서 걸립니다.

3. Bot Fight Mode. 무료 플랜에서 쓰는 기본 봇 대응 기능입니다. 알려진 봇 패턴에 걸리는 요청을 자동으로 처리하며, 켜고 끄는 토글 하나로 되어 있습니다. 봇 종류별로 대응을 나눠 정하려면 유료 플랜의 Super Bot Fight Mode를 써야 하고, 요청마다 점수를 매기는 Bot Management는 엔터프라이즈 플랜에 들어갑니다.

4. AI Labyrinth. 허가 없이 자료를 모아 가는 크롤러를 끝없이 이어지는 링크 안에 가둬 두는 기능입니다. 공식 문서는 이 링크에 nofollow 태그가 붙어 있어서 검색 최적화나 화면에는 영향을 주지 않고 봇에게만 보인다고 설명합니다. 규칙을 지키는 봇은 이 함정을 지나칩니다.

5. Turnstile. 문의 폼이나 로그인 앞에 붙이는 확인 장치입니다. 방문자에게 사진 고르기 같은 문제를 내지 않고 배경에서 확인하며, 클라우드플레어에 사이트를 올려 두지 않았어도 이 위젯만 따로 붙입니다.

6. 속도 제한 규칙. 회전문이 한 번에 들어오는 인원을 제한하듯, 같은 출처에서 짧은 시간에 몰려오는 요청을 서버 앞단에서 끊는 규칙입니다. 로그인 시도를 반복하는 접속이나 API를 과도하게 부르는 접속에 씁니다.

문의 폼 스팸은 장치를 겹쳐 두면 대부분 걸러집니다. 먼저 화면에 보이지 않는 입력칸을 하나 두고, 그 칸이 채워진 채로 들어온 제출을 조용히 버립니다. 사람 눈에는 없는 칸이라 방문자는 불편을 느끼지 않는데, 화면을 해석하지 않는 단순한 스크립트는 여기서 걸립니다. 그다음 폼 제출에 Turnstile을 붙이고, 같은 주소에서 반복 제출이 들어오면 속도 제한으로 끊습니다.

VPN과 주거용 프록시로 우회하는 봇 대응

여기까지 켜 두어도 계속 들어오는 접속이 있는데, 차단당하면 다른 IP로 갈아타는 봇입니다. 문 앞 경비가 옷차림만 보고 사람을 가린다면 옷을 갈아입고 다시 오면 그만이듯, IP만 보고 막는 방어는 상대가 IP를 바꾸는 순간 풀립니다.

흔히 VPN이라고 부르지만, 실제로 문제가 되는 쪽은 주거용 프록시(residential proxy)입니다. 쉽게 말해 일반 가정의 인터넷 회선을 빌려 그 집 IP로 접속하게 해 주는 서비스입니다. 데이터센터 IP는 목록으로 정리되어 있어 막기 쉽지만, 가정 회선 IP는 진짜 방문자와 같은 대역을 씁니다. 그 IP를 막으면 그 집에 사는 사람도 함께 막힙니다.

그래서 IP 차단은 대응의 출발점이지 결론이 되기 어렵고, 업계가 보는 신호도 IP에서 옮겨 갔습니다. 클라우드플레어 공식 문서를 기준으로 정리하면 이렇습니다.

• 봇 점수: 요청마다 1에서 99 사이의 점수를 매깁니다. 1은 자동화가 확실한 쪽, 30 이상은 사람일 가능성이 높은 쪽입니다.
• TLS 지문(JA4): 접속을 시작할 때 오가는 암호 설정의 순서와 조합을 지문처럼 씁니다. 브라우저마다 값이 다르고, 자동화 도구는 흉내 내기 어렵습니다. IP를 바꿔도 지문은 따라옵니다.
• 자바스크립트 탐지: 가벼운 스크립트를 넣어 화면 없는 브라우저와 자동화 도구를 가려냅니다.
• 행동과 이상 탐지: 요청 간격, 페이지를 도는 순서, 평소 트래픽과의 차이를 봅니다.

여기에 규칙을 하나 더 걸 수도 있습니다. 클라우드플레어 공식 문서는 특정 네트워크 대역에서 오는 자동화 트래픽만 골라 확인 절차를 거치게 하는 예시를 보여 줍니다. 봇 점수가 30 미만이고, 검증된 봇이 아니며, 지정한 네트워크 번호에서 온 요청을 대상으로 삼는 방식입니다. 나라 전체나 IP 대역을 통째로 막지 않고 의심스러운 조합만 거르는 셈입니다.

다만 여기에는 제약이 하나 붙습니다. 봇 점수와 JA4 지문을 규칙에 쓰려면 엔터프라이즈 플랜의 Bot Management가 필요합니다. 무료나 저가 플랜에서 같은 수준을 기대하기는 어렵습니다. 대신 아래 네 가지는 플랜과 상관없이 효과를 냅니다.

1. 민감한 경로만 골라 확인 절차를 겁니다. 로그인, 회원가입, 문의 폼, 검색처럼 부담이 큰 곳에만 Turnstile을 붙입니다. 전체 페이지에 걸면 방문자가 먼저 떠나기도 합니다.
2. 속도 제한의 기준을 IP에서 옮깁니다. IP는 바꾸기 쉬우니 계정, 세션, API 키처럼 바꾸기 어려운 값을 기준으로 셉니다.
3. 서버 부담이 큰 화면을 로그인 뒤로 옮깁니다. 전체 목록이나 대량 조회처럼 한 번에 많이 가져갈 수 있는 화면은 로그인한 사용자에게만 엽니다.
4. 캐시로 비용을 흡수합니다. 앞단에서 응답이 끝나면 아무리 많이 가져가도 서버 비용은 크게 늘지 않습니다.

우회 수단이 있는 이상 완전한 차단은 어렵습니다. 그래서 전부 막겠다고 붙들기보다, 상대가 들이는 비용을 수지가 맞지 않는 수준까지 올리는 쪽이 현실적입니다.

지금 대규모로 뚫리고 있을 때의 대응 순서

앞의 내용이 평상시에 갖춰 두는 설정이라면, 이미 대규모로 들어오고 있을 때는 순서가 달라집니다. 불이 난 뒤에 소화기를 찾지 않으려면 절차를 미리 정해 둬야 합니다.

1. 공격인지부터 확인합니다. 서버가 느려졌다고 전부 공격은 아니므로, 로그에서 세 가지를 봅니다. 특정 경로에 요청이 몰리는지, 참조 주소 없이 들어오는 비율이 갑자기 올랐는지, 평소 없던 네트워크 번호에서 오는지입니다.

2. 표적이 된 경로부터 좁혀 겁니다. 사이트 전체를 잠그기 전에 요청이 몰리는 경로에만 규칙을 겁니다. 검색, 목록, 로그인처럼 서버 부담이 큰 곳이 대체로 표적입니다.

3. 속도 제한을 임시로 조입니다. 평상시 기준보다 낮춰 두었다가, 공격이 잦아들면 되돌립니다.

4. 그래도 서버가 버티지 못하면 Under Attack Mode를 켭니다. 클라우드플레어의 7계층 DDoS 완화 기능으로, 켜면 방문자마다 짧은 확인 화면을 거칩니다. 공식 문서는 이 기능을 마지막 수단으로 설명하면서 실제로 공격받는 동안에만 쓰라고 안내합니다. 자바스크립트를 실행해야 통과하는 구조라서 API 호출과 외부 연동, 모니터링 도구가 함께 막히고, 외부 분석 도구의 수치도 영향을 받습니다. 상시로 켜 두는 설정이 아닙니다.

5. 엔터프라이즈 플랜이라면 봇 점수로 규칙을 나눕니다. 공식 문서가 권하는 조합은 세 단계입니다. 검증된 봇은 규칙을 건너뛰게 하고, 점수 1은 차단하고, 2에서 29 사이에는 관리형 챌린지를 겁니다. 관리형 챌린지는 상대에 따라 난이도가 자동으로 조절되는 확인 절차입니다. API 경로는 조건에서 빼 두어야 연동이 끊기지 않습니다.

6. 공격이 끝나면 되돌립니다. 임시 조치를 그대로 두면 정상 방문자와 외부 연동이 계속 막히므로, 무엇을 언제 켰는지 적어 두고 하나씩 원위치시킵니다.

상대도 비용을 들여 접속하는 쪽이라, 방어가 두터워지면 다른 사이트로 옮겨 가기도 합니다. 그래서 영구 차단을 목표로 삼기보다 공격이 지나갈 때까지 버티는 설정을 갖춰 두는 편이 실속 있습니다.

크롤링을 막는 대신 값을 매기는 방식

막는 것만이 답은 아닙니다. 클라우드플레어의 AI Crawl Control은 크롤러에게 402 응답, 즉 결제가 필요하다는 상태 코드를 돌려주면서 안내 문구를 함께 보냅니다.

이 방식은 문을 잠근 뒤 "이용 문의는 적힌 연락처로"라고 붙여 두는 쪽에 가깝습니다. 개별 사이트가 AI 회사와 직접 이야기를 트기는 어려우니, 접속을 막으면서 연락 경로를 함께 남기는 구조입니다.

표준을 만들려는 움직임도 있습니다. RSL(Really Simple Licensing), 즉 간단한 라이선스 표기 규격은 2025년 9월 10일 공개됐습니다. robots.txt에 이용 조건과 대가를 기계가 읽는 형태로 적어 두는 방식입니다. 레딧, 야후, 미디엄, 쿠오라가 지지를 밝혔다고 합니다. 다만 표기가 있다고 상대가 값을 치르지는 않으니, 실제 효력은 앞으로 쌓일 사례를 봐야 판단할 수 있습니다.

봇에게 신원을 증명하게 하는 규격도 나왔습니다. Web Bot Auth는 봇이 스스로 신원을 암호로 서명해 보내는 방식이고, HTTP 메시지 서명 표준(RFC 9421)을 바탕으로 합니다. 사용자 에이전트 문자열은 아무나 흉내 낼 수 있고 IP 목록은 자주 바뀌는 반면, 서명은 위조하기 어렵습니다. 클라우드플레어, 아마존, 아카마이, 오픈AI가 함께 참여하고 있고 AWS WAF도 지원을 발표했습니다.

클라우드플레어 말고 쓸 수 있는 대안

한 회사에 다 맡기기 어렵거나, 이미 다른 인프라를 쓰고 있을 수 있습니다. 2026년 8월 기준으로 자주 비교되는 선택지를 정리하면 이렇습니다.

마지막 항목만 성격이 다릅니다. Anubis는 접속하는 쪽에 SHA-256 계산 문제를 내고, 답을 맞힌 요청만 통과시키는 오픈소스 프로그램입니다. 개발자 Xe Iaso가 2025년 1월 공개했는데, 아마존 크롤러가 이 개발자의 서버를 마비시킨 일이 계기였다고 합니다. 계산 비용이 사람에게는 거의 느껴지지 않는 수준이지만, 하루에 수백만 페이지를 훑는 쪽에는 부담이 됩니다. GNOME, FFmpeg, 유네스코 같은 곳에서 쓰고 있습니다.

다만 만능은 아닙니다. 코드버그는 2025년 8월에 Anubis의 문제를 푸는 봇이 늘었다고 밝혔다고 합니다. 그러면서도 몇 달 동안 대부분의 수집을 막아 줬다고 평가했습니다. 이런 방식은 완전한 차단이 아니라 상대의 비용을 올리는 쪽에 가깝습니다.

DDoS 공격 규모와 방어를 여러 겹으로 쌓는 순서

자료를 가져가는 봇과 서비스를 무너뜨리려는 공격은 다릅니다. 클라우드플레어의 2026년 상반기 DDoS 보고서에 담긴 수치는 이렇습니다.

• 네트워크 계층 공격 2,320만 건을 막았고, 시간당 평균 약 5,343건에 해당합니다.
• HTTP 계층에서는 29조 6,400억 건의 공격 요청을 차단했습니다.
• 초당 1테라비트를 넘는 공격이 상반기에만 935건 발생했는데, 1분기 130건에서 2분기 805건으로 늘었습니다.
• DNS를 노린 공격이 네트워크 계층 활동의 34.3%를 차지했습니다.
• 가장 많이 공격받은 업종은 미디어와 제작, 출판 분야로 전체 HTTP 공격 요청의 14.2%를 받았습니다.

개인 블로그나 소규모 사이트가 이 규모의 공격을 받을 일은 드뭅니다. 그래도 방어의 순서는 규모와 무관하게 같습니다. 가게 문 하나만 잠그고 끝내지 않듯, 방어를 여러 겹으로 나눠 두면 한 겹이 뚫려도 다음 겹이 남습니다.

1. 원본 서버 주소를 숨깁니다. CDN을 앞에 두어도 서버의 실제 IP가 노출되어 있으면 공격이 그리로 곧장 들어옵니다. 방화벽에서 CDN 대역의 접속만 받도록 설정합니다. 앞문에 경비를 세우고 뒷문을 열어 두면 소용이 없습니다.
2. DNS를 관리형 서비스에 맡깁니다. 2026년 상반기 공격의 3분의 1이 DNS를 노렸습니다. 직접 운영하는 네임서버는 이 공격을 감당하기 어렵습니다.
3. 속도 제한과 지역 규칙을 겁니다. 로그인, 검색, API처럼 부담이 큰 경로마다 따로 정합니다.
4. 봇 분류별 정책을 정합니다. 앞에서 본 세 가지 분류를 나눠 설정합니다.
5. 정적 파일을 최대한 캐시에 올립니다. 앞단에서 응답이 끝나면 요청이 서버까지 오지 않습니다.
6. 로그를 주기적으로 봅니다. 무엇이 막혔고 무엇이 통과했는지 확인하지 않으면 설정이 맞는지 알 수 없습니다.

소규모 콘텐츠 사이트라면 이 작업은 사흘이면 대부분 끝납니다. 첫날에는 관리형 robots.txt를 켜고 AI 봇 세 가지 분류를 정하는데, Search는 허용, Training은 차단으로 두고 Agent는 상황에 맞게 고릅니다. 둘째 날에는 문의 폼에 보이지 않는 입력칸과 Turnstile을 붙이고 제출 경로에 속도 제한을 겁니다. 셋째 날에는 서버 방화벽에서 CDN 대역 밖의 접속을 막고, 일주일 뒤 로그를 열어 검색 크롤러가 정상적으로 들어오는지 확인합니다.

AI 크롤러를 전부 막으면 검색 노출도 떨어지나요?

분류를 나누지 않고 한꺼번에 막으면 그럴 수 있습니다. 검색 목적 크롤러는 색인을 만들어 검색 결과에 링크를 남기므로, 이쪽까지 막으면 검색 유입이 줄어듭니다. 클라우드플레어가 Search, Training, Agent를 나눠 놓은 이유가 여기에 있습니다. 다만 검색과 학습을 겸하는 크롤러에는 더 제한적인 규칙이 적용되므로, Training을 막으면 그 크롤러의 검색 수집도 함께 멈춘다는 점을 감안해야 합니다. 검색 노출을 유지하려면 Search를 허용으로 두고 Training만 막는 조합에서 시작하는 편이 안전합니다.

VPN으로 우회하는 공격이 흔한가요?

사이트 성격에 따라 크게 다릅니다. 돈이 되는 데이터를 가진 곳이 먼저 표적이 됩니다. 가격과 재고, 리뷰, 회원 계정처럼 한 번에 많이 뽑아 갈 수 있는 자료가 대표적입니다. 한 봇 방어 업체는 2026년 3월 리뷰 플랫폼을 노린 8천만 건 규모의 수집을 막았고, 여기에 동원된 IP가 85만 개를 넘었다고 밝혔습니다. 반면 개인 블로그나 회사 소개 사이트라면 AI 크롤러는 오더라도 이런 집요한 우회까지 겪는 경우는 드뭅니다. 클라우드플레어 기본 설정과 폼 보호만 해 두어도 대체로 조용한 편입니다.

VPN을 쓰는 방문자까지 막으면 문제가 되지 않나요?

문제가 됩니다. 회사 네트워크를 거쳐 접속하거나, 사생활을 이유로 VPN을 쓰는 방문자가 적지 않습니다. 특정 대역을 통째로 막으면 이런 사람들이 먼저 걸리므로, IP 하나만 보고 차단하기보다 자동화로 의심되는 신호와 겹칠 때만 확인 절차를 거는 편이 낫습니다. 확인 절차도 전체 페이지가 아니라 로그인이나 폼 제출 같은 경로에만 겁니다. 막는 대신 한 단계 더 묻는 방식이라 사람은 통과하고 자동화는 비용을 치릅니다.

무료 플랜만으로 충분한가요?

트래픽이 많지 않은 콘텐츠 사이트라면 무료 범위로도 상당 부분 대응할 수 있습니다. 무료 범위에 관리형 robots.txt와 AI 봇 분류별 차단이 들어 있고, Bot Fight Mode와 Turnstile, 속도 제한 규칙도 함께 씁니다. 요청마다 점수를 매겨 정교하게 나누는 Bot Management나 봇 종류별 대응을 따로 정하는 Super Bot Fight Mode는 유료 플랜에 들어갑니다. 로그인과 결제가 있는 서비스라면 유료 플랜을 검토하는 편이 낫습니다. 재고나 가격 정보를 노리는 수집이 잦은 서비스도 마찬가지입니다.

3줄 요약:

• robots.txt는 지키는 크롤러에게만 통하는 부탁이므로, 실제로 막으려면 서버 앞단에서 접속을 끊는 설정을 함께 켭니다.
• 클라우드플레어는 AI 봇을 검색, 학습, 에이전트로 나눠 무료 플랜에서도 따로 설정하게 했고, 2026년 9월 15일부터 신규 도메인에 새 기본값이 적용됩니다.
• VPN과 주거용 프록시로 IP를 갈아타는 봇에는 IP 차단이 통하지 않으므로, 신원과 행동을 함께 보는 신호로 상대의 비용을 올리는 쪽을 목표로 잡습니다.

Sources

• Cloudflare DDoS Threat Report H1 2026
• Your site, your rules: new AI traffic options for all customers (Cloudflare)
• Control content use for AI training with Cloudflare's managed robots.txt (Cloudflare)
• The next step for content creators in working with AI bots: Introducing AI Crawl Control (Cloudflare)
• Perplexity is using stealth, undeclared crawlers to evade website no-crawl directives (Cloudflare)
• Bot score (Cloudflare Docs)
• JA3/JA4 fingerprint (Cloudflare Docs)
• Custom rules for bot solutions (Cloudflare Docs)
• Under Attack mode (Cloudflare Docs)
• Challenge bad bots (Cloudflare WAF Docs)
• AI Labyrinth (Cloudflare Docs)
• Cloudflare Bots Overview (Cloudflare Docs)
• Rate limiting rules (Cloudflare Docs)
• Bot Traffic Worldwide (Cloudflare Radar)
• Authorities disrupt world's largest IoT DDoS botnets (U.S. Department of Justice)
• Canadian man arrested, charged with administrating KimWolf DDoS botnet (U.S. Department of Justice)
• How crawlers impact the operations of the Wikimedia projects (Wikimedia Diff)
• RSL 1.0 Specification (RSL Standard)
• AWS WAF announces Web Bot Auth support (AWS)