사쿠라 인터넷은 1996년 12월 23일 창업했다고 하니, 2026년에는 창업 30주년이 됩니다. 참고로 본 기사는 사쿠라 인터넷 주식회사와 무관한 한 유저의 자율 검증이며 공식 견해가 아닙니다.

2026년 2월, 사쿠라의 렌탈 서버에 '웹사이트 접근 제어'라는 기능이 추가되었습니다. 설정 화면에는 다음 3가지 항목이 있습니다.

AI 데이터 스크레이퍼 (AI data scraper)
AI 검색 크롤러 (AI search crawler)
AI 어시스턴트 (AI assistant)

처음에는 'AI로부터의 접근을 막는 기능이구나'라고 생각해서 전부 제한했습니다.

하지만 잘 생각해 보니 AI 검색이나 AI 어시스턴트까지 막으면, AI를 통해 자신의 사이트를 발견될 기회마저 줄이는 것이 아닐까? 라는 의문이 생깁니다.

게다가 공식 도움말을 읽어봐도,

그렇다면 기술적으로 무엇을 보고 AI로부터의 접근을 판별하는지, 어떻게 막는지는?

까지는 알 수 없습니다.

그래서 curl을 사용해서 간단히 조사해봤습니다.

2026년 10월 7일 시점, 필자의 사쿠라 렌탈 서버 환경에서 확인된 동작은 다음과 같습니다.

제한 대상의 User-Agent를 표방할 경우: 403 Forbidden
허용할 경우 즉시 200 OK
403 응답은 nginx의 표준적인 짧은 에러 페이지
OpenAI 공식 IP가 아닌 자택 회선에서
GPTBot
이라고만 표방해도 403이 발생함 -
GPTBot / gptbot / xxxGPTBotxxx / NotGPTBotAtAll 모두 403-
GPT Bot / GPT-Bot / GPT_Bot은 200 - 다른 회사 봇도 거의 비슷한 경향
3개 카테고리마다 별개의 User-Agent 분류가 존재하는 것처럼 보임
반면, 등록되지 않은 AI 관련 User-Agent도 적지 않음

따라서 관측 결과를 가장 단순하게 설명하는 모델은,

사전 nginx 부근에서 알려진 AI 봇의 User-Agent 문자열을 대소문자를 무시한 부분 일치로 대조하여, 3개 카테고리 중 하나로 분류하고. 계약자의 설정이 '제한'이라면 Apache에 전달하기 전에 403을 반환하는

것입니다.

다만, 내부 구현은 공개되어 있지 않습니다. 아래는 공식 자료와 외부에서 관측 가능한 동작을 조합한 추측입니다.

기존 웹사이트 운영에서는 대략적으로,

인간
↓
검색 엔진
...

만 생각하면 충분했습니다.

하지만 생성 AI 시대를 맞이하여, 같은 'AI로부터의 접근'이라 하더라도 접근 목적이 다릅니다. 예를 들어 OpenAI는 현재 적어도 다음처럼 User-Agent를 나누고 있습니다.

User-Agent	주요 용도
`GPTBot`	생성 AI 모델 개선/학습에 사용될 가능성이 있는 크롤링
`OAI-SearchBot`	ChatGPT의 검색 기능에 웹사이트를 게재하기 위한 검색 크롤링
`ChatGPT-User`	사용자 프롬프트를 기반으로 그 자리에서 페이지를 가져옴

OpenAI 자체도 GPTBot과 OAI-SearchBot은 독립적으로 제어할 수 있다고 설명합니다.

즉,

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

은 다른 용도입니다.

Cloudflare 역시 2026년 7월부터 AI 접근을 주로,

TrainingSearchAgent

의 세 가지 동작으로 나누어 제어하는 방향으로 나아가고 있습니다.

사쿠라의

AI 데이터 스크레이퍼
AI 검색 크롤러
AI 어시스턴트

도 거의 같은 문제 의식에서 탄생한 분류라고 생각하면 이해하기 쉽습니다.

이 기능을 조사하게 된 또 다른 계기는 Cloudflare의 2026년 Annual Founders' Letter였습니다. 그 안에서 Cloudflare는 자사 네트워크에서 관측하는 자동화 트래픽 전체가 2026년 5월에 인간으로부터의 트래픽을 초과했다고 밝히고 있습니다.

이곳은 오해하기 쉬운데, 'AI 트래픽만 인간을 초과했다'는 의미가 아닙니다. 검색 크롤러 등을 포함한 자동화 트래픽 전체에 대한 이야기입니다. 다만, 그 역전 현상을 AI 에이전트나 AI 크롤러의 급증이 앞당긴 것이라는 설명입니다. 앞으로도 이 경향은 계속되어 5년 안에 인간 트래픽의 1000배가 될 것으로 예측하고 있습니다. 예전에 '모바일 접근이 PC 접근을 초과했다, 오호' 같은 이야기가 있었겠지만, 그 규모가 다릅니다. 1000배입니다, 1000배. 인간으로부터의 접근은 오차 범위가 되는 시대가 올 것입니다.

