Gatsby에서 Astro로 마이그레이션한 이유

Gatsby Cloud 종료와 함께 찾은 새로운 정적 사이트 생성 프레임워크, Astro로의 전환 경험을 공유합니다

#astro #gatsby #migration #static-site-generator #web-development

Jekyll로 시작한 블로그 여정

개발을 처음 배우며 선택한 블로그 플랫폼은 Jekyll이었습니다. 마크다운으로 글을 작성하고, Git을 통해 버전 관리까지 연습할 수 있었죠. 특히 commit 후 push만 하면 바로 배포되는 워크플로우가 매우 인상적이었습니다.

username.github.io 도메인을 무료로 사용할 수 있다는 것도 매력적이었습니다. 하지만 사용하다 보니 한계가 보이기 시작했습니다. Liquid 문법이 익숙하지 않았고, Ruby 기반이라 원하는 기능을 직접 구현하기 어려웠습니다.

Gatsby로의 전환

이런 아쉬움을 느끼던 차에 Gatsby를 알게 되었습니다. Jekyll의 마크다운 기반 글쓰기는 그대로 유지하면서 React의 강력함까지 활용할 수 있다는 점이 매우 매력적이었습니다.

실제로 사용해보니 Gatsby는 기대 이상이었습니다:

  • 빠른 로딩 속도: 프리페칭과 코드 스플리팅 덕분에 페이지 이동이 매끄러웠습니다
  • 강력한 이미지 최적화: gatsby-image의 자동 최적화와 지연 로딩이 훌륭했습니다. SVG placeholder까지 자동 생성해주어 사용자 경험이 한층 향상되었습니다
  • 풍부한 생태계: 웬만한 기능은 모두 플러그인으로 해결할 수 있었습니다

이렇게 Gatsby에 푹 빠져 살았습니다. 문서 오탈자 수정 같은 작은 기여도 하며 애정을 가지고 사용했습니다.

Gatsby와 이별하기

그런데 2024년 들어 분위기가 달라지기 시작했습니다. 업데이트가 뜸해지고, 커뮤니티 활동도 예전 같지 않았습니다. 결정적인 순간은 Gatsby Cloud 서비스 종료 발표를 본 것이었습니다. Reddit의 관련 토론에서도 많은 개발자들이 걱정스러워하고 있었죠. Netlify가 Gatsby를 인수한 후 Gatsby Cloud가 문을 닫으면서 앞으로의 방향성이 불분명해 보였습니다. 실제로 GitHub 스타 수와 npm 다운로드 수치를 보면 사용자가 줄어드는 추세가 명확했습니다.

Astro.js

그러던 중 The Rise of Astro.js in 2025 글을 읽게 되었습니다.

Astro의 철학을 보는 순간 ‘이거다!’ 싶었습니다. 콘텐츠 중심, 서버 우선, 기본적으로 빠른 성능, 불필요한 복잡성 제거, 개발자 경험 우선. 이 모든 것이 제가 블로그에서 추구하는 가치와 정확히 맞아떨어졌습니다.

블로그는 무엇보다 콘텐츠를 빠르게 전달하는 것이 중요합니다. Google의 Core Web Vitals가 2021년부터 검색 순위에 영향을 미치고 있고, LCP가 1초 개선될 때마다 전환율이 최대 13% 증가한다는 연구도 있습니다. 2024년부터는 INP가 FID를 대체하며 사용자 경험이 SEO의 핵심이 되었죠. 이런 트렌드에서 Astro의 성능 중심 접근법은 매우 매력적이었습니다.

아일랜드 아키텍처로 다양한 UI 라이브러리를 혼용할 수 있다는 점도 좋았습니다. 저는 React만 사용할 예정이지만, 선택의 폭이 넓다는 건 언제나 환영이죠. 물론 SPA나 대규모 상태 관리, 실시간 기능에는 한계가 있지만, 콘텐츠 위주 블로그에서는 전혀 문제가 되지 않습니다.

Astro의 “Islands Architecture”는 정말 혁신적이었습니다. 필요한 부분만 JavaScript를 로드하는 방식이죠:

<!-- 정적 HTML -->
<header>Static Header</header>

<!-- 인터랙티브한 부분만 JavaScript 로드 -->
<ThemeToggle client:load />

<!-- 나머지는 정적 HTML -->
<article>Blog Content...</article>

이런 방식으로 JavaScript 번들 크기를 대폭 줄일 수 있습니다.

“Zero JavaScript by Default” 철학도 인상적이었습니다. Gatsby가 모든 페이지를 React 앱으로 만드는 반면, Astro는 기본적으로 JavaScript를 아예 보내지 않습니다. 필요할 때만 client:* 지시어로 추가하죠:

  • client:load - 페이지 로드 시 즉시 hydrate
  • client:idle - 브라우저가 idle 상태일 때 hydrate
  • client:visible - viewport에 보일 때 hydrate
  • client:media - 특정 미디어 쿼리 조건에서만 hydrate

프레임워크에 구애받지 않는다는 점도 훌륭합니다. React, Vue, Svelte, SolidJS를 마음대로 조합할 수 있어요. 저는 기존에 사용하던 React와 shadcn/ui를 그대로 활용할 수 있어서 마이그레이션이 한결 수월했습니다.

---
// Astro Component
import ReactComponent from './ReactComponent.jsx';
import VueComponent from './VueComponent.vue';
---

<ReactComponent client:load />
<VueComponent client:idle />

무엇보다 성능 개선이 눈에 띄었습니다. First Contentful Paint가 1.2초에서 0.6초로 절반 수준으로 빨라졌고, JavaScript 번들 크기는 245KB에서 45KB로 5분의 1 수준까지 줄어들었습니다.

마이그레이션 과정

마이그레이션 과정은 예상보다 훨씬 간단했습니다. MDX 파일들을 Astro 라우팅 구조에 맞게 정리하고, URL이 바뀌는 경우 301 리다이렉트만 설정하면 끝입니다. astro.config.mjs에서 리다이렉트를 쉽게 설정할 수 있어 SEO에 영향 없이 URL 구조를 바꿀 수 있었습니다.

게다가 Astro는 MCP를 지원하고, shadcn/ui도 MCP를 지원해서 AI의 도움을 받아 원하는 구조와 UI를 빠르게 구성할 수 있었습니다.

물론 아쉬운 점도 있습니다. 플러그인 생태계가 Gatsby만큼 풍성하지는 않아요. 그래도 필요한 기능들은 웬만큼 갖춰져 있고, 새로운 플러그인들도 꾸준히 나오고 있어서 큰 걱정은 없습니다.

가장 아쉬운 건 이미지 처리 부분이었습니다. Gatsby의 gatsby-image는 여러 사이즈 자동 생성, WebP 변환, 블러 플레이스홀더, 지연 로딩까지 모든 게 자동이었거든요. Astro Image 컴포넌트도 기본 최적화는 해주지만, Gatsby만큼 완벽하게 자동화되지는 않습니다. 하지만 개인 블로그 수준에서는 충분했습니다.

결론

Gatsby는 여전히 훌륭한 도구입니다. 하지만 Astro의 단순함과 뛰어난 성능, 그리고 활발하게 성장하는 커뮤니티를 보면 앞으로가 더 기대됩니다. 정적 사이트를 만드신다면 Astro를 적극 추천합니다.

Astro로 개발 블로그를 시작하려는 분들을 위해 간단한 스타터를 만들어두었습니다. https://github.com/gnujoow/glob-astro-blog-starter 도움이 되었으면 좋겠습니다.

참고 자료

Back to List