봇 탐지에 $200M이 몰릴 때, 봇 운영팀이 읽는 법

우리가 봇을 운영하면서 봇 탐지 뉴스를 보는 이유

Spur Intelligence가 Insight Partners에서 2억 달러(약 2,800억 원)를 유치했다. 사람 트래픽과 봇 트래픽을 구분하는 기술을 만드는 스타트업에 이 규모가 들어왔다는 건, 단순히 "봇 탐지 시장이 크다"는 이야기가 아니다.

우리 팀은 매일 수십 번씩 봇을 돌린다. 콘텐츠 생성봇, 공고 크롤러, 소셜 자동화 스크립트가 cron으로 돌아가며 사이트를 먹여 살린다. 동시에 우리 사이트로 들어오는 가짜 트래픽이 AdSense 광고 계정에 얼마나 위험한지도 잘 안다. 봇을 쏘는 쪽이면서 봇을 막아야 하는 쪽이기도 하다.

이 이중성이 $200M 투자 소식을 읽는 우리만의 시각을 만든다. 단, 여기서 놓치면 안 되는 게 있다. 봇 탐지 기술이 좋아진다는 건, 우리가 운영하는 "착한 봇"도 더 높은 기준을 통과해야 한다는 뜻이다. 그 함정을 먼저 짚어두고 시작한다.

$200M이 의미하는 탐지 수준의 도약

벤처 투자에서 $200M 라운드는 이미 유의미한 매출이 있다는 신호다. 통상적인 10x ARR 멀티플을 대입하면 Spur의 연 매출은 $20M(약 280억 원) 이상으로 추산된다. 그 돈은 대형 e-commerce, 광고 플랫폼, 금융사에서 온다. 이미 실제로 쓰이고 있다는 뜻이다.

지금까지 정밀한 봇 탐지는 비용 때문에 대형 플랫폼 전유물이었다. Cloudflare Bot Management만 해도 엔터프라이즈 플랜은 월수백 달러부터 시작한다. 그런데 $200M이 R&D와 영업에 투입되면 탐지 모델 정확도가 올라가고, 더 저렴한 티어가 만들어지고, 결국 우리가 크롤링 대상으로 삼는 정부 공고 사이트나 뉴스 사이트도 이 기술을 도입하기 시작한다. 지금 안 쓰는 곳이 1~2년 내 쓰기 시작할 수 있다.

Imperva의 2024년 보고서에 따르면 인터넷 트래픽의 약 47%가 봇이다. 그 절반가량이 "나쁜 봇"이고, 나머지는 크롤러나 모니터링 스크립트 같은 자동화 도구다. 12년간 검증된 AI 전문교육 커리큘럼들이 반복 학습의 중요성을 강조하듯, Spur의 탐지 모델도 수억 건의 실제 트래픽 패턴을 쌓아 지금의 정확도에 도달했다. 그 수준의 기술이 중소형 사이트까지 내려오기 시작하면, 파장은 예상보다 빠르다.

소수 개발팀 자동화의 구조적 취약점

10명 이하 팀이 10개 이상의 사이트를 운영한다는 건 자동화 없이는 물리적으로 불가능하다. 자동화는 선택지가 아니라 생존 인프라다.

그 인프라의 가장 큰 위험은 "언제 갑자기 막힐지 모른다"는 불확실성이다. 크롤러 하나가 대상 사이트 IP 차단에 걸리거나 User-Agent 필터에 걸리면, 그 봇에 의존하는 다운스트림 발행 파이프라인 전체가 조용히 멈춘다. 최악의 경우 며칠이 지나서야 발행이 멈춘 걸 알아챈다.

직접 경험해보니 가장 골치 아픈 건 에러가 명시적으로 뜨지 않는 경우였다. Cloudflare 챌린지 페이지를 HTML로 받아와서 실제 콘텐츠인 줄 알고 파싱을 시도하다가 빈 결과를 내보내는 패턴이 전형적이다. HTTP 200이 반환되는데 봇이 막혀 있는 상태. 코드는 멀쩡히 돌아가는데 아무것도 발행되지 않는다. 탐지가 정교해질수록 이런 조용한 실패가 더 많아진다.

자동화 유형별 실제 대응 시나리오

