• 목록

AI 크롤러가 홈페이지에 접근하는 과정은 단순히 “AI가 웹사이트를 읽는다”는 한 문장으로 설명하기 어렵다.

웹사이트와 자동화 프로그램 사이에서는 HTTP 요청이 발생하고, 크롤러는 자신을 식별하는 정보를 전달할 수 있다. 사이트는 robots.txt를 통해 크롤링 정책을 표현할 수 있으며, 서버나 웹 애플리케이션 방화벽(WAF, Web Application Firewall)은 실제 요청을 허용하거나 차단할 수도 있다.

따라서 AI 크롤러의 웹 접근을 이해하려면 크게 세 가지를 구분해야 한다.

식별(Identification)

누가 홈페이지에 접근하고 있는가?

정책(Policy)

그 크롤러에게 어떤 영역의 접근을 허용한다고 표시했는가?

통제(Enforcement)

실제 HTTP 요청을 서버까지 통과시킬 것인가?

이 세 가지는 서로 연결되어 있지만 같은 기술은 아니다.

가장 중요한 차이는 robots.txt에 특정 AI 봇을 차단한다고 작성하는 것과 서버에서 그 봇의 접속 자체를 기술적으로 차단하는 것은 다르다는 점이다.

■ 크롤러(Crawler)란 무엇인가?

크롤러(Crawler)는 웹페이지를 자동으로 방문하면서 정보를 발견하고 수집하는 프로그램이다.

검색엔진은 오래전부터 크롤러를 사용해왔다.

일반적인 과정을 단순화하면 다음과 같다.

URL 발견

↓

웹 서버에 HTTP 요청

↓

웹페이지 응답

↓

HTML 등의 콘텐츠 수집

↓

페이지 안의 링크 발견

↓

다른 URL 방문

↓

정보 저장 또는 색인

Googlebot 같은 검색엔진 크롤러가 대표적이다.

생성형 AI 환경에서도 웹 콘텐츠를 자동으로 발견하거나 수집하기 위해 크롤러가 사용될 수 있다.

다만 모든 AI 관련 자동화 프로그램이 같은 목적으로 움직이는 것은 아니다.

검색을 위한 크롤러가 있을 수 있고, AI 모델 개발을 위한 크롤러가 있을 수 있으며, 사용자의 요청에 따라 특정 페이지를 가져오는 fetcher나 에이전트도 존재한다.

따라서 AI 크롤러라는 표현은 하나의 동일한 프로그램 구조를 의미한다기보다 AI와 관련해 웹 콘텐츠에 자동 접근하는 프로그램을 넓게 지칭할 때 사용되는 경우가 많다.

■ 크롤러가 홈페이지에 들어오면 실제로 무슨 일이 일어날까?

웹사이트를 방문하려면 브라우저든 크롤러든 일반적으로 서버에 요청을 보내야 한다.

예를 들어 어떤 프로그램이 다음 페이지를 가져오려고 한다고 가정해보자.

https://example.com/article

프로그램은 해당 서버에 HTTP 요청을 보낸다.

개념적으로는 다음과 같은 흐름이다.

AI Crawler

↓

HTTP Request

↓

웹 서버 또는 CDN·WAF

↓

요청 허용

↓

HTML Response

↓

콘텐츠 분석

여기서 중요한 점은 AI가 홈페이지의 내용을 가져가기 전에 먼저 웹 서버와 통신하는 과정이 존재한다는 것이다.

웹사이트 입장에서는 사람이 사용하는 브라우저의 요청도 HTTP 요청이고 자동화 프로그램의 요청도 HTTP 요청이다.

따라서 자동화 트래픽을 관리하려면 들어오는 요청이 어떤 프로그램에서 발생했는지를 구분하는 과정이 필요하다.

■ User-Agent란 무엇인가?

HTTP 요청에는 요청을 보내는 프로그램에 대한 여러 정보가 포함될 수 있다.

그중 하나가 사용자 에이전트(User-Agent)다.

User-Agent는 브라우저나 크롤러 같은 클라이언트가 자신을 식별하기 위해 HTTP 요청에 전달할 수 있는 정보다.

