웹을 보는 방식

2026년 3월 16일

Cloudflare의 새로운 pay-per-crawl API에 관한 소식은 몇 가지 이유로 제 눈길을 끌었습니다. 왜 그랬는지, 결과가 대략 어떻게 보이는지, 그리고 시험 삼아 바로 이 사이트를 크롤링하게 했을 때 무엇을 배웠는지 이어서 이야기해 보겠습니다.

우선, 이게 대체 무슨 일일까요? Cloudflare의 Crawl API는 사람들이 봇으로 웹사이트에서 데이터를 수집하도록 돕는 동시에, 바로 그와 동시에 웹사이트가 봇에 의해 크롤링되는 것을 막는 가장 대중적인 기술 가운데 하나도 제공하고 있습니다?!?

처음에는 이 상황이 전형적인 여우에게 닭장을 맡기는 꼴처럼 보였습니다. 하지만 이후 문서를 조금 읽어 보니, 그들은 여전히 자신들의 봇 차단 장치(예: Turnstile)를 존중하는 듯합니다.

Cloudflare나 다른 봇 완화 기술을 사용하고 있다면, Cloudflare 크롤 봇이 페이지를 수집할 수 있도록 그들의 안내를 따라 허용해야 합니다. 흥미롭게도, 이 기능을 제공하기 위해 그들이 HTTP Message Signatures의 최신 명세를 사용하고 있는 것처럼 보입니다. 아무나 자신을 CloudflareBrowserRenderingCrawler라고 주장한다고 해서 들여보낼 수는 없으니까요, 그렇죠?

여기서 기발한 점은 Cloudflare가 Content Delivery Network(CDN)로 잘 알려져 있다는 것입니다. 그래서 이론적으로는(이 부분은 아래에서 다시 이야기하겠습니다) 사용자가 어떤 웹사이트를 크롤링해 달라고 요청하면, 원본 웹사이트로 다시 왕복 요청을 보낼 필요 없이 캐시에서 데이터를 전달할 수 있습니다. 어떤 상황에서는 이것이 스크레이퍼가 웹사이트에 주는 부담을 크게 줄여 줄 수도 있습니다.

Crawl API의 도입은 또한 Cloudflare가 웹 출판자들이 크롤링으로부터 어떻게 이익을 얻을 수 있는지에 대해 그리고 있는 그림에서 또 하나의 퍼즐 조각처럼 보이기도 합니다. 이 전략이 실제로 통할지는 시간이 말해 주겠지만, 적어도 그들은 그저 어디에나 “AI”를 뿌려 대는 것만은 아닌, 웹에 대한 나름의 계획 비슷한 것은 가지고 있습니다.

LLM에 높은 가치가 있는 자원(학술 논문, 프리프린트, 책, 뉴스 기사 등)을 많이 보유한 웹사이트를 운영한다면, 같은 캐시된 콘텐츠를 원본 서버로 다시 돌아가지 않고도 여러 주체에게 전달할 수 있을 것입니다. 현재 봇에 짓눌리고 있는 자원 제약이 큰 문화유산 기관들에게는 이것이 반가운 발전이 될 수 있다고 생각합니다.

하지만 이 소식이 제 눈에 들어온 주된 이유는, 시선을 조금만 비틀어 보면 Cloudflare의 Crawl API가 웹 아카이빙 기술과 아주 많이 닮아 보인다는 점입니다. 예를 들어 Browsertrix API는 웹사이트 크롤을 설정하고, 시작하고, 모니터링하고, 다운로드할 수 있게 해 줍니다.

사람이 볼 수 있도록 웹사이트를 수집하는 데 초점을 둔 Browsertrix와 달리, Cloudflare의 Crawl 서비스는 LLM 학습을 위해 웹을 바라보는 데 맞춰져 있습니다. 이 서비스는 텍스트 콘텐츠를 반환합니다. 즉 HTML, Markdown, 그리고 수집한 텍스트를 그들의 LLM 가운데 하나에 주어진 프롬프트와 함께 통과시켜 얻은 구조화된 JSON 데이터입니다.

웹을 본다는 것

그렇다면 이것이 웹 아카이빙 기술과 닮아 있다는 점이 왜 흥미로울까요?

물론 여러분에게는 흥미롭지 않을 수도 있습니다. 하지만 (크흠) 제 학위논문 연구(Summers, 2020)에서 저는 기록학적 관점에서 웹 아카이빙 기술이 웹을 바라보는 서로 다른 보는 방식 을 어떻게 수행하는지 살피는 데 많은 시간(솔직히 너무 많은 시간)을 썼습니다. 저는 NIST의 National Software Reference Library(NSRL)와 1년을 함께하며 그들이 웹에서 소프트웨어를 어떻게 수집하는지, 그리고 그들이 만든 도구들이 어떻게 웹을 특정한 방식으로 보고 가치화하며, 특정한 것들(예: 소프트웨어)을 읽어낼 수 있게 만드는지(Scott, 1998)를 이해하려 했습니다.