크롤러 의존 봇이 가장 직접적인 영향을 받는다. 정부 지원 사업 공고를 크롤링하는 봇은 현재 requests + BeautifulSoup 조합으로 돌아가고 있는데, 대상 사이트가 Spur급 탐지를 도입하면 조용히 막힌다. 대안은 둘이다. 공공데이터포털에 공식 API가 있으면 그걸 쓰는 게 먼저다. 없으면 Playwright 계열로 실제 브라우저를 띄워야 한다. 우리 blindboxdex 봇이 이미 Playwright를 쓰는데, 안정성은 올라가지만 크롬 인스턴스 하나가 메모리 150-200MB를 먹는다. 봇이 여러 개면 서버 용량 계산을 처음부터 다시 해야 한다.

소셜 포스팅 봇은 공식 API를 쓰면 봇 탐지 이슈에서 상대적으로 안전하다. 위험은 다른 데서 온다. 우리가 직접 겪었듯이 Threads에서 신규 계정으로 연속 발행을 했다가 계정 정지를 먹었다. 봇 탐지 기술보다 플랫폼 정책 변화가 더 빠르고 예고 없이 온다는 게 그때의 교훈이었다. 공식 API를 쓰더라도 "얼마나 자주"가 결국 변수가 된다.

콘텐츠 생성봇은 오히려 반사 이익을 받는 영역이다. 봇 탐지 기술이 광범위해지면 검색 트래픽 데이터의 봇 오염이 줄고, AdSense CPM 실측치가 더 정확해진다. 실제 사람이 보는 트래픽만 남으면 광고 수익 예측도 신뢰할 수 있다. 봇 탐지의 발전이 우리한테 유리하게 작용하는 지점이 여기다.

API-first 전환의 실제 트레이드오프

봇 탐지가 고도화될수록 스크래핑 의존도를 줄이고 공식 API로 가는 방향이 맞다. 그런데 현실적인 트레이드오프가 있다.

공식 API는 안정적이고 탐지 걱정이 없다. 대신 커버리지가 좁고 지연이 있다. 공공데이터포털 API는 실제 사이트 공고보다 반나절에서 하루 늦게 업데이트되는 경우가 많다. Holodex API처럼 잘 관리된 서드파티 API도 데이터 범위에 한계가 있다. 반면 스크래핑은 데이터가 실시간에 가깝지만 유지보수 비용이 숨어 있다. 스크래퍼 하나 짜는 데 2시간이지만 연간 유지에는 10-20시간이 실제로 든다. 그 비용이 축적되면 꽤 무겁다.

우리가 택한 방식은 계층 분리다. 공식 API가 있으면 API 우선. 없으면 requests + 명시적 실패 감지로 보완한다. Cloudflare 챌린지 패턴이나 예상 밖 리디렉션을 명시적으로 체크하고 알림을 트리거한다. 크롤러는 robots.txt 준수 + 적절한 딜레이를 달아 "정중한 크롤러"로 운용한다. 봇 탐지 알고리즘이 정교해질수록, 역설적으로 프로토콜을 지키는 봇이 오래 살아남는다.

지금 당장 손댈 수 있는 것들

크롤러마다 조용한 실패 감지 로직을 추가하라. HTTP 200이 왔다고 데이터가 있는 게 아니다. 응답 본문에 Cloudflare 챌린지 키워드가 있는지, 예상 DOM 엘리먼트가 실제로 존재하는지를 명시적으로 체크하고 알림을 보내야 한다. 빈 데이터를 발행하는 게 발행이 멈추는 것보다 훨씬 나쁘다.

크롤러 User-Agent를 의미 있게 설정하라. Mozilla/5.0 (compatible; HedvionBot/1.0; +https://hedvion.com/bot) 형식으로 봇임을 밝히고 연락처를 넣으면, 봇 탐지 시스템이 화이트리스트 처리하는 경우가 실제로 있다. 숨기는 것보다 투명한 게 더 오래 살아남는다.

각 크롤러의 대체 경로를 문서화해두라. 이 봇이 막히면 다음 옵션이 뭔지 — 공식 API 링크, 대안 소스, 또는 그냥 스킵하는 게 맞는지. 항목이 있기만 해도 장애 대응 속도가 달라진다.

마지막으로, 우리 사이트로 들어오는 봇 트래픽 비중을 한 번 확인하라. Google Search Console 크롤 통계나 서버 액세스 로그의 UA 패턴을 보면 대략적인 수치가 나온다. AdSense를 운영한다면 이 숫자가 예상보다 높을 가능성이 있다. Spur의 $200M은 시장이 이 문제를 얼마나 크게 보는지를 보여주는 숫자이기도 하고, 동시에 우리 같은 자동화 팀이 워크플로를 점검해야 할 시점이 가까워졌다는 신호이기도 하다.

원문: AI News & Artificial Intelligence | TechCrunch