Astro와 Cloudflare Pages로 개인 정적 블로그를 시작한 이유

처음부터 정적 블로그가 정답이라고 확신한 건 아니었습니다. 티스토리나 워드프레스처럼 익숙한 선택지도 있었고, 관리 화면이 있는 도구가 편해 보이기도 했습니다.

그런데 Daejin Lab은 글을 쓰는 블로그이면서 동시에 제 작업 방식을 실험하는 공간이었습니다. Markdown 파일, Git 커밋, Cloudflare Pages 배포 흐름을 직접 잡아두면 나중에 다른 블로그에도 복제하기 쉽겠다고 봤습니다.

실제 구성

이 글을 업데이트한 시점의 구성은 아래와 같습니다.

프로젝트: daejin-lab-blog
프레임워크: Astro
콘텐츠: Markdown
저장소: GitHub private repo
배포: Cloudflare Pages
초기 공개 주소: https://daejin-lab-blog.pages.dev
현재 production 주소: https://daejinlab.com
빌드 명령: npm run build
출력 폴더: dist
Node 버전: 22 계열

초기에는 커스텀 도메인을 바로 붙이지 않고 pages.dev 주소로 Search Console까지 연결했습니다. 이후 production 기준은 https://daejinlab.com으로 정리했고, canonical과 sitemap도 현재 도메인을 기준으로 맞췄습니다.

좋았던 점

정적 블로그는 구조가 단순합니다.

서버 관리가 거의 없다.
HTML을 미리 만들어 CDN에서 제공한다.
Markdown 파일로 글을 관리할 수 있다.
GitHub 이력으로 변경사항이 남는다.
Cloudflare Pages 무료 범위에서 시작할 수 있다.

개인 프로젝트에서는 이 단순함이 중요했습니다. 글을 쓰는 것보다 배포와 유지보수에 시간이 빨려 들어가면 오래 운영하기 어렵습니다.

실제로 불편했던 점

장점만 있지는 않았습니다. 초반에 막힌 부분은 대부분 글 작성이 아니라 주변 설정이었습니다.

Cloudflare에서 Workers와 Pages 화면을 헷갈림
GitHub HTTPS 인증이 자동화 세션에서 막힘
Search Console sitemap이 처음에 다른 도메인을 가리킴
Astro site 설정과 robots.txt 주소를 다시 맞춤

특히 sitemap 문제는 예상보다 오래 봤습니다. 처음에는 파일이 없는 줄 알았지만, 실제 원인은 URL 기준값이었습니다.

기존 후보: https://daejinlab.com/sitemap-index.xml
초기 기준: https://daejin-lab-blog.pages.dev/sitemap.xml
현재 기준: https://daejinlab.com/sitemap.xml

Search Console 속성은 pages.dev로 등록했는데 sitemap 안쪽 주소가 다른 도메인을 가리키면 문제가 생깁니다. 정적 블로그는 서버가 없어도 이런 기준값은 직접 맞춰야 합니다.

확인한 명령어

배포 전에는 로컬에서 먼저 빌드합니다.

npm run build

그리고 sitemap 파일도 확인합니다.

dist/sitemap.xml
dist/sitemap-index.xml
dist/sitemap-0.xml

예전 빌드에서는 공개 URL 수를 숫자로 세어 보며 Search Console 화면의 지연인지, 사이트 파일 문제인지 나눠봤습니다. 지금은 글 수가 계속 바뀔 수 있어서 공개 글 안에 숫자를 고정하기보다, npm run brief:ops -- --markdown 같은 read-only 점검으로 그때그때 확인합니다.

이번 배포 흐름에서 다시 확인한 것

실제로 운영하면서 가장 자주 확인한 것은 화려한 기능이 아니라 아래 항목이었습니다.

npm run build

초기에는 Astro 정적 빌드 산출물과 공개 주소를 pages.dev 기준으로 봤습니다. 이후 커스텀 도메인 전환 뒤에는 현재 production 주소인 https://daejinlab.com 기준으로 sitemap과 canonical을 다시 봤습니다. 검색 등록 문제가 남아 있을 때는 URL 기준을 자주 흔들지 않는 편이 안전하다고 판단했습니다.