Cloudflare는 이 시대를 문제로 삼아, 'AI 에이전트가 점심 식사 장소를 결정하기 위해 1,000개 매장의 메뉴를 읽더라도, 실제로 고객을 얻는 곳은 단 한 군데일 수 있다'라는 예를 들고 있습니다. AI에게는 편리하지만, 나머지 999개 매장은 HTTP 요청을 처리하는 비용만 부담할 가능성이 있는 것입니다.

이 문제를 고려하면, 사쿠라가 먼저 '서버 부하 저감'을 AI 접근 제어의 목적으로 내세우는 것도 이해가 됩니다.

사쿠라 인터넷은 2026년 2월 10일, 렌탈 서버/매니지드 서버를 대상으로 '웹사이트 접근 제어 기능' 제공을 시작했습니다. 공식 발표에 따르면 다음 세 종류입니다.

설정	공식 설명 요약
AI 데이터 스크레이퍼	페이지에서 정보를 추출·획득하는 AI 봇을 제어
...
목적으로는 '서버 부하 저감 및 부정 이용 방지'가 언급되었습니다.

게다가 'AI 데이터 스크레이퍼'는 미설정 사용자부터 2026년 3월 17일 이후 자동으로 제한이 유효화됩니다.

참고로, Googlebot 등 일반 검색 엔진의 SEO 관련 봇은 제어 대상에서 제외됩니다.

기술 검증에 들어가기 전에 실용적인 결론을 먼저 적겠습니다.

상품・서비스・점포・회사 정보 등을 일반 공개하는 일반 사이트라면, 우선 다음부터 시작하는 것이 좋을 것입니다.

항목	권장
AI 데이터 스크레이퍼	제한
...
생각은 간단합니다.

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

기존에는,

Googlebot
↓
Google 검색
...

이었습니다.

앞으로는,

OAI-SearchBot 등
↓
AI 검색
...

같은 경로도 늘어날 것입니다.

검색 용도까지 전부 막아버리면, AI 입장에서 자사 사이트가 발견되기 어려워질 가능성이 있습니다. 예를 들어 사용자가 AI에게,

이 회사의 웹사이트를 읽고 서비스 특징을 정리해 줘

라는 프롬프트를 전달했을 경우입니다.

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

따라서 이것은 봇의 자동 데이터 대량 수집이 아니라 '실제 방문자'에 가까운 접근입니다. 물론, 뉴스, 유료 기사, 사진, 창작물 등 콘텐츠 자체가 상품인 사이트는 이야기가 달라집니다.

| 사이트 | 데이터 스크레이퍼 | AI 검색 | AI 어시스턴트 |
|---|---|
| 기업・점포 사이트 | 제한 | 허가 | 허가 |
| ... |
'AI니까 전부 거부'가 아니라, 용도별로 얻을 수 있는 가치가 무엇인지 생각하는 것이 더 현실적일 것입니다.

자, 이제 본론입니다.

공식 도움말에는 'AI 봇의 접근 제어 (HTTP/HTTPS)'라고 되어 있습니다. 이는 robots.txt를 수정하는 기능이 아닙니다. robots.txt는 기본적으로 단순한 사이트 측의 의사 표시일 뿐입니다. 상대방이 지키지 않으면 HTTP 요청 자체는 도착합니다.

반면, 사쿠라의 기능은 실제로 HTTP 상태 코드 403 Forbidden을 반환합니다. 그렇다면 어디서 판정하고 있는 것일까요?

사쿠라의 공식 사양에 따르면, 렌탈 서버 웹은,

nginx + Apache 2.4계

입니다.

공식 용어집에서는 더 명확하게,

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

라는 구성이라고 설명되어 있습니다.

그래서 먼저 다음 가설을 세웠습니다. AI 접근 제어는 Apache나 WordPress보다 앞선 nginx 근처에서 User-Agent를 보고 있는 것이 아닐까?

이하, 실험 시의 도메인명・사용자명・IP 주소 등은 기사용으로 익명화했습니다.

curl -v
-A 'Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)'

결과 중 중요한 부분만 발췌하면 다음과 같습니다.

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

nginx 특유의 순수한 403 에러입니다.

제어판에서 제한을 해제하고, 동일한 User-Agent로 다시 접속합니다.

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

이번에는 WordPress에서 유래한 것으로 보이는 응답까지 돌아옵니다.

설정 변경이 거의 즉시 반영되었습니다.

허용 시에도 프론트엔드의 nginx를 통과하기 때문에, server: nginx만으로는 nginx 자체가 403을 만들었다는 증거가 되지 못합니다. 하지만,

제한 시에는 146바이트의 간소한 nginx 403 페이지
허용 시에는 WordPress 등 후단에서 부여된 헤더가 존재함
설정 변경이 즉시 반영됨

이라는 차이점을 고려하면,

AI bot
↓
nginx
...

