이제 독자는 AI 어시스턴트입니다

저는 1년 가까이 제 사이트의 트래픽을 잘못 읽고 있었습니다. 사람 방문자 수, 검색 클릭, 방문 깊이만 들여다봤고, 로그에 찍힌 봇 기록은 걸러내야 할 잡음으로 취급했습니다. 그러다 어느 날 그 숫자를 실제로 더해 봤습니다. 대표적인 하루 동안 제 사이트는 사람 방문자 약 301명을 맞이했고, AI 에이전트로부터는 약 19,800건의 요청을 받았습니다. 이 에이전트들은 학습 데이터를 긁어가고 있던 것이 아니었습니다. 가장 큰 단일 출처는 압도적인 차이로 ChatGPT였고, 바로 그 순간 누군가의 질문에 답하려고 제 페이지를 실시간으로 가져가는 중이었습니다. 제 진짜 독자는 조용히 방문을 멈춘 상태였습니다. 그들은 어시스턴트를 통해 제 글을 읽고 있었고, 그 어시스턴트는 자신이 답해 주는 사람들보다 약 66배 더 자주 제 글을 읽고 있었습니다. {.answer-block}

요약(TL;DR)

• 최근의 대표적인 하루 동안 제 사이트에는 사람 방문자 약 301명과 AI 에이전트 요청 약 19,800건이 들어왔습니다. 에이전트 요청량의 7일 평균은 하루 약 19,850건이고, 사람 방문자의 28일 평균은 하루 약 301명입니다. 비율로는 66 대 1에 가깝습니다.¹
• 이 에이전트 트래픽의 대부분은 학습용 크롤러가 아닙니다. 사용자의 질문에서 시작된 실시간 조회입니다. ChatGPT-User가 하루 약 13,100건, Claude-User가 약 2,300건으로, 사람이 방금 어시스턴트에게 무언가를 물었다는 이유만으로 페이지를 가져가는 에이전트들입니다.¹²³
• 각 업체의 공식 문서가 이 경계선을 분명하게 긋고 있습니다. OpenAI는 “ChatGPT-User는 웹을 자동으로 크롤링하는 데 사용되지 않습니다”라고 못 박습니다. Anthropic은 Claude-User가 “사용자가 Claude에게 질문할 때” 페이지에 접근한다고 설명합니다. Cloudflare는 이를 아예 Agent(에이전트)라는 별도의 동작 유형으로 정리해, 학습(Training)·검색(Search)과 구분합니다.²³⁴
• 모두가 걱정하는 학습용 크롤러는 이에 비하면 반올림 오차 수준이었습니다. 같은 날 GPTBot은 55건, ClaudeBot은 212건을 요청했습니다.¹²³
• 실무적으로 달라지는 지점은 이렇습니다. 이제 콘텐츠는 점점 더 ‘답변을 만드는 재료’로 소비됩니다. 독자는 여러분의 페이지에 한 번도 도착하지 않는 사람이고, 실제로 그 글을 읽는 존재는 질문이 던져진 시점에 페이지를 가져가는 어시스턴트입니다. 이 변화는 무엇을 측정할지, 무엇을 쓸지, 그리고 ‘트래픽’이라는 말의 의미 자체를 바꿔 놓습니다.

모든 것을 다시 보게 만든 숫자 하나

이 사이트는 개인 사이트입니다. 기술 가이드와 에세이를 10개 언어로 싣고, 하루 방문자는 수백 명 수준입니다. 준수하지만 화제성 있는 규모는 아닙니다. 몇 달 동안 제 대시보드는 검색 클릭과 체류 시간에 대한 깔끔한 이야기를 들려줬고, AI 에이전트 항목은 제가 머릿속으로 “크롤러, 무시”라고 이름 붙여 둔 구석에 그대로 놓여 있었습니다.

