정적 블로그를 운영하다 보면 GitHub Actions로 배포 자동화를 붙이고 싶어집니다. 하지만 Daejin Lab처럼 Astro와 Cloudflare Pages를 쓰는 경우, 처음부터 GitHub Actions가 꼭 필요한 것은 아닙니다.

이미 GitHub에 push하면 Cloudflare Pages가 빌드와 배포를 처리할 수 있기 때문입니다. 지금 단계에서 더 중요한 것은 “배포를 더 자동화하는 것”이 아니라 “배포 전에 어떤 검사를 반복할지 정하는 것”이었습니다.

먼저 나눠볼 것

배포 자동화는 크게 두 단계로 나눠서 봐야 합니다.

빌드가 성공하는지 확인하는 자동화
성공한 결과를 실제 사이트에 배포하는 자동화

이 둘을 한 번에 묶으면 문제가 생겼을 때 원인을 찾기 어렵습니다. 처음에는 로컬에서 npm run build를 통과시키고, 그다음 GitHub와 Cloudflare Pages의 배포 로그를 확인하는 흐름이면 충분합니다.

이번 Daejin Lab 작업에서도 실제 기준은 단순했습니다.

npm run build
/sitemap.xml 200 확인
/sitemap-index.xml 200 확인
/robots.txt 200 확인
대표 글 URL 200 확인
Search Console에는 /sitemap.xml만 우선 제출

이 기준은 Cloudflare Pages 배포 후 꼭 확인하는 체크리스트와 이어집니다.

GitHub Actions가 필요한 순간

GitHub Actions는 아래 같은 경우에 의미가 커집니다.

push 전에 빌드 검증을 자동으로 하고 싶을 때
링크 깨짐이나 sitemap 검사를 반복하고 싶을 때
글 frontmatter 규칙을 검사하고 싶을 때
이미지 최적화나 별도 생성 작업이 필요할 때
여러 사이트를 같은 규칙으로 관리할 때

단순히 “자동화가 멋있어 보여서” 붙이는 것은 오히려 유지보수 부담이 됩니다. 특히 개인 블로그 초반에는 자동화 파일을 관리하는 시간보다 글 품질과 검색 확인에 쓰는 시간이 더 중요했습니다.

지금 단계에서의 운영 기준

Daejin Lab 초기 운영에서는 GitHub Actions를 배포 도구로 쓰기보다, 검증 도구로 보는 편이 맞습니다.

로컬: 글 작성, npm run build
GitHub: 변경 이력 저장
Cloudflare Pages: 실제 배포
GitHub Actions: 나중에 반복 검증 자동화

Search Console이나 sitemap 이슈가 있는 시기에는 자동화보다 공개 URL 확인이 더 중요합니다. 실제로 sitemap이 “가져올 수 없음”으로 보였을 때도 GitHub Actions를 추가하는 것보다, curl로 공개 URL의 상태 코드와 content-type을 확인하는 편이 먼저였습니다.

나중에 넣을 수 있는 검증

글이 30개를 넘고 운영이 반복되면, GitHub Actions에 아래 검사를 붙일 수 있습니다.

npm run build
sitemap 파일 생성 여부
RSS 파일 생성 여부
필수 페이지 존재 여부
draft: false 글 개수 확인
카테고리별 글 개수 확인
내부 링크 대상 존재 여부
대표 URL의 canonical 확인

이 정도만 자동화해도 실수는 많이 줄어듭니다. 예를 들어 카테고리를 추가했는데 src/content.config.ts의 enum을 갱신하지 않았거나, 글 안의 내부 링크가 잘못된 경우를 push 전에 잡을 수 있습니다.

남긴 기준

GitHub Actions는 배포를 복잡하게 만들기 위한 도구가 아니라, 반복 검증을 줄이기 위한 도구로 쓰는 편이 좋습니다.

지금은 Cloudflare Pages 자동 배포 흐름을 유지하고, 다음 단계에서 빌드·sitemap·내부 링크·frontmatter 검사를 Actions로 옮기는 방식이 적당합니다. 자동화는 사이트가 어느 정도 안정된 뒤에 붙여도 늦지 않습니다.