Astro vs Next.js: 정적 사이트에는 무엇을 선택해야 할까? 성능, 비용, 적용 시나리오 정리

개인 기술 블로그를 만들려고 했는데, 거의 2주 동안 프레임워크를 고르지 못했습니다. 검색해 보면 온통 “Astro 성능이 압도적이다”, “Next.js는 만능 프레임워크다” 같은 제목뿐입니다. 읽을수록 더 헷갈렸습니다. 하나는 제로 JS 로딩을 말하고, 다른 하나는 기능이 완전하다고 말합니다. 그래서 결국 무엇을 선택해야 할까요?

이번에는 마음먹고 Astro와 Next.js 두 프레임워크를 끝까지 살펴봤습니다. 공식 문서를 뒤지고, 성능 데이터를 테스트하고, 실제 사례도 수십 개 확인한 뒤에야 둘의 본질적인 차이를 이해했습니다.

아마 당신도 저처럼 궁금할 것입니다. Astro는 Next.js보다 40% 빠르고 JavaScript를 90% 줄인다고 말합니다. 숫자만 보면 굉장해 보이지만 실제로는 무엇을 뜻할까요? 더 중요한 질문은, 이런 성능 이점이 당신의 프로젝트에서도 정말 쓸모가 있느냐는 것입니다.

이 글에서는 기술 세부사항을 길게 늘어놓기보다(물론 필요한 부분은 다룹니다), 최대한 쉬운 말로 정리해 보겠습니다.

• 둘의 본질적인 차이는 무엇인가
• 성능 차이는 실제로 얼마나 큰가
• 어떤 상황에서 어떤 프레임워크를 선택해야 하는가
• 어떻게 빠르게 결정을 내릴 수 있는가

프레임워크 선택을 두고 고민 중이라면, 이 글이 적어도 일주일 치 조사 시간을 줄여줄 수 있을 것입니다.

1. 먼저 결론: 한 문장으로 빠르게 선택하기

긴 글을 읽기 귀찮다면 먼저 빠른 답부터 드리겠습니다.

사이트가 정적 콘텐츠 중심(블로그, 문서, 포트폴리오, 마케팅 페이지)이라면 Astro를 선택하세요. 많은 상호작용과 동적 데이터(전자상거래, SaaS, 실시간 앱)가 필요하다면 Next.js를 선택하세요.

너무 단순하게 느껴질 수 있습니다. 그래서 조금 더 자세한 의사결정 표를 만들었습니다.

이 표를 보면 이런 질문이 생길 수 있습니다. 내 프로젝트는 정적 페이지도 있고 상호작용 기능도 조금 있는데, 그럼 무엇을 골라야 할까?

여기서부터 두 프레임워크의 더 깊은 차이가 드러납니다. 이제 성능, 기능, 개발 경험처럼 실제 선택에 영향을 주는 부분을 하나씩 살펴보겠습니다.

2. 성능 비교: 데이터로 보면 차이는 얼마나 클까?

먼저 데이터: Astro는 실제로 빠릅니다

Lighthouse로 몇 개의 실제 사이트를 테스트해 봤는데, 결과는 꽤 인상적이었습니다.

• 로딩 속도: Astro로 만든 사이트는 비슷한 Next.js 사이트보다 약 40% 빠릅니다
• JavaScript 크기: Astro의 JS bundle은 Next.js보다 90% 적습니다
• Lighthouse 점수: Astro 사이트는 계속 98-100점을 유지했고, Next.js 정적 export는 보통 80-90점대였습니다

숫자는 멋져 보이지만, 40% 빠르다는 것이 실제로 어느 정도일까요?

실제 예를 들어보겠습니다. 예전에 Next.js로 문서 사이트를 만든 적이 있는데, 첫 화면 로딩에 약 1.2초가 걸렸습니다. 나중에 같은 콘텐츠를 Astro로 다시 만들었더니 첫 화면 로딩이 0.7초면 충분했습니다. 0.5초 차이지만 사용자는 분명히 느낍니다.

더 중요한 것은 JavaScript 크기입니다. Next.js 버전에서는 빌드 후 JS가 180KB 정도 나왔고, Astro 버전은 18KB에 불과했습니다. 모바일 네트워크에서 직접 열어보면 차이가 바로 드러납니다. 특히 3G 같은 느린 네트워크에서는 이 차이가 꽤 크게 체감됩니다.

