한밤의 크롤링

태평양 시간 새벽 3시, 제 프로덕션 사이트는 업무 시간 중 어느 때보다 더 많은 요청을 처리하고 있어요. 사용자가 아니라 봇에게요.

Googlebot은 21,000페이지를 크롤링하고 있어요. Bingbot은 10,000페이지를 크롤링해요. 종합 야간 점검은 15,000개의 블로그 글과 회사 페이지를 처리하고 있어요. 워밍 패스가 다음 날 트래픽을 위해 Cloudflare 엣지 캐시를 준비해요. 이 야간 프로세스들이 처리하는 페이지 수는 모든 실제 방문자를 합친 것보다 많아요.

낮에 만드는 사이트는 가장 중요한 사이트가 아니에요. 가장 중요한 사이트는 새벽 3시에 크롤러가 보는 그 사이트예요.

크롤링 인구조사

매일 크롤링 인구조사를 실행해서 지난 24시간 동안 봇이 본 것을 집계해요. 이 인구조사는 Cloudflare의 분석 API을 사용자 에이전트로 필터링해서 수행해요. 숫자가 검색 엔진이 무엇을 가치 있게 여기는지 보여줘요:

Google:     21,463  (67%)
Bing:       10,620  (33%)
Combined:   32,083

Jobs:       16,111  (50% of all crawls)
Blog:       298
Locale:     1,233
Programmatic: 257
Companies:  14

채용 페이지가 크롤링 예산의 절반을 차지해요. Googlebot은 하루에 10,654개의 채용 페이지를 크롤링해요. 채용 사이트맵에는 상한선이 없어요. 자격 조건에 맞는 모든 채용 공고가 포함돼요. 크롤링 예산 배분을 보면 Google이 이 사이트에서 가장 가치 있다고 판단하는 콘텐츠가 무엇인지 알 수 있어요.

블로그 글은 가장 높은 품질의 콘텐츠임에도 하루 298회만 크롤링돼요. 크롤링 투자 비율(채용이 블로그보다 50배)과 콘텐츠 투자 비율(블로그가 페이지당 채용보다 100배 더 많은 노력 필요)이 일치하지 않아요. 검색 엔진은 가장 많은 노력이 들어간 것이 아니라, 대규모로 인덱싱할 수 있는 것을 크롤링해요.

회사 페이지는 사이트맵에 7,000개 이상 있음에도 하루 14회만 크롤링돼요. 크롤링 예산 고갈 문제예요: 채용 페이지가 예산을 너무 많이 소비해서 회사 페이지는 거의 발견되지 않아요. 야간 데이터가 이 문제를 드러냈어요. 인구조사가 없었다면 7,000개의 회사 페이지가 크롤러에게 사실상 보이지 않는다는 걸 몰랐을 거예요.

410이 알려주는 것

인구조사는 HTTP 상태 코드를 추적해요. 가장 흥미로운 상태 코드는 410: Gone이에요.

Google 410s:  7,614  (35.5% of crawls)
Bing 410s:    4,494  (42.3% of crawls)

전체 크롤러 요청의 3분의 1 이상이 410을 반환하는 만료된 채용 페이지에 도달해요. 크롤러가 처음 발견했을 때 존재했고, 인덱싱되었다가 이후 삭제된 채용 공고예요. 410은 크롤러에게 “이 페이지는 존재했지만 영구적으로 사라졌으니 더 이상 요청하지 마세요”라고 알려줘요.

410 비율은 감소하고 있어요. 지난주 Google의 경우 8,858이었는데 이번 주는 7,614예요. 크롤러가 학습하고 있어요. 매일 검색 엔진이 인덱스를 업데이트하면서 유령 요청 수가 줄어들어요. 하지만 학습은 느려요. Bing의 410 비율(42.3%)이 Google(35.5%)보다 높은 이유는 Bing이 제거 신호를 더 느리게 처리하기 때문이에요.

