인간
↓
검색 엔진
...

모델 학습을 위해 데이터를 모으는 것
검색을 위해 색인을 만들어 두는 것
사용자의 요청으로 지금 읽는 것

AI가 대량의 데이터를 가져가서 미래 학습 등에 사용
↓
제한
...

Googlebot
↓
Google 검색
...

OAI-SearchBot 등
↓
AI 검색
...

인간
↓
AI 어시스턴트
...

nginx + Apache 2.4계

Internet
↓
nginx (전단/입구)
...

> GET / HTTP/2
> Host: www.example.com
> User-Agent: Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)
...

< HTTP/2 200
< server: nginx
< content-type: text/html; charset=UTF-8
...

AI bot
↓
nginx
...

for ua in \
'GPTBot' \
'GPT Bot' \
...

GPTBot 403
GPT Bot 200
GPT-Bot 200
...

lower(User-Agent).contains(

이 표에서 말하는 '미분류'는,

이번에 시도한 3가지 카테고리 중 어느 것을 단독으로 제한해도 200이었다는 의미이며, '해당 회사의 접근을 전혀 감지할 수 없다'는 뜻은 아닙니다.

OpenAI는 매우 명확합니다.

이는 OpenAI 자체가 설명하는 용도와도 잘 일치합니다. 사쿠라의 3가지 체크박스는 단순한 UI상의 설명이 아니라, 내부적으로도 User-Agent별로 카테고리를 가지고 있을 가능성이 높아 보입니다.

여기서의 포인트는,

'AI 어시스턴트를 제한'한다고 해서, 세상의 AI 어시스턴트로부터의 접근을 전부 막을 수 있는 건 아니라는 것입니다. 이번 실측에서 AI 어시스턴트로 403이 된 것은,

뿐이었습니다. 반면,

은 모두 200이었습니다. 즉, 적어도 현재 시점의 동작은 **알려진 User-Agent 리스트 방식**이라고 생각하는 것이 자연스럽습니다.

Amazon의 공식 자료에서는,

-
`Amazonbot`:
제품/서비스 개선, AI 모델 학습에 사용될 가능성 -
`Amzn-SearchBot`:
검색 용도 -
`Amzn-User`:
사용자 조작 시작점

이라고 설명되어 있습니다. 하지만 이번 사쿠라 측의 동작에서는,

모두 'AI 검색 크롤러'로 403이 되었습니다. 즉, 사쿠라가 각 회사의 공식 카테고리를 그대로 기계적으로 복사하고 있다고는 보기 어려워 보입니다.

3가지 카테고리 모두 제한한 상태에서는,

이었습니다. 언뜻 보면,

`Applebot-Extended`도 사쿠라의 리스트에 등록되어 있는 것처럼 보이기도 합니다.

하지만, User-Agent를 조금 변형시켜 보면,

Applebot-Extended → 403
Applebot Extended → 403
Applebot_Extended → 403

이것으로 설명할 수 있습니다. 전체가 아니라, 그 안의 

에만 히트하고 있다고 생각하면 됩니다. 실제로 `Applebot` 단독으로도 AI 검색 카테고리에서 403입니다. 따라서,

Applebot-Extended가 명시적으로 등록되어 있다는 증거는 아니라고 볼 수 있습니다.

403이 된 주요 User-Agent에 대해서 변형 버전을 넣어보았습니다. 예로 `OAI-SearchBot`의 경우,

같은 경향은 

`GPTBot`
`ClaudeBot`
`Claude-SearchBot`
`PerplexityBot`
`Amzn-SearchBot`
`meta-externalagent`
`meta-webindexer`
`CCBot`
`DuckAssistBot`
등에서도 재현하고 있습니다. 따라서 적어도 이들에 대해서는,

라고 생각할 수 있습니다.

지금까지의 결과를 바탕으로, 사쿠라의 'AI 접근 제어'에 대해 개념도를 그리면

nginx 설정을 작성하면 동작만 놓고 보면 다음과 같습니다.

그리고 계약자별로,

같은 플래그를 가지고 있다고 생각하면 거의 모든 관측 결과를 설명할 수 있습니다. 물론, 실제로는 설정 DB, 생성된 nginx 설정, 공유 메모리, 독자 모듈 등 다른 구현 방식일 수도 있습니다.

이번 실험에서 가장 중요한 포인트는 여기입니다. 예를 들어,

인데도 403이 됩니다. 즉 정말 OpenAI의 GPTBot인지 확인하는 것이 아닙니다. 오히려 악의적인 스크레이퍼가

이라고만 이름을 내세우면, 이 User-Agent 판별을 회피할 가능성이 높습니다. 따라서 이 기능은,

고도화된 AI 봇 감지 시스템

이 아닙니다. 오히려,

정직하게 알려진 User-Agent를 이름으로 내세워 접근해 오는 AI 사업자를, 공유 렌탈 서버 위에서 저비용으로 제어하는 장치

라고 생각하는 것이 합리적입니다. 대량 요청을 PHP나 WordPress까지 통과시킨 후에 거부하는 것보다, 입구의 nginx에서 즉시 403을 반환하는 것이 압도적으로 가볍기 때문입니다.

`robots.txt`는 기본적으로 '요청'입니다.

이라고 써도 상대방이 무시하고 HTTP GET을 하면 웹 서버에 도달합니다. 반면, 이번 사쿠라의 기능은,

입니다. 즉,

이라는 차이가 있습니다. 다만, 그 게이트는 '이름(UA)을 이름으로 내세운 상대'만 보고 있기 때문에,

같은 엄격한 확인과는 별개입니다.

Cloudflare는 현재 AI 관련 접근을 `Search / Training / Agent`와 같은 행동으로 분류하고, AI Crawl Control이나 WAF, Bot Management 등을 조합하여 사용합니다. 또한, Verified Bot 메커니즘도 갖추고 있어 '어떤 이름을 이름으로 내세웠는지'뿐만 아니라 더 강력한 식별을 하는 방향입니다.

반면에 이번에 관측된 사쿠라의 방식은 상당히 간단했습니다.

사쿠라(이번 관측) | Cloudflare | 
|---|---|
| 주요 목적 | 공유 호스팅의 부하 경감・접근 제어 | AI 접근 전반의 가시화・제어 |
... 
같은 문제를 다루고 있지만, 서비스의 성격이 상당히 다릅니다.

사쿠라는 '렌탈 서버 이용자가 어려운 점을 생각하지 않아도 입구에서 가볍게 막을 수 있다'는 것에 중점을 둔 것으로 보입니다.

이번 실험 전에 매우 참고가 된 것이 유튜브 비즈니스 서포트의 검증 기사였습니다.

2026년 9월 4일 기준으로, AI 데이터 스크레이퍼만 제한했던 환경에서는 

이었다고 보고되었습니다. 그런데 필자가 2026년 10월 7일에 측정한 환경에서는 

이었습니다. 즉, 필자 환경에서는 `Claude-SearchBot`은 명확하게 'AI 검색 크롤러'로 분류되었습니다. 이 것만으로는 9월에서 10월 사이에 사쿠라가 규칙을 수정했다고 단정할 수는 없습니다. 서버 환경이나 측정 조건의 차이도 고려해야 합니다. 다만, **User-Agent 분류 테이블이 중앙 측에서 업데이트될 수 있는 메커니즘**이라고 생각한다면 가능한 이야기입니다. 이 점은 앞으로 시간을 두고 재측정하면 알게 될지도 모릅니다.

참고:

이 기능에 대해서는 사쿠라 자체에서 
AI 시대의 웹사이트 운영 입문 ~ AI 크롤러・스크레이핑 대책과 접근 제어의 사고방식~
이라는 세미나가 2026년 8월에 예정되어 있었습니다. 다만, 2026년 8월 18일에 '여러 사정'으로 연기가 발표되었습니다. 내용 소개를 보니 이번에 알고 싶었던 주제 그 자체이므로, 재개최나 자료 공개가 있다면 꼭 확인하고 싶습니다.

필자 입장에서는 일반 공개 기업・점포・서비스 사이트라면, 우선 

을 기준으로 삼는 것이 좋다고 생각합니다. 이유는, 

부하만 발생시키기 쉬운 대량 데이터 수집은 억제하면서, AI 시대의 '발견되는 경로'는 남겨두기 위함입니다. 반면, 기사나 사진 등 콘텐츠 자체를 상품으로 하는 사이트에서는 더 엄격하게 할 합리성이 있다고 생각합니다. 이것이 AI에 의한 제로 클릭 문제입니다.

또한, 함께 고려해야 할 중요한 포인트로서, 사쿠라의 'AI 접근 제어' 설정만으로는 완전한 제어가 가능하다는 것이 아닙니다. 이번 실험에서도 미분류된 AI User-Agent가 여러 개 있다는 것이 확인되었습니다. 또한 User-Agent를 위장하면 쉽게 우회할 수 있습니다.

따라서,

- 사쿠라의 접근 제어
- robots.txt
- WAF나 CDN
- 필요하다면 인증
- 애초에 공개해도 되는 정보인지 확인

을 용도에 맞게 조합하여 생각해야 할 것입니다.

이번에, 사쿠라 렌탈 서버의 '웹사이트 접근 제어'가 무엇을 하는지 공식 자료와 `curl`을 사용해 블랙박스적으로 조사해보았습니다.

실측으로 알게 된 것은,

- AI 관련 User-Agent에 대해 실제로 HTTP 403을 반환함
- 403은 nginx의 표준적인 응답처럼 보임
- 사쿠라 공식 구성도 전단(前段) nginx + 후단(後段) Apache
- 자택 회선에서도 User-Agent를 명시하는 것만으로 차단됨
- 적어도 거부 시 공식 IP 인증은 필수 아님
- 대소문자를 무시한 부분 일치로 보임
- 3개 카테고리마다 알려진 User-Agent의 분류 테이블이 있는 것처럼 보임
- 한편, 미등록된 AI User-Agent도 존재함

이었습니다.

이 메커니즘은 'AI임을 고도로 간파하는' 것은 아닙니다. 하지만 공유 렌탈 서버라는 환경에서, 알려진 AI 크롤러로부터의 대량 접근을 저렴하게 입구에서 막는 시스템으로는 상당히 합리적이라고 생각합니다.

그리고 개인적으로는, 이 세 가지 스위치가 보여주는 사고방식이 더 흥미롭습니다. 앞으로의 웹사이트 운영에서는,

라는 양자택일이 아니라,

을 따로따로 생각할 필요가 있을 것 같습니다. 30년 전에 태어난 인간이 접속한다는 전제였던 웹에서는 이런 설정이 필요하지 않았습니다.

사쿠라 인터넷이 창업 30주년을 맞은 해에, 임대 서버 관리 화면에 이 세 가지 체크박스가 추가된 것은 웹 자체가 다음 시대로 진입하고 있음을 상징하는 듯하여 매우 흥미롭다고 생각합니다.

본 기사의 결과는 **2026년 10월 7일에 필자가 관리하는 사쿠라의 임대 서버 환경에서 진행한 블랙박스 테스트**입니다.

다음 사항은 보장할 수 없습니다.

- 모든 플랜 및 모든 서버에서 동일하게 구현되어 있다는 것
- 내부적으로 nginx의 `map`이나 정규 표현식을 실제로 사용하고 있다는 것 - IP 주소 등을 보조 정보로 일절 이용하지 않았다는 것
- 앞으로도 User-Agent 목록이나 분류가 변하지 않을 것이라는 것
- 403 에러를 반환하는 User-Agent가 실제 AI 사업자의 봇이라는 것

특히 User-Agent 분류는 향후 업데이트될 가능성이 있습니다. 이 기사를 읽은 시점의 동작을 확인하고 싶다면, 본인이 관리하는 사이트에서 재테스트해 주십시오.

대량의 요청을 보낼 필요는 없습니다. 이 기사의 테스트 또한, 1개의 User-Agent당 수회 정도의 저빈도 접근으로 진행했습니다.

- 웹사이트 접근 제어를 설정하고 싶다
- '웹사이트 접근 제어 기능' 제공 개시
- 기본 사양을 알고 싶다 (사쿠라 임대 서버)
- Apache - 사쿠라 지원 정보
- 【연기】 세미나 “AI 시대의 웹사이트 운영 입문 ~ AI 크롤러/스크레이핑 대책과 접근 제어의 사고방식”
- 사쿠라 인터넷 연혁

- Overview of OpenAI Crawlers
- About AmazonBot
- Cloudflare AI Crawl Control
- Cloudflare Bot reference
- Your site, your rules: new AI traffic options for all customers
- Have it both ways: stay discoverable in search while disallowing AI training
- Cloudflare’s 2026 Annual Founders’ Letter

- 2026-10-07: 초판. 사쿠라 임대 서버 환경에서의 실측 결과를 반영.