Astro vs Next.js: 정적 사이트 성능이 40% 더 빠른 기술적 이유

기술 블로그용 프레임워크를 고를 때 꽤 오래 고민했습니다. Next.js는 Vercel이 만들었고 강력한 React 생태계를 갖추고 있습니다. Astro는 커뮤니티에서 평판이 좋고 ‘압도적인 성능’, ‘Lighthouse 만점’을 내세웁니다. 온라인 비교 글을 많이 읽어 봤지만 누구는 Astro가 빠르다고 하고, 누구는 Next.js가 기능이 더 완전하다고 해서 볼수록 혼란스러웠습니다.

그래서 이틀 동안 두 프레임워크를 모두 직접 써 봤습니다. 같은 콘텐츠로 두 버전의 블로그를 만들고 Lighthouse를 실행했으며, 빌드 속도를 비교하고 실제 배포 후 접속 속도도 측정했습니다. 그 결과 Astro로 바꾼 뒤 Lighthouse 점수가 88점에서 100점으로 올랐고 첫 화면 로딩은 거의 절반으로 줄었습니다.

이 글은 그 비교를 정리한 결과입니다. 어느 한쪽을 과장하거나 깎아내리지 않고 실제 데이터를 바탕으로 성능, 아키텍처, 생태계, 배포라는 네 가지 관점에서 두 프레임워크를 깊이 살펴봅니다. 끝까지 읽으면 자신의 상황에 무엇을 선택해야 할지 알 수 있을 것입니다.

성능 대결 - 진정한 속도의 왕은 누구일까요?

Astro와 Next.js 비교에서 성능은 빼놓을 수 없는 주제입니다. 블로그나 문서 사이트를 만든다면 누구나 더 빠른 로딩과 더 나은 SEO를 원하기 때문입니다.

JavaScript 용량 차이: 90%라는 격차는 과장이 아닙니다

먼저 가장 직관적인 데이터부터 보겠습니다. 같은 콘텐츠로 각각 블로그를 만들었습니다. 약 30개의 글이 있고 코드 하이라이팅과 이미지도 포함했습니다. 빌드 후 JavaScript 번들 크기를 비교한 결과는 다음과 같습니다.

• Next.js 정적 내보내기: 홈페이지 JavaScript 약 85KB(gzip 압축 후)
• Astro: 홈페이지 JavaScript 약 8KB(gzip 압축 후)

이 차이는 실제로 존재합니다. Astro 공식 자료는 JavaScript가 90% 감소한다고 설명하는데, 제가 측정한 결과도 거의 일치했습니다.

왜 이렇게 차이가 클까요? 핵심은 아키텍처 설계입니다. Next.js는 정적 내보내기(SSG)를 사용하더라도 React 런타임, 하이드레이션 로직, 라우팅 관리 같은 기본 코드를 번들에 포함합니다. 반면 Astro는 기본적으로 페이지를 순수 HTML로 렌더링하고 JavaScript를 전혀 보내지 않습니다. 특정 컴포넌트에 client:* 지시어를 명시적으로 추가한 경우만 예외입니다.

쉽게 말해 Next.js는 정적 콘텐츠만 보여 주고 싶어도 완전한 React 도구 세트를 제공합니다. Astro는 필요한 부분만 제공하고 나머지는 아예 포함하지 않습니다.

Lighthouse 점수: Astro는 가볍게 만점을 받습니다

성능은 번들 크기만 볼 수 없고 실제 사용자 경험도 살펴야 합니다. Chrome DevTools의 Lighthouse로 두 사이트를 각각 측정했습니다. 둘 다 프로덕션 환경이며 Vercel에 배포했습니다.

Astro 블로그:

• Performance: 100
• Accessibility: 98
• Best Practices: 100
• SEO: 100

Next.js 블로그(SSG):

• Performance: 88
• Accessibility: 98
• Best Practices: 96
• SEO: 100

성능 항목의 차이는 주로 FCP(First Contentful Paint)와 TTI(Time to Interactive)에서 발생했습니다. Astro 사이트는 대체로 0.5초 안에 최초 콘텐츠 렌더링을 마치지만 Next.js는 1~1.5초가 필요합니다.