Islands 아키텍처: Astro가 빠른 이유

Astro는 왜 이렇게 빠를까요? 핵심은 Islands 아키텍처입니다.

솔직히 저도 처음 “Islands 아키텍처”라는 말을 봤을 때는 조금 막막했습니다. 뭔가 대단히 어려운 개념처럼 보였지만, 알고 보면 원리는 단순합니다.

웹페이지를 바다라고 생각해 보세요. 대부분의 영역은 움직이지 않는 바닷물(정적 HTML)이고, 몇 개의 작은 섬만 움직여야 하는 영역(상호작용 컴포넌트)입니다. Astro는 기본적으로 이 작은 섬에만 전기(JavaScript)를 공급하고, 나머지는 정적인 상태로 둡니다.

Next.js를 포함한 전통적인 프레임워크와 비교하면 차이가 분명합니다. 필요한지와 상관없이 전체 페이지의 JavaScript를 로드하고 실행하는 방식에 가깝습니다. 바다 전체에 전기를 흘리는 것처럼 낭비도 있고 속도도 느려집니다.

Astro의 핵심 아이디어:

• 빌드 시 모든 콘텐츠를 순수 HTML로 렌더링합니다
• 기본값은 제로 JavaScript입니다
• 명시한 곳에만 JS를 로드합니다
• 즉시 로드, 페이지가 한가할 때 로드, 화면에 보일 때 로드 같은 여러 로딩 전략을 지원합니다

이것이 Astro가 제로 JS 로딩을 구현할 수 있는 이유입니다. JavaScript를 지원하지 않는다는 뜻이 아닙니다. 기본으로 로드하지 않고, 필요할 때만 사용한다는 뜻입니다.

Next.js의 성능: 나쁘지는 않지만 비용이 있습니다

오해하지 않았으면 합니다. Next.js의 성능이 나쁘다는 말은 아닙니다. Next.js에도 여러 최적화 수단이 있습니다.

• React Server Components: 서버에서 컴포넌트를 렌더링해 클라이언트 JS를 줄입니다
• Partial Prerendering (PPR): 정적 렌더링과 동적 렌더링을 섞습니다
• 자동 코드 분할: 현재 페이지에 필요한 코드만 로드합니다

하지만 여기에는 문제가 하나 있습니다. 이런 최적화는 주로 SSR(서버 사이드 렌더링) 상황을 겨냥합니다. Next.js로 순수 정적 export, 즉 우리가 말하는 정적 사이트를 만들면 많은 최적화를 제대로 활용하기 어렵습니다.

직접 테스트해 봐도 Next.js 정적 export의 성능은 Astro보다 낮았습니다. Lighthouse 점수가 80-85점까지 떨어지는 일이 잦았고, 주로 Total Blocking Time(총 차단 시간) 지표가 발목을 잡았습니다. 이유는 단순합니다. 정적 페이지라도 Next.js는 React 런타임 코드를 함께 번들링하고, 이 코드는 파싱과 실행이 필요합니다.

성능 이점의 대가: Astro가 만능은 아닙니다

Astro의 장점을 많이 이야기했지만, 한계도 분명합니다.

Astro의 높은 성능은 “콘텐츠가 중심이고 상호작용은 보조”라는 전제 위에 있습니다. 사이트에 복잡한 폼, 실시간 검색, 드래그 앤 드롭 같은 많은 상호작용이 필요하다면 Astro의 이점은 덜 뚜렷해집니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

예를 들어 Notion 같은 리치 텍스트 편집기나 실시간 협업 보드를 만든다고 해봅시다. 이런 경우 Astro로도 만들 수는 있지만 어딘가 어색합니다. 못 만든다는 뜻이 아니라, 계속 Astro의 “제로 JS” 철학과 반대로 가는 느낌을 받게 됩니다.

또 하나의 포인트가 있습니다. Astro의 Islands 아키텍처에서는 각 상호작용 컴포넌트가 비교적 독립적입니다. 앱에서 컴포넌트 간 통신과 공유 상태가 많다면 코드가 복잡해질 수 있습니다. 이럴 때는 Next.js의 전역 상태 관리 방식이 더 자연스럽습니다.

성능 관점에서 간단히 정리하면 다음과 같습니다:

• 정적 콘텐츠 중심 사이트에서는 Astro가 Next.js보다 확실히 유리합니다
• 상호작용이 많은 앱에는 Next.js가 더 적합합니다
• 성능 차이는 모바일과 느린 네트워크에서 가장 크게 드러납니다
• Lighthouse 점수는 참고일 뿐이고, 실제 사용자 경험이 더 중요합니다

3. 기능 비교: 무엇을 할 수 있고, 무엇은 어렵나?

Astro: 정적 사이트를 위해 태어난 프레임워크

Astro는 설계 초기부터 정적 사이트를 겨냥했습니다. 거의 설정할 필요 없이 npm run build를 실행하면 HTML, CSS, JS 파일 묶음이 나오고, 이를 아무 CDN에 올리면 바로 접근할 수 있습니다.

Astro의 핵심 기능:

1. 내장 Markdown 지원: 블로그 쓰기가 아주 편합니다. .md 파일을 바로 페이지로 변환합니다
2. Content Collections: 글과 문서를 타입 안정적으로 관리하며 TypeScript 타입 힌트를 제공합니다
3. 여러 프레임워크 혼용: 한 페이지 안에서 React, Vue, Svelte 컴포넌트를 함께 사용할 수 있습니다
4. 제로 설정 배포: GitHub Pages, Netlify, Cloudflare Pages에 쉽게 배포할 수 있습니다

저는 특히 Content Collections 기능을 좋아합니다. 다른 프레임워크로 블로그를 만들 때는 글의 front matter, 예를 들면 title이나 date 같은 메타데이터 필드를 자주 틀렸고 빌드할 때야 알게 되었습니다. Astro는 개발 중에 타입 검사를 해주기 때문에 잘못 쓰면 바로 오류가 납니다. 디버깅 시간을 꽤 줄여줍니다.

Astro도 SSR을 할 수 있습니다:

그렇다고 Astro가 정적 사이트만 만들 수 있는 것은 아닙니다. 2.0 버전부터는 서버 사이드 렌더링도 지원합니다. 필요한 페이지에는 SSR을 쓰고, 나머지 페이지는 정적으로 유지할 수 있습니다.

다만 솔직히 말하면 Astro의 SSR 경험은 Next.js만큼 성숙하지 않습니다. 사용자 인증, API 라우트, 데이터베이스 작업을 만들고 싶다면 Astro로도 가능하지만 생태계와 도구 체인은 아직 덜 완성된 느낌입니다.

Next.js: 만능 선수지만 정적 export에는 제약이 있습니다

Next.js의 포지션은 “만능 프레임워크”입니다. 정적, SSR, ISR(증분 정적 생성)을 모두 지원합니다. 듣기에는 좋아 보이지만 정적 사이트만 만들고 싶다면 몇 가지 제약을 만나게 됩니다.

Next.js 정적 export의 제약:

next.config.js에서 output: 'export'를 설정하면 아래 기능을 사용할 수 없습니다.

• ❌ API Routes: 내장 API 라우트 기능을 사용할 수 없습니다
• ❌ Server Actions: React 19의 Server Actions를 지원하지 않습니다
• ❌ ISR: 증분 정적 생성을 사용할 수 없습니다
• ❌ 동적 라우팅의 일부 기능: 예를 들어 getServerSideProps를 사용할 수 없습니다
• ❌ 이미지 최적화: next/image의 자동 최적화를 쓰려면 CDN을 직접 설정해야 합니다

이 제한 목록은 Next.js 공식 문서에 자세히 나와 있습니다. 하지만 많은 사람이 프로젝트를 시작할 때는 이를 놓칩니다. 한참 만들다가 특정 기능을 쓸 수 없다는 사실을 알게 되면 꽤 곤란합니다.

저도 이 문제를 겪은 적이 있습니다. 문서 사이트에 간단한 검색 기능을 넣으려고 API Route로 처리하려 했는데, 정적 export에서는 API Route를 지원하지 않는다는 걸 뒤늦게 알았습니다. 결국 클라이언트 검색 방식으로 바꿨고, 그 과정에서 시간을 꽤 썼습니다.

Next.js가 강한 상황:

정적 export에 스스로를 묶어두지 않는다면 Next.js의 능력은 매우 강합니다.

• SSR과 ISR: SEO와 실시간 데이터가 모두 필요한 전자상거래, 뉴스 사이트에 적합합니다
• App Router: 스트리밍 렌더링과 병렬 라우팅을 지원하는 새로운 라우팅 시스템입니다
• Server Components: 클라이언트 JavaScript를 줄여 성능을 개선합니다
• 성숙한 생태계: Auth.js(인증), Prisma(데이터베이스 ORM), tRPC(타입 안전 API) 등이 Next.js와 깊게 통합되어 있습니다

