GitHub Actions로 블로그 배포 자동화를 볼 때의 기준

GitHub Actions를 보면 배포를 전부 자동화하고 싶어집니다. push하면 빌드되고, 배포되고, 확인까지 끝나는 흐름은 확실히 편해 보입니다.

하지만 Daejin Lab에서는 자동화보다 먼저 확인 기준을 정해야 했습니다. 자동으로 빨리 배포되는 것보다, 잘못된 글이나 설정이 그대로 공개되지 않게 막는 게 더 중요했습니다.

먼저 나눠볼 것

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

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

이 둘을 한 번에 묶으면 문제가 생겼을 때 원인을 찾기 어렵습니다. 처음에는 로컬에서 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 또는 sitemap index를 수동 확인 후 제출

이 기준은 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를 추가하는 것보다, 공개 URL의 상태 코드와 content-type을 확인하는 편이 먼저였습니다.

이번 콘텐츠 보강에서 확인한 점

이번 글 보강 작업도 GitHub Actions 없이 로컬 검증으로 충분했습니다. 실제로는 아래 순서만으로도 많은 문제를 잡을 수 있었습니다.

git diff --check
npm run build
astro_static_blog_local_verify.py
static_blog_public_audit.py
수정 글 내부 링크 수 확인
수정 diff 민감정보 패턴 확인

이 정도 검증을 먼저 로컬에서 고정한 뒤, 같은 명령을 GitHub Actions로 옮기는 편이 안전합니다. 처음부터 Actions YAML을 만들면 “무엇을 검사해야 하는지”보다 “워크플로가 왜 실패했는지”에 시간을 쓰게 될 수 있습니다.

내부 링크 검사는 블로그 글 내부 SEO와 관련 글 연결과 연결되고, 검색 노출 기준은 robots, canonical, index 상태 확인 기록과 같이 봐야 합니다.

나중에 넣을 수 있는 검증

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

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

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

지금 남긴 배포 자동화 기준

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

지금은 Cloudflare Pages 자동 배포 흐름을 유지하고, 다음 단계에서 빌드·sitemap·내부 링크·frontmatter 검사를 Actions로 옮기는 방식이 적당합니다. 다만 발행 버튼을 자동화하지 않기로 한 이유에서 정한 것처럼, 글 발행 판단과 콘솔 조작은 자동화 대상에서 분리해두는 것이 안전합니다.

이 카드는 GitHub Actions를 배포 트리거보다 검증 게이트로 쓰는 기준을 한 장으로 정리한 것입니다.

다음 단계에서 Actions에 넣을 최소 검사

지금 Daejin Lab은 Cloudflare Pages 자동 배포만으로도 운영이 가능합니다. 그래서 GitHub Actions를 바로 복잡하게 붙일 필요는 없습니다. 다만 글이 40개가 되고 보강 작업이 반복되기 시작했기 때문에, push 전에 자동으로 잡아주면 좋은 검사는 조금씩 분명해졌습니다.

가장 먼저 넣을 만한 검사는 아래입니다.

npm run build
Markdown frontmatter 필수값 확인
heroImage 경로 존재 확인
본문 1,800자 미만 글 수 출력
내부 링크 대상 파일 존재 확인
sitemap.xml 생성 후 URL 수 확인

이 검사는 발행 판단을 대신하지 않고, 실수를 줄이는 역할만 합니다. 외부 콘솔 조작이나 AdSense 신청은 여전히 자동화 대상이 아닙니다. 이 원칙은 발행 버튼을 자동화하지 않기로 한 이유와 같고, 실제 공개 확인은 Cloudflare Pages 배포 후 꼭 확인하는 체크리스트에서 계속 수동 검증으로 남겨두는 편이 안전합니다.

자동화 전에 남긴 조건

GitHub Actions는 반복 작업을 줄여주는 도구입니다. 다만 검수 기준이 없는 상태에서 붙이면 실수도 빠르게 배포합니다.

다음에 배포 자동화를 더 붙인다면 npm run build, sitemap 확인, 대표 URL 확인 정도는 먼저 통과시키고 싶습니다. 자동화의 목표는 사람을 없애는 게 아니라, 사람이 봐야 할 지점까지 안전하게 데려오는 것이라고 봅니다.

자동화하고 싶은 마음을 한번 눌렀다

GitHub Actions를 붙이면 뭔가 제대로 된 프로젝트처럼 보입니다. 하지만 지금 단계에서는 멋진 자동화보다 단순한 배포 흐름이 더 필요했습니다. 실패했을 때 제가 직접 어디서 막혔는지 찾을 수 있어야 다음 자동화도 안전하게 붙일 수 있습니다.

2026-05-31에 다시 본 배포 자동화의 조건

GitHub Actions로 배포를 자동화하면 편하지만, 블로그에서는 push가 곧 공개가 됩니다. 그래서 이 글은 자동 배포 설정 글이 아니라, 자동화 앞에 어떤 검증을 둬야 하는지 설명하는 글로 보강했습니다.

이 카드는 배포 자동화가 빠른 공개 버튼이 아니라 검증 게이트와 함께 있어야 한다는 기준입니다.

참고한 공식 문서

• GitHub Actions Docs
• GitHub Actions에서 secrets 사용
• Cloudflare Pages — Build configuration

확인하지 않은 것

이 글은 현재 모든 발행을 GitHub Actions에 완전 위임했다는 뜻이 아닙니다. Daejin Lab에서는 build와 검증은 자동화하되, 공개 승인선은 별도로 둡니다.

FAQ

GitHub Actions가 있으면 수동 검수는 필요 없나요?

필요합니다. Actions는 빌드와 테스트를 반복할 수 있지만, 글의 공개 적합성과 민감정보 여부는 사람이 봐야 합니다.

secrets는 어떻게 다뤄야 하나요?

실제 값은 공개 글이나 repo에 넣지 않습니다. 필요하면 GitHub Actions secrets 같은 전용 저장소를 써야 합니다.

블로그 배포에서 가장 먼저 자동화할 것은 무엇인가요?

발행 버튼이 아니라 build, link check, draft/secret 검사 같은 안전 검증입니다.