블로그를 GitHub와 Cloudflare로 운영한다면 새로운 글을 발행하기 전에 실제 웹사이트 디자인을 미리 확인할 수 있다. GitHub 작업 브랜치와 Cloudflare Workers Preview를 이용하는 방식이다.
하지만 GitHub 저장소가 비공개라고 해서 Preview 웹사이트까지 자동으로 비공개가 되는 것은 아니다.
원고 작성부터 운영 배포까지 어떤 방식으로 분리하는 것이 좋을까?
원고 검수와 디자인 검수는 다른 작업이다
블로그 글을 검토할 때는 크게 두 가지를 확인한다.
첫째는 문장과 내용이다. 글의 흐름이 자연스러운지, 사실관계가 정확한지, 불필요한 표현이 없는지 살펴본다. 이 단계에서는 실제 웹페이지가 없어도 Markdown 원고만으로 충분히 검토할 수 있다.
둘째는 디자인과 화면 구성이다. 글자 크기, 이미지 배치, 문단 간격, 모바일 반응형 화면 등을 확인한다. 이때는 실제 웹사이트와 동일한 환경에서 미리보는 것이 편리하다.
두 작업을 하나의 배포 과정에 묶을 필요는 없다.
처음 고려한 방법: GitHub Private 브랜치
처음에는 GitHub의 비공개 저장소에 원고를 먼저 Push하고, GitHub에서 Markdown을 읽으며 검수하는 방법을 생각했다.
그러나 Cloudflare Workers의 Preview Builds가 활성화되어 있으면 비운영 브랜치에 Push할 때 Preview 배포가 자동으로 실행될 수 있다.
원고 검수 단계에서는 배포를 막고, 디자인 검수 단계에서만 배포하려면 브랜치별 빌드 제외 규칙이나 별도의 작업 브랜치 관리가 필요하다.
기술적으로 가능한 방법이지만, 원고를 검토하기 위해 배포 예외 규칙까지 관리하는 것은 번거롭게 느껴졌다.
Preview 접근 제한도 검토했다
Cloudflare Workers Preview는 운영 사이트와 별도로 화면을 확인하는 데 유용하다. 다만 Preview 주소는 기본적으로 외부에서 접근할 수 있다.
이를 제한하기 위해 Cloudflare Zero Trust의 Access 정책도 검토했다. 특정 계정만 Preview에 접속하도록 하는 방법이다.
하지만 설정 과정에서 결제 수단 등록을 요구하는 화면을 마주했고, 신용카드를 등록하면서까지 현재의 개인 블로그 검수 환경을 확장하고 싶지는 않았다. 따라서 Access는 가능성만 검토하고 실제 도입은 보류했다.
이것은 Access에 반드시 유료 요금제가 필요하다는 뜻은 아니다. 현재의 운영 규모와 개인적인 설정 선호를 고려해 선택하지 않았다는 의미다.
접근 제한을 사용하지 않는다면 Preview를 비공개 저장 공간으로 취급해서는 안 된다. 아직 공개되어서는 안 되는 내용이나 인증정보를 Preview에 포함하지 않는 것이 중요하다.
최종 선택: 채팅에서 원고를 먼저 완성한다
복잡한 설정 대신 작업 단계를 분리하기로 했다.
- 원고 작성: ChatGPT에서 Markdown 초안을 작성한다.
- 문장 검수: 같은 채팅에서 글의 흐름과 표현을 수정하고 최종 원고를 승인한다.
- Preview 준비: 승인된 원고를 GitHub 작업 브랜치에 Commit·Push한다.
- 디자인 검수: Cloudflare Preview에서 실제 웹페이지와 모바일 화면을 확인한다.
- 최종 발행: 수정과 검증을 마친 뒤
main에 병합한다. - Preview 정리: 운영 배포를 확인하고 사용이 끝난 Preview를 삭제한다.
이 방식에서는 원고를 검토하기 위해 GitHub에 미리 Push하거나 별도의 배포 제외 규칙을 만들 필요가 없다.
원고가 충분히 정리된 뒤에만 Preview를 생성하므로 불필요한 배포도 줄일 수 있다.
구현할 때 주의할 점
Preview와 Production은 분리된 주소다. 블로그 내부 링크를 /ko/knowledge/ 같은 루트 상대경로로 만들면 두 환경 모두에서 현재 접속한 도메인을 유지할 수 있다. 반면 SEO canonical과 sitemap은 공식 운영 도메인을 사용하는 것이 적절하다.
또한 블로그 생성기가 draft: true인 글을 빌드 대상에서 제외한다면, Preview에서도 해당 글을 볼 수 없을 수 있다. 디자인 검수 대상 원고를 빌드에 포함할 때는 그 결과가 외부에 접근 가능한 상태가 될 수 있다는 점을 먼저 확인해야 한다.
마지막으로 Preview는 main에 병합했다고 자동으로 사라진다고 가정해서는 안 된다. 브랜치의 Preview와 특정 배포 버전의 URL을 구분하고, 지원되는 삭제 기능으로 정리해야 한다.
결국 중요한 것은 도구보다 순서다
GitHub Private, Cloudflare Workers Preview, Cloudflare Access는 각각 유용한 기능이다. 그러나 모든 기능을 처음부터 도입할 필요는 없다.
원고는 배포 전에 검토하고, Preview는 디자인 검수에만 사용하며, 승인한 결과만 운영에 반영한다.
이 원칙만 지켜도 불필요한 설정을 늘리지 않으면서 블로그를 체계적으로 운영할 수 있다.