AI 크롤러 차단 설정법, 봇 트래픽이 사람 추월

클라우드플레어는 봇 트래픽이 사람 트래픽을 넘어서는 시점을 두 번 내다봤다. 두 번 다 빗나갔다. 처음 잡은 시점을 한 차례 앞당겼는데, 실제 역전은 그 앞당긴 예측보다도 일찍 찾아왔다. 전 세계 350개 이상 도시에 수천 개 데이터센터를 깔아 두고 인터넷의 상당 부분을 지켜보는 회사의 집계다. 같은 집계에서 봇은 이미 인터넷 트래픽의 절반을 넘었다. 트래픽을 이만큼 넓게 들여다보는 회사조차 속도를 두 번이나 잘못 읽었다. 그만큼 증가세가 가팔랐다는 얘기다.

매슈 프린스 클라우드플레어 CEO가 더버지 팟캐스트 ‘디코더’에 나와 한 이야기에서 숫자는 출발점일 뿐이다. 핵심은 그다음에 나온다. 웹사이트를 읽는 쪽이 사람에서 기계로 넘어가면, 사람 눈에 광고를 띄워 돈을 버는 웹의 기본 구조가 흔들린다. 사이트를 운영하는 입장이라면 설정 화면은 잠시 미뤄 두자. AI 봇을 막을지, 받을지, 돈을 받고 들일지부터 정하는 게 순서다.

방문자가 기계로 바뀌면 사이트는 광고와 통계를 함께 잃는다

웹은 적어도 30년 동안 광고로 먹고살았다. 구글은 검색 회사로 머물지 않았다. 더블클릭을 사들이고 구글 애널리틱스를 만들면서 ‘누가 내 사이트에 왔는지 확인하고, 그 방문에 광고를 붙이는’ 생태계를 통째로 설계했다. 이 판 전체가 방문자는 사람이라는 전제에 기대고 있다. 광고는 사람이 봐야 매출이 되고, 방문 통계도 사람이 다녀갔다는 신호일 때만 쓸모가 있다.

봇은 이 전제 바깥에 있다. 사이트로 들어오는 자동화 트래픽은 성격에 따라 세 갈래로 나눠 보면 정리가 쉽다.

• 검색 크롤러: 페이지를 색인해 검색 결과에 올린다. 사용자가 결과를 누르면 방문으로 돌아온다. 사이트 입장에서도 손해 보지 않는 거래다.
• AI 학습·수집용 크롤러: 페이지 내용을 긁어 가 모델 학습이나 답변 생성의 재료로 쓴다. 방문이 되돌아온다는 보장은 없다.
• AI 에이전트: 사람이 맡긴 일을 대신 처리하러 사이트에 들어온다. 가격 비교, 예약, 정보 요약 같은 작업. 사람 대신 페이지를 읽으니 광고가 노출되지 않는 경우가 많다.

걸리는 건 뒤의 두 부류가 계속 불어난다는 점이다. 서버 비용과 대역폭은 사이트가 고스란히 떠안는데, 광고 노출과 방문은 줄어든다. 방문 통계에 봇이 섞이면 애널리틱스 숫자만 보고 어떤 콘텐츠가 성과를 냈는지 판단하기도 어려워진다. 프린스 CEO가 클라우드플레어를 설명하는 방식도 달라졌다. 예전엔 ‘인터넷을 빠르게 하고 나쁜 이들로부터 지키는 서비스’였는데, 이제는 ‘처음부터 이렇게 지어졌어야 할 인터넷을 다시 짓는 회사’라고 말한다. 트래픽을 지키는 일이 인터넷의 사업 모델을 다시 짜는 일로 커졌다고 보기 때문이다. 회사 소개 문구를 바꿀 만큼 판이 달라졌다는 인식이기도 하다.

막을지, 열지, 돈 받고 열지는 수익원이 가른다

클라우드플레어가 사이트 운영자에게 내놓는 선택지는 크게 세 가지. AI 도구를 전부 막거나, 전부 들이거나, 접근 대가를 치를 의향이 있는 봇만 들이는 것이다. 셋 중 정해진 정답은 없다. 사이트가 무엇으로 돈을 버느냐에 따라 답이 갈린다.

표에서 가장 흐릿한 칸은 유료 허용의 ‘감수할 것’이다. 과금 구조가 아직 자리 잡는 중이니, 당장 이 선택지에 수익 기대를 크게 거는 건 이르다. 판단 기준은 세 가지 질문으로 좁혀진다.

