웹이 문을 걸어 잠그기 시작했다
요즘 웹사이트 운영자들의 가장 큰 골칫거리는 AI 크롤러예요. 크롤러가 뭐냐면, 웹페이지를 자동으로 돌아다니며 내용을 긁어 가는 프로그램이에요. 검색엔진도 원래 크롤러로 동작하는데요, 생성형 AI 붐 이후 학습 데이터를 모으려는 크롤러가 폭발적으로 늘었어요.
피해는 생각보다 커요. 2025년에는 SourceHut 같은 오픈소스 코드 호스팅 서비스와 여러 오픈소스 프로젝트의 Git 서버가 크롤러 트래픽 때문에 장애를 겪었어요. 위키미디어 재단은 멀티미디어 콘텐츠 다운로드 대역폭이 50%나 늘었는데, 주범이 크롤러라고 밝혔고요. 결국 많은 사이트가 문을 걸어 잠그기 시작했어요. Cloudflare는 2025년 7월부터 새로 가입한 도메인에서 AI 크롤러를 기본으로 차단하고, 크롤링에 돈을 받는 'Pay per crawl' 모델까지 내놨어요.
TechPolicy.Press에 실린 이번 글의 메시지는 제목 그대로예요. 열린 웹을 망가뜨리는 방식으로는 정작 나쁜 봇을 막을 수 없다는 거죠. 왜 그런지 하나씩 뜯어볼게요.
지금 쓰이는 봇 차단 기술들
robots.txt는 가장 오래된 방법이에요. 사이트 루트에 User-agent: GPTBot / Disallow: / 같은 규칙을 적어 두면 '이 크롤러는 들어오지 마세요'라고 알리는 건데요, 문제는 이게 신사협정이라는 거예요. 강제력이 전혀 없어서 지킬 마음이 없는 봇은 그냥 무시해요.
User-Agent나 IP 차단도 쉽게 우회돼요. User-Agent는 문자열 하나만 바꾸면 되고, IP 차단은 주거용 프록시(residential proxy)로 피해 가요. 일반 가정집 인터넷 회선 수백만 개를 빌려 쓰는 서비스라서, 막으려다 보면 진짜 사용자까지 함께 막혀요.
CAPTCHA는 이미 한계에 다다랐어요. 2023년 한 연구에서는 봇이 사람보다 CAPTCHA를 더 빠르고 정확하게 푼다는 결과까지 나왔거든요. 결국 고생하는 건 사람뿐이에요.
작업 증명(Proof of Work) 챌린지는 최근 오픈소스 진영에서 많이 쓰는 방식이에요. Anubis 같은 도구가 대표적인데요, 방문자의 브라우저에게 잠깐 계산 문제를 풀게 해서 대량 크롤링 비용을 높이는 원리예요. 사람 한 명에게는 1~2초면 끝나는 일이지만, 수백만 페이지를 긁는 봇에게는 큰 부담이 되죠. 다만 저사양 기기나 자바스크립트를 끈 환경에서는 불편해져요.
기기 증명(Attestation)은 가장 논란이 큰 방향이에요. 검증된 기기와 브라우저인지를 하드웨어 수준에서 확인하는 방식인데요, 구글이 2023년에 Web Environment Integrity라는 제안을 냈다가 거센 반발에 철회했어요. 이게 퍼지면 리눅스 사용자, 직접 만든 브라우저 사용자, 오래된 스마트폰 사용자가 웹에서 밀려날 수 있거든요.
핵심 딜레마: 나쁜 봇은 규칙을 지키지 않는다
비유하자면 이래요. 아파트에 도둑이 든다고 출입구에서 신분증 검사를 시작했다고 해볼게요. 주민도 택배기사도 손님도 모두 불편해지는데, 정작 도둑은 담을 넘어 들어와요. 모든 방어 장치가 규칙을 지키는 쪽에 비용을 물리는 구조인 거예요. 정교한 공격자는 진짜 크롬 브라우저를 자동으로 조종하고, 주거용 IP를 쓰고, 사람처럼 마우스를 움직이면서 그냥 통과해요.
그 결과 웹은 점점 '검증된 대형 플랫폼만 드나들 수 있는 공간'으로 바뀌어요. 새로 시작하는 검색엔진, 인터넷 아카이브 같은 보존 프로젝트, 데이터를 수집하는 연구자, 스크린리더를 쓰는 시각장애인이 먼저 피해를 봐요. 동시에 누가 웹에 들어올 수 있는지 정하는 권한이 Cloudflare 같은 소수 게이트키퍼에게 몰리게 되죠.
업계는 어디로 가고 있나
흥미로운 건 방향이 '나쁜 봇 잡기'에서 '좋은 봇이 스스로 신분을 증명하게 하기'로 바뀌고 있다는 점이에요. Cloudflare의 Web Bot Auth는 HTTP 메시지 서명(RFC 9421)으로 봇이 자기 신원을 암호학적으로 증명하게 해요. IETF에서는 AI Preferences 워킹그룹이 꾸려져서, 콘텐츠를 AI 학습에 써도 되는지 표시하는 표준을 논의하고 있고요. 2025년에는 Cloudflare가 Perplexity를 두고 robots.txt를 피해 가는 '스텔스 크롤링'을 한다며 공개적으로 비판하기도 했어요.
그런데 서명에도 한계가 있어요. 착한 봇을 화이트리스트에 올리는 데는 유용하지만, 애초에 서명을 하지 않는 나쁜 봇을 막아 주지는 못하거든요.
한국 개발자에게 주는 시사점
서비스를 운영한다면 무작정 막기 전에 로그부터 보세요. 어떤 경로에 트래픽이 몰리는지 파악하고, 검색이나 Git diff처럼 비싼 엔드포인트에만 행동 기반 속도 제한을 거는 게 사이트 전체를 막는 것보다 훨씬 효과적이에요. 차단 설정을 켤 때는 네이버 검색 크롤러(Yeti) 같은 국내 검색엔진이나 접근성 도구까지 막히지 않는지 꼭 확인하세요. CAPTCHA는 웹 접근성 측면에서도 장벽이 될 수 있어요.
크롤러를 만든다면 User-Agent에 이름과 연락처를 분명히 적고, robots.txt를 지키고, 요청 사이에 간격을 두세요. 국내에서도 AI 서비스용 데이터 수집이 늘고 있는데, 좋은 봇으로 남는 게 길게 보면 서비스 신뢰를 지키는 길이에요.
마무리
나쁜 봇은 규칙을 지키지 않아요. 그래서 규칙을 강화할수록 피해는 규칙을 지키는 사람에게 돌아가요. 여러분의 서비스는 AI 크롤러를 어떻게 다루고 있나요? 차단했다면, 그 대가를 일반 사용자가 치르고 있지는 않나요?
🔗 출처: Hacker News