제가 발견한 것은 NSRL이 일종의 웹 아카이빙을 수행하고 있었다는 점입니다. 그 아카이브 기록의 형태는 초기 사용 조건에 의해 결정되었습니다(그들의 경우에는 포렌식 분석이었습니다). 하지만 이러한 초기의 포렌식 용도가 기록의 가치를 완전히 결정해 버리지는 않았습니다. 그 기록들은 이후 다양한 사용, 비사용, 오용을 겪었습니다. 예를 들어 NSRL이 Stanford의 Cabrinety Archive에서 소프트웨어를 추가하기 시작했을 때라든지, 팀의 개인적 전문성과 비디오게임에 대한 관심 때문에 Steam 플랫폼의 콘텐츠 아카이빙에 집중하게 되었을 때 같은 경우입니다.

그래서 아마도 Cloudflare의 Crawl 서비스가 웹을 어떻게 보는지 에 관심을 가질 준비가 이미 되어 있었다고 할 수 있겠습니다. 이것이 중요한 이유는 그들이 수집한 데이터 위에 모델(LLM 등)과 다른 서비스들이 구축될 것이기 때문입니다. 하지만 그뿐 아니라, 이 서비스가 성공한다면 아마 다른 용도로도 전용될 가능성이 크기 때문입니다.

테스트

Cloudflare가 웹을 어떻게 보는지 시험하기 위해, 저는 단순히 제 자신의 정적 웹사이트—지금 여러분이 보고 있는 바로 그 사이트—를 크롤링해 달라고 요청했습니다. 이렇게 한 데에는 몇 가지 이유가 있습니다.

이것은 정적 웹사이트이고, 거기에 HTML 페이지가 정확히 몇 개 있는지 제가 알고 있습니다. 홈페이지에 각 글로 이어지는 인덱스 페이지의 페이지네이션 링크가 포함되어 있어서, 모든 페이지를 직접 발견할 수 있습니다.
서버 로그를 쉽게 확인해서 크롤러 활동이 어떻게 보이는지 볼 수 있습니다.
제 사이트에서는 어떤 종류의 Web Application Firewall도, 다른 형태의 봇 보호도 사용하지 않습니다(robots.txt는 있지만 CloudflareBrowserRenderingCrawler/1.0을 차단하지는 않습니다).
제 웹사이트는 Cloudflare를 CDN으로 사용하지 않는 May First에 호스팅하고 있습니다. 따라서 웹 콘텐츠가 애초에 Cloudflare의 CDN 안에 의도적으로 들어 있지는 않았을 것입니다.

이 방법론은 제가 이전에 Jess Ogden과 Shawn Walker와 함께 Internet Archive의 Save Page Now 서비스가 웹에서 어떤 콘텐츠를 아카이브하는지에 어떤 형태를 부여하는지 분석했던 작업(Ogden, Summers, & Walker, 2023)을 바탕으로 조정한 것입니다.

저는 크롤을 시작하고, 모니터링하고, 결과를 다운로드하기 위한 작은 명령줄 유틸리티 cloudflare-crawl을 작성했습니다. 크롤러가 도는 동안 저는 동시에 서버 로그를 지켜봤습니다. 이 유틸리티를 실행하면 이런 모습입니다.

$ uvx https://github.com/edsu/cloudflare-crawl https://inkdroid.org

created job 36f80f5e-d112-4506-8457-89719a158ce2
waiting for 36f80f5e-d112-4506-8457-89719a158ce2 to complete: total=1520 finished=837 skipped=1285
waiting for 36f80f5e-d112-4506-8457-89719a158ce2 to complete: total=1537 finished=868 skipped=1514
...
wrote 36f80f5e-d112-4506-8457-89719a158ce2-001.json
wrote 36f80f5e-d112-4506-8457-89719a158ce2-002.json
wrote 36f80f5e-d112-4506-8457-89719a158ce2-003.json
wrote 36f80f5e-d112-4506-8457-89719a158ce2-004.json
wrote 36f80f5e-d112-4506-8457-89719a158ce2-005.json

생성된 각 JSON 파일에는 크롤에 대한 메타데이터와 함께, 발견된 각 URL마다 하나씩의 “record” 목록이 들어 있습니다.

