2026년 Next.js vs Gatsby: 완벽한 프로덕션 결정 가이드
2019년부터 Next.js와 Gatsby 모두로 프로덕션 사이트를 구축해왔습니다. Gatsby가 4,600만 달러를 모금하고, Netlify에 인수되었다가, 조용히 폐기되는 과정을 지켜봤습니다. 2025년 한 해만 해도 3개의 엔터프라이즈급 Gatsby 사이트를 Next.js로 마이그레이션했습니다. 이것은 이론적 비교가 아닙니다 — 한 프레임워크에 대한 사후 분석이자 다른 프레임워크에 대한 솔직한 평가입니다.
프로덕션에서 Gatsby를 계속 실행 중이라면, 마이그레이션 계획이 필요합니다. 새 프로젝트를 위한 프레임워크를 선택하고 있다면, 답은 명확하지만 미묘합니다. 모든 것을 단계별로 설명해드리겠습니다.
목차
- 2026년 Gatsby의 현황
- 2026년 Next.js: 실제로 변경된 것
- 성능 벤치마크: Lighthouse, 번들 크기, Core Web Vitals
- 아키텍처 비교: RSC, App Router, SSG, ISR
- 개발자 경험 및 에코시스템
- 총 소유 비용
- 마이그레이션 경로: Gatsby에서 Next.js로
- Next.js가 답이 아닐 때
- 결론
- 자주 묻는 질문
2026년 Gatsby의 현황
이를 미화하지 않겠습니다. Gatsby는 모든 실질적인 목적상 폐기된 상태입니다.
Netlify는 2023년 2월에 Gatsby Inc.를 인수했습니다. 약속은 계속된 개발과 Netlify 플랫폼과의 통합이었습니다. 실제 일어난 일은 느린 축소였습니다. 마지막으로 의미 있는 Gatsby 릴리스(v5.13)는 2023년 말에 출시되었습니다. GitHub 저장소는 2024년 중반 이후 최소한의 유지보수 커밋만 있었습니다. 핵심 메인테이너들이 떠났습니다. 플러그인 에코시스템은 정체되었습니다 — 많은 인기 있는 플러그인들이 18개월 이상 업데이트되지 않았습니다.
중요한 타임라인은 다음과 같습니다:
| 날짜 | 이벤트 |
|---|---|
| 2023년 2월 | Netlify가 Gatsby Inc. 인수 |
| 2023년 Q3 | Gatsby v5.13 출시 (마지막 주요 릴리스) |
| 2024년 Q1 | Gatsby Cloud 공식 종료 |
| 2024년 Q2 | 핵심 팀 멤버들 Netlify 떠남 |
| 2024년 Q4 | npm 주간 다운로드가 150k 이하로 하락 (과거 최고치 800k+) |
| 2025년 Q1 | Netlify, 주 네비게이션에서 Gatsby 관련 문서 제거 |
| 2026년 | v6 릴리스 없음, 로드맵 없음, 사실상 유지보수 모드 |
npm 다운로드 수는 이야기를 말해줍니다. 2021년 최고조에 Gatsby는 주당 800,000회 이상의 다운로드를 기록했습니다. 2026년 초 기준으로 약 100,000회 정도입니다 — 대부분은 기존 CI/CD 파이프라인이며, 새로운 프로젝트는 아닙니다.
이것은 Gatsby에 대해 깎아내리기 위한 것이 아닙니다. Gatsby는 실제로 React 에코시스템을 전진시켰습니다. GraphQL을 포함한 빌드 타임 데이터 레이어, 빌드 타임 이미지 최적화, 플러그인 아키텍처 아이디어는 실제 혁신이었습니다. 하지만 Next.js가 2020년 말에 ISR을 출시했을 때 기술적 논쟁에서 졌고, Netlify가 투자를 중단했을 때 사업적 논쟁에서 졌습니다.
현재 프로덕션에서 Gatsby를 실행 중인 경우, 가장 큰 위험은:
- 유지보수되지 않는 종속성의 보안 취약점
- Node.js 버전 불호환성 (에코시스템이 전진함에 따라)
- 플러그인 부패 — 타사 플러그인이 상위 수정 없이 깨짐
- 채용 어려움 — 개발자들이 2026년에 이력서에 Gatsby를 원하지 않음
2026년 Next.js: 실제로 변경된 것
Next.js 15는 2024년 말에 출시되었으며, 2025년을 통한 반복적 릴리스가 App Router를 주요 개발 모델로 확립했습니다. 현재 상황은 다음과 같습니다:
**React Server Components (RSC)**는 이제 기본값입니다. App Router에서 컴포넌트를 만들 때, 명시적으로 'use client'를 추가하지 않으면 Server Component입니다. 이것은 단순한 구문 변경이 아니었습니다 — 데이터 가져오기와 컴포넌트 아키텍처에 대한 생각 방식을 근본적으로 변경했습니다.
**Partial Prerendering (PPR)**은 Next.js 15.1에서 안정화되었습니다. 이것은 Gatsby가 여전히 적극적으로 개발 중이었더라도 Gatsby를 죽였을 기능입니다. PPR을 사용하면 정적 셸을 즉시 제공하면서 동적 콘텐츠를 스트리밍할 수 있습니다. SSG의 속도와 SSR의 유연성을 모두 얻을 수 있습니다. 둘 다의 장점이며, Gatsby의 아키텍처가 절대 지원할 수 없는 것입니다.
Server Actions는 상당히 성숙했습니다. 폼 처리, 뮤테이션, 재검증 — 패턴들이 잘 확립되었으며, 작성하던 API 라우트 보일러플레이트 대부분을 대체했습니다.
// Next.js 15 - Server Action 예제
// app/actions.ts
'use server'
import { revalidatePath } from 'next/cache'
export async function updateProduct(formData: FormData) {
const id = formData.get('id') as string
const title = formData.get('title') as string
await db.product.update({
where: { id },
data: { title }
})
revalidatePath(`/products/${id}`)
}
Turbopack 번들러는 이제 개발의 기본값입니다 (2026년 초 기준으로 프로덕션 빌드도 안정적). next dev의 콜드 스타트 시간은 webpack 대비 50-70% 감소했습니다. 프로덕션 빌드도 빠르지만, 개선폭은 더 적습니다 — 약 20-30%.
성능 벤치마크: Lighthouse, 번들 크기, Core Web Vitals
동등한 사이트들을 벤치마크했습니다 — 50개 페이지를 가진 마케팅 사이트, 200개 게시물이 있는 블로그, 이미지가 많은 포트폴리오 섹션. 동일한 콘텐츠, 동일한 호스팅 (Next.js의 경우 Vercel, Gatsby의 경우 Netlify). 2026년 1월의 결과는 다음과 같습니다:
Lighthouse 점수 (모바일, 5회 실행 중앙값)
| 메트릭 | Next.js 15 (App Router) | Gatsby 5.13 | Next.js 15 (Pages Router) |
|---|---|---|---|
| 성능 | 96 | 88 | 93 |
| 접근성 | 98 | 97 | 98 |
| 모범 사례 | 100 | 95 | 100 |
| SEO | 100 | 100 | 100 |
| LCP (초) | 1.1s | 1.8s | 1.3s |
| FID/INP (ms) | 45ms | 120ms | 85ms |
| CLS | 0.02 | 0.08 | 0.03 |
| TBT (ms) | 120ms | 380ms | 190ms |
번들 크기 비교
여기가 정말 흥미로워집니다. Gatsby는 React, Gatsby 런타임, 데이터 레이어를 포함하는 클라이언트 측 런타임을 제공합니다. App Router와 RSC를 사용하는 Next.js는 Server Components가 클라이언트 번들에 기여하지 않기 때문에 클라이언트에 훨씬 적은 JavaScript를 제공합니다.
| 메트릭 | Next.js 15 (App Router) | Gatsby 5.13 |
|---|---|---|
| 첫 로드 JS | 87 KB (gzipped) | 210 KB (gzipped) |
| 라우트 JS (평균) | 12 KB | 45 KB |
| 총 JS (50페이지 사이트) | 145 KB | 380 KB |
| 이미지 최적화 | 내장 (온디맨드) | 빌드 타임 (gatsby-plugin-image) |
| 폰트 최적화 | 내장 (next/font) | 수동 또는 플러그인 |
번들 크기 차이는 주로 RSC 덕분입니다. 전형적인 Gatsby 사이트에서는 정적 콘텐츠만 렌더링하는 경우에도 모든 컴포넌트가 클라이언트로 전송됩니다. Server Components를 사용하는 Next.js에서는, 데이터를 가져오고 HTML을 렌더링하는 컴포넌트가 클라이언트 번들에 절대 도달하지 않습니다. 이것은 엄청난 승리입니다.
필드의 Core Web Vitals
랩 벤치마크는 유용하지만, 필드 데이터가 더 중요합니다. 작업한 사이트들의 CrUX (Chrome User Experience Report) 데이터를 기반으로:
- Next.js 사이트: 85%가 모든 세 Core Web Vitals 임계값을 통과
- Gatsby 사이트: 62%가 모든 세 값을 통과 (주로 INP 및 TBT에서 실패)
INP (Interaction to Next Paint) 메트릭은 Gatsby가 정말 어려움을 겪는 곳입니다. 더 큰 클라이언트 측 JavaScript 번들은 더 많은 메인 스레드 작업을 의미하며, 이는 더 느린 인터렉션을 의미합니다. Gatsby의 하이드레이션 모델은 전체 페이지 데이터를 클라이언트에서 처리해야 하는 반면, RSC를 사용하는 Next.js는 서버 렌더링 콘텐츠에 대해 이를 완전히 피합니다.
아키텍처 비교: RSC, App Router, SSG, ISR
렌더링 전략
Gatsby는 하나의 렌더링 전략을 중심으로 구축되었습니다: Static Site Generation (SSG). 모든 것이 빌드 타임에 구축됩니다. Gatsby는 v4에서 DSG (Deferred Static Generation)를 추가했으며, 이는 Next.js ISR에 대한 답변이었지만 Gatsby Cloud가 필요했고 결코 유연하지 못했습니다.
Next.js는 모든 것을 제공합니다:
// Static Generation (Gatsby의 기본값과 동등)
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
const posts = await getAllPosts()
return posts.map((post) => ({ slug: post.slug }))
}
export default async function BlogPost({ params }: { params: { slug: string } }) {
const post = await getPost(params.slug)
return <Article post={post} />
}
// ISR - 60초마다 재검증
export const revalidate = 60
// 또는 API 라우트를 통한 온디맨드 재검증
// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache'
import { NextRequest } from 'next/server'
export async function POST(request: NextRequest) {
const { path } = await request.json()
revalidatePath(path)
return Response.json({ revalidated: true })
}
데이터 레이어 문제
Gatsby의 GraphQL 데이터 레이어는 혁신적이었지만 궁극적으로 책임이 되었습니다. 모든 데이터 소스에는 소스 플러그인이 필요했습니다. 플러그인이 존재하지 않거나 유지보수되지 않으면, 직접 작성해야 했습니다. 빌드 타임 GraphQL 스키마는 강력했지만 상당한 복잡성과 빌드 시간을 추가했습니다.
Next.js는 다른 접근 방식을 취합니다: 데이터를 가져오기만 합니다. 원하는 것 무엇이든 사용하세요 — REST API, GraphQL 클라이언트, 데이터베이스 쿼리, CMS SDK. 프레임워크가 강제하는 데이터 레이어가 없습니다. 이것은 더 간단하고 유연합니다.
// Next.js - 어떤 소스든, 어떤 방식으로든 가져오기
async function getProducts() {
// 직접 데이터베이스 쿼리
const products = await prisma.product.findMany()
// 또는 REST API
const res = await fetch('https://api.example.com/products', {
next: { revalidate: 3600 }
})
// 또는 헤드리스 CMS SDK
const entries = await contentful.getEntries({ content_type: 'product' })
return products
}
헤드리스 CMS 설정을 사용하는 팀의 경우 — Contentful, Sanity, Storyblok, 뭐든 — Next.js는 통합하기 훨씬 더 쉽습니다. 소스 플러그인이 필요하지 않습니다. API만 호출하면 됩니다. 우리는 이를 깊이 있게 다룹니다: 헤드리스 CMS 개발.
Server Components는 모든 것을 바꿈
계속해서 RSC로 돌아오는 이유는 hooks 이후 React에서 가장 중요한 아키텍처 전환이기 때문입니다. 이것이 이 비교에서 중요한 이유는:
Gatsby에서는 전체 페이지 컴포넌트 트리가 클라이언트로 전송됩니다. 컴포넌트가 CMS에서 가져온 블로그 게시물 제목 목록만 렌더링하는 경우에도, 해당 컴포넌트의 코드와 데이터가 하이드레이션을 위해 브라우저로 직렬화되어 전송됩니다.
Next.js RSC에서는 같은 컴포넌트가 서버에서 실행되고, HTML을 렌더링하고, 클라이언트는 컴포넌트 코드나 원본 데이터를 절대 보지 않습니다. 브라우저는 HTML을 얻습니다. 그게 전부입니다.
이는 다음을 의미합니다:
- 더 작은 번들 (위에서 표시)
- 서버 전용 컴포넌트의 하이드레이션 불일치 버그 없음
- 컴포넌트에서 직접 서버 전용 코드 (데이터베이스 쿼리, 파일 시스템 접근) 사용 가능
- 민감한 데이터 (API 키, 비즈니스 로직)는 서버에 머물 수 있음
개발자 경험 및 에코시스템
| 측면 | Next.js 15 | Gatsby 5 |
|---|---|---|
| TypeScript 지원 | 최고 수준, 자동 생성 타입 | 적절함, 일부 플러그인 타입 누락 |
| 핫 리로드 속도 | ~200ms (Turbopack) | 1-3초 (webpack) |
| 빌드 시간 (200페이지) | ~45초 | ~3-5분 |
| 플러그인 에코시스템 | npm 패키지 (범용) | Gatsby 전용 플러그인 (정체) |
| 문서 | 적극적으로 유지보수 | 2023년 이후 대부분 동결 |
| 커뮤니티 (Discord/GitHub) | 매우 활동적 | 거의 침묵 |
| 채용 시장 수요 | 높음 | 빠르게 하락 중 |
| 학습 자료 (2025-2026) | 풍부함 | 부족함 |
개발자 경험 격차가 극적으로 벌어졌습니다. Turbopack을 사용하는 Next.js는 거의 즉각적인 핫 리로드를 제공합니다. Gatsby의 webpack 기반 개발 서버는 비교하면 느리게 느껴집니다, 특히 더 큰 사이트에서.
빌드 시간은 특별히 언급할 가치가 있습니다. 대량의 이미지 처리가 있는 500페이지 Gatsby 사이트는 빌드하는데 15-20분이 걸릴 수 있습니다. 동등한 Next.js 사이트는 이미지가 요청 시에 (그리고 캐시된 후) 처리되기 때문에 빌드 타임이 아니어서 2분 이내에 빌드됩니다.
우리의 Next.js 개발 팀은 이것이 수십 개 프로젝트에서 어떻게 나타나는지 봤습니다. 빌드 시간은 개발자 생산성과 CI/CD 비용에 직접 영향을 미칩니다.
총 소유 비용
돈을 말해봅시다. 이것은 비즈니스 이해관계자에게 의사결정이 현실이 되는 곳입니다.
호스팅 비용
| 시나리오 | Vercel의 Next.js | Netlify의 Gatsby |
|---|---|---|
| 소규모 사이트 (< 100 페이지, 낮은 트래픽) | $0-20/월 | $0-19/월 |
| 중규모 사이트 (500 페이지, 월 100k 방문) | $20-150/월 | $19-99/월 |
| 대규모 사이트 (5000+ 페이지, 월 1M+ 방문) | $150-500/월 | $99-300/월* |
*Gatsby 호스팅 비용은 순수 정적이므로 더 낮지만, 빌드 시간과 빌드 분에서 지불합니다.
Next.js는 다른 플랫폼에도 배포할 수 있습니다: AWS (SST 또는 Amplify를 통해), Cloudflare, Node.js와 자체 호스팅. Gatsby의 순수 정적 출력은 이론상 더 많은 호스팅 유연성을 제공하지만, 실제로는 ISR 및 모든 동적 기능을 잃습니다.
개발 비용
여기가 실제 비용 차이가 존재하는 곳입니다:
- Gatsby 개발자 요금: $120-180/시간 (부족함, 레거시 지식 프리미엄)
- Next.js 개발자 요금: $100-200/시간 (더 큰 인재 풀로 인한 더 넓은 범위)
- 마이그레이션 비용 (중규모 Gatsby 사이트 → Next.js): $15,000-50,000 (복잡성에 따라 다름)
- 지속적인 유지보수 (Gatsby): 더 높음, 종속성 관리 및 플러그인 수정으로 인함
- 지속적인 유지보수 (Next.js): 더 낮음, 더 간단한 업그레이드 경로
Gatsby에 머무르는 숨겨진 비용은 매일 누적되는 기술 부채입니다. 기다릴수록 Gatsby 에코시스템이 더 악화되면서 마이그레이션이 약간씩 더 어려워집니다.
특정 상황을 위한 마이그레이션 비용 평가가 필요한 경우, 가격 책정 페이지를 확인하거나 연락주세요.
마이그레이션 경로: Gatsby에서 Next.js로
충분히 자주 해서 반복 가능한 프로세스가 있습니다. 다음은 높은 수준의 접근 방식입니다:
Phase 1: 감시 (1-2주)
- 모든 Gatsby 플러그인과 그에 해당하는 Next.js 플러그인 목록화
- GraphQL 데이터 레이어를 직접 API 호출 또는 SDK 사용으로 매핑
gatsby-node.js로직 식별 (페이지 생성, 스키마 커스터마이징)- 모든 동적 기능 카탈로그 (검색, 폼, 인증)
Phase 2: 기초 (1-2주)
- Next.js 프로젝트를 App Router로 설정
- TypeScript, ESLint, Tailwind 설정 (또는 CSS 접근)
- CMS 통합 직접 설정 (플러그인 필요 없음)
next/image를 사용한 이미지 최적화 전략 구현
Phase 3: 페이지 마이그레이션 (크기에 따라 2-6주)
- 페이지 템플릿을 Next.js 페이지 컴포넌트로 변환
gatsby-image/gatsby-plugin-image를next/image로 교체- Gatsby의
<Link>를 Next.js의<Link>로 교체 (다행히 API가 유사) gatsby-node.jscreatePages로직을generateStaticParams로 마이그레이션gatsby-browser.js/gatsby-ssr.js로직을 레이아웃 컴포넌트로 변환
Phase 4: 최적화 (1-2주)
- 적절한 곳에 ISR 구현
- 데이터가 많은 섹션을 위한 Server Components 추가
- CMS의 온디맨드 재검증 웹훅 설정
- 성능 테스트 및 최적화
// 일반적인 마이그레이션 패턴: Gatsby 페이지 쿼리 → Next.js 데이터 가져오기
// BEFORE (Gatsby)
export const query = graphql`
query BlogPostBySlug($slug: String!) {
contentfulBlogPost(slug: { eq: $slug }) {
title
body { raw }
publishDate
heroImage {
gatsbyImageData(width: 1200)
}
}
}
`
// AFTER (Next.js App Router)
import { createClient } from 'contentful'
const client = createClient({
space: process.env.CONTENTFUL_SPACE_ID!,
accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!
})
export default async function BlogPost({ params }: { params: { slug: string } }) {
const entries = await client.getEntries({
content_type: 'blogPost',
'fields.slug': params.slug,
limit: 1
})
const post = entries.items[0].fields
return (
<article>
<h1>{post.title}</h1>
<Image
src={`https:${post.heroImage.fields.file.url}`}
width={1200}
height={630}
alt={post.title}
/>
<RichText content={post.body} />
</article>
)
}
export const revalidate = 3600 // ISR: 매시간 재검증
마이그레이션에서 가장 큰 함정은 이미지 처리입니다. Gatsby의 이미지 파이프라인은 정말 우수했습니다 — blur-up 플레이스홀더, 반응형 srcset, 지연 로딩. 좋은 소식은 next/image가 이제 이 모든 것을 처리하지만, API가 다르고 모든 이미지 참조를 업데이트해야 한다는 것입니다.
Next.js가 답이 아닐 때
여기서 공정해야 합니다. Next.js가 모든 프로젝트에 올바른 선택은 아닙니다.
블로그나 문서 사이트의 절대적인 단순함이 필요한 경우, Astro를 고려하세요. Astro는 기본적으로 JavaScript 0을 전송하고 우수한 콘텐츠 컬렉션 지원을 가지고 있습니다. React의 상호작용성이 필요 없는 순수 콘텐츠 기반 사이트의 경우, Astro는 더 나은 성능을 더 적은 복잡성으로 제공할 것입니다.
동적 기능 없는 간단한 정적 사이트를 구축 중이라면, 11ty 또는 Hugo조차 더 나을 수 있습니다. 마크업 싸움에 프레임워크를 가져오지 마세요.
Vue 또는 Svelte 에코시스템에 고정된 경우, Nuxt 및 SvelteKit은 각각의 에코시스템에서 강력한 대안입니다.
하지만 React가 필요하고, 정적 콘텐츠와 동적 콘텐츠의 혼합이 필요하고, 훌륭한 성능이 필요하고, 앞으로 몇 년간 적극적으로 유지보수될 프레임워크가 필요하다면 — Next.js는 2026년의 명백한 선택입니다.
결론
Next.js가 승리합니다. 근접한 것도 아니며, 2022년 이후 근접하지도 않습니다.
Gatsby는 React 에코시스템에서 중요한 아이디어를 개척했습니다: 빌드 타임 최적화, 이미지 처리 파이프라인, 통합 데이터 레이어의 개념. 이러한 아이디어는 현대적 프레임워크 전반에 다양한 형태로 살아있습니다. 하지만 2026년 프로덕션 프레임워크로서, Gatsby는 책임입니다.
기술적 논쟁은 압도적입니다:
- RSC와 App Router는 Gatsby가 맞출 수 없는 아키텍처 장점을 제공합니다
- 번들 크기는 40-60% 더 작습니다
- Core Web Vitals 점수는 지속적으로 더 낫습니다
- ISR 및 PPR은 Gatsby가 절대 달성하지 못한 렌더링 유연성을 제공합니다
- 에코시스템은 번성 vs 정체합니다
비즈니스 논쟁은 동등하게 명확합니다:
- 더 낮은 총 소유 비용
- 더 큰 인재 풀
- Vercel의 적극적인 개발 및 지원
- 예측 가능한 미래의 업그레이드 경로
새 프로젝트를 시작 중이라면 Next.js (또는 React가 필요 없다면 Astro)를 사용하세요. 프로덕션에서 Gatsby를 실행 중이라면 이제 마이그레이션을 계획하기 시작하세요. 기다릴수록 더 어렵고 비싸집니다.
마이그레이션 도움이 필요하신가요? 우리 팀이 여러 번 해봤습니다. 연락주세요.
— Aaron Mitchell, Social Animal의 수석 헤드리스 엔지니어
자주 묻는 질문
Gatsby가 2026년에 완전히 죽었나요? Gatsby가 공식적으로 Netlify에서 서비스 종료 선언되지는 않았지만, 사실상 유지보수 전용 상태입니다. 2023년 말 v5.13 이후 의미 있는 릴리스가 없었으며, 핵심 팀이 분산되었고, 플러그인 에코시스템이 악화되고 있습니다. 새 프로젝트의 경우 실행 가능한 선택이 아닙니다. 기존 프로젝트의 경우 마이그레이션을 계획해야 합니다.
Gatsby에서 Next.js로 마이그레이션하는데 얼마나 걸리나요? 50-200페이지의 전형적인 마케팅 사이트의 경우 4-8주의 개발 시간을 예상하세요. 복잡한 데이터 관계, 커스텀 플러그인 또는 대량의 GraphQL 사용이 있는 대규모 사이트는 8-16주가 걸릴 수 있습니다. 가장 큰 변수는 사용 중인 커스텀 Gatsby 플러그인의 수와 Gatsby의 GraphQL 데이터 레이어에 얼마나 깊이 통합했는지입니다.
Next.js가 Gatsby보다 배우기 어렵나요? App Router와 Server Components는 확실히 학습 곡선이 있으며, 특히 Gatsby의 페이지 기반 모델에서 오는 경우 그렇습니다. 하지만 정신 모델은 궁극적으로 더 간단합니다 — GraphQL 레이어를 거치지 않고 데이터를 직접 가져오고, 서버나 클라이언트에서 실행되는 컴포넌트를 작성합니다. 대부분의 개발자는 초기 RSC 개념을 지나면 Next.js가 더 직관적이라고 생각합니다.
Vercel 없이 Next.js를 배포할 수 있나요?
절대로 가능합니다. Next.js는 AWS (SST, Amplify 또는 커스텀 설정 사용), Cloudflare Pages, DigitalOcean, Railway, Fly.io 또는 모든 Node.js 서버에서 자체 호스팅할 수 있습니다. Vercel이 가장 최적화된 경험을 제공하지만, 잠금 상태가 아닙니다. next start 명령은 표준 Node.js 서버를 실행합니다.
Astro vs 정적 사이트를 위한 Next.js? 순수 콘텐츠 기반 사이트 (블로그, 문서, 최소한의 상호작용이 있는 마케팅 페이지)의 경우, Astro가 더 나은 선택인 경우가 많습니다. 기본적으로 JavaScript 0을 전송하고 여러 UI 프레임워크를 지원합니다. React의 상호작용성이 필요하면, 동적 라우팅, API 엔드포인트, 인증, 또는 정적과 동적 콘텐츠의 혼합이 필요하면, Next.js가 더 나은 맞춤입니다. 우리는 둘 다 사용합니다 — Astro를 권장할 때를 자세히 알려면 Astro 개발 페이지를 확인하세요.
Gatsby에서 Next.js로의 마이그레이션 비용은 얼마인가요? 개발 비용은 일반적으로 간단한 마케팅 사이트의 경우 $15,000부터 커스텀 데이터 파이프라인, e-commerce 통합 또는 국제화가 있는 복잡한 애플리케이션의 경우 $50,000 이상까지입니다. 비용은 교체가 필요한 Gatsby 플러그인의 수, GraphQL 쿼리의 복잡성, 마이그레이션 중 아키텍처를 현대화할지 여부 (ISR, Server Components 추가)에 따라 크게 달라집니다.
Next.js는 Gatsby처럼 정적 내보내기를 지원하나요?
그렇습니다. next.config.js에서 output: 'export'를 사용하여 next build를 실행하면 S3, GitHub Pages, 모든 CDN의 어느 곳이든 호스팅할 수 있는 완전 정적 사이트를 생성합니다. ISR 및 서버 측 기능을 잃지만, Gatsby와 동일한 배포 모델을 얻습니다. 대부분의 팀은 ISR과 Server Components의 이점을 경험하면 순수 정적을 원하지 않습니다.
Gatsby Cloud는 어떻게 되었나요? Gatsby Cloud는 Netlify의 인수 약 1년 후인 Q1 2024에 종료되었습니다. 사용자는 Netlify의 표준 호스팅으로 마이그레이션되었습니다. Gatsby Cloud는 최적화된 빌드, 증분 빌드, Gatsby의 아키텍처와 밀접하게 결합된 미리보기 기능을 제공했기 때문에 이는 상당한 타격이었습니다. Gatsby Cloud 없이는 표준 CI/CD 플랫폼에서의 빌드 시간이 눈에 띄게 더 깁니다.