검색엔진과 AI 크롤러를 안내하는 robots.txt 사용법

웹사이트를 개발하고 배포하다 보면 한 번쯤 robots.txt라는 파일에 대해서 듣게 됩니다. 저도 처음에는 검색 엔진이 크롤링할 때 필요한 정보를 제공해주는 수단으로 이해했었죠.

하지만 개인 블로그를 운영하면서 느낀 건, 이 작고 단순한 파일이 생각보다 많은 역할을 한다는 겁니다. 검색 결과에 어떤 페이지가 보이고 안 보이는지, 트래픽 낭비를 줄일 수 있는지 등, 의외로 중요한 결정들이 이 한 장짜리 텍스트 파일에 달려 있습니다.

특히 요즘처럼 데이터 학습을 위해서 AI 크롤러가 우후죽순 등장하는 시대에는, 단순한 SEO 도구를 넘어 창작자의 콘텐츠 보호 수단으로 robots.txt를 다시 바라보게 됩니다.

이 글에서는 robots.txt의 기본 개념부터 문법, 한계, 그리고 AI 시대에 맞는 전략적 사용법까지 정리해보려고 합니다. 저처럼 개인 블로그를 운영하시는 분들께 특히 도움이 되길 바랍니다.

robots.txt란?

웹사이트 루트(예: https://example.com/robots.txt)에 위치한 이 작은 텍스트 파일 하나가, 사실 검색엔진 크롤러에게 보내는 “여기서부터 여기까지만 와 주세요”라는 안내 표시입니다. 개발자로서 보면 “크롤러는 어디까지 와서 무엇을 훑어야 하나?”라는 질문에 답해주는 일종의 크롤링 안내서이죠.

기본적으로, 검색엔진 봇이 처음 사이트에 접속하면 먼저 /robots.txt 파일을 찾아 읽습니다. 그 안에서 User‑agent(어떤 봇인지), Disallow(접근 금지 경로), Allow(접근 허용 경로), Sitemap(사이트맵 위치) 등의 토큰이 보이면, 해당 규칙을 해석해서 다음 동작을 결정하죠.

예컨대:

User‑agent: *
Disallow: /drafts/

이렇게 지정했다면, 모든 봇에게 /drafts/ 이하 경로는 “크롤링하지 말아 주세요”라는 신호입니다.

개발자 관점에서 주의해야 할 것은: “크롤링 제한”이지 “검색엔진 결과에서 완전히 사라짐”은 아니다라는 점입니다. 즉, 크롤링을 막아도 인덱스에 남을 가능성이 있고, 반대로 noindex 메타 태그를 써도 크롤링은 허용돼 있을 수 있습니다. 이 둘을 혼동하면 “왜 내 글이 검색에 안 나와?” 혹은 “왜 숨겼는데 노출돼?”라는 미스터리를 만나게 될 수 있어요.

robots.txt의 문법

robots.txt 파일은 복잡해볼 수도 있지만 문법은 아주 간단합니다. 5가지 지시문(directive)으로 이루어져있습니다.

User‑agent: <봇이름 또는 *>

어떤 크롤러(봇)에게 규칙을 적용할지 지정합니다. 별표를 사용하면 방문자에게 모든 사용자 에이전트가 어떤 장치나 브라우저에서도 콘텐츠에 접근할 수 있음을 표시하게 됩니다.

Disallow: <경로 또는 *>

해당 봇이 접근하지 말아야 할 경로를 지정합니다. 루트(/)를 적으면 사이트 전체 차단이 됩니다.

Allow: <경로>

Disallow에 의해 차단된 범위 안에서 예외적으로 허용할 때 쓰입니다 (주로 Googlebot의 고급 규칙 등).

Sitemap: <URL>

사이트맵 XML 파일 위치를 알려줘서 크롤러가 구조를 좀 더 효율적으로 이해하도록 돕습니다.

Crawl‑delay: <초 수>

(지원하는 봇에 한해) 동일한 서버에 대한 요청 빈도를 제한할 수 있는 옵션입니다.

예를 들어, 다음과 같은 robots.txt 파일을 함께 해석해볼께요?

User‑agent: Googlebot
Disallow: /private/
Allow: /

Sitemap: https://www.example.com/sitemap.xml

이 설정은 구글 검색 엔진의 크롤러인 Googlebot을 상대로하고 있으며, /private/ 경로를 제외한 모든 경로의 크롤링을 허용한다는 의미입니다.

또한 사이트맵 위치도 제공하고 있습니다.

하나의 robots.txt 파일에 여러 규칙이 있으면 더 구체적인 규칙이 우선됩니다. 예를 들어, User-agent: *에 대한 한 규칙보다 User-agent: Googlebot에 대한 규칙이 우선합니다.

참고로 robots.txt 파일 안에 봇은 무시하지만 사람은 읽을 수 있는 주석을 넣을 수도 있습니다. # 기호 뒤에 나오는 모든 문자는 주석 처리가 됩니다.

예를 들어, 위키피디아의 robots.txt 파일을 열어보면 다음과 같은 주석으로 시작한다는 것을 알 수 있습니다.

# robots.txt for http://www.wikipedia.org/ and friends
#
# Please note: There are a lot of pages on this site, and there are
# some misbehaved spiders out there that go _way_ too fast. If you're
# irresponsible, your access to the site may be blocked.
#

User Agent의 종류

과거에는 우리의 웹사이트를 크롤링하는 User Agent가 주로 검색 엔진이었습니다. 국내외 대표적인 검색 엔진의 크롤러의 이름을 정리해보면 다음과 같습니다.

회사	User-agent 이름	설명
Google	Googlebot	일반 웹 검색
	Googlebot-Image	이미지 검색
	Googlebot-News	뉴스 검색
Bing (Microsoft)	Bingbot	Bing 검색
	MSNBot	과거 사용되던 크롤러
Yahoo	Slurp	Yahoo 검색
DuckDuckGo	DuckDuckBot	DuckDuckGo 검색
Baidu (중국)	Baiduspider	바이두 검색
Yandex (러시아)	YandexBot	얀덱스 검색
Naver (한국)	Yeti	네이버 검색
Daum (한국)	Daumoa	다음/카카오 검색

최근에는 데이터 학습을 위해서 AI 업체에서도 열심히 전세계의 웹사이트를 크롤링하고 있습니다. 대표적인 AI 업체의 크롤러 이름은 다음과 같습니다.

회사	User-agent 이름	설명
OpenAI	GPTBot	ChatGPT 학습용 크롤러
	ChatGPT-User	사용자의 실시간 검색 요청 기반 수집
Anthropic	AnthropicBot	Claude AI 학습용
Perplexity	PerplexityBot	Perplexity AI 크롤러
Google AI	Google-Extended	Gemini(Bard) 학습 데이터 수집 제어용
Meta (페이스북)	facebookexternalhit	링크 미리보기용 (학습 목적 아님)
Amazon	Amazonbot	Alexa 및 AI 서비스용 가능성 있음
Common Crawl	CCBot	공개 크롤링 데이터 (AI 학습에 자주 활용됨)
ByteDance (TikTok)	Bytespider	ByteDance AI 학습용 (중국)
Apple	Applebot	Siri, Spotlight 등
You.com	youBot	You.com 검색 및 AI 크롤러

robots.txt의 한계

robots.txt는 강제성이 있는 법률 조항이 아니라 자율적으로 따르는 약속입니다. 대부분의 검색 엔진 봇은 이 신호를 존중하지만, 악성 크롤러나 무차별 스크래퍼(scraper)에게는 무시당할 수 있어요. 따라서 보안 수단으로 robots.txt를 여기는 것은 위험합니다.

또한 robots.txt을 통해 크롤링을 막았다고 해서 자동으로 검색 결과에서 해당 페이지가 사라지는 것은 아닙니다. 실제로 Disallow로 막은 페이지가, 다른 외부 링크 등을 통해 검색 엔진 인덱스에 남아있을 수 있어요.

반대로 noindex 메타 태그는 인덱스에서 제외하라는 강한 신호지만, 그것을 봇이 읽기 위해서는 먼저 그 페이지에 접근해야 하므로, 만약 robots.txt로 접근까지 막았다면 noindex가 작동하지 않습니다.

정리하자면,

• Disallow → 크롤링 차단
• noindex → 인덱스에서 제거 요청 이 둘은 목적이 다르고, 서로 보완적으로 사용하는 것이 바람직합니다.

또 하나 주의사항: robots.txt는 인증(로그인)된 사용자 전용 콘텐츠를 숨기기 위한 용도로는 적합하지 않습니다. 인증 레이어 없이 공개되어 있는 상태라면 단순히 Disallow만으로는 봇이 접근을 막지 못할 수 있어요. 이럴 땐 서버 측에서 인증 혹은 nofollow/noindex 등의 추가 조치가 필요합니다.

AI 시대에 robots.txt

최근 들어 AI 학습용 크롤러들이 활발해지면서, robots.txt를 그저 SEO 차원의 도구로만 보는 시대는 지나가고 있습니다. 예컨대 User Agent가 GPTBot, AnthropicBot, PerplexityBot 등과 같은 이름의 봇들이 실제로 웹을 돌아다니며 학습 데이터를 수집하고 있고, 일부 사이트 운영자는 이들에 대해 별도의 규칙을 설정하는 일이 늘고 있어요.

회사에서든 개인적으로 웹사이트를 운영자하고 계시다면 다음과 같은 부분을 고려해보실 필요가 있습니다.

• AI 학습용 크롤러의 접근을 허용할 것인가, 차단할 것인가?
• 콘텐츠(특히 기술 블로그나 전문 아티클)를 공개적으로 AI 학습에 활용되더라도 괜찮다는 입장이라면 허용 전략을, 내 글을 학습 데이터로 쓰는 건 원치 않는다면 차단 전략을 생각해야 합니다.
• 기존 검색엔진 + AI 봇을 구분하는 규칙 구성 예컨대:

User‑agent: *
Disallow:

User‑agent: GPTBot
Disallow: /

User‑agent: AnthropicBot
Disallow: /

이렇게 하면 다른 크롤러는 허용하되, 특정 AI 봇만 차단하는 균형적 접근이 가능해집니다.

Content Signal의 등장

AI 학습이 저작권 침해로 이어지는 일들이 늘어나면서 robots.txt에서 제공하는 기존 지시문으로는 부족하다는 인식이 생기고 있습니다. 기존 지시문으로는 어떤 크롤러가 허용되고 사이트의 어느 부분에 대한 접근 권한이 있는지 지정할 수 있지만 콘텐츠에 액세스한 후에 무엇을 할 수 있는지 알려줄 수 없기 때문입니다.

많은 크롤러와 일부 봇은 robots.txt 파일을 준수하지만, 모든 크롤러가 준수하는 것은 아닙니다. 더욱이 전통적인 robots.txt는 크롤러의 접근만 제어할 뿐, 크롤링된 데이터가 어떻게 사용되는지까지는 제어할 수 없었습니다. 예를 들어, 검색 엔진의 색인 목적과 AI 모델 학습 목적을 구분할 방법이 없었던 것이죠.

이 문제를 해결하기 위한 여러 시도 중에 대표적으로 Cloudflare는 2025년 9월 Content-Signal이라는 새로운 지시문을 제안하였습니다. 이 지시문을 활용하여 우리는 콘텐츠 신호 정책을 robots.txt에 명시할 수 있습니다. 즉, 콘텐츠에 대해 수행할 수 있는 작업과 수행할 수 없는 작업에 대한 선호도를 표현할 수 있도록 허용합니다.

콘텐츠 신호 정책은 세 가지 신호를 정의합니다:

• search: 검색 인덱스를 구축하고 검색 결과를 제공하는 것 (예: 하이퍼링크와 짧은 발췌문 반환). 단, AI 생성 검색 요약은 포함되지 않습니다.
• ai-input: 콘텐츠를 하나 이상의 AI 모델에 입력하는 것 (예: RAG(검색 증강 생성), grounding, 생성형 AI 검색 답변을 위한 실시간 콘텐츠 활용)
• ai-train: AI 모델을 학습하거나 파인튜닝하는 것

각 신호에 대해 yes 또는 no 값을 지정할 수 있으며, 명시하지 않은 신호는 중립을 의미합니다.

User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /

위 설정은 모든 봇에게 접근을 허용하고 있지만, 이 콘텐츠는 검색 색인용으로는 사용 가능하지만 AI 모델 학습용으로는 사용하지 말아달라는 의사 표현입니다. ai-input 신호를 명시하지 않았으므로, 이에 대한 선호를 표현하지 않은 것입니다.

더 세밀하게 제어하고 싶다면 다음과 같이 설정할 수 있습니다:

User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

이렇게 하면 검색과 실시간 AI 답변 생성은 허용하되, 모델 학습에는 사용하지 말아달라는 의사를 명확히 전달할 수 있습니다.

Cloudflare는 콘텐츠 신호 정책의 사람이 읽을 수 있는 버전도 robots.txt 파일의 주석으로 포함할 것을 권장합니다:

# As a condition of accessing this website, you agree to abide by the following content signals:
#
# (a) If a content-signal = yes, you may collect content for the corresponding use.
# (b) If a content-signal = no, you may not collect content for the corresponding use.
# (c) If the website operator does not include a content signal for a corresponding use,
#     the website operator neither grants nor restricts permission via content signal
#     with respect to the corresponding use.

User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /

즉, 이 지시문은 크롤링 허용 여부를 넘어서, 크롤링된 콘텐츠가 어떻게 활용되기를 원하는지에 대한 운영자의 선호를 명시하는 것이죠.

아쉽게도 아직까지 모든 크롤링 봇이 Content-Signal 지시문을 따르고 있지는 않은 상황입니다. Cloudflare가 2025년 제안한 비교적 새로운 지시문으로, 공식 표준(RFC)에 포함된 것은 아닙니다. 이는 강제성이 있는 법률 조항이 아니라 자발적으로 따르는 신호 체계입니다.

그럼에도 불구하고 점점 더 많은 사이트와 크롤러가 이 신호에 주목하고 있고, 향후 업계 표준으로 자리 잡을 가능성도 있습니다. 실제로 Perplexity, Brave 등 일부 기업은 Content-Signal을 일부 지원한다고 밝히기도 했습니다.

콘텐츠 신호 정책에 대한 좀 더 자세한 내용은 http://contentsignals.org를 참고바랍니다.

robots.txt 예시

이제 “내 블로그는 어떻게 설정할까?” 고민하는 운영자들을 위해 세 가지 전략 예시를 들어보겠습니다.

🟩 개방적 전략 (모두 허용)

User-agent: *
Allow: /

모든 크롤러가 사이트의 모든 부분에 접근할 수 있도록 완전히 개방하는 웹의 가치와 철학을 반영하는 설정입니다. AI 시대 전부터 아마도 가장 흔하게 사용되고 있는 웹사이트에서 많이 사용하던 설정입니다.

자유롭게 인덱싱과 크롤링을 허용하기 때문에 유입 트래픽을 최대화할 수 있는 장점이 있습니다. 하지만 AI 학습 차원에서 콘텐츠가 대량 수집될 가능성 있어서 주의가 필요한 설정이기도 합니다.

🟧 균형적 전략 (검색 허용, AI 학습 차단)

User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /

User‑agent: GPTBot
Disallow: /
User‑agent: AnthropicBot
Disallow: /

검색 엔진을 통합 유입은 중요하지만 AI 학습에 콘텐츠가 활용되는 것은 원치 않는 개인 블로그나 콘텐츠 사이트에서 많이 쓰이는 설정입니다. 위에서 다룬 Content-Signal 지시문을 통해서 AI 모델 학습용으로 콘텐츠가 활용되는 것을 명시적으로 거부하고 있습니다.

🟥 보수적 전략 (AI 포함 전면 차단)

User‑agent: *
Disallow: /

User‑agent: GPTBot
Disallow: /
User‑agent: AnthropicBot
Disallow: /

보안이 중요하여 콘텐츠가 전혀 인덱싱 크롤링되기를 바라지 않는 웹사이트에서는 사용하는 설정입니다. 불필요한 크롤러 요청과 트래픽 낭비 최소화할 수 있지만 검색 엔진 웹사이트가 전혀 노출되지 않을 수 있기 때문에 트래픽 유입에는 불리합니다.

마치며

현재 인터넷은 흥미로운 전환점에 서 있습니다. 매일 방대한 양의 데이터를 수집하는 AI 기업들이 늘어나면서, 웹사이트 운영자들은 보상 없이 실질적인 비용(서버 트래픽, 대역폭 등)을 부담하고 있습니다. 전통적인 무임 승차자 문제가 발생하고 있는 것이죠.

더욱이 2030년 경이면 봇 트래픽이 인간 트래픽을 초과할 것으로 예상되고, 봇 활동만으로도 현재 인터넷 트래픽의 총합을 넘어설 것으로 전망됩니다.

과거 웹의 생태계는 달랐습니다. 블로깅 초창기에는 링크백(linkback)이라는 문화가 있었죠. 누군가 내 글을 인용하면 링크를 남겨주고, 그 링크를 통해 추천 트래픽이 발생하거나 최소한 저작권자 표기를 통해 원작자가 인정받았습니다. 돈이 오가지 않았지만, 그 표기 자체가 미래의 발견을 촉진하고 본질적인 가치를 만들어냈습니다. 이러한 규범은 MIT 라이선스, Creative Commons 같은 허용적 라이선스에도 깊이 내재되어 있습니다.

하지만 지금은 다릅니다. 스크래핑된 콘텐츠가 원 창작자와 경쟁하는 데 사용되기도 하고, 저작권자 표기도 최소화되고 있습니다. 이로 인해 많은 콘텐츠 창작자들이 불가능한 선택에 직면하게 되었습니다.

콘텐츠를 완전히 차단할 것인가? 아니면 추천도 없고 표기도 없는 현실을 받아들일 것인가?

만약 차단만이 유일한 해결책이라면, 웹에서의 아이디어 자유로운 전파가 방해받고, AI 생태계에 새로 진입하는 이들은 모델 학습에서 부당한 불이익을 받게 될 것입니다.

그래서 robots.txt와 Content Signal 같은 도구가 중요합니다. 이들은 “차단”과 “무조건 허용” 사이의 중간 지대를 제공합니다. 검색은 허용하되 AI 학습은 거부하거나, 실시간 답변 생성은 허용하되 모델 학습은 차단하는 등 세밀한 제어가 가능해집니다.

작은 설정 하나로도 검색 결과가 바뀌고, 트래픽 흐름이 달라지며, 콘텐츠의 운명이 결정될 수 있습니다. 개인 블로그를 운영하든, 회사 웹사이트를 관리하든, 이제는 robots.txt를 단순한 기술적 설정이 아닌 콘텐츠 창작자로서의 권리와 철학을 표현하는 수단으로 바라봐야 할 때입니다.