흥미롭게도 모바일 3G 네트워크에서는 이 차이가 더 커집니다. Lighthouse의 Slow 4G 시뮬레이션으로 테스트했을 때 Astro의 Performance는 여전히 95점 이상을 유지했지만 Next.js는 약 75점까지 떨어졌습니다.

블로그나 문서 같은 콘텐츠 사이트에서는 Astro의 성능 우위가 분명히 체감됩니다.

빌드 속도: 대규모 프로젝트에서 차이가 더 뚜렷합니다

개발 경험에서는 빌드 속도도 중요한 지표입니다. Starlight와 Nextra를 사용해 1,000페이지 규모의 문서 사이트를 측정했습니다.

• Astro (Starlight): 빌드 시간 약 18초
• Next.js (Nextra): 빌드 시간 약 52초

Astro가 거의 3배 빨랐습니다. 이는 공식적으로 소개하는 ‘Gatsby보다 3배 빠른 속도’와도 대체로 일치합니다.

공정하게 말하면 Next.js 15의 빌드 성능은 크게 개선되었습니다. 이전 버전은 80초 이상 걸렸을 수 있지만 현재는 병렬 빌드 최적화로 약 50초까지 줄었습니다. 그래도 Astro와 비교하면 아직 차이가 있습니다.

실제 사례: 대기업은 무엇을 선택했을까요?

데이터만으로 감이 오지 않는다면 실제 사례를 보면 더 직관적입니다.

Astro를 사용하는 유명 사이트:

• IKEA 개발자 문서
• NordVPN 공식 블로그
• Firebase 문서 사이트
• Cloudflare 개발자 센터

이 사이트들의 공통점은 콘텐츠가 중심이며 최고의 로딩 속도와 SEO 성능을 추구한다는 점입니다.

Next.js를 사용하는 유명 사이트:

• Nike 전자상거래 플랫폼
• Spotify 마케팅 페이지
• Hulu 콘텐츠 플랫폼
• TikTok의 일부 페이지

Next.js 사례는 동적 기능, 사용자 상호작용, 개인화 콘텐츠가 필요한 환경에 더 많이 나타납니다.

이 비교만으로도 선택 기준이 드러납니다. 순수 콘텐츠 표시형 사이트에는 Astro, 동적 상호작용 환경에는 Next.js가 적합합니다.

기술 아키텍처 - Islands와 RSC 중 정적 환경에 더 적합한 것은?

성능 데이터를 보고 나면 이런 궁금증이 생길 수 있습니다. Astro와 Next.js는 내부적으로 어떤 기술을 사용하기에 이렇게 큰 차이가 날까요?

Astro Islands: 페이지는 바다, 상호작용은 섬

Astro의 핵심은 Islands 아키텍처입니다. 처음 들으면 다소 낯설 수 있지만 원리는 단순합니다.

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

지금 시작 →광고

웹페이지를 바다라고 상상해 보세요. 대부분은 정적인 수면, 즉 순수 HTML입니다. JavaScript로 ‘활성화’해야 하는 곳은 상호작용 컴포넌트라는 소수의 섬뿐입니다. 페이지의 검색창, 댓글 영역, 좋아요 버튼 같은 부분이 실제 상호작용을 필요로 합니다.

Astro는 기본적으로 전체 페이지를 정적 HTML로 렌더링한 다음 client:* 지시어로 특정 컴포넌트에 ‘섬’을 열 수 있게 합니다.

---

import SearchBox from '../components/SearchBox.jsx'
import StaticHeader from '../components/Header.astro'

---

<StaticHeader /> <!-- 순수 HTML, JavaScript를 전송하지 않음 -->
<SearchBox client:load /> <!-- 아일랜드이며 JavaScript를 로드함 -->

이 설계에는 세 가지 장점이 있습니다.

1. 필요할 때만 JavaScript 로드: 상호작용 컴포넌트만 JavaScript를 전송하고 나머지는 순수 HTML로 유지합니다.
2. 독립 하이드레이션: 각 아일랜드가 서로 격리되어 간섭하지 않으며 병렬로 로드할 수 있습니다.
3. 유연한 하이드레이션 전략: client:load(즉시 로드), client:idle(브라우저가 유휴 상태일 때), client:visible(뷰포트에 들어올 때)을 선택할 수 있습니다.

실제 예를 들어 보겠습니다. 제 블로그 홈페이지에는 코드 하이라이팅 컴포넌트와 다크 모드 전환 버튼이 있습니다. Astro를 쓰면 다음과 같습니다.