{
  "success": true,
  "result": {
    "id": "36f80f5e-d112-4506-8457-89719a158ce2",
    "status": "completed",
    "browserSecondsUsed": 1382.8220786132817,
    "total": 1967,
    "finished": 1967,
    "skipped": 6862,
    "cursor": 51,
    "records": [
      {
        "url": "https://inkdroid.org/",
        "status": "completed",
        "metadata": {
          "status": 200,
          "title": "inkdroid",
          "url": "https://inkdroid.org/",
          "lastModified": "Sun, 08 Mar 2026 05:00:39 GMT"
        },
        "markdown": "..."
        "html": "...",
      },
      {
        "url": "https://www.flickr.com/photos/inkdroid",
        "status": "skipped"
      }
    ]
  }
}

분석

저는 그들의 모델 제공물을 시험하는 데는 그다지 관심이 없다고 판단해서, JSON 콘텐츠(수집한 텍스트를 모델에 통과시킨 결과)는 요청하지 않았습니다. 만약 그랬다면 각 성공한 결과에 json 속성도 함께 들어 있었을 것입니다. 분명 이것을 활용하는 사람들은 있겠지만, 저는 이 서비스가 원본 웹사이트와 어떻게 상호작용하는지가 더 궁금했고, 그들의 LLM으로 콘텐츠를 돌리는 데 비용이 얼마나 드는지 힘들게 알아내고 싶지도 않았습니다.

아래는 Cloudflare 봇이 제 nginx 로그에 나타나는 방식의 일부입니다. 보시다시피 로그는 인터넷 상의 어떤 기계가 요청을 하고 있는지, 언제 요청되었는지, 그리고 사이트의 어떤 URL이 요청되고 있는지에 대한 통찰을 제공합니다.

104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /about/ HTTP/1.1" 200 5077 "-" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /css/main.css HTTP/1.1" 200 35504 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /css/highlight.css HTTP/1.1" 200 1225 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /css/webmention.css HTTP/1.1" 200 1238 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /images/feed.png HTTP/1.1" 200 8134 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /js/bootstrap.min.js HTTP/1.1" 200 17317 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /images/ehs-trees.jpg HTTP/1.1" 200 63047 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:59 +0000] "GET /js/highlight.min.js HTTP/1.1" 200 20597 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"

그렇다면 Cloudflare Crawl은 제 웹사이트를 어떻게 보았을까요?

아직은 서비스 초기라서 그럴 수도 있겠지만, 제가 알아차린 한 가지는 사이트를 크롤링해 달라고 요청할 때마다 결과가 급진적으로 다르게 보였다는 점입니다.

crawl time	completed	skipped	queued	errored	unique_urls
2026-03-12 13:13:00	165	84	0	1	223
2026-03-12 13:44:00	72	4	2	0	78
2026-03-12 14:09:00	1947	7304	0	23	9191
2026-03-12 16:33:00	72	4	2	0	78
2026-03-12 17:34:00	1948	7365	0	22	9191
2026-03-13 16:50:00	1947	7363	0	23	9187
2026-03-14 07:32:00	72	4	2	0	78

더 성공적이었던 크롤은 사이트 전체를 꽤 잘 크롤링했습니다. 제 웹사이트는 링크가 잘 연결되어 있고, 표준적인 홈페이지를 가지고 있으며, 모든 글로 연결되는 링크가 들어 있는 앵커 태그 기반 페이지네이션도 있습니다. 하지만 결과가 부분 크롤인지 아닌지를 아는 것은 어려워 보입니다. “웹사이트”의 실제 크기를 아는 것은 웹 아카이빙 실무에서 가장 어려운 일 중 하나입니다. “skipped”로 표시된 URL은 크롤 범위 밖에 있었습니다. 그것들까지 포함하고 싶다면, 크롤 설정 시 options.includeExternalLinks 옵션이 있는 것 같습니다.

웹 서버 로그를 지켜보면서 분명했던 점은 다음과 같습니다.

Cloudflare는 이전에 캐시된 데이터에 의존하는 것으로 보이기는 하지만, 그 논리가 정확히 무엇인지는 완전히 분명하지 않습니다. 예를 들어 어떤 크롤은 완료까지 5분이 걸렸고 1,974개의 완료 결과를 반환했지만, 웹 서버에서는 그 URL들 가운데 594개에 대한 요청만 보였습니다. 바로 이어서 똑같은 크롤을 다시 실행했더니 20분 더 오래 걸렸고, 역시 1,974개의 결과를 반환했지만 이번에는 847페이지가 요청되었습니다. 그 사이 웹사이트의 콘텐츠는 하나도 바뀌지 않았습니다. 🤷
Cloudflare는 각 페이지를 렌더링하기 위해 CSS, JavaScript, 이미지도 가져오는 것으로 보입니다(이들은 Browser Worker에 의해 캐시되지 않는 듯합니다).
웹 서버에서의 처리량은 분당 약 300 요청(초당 5요청) 정도에서 정점을 찍는 것처럼 보였습니다. 대부분의 사이트에는 이것이 충분히 감당 가능한 수준으로 보입니다.

