처음에는 블로그 글 하나를 조금 더 편하게 확인하고 싶었을 뿐이다.
AI와 함께 원고를 작성하고 HTML 파일을 만들어 받아보는 방식이었다. 문장을 수정하면 새 파일을 받고, 그림을 바꾸면 다시 파일을 열었다. PC에서는 괜찮아 보이던 화면이 스마트폰에서는 어색하게 나타나기도 했다.
그때마다 새 파일을 만들고 이전 파일과 비교해야 했다. 작업이 반복될수록 어떤 파일이 최종본인지도 헷갈리기 시작했다.
글을 쓰는 일보다 파일을 주고받는 일이 더 번거로워질 때도 있었다.
하나의 글이 여러 편의 이야기로 늘어났다
스마트홈 경험을 정리하면서 이런 불편함이 더 크게 느껴졌다.
처음에는 하나의 글로 시작했지만, 도어락과 스마트 버튼, 실패했던 플러그, 조명 자동화 같은 경험을 정리하다 보니 여러 편의 이야기가 되었다.
각 글에 설명용 그림을 넣고, 모바일 화면도 함께 고려해야 했다. AI가 만든 도식이 실제 브라우저에서 예상과 다르게 표시되는 문제도 있었다.
이제는 단순히 글 한 편을 만드는 일이 아니었다. 여러 원고와 디자인을 동시에 관리하는 방법이 필요했다.
GitHub 브랜치가 원고 검수 공간이 될 수 있을까?
나는 개발하면서 GitHub를 사용하고 있었지만, 브랜치를 주로 코드 수정과 기능 테스트를 위한 공간으로 생각했다.
그런데 블로그 원고도 Markdown 파일이라면 브랜치에서 관리할 수 있지 않을까?
GitHub Private 저장소의 별도 브랜치에 원고를 올리고, Markdown을 직접 읽으면서 문장을 검수하는 방법을 생각했다. 그다음 Cloudflare Preview에서 실제 화면을 확인하고, 최종 승인 후 main에 병합하면 될 것 같았다.
처음에는 꽤 좋은 방법이라고 생각했다.
하지만 한 가지 문제가 있었다.
Cloudflare에 브랜치별 Preview 자동 배포가 연결되어 있다면 GitHub에 원고를 Push하는 순간 Preview가 만들어질 수 있었다.
나는 원고를 먼저 읽고 싶은 것이지, 원고를 저장할 때마다 웹사이트를 배포하고 싶은 것은 아니었다.
원고 검수용 브랜치만 자동 배포 대상에서 제외하는 방법도 알아봤다. 가능하더라도 브랜치 이름과 배포 예외 규칙을 계속 관리해야 한다는 점이 마음에 걸렸다.
편해지려고 시작한 일에 새로운 관리 작업을 만들고 싶지는 않았다.
비공개 Preview도 생각해 봤다
다른 방법은 Cloudflare Preview 자체를 비공개로 만드는 것이었다.
Cloudflare Zero Trust의 Access를 이용하면 허용된 계정만 접근하는 방식으로 구성할 수 있었다.
그런데 설정을 살펴보다가 신용카드 등록이 필요하다는 화면을 만났다.
무료로 사용할 수 있는 범위가 있다는 설명도 있었지만, 현재의 블로그 검수를 위해 결제 수단까지 등록하고 싶지는 않았다.
내가 원하는 기능은 복잡하지 않았다. 원고를 편하게 읽고, 실제 디자인을 확인한 다음, 괜찮으면 발행하는 것이 전부였다.
Zero Trust가 나쁜 해결책이라는 뜻은 아니다. 접근 제한이 꼭 필요한 프로젝트라면 충분히 고려할 방법이다. 다만 지금 내게는 해결하려는 문제보다 설정 과정이 더 커지는 느낌이었다.
결국 비공개 Preview 구성은 검토 단계에서 멈췄다.
다시 처음으로 돌아가 보니 답이 단순했다
처음에 해결하고 싶었던 문제를 다시 생각했다.
HTML 파일을 계속 주고받지 않으면서, 원고와 실제 화면을 편하게 검토하고 싶었던 것이다.
그렇다면 원고를 검수하기 전에 GitHub에 올릴 필요가 있을까?
어차피 글은 AI와 채팅하면서 만들고 있었다.
채팅에서 원고를 보여주고 문장을 수정한 뒤, 내용이 완성되었을 때만 작업 브랜치에 Push하면 되는 일이었다.
그다음에는 Cloudflare Preview에서 화면을 검토하고, 디자인 수정이 끝나면 main에 병합하면 된다.
정리하면 다음과 같은 방식이다.
AI와 원고 작성 → 채팅에서 문장 검수 → 원고 승인 → GitHub 브랜치 Push → Cloudflare Preview 디자인 검수 → main 병합 → Preview 정리
처음 고민했던 Private Markdown 검수용 브랜치도, 브랜치별 배포 제외 규칙도 필수는 아니었다.
단, Access를 적용하지 않은 Preview는 공개적으로 접근할 수 있다는 사실을 잊지 않아야 한다. 따라서 Preview에는 외부 공개를 감당할 수 있는 내용만 올리기로 했다.
마지막 배포가 남는다는 것도 알게 됐다
Preview를 사용하다 보니 또 다른 의문이 생겼다.
작업 브랜치를 main에 병합하면 Preview는 어떻게 될까?
처음에는 운영 사이트에 반영되면 Preview 주소가 더는 필요 없으니 자연스럽게 없어질 것이라고 생각했다.
하지만 Preview는 운영 사이트와 별개의 배포 결과다. 병합 이후에도 마지막으로 배포한 화면이 남아 있을 수 있다.
운영 블로그는 계속 바뀌는데 오래된 Preview는 이전 화면을 보여주는 셈이다.
그래서 최종 운영 방식에 한 가지를 더 추가했다.
main 병합 후 운영 배포를 확인하고, 사용이 끝난 Preview를 정리하는 것이다.
이 과정은 GitHub Actions로 자동화하는 방향도 검토하기로 했다. 다만 실제 삭제 방식은 Cloudflare의 Preview 유형을 확인한 뒤 적용해야 한다.
도구를 더 쓰는 것이 항상 개선은 아니었다
처음에는 HTML 파일을 주고받는 불편함에서 출발했다.
그런데 하나의 질문이 GitHub 브랜치, 자동 배포, Cloudflare Preview, Zero Trust, GitHub Actions까지 이어졌다.
새로운 기능을 알아가는 과정은 재미있었다. 동시에 모든 기능을 사용해야만 더 좋은 운영 방식이 만들어지는 것은 아니라는 사실도 느꼈다.
내가 원하는 것은 기술적으로 가장 복잡한 시스템이 아니다. 실제로 계속 사용할 수 있는 간단한 작업 방식이다.
앞으로도 필요하다면 더 많은 자동화를 도입할 수 있을 것이다. 하지만 지금은 원고 검수와 디자인 검수를 분리하는 것만으로도 처음의 불편함을 상당 부분 줄일 수 있다.
작은 불편함 하나에서 시작한 생각이 결국 블로그를 만드는 방식까지 바꾸게 되었다.