GitHub Page -> Netlify, Jekyll 블로그 이전 및 재구축기

들어가며

GitHub Pages에서 호스팅 하던 Jekyll 블로그를 Netlify로 이전하는 작업을 진행했습니다. 단순히 호스팅 플랫폼을 바꾸는 것을 넘어, RSS 피드를 수집하여 자동으로 포스팅하는 시스템까지 함께 이전하면서 겪었던 고민과 기술적인 결정들을 공유하고자 합니다.

GitHub Pages도 훌륭한 무료 호스팅 서비스지만, 더 빠른 배포 속도, 강력한 빌드 제어, 그리고 다양한 부가 기능에 매력을 느껴 Netlify로의 이주를 결심하게 되었습니다.

이 글에서는 다음과 같은 내용을 다룹니다.

• 왜 Netlify를 선택했는가?
• Jekyll 블로그를 Netlify에 배포하는 기본 과정
• RSS 자동 포스팅 시스템을 이전하며 겪었던 아키텍처 고민
• 최종적으로 완성된 “GitHub Actions + Netlify” 하이브리드 아키텍처

왜 Netlify인가?

GitHub Pages와 비교했을 때 Netlify가 가지는 몇 가지 명확한 장점이 있습니다.

• 빠른 빌드 및 배포: Netlify의 분산 빌드 시스템은 일반적으로 GitHub Actions보다 더 빠른 속도를 제공합니다.
• 쉬운 설정: netlify.toml 파일을 통해 모든 빌드 설정을 코드로 관리할 수 있으며, 직관적인 웹 UI도 제공합니다.
• baseurl 문제로부터의 해방: GitHub Pages의 프로젝트 사이트(id.github.io/repo)와 달리, Netlify는 루트 도메인에서 서비스를 제공하므로 baseurl 설정의 번거로움이 없습니다.
• 강력한 부가 기능: 배포 미리보기(Deploy Previews), A/B 테스팅, 서버리스 함수 등 개발자에게 유용한 기능들이 많습니다.

Netlify로 Jekyll 블로그 이전하기

기본적인 이전 과정은 매우 간단합니다.

1단계: netlify.toml 설정 파일 추가

가장 깔끔한 방법은 프로젝트 루트에 netlify.toml 파일을 만들어 모든 빌드 설정을 명시하는 것입니다.

```toml

netlify.toml

기본 빌드 설정을 정의합니다.

[build] # Jekyll 빌드 명령어입니다. GitHub Actions에서 쓰던 복잡한 경로가 필요 없습니다. command = “bundle exec jekyll build”

# 빌드 결과물이 생성되는 폴더입니다. publish = “_site”

빌드 환경에서 사용할 환경 변수입니다. (매우 중요)

[build.environment] # 로컬에서 사용하는 Ruby 버전과 맞춰줍니다. (예: “3.3”) RUBY_VERSION = “3.3”

# 프로덕션 환경으로 빌드하도록 설정합니다. JEKYLL_ENV = “production”```

중요: 이주 전, _config.yml의 baseurl 값이 ""(빈 문자열)로 되어 있는지 꼭 확인해야 합니다.

2단계: Netlify에서 사이트 생성

1. Netlify에 GitHub 계정으로 로그인합니다.
2. Add new site > Import an existing project를 선택하여 블로그의 GitHub 저장소를 연결합니다.
3. Netlify가 netlify.toml 파일을 자동으로 감지하므로, 별다른 설정 없이 Deploy site 버튼만 누르면 배포가 시작됩니다.

이것만으로도 몇 분 안에 Netlify의 임시 도메인으로 블로그가 배포되는 것을 확인할 수 있습니다.

자동 포스팅 시스템, 어떻게 옮길 것인가?

문제는 기존에 GitHub Actions로 운영하던 RSS 자동 포스팅 시스템이었습니다. 이 시스템을 Netlify로 옮기는 과정에서 두 가지 아키텍처를 두고 고민하게 되었습니다.

시나리오 1: 모든 것을 Netlify에서 (Stateless 방식)

첫 번째로 시도한 방법은 GitHub Actions를 완전히 버리고, Netlify의 내장 기능인 Scheduled Functions를 사용하는 것이었습니다.

• 동작 방식:
  1. Netlify의 스케줄러가 매일 정해진 시간에 빌드를 트리거합니다.
  2. 빌드 명령어(command)에 RSS 스크립트 실행을 추가하여(node scripts/fetch-rss.mjs && jekyll build), 빌드 직전에만 임시로 .md 파일을 생성합니다.
  3. 생성된 임시 파일들을 포함하여 사이트를 빌드하고 배포합니다.
• 장점: git commit 로그가 깨끗하게 유지됩니다.
• 치명적인 단점: 이 방식은 “기억”을 하지 못합니다. 빌드 환경은 일회성이므로, 빌드가 끝나면 RSS 스크립트가 만들었던 .md 파일도 함께 사라집니다. 즉, RSS 피드에서 사라진 과거의 기사는 내 블로그에서도 함께 사라지게 됩니다. 콘텐츠가 축적되어야 하는 블로그에는 맞지 않는 방식이었습니다.

시나리오 2: 역할 분담! (하이브리드 방식)

위 시나리오의 단점을 깨닫고, 각 플랫폼이 가장 잘하는 일에 집중하도록 역할을 분담하는 하이브리드 모델을 채택했습니다. 이것이 최종적으로 선택한 아키텍처입니다.

• 콘텐츠 생성 및 저장 (GitHub Actions):
  • 기존의 RSS 수집용 GitHub Actions 워크플로우를 그대로 유지합니다.
  • 이 워크플로우는 RSS 피드를 가져와 .md 파일을 생성하고, Git 저장소에 직접 커밋(commit) & 푸시(push) 합니다.
  • 이제 Git 저장소가 우리 블로그 콘텐츠의 영구적인 “데이터베이스” 역할을 합니다.
• 빌드 및 배포 (Netlify):
  • Netlify는 오직 배포에만 집중합니다.
  • GitHub 저장소의 main 브랜치에 새로운 푸시(내가 쓴 글이든, 봇이 만든 RSS 글이든)가 발생할 때마다, 이를 감지하여 netlify.toml의 간단한 bundle exec jekyll build 명령어로 사이트를 빌드하고 배포합니다.

결론

Netlify로의 이전은 매우 만족스러웠습니다. 초기에는 Netlify의 모든 기능을 활용하려 했지만, 결국 “콘텐츠가 영구적으로 축적되어야 한다”는 블로그의 본질적인 특성을 고려하여 Git을 데이터베이스로 활용하는 하이브리드 모델이 가장 안정적이고 효과적이라는 결론을 내렸습니다.

이 과정은 단순히 플랫폼을 옮기는 것을 넘어, CI/CD 파이프라인과 상태 관리(Stateful vs Stateless)에 대해 더 깊이 고민해볼 수 있었던 좋은 경험이었습니다. 혹시 저와 비슷한 고민을 하고 계신 분들께 이 글이 도움이 되기를 바랍니다.```