예를 들어 일반 웹브라우저는 자신이 Chrome이나 Safari 같은 브라우저라는 정보를 User-Agent에 포함할 수 있다.

검색 크롤러도 자신을 나타내는 User-Agent를 사용할 수 있다.

AI 관련 크롤러 역시 서비스마다 별도의 User-Agent를 사용할 수 있다.

예를 들어 OpenAI는 검색 관련 웹 접근에 OAI-SearchBot을 사용하고, 모델 개발과 관련된 웹 접근에는 GPTBot을 별도로 안내하고 있다.

따라서 웹사이트는 User-Agent를 기준으로 서로 다른 크롤러에 서로 다른 크롤링 정책을 전달할 수 있다.

■ robots.txt란 무엇인가?

robots.txt는 웹사이트 운영자가 자동화된 크롤러에게 사이트의 어떤 영역을 크롤링할 수 있는지를 전달하기 위해 사용하는 파일이다.

이 방식은 로봇 배제 프로토콜(Robots Exclusion Protocol)에 기반한다.

robots.txt는 일반적으로 웹사이트의 최상위 경로에 위치한다.

예를 들어

https://example.com/robots.txt

와 같은 형태다.

크롤러는 사이트를 크롤링하기 전에 이 파일을 확인하고 자신에게 적용되는 규칙을 찾을 수 있다.

기본적인 구조는 다음과 같다.

User-agent

↓

어떤 크롤러에게 적용되는 규칙인가?

Disallow / Allow

↓

어떤 경로의 크롤링을 허용하거나 제한하는가?

즉 robots.txt는

누구에게

어떤 경로를

크롤링하도록 허용하거나 제한할 것인가

를 표현하는 구조라고 볼 수 있다.

■ robots.txt는 어떻게 특정 AI 크롤러를 구분할까?

robots.txt에서는 User-agent 필드를 이용해 특정 크롤러에 적용되는 규칙을 지정할 수 있다.

개념적인 예를 들어보자.

User-agent: ExampleBot

Disallow: /private/

이 규칙은 ExampleBot이라는 User-Agent를 사용하는 크롤러에게 /private/ 경로를 크롤링하지 말라는 정책을 전달한다.

반대로 사이트 전체에 대한 크롤링 정책을 설정하거나 특정 경로만 허용하는 구조도 가능하다.

AI 사업자가 검색용 크롤러와 학습 관련 크롤러에 서로 다른 User-Agent 토큰을 제공한다면 웹사이트 운영자는 robots.txt에서도 각 봇을 별도로 지정할 수 있다.

그래서 기술적으로는

Search Bot

→ 별도 정책

Training Bot

→ 별도 정책

처럼 목적이 다른 크롤러에 서로 다른 크롤링 규칙을 전달하는 것이 가능하다.

■ robots.txt는 보안 기능이 아니다

robots.txt를 이해할 때 가장 중요한 부분이다.

robots.txt에

Disallow

규칙을 작성했다고 해서 서버가 해당 HTTP 요청을 기술적으로 차단하는 것은 아니다.

robots.txt는 크롤러가 확인하고 따라야 하는 크롤링 정책을 표현하는 표준이다.

즉 개념적으로는 다음과 같다.

robots.txt

↓

“이 영역은 크롤링하지 마세요.”

반면 실제 접근 제어는

서버 또는 WAF

↓

“이 요청은 서버에 접근할 수 없습니다.”

에 가깝다.

로봇 배제 프로토콜을 표준화한 RFC 9309 역시 이 프로토콜이 접근 권한을 부여하기 위한 시스템이 아니라는 점을 설명하고 있다.

따라서 비공개 자료, 개인정보, 관리자 페이지처럼 외부에서 접근하면 안 되는 데이터를 robots.txt만으로 보호하는 것은 접근 통제와 다른 문제다.

■ robots.txt와 WAF는 무엇이 다른가?

웹 애플리케이션 방화벽(WAF, Web Application Firewall)은 웹 애플리케이션으로 들어오는 HTTP 요청을 검사하고 규칙에 따라 처리하는 보안 계층이다.

