Summary
사용자가 웹사이트를 직접 방문하기보다 AI가 여러 정보를 수집하고 요약해 답변을 제공하는 비중이 커지면서 제로클릭이라는 키워드가 등장하게 되었습니다
기업은 AI 검색에 자사 콘텐츠가 노출되도록 검색 크롤러의 접근을 허용해야 하지만, 모든 AI 기반 자동화에 동일한 권한을 제공해서는 안 됩니다.
AI 트래픽은 검색, 학습, 비교, 거래, 공격 등 목적이 서로 다르므로 신원·접근 목적·요청량·비즈니스 영향을 기준으로 구분해야 합니다.
앞으로의 봇 관리는 단순 차단이 아니라, 자동화 트래픽별로 허용·속도 제한·추가 검증·차단 정책을 설계하는 방향으로 변화해야 합니다.
최근 AI 마케팅 업계에서 반복적으로 등장하는 키워드 중 하나는 제로클릭(Zero-click)입니다.
과거에는 고객이 검색 결과에서 링크를 클릭하고 기업의 웹사이트를 방문한 뒤, 여러 페이지를 살펴보며 제품이나 서비스를 비교했습니다. 그러나 생성형 AI 검색에서는 AI가 여러 출처를 바탕으로 정보를 요약하고 답변하기 때문에 사용자가 원문 웹사이트를 방문하지 않고도 탐색을 마칠 수 있습니다.
Bain & Company의 조사에 따르면 소비자의 약 80%가 전체 검색 중 최소 40%에서 AI 요약이나 제로클릭 결과에 의존하고 있으며, 이에 따라 기존의 유기적 웹 트래픽은 약 15~25% 감소할 수 있는 것으로 추정됐습니다.
이로인해 기업 입장에서는 새로운 과제가 생기게 되는데요,
AI가 우리 콘텐츠를 발견하고 답변에 인용할 수 있도록 접근을 허용해야 하지만, 모든 자동화 트래픽에 웹사이트와 API를 제한 없이 개방할 수는 없습니다.
마케터에게 제로클릭은 ‘어떻게 AI 답변에 우리 브랜드를 포함시킬 것인가’의 과제입니다. 하지만 서비스 운영자와 보안 담당자에게는 한 단계 더 복잡한 질문이 남습니다.
고객을 대신해 웹사이트를 방문하는 AI 에이전트를 정상 고객으로 봐야 할까요, 아니면 통제해야 할 봇으로 봐야 할까요?
제로 클릭은 웹사이트 방문자가 사라진다는 것일까?
제로클릭은 사용자의 직접 방문이 줄어드는 현상을 의미하지만, 인터넷상에서 기업 콘텐츠에 접근하는 요청 자체가 모두 사라지는 것은 아닙니다.
사용자가 AI에게 질문하면 AI 검색 서비스는 필요한 정보를 찾기 위해 웹페이지를 탐색하거나 검색 색인을 참고합니다. 앞으로는 단순한 정보 검색을 넘어 사용자를 대신해 상품을 비교하고, 재고를 확인하고, 예약이나 구매 과정을 지원하는 AI 에이전트의 활동도 늘어날 수 있습니다.
기존의 고객 여정을 비교하면 다음과 같습니다.
고객 여정 | 사람이 직접 수행할 때 | AI가 개입할 때 |
|---|---|---|
정보 탐색 | 검색 결과의 링크를 클릭 | AI가 여러 웹페이지와 검색 색인을 참고 |
제품 비교 | 각각의 제품 페이지를 방문 | 다수의 제품 정보를 자동으로 수집·비교 |
가격·재고 확인 | 필요할 때 한두 번 확인 | 반복적으로 가격·재고 데이터 조회 가능 |
예약·구매 | 사용자가 직접 정보를 입력 | 사용자를 대신해 양식이나 거래 절차 수행 가능 |
상태 확인 | 사용자가 직접 접속 | 주문·예약·배송 상태를 주기적으로 확인 |
따라서 제로클릭은 단순히 ‘웹사이트 트래픽이 사라지는 현상’이라기보다, 웹사이트에 접근하는 주체가 사람 중심에서 검색 크롤러와 AI 에이전트까지 확장되는 변화로 해석할 수 있습니다.
문제는 이 과정에서 발생하는 모든 자동화 요청이 기업에 동일한 가치를 제공하지 않는다는 점입니다.
AI 검색 크롤러와 AI 에이전트는 무엇이 다를까?
지금까지 기업은 자동화 트래픽을 주로 다음과 같이 구분했습니다.
검색엔진처럼 유용한 기능을 수행하는 Good Bot
스크래핑, 계정 공격, 매크로 등을 수행하는 Bad Bot
하지만 AI 환경에서는 이 두 분류 사이에 다양한 유형이 생기고 있습니다.
OpenAI도 검색 노출에 사용되는 OAI-SearchBot과 잠재적인 모델 학습에 사용되는 GPTBot을 별도로 운영합니다. 웹사이트 운영자는 검색 결과와 인용에 콘텐츠를 포함하려면 OAI-SearchBot의 접근을 허용할 수 있으며, 모델 학습 허용 여부는 GPTBot 정책을 통해 별도로 결정할 수 있습니다.
Cloudflare 역시 2026년 7월부터 AI 자동화 접근을 하나의 ‘AI Bot’으로 묶지 않고 Search·Agent·Training 행동으로 나눠 관리할 수 있도록 분류 체계를 확장했습니다.
자동화 트래픽 유형 | 주요 목적 | 기본 대응 방향 |
|---|---|---|
검색 크롤러 | 검색 결과 및 AI 답변에 콘텐츠 노출 | 허용하되 크롤링 정책 관리 |
학습 크롤러 | AI 모델 학습을 위한 데이터 수집 | 기업의 데이터 정책에 따라 결정 |
사용자 기반 AI 에이전트 | 정보 검색, 제품 비교, 사용자 요청 수행 | 신원과 요청량을 확인해 제한적 허용 |
거래형 AI 에이전트 | 로그인, 장바구니, 예약, 결제 과정 수행 | 인증 및 권한 검증 강화 |
가격·재고 스크래퍼 | 가격·재고·프로모션 반복 수집 | 빈도 제한 또는 차단 |
악성 자동화 | 계정 공격, 재고 선점, 매크로, API 남용 | 탐지 후 차단 |
즉, AI 기술을 사용한다는 사실만으로 정상 또는 악성 여부를 판단할 수는 없습니다.
누가 접근하는지, 무엇을 하려는지, 어느 정도의 자원을 사용하는지, 실제 비즈니스에 어떤 영향을 미치는지를 함께 봐야 합니다.
모든 AI 에이전트를 허용하면 어떤 문제가 생길까?
AI 검색에서 브랜드 노출을 확대하려면 콘텐츠가 검색 크롤러에 의해 발견될 수 있어야 합니다. 그러나 이를 이유로 모든 자동화 요청을 허용하면 웹사이트와 API 운영에는 새로운 부담이 발생할 수 있습니다.
콘텐츠와 데이터가 과도하게 수집될 수 있습니다
검색 노출을 위한 제한적인 크롤링과 가격·상품·기술 정보 전체를 반복적으로 수집하는 스크래핑은 목적이 다릅니다.
특히 상품 가격, 재고, 좌석, 프로모션처럼 실시간으로 변화하는 정보는 짧은 간격으로 반복 요청될 가능성이 높습니다. 이러한 접근은 검색 노출에 직접 기여하지 않으면서 서버와 데이터베이스에 지속적인 부하를 줄 수 있습니다.
정상적인 AI 에이전트도 시스템 부하를 만들 수 있습니다
악의가 없는 AI 에이전트라도 여러 사용자를 대신해 동시에 상품을 비교하거나 가격과 재고를 조회한다면 사람보다 훨씬 많은 요청을 발생시킬 수 있습니다.
예를 들어 한 명의 사용자는 몇 개의 상품만 확인할 수 있지만, AI 에이전트는 짧은 시간 동안 수십 개의 상품과 옵션, 재고 상태를 비교하기 위해 여러 API를 호출할 수 있습니다.
조회를 넘어 실제 비즈니스 흐름에 영향을 줄 수 있습니다
AI 에이전트가 단순히 콘텐츠를 읽는 단계에 머물지 않고 다음 영역에 접근하면 위험도는 달라집니다.
로그인 및 회원가입
상품 검색과 재고 조회
장바구니 담기
좌석과 객실 선점
예약 및 결제
주문·예약 변경
이러한 기능은 정상 고객에게도 제공되는 기능입니다. 따라서 요청 형식이 정상이라는 이유만으로 안전하다고 판단하기 어렵습니다.
AI 에이전트는 어떤 기준으로 구분해야 할까?
1. 접근 주체의 신원을 확인할 수 있는가?
첫 번째 기준은 해당 자동화 요청이 누구의 것인지 확인할 수 있는가입니다.
서비스 또는 운영 주체가 공개되어 있는가?
일관된 User-Agent를 사용하는가?
공식 IP 목록이나 인증 방법을 제공하는가?
robots.txt와 크롤링 지침을 준수하는가?
연락처와 사용 목적을 확인할 수 있는가?
Cloudflare는 검증된 봇과 에이전트의 조건으로 정직한 자기 식별, robots.txt 준수, 합리적인 요청 속도, 사이트 운영자의 정책을 우회하지 않는 행동을 제시합니다.
다만 신원이 확인된 봇이라고 해서 모든 URL과 API에 동일한 접근 권한을 부여해야 한다는 뜻은 아닙니다.
2. 접근 목적은 무엇인가?
동일한 기업이 운영하는 AI라도 목적에 따라 정책은 달라질 수 있습니다.
검색 결과와 답변 생성을 위한 접근인가?
모델 학습을 위한 데이터 수집인가?
사용자를 대신한 상품 비교인가?
실제 예약·구매를 수행하기 위한 접근인가?
가격·재고 정보를 반복 수집하기 위한 접근인가?
콘텐츠 페이지를 읽는 검색 크롤러와 결제 API를 호출하는 AI 에이전트는 같은 기준으로 처리하기 어렵습니다.
3. 시스템 자원을 얼마나 사용하는가?
자동화 요청의 정상성은 목적뿐 아니라 요청 방식에서도 판단해야 합니다.
초당 요청 수
동시 요청 수
동일 URL 및 API 반복 호출 횟수
세션 지속 시간
접근하는 페이지와 기능의 범위
시간대별 요청 패턴
정상 사용자 대비 탐색 속도
정상적인 검색 크롤러라도 시스템이 감당할 수 있는 범위를 넘어 접근한다면 속도 제한이 필요할 수 있습니다.
4. 비즈니스 결과에 어떤 영향을 주는가?
마지막으로 요청이 실제 서비스 운영에 미치는 영향을 확인해야 합니다.
브랜드 노출과 콘텐츠 발견에 기여하는가?
정상적인 비교와 구매 전환을 지원하는가?
실제 좌석이나 재고를 선점하는가?
분석 데이터와 수요 신호를 왜곡하는가?
정상 고객의 로그인·예약·결제를 방해하는가?
인프라와 외부 API 비용을 증가시키는가?
봇을 기술적으로 판별하는 것만으로는 부족합니다. 서비스와 비즈니스에 미치는 영향을 기준으로 정책을 결정해야 합니다.
허용·제한·검증·차단 정책은 어떻게 나눌까?
기업은 자동화 트래픽을 탐지한 뒤 하나의 조치만 적용하기보다 위험도와 목적에 따라 단계적으로 대응할 수 있습니다.
정책 | 적용 대상 | 운영 방법 |
|---|---|---|
허용 | 검증된 검색 크롤러, 정상 모니터링 봇 | 콘텐츠 영역 접근 허용 |
속도 제한 | 정상 목적이지만 요청량이 많은 크롤러·에이전트 | 초당 요청 수와 동시 요청 수 제한 |
접근 범위 제한 | 특정 정보만 필요한 AI 서비스 | 허용 URL·API 범위 지정 |
추가 검증 | 로그인·예약·구매에 접근하는 에이전트 | 인증, 토큰, 세션 검증 적용 |
대기·순차 처리 | 정상 요청이지만 시스템 처리량을 초과한 트래픽 | 처리 가능한 속도로 순차 진입 |
차단 | 신원 불명, 정책 우회, 비즈니스 로직 악용 | 실시간 탐지 후 접근 차단 |
여기서 중요한 점은 콘텐츠 접근 권한과 거래 권한을 분리하는 것입니다.
검색 크롤러가 블로그와 제품 설명을 읽을 수 있도록 허용했다고 해서 로그인, 장바구니, 예약, 결제 API까지 동일하게 열어둘 이유는 없습니다.
AI 에이전트 시대의 봇 관리는 단순히 차단 여부를 결정하는 작업이 아닙니다.
어떤 자동화 트래픽에 어느 수준의 접근 권한과 처리 속도를 제공할지 설계하는 작업입니다.
AI 에이전트 트래픽은 어떻게 관리해야 할까?
실제 운영에서는 다음과 같은 단계로 접근할 수 있습니다.
1단계. 현재 유입되는 자동화 트래픽을 파악합니다
먼저 어떤 봇과 에이전트가 어느 페이지와 API에 접근하고 있는지 확인해야 합니다.
단순히 전체 봇 비율만 확인하기보다 다음 항목을 함께 살펴봐야 합니다.
접근한 URL과 API
요청 횟수와 속도
세션별 탐색 흐름
로그인·장바구니·예약 접근 여부
응답 시간과 서버 자원 사용량
정상 사용자의 전환 과정에 미친 영향
2단계. 자동화 트래픽을 목적별로 분류합니다
검색, 학습, 비교, 거래, 공격 등 목적에 따라 카테고리를 나누고 각 유형에 필요한 접근 수준을 정의합니다.
3단계. 페이지와 API별 정책을 설정합니다
예를 들어 다음과 같이 구분할 수 있습니다.
블로그·가이드: 검색 크롤러 접근 허용
제품·가격 페이지: 제한적 접근과 요청량 관리
재고·좌석 API: 인증과 속도 제한
로그인·회원가입: 행동 분석과 추가 검증
장바구니·예약·결제: 세션 단위 분석과 동시 처리량 제어
4단계. 탐지 정책과 트래픽 제어를 분리합니다
어떤 요청을 허용할지 결정하는 것과, 허용된 요청을 얼마나 빠르게 처리할지는 서로 다른 문제입니다.
정상적인 AI 에이전트라도 시스템 처리량을 넘어서는 요청을 보내면 서비스 장애가 발생할 수 있습니다. 따라서 진입 자격 판단과 진입 속도 제어가 함께 필요합니다.
5단계. 정책을 지속적으로 조정합니다
새로운 AI 검색 서비스와 에이전트가 등장하면 기존 분류와 정책이 맞지 않을 수 있습니다.
신규 User-Agent 및 에이전트 확인
허용 트래픽의 실제 추천·전환 기여도 측정
과도한 API 요청과 자원 사용량 확인
오탐과 우회 패턴 분석
URL·API별 정책 재조정
제로클릭과 AI 에이전트 대응은 한 번 설정하고 끝나는 작업이 아니라 지속적인 운영 영역입니다.
제로클릭 이후에는 ‘발견 가능성’과 ‘접근 통제’를 함께 설계해야 합니다
제로클릭 시대에 기업은 AI 답변에 자사 브랜드와 콘텐츠가 포함될 수 있도록 준비해야 합니다.
하지만 AI에게 발견되기 위해 모든 자동화 접근을 허용하거나, 보안을 위해 모든 AI 봇을 차단하는 방식은 지속 가능하지 않습니다.
앞으로의 웹사이트와 API에는 다양한 자동화 주체가 접근하게 됩니다.
검색 결과와 AI 답변을 만드는 크롤러
모델 학습을 위한 수집 봇
고객을 대신해 정보를 비교하는 AI 에이전트
예약과 구매를 지원하는 거래형 에이전트
정상 에이전트로 위장한 스크래퍼와 악성 봇
따라서 기업은 다음 두 가지 질문에 동시에 답해야 합니다.
AI가 우리 브랜드와 콘텐츠를 발견할 수 있는가?
발견한 AI가 우리 서비스에서 무엇을, 어느 정도까지 할 수 있는가?
AI 검색 시대의 경쟁력은 콘텐츠를 많이 공개하는 것만으로 완성되지 않습니다.
AI에게 필요한 정보는 정확하게 제공하면서, 자동화 트래픽의 접근 권한과 처리 속도를 서비스 목적에 맞게 통제하는 운영 체계가 함께 필요합니다.
FAQ
Q1. AI 검색 크롤러를 차단하면 GEO 노출에 불리할 수 있나요?
검색과 답변 생성에 사용되는 크롤러가 콘텐츠에 접근하지 못하면 해당 페이지가 AI 검색의 요약이나 출처로 활용될 가능성이 낮아질 수 있습니다. 다만 검색용 크롤러와 모델 학습용 크롤러는 역할이 다르므로 robots.txt에서 각각 다른 정책을 설정할 수 있습니다. OpenAI의 경우 OAI-SearchBot은 검색 노출, GPTBot은 잠재적 모델 학습과 관련된 크롤러로 구분됩니다.
Q2. AI 에이전트는 모두 정상적인 봇인가요?
아닙니다. AI 기술을 사용한다는 사실만으로 정상 여부를 판단할 수 없습니다. 신원, 접근 목적, 요청 빈도, 접근하는 URL과 API, 거래 및 시스템에 미치는 영향을 함께 분석해야 합니다.
Q3. 정상적인 AI 에이전트도 서버 장애를 일으킬 수 있나요?
가능합니다. 악의가 없더라도 짧은 시간에 많은 상품, 가격, 재고 또는 예약 API를 호출하면 서버와 데이터베이스에 부담을 줄 수 있습니다. 따라서 정상 에이전트에도 합리적인 요청량 제한과 트래픽 제어 정책이 필요합니다.
Q4. robots.txt만으로 AI 에이전트 트래픽을 모두 관리할 수 있나요?
robots.txt는 크롤러에 사이트 운영자의 접근 정책을 전달하는 수단이지만, 모든 자동화 도구가 이를 준수하는 것은 아닙니다. 또한 로그인·장바구니·예약·결제처럼 실제 서비스 기능에서 발생하는 자동화 활동은 행동 기반 탐지와 API 보호가 함께 필요합니다.
Q5. BotManager와 NetFUNNEL은 어떤 차이가 있나요?
BotManager는 자동화 트래픽의 행동과 위험도를 분석해 악성 봇과 매크로를 탐지하고 대응하는 역할을 합니다. NetFUNNEL은 정상적으로 허용된 요청이 시스템 처리량을 초과하지 않도록 진입 속도와 동시 처리량을 제어합니다. 즉, BotManager가 ‘누구를 들여보낼 것인가’를 판단한다면 NetFUNNEL은 ‘얼마나 빠르게 들여보낼 것인가’를 관리합니다.