• 코드 하이라이팅은 순수 CSS를 사용합니다(JavaScript 불필요).
• 다크 모드 버튼은 즉시 상호작용해야 하므로 client:load를 사용합니다.
• 결과적으로 홈페이지에서 로드하는 JavaScript는 버튼 코드인 5KB뿐입니다.

Next.js는 어떨까요? 코드 하이라이팅이 정적이어도 전체 React 런타임을 번들에 포함합니다.

Next.js RSC: 서버 컴포넌트로 부담 줄이기

Next.js 15의 해답은 React Server Components(RSC)입니다. 이 기술은 Astro와 어느 정도 비슷하게 ‘서버에서 렌더링할 수 있는 것은 클라이언트로 보내지 않는다’는 접근을 사용합니다.

RSC는 React 컴포넌트를 두 종류로 나눕니다.

1. Server Components(기본값): 서버에서 렌더링되며 브라우저에 JavaScript를 보내지 않습니다.
2. Client Components('use client'로 선언): 상호작용이 필요한 컴포넌트이며 번들에 포함되어 전송됩니다.

// app/components/Header.jsx
// 기본값은 Server Component이며 JavaScript를 전송하지 않음
export default function Header() {
  return <header>My Blog</header>
}

// app/components/SearchBox.jsx
'use client' // 클라이언트 JavaScript가 필요함을 명시적으로 선언
import { useState } from 'react'
export default function SearchBox() {
  const [query, setQuery] = useState('')
  // ...
}

Astro Islands와 비슷해 보이나요? 실제로 닮은 점이 있지만 몇 가지 중요한 차이가 있습니다.

1. 기본 동작이 다릅니다

• Astro: 기본적으로 JavaScript가 없으며 수동으로 ‘아일랜드’를 활성화합니다.
• Next.js: 컴포넌트 코드는 줄지만 기본적으로 React 런타임을 전송합니다.

2. 적합한 환경이 다릅니다

• Astro Islands: 정적 콘텐츠가 중심이고 상호작용이 가끔 필요한 환경에 더 적합합니다.
• Next.js RSC: 동적 콘텐츠가 많고 서버 측 데이터 가져오기가 필요한 환경에 적합합니다.

3. 프레임워크 결합 정도가 다릅니다

• Astro: 프레임워크에 독립적이며 React, Vue, Svelte를 함께 사용할 수 있습니다.
• Next.js: React와 긴밀하게 결합되어 있습니다.

정적 환경에서는 무엇을 선택해야 할까요?

사이트가 순수 정적 콘텐츠(블로그, 문서, 포트폴리오)로 구성된다면 Astro Islands가 더 가볍습니다. 극단적인 예로 순수 Markdown 블로그에서 Astro는 JavaScript를 전혀 보내지 않을 수 있지만 Next.js는 최소한 40~50KB의 기본 런타임을 전송해야 합니다.

그렇다면 동적 콘텐츠 업데이트가 필요할 때는 어떨까요? Next.js의 ISR(Incremental Static Regeneration)이 유리합니다. 예를 들어 블로그가 CMS와 연결되어 새 글을 발행한 뒤 자동으로 갱신되어야 한다면, ISR은 사이트 전체를 다시 빌드하지 않고 특정 페이지를 정해진 시간에 다시 생성할 수 있습니다.

Astro도 4.0 이후 Server Islands를 지원해 동적 콘텐츠를 지연 렌더링할 수 있습니다. 하지만 솔직히 이 기능은 아직 Next.js의 ISR만큼 성숙하지 않았습니다.

제 권장 사항은 다음과 같습니다.

• 90% 이상이 정적 콘텐츠: Astro를 선택하면 성능 향상이 뚜렷합니다.
• 콘텐츠를 자주 업데이트해야 함: Next.js의 ISR이 더 유연합니다.
• 혼합 환경(일부 정적, 일부 동적): 팀의 기술 스택을 고려하면 둘 다 선택할 수 있습니다.

기능 생태계 - 개발 경험과 확장성 비교

아키텍처를 살펴봤으니 실제 개발에서 더 중요하게 느껴지는 질문을 보겠습니다. 두 프레임워크의 사용 경험은 어떤지, 기능은 충분한지 비교해 봅니다.