더 성공적이었던 크롤에서는 Cloudflare의 네트워크 블록 안에 있는 246개의 서로 다른 IP 주소가 크롤링을 수행하는 것처럼 보였습니다.

ip	request_count
104.28.153.88	405
104.28.163.131	266
104.28.161.242	232
104.28.165.231	223
104.28.153.132	212
104.28.163.132	212
104.28.163.81	201
104.28.166.65	188
104.28.166.121	186
104.28.164.201	185
104.28.153.179	182
104.28.153.137	178
104.28.164.202	172
104.28.161.243	172
104.28.166.127	163
104.28.165.232	155
104.28.153.119	153
104.28.165.14	151
104.28.153.83	148
104.28.153.140	145
104.28.153.87	145
104.28.153.55	143
104.28.153.136	142
104.28.163.133	132
104.28.153.118	131
104.28.166.58	130
104.28.163.78	126
104.28.160.31	125
104.28.153.139	124
104.28.161.245	124
104.28.163.214	123
104.28.153.120	123
104.28.165.230	121
104.28.153.180	121
104.28.164.156	119
104.28.153.96	119
104.28.153.64	112
104.28.153.133	111
104.28.166.128	111
104.28.153.128	109
104.28.166.126	104
104.28.165.17	103
104.28.165.18	103
104.28.160.30	103
104.28.153.134	101
104.28.166.120	101
104.28.153.129	101
104.28.153.181	100
104.28.153.86	100
104.28.165.229	100
104.28.163.134	99
104.28.164.203	99
104.28.162.194	98
104.28.166.62	98
104.28.163.212	98
104.28.153.123	97
104.28.164.154	97
104.28.166.61	97
104.28.161.246	96
104.28.153.92	96
104.28.166.125	96
104.28.153.68	93
104.28.159.23	92
104.28.153.76	91
104.28.153.71	91
104.28.153.124	90
104.28.158.143	88
104.28.165.21	88
104.28.153.94	87
104.28.166.118	86
104.28.161.133	84
104.28.153.85	82
104.28.164.152	82
104.28.163.77	82
104.28.153.148	79
104.28.164.150	79
104.28.165.12	79
104.28.161.201	79
104.28.153.183	78
104.28.160.65	78
104.28.153.126	77
104.28.153.138	77
104.28.159.133	76
104.28.165.20	75
104.28.158.137	75
104.28.153.56	75
104.28.153.81	74
104.28.153.131	73
104.28.153.59	72
104.28.166.60	72
104.28.166.66	69
104.28.159.120	69
104.28.153.53	68
104.28.153.185	68
104.28.153.191	67
104.28.166.119	66
104.28.153.95	64
104.28.165.76	64
104.28.154.20	62
104.28.153.121	57
104.28.158.142	57
104.28.160.68	56
104.28.163.177	56
104.28.153.80	56
104.28.161.215	55
104.28.161.244	55
104.28.153.62	55
104.28.166.134	55
104.28.153.122	54
104.28.165.19	53
104.28.153.127	53
104.28.159.118	53
104.28.157.166	53
104.28.153.226	53
104.28.157.169	52
104.28.159.111	48
104.28.153.196	48
104.28.161.132	48
104.28.153.84	47
104.28.161.214	47
104.28.165.13	46
104.28.153.219	46
104.28.163.171	46
104.28.165.15	45
104.28.163.176	45
104.28.159.109	45
104.28.158.155	45
104.28.153.218	45
104.28.158.131	44
104.28.161.200	44
104.28.153.222	44
104.28.161.197	44
104.28.159.74	44
104.28.158.139	44
104.28.158.138	44
104.28.153.235	43
104.28.153.106	43
104.28.164.160	43
104.28.153.57	38
104.28.159.119	37
104.28.163.82	36
104.28.153.197	36
104.28.153.93	36
104.28.160.25	35
104.28.153.78	34
104.28.153.72	34
104.28.153.125	34
104.28.153.61	34
104.28.166.131	34
104.28.158.132	33
104.28.159.135	33
104.28.160.34	33
104.28.163.220	33
104.28.153.77	33
104.28.166.135	33
104.28.164.155	33
104.28.163.213	33
104.28.158.136	33
104.28.160.121	33
104.28.157.174	33
104.28.165.71	33
104.28.153.130	33
104.28.163.76	32
104.28.160.32	32
104.28.160.64	32
104.28.153.89	32
104.28.159.110	32
104.28.163.172	32
104.28.154.18	32
104.28.163.178	31
104.28.166.124	30
104.28.165.114	25
104.28.153.182	25
104.28.166.132	25
104.28.159.108	24
104.28.165.75	24
104.28.157.171	24
104.28.153.240	23
104.28.164.204	23
104.28.153.108	23
104.28.159.24	22
104.28.157.242	22
104.28.153.63	22
104.28.153.105	22
104.28.159.229	22
104.28.158.130	22
104.28.164.213	22
104.28.159.136	22
104.28.164.158	22
104.28.157.83	22
104.28.153.107	22
104.28.159.83	22
104.28.157.172	22
104.28.157.82	22
104.28.158.145	22
104.28.162.93	22
104.28.163.174	22
104.28.153.98	22
104.28.157.170	21
104.28.158.126	21
104.28.165.74	21
104.28.153.216	21
104.28.159.112	21
104.28.161.199	14
104.28.153.194	13
104.28.154.15	13
104.28.159.232	13
104.28.166.59	13
104.28.159.150	12
104.28.165.72	12
104.28.158.252	12
104.28.153.104	12
104.28.158.254	11
104.28.158.129	11
104.28.153.58	11
104.28.162.195	11
104.28.160.28	11
104.28.159.115	11
104.28.158.255	11
104.28.153.214	11
104.28.153.67	11
104.28.160.29	11
104.28.153.195	11
104.28.164.153	11
104.28.160.23	11
104.28.160.24	11
104.28.159.114	11
104.28.160.27	11
104.28.160.66	11
104.28.157.175	11
104.28.157.173	11
104.28.159.122	11
104.28.154.12	11
104.28.160.33	11
104.28.164.159	11
104.28.163.170	11
104.28.165.11	11
104.28.154.17	10
104.28.163.222	10
104.28.159.121	2
104.28.157.243	2
104.28.153.73	2
104.28.157.233	2
104.28.153.54	2
104.28.158.146	2
104.28.163.169	2

