필사 모드: 스크래퍼는 이제 수백만 개의 가정용 IP에서 온다 — residential proxy와 오픈소스 인프라의 소모전

• 들어가며 — IP가 더는 신원이 아니게 된 날
• residential proxy는 왜 차단이 안 되나
• AI 크롤러가 오픈소스 인프라를 가장 먼저 때렸다
• 방어 수단과 그 대가
• 마치며
• 참고 자료

들어가며 — IP가 더는 신원이 아니게 된 날

2026년 7월 10일, LWN의 Jonathan Corbet가 스크래퍼 상황 업데이트를 냈습니다. 2025년 초의 글에 이은 후속인데, 결론이 담담해서 더 무겁습니다 — 문제는 해결되기는커녕 계속 커졌고, LWN은 최근 역대 가장 강한 스크래퍼 공격을 받았다는 것입니다.

공개 인프라를 조금이라도 운영해 본 사람이라면 이 이야기가 남 일이 아닙니다. git 서버든, 위키든, 문서 사이트든, 개인 블로그든, 지금은 전부 표적입니다. 그리고 우리가 10년간 써 온 방어 공식 — IP로 레이트리밋하고, 나쁜 user-agent를 막고, 지역으로 거른다 — 이 거의 통하지 않습니다. 이유는 두 가지가 겹쳤기 때문입니다. residential proxy가 "IP = 신원"이라는 전제를 깼고, AI 크롤러 골드러시가 그 수요를 채웠습니다. 이 글은 왜 차단이 구조적으로 실패하는지, 그리고 방어책들이 하나같이 개방형 웹에 세금을 물린다는 사실을 정직하게 짚습니다.

residential proxy는 왜 차단이 안 되나

먼저 공격의 모양을 봅시다. Corbet가 보고한 최근 공격의 형태는 이렇습니다.

한 번의 공격에서 관측된 것 (LWN 보고, 2026-07-10)
- 몇 시간 동안 수백만 개의 서로 다른 IP
- 각 IP는 사이트를 많아야 두세 번만 두드림
- 봇은 대개 이미지·CSS는 받지 않음 (사람이 아니라는 신호)
- 하지만 그걸 알아챌 즈음, 그 IP는 이미 다시 등장하지 않음

여기서 핵심은 IP 하나하나가 진짜 가정용 회선이라는 점입니다. residential proxy는 평범한 사람들의 기기 — 휴대폰, 셋톱박스, 라우터 — 에 깔린 소프트웨어로, 중앙 제어 노드의 명령을 받아 페이지를 대신 받아 오고 결과를 돌려줍니다. 기기 주인은 대개 이 사실을 모릅니다.

공급원은 크게 둘입니다. 하나는 범죄형 봇넷으로, 멀웨어에 감염된 기기들이며 미디어 스트리밍 장치가 큰 매개체로 지목됩니다. 다른 하나는 "합법에 가까운" 사업자입니다. Corbet는 그중 가장 두드러진 예로 Bright Data를 듭니다 — 접근 제어와 트래픽 제한을 우회하는 능력을 대놓고 광고하고, "무료" VPN을 제공하는 대가로 사용자 기기를 통해 트래픽을 흘려보낼 권한을 가져갑니다. 이름이 알려지지 않은 다른 사업자들은 앱 개발자에게 SDK를 쥐여 주고, 사용자의 네트워크 연결을 되파는 대가로 돈을 지불합니다.

그래서 차단이 안 됩니다. 요청 하나하나가 그럴듯하게 위조된 user-agent를 달고 진짜 집주소에서 옵니다. 봇이라고 지문을 잡아냈을 때는 이미 그 IP가 은퇴한 뒤입니다. IP 평판, 레이트리밋, 지역 차단은 전부 "IP 신원이 안정적"이라는 가정 위에 서 있는데, 그 가정이 무너진 것입니다. 단속이 도움은 됩니다 — Google은 연초에 IPIDEA를, 7월 2일에는 FBI 등과 공조해 NetNut을 무너뜨렸고, 그때마다 LWN의 트래픽이 잠시 줄었습니다. 하지만 몇 달 뒤 공격은 되돌아왔습니다. 두더지잡기입니다.

AI 크롤러가 오픈소스 인프라를 가장 먼저 때렸다

한 가지는 정직하게 밝힙니다. LWN 글의 본문은 대체로 LWN 자신의 운영 경험입니다. 다만 이 파도를 가장 먼저, 가장 세게 맞은 곳은 오픈소스 인프라였고, 가장 유명한 방어 도구도 바로 거기서 태어났습니다.

