가짜 ClaudeBot이 우리 서버를 긁고 있다 — AI 크롤러 화이트리스트가 만든 새로운 공격 표면

미리 밝혀둡니다. 이 주제로 최근 30일간의 커뮤니티 반응을 뒤져봤는데, 레딧에서는 건질 만한 신규 스레드가 없었습니다. 그래서 이 글은 화제 중계가 아닙니다. 그동안 쌓인 기술 문서와 현장 사람들의 관측을 제 시각으로 엮은 쪽에 가깝습니다. 대신 주제 하나는 확실합니다. 지금 방치하면 나중에 비싼 값을 치릅니다.

어쩌다 우리는 봇에게 문을 열어줬나

2023년부터 분위기가 묘해졌습니다. AI 회사가 학습 데이터를 긁어가기 시작하자 사이트 운영자는 두 갈래로 갈렸습니다. 한쪽은 robots.txt로 전부 막았습니다. 다른 한쪽은 오히려 반겼고요.

반긴 쪽 논리는 단순했습니다. ChatGPT나 Claude가 답변에 우리 사이트를 인용해주면 그게 새 유입 경로가 된다는 겁니다. 검색 엔진 최적화(SEO) 자리를 ‘생성형 엔진 최적화’가 대체한다는 말도 여기서 나왔습니다. 그래서 많은 사이트가 ClaudeBot, GPTBot, PerplexityBot 같은 이름을 방화벽 예외 목록에 올렸습니다.

문제는 그 ‘이름’의 정체입니다. 대개는 HTTP 요청 헤더에 들어 있는 User-Agent 문자열 한 줄이 전부였습니다.

User-Agent는 자기소개일 뿐, 신분증이 아닙니다

개발자가 아닌 분들을 위해 잠깐 짚고 가겠습니다.

웹사이트에 접속하면 브라우저가 서버에 자기소개를 보냅니다. “나는 크롬 130 버전이고 윈도우에서 왔습니다” 같은 문장이죠. 이게 User-Agent입니다. 그런데 이건 그냥 텍스트 한 줄입니다. 검증하는 데도 없고 서명도 안 붙습니다. 발급해주는 기관 같은 건 당연히 없고요.

터미널에서 명령어 한 줄이면 누구나 자기가 ClaudeBot이라고 우길 수 있습니다. 과장이 아니라 진짜 한 줄입니다. 기술적 장벽이 0에 가깝습니다.

건물 로비에서 “저 배달원인데요” 한마디에 경비원이 그냥 통과시켜주는 상황을 떠올리면 됩니다. 배달 유니폼도 사원증도 안 봅니다. 말만 하면 됩니다. 게다가 우리는 그 로비에 “배달원은 프리패스"라는 안내문까지 붙여놨습니다.

공격자 입장에서 이건 너무 좋은 거래입니다

취약점 스캐너를 돌려본 분은 아실 겁니다. 대량 스캔의 최대 적은 레이트 리밋과 차단입니다. 같은 IP에서 초당 수십 번씩 이상한 경로를 찔러대면 WAF(웹 방화벽)가 바로 끊어버립니다.

그런데 AI 크롤러로 위장하면 이 제약이 상당 부분 풀립니다.

일단 화이트리스트에 올라 있으면 레이트 리밋을 통째로 건너뜁니다. 크롤러는 원래 많이 긁어가는 쪽이니 운영자가 아예 예외로 빼뒀을 가능성이 높습니다.

로그에서도 눈에 잘 안 띕니다. 액세스 로그에 ClaudeBot이 수천 줄 찍혀 있으면 대개 “아 크롤러 왔다 갔구나” 하고 넘어갑니다. 그 안에 /wp-admin/, /.env, /.git/config, /actuator/health 같은 경로가 섞여 있어도 말이죠.

사람 쪽 방어선도 헐겁습니다. 보안 담당자에게 “GPTBot 트래픽이 좀 많은데요"라고 보고하면 우선순위가 뒤로 밀립니다. “정체불명 스캐너가 붙었습니다"와는 체감 온도가 완전히 다르니까요.