HTML 일부를 표본 점검해 보니 실제 웹에 있던 것과 거의 동일해 보였습니다. 가장 완전한 결과에서는 URL의 4%가 크롤되지 않았다는 점을 발견했습니다. 한 가지 예외는 OPML과 RSS 피드 같은 몇몇 XML 파일이었는데, 텍스트와 Markdown 결과에는 XSL 요소만 나타났습니다.

제 생각에는 여기서 몇 가지 방향으로 더 나아갈 수 있을 것 같습니다.

사이트 외부에 있는 페이지를 건너뛰는 대신 수집하도록 지시했을 때 무슨 일이 일어나는지 시험하기
더 동적인 콘텐츠에서는 어떤 일이 일어나는지, 그리고 페이지 렌더링을 얼마나 기다려야 하는지 시험하기
왜 가끔 잘린 결과가 돌아오는지, 그리고 그것이 발생할 때를 식별할 수 있는 신호가 있는지 이해해 보기
Cloudflare가 언제 내부 캐시를 사용할 수 있다고 판단하는지 그 논리를 더 탐구하기

제가 언급하지 않은 한 가지는 Cloudflare 무료 플랜이 크롤당 최대 100페이지로 제한된다는 점입니다. 저는 이 테스트를 하기 위해 월 5달러 유료 플랜 계정을 설정했습니다. 모든 테스트를 통틀어 저는 “browser hours”를 0.7 정도만 사용한 것으로 보였고, 이는 월 10시간 허용량 안에 넉넉히 들어갑니다. 현재 한도를 초과하면 시간당 $0.09가 듭니다.

추신. 궁금하시다면 제가 일부 분석에 사용했던 Marimo 노트북은 여기에서 찾을 수 있습니다.

참고문헌

Ogden, J., Summers, E., & Walker, S. (2023). Know(ing) Infrastructure: The Wayback Machine as object and instrument of digital research. Convergence: The International Journal of Research into New Media Technologies, 135485652311647. https://doi.org/10.1177/13548565231164759

Scott, J. C. (1998). Seeing like a state: How certain schemes to improve the human condition have failed. Yale University Press. Retrieved from https://theanarchistlibrary.org/library/james-c-scott-seeing-like-a-state

