1685 단어
8 분

Netlify 한도를 넘어서 Cloudflare Pages로 이전하기

/posts/netlify-to-cloudflare-pages/
작성 안내

이 글은 GPTs를 활용해 블로그 원고 작성 과정의 일부를 보조받았습니다.

요약#

이 글은 티스토리에서 시작해 Netlify를 거쳐 Cloudflare Pages로 옮긴 과정을 정리한 기록입니다.

Netlify의 무료 빌드 한도 변경이 계기가 되었고, 실제 이전 과정과 그때의 경험을 함께 담았습니다.

결과적으로 제 환경에서는 비용 부담 없이 블로그를 운영할 수 있었고, Cloudflare Pages는 무제한 대역폭을 제공하면서도 안정적으로 운영된다는 인상을 개인적으로 받았습니다.


티스토리에서의 첫 시작#

개발 중 발생한 이슈를 해결하기 위해 구글링을 하면 티스토리 블로그 글이 자주 보이곤 했습니다.

그만큼 당시 티스토리는 국내에서 대표적인 개발 블로그 플랫폼으로 자리 잡고 있었습니다.

개발자들 사이에서는 자기 개발이나 기록을 목적으로 블로그를 운영하는 경우가 많았고 저 역시 자신의 기술적 활동을 정리하고 공유할 수 있는 공간이 필요했습니다.

그렇게 글을 쓰며 점점 기술 중심의 글쓰기에 익숙해졌고, 자연스럽게 글쓰기 도구에도 변화를 고민하게 되었습니다.

넷리파이(Netlify)로의 전환과 한계#

시간이 지나면서 마크다운(Markdown) 문법이 익숙해졌고 README.md를 작성하거나 코드 스니펫(snippet)을 정리하는 일이 많아지면서 글도 마크다운으로 쓰는 게 더 편해졌습니다.

또한 플랫폼에 종속된 채 글을 작성하면 서비스 종료나 정책 변경의 영향을 받을 수 있다는 한계가 있었습니다.

한 번 작성한 글을 다른 플랫폼으로 옮기려면 API / 서드파티 도구를 이용하거나 수작업으로 옮겨야 했고 이 과정은 번거롭고 시간이 많이 들었습니다.

서비스형 블로그는 쓰기 쉽지만 근본적으로 사용자가 콘텐츠를 완전히 소유하지 못하며 반대로 자체 CMS는 관리 부담이 따릅니다. 그래서 완전한 자율성과 유지 편의성 사이의 균형을 찾는 일이 늘 과제였습니다.

이런 맥락에서 정적 사이트 생성기(SSG)는 당시 제게는 꽤 현실적인 대안처럼 느껴졌습니다.

콘텐츠를 파일 단위로 직접 관리할 수 있고, 테마나 구조를 자유롭게 바꿀 수 있다는 점이 매력적이었습니다.

Jekyll이나 Astro 같은 빌더를 이용하면 테마와 구조를 자유롭게 바꿀 수 있고 콘텐츠를 마크다운 파일 형태로 직접 소유할 수 있습니다.

깃 저장소가 곧 백업이 되기 때문에 다양한 환경에서 제약 없이 운영할 수 있습니다.

이후 정적 사이트를 보다 간편하게 배포하기 위해 Netlify를 사용하기 시작했습니다.

Netlify는 Git과 연동되어 푸시만으로 자동 빌드와 배포가 가능했고 별도의 서버 관리 없이도 정적 블로그를 운영할 수 있었습니다.

초기에는 무료 플랜으로도 충분했지만 점차 배포 빈도가 늘면서 제한이 부담으로 다가오기 시작했습니다.

2025년 Netlify의 요금 정책이 변경되면서 무료 플랜 기준 배포 횟수에 제한이 생겼고 배포가 발생할 때마다 한도가 차감되는 구조에서 이 제한은 생각보다 빨리 소진되었습니다.

한 달에 20회 정도만 배포해도 무료 한도를 모두 사용하게 되었고 작은 수정조차 배포를 망설이게 되는 상황이 되었습니다.

이런 구조는 글을 자주 수정하고 보완하는 제 작업 방식과 잘 맞지 않다고 느껴졌습니다.

Cloudflare Pages로 눈을 돌리다#

Netlify의 배포 한도가 반복적으로 걸림돌이 되던 시점에, 대안으로 떠오른 서비스가 Cloudflare Pages였습니다.

기존 운영 환경과 잘 맞는 선택지였고 무료 플랜에서도 배포 횟수에 제한이 없으면서 Netlify보다 더 넉넉한 대역폭을 제공한다는 점이 눈에 띄었습니다.

정적 파일 위주의 블로그를 운영하는 데에는 비용이나 사용량을 크게 신경 쓰지 않아도 되는 구조라는 점도 선택에 영향을 주었습니다.

전환 과정은 생각보다 단순했습니다. Cloudflare Pages에서 애플리케이션을 생성하고 정적 파일을 업로드하는 방식으로 배포를 진행했으며 이후 도메인 등록기관에서 네임서버를 Cloudflare 쪽으로 변경한 뒤 해당 애플리케이션에 연결했습니다.

몇 시간의 전파 시간이 지난 뒤에는 기존에 사용하던 도메인을 그대로 유지한 채 블로그를 운영할 수 있었습니다.

초기 설정은 몇 분 만에 완료되었고 현재는 로컬에서 빌드한 결과물을 직접 업로드하는 방식으로 배포하고 있으며 이후에는 CLI를 통해 배포 과정을 자동화할 계획입니다.

이전 이후의 변화와 정리#

가장 크게 체감된 변화는 배포에 대한 부담이 줄었다는 점이었습니다.

Netlify를 사용할 때는 배포 한도를 항상 염두에 두어야 했지만 Cloudflare Pages로 옮긴 뒤에는 적어도 제 사용 방식에서는 그런 계산을 따로 할 필요가 없었습니다.

정적 사이트 구조 덕분에 속도 저하나 캐싱 문제를 따로 신경 쓸 필요도 없었고 기존에 사용하던 SEO 설정이나 Analytics 코드 역시 그대로 유지할 수 있었습니다.

Cloudflare의 전역 CDN과 연동되면서 접근 속도도 이전보다 안정적으로 느껴졌습니다.

결국 이번 이전은 블로그 운영을 조금 더 편안하게 만들기 위한 선택이었고, 저에게 맞는 방식으로 기록을 이어가기 위한 작은 조정이었습니다.

참고자료#

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