robots.txt와 WAF의 가장 큰 차이는 정책 전달과 실제 요청 통제에 있다.

robots.txt

→ 크롤러에게 사이트의 크롤링 정책을 전달한다.

WAF

→ 들어오는 HTTP 요청을 검사하고 실제로 허용하거나 차단할 수 있다.

예를 들어 어떤 자동화 프로그램이 robots.txt 규칙을 무시하고 계속 요청을 보낸다고 가정해보자.

robots.txt 자체가 그 프로그램의 네트워크 연결을 끊는 것은 아니다.

반면 서버나 WAF에서 해당 요청을 식별해 차단한다면 요청 단계에서 접근을 제한할 수 있다.

따라서 두 기술은 경쟁 관계라기보다 서로 다른 계층의 문제를 처리한다.

■ User-Agent만 보고 AI 봇인지 판단할 수 있을까?

User-Agent는 크롤러를 구분하는 중요한 정보지만 그 문자열만으로 요청의 실제 주체를 완전히 확인할 수 있는 것은 아니다.

이유는 단순하다.

HTTP 요청을 보내는 프로그램이 User-Agent 문자열을 설정할 수 있기 때문이다.

악의적인 프로그램이 자신의 User-Agent를 알려진 검색엔진 크롤러와 비슷하게 표시하는 것도 기술적으로 가능하다.

따라서 실제 봇 관리 시스템에서는 User-Agent 외의 정보를 함께 이용할 수 있다.

예를 들면

IP 주소

공개된 IP 범위

역방향 DNS(reverse DNS)

네트워크 특성

암호학적 인증

등이다.

즉

“나는 ExampleBot입니다.”

라는 문자열을 보내는 것과

“실제로 ExampleBot 운영자의 시스템에서 발생한 요청이다.”

를 확인하는 것은 다른 문제다.

■ Verified Bot이란 무엇인가?

Verified Bot은 알려진 자동화 서비스가 운영하는 봇이라는 것을 별도의 검증 방법으로 확인한 자동화 트래픽을 의미한다.

예를 들어 Cloudflare 같은 봇 관리 서비스에서는 공개된 IP 주소 목록, 역방향 DNS, Web Bot Auth 등의 방법을 이용해 알려진 봇을 확인할 수 있다.

이 과정의 목적은 단순히 User-Agent 문자열을 신뢰하는 것보다 실제 요청 주체를 더 정확하게 식별하는 데 있다.

구조를 단순화하면 다음과 같다.

HTTP Request

↓

User-Agent 확인

↓

IP·DNS·인증 정보 등 확인

↓

알려진 Bot인지 검증

↓

Bot Category 확인

↓

정책 적용

따라서 봇 접근 제어에서 식별과 차단은 별개의 단계다.

먼저 어떤 요청인지 알아야 그 요청에 어떤 정책을 적용할지 결정할 수 있다.

■ Reverse DNS는 봇 확인에 어떻게 사용될까?

일반적인 DNS 조회는 도메인 이름을 IP 주소로 변환한다.

예를 들어

example.com

↓

203.0.113.x

와 같은 방식이다.

역방향 DNS(reverse DNS)는 반대로 IP 주소를 기준으로 연결된 호스트 이름을 확인하는 방식이다.

일부 검색엔진이나 자동화 서비스에서는 공식 크롤러인지 확인하는 방법으로 DNS 정보를 이용할 수 있도록 안내한다.

다만 단순히 하나의 역방향 조회 결과만 확인하는 것보다 서비스 사업자가 공개한 검증 절차에 따라 확인하는 것이 중요하다.

결국 핵심은 User-Agent 문자열만 보는 것이 아니라 네트워크 수준의 정보까지 이용해 요청 주체를 검증할 수 있다는 것이다.

■ 크롤러와 Fetcher는 무엇이 다를까?

AI의 웹 접근을 이해할 때 크롤러(Crawler)와 fetcher를 구분할 필요가 있다.