그 이름표가 실수였습니다. Cloudflare 엣지 로그를 사람 방문자 분석과 같은 화면에 놓고 보니, 두 숫자의 격차는 비교가 무의미할 정도였습니다. 사람은 28일 평균 하루 약 301명. AI 에이전트는 7일 평균 하루 약 19,850건이었고, 출처별로 쪼개 본 대표적인 하루에는 19,785건이었습니다.¹ 두 기간 모두 안정적이라 어느 쪽을 고르든 비율은 크게 달라지지 않습니다. 19,785 대 301은 65.7 대 1이고, 변동이 더 적은 7일 평균으로는 65.9 대 1입니다. 66 대 1이라고 부르겠습니다.

여기서 곧바로 정당한 반론이 나옵니다. 다른 이야기를 하기 전에 먼저 인정하고 넘어가겠습니다. 두 숫자의 단위가 같지 않습니다. 301은 순 방문자 수이고, 19,800은 요청 수입니다. 사람 한 명의 방문도 여러 건의 페이지 요청으로 이어집니다. 그러니 이것은 “독자가 66배 많다”는 뜻이 아닙니다. “어시스턴트가 제 페이지를 요청하는 빈도가, 사람이 읽으러 찾아오는 빈도보다 약 66배 높다”에 더 가깝습니다. 그래도 정직하게 비교해도 결론의 방향은 같습니다. 흥미로운 부분은 정확한 배수가 아니라, 그 에이전트 요청의 정체가 무엇으로 밝혀졌는가이기 때문입니다.

여러분이 걱정하던 그 크롤러가 아닙니다

기본적인 가정은, 저를 포함해서, AI 에이전트 트래픽이 벽처럼 쌓여 있다면 그건 학습용 스크레이퍼가 다음 파운데이션 모델을 위해 콘텐츠를 빨아들이고 있다는 뜻이라는 것입니다. robots.txt 수정 열풍을 일으킨 바로 그 공포죠. 하지만 제 로그가 보여 주는 것은 그게 아니었습니다.

같은 날의 요청을 user-agent별로 나눠 보면 이렇습니다.¹

위의 두 줄을 다시 보시기 바랍니다. ChatGPT-User와 Claude-User를 합치면 그날 약 2만 건의 에이전트 요청 가운데 1만 5천 건이 넘습니다. 둘 다 학습용 크롤러가 아니며, 이 구분은 제 해석이 아닙니다. 각 업체가 문서에 평이한 문장으로 적어 둔 내용입니다.

OpenAI의 봇 문서는 ChatGPT-User를 “ChatGPT 및 Custom GPTs에서 이루어지는 특정 사용자 동작”에 사용한다고 밝히고, “사용자가 ChatGPT나 CustomGPT에 질문하면 웹 페이지를 방문할 수 있다”고 설명한 뒤, “ChatGPT-User는 웹을 자동으로 크롤링하는 데 사용되지 않습니다”라고 단정적으로 못 박습니다.² 대량 학습 크롤러는 GPTBot이라는 별개의 에이전트이며, “생성형 AI 파운데이션 모델 학습에 사용될 수 있는 콘텐츠”를 크롤링한다고 설명돼 있습니다.² 제 사이트의 그 대표적인 하루에 GPTBot은 55건을 요청했습니다. ChatGPT-User는 1만 3천 건을 요청했습니다.

Anthropic도 똑같은 선을 긋습니다. Claude-User는 “Claude AI 사용자를 지원합니다. 사용자가 Claude에게 질문하면 Claude-User 에이전트로 웹사이트에 접근할 수 있습니다.” 학습용 크롤러인 ClaudeBot은 “학습에 기여할 수 있는 웹 콘텐츠를 수집해 생성형 AI 모델의 유용성과 안전성을 높이는 데 도움을 줍니다.”³ 구조는 동일합니다. 사용자 질문에서 출발한 에이전트가 학습용 크롤러를 압도합니다. 2,274 대 212입니다.

