내 경험상 Cloudflare로 보호된 페이지에서는 이게 작동하지 않음
아쉽게도, 문제를 스스로 만들고 다시 해결책을 파는 셈이 됨
Azure의 bot protection만 통과하면 괜찮을지도 모름
Cloudflare가 프록시를 사용하는 웹사이트의 미리 스크랩된 버전을 호스팅하지 않는 게 의외임
예를 들어 https://www.example.com/cdn-cgi/cached-contents.json 같은 형태로 제공할 수도 있을 텐데, 이미 캐시에 콘텐츠가 있으니까 굳이 스크래핑 서비스나 API를 거칠 필요가 없다고 생각함
물론 그렇게 하지 않는 이유도 있겠지만, 기본 옵션으로 제공하지 않는 게 놀라움
이런 캐시 덤프를 공개하는 건 원본의 프라이버시와 저작권 가정을 완전히 깨뜨림
접근 제어를 걸 수도 있겠지만, 그건 결국 아무도 원하지 않은 복잡한 CDN API를 새로 만드는 셈이고, 법적 문제도 생김
“편리한 JSON”에서 “AI 스크래퍼에게 사이트 전체를 넘기는” 건 한 끗 차이임
JSON 변환은 CPU를 쓰고, 결과를 저장하면 캐시 공간이 두 배로 늘어남
요청이 있을 때만 변환하면 원본 요청을 줄이면서도 캐시 효율을 유지할 수 있음
내가 CDN에서 일할 때는 캐시 히트율을 높이기 위해 ‘second hit caching’을 썼음 — 두 번째 요청이 들어올 때만 캐시에 저장하는 방식임
완전히 같은 건 아니지만, Cloudflare는 이미 비슷한 기능을 제공 중임 Markdown for Agents 기능을 켜면, AI 시스템이 text/markdown을 요청할 때 HTML을 실시간으로 Markdown으로 변환해줌
사실 내부적으로는 이미 이런 식으로 공개 콘텐츠를 캐시 기반으로 제공하고 있을 가능성도 있음
단, 이런 방식은 단순한 사이트에는 통하겠지만, SPA 같은 복잡한 사이트는 여전히 브라우저 렌더링이 필요한 스크래핑 서비스가 필요함
Cloudflare가 스크래핑 방어책을 팔면서 동시에 스크래핑 서비스를 파는 게 마치 조직폭력배 같음
인터넷 전반에 걸친 영향력 덕분에 가능한 일임
구조화된 crawl endpoint를 노출하는 건 robots.txt나 sitemap의 자연스러운 진화처럼 느껴짐
더 많은 사이트가 이런 기계 판독용 진입점을 제공하면, 인덱싱이 훨씬 효율적일 것임
지금은 크롤러들이 같은 구조를 계속 재탐색하느라 낭비가 많음
REST를 계속 썼다면 인덱싱 낭비가 훨씬 줄었을 것 같음
나는 API를 사람 중심으로 설계하고, LLM 제공자가 그 위에서 최적화하도록 하는 쪽을 선호함
사실 semantic HTML이 이미 그 역할을 하고 있음
HTML과 DOM은 본질적으로 기계가 읽기 위한 구조임
새로운 걸 발명할 필요 없이, 기존 기술을 제대로 활용하면 됨
비효율적인 크롤링으로 이득을 보는 건 anti-bot 솔루션 업체뿐임
하지만 이런 구조는 공급망 공격을 악화시킬 수도 있음
사람에게는 정상 페이지를, 봇에게는 다른 페이지를 보여주는 식으로 악용될 수 있음
결국 크롤러와 사람에게 다른 콘텐츠를 보여주는 건 근본적인 문제를 낳음
웹 아카이빙 용도로 쓸 수 있었을 텐데, WARC 포맷 지원이 없는 게 아쉬움
기자나 연구자에게 유용했을 것임
원본 서버는 여전히 Cloudflare의 Browser Rendering 요청을 감지하고 차단할 수 있음 CF-Worker 헤더로 구분 가능하고, WAF 규칙이나 미들웨어에서 필터링 가능함
다만 이 요청들은 Cloudflare ASN 13335에서 오며 낮은 bot score를 가지므로, 단순한 점수 기반 방어는 통하지 않음
결국 애플리케이션 레벨의 속도 제한과 행위 분석이 더 효과적임
구조적 충돌은 존재하지만, 검색엔진이 웹마스터 도구를 제공하는 것과 비슷한 상황임
내 사이트의 잘 크롤된 버전을 제공할 수 있으면 좋겠다고 생각했음
사이트 관리자에게 그런 기능을 제공하면, 크롤러들이 단순히 전송 비용만 내고 접근할 수 있을 텐데
직접 내 사이트를 대상으로 크롤 잡을 돌리고, static. 서브도메인으로 제공하는 식으로 구현할 수도 있을 듯함
하지만 그게 어떤 용도인지 잘 모르겠음
사이트가 정적이라면 그냥 HTML로 렌더링해서 호스팅하면 되고, 동적이라면 스냅샷이 무슨 의미가 있을지 의문임
캐싱을 추가하는 게 더 나은 접근일 수도 있음
Cloudflare는 요즘 멋진 기능들을 다 가져가는 느낌임
AWS는 뭐 하고 있는지 궁금함
Hacker News 의견들
내 경험상 Cloudflare로 보호된 페이지에서는 이게 작동하지 않음
아쉽게도, 문제를 스스로 만들고 다시 해결책을 파는 셈이 됨
Cloudflare가 프록시를 사용하는 웹사이트의 미리 스크랩된 버전을 호스팅하지 않는 게 의외임
예를 들어 https://www.example.com/cdn-cgi/cached-contents.json 같은 형태로 제공할 수도 있을 텐데, 이미 캐시에 콘텐츠가 있으니까 굳이 스크래핑 서비스나 API를 거칠 필요가 없다고 생각함
물론 그렇게 하지 않는 이유도 있겠지만, 기본 옵션으로 제공하지 않는 게 놀라움
접근 제어를 걸 수도 있겠지만, 그건 결국 아무도 원하지 않은 복잡한 CDN API를 새로 만드는 셈이고, 법적 문제도 생김
“편리한 JSON”에서 “AI 스크래퍼에게 사이트 전체를 넘기는” 건 한 끗 차이임
요청이 있을 때만 변환하면 원본 요청을 줄이면서도 캐시 효율을 유지할 수 있음
내가 CDN에서 일할 때는 캐시 히트율을 높이기 위해 ‘second hit caching’을 썼음 — 두 번째 요청이 들어올 때만 캐시에 저장하는 방식임
Markdown for Agents 기능을 켜면, AI 시스템이
text/markdown을 요청할 때 HTML을 실시간으로 Markdown으로 변환해줌Cloudflare가 스크래핑 방어책을 팔면서 동시에 스크래핑 서비스를 파는 게 마치 조직폭력배 같음
인터넷 전반에 걸친 영향력 덕분에 가능한 일임
DNS는 데이터 수집과 ‘착한 이미지’용임
퍼블리셔가 Cloudflare 뒤에 있고, AI 기업이 데이터를 원하면 Cloudflare를 통해 유료로 접근하게 만드는 구조임
일반 사용자가 아니라, AI 기업이 주요 고객층임
/crawl엔드포인트는robots.txt를 존중함즉, 크롤링 금지된 URL은 응답에
"status": "disallowed"로 표시됨구조화된 crawl endpoint를 노출하는 건
robots.txt나sitemap의 자연스러운 진화처럼 느껴짐더 많은 사이트가 이런 기계 판독용 진입점을 제공하면, 인덱싱이 훨씬 효율적일 것임
지금은 크롤러들이 같은 구조를 계속 재탐색하느라 낭비가 많음
나는 API를 사람 중심으로 설계하고, LLM 제공자가 그 위에서 최적화하도록 하는 쪽을 선호함
HTML과 DOM은 본질적으로 기계가 읽기 위한 구조임
새로운 걸 발명할 필요 없이, 기존 기술을 제대로 활용하면 됨
사람에게는 정상 페이지를, 봇에게는 다른 페이지를 보여주는 식으로 악용될 수 있음
웹 아카이빙 용도로 쓸 수 있었을 텐데, WARC 포맷 지원이 없는 게 아쉬움
기자나 연구자에게 유용했을 것임
원본 서버는 여전히 Cloudflare의 Browser Rendering 요청을 감지하고 차단할 수 있음
CF-Worker헤더로 구분 가능하고, WAF 규칙이나 미들웨어에서 필터링 가능함다만 이 요청들은 Cloudflare ASN 13335에서 오며 낮은 bot score를 가지므로, 단순한 점수 기반 방어는 통하지 않음
결국 애플리케이션 레벨의 속도 제한과 행위 분석이 더 효과적임
구조적 충돌은 존재하지만, 검색엔진이 웹마스터 도구를 제공하는 것과 비슷한 상황임
robots.txt를 따르니, 그게 가장 간단한 방법임이 크롤러가 bot 차단 로직 앞에서 동작하는지 뒤에서 동작하는지 궁금했음
내 사이트의 잘 크롤된 버전을 제공할 수 있으면 좋겠다고 생각했음
사이트 관리자에게 그런 기능을 제공하면, 크롤러들이 단순히 전송 비용만 내고 접근할 수 있을 텐데
직접 내 사이트를 대상으로 크롤 잡을 돌리고,
static.서브도메인으로 제공하는 식으로 구현할 수도 있을 듯함사이트가 정적이라면 그냥 HTML로 렌더링해서 호스팅하면 되고, 동적이라면 스냅샷이 무슨 의미가 있을지 의문임
캐싱을 추가하는 게 더 나은 접근일 수도 있음
Cloudflare는 요즘 멋진 기능들을 다 가져가는 느낌임
AWS는 뭐 하고 있는지 궁금함
이번 기능은 정말 인상적임
Cloudflare가 미래의 방향으로 미리 움직이고 있음