크롤러는 일반적으로 웹을 자동으로 탐색하면서 페이지를 발견하고 수집한다.

Crawler

↓

URL 발견

↓

페이지 수집

↓

새로운 링크 발견

↓

다음 페이지 수집

반면 fetcher는 특정 요청에 따라 필요한 URL이나 데이터를 가져오는 역할을 의미할 수 있다.

User Request

↓

특정 정보 필요

↓

특정 URL Fetch

↓

정보 반환

생성형 AI에서는 이 차이가 특히 중요해지고 있다.

AI가 미리 웹을 돌아다니면서 정보를 수집하는 것과 사용자가 지금 특정 사이트의 내용을 확인해달라고 요청해서 AI가 해당 페이지에 접근하는 것은 목적과 시점이 다르기 때문이다.

실제로 일부 AI 서비스는 검색 크롤러와 사용자 요청 기반 fetcher에 서로 다른 이름과 정책을 사용하고 있다.

■ User-requested Agent는 일반 크롤러와 동일할까?

AI 에이전트가 사용자를 대신해 웹사이트에 접근하는 경우에는 전통적인 크롤러와 다른 문제가 발생한다.

예를 들어 사용자가 AI에게

“이 쇼핑몰에서 제품 가격을 확인해줘.”

라고 요청했다고 가정해보자.

AI가 실제 웹사이트에 접근한다면 이 요청은 웹사이트 입장에서는 자동화 트래픽이다.

하지만 접근 목적은 검색엔진처럼 웹 전체를 미리 색인하는 것이 아니라 특정 사용자의 현재 요청을 수행하는 것이다.

그래서 일부 서비스에서는 사용자 요청 기반 접근을 일반적인 크롤러와 별도로 분류한다.

이 차이는 AI 웹 접근 정책이 단순한

Bot / Human

구분만으로 설명하기 어려워지는 이유 중 하나다.

■ Search Bot과 Training Bot을 따로 제어할 수 있는 이유

검색용 봇과 학습용 봇이 별도의 User-Agent 또는 접근 시스템을 사용한다면 웹사이트는 두 접근에 서로 다른 정책을 표현할 수 있다.

예를 들어 한 AI 사업자가

SearchBot

과

TrainingBot

을 별도로 운영한다고 가정해보자.

사이트에서는 개념적으로

SearchBot

→ 검색을 위한 크롤링 정책

TrainingBot

→ 모델 개발을 위한 크롤링 정책

을 각각 표현할 수 있다.

이것이 가능한 이유는 검색과 학습이 웹 콘텐츠를 이용하는 서로 다른 과정이기 때문이다.

검색 시스템은 웹페이지를 발견하고 관련 정보를 검색하거나 연결하는 과정에 콘텐츠를 사용할 수 있다.

모델 학습은 데이터를 학습 과정에 이용해 모델의 동작이나 파라미터에 영향을 주는 과정이다.

두 과정은 목적과 처리 방식이 동일하지 않기 때문에 서비스 사업자가 별도의 크롤러나 제어 신호를 제공할 수 있다.

■ Google-Extended처럼 ‘크롤링’과 ‘이용’을 분리하는 경우도 있다

웹 콘텐츠 제어가 항상 특정 크롤러의 접속 여부만으로 이루어지는 것은 아니다.

Google의 Google-Extended가 대표적인 사례다.

Google-Extended는 별도의 HTTP User-Agent 크롤러라기보다 robots.txt에서 사용하는 제품 토큰(Product Token)이다.

Google은 이를 통해 이미 크롤링된 사이트 콘텐츠가 향후 Gemini 모델 학습과 일부 Gemini 관련 grounding에 사용되는 것을 사이트 운영자가 관리할 수 있도록 하고 있다.

동시에 Google은 Google-Extended 설정이 Google Search에서의 사이트 포함이나 순위에는 영향을 주지 않는다고 설명한다.

이 사례는 웹 콘텐츠 관리에서

콘텐츠를 가져올 수 있는가

와

가져온 콘텐츠를 특정 AI 목적으로 사용할 수 있는가

가 별개의 정책 문제로 표현될 수도 있다는 것을 보여준다.