웹의 상당 부분 앞단에 자리 잡고 있으면서 특정 업체를 편들 이유가 없는 Cloudflare도 바로 이 구분을 공식화했습니다. 검증된 봇 분류 체계는 AI 봇을 동작 방식에 따라 별개의 범주로 나눕니다. Agent는 “사람을 대신해 페이지를 방문하는, 사용자 지시에 따른 에이전트”, Search는 “검색 색인이나 RAG 데이터베이스를 구축하기 위한 크롤링”, Training은 “모델을 학습하거나 파인튜닝하기 위한 크롤링”입니다.⁴ 결정적인 구분 기준은 사람의 지시 여부입니다. 학습용 봇이나 검색 봇은 지속적인 데이터셋을 만들기 위해 자율적으로 크롤링합니다. Agent의 조회는 사람의 상호작용에 의해 요청 단위로 발생하며, 하나의 구체적인 질문에 실시간으로 답하기 위한 것입니다. 제 트래픽은 압도적으로 세 번째에 해당합니다.

실시간 조회가 실제로 의미하는 것

이 동작 방식을 잠시 곱씹어 볼 필요가 있습니다. 머릿속 모델이 완전히 바뀌기 때문입니다. ChatGPT-User가 제 페이지에 접근할 때, 그 앞에는 이런 순서가 있었습니다. 어떤 사람이 어시스턴트를 열어 질문을 입력했고, 어시스턴트는 답을 만들기 위해 제 페이지를 읽을 가치가 있다고 판단했고, 실시간으로 페이지를 가져와 필요한 부분을 추출한 뒤 답변을 구성했습니다. 그 사람은 답을 얻었습니다. 그리고 제 이름도, 제 레이아웃도, 다른 글도, 페이지 하단에 조용히 적어 둔 제 앱 소개도 한 번도 보지 못했을 가능성이 큽니다.

그래도 그 사람은 독자입니다. 다만 제가 영영 만나지 못하는 독자일 뿐입니다. 어시스턴트는 배달원이고, 제 분석 도구는 하루 1만 3천 번 오가는 그 배달 차량만 보면서 그것을 잡음이라고 불러 왔습니다.

AI와 콘텐츠를 둘러싼 소란 아래 조용히 흐르는 이야기가 바로 이 뒤집힘입니다. 학습 크롤러 논쟁은 모델이 언젠가 한 번 여러분의 글을 가중치 속으로 삼키느냐 마느냐의 문제입니다. 그 논쟁도 중요하지만, 지금 살아 있는 독자층을 이해하고 싶다면 그건 잘못된 관측 대상입니다. 살아 있는 독자는 Agent 조회를 통해 끊임없이 도착하고, 그 하나하나는 바로 지금 일어나고 있는 사람의 상호작용에서 발사됩니다. 제 로그에 남은 모든 ChatGPT-User 조회의 출발점에는, 제 페이지가 답할 수 있는 무언가를 어시스턴트에게 물어본 사람이 있습니다. 질문 하나가 여러 번의 조회를 부르기도 하고, 어떤 조회는 누구에게도 노출되지 않은 채 끝나기도 하지만 말입니다. 하루 1만 5천 건의 조회 대 300명의 사람 방문이라는 규모가 말해 주는 바는 분명합니다. 제 콘텐츠가 실제로 닿는 사람들은 대부분 어시스턴트 건너편에 있습니다.

사이트를 측정하는 방식이 달라집니다

어시스턴트가 실재하는 독자층이라는 사실을 받아들이는 순간, 계기판에서 가장 중요한 계기 하나가 통째로 비어 있다는 걸 알게 됩니다. 표준적인 분석 도구는 읽기가 여러분의 페이지 위에서 일어난다는 전제로 만들어져 있습니다. 세션, 스크롤 깊이, 체류 시간, 화면 아래쪽에 배치한 전환 요소. 사람이 Claude를 통해 그 글을 읽을 때 이 중 어느 것도 작동하지 않습니다. 어시스턴트는 스크롤하지 않고, 전환하지 않으며, 정의상 매번 곧바로 이탈합니다. 페이지 위 참여도만으로 콘텐츠를 평가한다면, 가장 빠르게 자라는 독자층은 통계적으로 보이지 않습니다.