Markdown 처리: Astro는 바로 사용하고 Next.js는 설정해야 합니다

블로그나 문서 사이트를 만들 때 Markdown은 빼놓을 수 없습니다. 이 부분에서는 Astro의 경험이 훨씬 좋습니다.

Astro의 Markdown 지원:

• .md 파일을 src/pages/에 넣으면 바로 페이지로 렌더링됩니다.
• MDX를 별도 설정 없이 사용할 수 있어 Markdown 안에 컴포넌트를 작성할 수 있습니다.
• Content Collections API가 타입 안전한 콘텐츠 관리를 제공합니다.

// src/content/config.ts
import { defineCollection, z } from 'astro:content'

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    date: z.date(),
    tags: z.array(z.string())
  })
})

export const collections = { blog }

이후 TypeScript 타입 힌트를 활용해 글을 조회할 수 있고 RSS와 Sitemap도 자동으로 생성할 수 있어 매우 편리합니다.

Next.js의 Markdown 처리:

• @next/mdx 또는 next-mdx-remote를 설치해야 합니다.
• remark/rehype 플러그인 체인을 직접 구성해야 합니다.
• 콘텐츠 관리는 contentlayer 같은 서드파티 라이브러리에 의존해야 합니다.

Next.js로 할 수 없다는 뜻은 아니지만 추가 설정이 필요합니다. 초보자에게는 Astro의 즉시 사용 가능한 경험이 확실히 더 친절합니다.

프레임워크 호환성: 진정한 통합은 Astro입니다

이 부분에서는 Astro가 압도적인 차이를 보여 줍니다.

한 프로젝트에서 React, Vue, Svelte, Solid, Preact 등 거의 모든 주요 프레임워크를 함께 사용할 수 있습니다. 예를 들면 다음과 같습니다.

• 내비게이션 바는 팀에 익숙한 React를 사용합니다.
• 폼은 기존 컴포넌트가 있는 Vue를 사용합니다.
• 차트는 성능이 좋은 Svelte를 사용합니다.

---

import ReactNav from './ReactNav.jsx'
import VueForm from './VueForm.vue'
import SvelteChart from './SvelteChart.svelte'

---

<ReactNav client:load />
<VueForm client:visible />
<SvelteChart client:idle />

Next.js는 어떨까요? React와 긴밀하게 결합되어 있어 다른 프레임워크를 쓰기는 사실상 어렵습니다. 이는 단점이라기보다 지향점의 차이입니다. Next.js는 완전한 React 생태계 경험을 제공하는 것이 목표입니다.

하지만 정적 웹사이트 프레임워크 선택이라는 관점에서는 Astro의 유연성이 분명한 장점입니다. 기존 컴포넌트를 모두 다시 작성하지 않고 재사용할 수 있습니다.

플러그인 생태계: Next.js는 규모, Astro는 집중도에서 강합니다

Next.js의 생태계는 확실히 강력합니다.

• npm의 수십만 개 React 라이브러리를 자유롭게 사용할 수 있습니다.
• Vercel이 제공하는 다양한 통합 기능(Analytics, Edge Config, KV 저장소)이 있습니다.
• 커뮤니티가 활발해 거의 모든 문제의 해결책을 찾을 수 있습니다.

Astro의 생태계는 조금 작지만 필요한 기능은 충분합니다.

• 400개 이상의 공식 통합과 커뮤니티 플러그인이 있습니다.
• 문서 사이트 전용 Starlight를 바로 사용할 수 있습니다.
• 이미지 최적화, Sitemap, RSS 같은 일반 기능은 모두 공식 지원합니다.

개인적으로 블로그나 문서 사이트를 만든다면 Astro 생태계로 충분하다고 느꼈습니다. 하지만 복잡한 애플리케이션에서는 Next.js의 React 생태계가 강점을 발휘합니다.

개발자 경험: 학습 곡선 비교

Astro 학습 곡선:

• HTML/CSS/JavaScript를 안다면 거의 바로 시작할 수 있습니다.
• .astro 파일 문법이 Vue 단일 파일 컴포넌트처럼 단순합니다.
• 문서가 명확해 10분이면 기본 사용법을 익힐 수 있습니다.

Next.js 학습 곡선:

• React에 익숙해야 합니다.
• App Router의 개념 모델이 비교적 복잡합니다(Server/Client Components, 중첩 레이아웃, 데이터 가져오기).
• 설정 옵션이 많아 초보자는 혼란스러울 수 있습니다.

솔직히 Next.js는 기능이 강력한 만큼 복잡합니다. 블로그를 빠르게 만들고 싶을 뿐이라면 Astro의 단순하고 직접적인 방식이 훨씬 편하게 느껴질 것입니다.

문서 사이트 솔루션 비교: Starlight vs Nextra

정적 웹사이트에서 문서 사이트는 큰 비중을 차지합니다. 두 프레임워크 모두 전용 문서 사이트 솔루션이 있습니다.

Astro Starlight:

• 공식 제품으로 긴밀하게 통합되어 있습니다.
• 사이드바, 검색, 다국어 전환을 자동으로 생성합니다.
• 최고의 성능으로 Lighthouse 만점을 받을 수 있습니다.
• 테마가 깔끔하고 현대적이며 바로 사용할 수 있습니다.

Next.js Nextra:

• Vercel이 개발했으며 Next.js 기반입니다.
• 기능이 풍부하고 사용자 정의 범위가 넓습니다.
• React 생태계의 지원으로 다양한 컴포넌트 라이브러리를 선택할 수 있습니다.
• Starlight만큼 빠르지는 않지만 충분한 성능을 냅니다.

저는 Starlight로 기술 문서 사이트를 만들었고 처음부터 배포까지 2시간밖에 걸리지 않았습니다. 배포 시간까지 포함한 결과이니 실제 사용 경험이 매우 매끄러웠습니다.

적합한 환경 - 선택 의사결정 트리

지금까지 기술적인 내용을 많이 살펴봤습니다. 이제 가장 중요한 질문으로 돌아가겠습니다. 결국 무엇을 선택해야 할까요?

요구 사항과 비교할 수 있도록 의사결정 과정을 정리했습니다.

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

15% 할인 받기 →광고

언제 Astro를 선택해야 할까요?

사이트가 다음 조건 중 두 가지 이상에 해당한다면 Astro를 적극 권장합니다.

1. 콘텐츠가 중심이고 상호작용은 보조적일 때

• 개인 블로그, 기술 문서, 기업 사이트, 마케팅 랜딩 페이지
• 페이지의 90% 이상이 정적 콘텐츠
• 검색창, 댓글 영역, 다크 모드 스위치처럼 소수의 컴포넌트만 상호작용 필요

2. 성능과 SEO가 필수 지표일 때

• Google Lighthouse 점수가 만점에 가까워야 함
• Core Web Vitals가 순위에 직접 영향을 줌
• 모바일의 느린 네트워크 환경에서 자주 접속함

3. Markdown 콘텐츠 관리가 필요할 때

• 글을 Markdown으로 작성하고 이미지는 로컬에 저장함
• Content Collections처럼 타입 안전한 콘텐츠 API가 필요함
• RSS와 Sitemap을 별도 설정 없이 생성하고 싶음

4. 여러 프레임워크를 함께 사용할 때

• 팀에서 React와 Vue를 모두 사용함
• 서로 다른 프레임워크의 기존 컴포넌트를 재사용하고 싶음
• 단일 프레임워크에 종속되고 싶지 않음

5. 빠르게 시작해야 할 때

• 복잡한 프레임워크 개념을 배우고 싶지 않음
• 10분 안에 쓸 수 있는 사이트를 만들고 싶음
• 팀원의 기술 스택이 통일되어 있지 않음

언제 Next.js를 선택해야 할까요?

다음과 같은 요구 사항이라면 Next.js가 더 적합합니다.

1. 동적 콘텐츠 업데이트가 필요할 때

• Headless CMS(Contentful, Sanity)에 연결함
• 콘텐츠를 정해진 시간이나 필요할 때 다시 생성해야 함(ISR)
• 댓글, 좋아요, 북마크 같은 사용자 생성 콘텐츠가 있음

2. 복잡한 동적 라우팅이 필요할 때

• 전자상거래 사이트(상품 상세 페이지, 장바구니, 결제)
• 커뮤니티 포럼(사용자 프로필, 게시물, 답글)
• 서버 측에서 많은 데이터를 가져와야 함

3. React와 깊이 통합해야 할 때

