Astro vs Next.js, 정적 사이트에는 뭘 쓸까

이 블로그도 Next.js인데

맞다. 이 블로그는 Next.js로 만들었다. 근데 회사에서 기술 문서 사이트를 따로 만들 일이 생겼을 때 Astro를 써봤다. 둘 다 써보니 정적 사이트에 한해서는 차이가 꽤 있었다.

Astro의 첫인상

빌드 결과물을 보고 놀랐다. JavaScript가 0바이트였다. 페이지에 인터랙티브 요소가 없으면 진짜 HTML과 CSS만 나온다. Next.js는 아무것도 없는 페이지도 React 런타임을 포함해서 최소 80KB 정도의 JS가 나가는데.

문서 사이트의 Lighthouse 점수가 성능 100, 접근성 98, SEO 100이 나왔다. Next.js 블로그는 성능 94였다. 6점 차이가 별것 아닌 것 같지만 Core Web Vitals에서 LCP가 확실히 빨라졌다.

(JavaScript 0바이트는 좀 충격적이었다.)

Islands Architecture가 핵심이다

Astro의 핵심 개념이 Islands Architecture다. 페이지 전체를 JavaScript로 관리하는 게 아니라, 인터랙티브가 필요한 컴포넌트만 "섬"처럼 JavaScript를 붙인다.

검색 바 같은 건 client:load로 즉시 로드하고, 댓글 영역은 client:visible로 화면에 보일 때만 로드한다. 이 선택적 하이드레이션이 번들 사이즈를 확 줄여준다.

근데 불편한 점도 있었다

상태 관리가 애매하다. Astro 컴포넌트끼리 상태를 공유하려면 별도 라이브러리가 필요하다. React처럼 부모에서 자식으로 상태를 내려주는 게 자연스럽지 않다. nanostores라는 걸 쓰긴 했는데 React의 useState만큼 직관적이지는 않았다.

그리고 동적 라우팅이나 서버사이드 로직이 필요하면 Astro만으로는 부족하다. 어댑터를 붙여야 하고, 그 시점에서 "그냥 Next.js 쓸 걸" 하는 생각이 든다.

실제로 비교해본 빌드 결과

같은 콘텐츠(문서 43페이지)를 두 프레임워크로 빌드해봤다.

Astro: 빌드 시간 8초, 결과물 크기 2.3MB, 페이지당 JS 평균 0-12KB. Next.js: 빌드 시간 23초, 결과물 크기 14.7MB, 페이지당 JS 평균 87KB.

차이가 확실하다. 정적 콘텐츠 위주라면 Astro가 압도적으로 가볍다.

내 선택 기준

정적 콘텐츠가 90% 이상이면 Astro. 블로그, 문서 사이트, 랜딩 페이지, 포트폴리오. 인터랙티브 요소가 많거나 앱에 가까우면 Next.js. 대시보드, 어드민, SaaS.

이 블로그를 Astro로 다시 만들까 잠깐 고민했는데, 검색 모달이나 테마 토글 같은 인터랙티브 요소가 여기저기 있어서 Next.js가 더 편하다는 결론이 나왔다. 근데 다음에 기술 블로그를 하나 더 만들 일이 있으면 Astro를 쓸 것 같다.