여기서 세 가지 조정이 따라옵니다. 저는 셋 다 실행하기 시작했습니다.

첫째, AI 에이전트 요청 로그를 보안 지표가 아니라 독자 지표로 다루는 것입니다. 저는 이제 페이지별 ChatGPT-User와 Claude-User 요청량을 사람 순 방문자와 똑같은 방식으로 추적합니다. 그 수치가 “어시스턴트가 누군가에게 답하기 위해 이 페이지를 얼마나 자주 쓰는가”에 가장 가까운 대리 지표이기 때문입니다. 에이전트가 가장 많이 가져가는 페이지가 사람이 가장 많이 클릭하는 페이지와 늘 같지는 않고, 그 간극 자체가 제가 그동안 버려 온 콘텐츠 신호였습니다.

둘째, 페이지 위에서 벌어지는 순간만을 위해 최적화하는 일을 그만두는 것입니다. 검색으로 도착한 사람이 훑어보도록 쓴 페이지와, 질문에 답하는 어시스턴트가 깔끔하게 추출해 갈 수 있도록 쓴 페이지는 같지 않습니다. 두 번째 역할은 상단에 놓인 명확하고 그 자체로 완결된 답변, 모호하지 않은 주장, 주변 장식 없이도 그대로 들어올릴 수 있는 구조에 보상을 줍니다. 제가 모든 글의 첫머리에 직접적인 답변 블록을 두는 이유가 이것입니다. 그 블록은 독자를 위한 것인 만큼 배달원을 위한 것이기도 합니다.

셋째, 유입 경로 추적이 더 어려워졌다는 사실을 받아들이고, 대신 그것이 드리우는 그림자를 측정하는 것입니다. 저는 Claude-User 조회 뒤에 있는 사람을 볼 수 없습니다. 대신 볼 수 있는 것은 2차 신호입니다. 어시스턴트를 거쳐 이미 제 글을 알게 된 상태로 사이트에 도착하는 사람들, 즉 답변을 읽고 원문이 궁금해져 눌러 들어온 소수의 흐름입니다. 조회량에 비하면 실개천 수준입니다. 하루 9명 대 1만 5천 건이니까요. 하지만 그것은 보이지 않는 독자층에서 드러난 끄트머리이고, 좋은 답변 재료가 되는 일이 결국 사람을 원문으로 되돌려 보내는지를 정직하게 보여 주는 점수판은 바로 그 추세입니다.

그 아래에 놓인 전략

이 모든 것을 독립 사이트의 종말로 읽고 싶은 유혹이 있습니다. 어시스턴트가 콘텐츠를 노천 채굴하듯 캐가고, 대신 답해 주고, 사람은 자기가 붙잡는다는 이야기죠. 실제로 그런 일이 벌어지기도 합니다. 하지만 그 구도는 너무 납작합니다. 그 조회가 무엇을 선별하고 있는지를 빠뜨리기 때문입니다.

어시스턴트가 여러분의 페이지를 가져가는 이유는, 질문이 던져진 그 시점에 그 구체적인 질의에 대해 그 페이지가 이용 가능한 최선의 출처라고 판단했기 때문입니다. 이건 키워드로 순위를 다투던 예전의 검색 게임이 아닙니다. 답변 엔진이 정확해야 할 때 손을 뻗는 대상이 되는 일입니다. 화폐는 백링크나 키워드 밀도가 아니라, 충분히 많은 사람이 묻는 무언가에 대해 명백하게 옳고, 그 옳음을 그대로 인용해 갈 수 있게 만들어져 있는가입니다. 정확하고, 구체적이고, 최신인 페이지는 조회됩니다. 이미 알려진 내용을 얇게 다시 쓴 페이지는 조회되지 않습니다. 모델은 그 일반적인 부분을 이미 알고 있고, 스스로 안정적으로 담고 있지 않은 것이 필요할 때만 밖으로 손을 뻗기 때문입니다.