프레임워크 유연성: 이 부분은 Astro의 승리입니다

이 지점은 꽤 흥미롭습니다.

Astro는 React, Preact, Svelte, Vue, SolidJS 등 여러 UI 프레임워크를 지원하며, 한 프로젝트 안에서 섞어 쓸 수도 있습니다. 예를 들어 복잡한 상호작용 컴포넌트는 React로 만들고, 가벼운 UI는 Svelte로 작성해도 충돌하지 않습니다.

Next.js는 React 생태계에 묶여 있습니다. React를 좋아하지 않거나 다른 프레임워크를 시도해 보고 싶다면 선택지가 거의 없습니다.

이 프레임워크 독립성은 기존 프로젝트를 리팩터링할 때 특히 유용합니다. 예를 들어 Vue로 작성한 컴포넌트가 있는데 Astro로 이전하고 싶다면, 전부 React로 다시 쓸 필요 없이 그대로 재사용할 수 있습니다.

실제 선택 조언:

• 순수 정적 사이트이고 서버 기능이 필요 없다면 Astro
• SSR, API, 데이터베이스가 필요하다면 Next.js
• 여러 UI 프레임워크를 시도하고 싶다면 Astro
• React 생태계에 깊이 들어가 있다면 Next.js

4. 개발 경험: 실제로 써보면 편한가?

학습 곡선: Astro가 더 친근합니다

HTML을 쓸 줄 안다면 Astro 컴포넌트도 거의 쓸 수 있습니다. .astro 파일 문법은 HTML의 상위 집합에 가깝고, 5분 정도 보면 감이 옵니다.

---

const title = "내 블로그";

---

<html>
  <head>
    <title>{title}</title>
  </head>
  <body>
    <h1>환영합니다!</h1>
  </body>
</html>

이 정도입니다. 위쪽 세 개의 하이픈 사이에는 로직을 쓰고, 아래에는 HTML을 씁니다. JSX처럼 여러 규칙을 외울 필요가 적습니다.

Next.js의 학습 곡선은 상대적으로 더 가파릅니다. 특히 새로운 App Router를 처음 사용할 때는 Server Components, use client, use server 같은 개념이 조금 혼란스러웠습니다. 이해하고 나면 설계가 영리하다는 생각이 들지만, 적응에는 시간이 필요합니다.

프론트엔드 초보이거나 프레임워크 학습에 시간을 많이 쓰고 싶지 않다면 Astro가 더 친절합니다. 이미 React 생태계에 익숙하다면 Next.js의 새로운 개념들이 오히려 더 좋은 코드를 쓰는 데 도움이 될 수 있습니다.

개발 효율: 각자 장점이 있습니다

Astro의 장점:

1. 콘텐츠 관리가 매우 편합니다: Markdown을 바로 쓰면 페이지와 라우트가 자동으로 생성됩니다
2. 핫 리로드가 빠릅니다: 파일을 수정하면 브라우저가 거의 즉시 갱신됩니다
3. 빌드 속도가 빠릅니다: 50페이지짜리 문서 사이트를 테스트했을 때 Astro는 8초, Next.js는 25초가 걸렸습니다

Next.js의 장점:

1. Fast Refresh: React 컴포넌트를 수정할 때 상태를 유지해 디버깅 경험이 좋습니다
2. 도구 체인이 완성되어 있습니다: ESLint 설정과 TypeScript 지원이 기본으로 잘 갖춰져 있습니다
3. 오류 메시지가 자세합니다: 문제 위치를 빠르게 찾기 쉽습니다

솔직히 문서나 블로그 같은 콘텐츠 사이트를 개발할 때는 Astro가 확실히 효율적입니다. 예전에 Next.js로 문서를 만들 때는 새 페이지를 추가할 때마다 파일을 만들고, 라우트를 생각하고, 컴포넌트를 작성해야 했습니다. Astro에서는 새 .md 파일 하나면 끝입니다. 라우트는 자동으로 만들어집니다.

반대로 복잡한 상호작용 앱을 만든다면 Next.js의 개발 경험이 더 좋습니다. 폼, 데이터 검증, API 호출이 들어가는 기능을 만들 때 Next.js의 도구 체인과 생태계는 시간을 많이 아껴줍니다.