410 추세는 가장 명확한 야간 신호예요. 검색 엔진이 사이트의 현재 상태에 얼마나 빠르게 수렴하고 있는지 알려줘요. 410 비율이 증가하면 크롤러가 적응할 수 있는 속도보다 빠르게 콘텐츠를 제거하고 있다는 뜻이에요. 410 비율이 감소하면 인덱스가 따라잡고 있다는 뜻이에요. 균형점은 410이 0인 상태, 즉 크롤러가 요청하는 모든 페이지가 여전히 존재하는 상태예요.

524 문제

Cloudflare는 오리진 서버가 타임아웃 시간 내에 응답하지 않으면 524를 반환해요. 대규모 배포일(커밋 87개)에 인구조사는 다음과 같은 결과를 보여줬어요:

Google 524s:  68  (0.3%)
Bing 524s:    0

24시간 동안 68건의 오리진 타임아웃이에요. 각각은 Googlebot이 페이지를 요청하고, Cloudflare가 Railway에 요청을 전달했지만 Railway가 제시간에 응답하지 못했다는 뜻이에요. 가장 유력한 원인은 잦은 배포 중 Railway 워커 재시작이었어요. 각 배포가 애플리케이션을 재시작하면서 요청이 타임아웃되는 짧은 시간대가 생겨요.

크롤링의 0.3%에서 Google은 깨진 사이트를 봤어요. 524 오류는 어떤 애플리케이션 로그에도 나타나지 않았어요. 오류가 발생할 때 애플리케이션이 실행되고 있지 않았으니까요. 이 오류는 Cloudflare와 Railway 사이의 틈에만 존재했고, 크롤링 인구조사를 통해서만 확인할 수 있었어요.

다음 날 아침 524 건수는 0으로 떨어졌어요. 배포가 멈췄고 워커가 안정됐어요. 야간 데이터가 이 문제가 구조적 문제가 아니라 일시적인 배포 혼잡이었음을 확인해줬어요.

워밍 패스

크롤러가 도착하기 전에 워밍 패스가 실행돼요. 모든 블로그 글, 모든 로케일 변형, 50개의 회사 페이지를 Cloudflare 엣지 캐시를 통해 가져와요. 목표는 Googlebot이 페이지에 접근할 때 오리진 렌더링을 기다리지 않고 캐시된 응답을 받도록 하는 거예요.

이 차이가 중요해요. 캐시된 블로그 글은 80ms에 반환돼요. 캐시되지 않은 블로그 글은 오리진에서 1.5초가 걸려요. Googlebot은 초당 요청 수로 측정되는 크롤링 속도 예산이 있어요. 응답이 빠르면 같은 시간에 더 많은 페이지를 크롤링할 수 있어요. 캐시 워밍은 실질적인 크롤링 커버리지를 두 배로 늘려줘요.

워밍 패스는 사용자에게 보이지 않아요. 새벽 2시에 캐시된 블로그 글로 혜택을 받는 사람은 없어요. 하지만 워밍 패스가 Googlebot이 야간 시간대에 블로그 글을 300개 발견할지 600개 발견할지를 결정해요. 사람이 그 메커니즘을 보지 못해도 SEO 영향은 실재해요.

밤이 보여주는 것

매일 아침 야간 로그를 읽어요. 패턴은 늘 같아요: 대부분 정상, 몇 가지 이상 징후, 한두 가지 조사할 만한 것. 리듬은 지루해요. 가치는 바로 그 지루한 리듬에 있어요.

지루한 밤은 배포가 아무것도 깨뜨리지 않았고, 크롤러가 기대한 것을 찾았고, 캐시가 작동하고 있고, 사이트가 다음 날 트래픽을 맞을 준비가 됐다는 뜻이에요. 흥미로운 밤은 뭔가 변했다는 뜻이에요: 새로운 오류 패턴, 작동을 멈춘 캐시 규칙, 랭킹 신호 변화를 나타내는 크롤링 예산 이동.