AI 봇 위장 하나로 탐지 회피와 차단 우회를 동시에 해결하는 셈입니다. 공격자 입장에서는 들인 품에 비해 남는 게 많은 수법입니다.

그럼 진짜 크롤러는 어떻게 구분하나

다행히 방법은 이미 나와 있습니다. 문제는 아는 사람이 적다는 겁니다.

1단계: IP 대역 확인

주요 AI 회사는 자사 크롤러가 쓰는 IP 목록을 공개합니다. Anthropic도 OpenAI도 문서에 적어뒀습니다. JSON으로 받아갈 수 있게 해둔 곳도 있고요. User-Agent는 ClaudeBot인데 IP가 그 목록에 없다면 가짜입니다. 여기서 대부분 걸러집니다.

2단계: 역방향 DNS 조회

구글이 검색봇 검증에 오래전부터 써온 방식입니다. 접속한 IP를 거꾸로 조회해 도메인을 얻은 다음, 그 도메인을 다시 정방향으로 조회해 원래 IP가 나오는지 봅니다. 이걸 포워드-컨펌드 rDNS라고 부릅니다. IP 목록이 자주 바뀌는 서비스에 특히 쓸 만합니다.

3단계: Web Bot Auth

이쪽이 진짜 해법입니다. IETF에서 논의 중인 표준인데, 봇이 요청을 보낼 때 개인키로 서명을 붙입니다. HTTP Message Signatures 위에 얹은 구조입니다.

봇은 자기 공개키를 정해진 위치에 게시해두고 요청마다 서명 헤더를 답니다. 서버는 그 서명을 공개키로 검증합니다. 개인키가 없으면 서명을 만들지 못하니 User-Agent 위조 같은 건 애초에 성립하지 않습니다.

IP 목록을 관리하지 않아도 된다는 게 큽니다. 크롤러가 새 데이터센터로 옮기든 CDN을 갈아타든 서명은 그대로 유효합니다. Cloudflare가 이 방식을 밀고 있고 봇 운영사도 하나둘 붙는 중입니다.

오늘 당장 할 수 있는 것

표준이 자리 잡을 때까지 기다릴 이유는 없습니다. 지금 확인할 게 둘 있습니다.

하나는 내 서버 설정입니다. nginx든 Cloudflare든 방화벽이든 User-Agent 문자열만 보고 통과시키는 규칙이 있는지 찾아보세요. 있다면 IP 검증을 붙이거나 그 예외 규칙을 아예 없애는 편이 낫습니다. AI 크롤러한테 레이트 리밋 면제까지 줄 이유는 별로 없습니다.

다른 하나는 과거 로그입니다. 최근 몇 달치 액세스 로그에서 AI 봇 User-Agent를 단 요청만 뽑아 그 IP가 공식 대역에 들어 있는지 대조해보세요. 그다음 그 요청이 어떤 경로를 찔렀는지 보면 됩니다. .env나 .git, 관리자 페이지 경로가 나온다면 이미 당한 겁니다.

작업 자체는 어렵지 않습니다. 많은 조직이 이걸 안 하는 건 어려워서가 아니라 이런 위장이 가능하다는 걸 몰라서입니다.

결국 문제는 신뢰를 어떻게 증명하느냐입니다

AI 크롤러 위장은 새로 생긴 취약점이 아닙니다. User-Agent를 신분증처럼 대하던 오래된 습관이 AI 붐이라는 조건을 만나 위험해졌을 뿐입니다.

지난 2년간 웹은 AI에게 문을 활짝 열었습니다. 정작 문지기 세우는 일은 뒤로 미뤘고요. Web Bot Auth 같은 표준이 퍼지기 전까지 그 틈은 공격자 몫으로 남습니다.

오늘 로그를 한 번 열어보시죠. 지금 여러분의 서버가 누구에게 문을 열어두고 있는지, 그리고 그 상대가 정말 본인이 맞는지 확인할 방법은 있는지. 둘 중 하나라도 답이 막히면 거기서부터 손대면 됩니다.