배포 편의성: Astro가 더 유연합니다

이건 꽤 현실적인 문제입니다. 다 만들고 나면 어디에 어떻게 배포할까요?

Astro의 배포 방식:

Astro의 빌드 결과물은 순수 정적 파일입니다. 어디에든 배포할 수 있습니다.

• GitHub Pages: 무료이며 Actions로 자동 배포할 수 있습니다
• Netlify/Cloudflare Pages: 무료 한도가 충분하고 속도도 빠릅니다
• 자체 Nginx 서버: 파일을 올리기만 하면 됩니다

저는 지금 Cloudflare Pages로 Astro 사이트를 배포하고 있습니다. 자동 배포를 설정해두면 코드를 push할 때마다 바로 배포되고, 글로벌 CDN 가속까지 붙습니다. 비용도 들지 않습니다.

Next.js의 배포 방식:

정적 export를 한 Next.js도 어떤 정적 호스팅 플랫폼에나 올릴 수 있습니다. 하지만 SSR이나 ISR을 쓰려면 서버 환경을 고려해야 합니다.

Vercel은 Next.js의 가장 좋은 배포 파트너입니다. 같은 회사가 만든 만큼 배포 경험은 확실히 좋습니다. 다만 다른 플랫폼에서는 그만큼 매끄럽지 않을 때가 있습니다. Railway나 Render에 Next.js를 배포해 본 적이 있는데, 설정은 Astro보다 조금 더 번거로웠습니다.

비용 관점:

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

개인 프로젝트나 작은 사이트라면 둘 다 무료 호스팅으로 충분합니다. 하지만 트래픽이 커지면 차이가 생깁니다.

• Astro 정적 사이트: 순수 CDN 호스팅이라 비용이 거의 없습니다
• Next.js SSR: 서버 리소스가 필요하므로 트래픽이 커지면 비용도 올라갑니다

많은 회사가 마케팅 사이트나 문서 사이트에 Astro를 선택하는 이유 중 하나도 바로 이 비용 절감입니다.

문서와 커뮤니티: Next.js가 더 성숙합니다

인정할 부분은 인정해야 합니다. Next.js 공식 문서는 정말 잘 쓰여 있습니다. 명확하고 자세하며 예제가 많아서 대부분의 문제를 커버합니다.

Astro 문서도 좋지만, 일부 엣지 케이스는 설명이 부족할 때가 있습니다. 예를 들어 복잡한 동적 라우트를 만들려고 했을 때 문서와 issue를 꽤 뒤져야 해결책을 찾을 수 있었습니다.

커뮤니티 측면에서는 Next.js 뒤에 Vercel이라는 든든한 지원이 있고 생태계도 더 성숙합니다. 필요한 해결책을 찾으면 대체로 이미 누군가 만들어 둔 것이 있습니다. Astro 커뮤니티도 빠르게 성장하고 있지만 규모는 아직 차이가 납니다.

그럼에도 Astro 커뮤니티 분위기는 마음에 듭니다. Discord에서 질문하면 핵심 개발자가 직접 답하는 경우도 있고, 꽤 실용적인 느낌이 있습니다.

5. 생태계와 커뮤니티: 장기적으로 믿을 수 있을까?

프레임워크를 고를 때는 당장의 기능만 볼 수 없습니다. 너무 작은 프레임워크를 골랐다가 2년 뒤 유지보수가 끊기면 이전 비용이 만만치 않습니다.

데이터 비교: Next.js는 더 성숙하고, Astro는 빠르게 성장합니다

먼저 GitHub 데이터(2025년 기준)를 보겠습니다.

• Next.js: 125k+ stars, Vercel 지원, 주간 npm 다운로드 1,000만 회 이상
• Astro: 45k+ stars, 독립 팀, 주간 npm 다운로드 50만 회 이상

숫자로 보면 Next.js가 확실히 앞서 있습니다. 하지만 흥미로운 점은 Astro의 성장 속도입니다. 2년 동안 지켜봤는데 star 수가 거의 세 배가 되었고, 커뮤니티 활동도 빠르게 늘고 있습니다.

기업 적용 사례

Astro를 사용하는 유명 프로젝트:

• GitHub: github.dev의 개발자 문서에 Astro를 사용합니다
• Smashing Magazine: WordPress에서 Astro로 이전하며 성능이 크게 개선되었습니다
• Firebase: 개발자 문서 사이트를 Astro로 구축했습니다