그래서 Agent 트래픽이 만들어 내는 유인은, 모처럼, 진짜로 좋은 페이지를 만드는 일과 방향이 맞습니다. 순위 알고리즘에 맞춰 설계된 페이지가 아니라, 실제 질문에 답하기 위해 가져갈 만한 가치가 있는 페이지 말입니다. 측정 가능한 보상은 “사람이 도착해서 스크롤했는가”에서 “어시스턴트가 이 페이지를 최선의 출처로 판단하고 사람에게 읽어 줬는가”로 옮겨 갔습니다. 저라면 두 번째 쪽에서 경쟁하겠습니다.

결론적인 입장

어시스턴트를 주요 독자층으로 대하십시오. 숫자상 이미 그렇기 때문입니다. 그리고 방문만큼이나 조회를 염두에 두고 만드십시오. 여러분의 페이지에 있는 사람은 이제 소수 독자이고, 대개 어시스턴트가 답한 뒤에도 원문이 궁금할 만큼 관심을 가진 사람입니다. 다수 독자는 어시스턴트 자신입니다. 사람의 질문이 필요로 할 때마다 여러분의 글을 실시간으로 가져가고, 분석 도구에는 한 번도 흔적을 남기지 않는 존재입니다. 이건 차단해야 할 크롤러 문제가 아닙니다. 이해해야 할 유통 경로이고, 지금 시점에서 대부분의 콘텐츠 사이트가 가진 가장 큰 경로입니다.

앞으로 몇 년의 사이트는 하나가 아니라 두 개의 숫자로 측정됩니다. 눈에 보이는 트래픽, 즉 페이지 위의 사람들이 있고, 추론해야만 하는 트래픽, 즉 영영 만나지 못할 사람들에게 답하기 위해 여러분의 글을 읽는 어시스턴트들이 있습니다. 제 경우 이 비율은 볼 수 없는 독자 쪽으로 약 66 대 1입니다. 여러분의 비율도 대시보드가 말해 주는 것보다는 이 숫자에 가까울 거라고 생각합니다. 그 항목들은 제가 놔뒀던 바로 그 구석에, 잡음이라는 이름표를 단 채 그대로 앉아 있을 테니까요.

핵심 정리

• AI 에이전트 요청을 잡음이 아니라 독자로 세십시오. 제 사이트에서는 사람의 페이지 도착 대비 약 66 대 1로 많았고, 배수 자체보다 그 구성이 더 중요합니다.¹
• 에이전트 트래픽의 대부분은 학습이 아니라 사용자 질문에 따른 실시간 조회입니다. ChatGPT-User와 Claude-User는 사람이 방금 어시스턴트에게 무언가를 물었기 때문에 페이지를 가져갑니다. 각 업체가 이를 문서로 밝히고 있고, Cloudflare는 별개의 Agent 동작으로 분류합니다.²³⁴
• 학습용 크롤러는 작은 일부입니다. 사용자 요청 기반 에이전트가 1만 5천 건을 넘긴 날, GPTBot과 ClaudeBot을 합친 요청은 300건 미만이었습니다.¹²³
• 페이지 위 분석은 가장 빠르게 자라는 독자층을 놓칩니다. 어시스턴트는 스크롤하지도 전환하지도 않으므로 참여도 지표에서는 Agent 독자층이 보이지 않습니다. 대신 페이지별 에이전트 조회량을 대리 지표로 추적하십시오.
• 조회되도록 쓰십시오. 명확하고 그 자체로 완결된 답을 앞에 두고, 구체적이고 정확하고 최신인 상태를 유지하십시오. 답변 엔진은 질문 시점에 최선의 출처라고 판단한 페이지를 가져가며, 이는 키워드 최적화보다 진짜로 옳은 쪽에 보상을 줍니다.

