Jekyll에서 Astro 기반 블로그로, 그리고 Firefly를 선택한 이유

Jekyll을 떠나게 된 배경#

Jekyll의 가장 큰 장점은 GitHub Pages와 자연스럽게 연결된다는 점이다. Markdown 파일을 저장소에 올리면 정적 페이지로 배포되는 구조는 개인 블로그에 충분했다. 하지만 오래 운영할수록 글을 쓰는 일보다 테마를 원하는 모습으로 바꾸는 일이 더 부담스러워졌다.

레이아웃을 수정하려면 Liquid 템플릿과 테마의 규칙부터 이해해야 했고, 로컬에서는 Ruby와 gem 버전도 맞춰야 했다. 작은 화면 구성을 바꾸거나 새 기능을 추가할 때조차 평소 사용하는 TypeScript 중심의 개발 환경과 다른 문맥을 오갔다. 글만 발행한다면 감수할 수 있지만, 블로그 자체를 계속 손보려면 익숙한 도구를 쓰는 편이 낫다고 판단했다.

블로그의 역할도 달라졌다. 단순한 글 목록을 넘어 프로젝트 경험, 기술적 판단, 회고와 짧은 기록을 서로 연결하고 싶었다. 카테고리와 태그, 검색, RSS, SEO 메타데이터와 반응형 화면을 기본으로 유지하면서도 필요한 기능을 컴포넌트 단위로 확장할 수 있는 구조가 필요했다.

Astro를 기반으로 선택한 이유#

Astro를 쓰면 기존의 정적 사이트 운영 방식은 유지하면서 개발 환경을 TypeScript와 컴포넌트 중심으로 옮길 수 있다. 글은 계속 Markdown과 MDX 파일로 관리하고 빌드 결과도 정적 파일로 만든다. GitHub Pages에 배포하는 단순한 흐름을 포기할 필요가 없었다.

콘텐츠 중심 페이지에 필요한 JavaScript만 전달하는 구조도 블로그와 잘 맞았다. 대부분의 페이지는 글을 읽는 데 집중하고, 검색이나 설정처럼 상호작용이 필요한 부분만 클라이언트에서 실행한다. 기능을 하나 추가했다고 모든 페이지의 실행 비용까지 커지지는 않는다는 점이 마음에 들었다.

Astro의 콘텐츠 컬렉션에서는 글의 메타데이터를 스키마로 관리한다. 제목, 발행일, 설명, 이미지, 태그, 카테고리 같은 필드를 빌드할 때 검증하므로 오래된 글과 새 글이 같은 규칙을 따르는지 확인하기 쉽다. Markdown 파일은 직접 소유하되 데이터 구조를 느슨하게 방치하지 않는 절충안이었다.

Firefly를 선택한 기준#

Astro는 좋은 기반이지만 블로그에 필요한 기능을 모두 직접 조립하려면 적지 않은 시간이 든다. Firefly에는 콘텐츠 중심 블로그를 운영하는 데 필요한 구조가 이미 갖춰져 있었고, 내가 원하는 확장 방향과도 잘 맞았다.

처음 눈에 들어온 건 이전에 사용하던 Jekyll 테마 Chirpy와 닮은 점이 많아서였다. 글을 중심에 두고 사이드바와 카테고리, 태그, 검색으로 콘텐츠를 탐색하는 방식이 익숙했다. 기반 기술을 바꾸더라도 독자가 글을 찾고 읽는 경험까지 완전히 낯설게 만들 필요는 없었다.

Firefly라는 이름에 맞춘 애니메이션 콘셉트도 마음에 들었다. 페이지 전환과 카드, 배경과 여러 인터랙션이 움직이지만 글 읽기를 방해하는 장식처럼 느껴지지는 않았다. 정적인 기술 블로그에 약간의 생동감과 개성을 더하는 분위기가 내가 만들고 싶은 블로그와 맞았다.