■ AI 봇 접근 제어는 어떤 계층으로 이루어질까?

지금까지의 내용을 기술 구조로 정리하면 AI 봇 접근 제어는 크게 세 계층으로 구분할 수 있다.

첫 번째는 식별(Identification)이다.

누가 요청하고 있는지를 확인한다.

User-Agent

IP

DNS

Bot Authentication

등의 정보가 사용될 수 있다.

두 번째는 정책 표현(Policy Expression)이다.

해당 크롤러가 어떤 콘텐츠에 접근할 수 있는지 사이트 운영자의 정책을 표현한다.

대표적인 것이 robots.txt다.

세 번째는 실제 통제(Enforcement)다.

들어오는 요청을 실제로 허용하거나 차단한다.

서버 규칙

WAF

Bot Management

등이 여기에 해당할 수 있다.

전체 구조를 단순화하면 다음과 같다.

AI Bot

↓

HTTP Request

↓

Identification

누가 요청했는가?

↓

Policy

어떤 접근 규칙이 설정되어 있는가?

↓

Enforcement

실제 요청을 허용할 것인가?

↓

Web Server

↓

Content Response

이 세 계층을 구분하면 robots.txt와 WAF가 왜 서로 다른 기술인지도 이해하기 쉬워진다.

■ 웹 콘텐츠의 ‘접근’과 ‘이용’도 구분되고 있다

AI 환경에서는 웹사이트에 들어오는 요청을 허용할 것인지뿐 아니라 가져간 콘텐츠를 어떤 목적으로 이용하는지도 별도의 문제로 나타나고 있다.

개념적으로는 다음과 같은 단계가 존재할 수 있다.

Access

웹페이지에 접근할 수 있는가?

↓

Crawl

콘텐츠를 자동으로 수집할 수 있는가?

↓

Index / Search

검색이나 정보 탐색에 사용할 수 있는가?

↓

AI Input / Grounding

AI 답변을 만들 때 외부 정보로 사용할 수 있는가?

↓

Training

모델 학습이나 파인튜닝에 사용할 수 있는가?

이 단계들이 모든 AI 서비스에서 동일한 기술 구조로 구현되는 것은 아니다.

각 회사가 사용하는 크롤러, 정책, robots.txt 처리 방식과 콘텐츠 이용 조건도 서로 다르다.

하지만 현재 웹 콘텐츠 제어가 단순한 접근 허용 / 접근 차단만으로 설명되지 않고 접근 목적과 콘텐츠 이용 목적까지 구분하는 방향으로 세분화되고 있다는 점은 여러 서비스의 정책에서 확인할 수 있다.

■ AI 크롤러가 홈페이지에 접근하는 전체 과정

전체 구조를 하나로 정리하면 다음과 같다.

AI 서비스에서 웹 콘텐츠 필요

↓

Crawler / Fetcher가 URL 요청

↓

HTTP Request 발생

↓

User-Agent 등 클라이언트 정보 전달

↓

웹사이트 또는 인프라에서 요청 주체 식별

↓

robots.txt 등 크롤링 정책 확인

↓

WAF·Bot Management·서버 규칙 등 적용

↓

요청 허용 또는 차단

↓

허용된 경우 서버가 콘텐츠 응답

↓

HTML·텍스트 등의 콘텐츠 수집

↓

검색·사용자 요청·AI 입력·모델 개발 등 서비스별 목적에 따라 처리

실제 시스템은 서비스와 기술 구조에 따라 이보다 복잡할 수 있다.

그러나 핵심은 AI가 홈페이지를 읽기 전에 네트워크 요청, 봇 식별, 크롤링 정책, 접근 제어라는 여러 기술 계층을 거칠 수 있다는 것이다.

■ 결국 robots.txt·User-Agent·WAF는 무엇이 다른가?

세 개념은 AI 봇 접근 관리에서 자주 함께 등장하지만 담당하는 역할은 다르다.

User-Agent

“누구라고 표시하며 요청하고 있는가?”

를 식별하는 데 사용되는 HTTP 정보다.