1. 수익이 방문에서 나오는가? 광고 단가나 구독 전환이 방문 수에 묶여 있다면, 방문을 돌려주지 않는 수집기는 비용만 남기고 간다. 차단 쪽으로 무게가 기운다.
2. AI 답변에 이름이 오르는 게 이득인가? 제품 설명서, 고객지원 문서, 회사 소개처럼 널리 읽히는 것 자체가 목적인 콘텐츠라면 허용이 낫다. 누군가 AI에게 물었을 때 우리 제품 이름이 나오는 편이 유리하니까.
3. 다른 데서 구할 수 없는 정보인가? 직접 취재한 기사, 자체 조사 데이터, 전문 리뷰처럼 대체재가 없는 콘텐츠라면 유료 허용을 따져 볼 만하다. 프린스 CEO가 디코더에서 ‘앞으로 어떤 정보가 가치를 가질지’를 비중 있게 다룬 것도 이 지점과 맞닿아 있다.

한 사이트 안에서도 답은 갈린다. 블로그 글은 막고 제품 문서는 열어 두는 식으로 경로마다 정책을 따로 두는 게 현실적인 절충이다. 셋 중 하나를 사이트 전체에 일괄 적용하는 것보다 손은 더 가지만, 잃는 것도 적다.

클라우드플레어 대시보드에서 AI 봇 막는 다섯 단계

클라우드플레어를 이미 쓰고 있다면 코드를 짤 일은 없다. 대시보드에서 끝난다. 다만 대시보드 개편이 잦아 메뉴 이름과 위치가 요금제, 계정, 화면 버전마다 다르다. 아래 경로는 흐름을 잡는 참고용이다. 메뉴가 안 보이면 봇(Bots)이나 AI라는 단어가 들어간 항목을 찾으면 된다.

1. 현황 확인: 대시보드 로그인 → 대상 도메인 선택 → 분석(Analytics) 또는 보안(Security) 영역의 트래픽·이벤트 화면. 여기서 자동화 트래픽의 비중과 자주 들어오는 봇을 본다. 무엇이 들어오는지 알고 막아야 검색 크롤러까지 막아 버리는 사고를 피한다.
2. 일괄 차단: 보안(Security) → 봇(Bots)으로 가서 ‘AI 봇 차단’이나 ‘AI 스크레이퍼·크롤러 차단’ 같은 이름의 항목을 켠다. 클라우드플레어가 AI 수집기로 분류해 둔 봇을 한꺼번에 막는 방식이다. 분류를 클라우드플레어에 맡기는 셈이라 가장 빠르지만 세밀하진 않다.
3. 크롤러별 선별: AI 크롤러를 하나씩 허용하거나 차단하는 관리 화면이 있는 계정이라면 거기서 봇마다 정책을 따로 준다. 대가를 내는 봇만 들이는 설정도 이 계열 메뉴에 들어 있다. 제공 여부와 메뉴 이름은 계정마다 다르다.
4. 경로별 규칙: 보안(Security) → WAF → 사용자 지정 규칙(Custom rules). ‘User-Agent에 특정 문자열 포함’과 ‘URI 경로가 /blog/로 시작’ 같은 조건을 묶고, 동작은 차단(Block)이나 챌린지(Challenge) 중에서 고른다. 블로그만 막고 문서는 여는 정책이 이렇게 만들어진다.
5. 적용 후 점검: 규칙을 켜고 며칠은 검색 유입과 검색엔진 관리 도구의 크롤링 오류를 지켜본다. 검색 노출이 떨어졌다면 규칙이 검색 크롤러까지 붙잡고 있는 건 아닌지 확인한다.

클라우드플레어가 없다면 robots.txt, 다만 요청문일 뿐이다

클라우드플레어를 쓰지 않는 사이트의 첫 수단은 robots.txt다. 사이트 최상위 경로에 두는 파일로, 크롤러 이름(User-agent)별로 들어와도 되는 경로를 적는다.

User-agent: [차단할 AI 크롤러 이름]
Disallow: /

User-agent: [일부만 허용할 AI 크롤러 이름]
Disallow: /blog/

User-agent: *
Allow: /

첫 블록은 해당 크롤러를 사이트 전체에서 막는다. 둘째 블록은 블로그 경로만 막고, 마지막 블록은 나머지 크롤러를 모두 들인다. 크롤러 이름은 AI 회사마다 제각각이고 새로 생기거나 바뀌기도 한다. 각 회사가 공개한 공식 문서에서 이름을 확인하고, 목록은 주기적으로 손봐야 한다.

한계는 분명하다. robots.txt는 ‘들어오지 말아 달라’는 요청문이지 자물쇠가 아니다. 규칙을 지키는 크롤러는 따르지만, 무시하는 봇 앞에서는 아무 효력이 없다. User-Agent 역시 봇이 스스로 밝히는 이름이라 얼마든지 사칭이 가능하다. robots.txt만 고쳐 두고 안심하는 건 절반짜리 대응이다.

강제력이 필요하면 한 단계 더 들어가야 한다. 웹서버 설정 파일에서 User-Agent 조건에 걸리는 요청에 접근 거부 응답을 돌려주거나, 호스팅 업체가 제공하는 방화벽 기능을 쓰는 방법이 있다. 사칭까지 걸러내려면 IP 대역 대조나 행동 기반 탐지가 필요한데, 개인이 직접 구축하기엔 부담이 크다. 클라우드플레어 같은 중간 계층 서비스가 이 영역을 쥐고 있는 이유가 여기 있다.