또 하나 배운 점은 배포와 발행을 분리해야 한다는 것입니다. 로컬에서 빌드가 성공해도, GitHub push와 Cloudflare 반영은 별도 단계입니다. 그래서 다음 작업부터는 로컬 수정 → 빌드 확인 → 커밋 → 승인 후 push → 공개 URL 확인 순서로 고정하려고 합니다.

이 배포 흐름은 Cloudflare Pages 배포 후 꼭 확인하는 체크리스트와 robots.txt와 canonical을 점검하며 확인한 색인 기본 조건에서 계속 이어서 점검합니다. Search Console 쪽 대기 기준은 사이트맵이 정상인데 Search Console은 실패할 때 다음에 한 일에 따로 남겼습니다.

WordPress 대신 이 구조를 고른 이유

WordPress는 관리자 화면과 플러그인이 강점입니다. 반대로 여러 블로그를 작게 실험하려는 입장에서는 업데이트, 보안, 플러그인 관리가 부담이 될 수 있습니다.

Astro 방식은 글 작성과 배포 흐름을 직접 만들어야 하지만, 한 번 구조를 잡으면 복제하기 쉽습니다. Daejin Lab을 1호 블로그로 만든 이유도 여기에 있습니다. 나중에 2호, 3호 블로그를 만들 때 같은 운영 구조를 가져갈 수 있는지 보려는 실험입니다.

다음에 볼 것

지금 남긴 기준은 도메인 전환 전후를 섞지 않는 것입니다. 도메인을 붙이는 순간에는 아래를 한 번에 다시 맞춰야 합니다.

astro.config.mjs의 site 값
robots.txt의 sitemap 주소
Search Console 속성
canonical URL
외부 링크와 RSS 주소

정적 블로그는 가볍지만, URL 기준값 하나를 잘못 잡으면 검색엔진 등록 단계에서 시간을 많이 씁니다. 이 부분은 다음 블로그를 만들 때 가장 먼저 체크할 항목으로 남겨둘 생각입니다.

지금은 이렇게 보고 있다

Astro와 Cloudflare Pages를 고른 이유는 화려한 기능 때문이 아니었습니다. 작게 시작하고, 파일로 남기고, 문제가 생기면 어디서 깨졌는지 추적하기 쉬웠기 때문입니다.

물론 관리형 블로그보다 손이 더 갑니다. 대신 제가 무엇을 고쳤고 언제 배포했는지가 Git에 남습니다. Daejin Lab 같은 실험형 블로그에는 그 투명함이 더 중요했습니다.

개인 블로그 운영에서 중요했던 점

이 글은 Astro 사용법만 설명하는 글이면 약합니다. 이미 Astro 튜토리얼은 많기 때문입니다. 제가 이 글에서 보여줘야 하는 건 “왜 굳이 귀찮은 정적 블로그를 택했는가”였습니다.

장기 운영을 생각하면 관리 화면이 편한 플랫폼도 매력적입니다. 그래도 저는 파일, Git, 빌드, 배포 로그가 남는 쪽을 골랐습니다. 검색 문제가 생겼을 때, 무엇을 언제 바꿨는지 되짚을 수 있어야 했기 때문입니다. 이 기록성이 Daejin Lab의 신뢰 포인트라고 봅니다.

편한 도구 대신 귀찮은 쪽을 고른 이유

정적 블로그는 처음부터 편하지 않았습니다. 글 하나를 고쳐도 파일, Git, 빌드, 배포를 같이 봐야 했습니다. 그래도 그 귀찮음 덕분에 제가 뭘 바꿨는지 남았습니다. 개인 블로그를 오래 운영하려면 편한 발행 버튼보다 되돌릴 수 있는 기록이 더 필요하다고 판단했습니다.

2026-05-23 기준으로 다시 그린 구조

AdSense 등록 후 이 글을 다시 읽어보니, 단순히 “Astro가 좋다”는 설명보다 Daejin Lab이 왜 이 구조를 택했는지 보여주는 그림이 필요했습니다. 지금 제 기준은 아래 흐름입니다.