Summers, E. H. (2020). Legibility Machines: Archival Appraisal and the Genealogies of Use. Digital Repository at the University of Maryland. https://doi.org/10.13016/U95C-QAYR

👋 웹멘션 ✍️ 🤩

추신. 궁금하시다면, 이 글에는 Mastodon이나, 어쩌면 Webmentions을 지원하는 다른 소셜 미디어 플랫폼에 좋아요를 누르거나, 부스트하거나, 답글을 달거나, 혹은 단순히 이 글로 링크하는 게시물을 작성함으로써 응답하실 수 있습니다.

별도의 언급이 없는 한 이곳의 모든 콘텐츠는 CC-BY 라이선스로 제공됩니다.

웹을 보는 방식

2026년 3월 16일

platforms web-archives

Leica Double-Gauss Lens Design

웹을 본다는 것

그렇다면 이것이 웹 아카이빙 기술과 닮아 있다는 점이 왜 흥미로울까요?

테스트

이것은 정적 웹사이트이고, 거기에 HTML 페이지가 정확히 몇 개 있는지 제가 알고 있습니다. 홈페이지에 각 글로 이어지는 인덱스 페이지의 페이지네이션 링크가 포함되어 있어서, 모든 페이지를 직접 발견할 수 있습니다.
서버 로그를 쉽게 확인해서 크롤러 활동이 어떻게 보이는지 볼 수 있습니다.
제 사이트에서는 어떤 종류의 Web Application Firewall도, 다른 형태의 봇 보호도 사용하지 않습니다(robots.txt는 있지만 CloudflareBrowserRenderingCrawler/1.0을 차단하지는 않습니다).
제 웹사이트는 Cloudflare를 CDN으로 사용하지 않는 May First에 호스팅하고 있습니다. 따라서 웹 콘텐츠가 애초에 Cloudflare의 CDN 안에 의도적으로 들어 있지는 않았을 것입니다.

$ uvx https://github.com/edsu/cloudflare-crawl https://inkdroid.org

created job 36f80f5e-d112-4506-8457-89719a158ce2
waiting for 36f80f5e-d112-4506-8457-89719a158ce2 to complete: total=1520 finished=837 skipped=1285
waiting for 36f80f5e-d112-4506-8457-89719a158ce2 to complete: total=1537 finished=868 skipped=1514
...
wrote 36f80f5e-d112-4506-8457-89719a158ce2-001.json
wrote 36f80f5e-d112-4506-8457-89719a158ce2-002.json
wrote 36f80f5e-d112-4506-8457-89719a158ce2-003.json
wrote 36f80f5e-d112-4506-8457-89719a158ce2-004.json
wrote 36f80f5e-d112-4506-8457-89719a158ce2-005.json

생성된 각 JSON 파일에는 크롤에 대한 메타데이터와 함께, 발견된 각 URL마다 하나씩의 “record” 목록이 들어 있습니다.

{
  "success": true,
  "result": {
    "id": "36f80f5e-d112-4506-8457-89719a158ce2",
    "status": "completed",
    "browserSecondsUsed": 1382.8220786132817,
    "total": 1967,
    "finished": 1967,
    "skipped": 6862,
    "cursor": 51,
    "records": [
      {
        "url": "https://inkdroid.org/",
        "status": "completed",
        "metadata": {
          "status": 200,
          "title": "inkdroid",
          "url": "https://inkdroid.org/",
          "lastModified": "Sun, 08 Mar 2026 05:00:39 GMT"
        },
        "markdown": "..."
        "html": "...",
      },
      {
        "url": "https://www.flickr.com/photos/inkdroid",
        "status": "skipped"
      }
    ]
  }
}

분석

104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /about/ HTTP/1.1" 200 5077 "-" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /css/main.css HTTP/1.1" 200 35504 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /css/highlight.css HTTP/1.1" 200 1225 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /css/webmention.css HTTP/1.1" 200 1238 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /images/feed.png HTTP/1.1" 200 8134 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /js/bootstrap.min.js HTTP/1.1" 200 17317 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:58 +0000] "GET /images/ehs-trees.jpg HTTP/1.1" 200 63047 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"
104.28.153.137 - - [12/Mar/2026:14:34:59 +0000] "GET /js/highlight.min.js HTTP/1.1" 200 20597 "https://inkdroid.org/about/" "CloudflareBrowserRenderingCrawler/1.0"

그렇다면 Cloudflare Crawl은 제 웹사이트를 어떻게 보았을까요?

