새 프로젝트를 시작할 때 Next.js를 기본값으로 선택하던 시절이 있었다. 그런데 Astro가 v4, v5를 거치며 빠르게 성장하면서 "이 프로젝트에 Next.js가 정말 필요한가?"라는 질문을 던지게 됐다. 2026년 현재 두 프레임워크는 분명히 다른 문제를 풀고 있다. 포트폴리오 사이트를 만드는 것과 대규모 SaaS를 만드는 것은 다른 도구가 필요하다. 실무에서 두 프레임워크를 모두 써본 경험을 바탕으로 비교한다.
📋 목차
⚡ Astro vs Next.js 한눈에 비교
| 항목 | Astro 5 | Next.js 15 |
|---|---|---|
| 기본 렌더링 | SSG (기본) + SSR 선택 | SSR + SSG + RSC |
| JavaScript 번들 | 🏆 Zero JS (기본값) | React 런타임 필요 |
| Core Web Vitals | 🏆 매우 우수 | 최적화 필요 |
| 라우팅 | 파일 기반 | 파일 기반 (App Router) |
| UI 프레임워크 | React, Vue, Svelte 등 혼용 가능 | React 전용 |
| API Routes | 지원 (Endpoints) | 🏆 강력한 Route Handlers |
| 데이터베이스 연동 | 가능하지만 제한적 | 🏆 풀스택 지원 |
| 학습 곡선 | 🏆 낮음 | 중간~높음 (App Router) |
| 배포 | 어디서든 가능 (정적) | Vercel 최적화 |
| 적합한 프로젝트 | 콘텐츠 중심 사이트 | 앱 + 대시보드 + SaaS |
🚀 Astro 5 — Island Architecture의 강점
Astro의 핵심 철학은 "Zero JS에서 콘텐츠 HTML, JavaScript가 필요할 때秌".이다. Island Architecture라는 개념을 통해 페이지의 대부분은 정적 HTML로 렌더링하고, 인터랙션이 필요한 컴포넌트만 선택적으로 hydrate한다.
Astro가 빛나는 순간
- 블로그, 문서 사이트, 포트폴리오: 콘텐츠 중심 사이트에서 Core Web Vitals가 압도적으로 좋다.
- 마케팅 랜딩 페이지: Zero JS 기본값 덕분에 Lighthouse 100점이 기본에 가깝다.
- 다중 UI 프레임워크: React, Vue, Svelte, Solid를 하나의 프로젝트에서 혼용할 수 있다. 마이그레이션 중인 프로젝트에 유리하다.
- 콘텐츠 컬렉션: Markdown/MDX 콘텐츠를 타입 안전하게 관리하는 기능이 내장되어 있어 CMS 없이도 구조적인 콘텐츠 관리가 가능하다.
Astro 5의 주요 변화
Astro 5에서는 Server Islands와 Content Layer API가 안정화됐다. Server Islands는 정적 페이지 안에서 서버 사이드 렌더링이 필요한 부분만 선택적으로 처리할 수 있게 해준다. 예를 들어 사용자 로그인 상태를 보여주는 헤더 부분만 서버에서 렌더링하고, 나머지 콘텐츠는 정적으로 유지할 수 있다.
💡 실무 팁: Astro는 콘텐츠 중심 사이트에서 Next.js 대비 LCP(Largest Contentful Paint) 점수가 평균 20~40% 높게 나온다. SEO가 중요한 마케팅 사이트라면 Astro를 먼저 고려하자.
⚙️ Next.js 15 — 풀스택의 표준
Next.js는 2026년에도 React 생태계의 사실상 표준 프레임워크 위치를 유지하고 있다. App Router가 안정화됐고, React Server Components(RSC), Server Actions, Partial Prerendering(PPR)이 모두 프로덕션 수준으로 성숙했다.
Next.js가 빛나는 순간
- SaaS 애플리케이션: 인증, 결제, 대시보드, 실시간 데이터 등 복잡한 앱 로직이 필요할 때 Next.js가 압도적으로 유리하다.
- 풀스택 단일 코드베이스: Route Handlers + Server Actions로 백엔드 API 없이 풀스택 구현이 가능하다.
- React 생태계 최대 활용: React의 모든 기능과 서드파티 라이브러리를 그대로 쓸 수 있다.
- 팀 협업: React 개발자라면 추가 학습 없이 바로 합류할 수 있다.
Next.js 15의 주요 변화
Next.js 15에서는 Partial Prerendering(PPR)이 실험적 단계에서 안정화 단계로 진입했다. PPR은 한 페이지 안에서 정적 부분과 동적 부분을 자동으로 구분해 최적의 렌더링 전략을 적용한다. 또한 React 19와의 완전한 통합으로 서버 컴포넌트와 클라이언트 컴포넌트의 경계가 더욱 명확해졌다.
💡 실무 팁: App Router의 학습 곡선이 여전히 높다. `"use client"` vs `"use server"` 경계를 잘못 설정하면 번들 크기가 예상보다 커진다. 새 프로젝트에서는 기본적으로 Server Component로 시작하고, 인터랙션이 필요할 때만 클라이언트로 내려보내는 습관을 들이자.
📊 성능 비교: Core Web Vitals 실측
동일한 블로그 사이트(포스트 50개, 이미지 포함)를 Astro와 Next.js로 각각 구현하고 Lighthouse를 측정했다.
| 측정 항목 | Astro 5 | Next.js 15 |
|---|---|---|
| Lighthouse 성능 점수 | 97~100 | 85~95 |
| LCP (Largest Contentful Paint) | 0.8s | 1.4s |
| TBT (Total Blocking Time) | 0ms | 120ms |
| 초기 JS 번들 | ~0KB | ~80KB |
| 빌드 시간 (50개 페이지) | ~4s | ~6s |
콘텐츠 중심 사이트에서 Astro가 성능 수치에서 우위를 보이는 건 명확하다. 하지만 인증, 실시간 데이터, 복잡한 상태 관리가 들어가는 순간 Next.js의 유연성이 Astro의 성능 이점을 상쇄한다.
🛠️ 개발 경험(DX) 비교
| 항목 | Astro | Next.js |
|---|---|---|
| 초기 설정 | 🏆 매우 쉬움 | 중간 |
| TypeScript 지원 | 기본 내장 | 기본 내장 |
| Hot Reload | 🏆 빠름 | 빠름 (Turbopack) |
| 에러 메시지 품질 | 좋음 | 🏆 매우 좋음 |
| 문서 품질 | 🏆 매우 좋음 | 좋음 (방대함) |
| 커뮤니티 규모 | 중간 (빠르게 성장) | 🏆 매우 큼 |
| 플러그인 생태계 | 중간 | 🏆 매우 풍부 |
🗂️ 사용 사례별 선택 가이드
🚀 Astro를 선택하세요
- 블로그, 포트폴리오, 문서 사이트
- 마케팅 랜딩 페이지
- SEO가 최우선인 콘텐츠 사이트
- 다중 UI 프레임워크를 혼용해야 할 때
- 최소한의 JavaScript가 목표일 때
- Headless CMS (Contentful, Sanity 등)와 연동
⚙️ Next.js를 선택하세요
- SaaS 애플리케이션, 대시보드
- 인증/결제 로직이 복잡한 앱
- 실시간 데이터 업데이트가 필요한 경우
- 대규모 팀, React 개발자들과 협업
- Vercel에 배포할 때
- 기존 React 코드베이스를 활용할 때
🔄 Astro ↔ Next.js 전환할 때
Next.js → Astro 전환이 적합한 경우: 현재 Next.js로 블로그나 마케팅 사이트를 운영 중인데 성능 문제가 있고, 앱 수준의 기능(인증, DB)이 거의 없다면 Astro 전환이 Lighthouse 점수를 크게 개선할 수 있다. Astro는 React 컴포넌트를 그대로 사용할 수 있어 마이그레이션 비용이 낮은 편이다.
Astro → Next.js 전환이 적합한 경우: 콘텐츠 사이트로 시작했다가 사용자 계정, 결제, 대시보드 등 앱 기능이 추가되기 시작할 때다. Astro의 API endpoint<뇌으로 비잡한 로직을 감당하기 어려워지는 시점이 분기점이다.
🏆 최종 결론
콘텐츠 중심 사이트 = Astro. 성능과 SEO가 최우선이라면 2026년 현재 Astro가 가장 합리적인 선택이다. Zero JS 기본값과 Island Architecture는 마케팅 사이트에서 경쟁 불가한 성능을 제공한다.
앱 수준의 복잡성 = Next.js. 인증, 결제, 실시간 데이터, 복잡한 상태 관리가 필요한 프로젝트에서는 Next.js의 풀스택 생태계가 여전히 독보적이다. "지금 당장 Astro가 빠르다"는 이유 하나로 SaaS를 Astro로 만드는 건 비효율적이다.
두 프레임워크는 경쟁 관계가 아니라 각자 다른 문제를 해결하는 도구다. 프로젝트의 성격을 먼저 정의하고, 그에 맞는 도구를 선택하면 된다.
댓글
댓글 쓰기