Hugo

Cloudflare 이전의 첫 단계는 “GitHub에 커밋하면 Cloudflare가 알아서 Hugo를 돌려 배포한다"를 만드는 것이었다. Workers Builds는 저장소를 연결하면 빌드 명령과 배포 명령을 실행해 준다. 간단해 보였지만, 폰에서 만들던 결과물과 똑같이 나오게 하려면 네 가지를 못 박아야 했다. 빌드 명령은 스크립트 하나로 wrangler.jsonc의 build.command에 bash scripts/cf-build.sh를 넣었다. Cloudflare 빌드 환경에는 Hugo가 없으므로 스크립트가 직접 내려받는다. PIN="${MHUB_HUGO_VERSION:-0.154.5}" curl -fsSL -o hugo.tar.gz \ "https://github.com/gohugoio/hugo/releases/download/v${PIN}/hugo_extended_${PIN}_linux-amd64.tar.gz" tar -xz -f hugo.tar.gz hugo export TZ=Asia/Seoul hugo --minify 버전 변수 이름을 HUGO_VERSION이 아니라 MHUB_HUGO_VERSION으로 한 데는 이유가 있다. Cloudflare 대시보드의 빌드 변수에 HUGO_VERSION이 있으면 플랫폼이 그 값을 다른 의미로 읽을 수 있어서, 내 스크립트만 읽는 전용 이름을 쓰는 편이 안전했다.

이 블로그는 한동안 루팅한 갤럭시 S9 한 대가 전부 떠받치고 있었다. Hugo로 만든 정적 파일을 폰 안의 Caddy가 내보내고, 글쓰기 화면과 조회수·댓글 API는 폰 안의 Node 서버가 처리하고, 바깥과는 Cloudflare Tunnel로 이어져 있었다. 잘 돌았지만 “폰이 꺼지면 블로그도 꺼진다"는 사실이 늘 마음에 걸렸다. 2026년 10월 10일, 이 구조를 끝내기로 했다. 이 글은 그 결정의 이유와 계획이고, 이어지는 시리즈는 실제로 옮기면서 겪은 일들이다. 왜 지금이었나 계기는 두 가지였다. 하나는 폰 쪽 감시 스크립트가 블로그 터널을 닷새 동안 17번이나 재시작한 기록을 본 것이다. 서비스는 대체로 살아 있었지만, 사람이 없을 때 폰 혼자 버티는 구조는 언제든 조용히 멈출 수 있었다. 다른 하나는 내가 AI 코딩 세션을 길게 쓰는 기간이 끝나간다는 점이었다. 그 전에 블로그를 “혼자서도 운영할 수 있는 모양"으로 만들어 두고 싶었다. 폰 안의 tmux 세션과 크론과 셸 스크립트를 유지보수하는 것보다, 관리 화면에서 글을 쓰고 GitHub에 저장되고 알아서 배포되는 쪽이 훨씬 단순하다.

지금 보고 계신 이 블로그(blog.mhub.uk) 자체가 이 시리즈의 소재입니다. Hugo 정적 사이트 생성기와 PaperMod 테마로 시작해서, 최근에는 카테고리 사이드바·추천글·전체 글 목록으로 이루어진 3분할 홈 화면으로 직접 레이아웃을 손봤습니다. 왜 Hugo인가 Hugo는 빌드마다 서버 자원을 거의 쓰지 않는 정적 사이트 생성기입니다. 휴대폰처럼 자원이 넉넉하지 않은 환경에서는 매 요청마다 서버 사이드 렌더링을 하는 방식보다, 미리 HTML을 만들어 두고 Caddy가 그냥 파일을 서빙하는 쪽이 훨씬 가볍습니다. 글을 쓰거나 설정을 바꿀 때만 hugo --minify로 다시 빌드하면 끝입니다.