한국어 사이트도 똑같이 긁힌다, 손댈 수 있는 범위만 다르다

AI 수집은 언어를 가리지 않는다. 한국어 글도 같은 방식으로 긁혀 가니, 봇 트래픽 증가가 국내 사이트의 서버 비용과 방문 통계에도 그대로 반영된다고 보는 게 합리적이다. 차이는 운영자가 손댈 수 있는 범위에서 난다. 사이트 형태에 따라 꽤 크게.

• 가입형 블로그 플랫폼: robots.txt나 봇 차단 설정을 운영자가 직접 고치지 못하는 경우가 많다. 이때 AI 봇 정책은 플랫폼 회사가 정하고, 개인은 플랫폼 공지와 이용약관 변경을 지켜보는 게 사실상 전부다. 플랫폼별 세부 정책은 각 서비스 공지에서 확인해야 한다.
• 자체 도메인 사이트·설치형 블로그: robots.txt 수정, 클라우드플레어 연결, 서버 규칙까지 전부 운영자 몫이다. 앞에서 본 설정 순서를 그대로 가져다 쓰면 된다.
• 온라인 쇼핑몰: 판단이 제일 까다롭다. AI 에이전트가 사람 대신 상품을 찾고 비교하는 흐름이 커지면, 에이전트를 전부 막는 건 고객 한 부류를 문 앞에서 돌려보내는 셈이 될 가능성이 있다(추측). 상품 정보 페이지는 열고 회원·결제 경로는 막는 식으로 나누는 게 무난해 보인다.

국내 포털의 검색 로봇을 실수로 막지 않는 것도 챙길 부분이다. 사용자 지정 규칙을 넓게 잡아 User-Agent에 bot이 들어간 요청을 통째로 막아 버리면 국내 검색 노출까지 사라진다. 대시보드 표시 언어에 따라 메뉴 이름이 달리 보이기도 한다. 이 글에서 괄호로 병기한 영문 명칭을 기준으로 찾는 편이 덜 헷갈린다.

확인된 것과 아직 불확실한 것

확인된 것

• 클라우드플레어 집계 기준으로 봇은 인터넷 트래픽의 절반을 넘었고, 자동화 트래픽이 사람 트래픽을 앞질렀다.
• 역전은 클라우드플레어가 두 차례 내놓은 예측보다 빨리 일어났다.
• 클라우드플레어는 사이트 운영자에게 AI 도구 전면 차단, 전면 허용, 대가를 내는 봇만 허용하는 선택지를 제공한다.
• 클라우드플레어 네트워크는 전 세계 350개 이상 도시, 수천 개 데이터센터에 걸쳐 있다.

아직 불확실한 것

• 대가 지불 방식의 가격 책정과 정산 구조가 어떤 모습으로 자리 잡을지
• 유료 접근 기능이 어느 요금제와 계정까지 열릴지, 대시보드 메뉴가 어떻게 바뀔지
• 어떤 종류의 정보가 AI 회사에게 돈을 낼 만한 가치로 인정받을지
• AI 회사들이 차단 설정과 robots.txt를 얼마나 일관되게 지킬지
• 에이전트 트래픽이 광고 중심의 웹 사업 모델을 얼마나 빠르게 대체할지

차단 토글보다 먼저 정할 것은 사이트의 수익 구조

AI 봇 대응은 보안 설정처럼 생겼지만 실은 사업 결정이다. 광고로 먹고사는 사이트, 브랜드 노출이 목적인 사이트, 독자 데이터를 쥔 사이트는 같은 토글 앞에서 서로 다른 답을 내야 한다. 순서는 네 단계. 지금 들어오는 봇을 확인하고, 수익이 방문에 묶여 있는지 판단하고, 경로별로 정책을 나눈 다음, 적용 후 검색 유입을 점검한다.

프린스 CEO는 사람이 아닌 트래픽이 웹의 주 사용자가 되는 흐름을 보면서, 대가를 내는 봇만 들이는 모델을 인터넷의 다음 사업 모델 후보로 밀고 있다. 이 모델이 광고만큼 넓게 퍼질지는 아직 모른다. 설정 한 번으로 끝날 문제가 아니라는 것만은 분명하다. AI 회사의 크롤러 목록은 계속 바뀌고, 사이트의 수익 구조도 가만히 있지 않는다. 정책을 한 번 정해 두고 잊기보다 분기마다 봇 현황을 다시 열어 보는 습관이 더 오래 간다.

출처: The Verge

테크가이드팀

Daily News Korea 테크가이드팀은 IT 기기 비교, 소프트웨어 추천, 트러블슈팅 가이드 등 실용적인 기술 콘텐츠를 제작합니다. 초보자도 쉽게 따라할 수 있는 단계별 가이드를 지향합니다.