AI 크롤러는 이미 와 있었다

추측이 아니라 서버 기록

AI에게 무언가를 물으면 답 아래에 출처가 붙는 일이 흔해졌고, 그 출처 목록에 들어가려면 무엇을 해야 하는지를 두고 조언이 쏟아지고 있다. 그러나 돌아다니는 조언의 대부분은 근거가 붙지 않은 추측이고, 광고 효과 측정에서 오래 되풀이되어 온 문제가 여기서도 그대로 나타난다. 무엇을 했더니 무엇이 되었다는 주장을 받치는 데이터가 없는 것이다.

다행히 이 질문은 비교적 쉽게 확인되는데, AI가 글을 가져가려면 그 글이 놓인 서버에 접속해야 하고 그 접속은 고스란히 기록으로 남기 때문이다. 그래서 이 사이트의 열나흘치(2026년 9월 30일부터 10월 13일까지) 접속 기록에서 AI 크롤러만 가려내 무엇을 얼마나 가져갔는지를 세어 보았다.

열나흘 동안 669건

이 기간에 확인된 AI 크롤러의 요청은 669건이었다. 자기 이름만 그렇게 밝힌 요청까지 합치면 더 많았는데, 각 업체가 공개한 주소 대역과 맞지 않는 것은 모두 걷어 낸 값이다.

가져간 범위는 넓었다. 사이트맵에 올라 있는 인사이트 글 스물두 편이 하나도 빠짐없이 수집되었고, 용어집 열여덟 쪽 가운데 열여섯 쪽이 함께 넘어갔다. 색인을 시작한 지 한 달이 채 되지 않은 사이트인데도 본문은 이미 거의 전부 읽힌 상태인 것이다.

눈에 띄는 것은 그 다음 숫자다. 669건 가운데 250건, 곧 37%가 본문이 아니라 robots.txt 와 sitemap.xml 두 파일에 쓰였다. 어느 글을 가져갈지 정하기 전에 무엇을 가져가도 되는지와 어디에 무엇이 있는지를 먼저 확인한다는 뜻이고, 결과적으로 이 두 파일이 본문보다 먼저 읽히는 입구 노릇을 하고 있는 것이다.

크롤러마다 다른 역할

위 표에서 전체 요청과 본문 요청의 비율은 크롤러마다 크게 갈린다. 메타의 크롤러는 271건 중 270건을 본문에 썼으니 사실상 글을 모으러 온 것이며, 반대로 오픈AI의 검색용 크롤러는 44번 들어와 본문을 한 쪽도 가져가지 않고 robots.txt 와 sitemap.xml 만 읽었다. 같은 회사의 GPTBot 이 본문 35쪽을 가져간 것과 견주면 두 크롤러의 역할이 나뉘어 있다고 판단된다.

그래서 'AI가 우리 글을 가져갔는가'라는 물음은 한 가지 답으로 정리되지 않는다. 학습용으로 모으는 쪽, 검색 색인을 만드는 쪽, 사용자의 질문이 들어온 순간에 한 쪽만 집어 오는 쪽이 각각 다르게 움직이며, 어느 쪽에 걸리고 싶은지에 따라 점검할 자리도 달라지는 것이다.

사람의 질문이 부르는 요청

앞의 669건은 사람과 무관하게 돌아다니는 수집이다. 그런데 사용자가 실제로 질문을 던진 순간에 그 답을 만들기 위해 들어오는 요청은 이름이 따로 붙어 있으며, 이 기간에 ChatGPT-User 로 기록된 두 건이 그것이었다. 가져간 쪽은 CPRP 용어 쪽과 첫 화면이었다.

두 건은 적지만 가리키는 바가 분명하다. CPRP 는 구글 서치콘솔에서도 이 사이트가 가장 많이 걸린 검색어였고(2026년 9월 28일 기준 노출 47회 가운데 11회), 사람이 검색으로 찾는 자리와 AI가 답을 만들려고 집어 오는 자리가 같았던 셈이다. 검색에 걸리게 하는 일과 AI 답변에 인용되게 하는 일이 전혀 다른 작업이라는 통념은 적어도 이 기록에서는 확인되지 않는다.

