Astro에서 다시 Jekyll로 — 바퀴를 다시 발명하지 말라

Astro에서 Chirpy 스타일을 직접 만들 수 있을까? 만들 수는 있다. 하지만 만들면 안 된다.

결론부터 말한다. Astro v5에서 Chirpy 테마를 재현하려고 하루를 쏟았다가, 결국 진짜 Chirpy(Jekyll) 테마로 갈아탔다. 마이그레이션 총 소요 시간 2시간, 빌드 시간 0.8초. 직접 만들었으면 며칠이 걸렸을 기능들이 테마 하나로 전부 해결됐다.

이건 Astro가 나쁘다는 이야기가 아니다. 이미 수년간 다듬어진 솔루션이 있는 영역에서 바퀴를 다시 발명하는 것이 왜 나쁜 판단인지에 대한 실전 사례 분석이다.

출발점 — Astro v5로 만든 블로그

이 블로그는 원래 Astro v5로 만들었다. 직접 컴포넌트를 짜고, 레이아웃을 구성하고, 스타일을 입혔다. SEO도 넣고, Giscus 댓글도 붙이고, GoatCounter 페이지뷰도 연동했다. 나름 잘 돌아가고 있었다.

벤치마크 발견 — Chirpy 테마의 완성도

그러다 otzslayer.github.io를 봤다. Chirpy 테마 기반의 Jekyll 블로그였는데, 한눈에 봐도 완성도 차이가 명확했다.

• 좌측 고정 사이드바 (프로필, 네비게이션, 소셜 링크)
• 우측 패널 (최근 업데이트, 트렌딩 태그)
• 페이지뷰 카운터가 각 글마다 자동 표시
• 광고(AdSense)가 자연스럽게 배치
• 다크/라이트 모드 토글
• 검색, TOC, 관련 글 추천까지

내 Astro 블로그에는 이 중 절반도 없었다. 당연히 생각했다. “이거 내 블로그에도 넣고 싶다.”

첫 번째 시도 — Astro에서 Chirpy 스타일 직접 구현

처음에는 Astro 안에서 Chirpy 스타일을 재현하려고 했다. Claude Code에 시켰더니 꽤 그럴듯한 결과물이 나왔다:

• Sidebar.astro – 좌측 사이드바 (프로필, 네비게이션, 소셜 아이콘)
• RightPanel.astro – 우측 패널 (최근 업데이트, 트렌딩 태그, 광고)
• SearchBar.astro – 클라이언트 사이드 검색
• global.css 1,235줄 전면 재작성
• Categories, Tags, Archives 페이지 신규 생성

빌드 성공, 48페이지 생성, 커밋하고 푸시까지 완료. 여기까지는 순조로웠다.

현실 확인 — 레이아웃과 완성도는 다른 문제다

배포하고 실제로 써보니 빠진 게 한두 개가 아니었다:

• 페이지뷰가 각 글에 표시 안 됨
• 우측 사이드바가 포스트 페이지에서 사라짐
• 광고 배치가 제대로 안 됨
• 좋아요/리액션 기능 없음
• 검색이 불안정
• 다크 모드 전환 시 스타일이 깨짐

여기서 깨달은 게 있다. 레이아웃을 비슷하게 만드는 것과 세부 기능까지 완성도 있게 동작하게 만드는 것은 완전히 다른 문제라는 것이다. Chirpy 테마가 수년간 커뮤니티의 피드백을 받으며 다듬어온 것들을 하루 만에 Astro 컴포넌트로 재현하는 건 불가능했다.

결정 — 진짜 Chirpy로 전환

고민 시간은 짧았다.

“계속 Astro에서 하나씩 고칠까, 아니면 그냥 Chirpy 테마를 쓸까?”

답은 명확했다. 이미 잘 만들어진 걸 쓰자. cotes2020/jekyll-theme-chirpy를 포크해서 기존 레포를 통째로 대체했다.

마이그레이션 — 7단계, 총 2시간

1. Chirpy 테마 클론 – 기존 Astro 파일 전부 삭제
2. _config.yml 설정 – 한국어, GA4, GoatCounter, Giscus 댓글, 아바타
3. 블로그 글 10개 마이그레이션 – frontmatter 변환 (pubDate -> date, heroImage -> image, category -> categories)
4. 이미지 경로 변경 – public/images/blog/ -> assets/img/blog/
5. 내부 링크 수정 – /blog/slug -> /posts/slug/
6. AdSense 설정 – 사이드바 + 인아티클 광고
7. GitHub Actions 배포 – Ruby 3.3 + Jekyll 빌드

빌드 시간 0.8초, 배포까지 총 50초. Astro 대비 빌드 속도가 오히려 빨랐다.

Chirpy가 제공하는 것들 — “그냥 됐다”의 목록

테마를 적용하니 이 모든 기능이 설정만으로 동작했다:

• 좌측 사이드바 (프로필, 네비게이션, 다크/라이트 토글)
• 우측 패널 (최근 업데이트, 트렌딩 태그)
• GoatCounter 페이지뷰 (각 글마다 자동 표시)
• Giscus 댓글 + 리액션
• 검색 (Simple-Jekyll-Search)
• TOC (Table of Contents)
• 관련 글 추천
• 이전/다음 글 네비게이션
• AdSense 광고 (사이드바 + 인아티클)
• 한국어 로케일 기본 제공
• PWA 지원
• SEO 최적화 (og:image, twitter:card 등)

직접 구현하면 며칠이 걸릴 기능들이, 테마 하나에 전부 포함되어 있었다. 직접 만들면 며칠, 테마를 쓰면 2시간. 이 차이가 “바퀴를 다시 발명하지 말라”는 격언의 본질이다.

핵심 교훈 — 만들 수 있다 vs 만들어야 한다

개발자들이 자주 빠지는 함정이 있다.

“이 정도는 직접 만들 수 있는데?”

맞다. 만들 수 있다. 근데 만들어야 하는가?

Astro에서 Chirpy 스타일을 재현하면서 확실히 깨달았다. 레이아웃을 비슷하게 만드는 건 쉽다. 하지만 페이지뷰 연동, 다크 모드 전환 애니메이션, 검색 인덱싱, 광고 배치 최적화, 반응형 사이드바 – 이런 세부 기능들을 프로덕션 수준으로 만드는 건 완전히 다른 규모의 작업이다.

비교 항목	Astro 직접 구현	Chirpy 테마 사용
소요 시간	수일 (추정)	2시간
기능 완성도	60~70%	100%
유지보수	전부 직접	커뮤니티 + 업데이트
빌드 시간	~1.5초	0.8초

이 정도 차이면 고민할 여지가 없다.

Don’t reinvent the wheel.

완벽한 커스텀보다 잘 돌아가는 기성품이 낫다. 아끼는 시간에 글을 한 편 더 쓰는 게 블로그에는 훨씬 가치 있다.

---

Astro가 나쁜 프레임워크라는 게 아니다. 좋은 프레임워크다. 다만 블로그처럼 이미 잘 만들어진 솔루션이 있는 영역에서는, 처음부터 만들 이유가 없다는 것이다. 에너지는 차별화할 수 있는 곳에 써야 한다.