crawl time	completed	skipped	queued	errored	unique_urls
2026-03-12 13:13:00	165	84	0	1	223
2026-03-12 13:44:00	72	4	2	0	78
2026-03-12 14:09:00	1947	7304	0	23	9191
2026-03-12 16:33:00	72	4	2	0	78
2026-03-12 17:34:00	1948	7365	0	22	9191
2026-03-13 16:50:00	1947	7363	0	23	9187
2026-03-14 07:32:00	72	4	2	0	78

웹 서버 로그를 지켜보면서 분명했던 점은 다음과 같습니다.

Cloudflare는 이전에 캐시된 데이터에 의존하는 것으로 보이기는 하지만, 그 논리가 정확히 무엇인지는 완전히 분명하지 않습니다. 예를 들어 어떤 크롤은 완료까지 5분이 걸렸고 1,974개의 완료 결과를 반환했지만, 웹 서버에서는 그 URL들 가운데 594개에 대한 요청만 보였습니다. 바로 이어서 똑같은 크롤을 다시 실행했더니 20분 더 오래 걸렸고, 역시 1,974개의 결과를 반환했지만 이번에는 847페이지가 요청되었습니다. 그 사이 웹사이트의 콘텐츠는 하나도 바뀌지 않았습니다. 🤷
Cloudflare는 각 페이지를 렌더링하기 위해 CSS, JavaScript, 이미지도 가져오는 것으로 보입니다(이들은 Browser Worker에 의해 캐시되지 않는 듯합니다).
웹 서버에서의 처리량은 분당 약 300 요청(초당 5요청) 정도에서 정점을 찍는 것처럼 보였습니다. 대부분의 사이트에는 이것이 충분히 감당 가능한 수준으로 보입니다.

더 성공적이었던 크롤에서는 Cloudflare의 네트워크 블록 안에 있는 246개의 서로 다른 IP 주소가 크롤링을 수행하는 것처럼 보였습니다.