robots.txt

“이 크롤러가 어떤 영역을 크롤링하도록 허용하거나 제한하는가?”

라는 사이트의 크롤링 정책을 표현한다.

WAF

“이 HTTP 요청을 실제로 통과시킬 것인가?”

를 규칙에 따라 판단하고 차단할 수 있는 보안 계층이다.

따라서 세 기술의 관계를 가장 간단하게 표현하면 다음과 같다.

User-Agent

↓

누구인가

robots.txt

↓

어디까지 크롤링하도록 정책을 표현했는가

WAF

↓

실제로 요청을 통과시킬 것인가

AI 검색, AI 에이전트, 모델 학습 등 웹 콘텐츠를 이용하는 목적이 다양해지면서 이 세 계층을 구분하는 것이 AI 크롤러의 웹 접근 구조를 이해하는 기본이 된다.

────────────────────

■ 주요 용어 정리

크롤러(Crawler)

웹페이지를 자동으로 방문하면서 URL과 콘텐츠를 발견하고 수집하는 프로그램이다.

AI 크롤러(AI Crawler)

AI 검색, 정보 수집, 모델 개발 등 AI 서비스와 관련된 목적으로 웹페이지에 자동 접근하는 프로그램을 넓게 지칭하는 표현이다.

Fetcher

특정 요청에 따라 필요한 URL이나 데이터를 가져오는 프로그램을 의미한다.

HTTP Request

브라우저나 크롤러 등의 클라이언트가 웹 서버에 특정 리소스를 요청하는 통신 메시지다.

사용자 에이전트(User-Agent)

HTTP 요청을 보내는 클라이언트가 자신의 종류나 신원을 나타내기 위해 전달할 수 있는 정보다.

robots.txt

웹사이트 운영자가 자동화된 크롤러에게 사이트의 크롤링 정책을 전달하기 위해 사용하는 파일이다.

로봇 배제 프로토콜(Robots Exclusion Protocol)

robots.txt를 통해 자동화된 클라이언트의 크롤링 범위를 표현하는 표준 규칙 체계다.

웹 애플리케이션 방화벽(WAF, Web Application Firewall)

웹 애플리케이션으로 들어오는 HTTP 요청을 검사하고 설정된 규칙에 따라 허용하거나 차단할 수 있는 보안 시스템이다.

봇 관리(Bot Management)

웹사이트로 들어오는 자동화 트래픽을 탐지·분류하고 정책을 적용하는 기술이나 시스템을 의미한다.

Verified Bot

알려진 서비스가 운영하는 봇인지 추가적인 검증 절차를 통해 확인한 자동화 트래픽을 의미한다.

역방향 DNS(Reverse DNS)

IP 주소를 이용해 연결된 호스트 이름을 조회하는 DNS 방식이다.

Grounding

생성형 AI가 답변을 만들 때 외부 정보나 특정 데이터 소스를 근거로 활용하는 과정을 설명할 때 사용되는 용어다.

────────────────────

■ 참고 자료

IETF / RFC Editor

RFC 9309 — Robots Exclusion Protocol

robots.txt의 동작 방식과 로봇 배제 프로토콜의 표준 규격.

OpenAI

Publishers and Developers FAQ

OAI-SearchBot과 GPTBot의 역할 및 웹사이트 크롤링 제어.

Google Search Central

Google Crawlers and Fetchers / Google-Extended

Googlebot의 크롤링 구조와 Google-Extended를 이용한 생성형 AI 관련 콘텐츠 이용 제어.

Anthropic

Web crawler 관련 공식 지원 문서

ClaudeBot, Claude-SearchBot, Claude-User의 역할과 robots.txt 처리 정책.

Perplexity

Perplexity Crawlers 공식 문서

PerplexityBot과 Perplexity-User의 역할 및 크롤러와 사용자 요청 기반 fetch의 차이.

Cloudflare Developers

Verified Bots / Bot Categories / AI Crawl Control / Managed robots.txt

봇 식별, 행동 분류, WAF 기반 접근 제어 및 AI 관련 크롤러 관리 구조.