자칭을 믿을 수 없는 까닭

같은 기간 Perplexity-User 를 자칭한 요청도 두 건 있었으나 둘 다 위조였다. 구글 클라우드 벨기에 리전의 한 주소에서 온 것이었고, 찾은 것은 글이 아니라 /docker-compose.yaml 과 /__/firebase/init.json 이었다. 설정 파일을 뒤져 열린 구멍을 찾는 취약점 스캐너이며, 같은 주소가 Applebot 과 Google-Extended, 오픈AI의 검색용 크롤러까지 번갈아 자칭했다.

여기서 조심할 대목이 있다. 이 주소가 구글 클라우드에 속한다는 사실만으로는 진위를 가릴 수 없는데, 구글의 크롤러도 자사 클라우드에서 돌고 있고 동시에 누구나 같은 클라우드에서 서버를 빌릴 수 있기 때문이다. 결국 각 업체가 공개하는 크롤러 주소 목록과 맞춰 보는 수밖에 없으며, 이 확인을 건너뛰면 수집량을 두 배로 부풀려 읽는다.

효과가 없었던 조치

AI 크롤러를 위한 사이트 안내 파일로 llms.txt 를 두는 방식이 널리 권해지고 있고, 이 사이트도 데이터에서 자동으로 만들어 /llms.txt 로 내보내고 있다. 그런데 열나흘 동안 이 파일을 읽은 AI 크롤러는 한 곳도 없었고, 읽은 것은 브라우저를 자칭한 요청 여덟 건과 웹 데이터를 모아 파는 업체 한 곳이었다.

표준으로 굳으면 사정이 달라질 가능성은 있다. 다만 지금 시점에서 들일 품을 어디에 쓸지 정해야 한다면, 아직 아무도 읽지 않는 파일을 손보는 것보다 모든 크롤러가 예외 없이 먼저 확인하는 robots.txt 와 sitemap.xml 을 다듬는 쪽이 값을 한다고 판단된다.

실제로 값을 한 것

같은 기간의 기록을 놓고 보면, 수집이 일어나게 만든 조치는 특별한 기술이 아니었다.

첫째는 AI 크롤러를 막지 않겠다는 결정이다. robots.txt 에서 GPTBot 과 ClaudeBot, Google-Extended 를 차단하지 않았는데, 이 결정 하나가 나머지 모든 작업의 전제가 되며 막아 둔 상태에서는 아래의 어떤 조치도 효과를 내지 않는다.

둘째는 묻는 말에 첫 문단에서 답하는 글의 형태다. 용어집 쪽은 첫 문장이 곧 정의이고 그 아래로 공식과 계산 예시가 이어지는데, ChatGPT-User 가 집어 온 CPRP 쪽이 바로 그 구조였다. AI가 인용하기 좋은 글은 결론이 뒤에 숨어 있지 않은 글이다.

셋째는 한 주제에 한 주소를 쓰는 원칙이다. 열여덟 개 용어를 한 쪽에 몰아 두지 않고 쪽을 나눈 덕에 각각이 따로 수집될 수 있었고, 실제로 열여섯 쪽이 개별로 넘어갔다.

넷째는 공식과 표를 글자로 쓰는 일이다. 이미지 안에 들어간 수식은 검색엔진도 AI도 읽지 못하므로, 계산 결과까지 HTML 에 찍히도록 서버에서 계산해 내보내고 있다.

남는 문제

수집은 충분히 일어나고 있으나 그 다음이 아직 비어 있다. 같은 기간 서치콘솔에 잡힌 클릭은 2회였고, AI 답변에 인용되었다 해도 그것이 방문으로 돌아온 흔적은 어느 지표에서도 확인되지 않는다. 인용은 출처 표기로 끝나기 쉬우며, 답을 이미 얻은 사람이 원문까지 올 이유는 그 답이 불충분하다고 느껴질 때에만 생기는 것이다.

이 구조는 당분간 이어질 것으로 보인다. 그렇다면 공개 글을 두는 목적을 방문자 수에만 걸어 두기 어렵고, 누가 썼는지가 함께 인용되는 쪽으로 설계를 옮겨 가는 편이 합리적인 선택이 될 것으로 판단된다.