ip	request_count
104.28.153.88	405
104.28.163.131	266
104.28.161.242	232
104.28.165.231	223
104.28.153.132	212
104.28.163.132	212
104.28.163.81	201
104.28.166.65	188
104.28.166.121	186
104.28.164.201	185
104.28.153.179	182
104.28.153.137	178
104.28.164.202	172
104.28.161.243	172
104.28.166.127	163
104.28.165.232	155
104.28.153.119	153
104.28.165.14	151
104.28.153.83	148
104.28.153.140	145
104.28.153.87	145
104.28.153.55	143
104.28.153.136	142
104.28.163.133	132
104.28.153.118	131
104.28.166.58	130
104.28.163.78	126
104.28.160.31	125
104.28.153.139	124
104.28.161.245	124
104.28.163.214	123
104.28.153.120	123
104.28.165.230	121
104.28.153.180	121
104.28.164.156	119
104.28.153.96	119
104.28.153.64	112
104.28.153.133	111
104.28.166.128	111
104.28.153.128	109
104.28.166.126	104
104.28.165.17	103
104.28.165.18	103
104.28.160.30	103
104.28.153.134	101
104.28.166.120	101
104.28.153.129	101
104.28.153.181	100
104.28.153.86	100
104.28.165.229	100
104.28.163.134	99
104.28.164.203	99
104.28.162.194	98
104.28.166.62	98
104.28.163.212	98
104.28.153.123	97
104.28.164.154	97
104.28.166.61	97
104.28.161.246	96
104.28.153.92	96
104.28.166.125	96
104.28.153.68	93
104.28.159.23	92
104.28.153.76	91
104.28.153.71	91
104.28.153.124	90
104.28.158.143	88
104.28.165.21	88
104.28.153.94	87
104.28.166.118	86
104.28.161.133	84
104.28.153.85	82
104.28.164.152	82
104.28.163.77	82
104.28.153.148	79
104.28.164.150	79
104.28.165.12	79
104.28.161.201	79
104.28.153.183	78
104.28.160.65	78
104.28.153.126	77
104.28.153.138	77
104.28.159.133	76
104.28.165.20	75
104.28.158.137	75
104.28.153.56	75
104.28.153.81	74
104.28.153.131	73
104.28.153.59	72
104.28.166.60	72
104.28.166.66	69
104.28.159.120	69
104.28.153.53	68
104.28.153.185	68
104.28.153.191	67
104.28.166.119	66
104.28.153.95	64
104.28.165.76	64
104.28.154.20	62
104.28.153.121	57
104.28.158.142	57
104.28.160.68	56
104.28.163.177	56
104.28.153.80	56
104.28.161.215	55
104.28.161.244	55
104.28.153.62	55
104.28.166.134	55
104.28.153.122	54
104.28.165.19	53
104.28.153.127	53
104.28.159.118	53
104.28.157.166	53
104.28.153.226	53
104.28.157.169	52
104.28.159.111	48
104.28.153.196	48
104.28.161.132	48
104.28.153.84	47
104.28.161.214	47
104.28.165.13	46
104.28.153.219	46
104.28.163.171	46
104.28.165.15	45
104.28.163.176	45
104.28.159.109	45
104.28.158.155	45
104.28.153.218	45
104.28.158.131	44
104.28.161.200	44
104.28.153.222	44
104.28.161.197	44
104.28.159.74	44
104.28.158.139	44
104.28.158.138	44
104.28.153.235	43
104.28.153.106	43
104.28.164.160	43
104.28.153.57	38
104.28.159.119	37
104.28.163.82	36
104.28.153.197	36
104.28.153.93	36
104.28.160.25	35
104.28.153.78	34
104.28.153.72	34
104.28.153.125	34
104.28.153.61	34
104.28.166.131	34
104.28.158.132	33
104.28.159.135	33
104.28.160.34	33
104.28.163.220	33
104.28.153.77	33
104.28.166.135	33
104.28.164.155	33
104.28.163.213	33
104.28.158.136	33
104.28.160.121	33
104.28.157.174	33
104.28.165.71	33
104.28.153.130	33
104.28.163.76	32
104.28.160.32	32
104.28.160.64	32
104.28.153.89	32
104.28.159.110	32
104.28.163.172	32
104.28.154.18	32
104.28.163.178	31
104.28.166.124	30
104.28.165.114	25
104.28.153.182	25
104.28.166.132	25
104.28.159.108	24
104.28.165.75	24
104.28.157.171	24
104.28.153.240	23
104.28.164.204	23
104.28.153.108	23
104.28.159.24	22
104.28.157.242	22
104.28.153.63	22
104.28.153.105	22
104.28.159.229	22
104.28.158.130	22
104.28.164.213	22
104.28.159.136	22
104.28.164.158	22
104.28.157.83	22
104.28.153.107	22
104.28.159.83	22
104.28.157.172	22
104.28.157.82	22
104.28.158.145	22
104.28.162.93	22
104.28.163.174	22
104.28.153.98	22
104.28.157.170	21
104.28.158.126	21
104.28.165.74	21
104.28.153.216	21
104.28.159.112	21
104.28.161.199	14
104.28.153.194	13
104.28.154.15	13
104.28.159.232	13
104.28.166.59	13
104.28.159.150	12
104.28.165.72	12
104.28.158.252	12
104.28.153.104	12
104.28.158.254	11
104.28.158.129	11
104.28.153.58	11
104.28.162.195	11
104.28.160.28	11
104.28.159.115	11
104.28.158.255	11
104.28.153.214	11
104.28.153.67	11
104.28.160.29	11
104.28.153.195	11
104.28.164.153	11
104.28.160.23	11
104.28.160.24	11
104.28.159.114	11
104.28.160.27	11
104.28.160.66	11
104.28.157.175	11
104.28.157.173	11
104.28.159.122	11
104.28.154.12	11
104.28.160.33	11
104.28.164.159	11
104.28.163.170	11
104.28.165.11	11
104.28.154.17	10
104.28.163.222	10
104.28.159.121	2
104.28.157.243	2
104.28.153.73	2
104.28.157.233	2
104.28.153.54	2
104.28.158.146	2
104.28.163.169	2

제 생각에는 여기서 몇 가지 방향으로 더 나아갈 수 있을 것 같습니다.

사이트 외부에 있는 페이지를 건너뛰는 대신 수집하도록 지시했을 때 무슨 일이 일어나는지 시험하기
더 동적인 콘텐츠에서는 어떤 일이 일어나는지, 그리고 페이지 렌더링을 얼마나 기다려야 하는지 시험하기
왜 가끔 잘린 결과가 돌아오는지, 그리고 그것이 발생할 때를 식별할 수 있는 신호가 있는지 이해해 보기
Cloudflare가 언제 내부 캐시를 사용할 수 있다고 판단하는지 그 논리를 더 탐구하기

추신. 궁금하시다면 제가 일부 분석에 사용했던 Marimo 노트북은 여기에서 찾을 수 있습니다.

참고문헌

Summers, E. H. (2020). Legibility Machines: Archival Appraisal and the Genealogies of Use. Digital Repository at the University of Maryland. https://doi.org/10.13016/U95C-QAYR

👋 웹멘션 ✍️ 🤩

별도의 언급이 없는 한 이곳의 모든 콘텐츠는 CC-BY 라이선스로 제공됩니다.

웹을 보는 방식

웹을 보는 방식