그 도구가 Anubis입니다. Xe Iaso가 2025년 초, Amazon의 크롤러가 robots.txt를 무시하고 자신의 git 서버를 짓밟자 만들었습니다. MIT 라이선스의 리버스 프록시로, 방문자의 브라우저가 SHA-256 작업증명 퍼즐을 풀어야 페이지를 내주는 문지기입니다. 이후 Linux 커널 메일링 리스트 아카이브, SourceHut, FFmpeg, Wine, GNOME의 GitLab 같은 git 포지와 FOSS 프로젝트가 줄줄이 채택했습니다.

왜 하필 git 포지였을까요. blame, diff, 커밋마다의 blob 같은 동적 엔드포인트는 요청당 연산이 비쌉니다. 모든 파일의 모든 커밋을 훑는 크롤러는 그 자체로 병리적인 부하입니다. 게다가 자체 호스팅 오픈소스 프로젝트는 Cloudflare 엔터프라이즈를 살 예산이 없습니다. 그러니 가벼운 작업증명 벽이 합리적인 선택이었습니다.

문제는 이게 군비경쟁이라는 것입니다. Codeberg는 2025년 중반 이미 상당수 봇이 Anubis 챌린지를 푸는 법을 학습했다고 보고했습니다. LWN 글에 달린 한 독자 댓글도 같은 말을 합니다 — AI 크롤러가 git 엔드포인트를 두드리며 Anubis 검사를 그냥 통과하고 있고, 일부는 실제 풀브라우저를 쓰는 것 같다는 것입니다. 작업증명은 값싼 봇의 비용을 올리지만, 자금이 넉넉한 크롤러는 그냥 진짜 브라우저를 돌려 버립니다.

방어 수단과 그 대가

Corbet가 훑는 방어 수단을 정리하면 이렇습니다. 어느 것도 공짜가 아닙니다.

CAPTCHA 쪽 escalation은 씁쓸합니다. Corbet는 신호등 찾기, 퍼즐 조각 맞추기, 심지어 스페이스바를 누른 채 노래를 흥얼거리라는 생체 챌린지까지 열거합니다. 봇이 똑똑해질수록 사람에게 지우는 부담이 커진다는 뜻입니다. 정작 LWN 자신은 Anubis를 쓰지 않기로 했습니다. Corbet의 이유는 두 가지인데, 정상 방문자에게 성가신 지연을 주고, 스크래퍼가 결국 우회할 것이 "필연"으로 보이기 때문입니다. 대신 LWN은 사이트를 공격적으로 최적화하고 비싼 연산을 줄였으며, 익명 사용자와 로그인 사용자를 다르게 대합니다. 정직하고도 얄궂은 결과 하나 — 공격을 받는 동안의 응답 시간이 평소보다 오히려 더 빠를 때가 많다고 합니다.

하지만 근본 비용은 세 겹으로 남습니다. 첫째, 모두에게 물리는 세금입니다. 운영자는 이 장치를 세우고 유지해야 하고, 사용자는 마찰을 감수해야 합니다. 둘째, 부수 피해입니다. 방어를 세게 걸수록 정상 검색엔진과 Internet Archive까지 걸려듭니다. 그렇다고 거대 검색엔진만 허용 목록에 넣으면, Corbet의 표현대로 이미 우리를 잘 섬기지 못하는 그 독점을 더 굳혀 줄 뿐입니다. 셋째, 모든 방어는 한시적입니다. 지금 효과가 있어도, 그 효과가 사라진 다음을 지금 고민해 둬야 합니다.

마치며

여기엔 깔끔한 승리가 없습니다. residential proxy는 "IP는 곧 신원"이라는 오래된 전제를 깨뜨렸고, AI 골드러시는 그 위에 무한한 수요를 얹었으며, 모든 대응책은 개방형 웹의 일부를 해자로 바꾸는 거래입니다. Corbet의 걱정은 그래서 과장이 아닙니다 — 인터넷 전체가 "방어벽 뒤로" 물러나 버릴 위험이 실재합니다.

공개 인프라를 운영하는 사람에게 남는 실질적 교훈은 이렇습니다. IP 기반 방어는 죽었다고 가정하십시오. 마찰 비용을 예산에 넣으십시오. 그리고 이것이 해결할 문제가 아니라 계속 굴러가는 군비경쟁임을 받아들이십시오. 정직한 대응은 마법의 벽에 기대는 것이 아니라, 값싼 엔드포인트·캐싱·익명과 로그인의 분리처럼 우아하게 무너지도록 설계하는 쪽입니다. 벽은 언젠가 뚫립니다. 뚫려도 서 있도록 짓는 편이 낫습니다.

참고 자료

• An update on the scraper situation — Jonathan Corbet, LWN.net (2026-07-10)
• Anubis (software) — Wikipedia
• Anubis: Fighting off the hordes of LLM bot crawlers — The Register (2025-07-09)
• Anubis로 과도한 크롤링 막기 — Forgejo 논의 (Codeberg)