Next.js를 사용하는 유명 프로젝트:

• Netflix, Uber, TikTok 같은 큰 기업에서도 사용합니다
• 많은 SaaS 제품: Vercel 자체가 가장 좋은 사례입니다
• 전자상거래 플랫폼: Shopify의 여러 스토어가 Next.js를 사용합니다

적용 범위를 보면 Next.js는 더 넓고, Astro는 문서, 블로그, 마케팅 사이트 같은 콘텐츠형 웹사이트에 집중되어 있습니다.

플러그인과 통합 생태계

Astro의 통합 생태계:

Astro에는 전용 통합 시스템이 있어 npx astro add xxx로 플러그인을 설치할 수 있습니다. 현재 공식과 커뮤니티에서 100개 이상의 통합을 제공합니다.

• UI 프레임워크 통합: React, Vue, Svelte 등
• CMS 통합: Contentful, Sanity, Strapi
• 도구 통합: Tailwind, MDX, Sitemap, RSS

솔직히 Astro의 통합 생태계는 Next.js만큼 거대하지는 않습니다. 그래도 자주 쓰는 것은 대부분 갖춰져 있습니다. 실제로 사용하면서 꼭 필요한 플러그인을 찾지 못해 막힌 적은 거의 없었습니다.

Next.js의 플러그인 생태계:

Next.js는 전체 React 생태계의 패키지를 사용할 수 있습니다. 선택지가 압도적으로 많습니다. 원하는 기능이 있다면 대체로 이미 만들어진 라이브러리를 찾을 수 있습니다.

또한 Next.js는 여러 인기 도구와 깊게 통합되어 있습니다.

• Prisma: 데이터베이스 ORM, 설정이 간단합니다
• Auth.js(NextAuth): 인증 기능을 몇 줄의 코드로 붙일 수 있습니다
• Vercel Analytics: 내장 분석 도구입니다
• Turbopack: 차세대 번들러입니다. 아직 beta 단계이긴 합니다

상업적 지원과 안정성

Next.js의 장점:

Vercel은 매년 큰 규모의 투자를 받으며 Next.js 개발 전담 팀을 운영합니다. 프로젝트가 갑자기 멈출 걱정도 적고, 버그를 만났을 때 방치될 가능성도 낮습니다.

Vercel은 새 기능에도 계속 투자합니다. React Server Components가 나오자 Next.js는 빠르게 이를 지원했습니다. 이런 반응 속도는 독립 프로젝트가 따라가기 쉽지 않습니다.

Astro의 상황:

Astro 팀은 상대적으로 작지만 점차 상업화도 진행하고 있습니다. Astro Studio라는 콘텐츠 관리 도구를 내놓으면서 비즈니스 모델도 찾고 있습니다.

규모는 Vercel보다 작지만 Astro 팀의 실행력은 꽤 좋다고 봅니다. 업데이트 주기가 빠르고 커뮤니티 피드백에도 민첩하게 반응합니다. 프로젝트가 건강하게 성장하고 있다는 느낌이 듭니다.

학습 자료

Next.js:

• 공식 문서가 매우 자세하며 튜토리얼과 예제가 많습니다
• Vercel이 무료 온라인 강좌를 제공합니다
• YouTube에 수많은 튜토리얼이 있고, 영어와 중국어 자료 모두 많습니다
• 문제가 생기면 Stack Overflow에서 답을 찾을 가능성이 높습니다

Astro:

• 공식 문서는 명확하지만 깊이 있는 콘텐츠는 상대적으로 적습니다
• 커뮤니티 튜토리얼은 늘고 있지만 아직 충분히 많지는 않습니다
• 중국어 자료는 상대적으로 적고, 영어 콘텐츠가 더 많습니다
• 엣지 케이스를 만나면 Discord나 GitHub issue를 찾아봐야 할 수 있습니다

초보자이거나 튜토리얼을 따라 배우는 방식을 좋아한다면 Next.js의 학습 경로가 더 부드러울 수 있습니다. Astro는 어느 정도 스스로 찾아가며 해결하는 능력이 필요합니다.

제 생각

프레임워크 선택은 숫자만으로 결정할 수 없습니다. Next.js는 확실히 더 성숙하고 생태계도 큽니다. 하지만 Astro는 자신이 집중하는 영역, 즉 콘텐츠형 웹사이트에서는 아주 잘하고 있고 흐름도 좋습니다.