• 팀에서 이미 React를 깊이 사용하고 있음
• 프로젝트가 React 생태계의 특정 라이브러리에 의존함
• Next.js의 통합 기능(Auth, Analytics, Edge Functions)이 필요함

4. 하이브리드 렌더링이 필요할 때

• 일부 페이지는 순수 정적이고 일부는 SSR이 필요함
• 사용자 로그인 상태에 따른 개인화 콘텐츠가 필요함
• API Routes를 BFF 계층으로 사용함

5. Vercel 생태계에 결합되어 있을 때

• 이미 Vercel 플랫폼을 사용하고 있음
• Vercel이 제공하는 다양한 통합 서비스가 필요함
• 원클릭 배포와 자동 최적화를 원함

실제 사례: 어떻게 선택했을까요?

몇 가지 실제 마이그레이션 사례를 소개하겠습니다.

Next.js에서 Astro로 마이그레이션한 사례:

• situ2001의 블로그: 순수 정적 콘텐츠로, 마이그레이션 후 Lighthouse 점수가 88점에서 100점으로 올랐고 빌드 시간은 절반으로 줄었습니다.
• 어느 기술 문서 사이트: 1,000페이지 이상 규모에서 마이그레이션 후 빌드 시간이 80초에서 20초로 줄고 첫 화면 로딩은 40% 빨라졌습니다.

마이그레이션한 이유:

1. 무거운 React 런타임이 필요하지 않았습니다.
2. 최고의 성능을 추구했습니다.
3. Markdown 처리 경험이 더 좋았습니다.

Next.js를 계속 사용한 사례:

• 어느 온라인 교육 플랫폼: 사용자 로그인, 학습 진도 추적, 동적 추천이 필요합니다.
• 전자상거래 사이트: 상품 데이터가 자주 바뀌어 ISR로 정기적으로 다시 생성해야 합니다.
• SaaS 제품의 마케팅 사이트: 정적 소개 페이지와 동적 Demo가 섞여 있습니다.

Next.js를 선택한 이유:

1. 서버 측 렌더링과 동적 기능이 필요했습니다.
2. 팀에 기존 React 기술 경험이 있었습니다.
3. Vercel의 통합 배포가 편리했습니다.

마이그레이션 비용 평가

현재 Next.js를 사용 중인데 Astro로 전환하려면 비용이 얼마나 들까요?

낮은 비용 환경(1~2일):

• 순수 Markdown 블로그
• 복잡한 React 컴포넌트가 없음
• Next.js 전용 API에 의존하지 않음

중간 비용 환경(1~2주):

• 사용자 정의 React 컴포넌트가 있음(Astro Islands로 감싸 그대로 사용 가능)
• 이미지 최적화 방식을 조정해야 함
• 레이아웃과 라우팅 로직을 다시 작성해야 함

높은 비용 환경(마이그레이션 비추천):

• React Hooks와 상태 관리를 대량으로 사용함
• Next.js의 API Routes, Middleware에 의존함
• 복잡한 서버 측 데이터 가져오기 로직이 있음

제 권장 사항은 이렇습니다. 사이트의 90%가 정적 콘텐츠라면 마이그레이션 효과가 뚜렷합니다. 동적 기능 비중이 30%를 넘는다면 굳이 옮기지 않는 편이 낫습니다.

의사결정 체크리스트: 세 가지 질문으로 선택하기

아직 확신이 서지 않나요? 다음 세 가지 질문에 답해 보세요.

Q1: 콘텐츠를 얼마나 자주 업데이트하나요?

• 매일/매주 업데이트 → Next.js(ISR이 편리함)
• 몇 달에 한 번 업데이트 → Astro(성능 우선)

Q2: 사이트에 상호작용 기능이 얼마나 많나요?

• 댓글/검색 정도만 있음 → Astro(Islands로 충분함)
• 사용자 상호작용이 많음 → Next.js(React 생태계가 강력함)

Q3: 팀은 어떤 기술 스택을 사용하나요?

• 여러 프레임워크 / 순수 HTML → Astro(유연함)
• React 중심 → Next.js(매끄럽게 통합됨)

답을 정리하면 이미 어느 쪽이 맞는지 감이 올 것입니다.

실전 조언 - 시작 및 배포 가이드