크롤링 인구조사는 7,000개의 회사 페이지가 Google에 보이지 않는다는 걸 보여줬어요. 낮 시간의 어떤 지표로도 이걸 알 수 없었을 거예요. 사용자 분석에서 회사 페이지 트래픽이 0인 건 수요가 낮기 때문이라고 생각했어요. 인구조사에서 회사 페이지 크롤링이 0인 건 Google이 페이지를 아직 평가조차 하지 않았다는 뜻이에요. 문제는 수요가 아니라 발견이에요.

524 분석은 Railway 배포가 Googlebot이 걸리는 오리진 타임아웃 구간을 만든다는 걸 보여줬어요. 어떤 애플리케이션 모니터링으로도 이걸 발견할 수 없었을 거예요. 타임아웃 중에 애플리케이션이 실행되지 않으니까요. 문제는 배포와 가용성 사이의 인프라 틈에 존재해요.

410 추세는 Bing이 Google보다 제거 신호를 20% 느리게 처리한다는 걸 보여줬어요. SEO에 중요해요: 만료된 채용 페이지가 Bing 인덱스에 더 오래 남아서, Bing 기반 서비스(DuckDuckGo, Yahoo)에서 검색하는 사용자에게 오래된 결과를 제공할 수 있어요.

이 인사이트들은 모두 야간 데이터에서 나왔어요. 낮은 사용자가 무엇을 하는지 알려줘요. 밤은 아무도 지켜보지 않을 때 인프라가 무엇을 하는지 알려줘요. 둘 다 중요하지만, SEO에는 밤이 더 중요해요.

FAQ

크롤링 인구조사는 어떻게 실행하나요?

인구조사는 Cloudflare의 GraphQL 분석 API(httpRequestsAdaptiveGroups)을 사용자 에이전트 패턴(%Googlebot%, %bingbot%)으로 필터링해서 사용해요. URL 경로 접두사별로 페이지를 분류하고 상태 코드를 집계해요. 스크립트는 30초 만에 실행되어 Google과 Bing 크롤링 동작을 나란히 비교한 결과를 만들어요.

크롤링 데이터에 Google Search Console을 사용하지 않는 이유는?

Google Search Console은 크롤링 통계를 2~3일 지연과 제한된 세분화로 보고해요. Cloudflare 인구조사는 실시간(지난 24시간)이며, GSC가 보고하지 않는 상태 코드, 콘텐츠 카테고리, 캐시 상태를 포함해요. GSC는 추세 파악에 유용하고, 인구조사는 운영 판단에 유용해요.

워밍 패스가 Cloudflare 비용을 증가시키나요?

아니요. Cloudflare 캐시는 출처에 관계없이 어떤 요청으로든 채워져요. 워밍 패스는 일반 요청 할당량에 포함되는 표준 HTTP 요청을 사용해요. 무료 플랜에서 캐시된 응답에 대한 요청 제한은 없어요. 워밍 패스 중 오리진 요청은 Railway의 대역폭에 포함되지만, 15,000페이지 평균 50KB 기준 워밍 패스당 약 750MB예요.

크롤러가 동작을 바꾸면 어떻게 되나요?

인구조사는 변경 여부에 관계없이 크롤러가 하는 모든 것을 포착해요. 크롤링 패턴의 변화(채용 페이지 증가, 블로그 페이지 감소)는 다음 인구조사에 즉시 나타나요. 여러 날에 걸친 추세 데이터로 그 변화가 일회성 이상인지 지속적 변화인지 파악할 수 있어요.

출처

이 글은 2026년 3월부터 Cloudflare GraphQL API을 통해 수집한 일일 크롤링 인구조사 데이터를 바탕으로 작성됐어요. 인구조사 도구: ~/Projects/Utility/crawl_census.py. 야간 점검 도구: ~/.claude/skills/nightcheck/.