CMS 마이그레이션 타임라인: WordPress에서 Next.js로 2026년
지난 5년간 약 40건의 CMS 마이그레이션을 주도했고, 받는 질문 중 가장 많은 것이 바로 이것이다: "이게 실제로 얼마나 걸릴까요?" 판매 피치 버전이 아닌, 현실적인 답변 말이다.
핵심은 이것이다 -- 현실적인 답변은 거의 항상 당신이 원하는 것보다 길지만, 최악의 우려보다는 짧다. 작은 마케팅 사이트? 3-6주를 봐야 한다. 블로그, 전자상거래, 맞춤 통합이 있는 중간 규모 사업? 2-4개월을 계획하자. 10,000개 이상의 페이지, 여러 로케일, 레거시 시스템이 있는 엔터프라이즈? 4-8개월을 준비하자.
하지만 이런 범위는 맥락 없이는 의미가 없다. 각 단계에서 정확히 무엇이 일어나는지, 팀이 어디서 시간을 잃는지, 그리고 마이그레이션을 1년에 걸쳐 질질 끌어지는 공포 이야기 중 하나가 되는 것을 어떻게 막을지 분석해보자.
목차
- 2026년 WordPress에서 Next.js로 마이그레이션해야 하는 이유?
- 사이트 규모별 마이그레이션 타임라인 개요
- 단계 1: 발견 및 감사
- 단계 2: 아키텍처 및 계획
- 단계 3: 콘텐츠 모델링 및 CMS 설정
- 단계 4: 프론트엔드 빌드
- 단계 5: 콘텐츠 마이그레이션
- 단계 6: QA 및 테스트
- 단계 7: 론칭 및 론칭 후
- 일반적인 지연 및 회피 방법
- 2026년 비용 예상
- FAQ
2026년 WordPress에서 Next.js로 마이그레이션해야 하는 이유?
솔직하게 말하자면: 모든 WordPress 사이트가 마이그레이션할 필요는 없다. 개인 블로그나 잘 작동하고 있는 소규모 사업 사이트를 운영하고 있다면 WordPress는 여전히 충분히 능력 있다. 하지만 팀들이 2026년에 headless CMS를 사용하는 Next.js로 이동하는 현실적이고 측정 가능한 이유들이 있다:
- 성능: 정적 생성 및 엣지 렌더링을 사용하는 Next.js 사이트는 Core Web Vitals에서 일관되게 90점 이상을 얻는다. WordPress 사이트는 상당한 최적화 작업 없이 평균 50-65점이다.
- 보안: 프론트엔드를 CMS와 분리하면 가장 일반적인 WordPress 공격 벡터를 제거한다. 2025년 Sucuri 보고서에 따르면 WordPress는 감염된 CMS 사이트의 96.2%를 차지했다.
- 개발자 경험: React 기반 컴포넌트 아키텍처는 더 빠른 반복과 더 쉬운 채용을 의미한다. WordPress PHP 인재풀이 줄어들고 있다 -- Stack Overflow의 2025년 조사에서 PHP는 언어 인기도 14위로 떨어졌다.
- 확장성: Vercel이나 Cloudflare에 배포된 엣지 Next.js 사이트는 "더 많은 서버를 추가하자" 방식 없이 트래픽 급증을 처리한다.
성능 문제, 보안 우려, 또는 WordPress 코드베이스를 건드리기를 싫어하는 개발 팀을 다루고 있다면 마이그레이션이 좋은 선택이다. 기술적 접근 방식에 대한 자세한 내용은 우리의 Next.js 개발 역량 페이지에서 다룬다.
사이트 규모별 마이그레이션 타임라인 개요
솔직한 분석은 다음과 같다. 이 타임라인은 전담 팀(다른 프로젝트와 시간을 분할하지 않음)과 합리적으로 반응적인 이해관계자를 가정한다.
| 사이트 규모 | 페이지 | 일반적인 복잡도 | 타임라인 | 팀 규모 |
|---|---|---|---|---|
| 소규모 (마케팅/브로셔) | 5-50 | 낮음 -- 적은 통합, 표준 콘텐츠 | 3-6주 | 2-3명 |
| 중간 규모 (사업) | 50-500 | 중간 -- 블로그, 양식, 일부 통합, 여러 템플릿 | 8-16주 | 3-5명 |
| 대규모 (중견기업) | 500-5,000 | 높음 -- 전자상거래, 다중 작성자, 복잡한 워크플로우 | 3-5개월 | 4-7명 |
| 엔터프라이즈 | 5,000+ | 매우 높음 -- 여러 로케일, 레거시 통합, 규정 준수 | 4-8개월 | 6-12명 |
이는 빌드 타임라인이지, 캘린더 타임라인이 아니다. 캘린더 시간은 항상 더 길다. 이해관계자 검토, 피드백 루프, 그리고 마케팅 VP가 디자인 승인 단계 동안 휴가를 가는 불가피한 2주가 있기 때문이다.
단계 1: 발견 및 감사
기간: 1-3주
대부분의 에이전시가 서두르고 대부분의 마이그레이션이 옆길로 가는 곳이 바로 여기다. 발견은 단순히 "WordPress 사이트를 보고 목록을 만드는 것"이 아니다. 이는 법의학적 작업이다.
실제로 일어나는 것
- 콘텐츠 인벤토리: 모든 콘텐츠 유형, 분류, 맞춤 필드, 미디어 자산을 카탈로그한다. Screaming Frog를 사용하여 기존 사이트를 크롤링하고 전체 URL 맵을 내보낸다. 2,000페이지 사이트의 경우 이것만 제대로 정리하는 데 전체 하루가 걸린다.
- 플러그인 감사: 활성화된 모든 플러그인과 각각이 하는 일을 문서화한다. 평균 WordPress 사이트에는 20-30개의 플러그인이 있다. 각각은 기능을 복제하거나, SaaS 도구로 대체하거나, 의도적으로 제거해야 하는 것을 나타낸다.
- 통합 매핑: 양식은 HubSpot으로? WooCommerce를 통한 결제 처리? Google Tag Manager를 통한 분석(맞춤 이벤트 포함)? 전체 그림을 그린다.
- SEO 기준선: 모든 메타 제목, 설명, 정규 URL, 구조화된 데이터, 내부 링크 패턴을 내보낸다. 마이그레이션 중에 SEO 가치를 잃을 여유가 없다.
- 이해관계자 인터뷰: 실제로 CMS를 매일 사용하는 사람들과 대화한다. 콘텐츠 편집자, 마케팅담당자, 블로그를 관리하는 누구든. 그들의 워크플로우는 기술 아키텍처보다 더 중요하다.
발견 산출물
- 콘텐츠 모델 문서
- 통합 종속성 맵
- SEO 마이그레이션 계획
- 위험 등록부(타임라인을 망칠 수 있는 것들)
- 예비 아키텍처 권장사항
발견을 건너뛰거나 성급하게 진행하는 것은 타임라인 초과의 #1 원인이다. "빠른 6주 마이그레이션"이 5개월 악몽이 된 사례를 봤다. WordPress 사이트에 조건부 논리를 갖춘 47개의 맞춤 Gravity Forms가 있었고, 3개의 서로 다른 CRM으로 데이터를 전송하고 있었기 때문이다.
단계 2: 아키텍처 및 계획
기간: 1-2주
발견 데이터를 손에 쥐었으면 큰 결정을 내린다.
Headless CMS 선택
Next.js는 당신의 프론트엔드 프레임워크이지만, 여전히 콘텐츠 관리 백엔드가 필요하다. 2026년의 최고 선택지:
| CMS | 최적의 사용 | 가격 (2026) | 학습 곡선 |
|---|---|---|---|
| Sanity | 복잡한 콘텐츠 모델, 실시간 협업 | 무료 티어, 그 다음 $99-$949/월 | 중간 |
| Contentful | 엔터프라이즈 팀, 강한 거버넌스 | $300/월 이상 | 중간 |
| Storyblok | 시각 편집, 마케팅 팀 | 무료 티어, 그 다음 €106-€399/월 | 낮음 |
| Payload CMS | 개발자 중심, 자가 호스팅 제어 | 무료 (오픈소스), 클라우드 $50/월부터 | 높음 |
| WordPress (Headless) | WordPress 관리자를 유지하길 원하는 팀 | 기존 호스팅 비용 | 낮음 (친숙함) |
네, WPGraphQL이나 REST API를 사용하여 WordPress를 headless CMS로 사용할 수 있다. 일부 팀은 콘텐츠 편집자가 친숙한 환경에 있으면서 프론트엔드에서 Next.js를 얻기 위해 이것을 한다. 유효한 접근 방식이지만 일부 WordPress 유지 관리 오버헤드를 상속받는다.
우리는 headless CMS 개발 작업의 일부로 팀이 이러한 옵션을 평가하도록 돕는다. 올바른 선택은 편집 팀의 기술 편안함에 크게 의존한다.
아키텍처 결정
- 렌더링 전략: 정적 사이트 생성 (SSG), 증분 정적 재생성 (ISR), 또는 서버 측 렌더링 (SSR)? 대부분의 2026년 사이트는 하이브리드를 사용한다 -- 콘텐츠 페이지에 ISR, 개인화되거나 실시간 페이지에 SSR.
- 호스팅: Vercel은 Next.js의 기본값이지만 Netlify, Cloudflare Pages, AWS Amplify도 모두 실행 가능하다. Vercel의 Pro 요금제는 월 $20/사용자이며 대부분의 팀을 커버한다.
- API 아키텍처: CMS의 네이티브 API를 사용할 것인가, 미들웨어 계층을 구축할 것인가, 아니면 타입 안전 API 호출을 위해 tRPC 같은 것을 사용할 것인가?
- 인증: 게이트된 콘텐츠나 회원 영역이 있다면 일찍부터 계획하자. NextAuth.js (지금은 Auth.js v5)가 대부분의 패턴을 처리한다.
단계 3: 콘텐츠 모델링 및 CMS 설정
기간: 1-3주
이것은 당신이 새로운 CMS에서 콘텐츠 구조를 구축하는 곳이다. 단순히 WordPress 구조를 복제하지 말자 -- 이것은 몇 년의 축적된 콘텐츠 부채를 수정할 기회다.
콘텐츠 모델 설계
WordPress는 평평한 콘텐츠 모델을 권장하는 경향이 있다: 게시물, 페이지, 그리고 ACF나 Meta Box를 통한 맞춤 필드의 난장판. Headless CMS를 사용하면 구조화된 콘텐츠에 대해 생각할 수 있다.
// Sanity의 블로그 게시물 콘텐츠 모델 예시
export default defineType({
name: 'blogPost',
title: 'Blog Post',
type: 'document',
fields: [
defineField({
name: 'title',
type: 'string',
validation: (Rule) => Rule.required().max(70),
}),
defineField({
name: 'slug',
type: 'slug',
options: { source: 'title' },
}),
defineField({
name: 'author',
type: 'reference',
to: [{ type: 'author' }],
}),
defineField({
name: 'body',
type: 'portableText', // 풍부한 구조화된 콘텐츠
}),
defineField({
name: 'seo',
type: 'seoFields', // 재사용 가능한 SEO 객체
}),
],
})
구조화된 콘텐츠는 블로그 게시물 본문이 단순한 HTML 덩어리가 아니라는 것을 의미한다. 웹, 모바일 앱, 이메일 뉴스레터, 뭐든 당신의 프론트엔드가 원하는 대로 렌더링할 수 있는 구조화된 블록이다.
CMS 구성
- 역할 및 권한 설정
- 미리보기 기능 구성 (Next.js의 라이브 미리보기는 편집자 채택에 필수적)
- 맞춤 입력 컴포넌트나 검증 규칙 구축
- 콘텐츠 변경 시 재빌드를 트리거하기 위한 웹훅 설정
단계 4: 프론트엔드 빌드
기간: 2-8주 (가장 큰 변수)
대부분의 캘린더 시간이 여기에 간다. Next.js 프론트엔드 빌드에는 다음이 포함된다:
설계 및 컴포넌트 시스템
마이그레이션 중에 재설계하고 있다면 (우리 클라이언트의 약 70%가 한다), 2-4주를 추가한다. 기존 설계를 복제하고 있다면 더 빠르게 이동할 수 있다.
// 컴포넌트 중심 아키텍처 예시
export default function BlogPost({ post }: { post: BlogPostType }) {
return (
<article>
<PageHeader title={post.title} date={post.publishedAt} />
<AuthorCard author={post.author} />
<PortableText
value={post.body}
components={customComponents}
/>
<RelatedPosts posts={post.related} />
<NewsletterSignup />
</article>
)
}
먼저 컴포넌트 라이브러리를 구축한 다음 페이지를 조립할 것을 강력히 권장한다. 처음에는 느려 보이지만 당신이 15번째 페이지 템플릿을 구축할 때 큰 대가를 치른다.
주요 빌드 작업
- 모든 콘텐츠 유형에 대한 페이지 템플릿
- 동적 라우팅 및 catch-all 라우트
- 네비게이션 (적용 가능한 경우 메가 메뉴 포함)
- 검색 기능 (Algolia, Meilisearch, 또는 Next.js 내장)
- 양식 구현 (Gravity Forms, Contact Form 7 등 대체)
- 제3자 통합 (분석, 채팅 위젯, CRM 연결)
- 이미지 최적화 (CMS의 이미지 CDN과 함께 Next.js Image 컴포넌트)
- 사이트맵 생성
- RSS 피드
- 301 리디렉션 매핑
리디렉션 매핑만 해도 큰 사이트에서 며칠이 걸릴 수 있다. 변경되는 모든 URL에는 리디렉션이 필요하거나 SEO 자산을 버리고 있는 것이다.
단계 5: 콘텐츠 마이그레이션
기간: 1-4주
콘텐츠 마이그레이션은 사소하게 간단하거나 악몽 같이 복잡하다. 중간 지점이 없다.
자동화된 마이그레이션
구조화된 콘텐츠 (블로그 게시물, 제품, 팀 멤버)의 경우 마이그레이션 스크립트를 작성하자:
// 단순화된 WordPress에서 Sanity로의 마이그레이션 스크립트
import { createClient } from '@sanity/client'
import { wpClient } from './wordpress-api'
const sanity = createClient({
projectId: 'your-project',
dataset: 'production',
token: process.env.SANITY_WRITE_TOKEN,
apiVersion: '2026-01-01',
})
async function migratePosts() {
const wpPosts = await wpClient.posts().perPage(100).get()
for (const post of wpPosts) {
await sanity.create({
_type: 'blogPost',
title: post.title.rendered,
slug: { current: post.slug },
// WordPress HTML을 Portable Text로 변환
body: htmlToPortableText(post.content.rendered),
publishedAt: post.date,
})
}
}
htmlToPortableText 단계가 상황을 복잡하게 만드는 곳이다. WordPress 콘텐츠는 shortcodes, 인라인 스타일, 비활성화된 플러그인의 플러그인 특정 마크업으로 가득 차 있으며, 구조화된 콘텐츠에 깔끔하게 매핑되지 않는다. 정리 시간을 예산으로 책정하자.
수동 콘텐츠 작업
일부 콘텐츠는 단순히 인간의 주의가 필요하다:
- Elementor, Divi, 또는 WPBakery로 구축된 복잡한 레이아웃의 페이지
- 비활성화된 플러그인의 embedded shortcodes를 포함한 콘텐츠
- 재최적화 또는 alt 텍스트가 필요한 미디어
- 업데이트가 필요한 내부 링크
500페이지 사이트의 경우 40-80시간의 수동 콘텐츠 작업을 계획하자. 정말로.
단계 6: QA 및 테스트
기간: 1-3주
이것을 단축하지 말자. 사후 대응이라는 이유로 QA를 다루고 론칭이 몇 달 지연된 경우를 봤다.
QA 체크리스트
- 기능 테스트: 모든 양식, 모든 상호작용 요소, 모든 동적 기능
- 교차 브라우저 테스트: Chrome, Firefox, Safari, Edge. Safari는 항상 이상한 것을 가지고 있다.
- 모바일 테스트: Chrome DevTools가 아닌 실제 기기. 실제 iPhone과 Android 기기에서 테스트하자.
- 콘텐츠 검증: 마이그레이션된 콘텐츠 중 최소 20%에 대해 형식 문제를 찾자.
- SEO 감사: 이전 메타 태그와 새로운 메타 태그를 비교하자. 구조화된 데이터를 검증하자. 모든 리디렉션을 테스트하자.
- 성능 테스트: Lighthouse 점수, 필드의 Core Web Vitals, k6과 같은 도구를 사용한 부하 테스트
- 접근성: WCAG 2.2 AA 준수. axe-core를 실행하되, 키보드 전용 네비게이션 테스트도 하자.
- 분석 검증: 추적이 모든 이벤트에서 올바르게 실행되는지 확인하자.
리디렉션 테스트
이것은 자체 콜아웃이 필요하다. 이전 사이트에서 모든 URL을 내보내자. 각각을 새 URL에 매핑하자. 모든 리디렉션을 테스트하자. 수천 개의 URL을 가진 엔터프라이즈 사이트의 경우 자동화된 테스트를 사용하자:
# curl을 사용하여 리디렉션 테스트
while IFS=, read -r old_url new_url; do
status=$(curl -o /dev/null -s -w "%{http_code}" -L "$old_url")
final=$(curl -o /dev/null -s -w "%{url_effective}" -L "$old_url")
echo "$old_url -> $final (Status: $status)"
done < redirects.csv
단계 7: 론칭 및 론칭 후
기간: 1-2주
론칭일
나는 화요일이나 수요일 아침에 론칭하는 것을 선호한다. 절대 금요일이 아니다 (주말에 디버깅하고 싶지 않다)이고 절대 월요일도 아니다 (사람들은 여전히 주말에서 따라가고 있다).
론칭 체크리스트:
- DNS 변경 (TTL은 48시간 전에 낮추어야 함)
- SSL 인증서 검증
- CDN 캐시 워밍
- 처음 4시간 동안 오류율 모니터링
- Google Search Console에서 크롤 오류 검증
- 모든 제3자 통합이 실행되는지 확인
론칭 후 (2주)
- Google Search Console에서 Core Web Vitals 모니터링
- 404 오류를 찾고 누락된 리디렉션 추가
- 첫 달 동안 매일 유기 검색 성능 추적
- 새로운 CMS에 대한 콘텐츠 편집자의 피드백 수집
- QA를 통과한 모든 엣지 케이스 해결
주요 마이그레이션 후 유기 검색에서 5-15%의 일시적 트래픽 하락은 정상이다. 리디렉션과 SEO가 제대로 처리되면 2-4주 이내에 복구되어야 한다. 복구되지 않으면 리디렉션 매핑이나 콘텐츠 패리티에 뭔가 잘못되었다.
일반적인 지연 및 회피 방법
수십 번의 마이그레이션 후 타임라인 킬러들은 다음과 같다:
빌드 중 범위 변경: "우리가 이미 하고 있으니까, 고객 포털도 추가할 수 있을까요?" 네, 그렇지만 이것은 별도의 프로젝트다. 범위 변경은 평균 3-6주를 마이그레이션에 추가한다.
이해관계자 가용성: 누군가의 받은편지함에 앉아 있는 디자인 검토 2주. 캘린더 시간을 적절히 예산으로 책정하고 피드백 라운드에 대한 명확한 SLA를 설정하자.
플러그인 기능 격차: 중요한 뭔가를 하고 있는데 아무도 문서화하지 않은 이상한 WordPress 플러그인. 발견이 이것을 잡아야 하지만 때때로 것들이 빌드 중에 나타난다.
콘텐츠 편집자 교육: 새로운 CMS를 사용할 수 없으면 마이그레이션을 완료하지 못한 것이다. 교육과 문서에 1-2일을 예산으로 책정하자.
콘텐츠 마이그레이션에 대한 완벽주의: 일부 콘텐츠는 마이그레이션할 가치가 없다. 2014년의 블로그 게시물 트래픽 없음? 가자. 블로그 인덱스에 대한 리디렉션을 설정하고 이동하자.
2026년 비용 예상
현실적인 숫자를 주겠다. 2026년 이 작업에 대한 에이전시 요금:
| 사이트 규모 | 타임라인 | 예상 비용 (에이전시) | 예상 비용 (프리랜서) |
|---|---|---|---|
| 소규모 | 3-6주 | $15,000-$35,000 | $8,000-$18,000 |
| 중간 규모 | 8-16주 | $40,000-$90,000 | $25,000-$55,000 |
| 대규모 | 3-5개월 | $80,000-$200,000 | $50,000-$120,000 |
| 엔터프라이즈 | 4-8개월 | $150,000-$500,000+ | 드물게 적절 |
이러한 범위는 우리가 시장 전반에서 본 것을 반영한다. 분산이 크다. "중간 규모 사이트"는 와일드하게 다른 것을 의미할 수 있다. 간단한 블로그와 연락처 양식을 가진 200페이지 사이트는 다국어 콘텐츠, 전자상거래, 회원 포털이 있는 200페이지 사이트와 매우 다르다.
당신의 특정 상황을 논의하고 싶다면 우리 가격 페이지에서 우리의 계약 모델을 설명하고 있으며, 직접 연락하여 범위 추정을 받을 수 있다.
FAQ
간단한 WordPress에서 Next.js로의 마이그레이션은 얼마나 걸리나요?
작은 마케팅 사이트 (50페이지 미만)는 표준 콘텐츠 유형과 최소한의 통합으로 킥오프에서 론칭까지 일반적으로 3-6주가 걸린다. 이는 주요 설계 변경 없이 2-3명 개발자의 팀을 가정한다. 재설계도 하고 있다면 설계 단계에 2-3주를 추가하자.
WordPress에서 Next.js로 마이그레이션하면서 SEO 순위를 잃지 않을 수 있나요?
절대적으로, 그러나 신중한 계획이 필요하다. 중요한 요소들은: 가능한 URL 구조 유지, URL이 변경되는 모든 것에 대한 301 리디렉션 구현, 모든 메타 태그 및 구조화된 데이터 보존, 새 사이트와 이전 사이트의 콘텐츠 패리티 보장이다. 유기 검색에서 5-15% 임시 하락은 정상이며 2-4주 이내에 복구되어야 한다. 가장 큰 위험 요인은 리디렉션 누락이다 -- 하나의 실패한 리디렉션 매핑은 사이트의 섹션 트래픽을 탱크시킬 수 있다.
WordPress를 Next.js와 함께 headless CMS로 사용해야 하나요 아니면 완전히 다른 CMS로 전환해야 하나요?
팀에 의존한다. 콘텐츠 편집자가 WordPress에 깊숙이 익숙하고 변경에 저항한다면, WPGraphQL을 사용하는 headless WordPress는 합리적인 중간 지점이다. 친숙한 관리자 인터페이스를 유지하면서 Next.js 프론트엔드 이점을 얻는다. 그러나 여전히 WordPress 유지 관리 부담을 가진다 (업데이트, 보안 패치, 호스팅). 변경에 개방적이라면, Sanity, Contentful, Storyblok과 같은 목적 구축 headless CMS는 더 나은 구조화된 콘텐츠, 실시간 협업, 더 적은 운영 오버헤드를 제공한다.
CMS 마이그레이션 중 가장 큰 위험은 무엇인가요?
상위 3개는: SEO 리그레션이 나쁜 리디렉션 매핑에서 (수정 가능하지만 손실된 트래픽에서 비용이 든다), 부정적한 발견에서 타임라인 초과 (보통 숨겨진 복잡성이 빌드 중에 나타난다), 그리고 편집자 채택 실패 (팀이 새로운 CMS를 사용하기를 거부한다 그들의 워크플로우로 구축되지 않았거나 너무 다르기 때문에). 세 가지 모두 적절한 계획으로 예방 가능하다.
2026년 WordPress에서 Next.js로 마이그레이션하는 데 비용이 얼마나 드나요?
에이전시 비용은 작은 브로셔 사이트 $15,000에서 복잡한 통합이 있는 대규모 엔터프라이즈 마이그레이션 $500,000+까지 이른다. 중간 규모 사업 사이트의 중앙값은 대략 $50,000-$90,000이다 전문 에이전시에서. 프리랜서 요금은 일반적으로 40-60% 낮지만 가용성 및 프로젝트 관리 주변 더 높은 위험과 함께 온다. 비용은 주로 고유 템플릿 수, 통합 복잡도, 수동 주의가 필요한 콘텐츠 량에 의해 주도된다.
한 번에 모든 콘텐츠를 마이그레이션해야 하나요?
아니다, 사실 단계적 마이그레이션이 종종 위험을 줄인다. 일부 팀은 블로그를 WordPress에서 유지하면서 마케팅 페이지를 Next.js로 이동하기 시작한 다음 두 번째 단계에서 블로그를 마이그레이션한다. 역방향 프록시 규칙을 사용하여 동일한 도메인 아래에서 다양한 소스에서 다양한 섹션을 제공할 수 있다. 이 접근 방식은 일부 아키텍처 복잡성을 추가하지만 더 빠르게 론칭하고 모든 것에 들어가기 전에 접근 방식을 검증하도록 한다.
변경 대신 Astro를 사용할 수 있나요?
네, 최소한의 상호작용을 가진 콘텐츠 중심 사이트의 경우 Astro는 탁월한 선택이 될 수 있다. Astro는 기본적으로 JavaScript를 배송하지 않고 부분 수화 ("islands architecture")를 지원하며, 콘텐츠 페이지가 엄청나게 빠르게 로드된다는 것을 의미한다. Next.js는 대규모 클라이언트 측 상호작용, 인증, 또는 실시간 기능이 필요할 때 더 좋다. 우리는 두 프레임워크에 마이그레이션을 수행했으며 올바른 선택은 완전히 사이트의 요구사항에 의존한다.