자주 묻는 질문

ChatGPT-User와 GPTBot은 무엇이 다른가요?

GPTBot은 OpenAI의 학습용 크롤러로, 파운데이션 모델 “학습에 사용될 수 있는” 콘텐츠를 수집합니다. ChatGPT-User는 사람이 ChatGPT에 질문했을 때 페이지를 가져가는, 사용자 지시 기반 에이전트입니다. OpenAI는 이 에이전트가 “웹을 자동으로 크롤링하는 데 사용되지 않는다”고 명시합니다.² 제 로그에서 두 값은 자릿수 자체가 다릅니다. GPTBot이 55건을 요청한 날 ChatGPT-User는 13,128건을 요청했습니다.¹

AI 어시스턴트가 제 웹사이트를 실시간으로 읽고 있나요?

흔한 질문에 답이 되는 콘텐츠를 제공하고 있다면 거의 확실히 그렇습니다. ChatGPT-User, Claude-User, Perplexity-User 같은 에이전트는 사람이 어시스턴트에게 그 페이지가 답할 수 있는 무언가를 물었을 때 실시간으로 페이지를 가져갑니다.²³ 이들은 학습용 크롤러와도, 검색 색인 봇과도 다르며, 제 사이트에서는 에이전트 트래픽의 지배적인 형태입니다.

이것은 SEO와 어떻게 다른가요?

전통적인 SEO는 사람이 클릭할 검색 결과 페이지에서 상위에 오르도록 최적화합니다. 답변 엔진 조회는 어시스턴트가 답변을 구성하기 위해 가져가 읽는 출처가 되도록 최적화하는 일이며, 사람이 사이트를 아예 방문하지 않는 경우도 많습니다. 보상의 축이 순위 신호에서, 모델이 정확해야 할 때 여러분의 페이지로 손을 뻗을 만큼 정확하고 구체적이고 최신인가로 옮겨 갑니다.

robots.txt로 AI 에이전트를 차단해야 할까요?

충분히 고민할 만한 선택이지만, 뭉뚱그려 결정하지 말고 동작 유형별로 판단하십시오. 학습용 크롤러(GPTBot, ClaudeBot) 차단은 여러분의 콘텐츠가 앞으로의 모델을 학습시키는지에 영향을 줍니다. 사용자 지시 기반 에이전트(ChatGPT-User, Claude-User) 차단은 어시스턴트가 그 페이지로 사람에게 실시간으로 답할 수 있는지에 영향을 주며, 많은 사이트에서 이쪽이 이제 가장 큰 독자층입니다. 알아 둘 만한 단서가 하나 있습니다. 사용자 지시 기반 에이전트는 학습용 크롤러보다 robots.txt를 존중해 온 이력이 약합니다. 따라서 robots.txt 차단은 실시간 조회보다 학습 쪽에 더 확실하게 작동하는 지렛대이고, 실시간 조회는 엣지 규칙 쪽이 더 믿을 만한 통제 수단일 수 있습니다. Cloudflare의 분류 체계가 이 범주들을 정확히 갈라 놓은 것도 서로 다르게 다룰 수 있게 하기 위해서입니다.⁴

제 사이트에서 볼 수 없는 독자층은 어떻게 측정하나요?

실시간 조회 뒤에 있는 사람을 직접 귀속시킬 수는 없으므로, 대신 두 가지를 측정하십시오. 하나는 엣지 로그에서 뽑은 페이지별 AI 에이전트 요청량으로, 어시스턴트가 각 페이지를 얼마나 자주 쓰는지에 대한 대리 지표입니다. 다른 하나는 어시스턴트를 거쳐 이미 글을 알게 된 상태로 도착하는 소수의 사람 방문 흐름으로, 보이지 않는 독자층이 드리운 눈에 보이는 그림자입니다.

출처