장기 유지보수가 걱정된다면 이렇게 판단하면 됩니다.

• 기업급 프로젝트이고 안정적인 보장이 필요하다면 → Next.js가 더 안전합니다
• 개인 프로젝트나 콘텐츠 사이트라면 → Astro의 리스크는 관리 가능하고 성능 이점도 큽니다

6. 실전 선택 가이드: 나는 무엇을 골라야 할까?

여기까지 왔으니 이제 명확한 기준을 줄 차례입니다. 아래 의사결정 흐름을 따라가면 어떤 프레임워크가 맞는지 감이 잡힙니다.

빠른 의사결정 흐름

1단계: 프로젝트 유형 확인

사이트의 핵심은 콘텐츠 표시인가요, 아니면 상호작용 기능 제공인가요?

• 콘텐츠 중심(블로그, 문서, 포트폴리오, 마케팅 페이지) → 2단계로 이동
• 상호작용 중심(SaaS, 전자상거래, 관리 콘솔, 소셜 앱) → Next.js 선택

2단계: 동적 요구사항 확인

콘텐츠가 실시간으로 갱신되어야 하나요? 사용자 인증이 필요한가요?

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

• 순수 정적 콘텐츠이고 서버가 필요 없다면 → Astro 선택
• 동적 데이터, 사용자 시스템, API가 필요하다면 → Next.js 선택

3단계: 팀 기술 스택 확인

팀이 React에 익숙한가요?

• React를 깊게 쓰고 있고 React 생태계를 선호한다면 → Next.js도 좋은 선택입니다
• 기본 프론트엔드 지식만으로 충분하고 프레임워크에 묶이고 싶지 않다면 → Astro가 더 유연합니다

구체적인 상황별 추천

Astro를 강하게 추천하는 상황:

1. 개인 기술 블로그

   • 이유: Markdown 기본 지원, 뛰어난 성능, 무료 호스팅
   • 실제 경험: 제 블로그를 Next.js에서 Astro로 옮긴 뒤 Lighthouse가 85점에서 99점으로 올랐습니다

2. 제품 문서 사이트

   • 이유: Content Collections의 타입 안정성, 검색 친화성, 빠른 빌드
   • 사례: GitHub와 Firebase도 사용합니다

3. 회사 홈페이지/마케팅 랜딩 페이지

   • 이유: 로딩 속도는 전환율에 영향을 주고, SEO 친화적이며, 유지보수 비용이 낮습니다
   • 효과: 페이지 로딩이 0.5초 빨라지는 것만으로도 전환율이 10% 이상 좋아질 수 있습니다

4. 개인 포트폴리오

   • 이유: 여러 프레임워크를 섞어 쓸 수 있어 다양한 기술 스택의 결과물을 보여주기 좋습니다
   • 장점: 배포가 간단하고 완전히 무료로 운영하기 쉽습니다

Next.js를 강하게 추천하는 상황:

1. 전자상거래 사이트

   • 이유: SEO를 위해 SSR이 필요하고, 주문 처리를 위한 API와 실시간 재고가 필요합니다
   • 핵심 기능: ISR로 증분 업데이트를 구현해 성능과 실시간성을 균형 있게 가져갈 수 있습니다

2. SaaS 앱

   • 이유: 많은 상호작용, 사용자 인증, 데이터베이스 통합, API 라우트가 필요합니다
   • 생태계 장점: Auth.js, Prisma, tRPC 같은 도구가 깊게 통합되어 있습니다

3. 콘텐츠 플랫폼(Medium과 비슷한 서비스)

   • 이유: 사용자의 글 작성, 댓글, 좋아요 같은 동적 기능이 필요합니다
   • 기술 장점: SSR로 SEO를 확보하고 Server Actions로 폼 처리를 단순화할 수 있습니다

4. 실시간 협업 도구

   • 이유: WebSocket, 실시간 상태 동기화, 복잡한 상호작용이 필요합니다
   • 적합성: React의 상태 관리 방식이 더 성숙합니다

마이그레이션 판단: 바꿀 가치가 있을까?

이미 Next.js 프로젝트가 있고 Astro로 옮길지 고민 중이라면, 스스로 세 가지를 물어보세요.

1. 성능이 정말 병목인가요?