저장소 오너가 꾸준히 개발을 이어 간다는 점도 중요했다. 테마는 처음 설치할 때의 완성도 못지않게 Astro와 의존성 변화에 대응하고 문제를 계속 고쳐 나가는 유지보수 가능성이 중요하다. 커밋과 릴리스가 이어지고 이슈 대응도 활발해서 장기적으로 함께 발전시킬 기반으로 삼기 좋다고 판단했다.

정적인 문서와 레이아웃은 Astro 컴포넌트로 구성하고, 검색·설정·페이지네이션처럼 상호작용이 필요한 UI는 Svelte island로 분리한다. 페이지 전체를 무거운 클라이언트 애플리케이션으로 만들지 않고도 필요한 곳에는 충분한 인터랙션을 넣을 수 있다.

글 목록과 상세 페이지, 카테고리와 태그, RSS, 검색, 다국어 콘텐츠, 다크 모드와 개인화 설정도 한 구조 안에 정리되어 있다. 레이아웃과 사이드바, 댓글, 분석, 글꼴 같은 기능은 TypeScript 설정 모듈로 조정할 수 있어 테마 코드를 매번 뒤지는 수고가 줄었다. Markdown 확장 문법과 Mermaid, 미디어 콘텐츠를 함께 다룬다는 점도 기존 기술 글을 옮길 때 중요했다.

Firefly를 고른 결정적인 이유는 Chirpy에서 이어지는 익숙한 독서 경험, 마음에 든 애니메이션 콘셉트, 활발한 저장소 운영이었다. 글은 콘텐츠 컬렉션에, 정적 화면은 Astro에, 상호작용은 Svelte에, 사이트별 선택은 설정 모듈에 두는 분명한 기술적 경계도 장기 운영에 대한 확신을 더했다.

전환하면서 유지한 것과 바꾼 것#

플랫폼은 바뀌었지만 콘텐츠를 Markdown 파일로 저장하고 Git으로 이력을 관리하는 원칙은 유지했다. 별도의 CMS를 두지 않고 main 브랜치의 변경을 자동화된 빌드와 배포로 연결한다. 도구가 바뀌어도 글이 특정 서비스에 묶이지 않게 하려는 선택이다.

기존 글의 발행일과 저자, 카테고리와 태그도 가능한 한 보존한다. 테마마다 이름이 다른 frontmatter 필드는 Firefly의 콘텐츠 스키마에 맞춰 통일하고, 이미지와 내부 링크는 새 디렉터리 구조에 맞게 정리한다. 예제나 이전 테마의 운영 기록처럼 지금 블로그의 맥락과 맞지 않는 콘텐츠는 그대로 옮기지 않는다.

전환에도 비용은 든다. Node.js 의존성과 빌드 파이프라인을 관리해야 하고, Astro와 Svelte 업데이트도 따라가야 한다. Firefly를 많이 수정할수록 업스트림 변경을 받아들이는 일도 어려워질 수 있다. 설정으로 해결할 항목과 로컬 코드를 바꿀 항목을 구분하고, 변경 후에는 타입 검사와 정적 빌드를 함께 확인하며 운영할 생각이다.

지금의 결론#

Jekyll은 글을 빠르게 공개하는 단순한 GitHub Pages 블로그에 여전히 좋은 선택이다. 하지만 지금 내 블로그에는 익숙한 프런트엔드 생태계, 컴포넌트 단위의 수정, 필요한 기능만 실행하는 정적 사이트 구조와 콘텐츠 확장성이 더 중요하다.

Astro는 그 기반을 제공하고 Firefly는 블로그로서 필요한 기능과 구조를 채워 준다. 이번 전환의 목표는 새 기술을 사용하는 것 자체가 아니다. 글을 쓰는 흐름은 단순하게 유지하면서 사이트를 고치고 확장하는 일을 더 예측 가능하게 만드는 것, 그리고 앞으로 쌓일 기록을 오래 관리할 수 있는 형태로 두는 것이다.