Daejin Lab의 공개 글은 Markdown 파일에서 시작해 Astro 빌드와 Cloudflare Pages를 거쳐 daejinlab.com에 반영됩니다. 중간에 git push와 공개 반영은 사람이 승인하는 단계로 남깁니다.

이 구조를 택한 이유는 편해서가 아니었습니다. 오히려 처음에는 더 귀찮았습니다. 파일을 고치고, 빌드를 돌리고, 배포 결과를 다시 확인해야 했습니다. 그래도 그 과정이 기록으로 남는다는 점이 좋았습니다.

현재 공개 표면을 숫자로만 보지 않기

이 글의 예전 문장에는 당시 빌드 숫자가 남아 있었습니다. 지금은 글 수가 바뀔 수 있기 때문에, 공개 글 안에 숫자를 무리하게 고정하지 않기로 했습니다. 다만 보강 시점의 read-only 점검값은 기록으로 남깁니다.

이 숫자는 2026-05-23 KST 보강 시점의 운영 점검값입니다. 공개 글에서는 숫자보다 “어떤 항목을 확인했는지”를 더 중요하게 봅니다.

참고한 공식 문서는 아래입니다.

• Astro Docs — Deploy your Astro site to Cloudflare
• Cloudflare Docs — Deploy an Astro site
• Cloudflare Docs — Build configuration

지금 다시 고른다면 무엇을 먼저 볼까

처음 블로그를 만들 때는 “어떤 플랫폼이 좋은가”를 고민했습니다. 지금은 질문이 조금 바뀌었습니다.

문제가 생겼을 때 원인을 되짚을 수 있는가?
글과 배포 이력이 남는가?
검색/광고/신뢰 페이지를 한 곳에서 검증할 수 있는가?
다음 블로그에도 같은 흐름을 옮길 수 있는가?

이 질문에 답하기 쉬운 쪽이 Astro와 Cloudflare Pages였습니다. WordPress나 티스토리가 나쁘다는 뜻은 아닙니다. 다만 Daejin Lab처럼 작업 과정을 글로 남기는 블로그에는 파일과 빌드 기록이 남는 쪽이 더 맞았습니다.

확인한 자료와 기록

이 글은 Daejin Lab을 처음 정적 블로그로 옮기며 확인한 공개 배포 흐름을 기준으로 보강했습니다.

• Astro Docs — Deploy your site to Cloudflare
• Cloudflare Pages Docs — Deploy an Astro site
• Cloudflare Pages Docs — Build configuration
• 2026-05-23 Daejin Lab 공개 배포 확인 기록: 홈, 글 목록, sitemap, RSS, canonical, custom domain 확인

공식 문서는 배포 방법을 확인하는 기준이고, 이 글의 판단은 실제로 Daejin Lab을 운영하면서 남긴 선택 기록입니다.

자주 묻는 질문

개인 블로그도 Astro가 항상 좋은가요?

아닙니다. 관리 화면에서 바로 쓰고 싶고 플러그인으로 해결하고 싶다면 관리형 블로그가 더 편할 수 있습니다. 저는 기록성, 재현성, 배포 흐름을 직접 확인하는 쪽을 더 중요하게 봤습니다.

Cloudflare Pages를 쓰면 SEO가 자동으로 좋아지나요?

아닙니다. 빠른 정적 배포는 장점이지만, sitemap, canonical, robots, 글 품질은 따로 확인해야 합니다. 이 블로그에서도 배포보다 검색 등록 과정에서 더 많이 멈췄습니다.

FAQ

Astro와 Cloudflare Pages 조합의 장점은 무엇인가요?

정적 페이지로 빌드하기 쉽고, GitHub push 이후 배포 흐름을 단순하게 유지할 수 있다는 점입니다. 다만 단순하다고 해서 검증이 사라지는 것은 아닙니다.

배포 후 가장 먼저 확인할 것은 무엇인가요?

홈, 글 목록, 대표 글, sitemap, RSS, 이미지 경로를 먼저 봅니다. 빌드 성공 메시지만으로는 공개 표면을 다 확인했다고 보기 어렵습니다.

AdSense 전에는 무엇을 더 보나요?

draft 노출, review 페이지, staging domain, 얇은 글 목록처럼 보이는지, 공식 출처와 본문 증거가 충분한지를 함께 봅니다.