이론을 살펴봤으니 이제 실습해 보겠습니다. 무엇을 선택하든 이 부분은 빠르게 시작하는 데 도움이 됩니다.

빠른 시작: 10분 만에 Hello World 만들기

Astro 빠른 시작:

# 프로젝트 생성
npm create astro@latest my-blog

# 템플릿 선택(Blog 또는 Empty 권장)
cd my-blog
npm install
npm run dev

http://localhost:4321을 열면 실행 중인 사이트가 보입니다. src/pages/index.astro를 수정하고 저장하면 즉시 반영됩니다.

Next.js 빠른 시작:

# 프로젝트 생성
npx create-next-app@latest my-blog

# 안내에 따라 선택(TypeScript, App Router, Tailwind 등)
cd my-blog
npm run dev

http://localhost:3000을 열고 app/page.tsx를 편집하면 변경 내용을 확인할 수 있습니다.

둘 다 초기화는 빠르지만 Astro 기본 템플릿은 블로그에 더 적합하고 Next.js 템플릿은 애플리케이션 개발에 더 가깝습니다.

추천 Starter 템플릿

Astro:

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

• Astro Blog: 간결하고 실용적인 공식 블로그 템플릿
• AstroPaper: 검색, 태그, RSS를 지원하는 완전한 기능의 블로그 테마
• Starlight: 별도 설정 없이 쓰는 문서 사이트 전용 솔루션

Next.js:

• Next.js Blog Starter: 공식 블로그 예제
• Nextra: 문서 사이트 솔루션
• Contentlayer Blog: Contentlayer를 통합한 블로그

개인적으로 기능이 완전하고 성능과 디자인도 좋은 AstroPaper를 추천합니다.

배포 방식 비교

프레임워크를 골랐다면 다음 단계는 배포입니다. 두 프레임워크 모두 배포 경험이 좋지만 각각 특징이 있습니다.

Vercel(권장):

• Astro: 무설정으로 자동 인식하며 빌드 명령은 npm run build입니다.
• Next.js: 네이티브 지원, 원클릭 배포, 자동 최적화를 제공합니다.
• 장점: 해외 접속이 빠르고 HTTPS를 자동 설정하며 Preview 환경을 제공합니다.
• 단점: 중국 내 접속이 다소 느리고 무료 플랜의 대역폭은 월 100GB로 제한됩니다.

Netlify:

• 둘 다 지원하며 설정도 매우 간단합니다.
• 장점: 무료 플랜 한도가 더 크고 Functions를 지원합니다.
• 단점: 빌드 속도가 Vercel보다 조금 느립니다.

Cloudflare Pages:

• 둘 다 지원하며 배포 속도가 빠릅니다.
• 장점: 글로벌 CDN, 무제한 대역폭, 매력적인 무료 플랜을 제공합니다.
• 단점: 빌드 환경이 가끔 불안정합니다.

GitHub Pages(정적 호스팅):

• Astro: 완벽하게 지원하며 설정이 간단합니다.
• Next.js: 정적 내보내기(output: 'export')가 필요하고 일부 기능이 제한됩니다.
• 장점: 완전 무료이며 GitHub Actions로 자동 배포할 수 있습니다.
• 단점: 중국 내 접속이 느리고 Server Components를 지원하지 않습니다.

중국 내 접속 최적화 권장 사항

대상 사용자가 중국에 있다면 다음 사항에 주의해야 합니다.

1. CDN 선택: Cloudflare Pages는 중국 내 접속이 Vercel보다 빠릅니다.
2. 폰트 최적화: 로컬 폰트나 중국 내 CDN을 사용해 Google Fonts를 피합니다.
3. 서드파티 리소스: 댓글 시스템은 Disqus보다 GitHub 기반의 Giscus를 선택합니다.
4. 이미지 호스팅: Imgur 대신 Alibaba Cloud OSS나 Tencent Cloud COS를 사용합니다.

제 블로그는 Cloudflare Pages에 배포했으며 중국 내 접속 속도도 꽤 괜찮습니다.

자주 묻는 문제와 해결 방법

Astro의 한계:

• ❌ Dashboard나 SaaS 제품 같은 상호작용이 많은 애플리케이션에는 적합하지 않습니다.
• ❌ 실시간 데이터 업데이트가 Next.js만큼 유연하지 않습니다.
• ✅ 해결 방법: 정적 콘텐츠는 Astro를 사용하고 동적 기능은 독립 서비스로 구현합니다.

