Cloudflare Pages 빌드 후 매번 실행하는 3가지 배포 후 점검 사항

저는 프로덕션 이슈를 디버깅하는 데 2주를 보냈습니다.

사이트맵 규칙이 인덱스 파일을 차단했고, 레이스 컨디션(race condition)으로 인해 이미지 업로드 실패가 발생했습니다. 이러한 문제들은 배포 후에만 나타났습니다.

이제 저는 매 빌드 후에 세 가지 특정 점검을 실행합니다. 전체 테스트 스위트를 사용하지는 않습니다. 대신 실제 실패 지점을 겨냥한 빠른 점검을 사용합니다.

저는 Astro 5 SSG로 구축된 세 개의 사이트(aiappdex.com, findindiegame.com, ossfind.com)에서 이 점검을 실행합니다.

1. 사이트맵 가용성 및 무결성

모든 도메인에서 sitemap-index.xml이 200 상태 코드를 반환하는지 확인합니다.

또한 sitemap-0.xml도 확인합니다. URL 개수가 최소 임계값을 충족하는지 확인하는데, aiappdex.com의 경우 그 임계값은 1,000입니다. 만약 이보다 낮아지면 데이터 파이프라인에 문제가 생긴 것입니다.

저는 이를 뼈아픈 경험을 통해 배웠습니다. 잘못된 리다이렉트 규칙이 브라우저에서는 잘 작동했지만 크롤러를 차단했습니다. curl을 사용하여 상태 코드를 확인함으로써 즉시 오류를 잡아낼 수 있었습니다.

2. IndexNow 제출

사이트맵 점검을 통과하면, IndexNow에 URL을 제출하는 스크립트를 실행합니다. 이를 통해 Bing, Yandex, Naver, Seznam에 새로운 콘텐츠가 있음을 알립니다.

만약 IndexNow가 403 에러를 반환한다면, 키 검증 파일이 누락되었거나 리다이렉트 규칙이 경로를 깨뜨리고 있는 것입니다. 이를 조기에 발견하면 인덱싱 지연을 방지할 수 있습니다.

저는 배포 후에 이를 수동으로 실행합니다. 이를 통해 실제 서비스 중이며 안정적인 URL만 제출되도록 합니다.

3. Lighthouse 트렌드 모니터링

매주 월요일마다 정기적으로 Lighthouse 점검을 실행합니다. 이 점검은 성능, 레이아웃 이동(layout shifts), 접근성을 확인합니다.

저는 단순한 실패보다는 트렌드를 관찰합니다. 점수가 약간 떨어진다고 해서 배포를 차단하지는 않습니다. 대신 이 결과를 활용하여 Tailwind 설정이나 레이아웃 컴포넌트에서 발생하는 회귀(regression) 현상을 찾아냅니다.

왜 이 세 가지일까요?

Cloudflare를 신뢰하기 때문에 업타임(uptime) 모니터링은 사용하지 않습니다. 사이트가 정적이기 때문에 엔드 투 엔드(end-to-end) 테스트도 사용하지 않습니다. 정적 CDN 배포의 경우, 이 세 가지 점검만으로도 주요 리스크를 충분히 커버할 수 있습니다.

출처: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-3a61