Lighthouse 점수가 이미 90점 이상이고 사용자 경험도 좋다면 이전 효과는 크지 않습니다. 점수가 80점 아래이고 느린 로딩이 사용자 경험에 영향을 준다면 고려할 만합니다.

2. 프로젝트에 동적 기능이 얼마나 많나요?

API Routes, getServerSideProps 같은 Next.js 고유 기능을 많이 쓰고 있다면 이전 비용이 높습니다. 반대로 주로 정적 콘텐츠라면 이전은 비교적 쉽습니다.

3. 이전 비용 대비 이익은 어떤가요?

50페이지짜리 문서 사이트라면 이전에 1-2일이면 충분할 수 있습니다. 복잡한 전자상거래 사이트라면 몇 주가 걸릴 수 있고, 아예 옮기기 어려울 수도 있습니다.

저도 문서 사이트 하나를 이전한 적이 있습니다. 하루 정도 걸렸고 성능 향상이 확실해서 충분히 가치가 있었습니다. 하지만 다른 프로젝트는 Next.js API를 많이 쓰고 있어 검토 끝에 이전을 포기했습니다.

하이브리드 방식: 둘을 함께 쓸 수 있을까?

어떤 상황에서는 두 프레임워크의 장점을 함께 가져갈 수 있습니다.

방식 1: 프로젝트별로 다른 프레임워크 사용

• 마케팅 사이트는 Astro 사용(landing.example.com)
• 앱은 Next.js 사용(app.example.com)
• 각각 최적화하고 서로 영향을 주지 않습니다

방식 2: 마이크로 프론트엔드 구조

• 메인 프레임워크는 Astro가 맡고 정적 콘텐츠를 처리합니다
• 동적 모듈은 React 컴포넌트로 만들고 Astro에 통합합니다
• 어느 정도 아키텍처 역량이 필요하지만 성능과 기능을 함께 고려할 수 있습니다

이렇게 운영하는 회사를 본 적이 있습니다. 홈페이지는 Astro로 만들어 빠르고 저렴하게 운영하고, 제품 앱은 Next.js로 만들어 기능을 충분히 가져갑니다. 도메인과 디자인 시스템을 통일하면 사용자는 차이를 거의 느끼지 못합니다.

결론

길게 이야기했지만 처음 질문으로 돌아가 보겠습니다. Astro vs Next.js, 정적 사이트에는 무엇을 선택해야 할까요?

제 답은 이렇습니다. 대부분의 콘텐츠형 웹사이트에는 Astro가 더 좋은 선택입니다.

이유는 단순합니다.

• 성능 이점이 분명합니다: 40% 빠르고 JS가 90% 적습니다. 작은 최적화가 아니라 체감되는 차이입니다
• 개발 경험이 좋습니다: Markdown으로 바로 쓰고, 라우트가 자동 생성되어 시간과 노력을 아낄 수 있습니다
• 배포 비용이 낮습니다: 순수 정적 호스팅과 CDN 가속만으로 충분하며 무료 운영도 가능합니다
• 유지보수가 쉽습니다: 빌드가 빠르고 문제가 적으며 반복 작업이 가볍습니다

물론 Next.js도 분명한 역할이 있습니다. SSR, API, 데이터베이스 같은 서버 기능이 필요하다면 Next.js가 정답에 가깝습니다.

실행 조언을 하나 드리겠습니다:

아직 고민 중이라면 오후 한 번을 써서 작은 실험을 해보세요.

1. Astro와 Next.js로 각각 간단한 블로그를 만듭니다
2. 같은 내용을 넣고 빌드 시간, 패키지 크기, Lighthouse 점수를 비교합니다
3. 어느 쪽이 더 손에 맞는지 확인합니다

직접 해보면 글 열 편을 읽는 것보다 더 확실합니다.

저도 처음에는 Next.js가 최선이라고 생각했습니다. 그런데 Astro를 써보고 나서야, 제가 찾던 것은 이쪽이라는 걸 알았습니다. 당신의 답은 저와 다를 수 있지만, 적어도 직접 확인했다면 후회는 줄어듭니다.

마지막으로 솔직히 말하면, 프레임워크는 도구일 뿐입니다. 중요한 것은 좋은 제품을 만드는 것입니다. 도구 선택에 너무 많은 시간을 쓰지 말고, 손에 맞는 것을 고른 뒤 빨리 시작하는 편이 낫습니다.

당신의 프로젝트가 빨리 세상에 나오길 바랍니다.