Next.js의 과도한 설계 문제:

• ❌ 단순한 블로그에는 너무 무겁습니다.
• ❌ App Router의 학습 곡선이 가파릅니다.
• ✅ 해결 방법: 정적 사이트만 필요하다면 Astro로 전환을 고려합니다.

성능 최적화 Checklist(공통):

• ☑ 이미지는 WebP 형식을 사용하고 지연 로딩을 설정합니다.
• ☑ 폰트는 font-display: swap을 사용해 렌더링 차단을 방지합니다.
• ☑ 서드파티 스크립트는 지연 로드합니다(Google Analytics, 광고).
• ☑ HTTP/2와 Brotli 압축을 활성화합니다.
• ☑ 적절한 Cache-Control 헤더를 설정합니다.

추천 학습 자료

Astro:

• 공식 문서: 설명이 명확해 읽고 나면 기본 사용법을 익힐 수 있습니다.
• Astro Blog Tutorial: 블로그 제작 과정을 단계별로 안내하는 공식 튜토리얼
• Starlight 문서: 문서 사이트를 만들 때 꼭 읽어야 할 자료

Next.js:

• 공식 문서: 내용은 포괄적이지만 조금 장황합니다.
• Next.js Learn: 초보자에게 적합한 대화형 튜토리얼
• App Router 마이그레이션 가이드: Pages Router에서 마이그레이션할 때 꼭 읽어야 할 자료

이 자료들을 살펴보면 기본 개발을 시작할 수 있습니다.

결론

지금까지 내용을 정리해 보겠습니다.

Astro vs Next.js에서 절대적으로 ‘누가 더 낫다’고 말할 수는 없습니다. 핵심은 사용 환경입니다.

제 선택은 무엇일까요?

저라면 다음처럼 권하겠습니다.

• 개인 블로그, 기술 문서: 고민하지 말고 Astro를 선택합니다.
• 기업 사이트, 랜딩 페이지: 성능 자체가 경쟁력이므로 Astro를 선택합니다.
• CMS 통합이 필요한 경우: 업데이트가 드물면 Astro, 자주 하면 Next.js를 선택합니다.
• 복잡한 애플리케이션, 전자상거래: 망설이지 말고 Next.js를 선택합니다.
• 팀에서 이미 React를 깊이 사용하는 경우: 학습 비용이 낮은 Next.js를 선택합니다.

저는 최종적으로 Astro를 선택했습니다. 주된 이유는 다음과 같습니다.

1. 블로그 콘텐츠의 95%가 정적이라 무거운 React 런타임이 필요하지 않습니다.
2. Lighthouse 만점을 받는 만족감이 컸고 SEO 순위도 실제로 개선되었습니다.
3. Markdown 처리 경험이 매우 좋아 글쓰기 효율이 높아졌습니다.

하지만 솔직히 Demo와 사용자 Dashboard가 포함된 SaaS 제품 사이트를 만든다면 여전히 Next.js를 선택할 것입니다. 동적 기능이 많아지면 Astro만으로는 충분하지 않습니다.

지금 바로 해 보기:

글만 읽지 말고 10분 동안 직접 시험해 보세요. 두 프레임워크로 각각 Hello World를 만들고 Lighthouse를 실행해 데이터 차이를 확인해 보세요. 백 편의 비교 글보다 실제 경험 한 번이 더 유용합니다.

# Astro
npm create astro@latest test-astro
cd test-astro && npm install && npm run dev

# Next.js
npx create-next-app@latest test-nextjs
cd test-nextjs && npm run dev

만든 뒤 Chrome DevTools를 열어 Lighthouse를 실행하고 직접 성능 차이를 확인하세요. 데이터는 거짓말을 하지 않습니다.

마지막으로 한마디: 프레임워크는 도구일 뿐이고 콘텐츠가 핵심입니다. Astro와 Next.js 중 무엇을 선택하든 고품질 콘텐츠를 만드는 일이 가장 중요합니다. 프레임워크 선택이 글쓰기를 시작하지 않는 핑계가 되게 하지 마세요.

궁금한 점이 있다면 댓글로 이야기해 주세요. 가능한 한 답변하겠습니다. 멋진 사이트를 완성하시길 바랍니다!