1602 단어
8 분

Cloudflare Pages로 옮기며, 기록 구조를 다시 정비했습니다

이 글은 AI 도구를 활용하여 블로그 원고 작성 과정의 일부를 보조받았습니다.

요약#

기존 learning-log 프로젝트를 Cloudflare Pages로 전환하고 이름을 workbench로 변경했습니다.

이 과정에서 도메인 구조를 blog와 workbench로 분리하고, 빌드 방식을 로컬 중심으로 재구성했습니다.

템플릿 엔진과 sitemap을 새로 도입하며, 앞으로 콘텐츠 관리 자동화를 염두에 둔 구조로 전환했습니다.


전환의 계기#

learning-log는 GitHub Pages에서 운영하던 개인 기록용 프로젝트였습니다.

정적 사이트로 전환하면서 읽기 중심의 구조를 갖추었지만, 기록을 자주 수정하고 재배포하는 과정에서 점점 빌드 속도와 안정성의 문제가 드러났습니다.

특히 GitHub Actions를 통한 자동 배포 중, 빌드가 대기 상태에서 멈추는 일이 종종 있었습니다.

짧은 글이라도 수정 빈도가 높다 보니, 이러한 지연은 작업 흐름을 끊는 문제로 이어졌습니다.

그런 경험이 쌓이면서 블로그처럼 로컬에서 직접 빌드 후 결과를 배포하는 방식으로 전환하기로 결정했습니다.


Cloudflare Pages로의 이동#

GitHub Pages 대신 Cloudflare Pages를 선택한 이유는 배포 속도와 제어의 단순화를 위해서였습니다.

기존에는 GitHub Actions를 통해 원격 빌드를 수행했지만, 빌드 대기가 길어지는 일이 자주 있었습니다.

이 문제를 해결하기 위해 로컬에서 직접 정적 파일을 빌드하고, 결과물만 Cloudflare Pages로 배포하는 구조로 전환했습니다.

로컬 빌드 방식으로 전환하면서 빌드 환경을 매번 초기화할 필요가 없어졌고, 전체 배포 속도도 한층 빨라졌습니다.

결과적으로 배포 과정이 한결 빠르고 안정적으로 느껴졌습니다.

Cloudflare Pages는 단순히 정적 파일을 그대로 배포하면서도, 전 세계 엣지 네트워크에 빠르게 반영되어 결과가 거의 즉시 업데이트되었습니다.

프로젝트 이름은 learning-log에서 workbench로 변경했습니다.

기록을 단순히 저장하는 공간이 아니라 실험하고 다듬는 작업대로 바라보자는 의미였습니다.

도메인 구조도 새로 정리했습니다.
기존 블로그 주소인 https://hyqrocodryx.kr를 기준으로

  • https://blog.hyqrocodryx.kr은 블로그,
  • https://workbench.hyqrocodryx.kr은 기록 프로젝트용으로 분리했습니다.

기존 URL은 blog 하위 도메인으로 리다이렉션되도록 설정해 구조적 혼란을 줄였습니다.


구조 개편과 템플릿 도입#

기존 learning-log는 Node.js로 작성된 간단한 빌드 스크립트를 사용했습니다.

템플릿 엔진 없이 JavaScript 조합으로 HTML을 생성하는 방식이었는데, 유지보수가 점점 어려워졌습니다.

이번 전환에서는 mustache 템플릿 엔진을 도입해 각 페이지의 공통 구조를 템플릿으로 관리하도록 변경했습니다.

또한 sitemap을 자동으로 생성하도록 추가해, 검색 엔진 인덱싱과 페이지 탐색성을 함께 개선했습니다.

이 과정에서 빌드 스크립트는 기존보다 명확한 단계로 구분되었습니다.

[Markdown 파싱 → 템플릿 렌더링 → sitemap 생성 → 배포] 의 단순한 흐름이 이제는 안정적인 구조로 자리 잡았습니다.


콘텐츠 관리 방향#

앞으로는 GPTs가 아닌 GPT API를 기반으로 한 리라이팅 툴을 사용할 계획입니다.

이를 위해 콘텐츠를 사이트 내부에 직접 포함하는 구조로 바꾸었습니다.

GPT는 요청 형태와 관계없이 응답을 Markdown 대신 리스트나 표 등으로 임의로 스타일링하는 경우가 많았습니다.

복사 가능한 형태로 요청해도 일관된 포맷으로 받기 어려웠기 때문에, 결과물을 직접 다운로드 가능한 Markdown 파일로 정리해 두는 방식을 사용하고 있습니다.

하지만 API를 사용하면 출력 포맷을 직접 제어할 수 있어, 콘텐츠를 빌드 과정에서 필요한 형태로 가공하거나 파일 단위로 저장하는 처리가 한층 수월해질 것입니다.

빌드 과정에서는 cmspull blog 같은 명령을 실행해 리라이팅 툴에서 최신 콘텐츠를 자동으로 패칭하도록 설정할 예정입니다.

이렇게 하면 빌드 시점에 필요한 콘텐츠가 자동으로 갱신되고, 관리 포인트를 한곳으로 모을 수 있습니다.

또한 나중에 Docker 기반 빌드 환경으로 전환하더라도, 컨테이너는 그대로 두고 실행 스크립트에서 콘텐츠만 갱신하도록 하면 전체 빌드 과정이 훨씬 빠르고 효율적으로 동작할 것으로 기대하고 있습니다.


전환 이후의 변화#

로컬 빌드 방식으로 바꾼 뒤, 배포 속도가 눈에 띄게 개선되었습니다.

클라우드 빌드 환경을 로드할 필요가 없기 때문에, 로컬에서 바로 결과를 생성하고 Cloudflare로 푸시하면 곧바로 반영되었습니다.

작업 흐름이 가벼워지고, 수정 후 결과를 바로 확인할 수 있게 되었습니다.

Cloudflare Pages의 미세한 차이들이 결국 이 프로젝트의 운영 방식을 바꾸었습니다.

기록은 여전히 단순한 정적 사이트이지만, 그 구조와 빌드 흐름은 이제 훨씬 유연해졌습니다.


마무리하며#

learning-log는 이제 workbench라는 이름으로,
기록을 남기는 도구에서 기록을 다루는 실험의 공간으로 변화했습니다.

GitHub Pages에서 Cloudflare Pages로의 전환은 단순한 배포 플랫폼 이동이 아니라,
기록을 지속적으로 다듬고 관리하기 위한 구조적 변화의 출발점이 되었습니다.

이 글에 대한 의견이나 개선점은 작성자에게만 전달