라는 경로가 가장 자연스럽다고 생각됩니다. 내부 구현은 비공개라 단정할 수는 없지만, Apache로 전달하기 전 단계에서 차단하고 있을 가능성이 상당히 높을 것입니다.

다음 의문점은,

User-Agent뿐만 아니라, 전송하는 쪽의 OpenAI 공식 IP도 확인하는가?
입니다. 이 판단은 간단합니다. 손안의 터미널에서 GPTBot이라는 이름을 사용하고 있으므로, 당연히 OpenAI 공식 크롤러의 IP 주소는 아닙니다.

그럼에도 403이 됩니다. 즉,

GPTBot이라는 User-Agent 문자열만으로 거부 조건을 충족시킬 수 있습니다.

물론 'IP 주소를 내부적으로 전혀 보고 있지 않다'는 것까지 증명한 것은 아니지만, 공식 IP를 통한 발신지 확인은 403을 만들기 위한 필수 조건은 아닙니다.

여기는 Cloudflare의 Verified Bot과 같은 방식과는 성격이 다른 것 같습니다.

다음으로는 실제로 어떤 문자열에 매칭되는지가 궁금했기 때문에, 먼저 GPTBot이라는 문자열을 변형하여 접속해 보았습니다.

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

결과는 이렇습니다.

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

NotGPTBotAtAll
'절대 GPTBot이 아니다'라는 것도 403입니다(웃음).

반면, GPT Bot처럼 문자열을 분리하면 200이 됩니다.

간단하게 표현하자면,

lower(User-Agent).contains(

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

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

OpenAI는 매우 명확합니다.

GPTBot
↓
AI 데이터 스크레이퍼
...


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

ClaudeBot
↓
AI 데이터 스크레이퍼
...


여기서의 포인트는,

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

ChatGPT-User
DuckAssistBot

뿐이었습니다. 반면,

Claude-User
Perplexity-User
Amzn-User
...

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

Amazon의 공식 자료에서는,

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

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

Amazonbot
Amzn-SearchBot

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

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

Applebot-Extended → 403

이었습니다. 언뜻 보면,

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

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

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

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

Applebot

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

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

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

oai-searchbot 403
OAI-SEARCHBOT 403
xxxOAI-SearchBotxxx 403
...


같은 경향은 

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

대소문자 무시 부분 일치

라고 생각할 수 있습니다.

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

HTTP Request
│
▼
...


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

어디까지나 동작을 설명하기 위한 가상 예시. 사쿠라의 실제 설정은 아닙니다.

map $http_user_agent $ai_category {
default "";
...}


그리고 계약자별로,

scraper = deny
search = allow
assistant = allow

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

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

NotGPTBotAtAll

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

Mozilla/5.0

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

고도화된 AI 봇 감지 시스템

이 아닙니다. 오히려,

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

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

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

User-agent: GPTBot
Disallow: /

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

GPTBot을 이름으로 내세움
↓
서버 측에서 판별
...

입니다. 즉,

robots.txt
= 출입 금지 표지판
s쿠라의 접근 제어
...

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

Cloudflare의 Verified Bot
Web Bot Auth
IP range 검증이나 reverse DNS

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

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

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

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

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

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

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

Claude-SearchBot → 403

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

AI 데이터 스크레이퍼만 제한
Claude-SearchBot → 200
AI 검색 크롤러만 제한
...

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

참고:

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

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

AI 데이터 스크레이퍼 제한
AI 검색 크롤러 제한 안 함
AI 어시스턴트 제한 안 함

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

부하만 발생시키기 쉬운 대량 데이터 수집은 억제하면서, 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 크롤러로부터의 대량 접근을 저렴하게 입구에서 막는 시스템으로는 상당히 합리적이라고 생각합니다.

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

AI를 허용할지 / 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: 초판. 사쿠라 임대 서버 환경에서의 실측 결과를 반영.

NotGPTBotAtAll이라도 403? 사쿠라의 렌탈 서버 '웹사이트 접근 제어'를 curl로 조사해봤다

요약

핵심 포인트

어디까지나 동작을 설명하기 위한 가상 예시. 사쿠라의 실제 설정은 아닙니다.

댓글

디버거 연결이 불가능한 운영 환경을 어떻게 운용할 것인가: Meta가 TEE에 스토리지까지 넣기로 한 판단

Polars를 사용하여 수십만 건 데이터 처리 속도 향상

Gemini 4 Argon이 프론티어 성능으로 게이트 리리즈로 출시되다

AI가 작성한 코드에 리뷰를 맡기지 않는 방법: Claude Code와 Codex를 번갈아 사용하는 3가지 원칙

디버거 연결이 불가능한 운영 환경을 어떻게 운용할 것인가: Meta가 TEE에 스토리지까지 넣기로 한 판단

Polars를 사용하여 수십만 건 데이터 처리 속도 향상

Gemini 4 Argon이 프론티어 성능으로 게이트 리리즈로 출시되다

AI가 작성한 코드에 리뷰를 맡기지 않는 방법: Claude Code와 Codex를 번갈아 사용하는 3가지 원칙