WordPress 대시보드가 열리고 업데이트 아이콘이 다시 빨간색으로 켜집니다. 클릭합니다. 3개 플러그인이 충돌합니다. 연락처 양식이 작동을 멈춥니다. 클라이언트가 밤 11시에 사이트가 느리다고 이메일을 보내고, 이미 알고 있습니다. 인터랙티브까지 6초, 모바일이면 7초일 수도 있습니다. 보안 공지가 다음 아침에 도착합니다. CVE-2022-뭔가입니다. 플러그인 작성자는 2년 전에 사라졌습니다. 할 수 있는 부분은 패치하고, 할 수 없는 부분은 미룹니다. 다음 번 업데이트는 이미 2주 뒤이고, 같은 트레이드오프를 또 마주합니다. 안정성 또는 기능, 절대 둘 다는 아닙니다. 더 나은 스택이 대기하고 있습니다. 선택하도록 강요하지 않는 스택입니다.

여기서 중요한 점은 WordPress가 웹의 40% 이상을 구동하고 있으며, 그럴 만한 이유가 있다는 것입니다. 접근하기 쉽고, 거대한 생태계가 있으며, 많은 비즈니스를 빠르게 온라인에 올렸습니다. 하지만 당신을 시작하게 하는 도구와 함께 성장하는 도구 사이에는 차이가 있습니다. 이것을 읽고 있다면, 아마도 그 벽에 부딪혔을 것입니다. WordPress에서 헤드리스 Next.js + Supabase 아키텍처로의 실제 마이그레이션이 어떤 모습인지 안내하겠습니다. 마케팅 버전이 아니라 실제 엔지니어링 플레이북입니다.

목차

WordPress를 벗어났나요? Next.js + Supabase를 위한 마이그레이션 플레이북

WordPress를 정말 벗어났다는 신호

모두가 WordPress를 떠날 필요는 없습니다. 솔직히 말씀드리겠습니다. 개인 블로그나 지역 비즈니스의 브로셔 사이트를 운영하고 있다면, 괜찮은 테마와 소수의 플러그인이 있는 WordPress가 여전히 올바른 선택일 가능성이 높습니다. 하지만 WordPress를 벗어났음을 나타내는 명확한 신호들이 있습니다.

플러그인 충돌이 매달 기능을 깨뜨립니다

WooCommerce를 업데이트하면 페이지 빌더가 깨집니다. 페이지 빌더를 업데이트하면 SEO 플러그인이 경고를 던집니다. PHP를 8.2로 업데이트하면 (호스팅 제공자가 요구하기 때문에) 3개 플러그인이 완전히 작동을 멈춥니다. 이것은 버그가 아닙니다. 아키텍처입니다. WordPress 플러그인은 모두 동일한 전역 범위, 동일한 훅, 동일한 데이터베이스를 공유합니다. 모든 플러그인은 다른 모든 플러그인과 잠재적 충돌입니다.

30개, 40개, 심지어 60개 이상의 활성 플러그인을 실행하는 WordPress 사이트를 감사했습니다. 그 시점에서 당신은 웹사이트를 유지하지 않습니다. 젠가 타워를 유지합니다.

성능이 풀타임 일이 되었습니다

PageSpeed 점수가 30점대입니다. 캐싱 플러그인, 이미지 최적화 플러그인, 축소 플러그인, CDN 플러그인을 설치했습니다. 모두 다른 25개 플러그인으로 인해 발생한 성능 문제를 해결하기 위해. 아이러니하지 않나요.

WordPress는 매 요청마다 페이지를 동적으로 생성합니다 (캐시되지 않는 한). 각 플러그인은 자체 CSS 및 JavaScript 파일을 주입할 수 있습니다. 인기 있는 플러그인이 있는 일반적인 WordPress 페이지는 15-30개의 별도의 렌더링 차단 리소스를 로드합니다. Google의 Core Web Vitals 데이터에 따르면 WordPress 사이트의 세 가지 CWV 메트릭 모두에서 33% 통과율을 보이는 반면, 최신 JavaScript 프레임워크로 구축된 사이트는 52%입니다.

보안 취약점이 당신을 잠 못 들게 합니다

WPScan의 취약점 데이터베이스는 수천 개의 WordPress 취약점을 추적했습니다. 대다수는 플러그인과 테마입니다. 사용자 데이터, 결제 또는 어떤 종류의 민감한 정보를 처리하는 사이트를 운영하는 경우, 각 플러그인은 공격 표면입니다. Patchstack은 WordPress 보안 취약점의 97%이 플러그인에서 발생한다고 보고했습니다.

본질적으로 수십 명의 독립적인 개발자 (많은 경우 플러그인을 부업으로 유지하는 경우)에게 보안 태세를 신뢰하는 것입니다.

개발팀이 이것을 싫어합니다

이것은 과소평가됩니다. 좋은 개발자는 더 이상 WordPress에서 일하고 싶어하지 않습니다. PHP-템플릿-스파게티-ACF-필드 워크플로우는 현대적인 컴포넌트 기반 개발과 비교할 때 고통스럽습니다. 엔지니어링 인재를 유치하고 유지하려는 경우, 기술 스택이 중요합니다.

WordPress 세금: 플러그인 지옥의 실제 비용

이것에 숫자를 붙여보겠습니다. 중간 규모의 WordPress 사이트 (전자상거래 사이트 또는 블로그, 사용자 계정, 사용자 정의 기능이 있는 SaaS 마케팅 사이트)의 경우, "WordPress 세금"은 일반적으로 다음과 같습니다:

비용 항목 연간 추정치
프리미엄 플러그인 라이선스 (15-20개 플러그인) $1,500 - $4,000
관리형 WordPress 호스팅 (WP Engine, Kinsta) $1,200 - $6,000
보안 모니터링 + 정리 (Sucuri, Wordfence) $300 - $500
성능 최적화 시간 (개발자 시간) $3,000 - $8,000
플러그인 충돌 디버깅 (개발자 시간) $2,000 - $6,000
업데이트로 인한 긴급 수정 $1,000 - $4,000
총 연간 WordPress 세금 $9,000 - $28,500

이것은 단일 새 기능을 구축하기 전입니다. 불을 켜두는 비용일 뿐입니다.

Next.js + Supabase가 의미 있는 스택인 이유

헤드리스로 가는 방법은 12가지가 있습니다. Gatsby를 사용할 수 있습니다 (Netlify가 인수한 이후 본질적으로 유지 모드입니다). Remix, Astro, 또는 SvelteKit을 사용할 수 있습니다. 백엔드의 경우 Firebase, PlanetScale, 또는 사용자 정의 API를 사용할 수 있습니다.

그러나 2026년에 WordPress에서 마이그레이션하는 팀의 경우, Next.js + Supabase는 이기기 어려운 달콤한 지점을 치고 있습니다. 이유는 다음과 같습니다.

Next.js: 모든 작업을 수행하는 프론트엔드

Next.js 15 (2024년 10월 이후 안정화)는 기본적으로 서버 컴포넌트를 제공합니다. 이는 정적 사이트의 성능을 동적 사이트의 유연성과 결합할 수 있음을 의미합니다. 블로그 포스트를 빌드 시간에 정적으로 생성하고, 동적 페이지를 서버 렌더링하고, 같은 앱에서 인터랙티브 컴포넌트를 클라이언트 렌더링할 수 있습니다.

WordPress에서 온 팀의 경우, 주요 이점은 다음과 같습니다:

  • 내장 이미지 최적화 -- 2-3개의 WordPress 플러그인 대체
  • 자동 코드 분할 -- 각 페이지는 필요한 JS만 로드합니다
  • 엣지 미들웨어 -- CDN 수준에서 리다이렉트, 인증, A/B 테스트 처리
  • 증분 정적 재생성 (ISR) -- 전체 배포 없이 개별 페이지 재구축
  • React Server Components가 있는 App Router -- 클라이언트 측 JavaScript를 획기적으로 감소

Social Animal에서는 많은 Next.js 프로젝트를 구축하며 (Next.js 개발 능력 확인), WordPress 대비 성능 차이는 일관되게 극적입니다.

Supabase: WordPress가 원했던 백엔드

Supabase는 PostgreSQL 위에 구축된 오픈 소스 Firebase 대안입니다. 다음을 제공합니다:

  • 스키마에서 자동으로 생성되는 REST 및 GraphQL API를 갖춘 완전한 Postgres 데이터베이스
  • 내장 인증 (이메일, OAuth, 매직 링크, SSO)
  • 세분화된 액세스 제어를 위한 행 수준 보안 정책
  • WebSockets을 통한 실시간 구독
  • 서버리스 백엔드 로직을 위한 엣지 함수
  • CDN 전달과 함께 파일 업로드를 위한 스토리지

WordPress 마이그레이션에 특히 Supabase가 뛰어난 이유는 WordPress가 MySQL을 사용하고, 데이터 모델이 PostgreSQL에 놀랍도록 잘 매핑되기 때문입니다. 사용자 정의 포스트 타입은 테이블이 됩니다. Post meta는 JSONB 컬럼이 됩니다. 사용자 데이터는 거의 1:1로 매핑됩니다.

Supabase의 무료 계층에는 500MB 데이터베이스, 1GB 스토리지, 인증 시 50,000명의 월간 활성 사용자가 포함됩니다. Pro 플랜은 월 $25로 대부분의 프로덕션 사이트를 다룹니다. 관리형 WordPress 호스팅만 해도 월 $30-$100를 지불하는 것과 비교하세요.

WordPress를 벗어났나요? Next.js + Supabase 마이그레이션 플레이북 - 아키텍처

마이그레이션 플레이북: 단계별

다음은 수십 개의 WordPress 마이그레이션을 통해 다듬은 접근 방식입니다. 주말 프로젝트가 아닙니다. 사이트 복잡도에 따라 4-12주를 예산하세요. 하지만 단계를 따르면 예측 가능하고 위험이 낮습니다.

1단계: 감사 및 아키텍처 (1주차)

단일 코드 라인을 작성하기 전에:

  1. 전체 플러그인 목록 내보내기 - wp plugin list --status=active (WP-CLI)
  2. 모든 플러그인을 새 스택의 대체 기능에 매핑하기
  3. 전체 URL 구조 내보내기 - 모든 포스트, 페이지, 분류법, 사용자 정의 포스트 타입 포함
  4. 모든 양식, 통합, 타사 연결 문서화하기
  5. 테마의 functions.php에 있는 사용자 정의 기능 식별하기

플러그인 매핑 연습은 중요합니다. 일반적인 대체 기능 예시입니다:

WordPress 플러그인 헤드리스 대체
Yoast SEO Next.js 내장 메타데이터 API + generateMetadata()
WP Super Cache / W3 Total Cache 필요 없음 (기본적으로 정적)
Wordfence / Sucuri Supabase RLS + Vercel의 내장 DDoS 보호
Contact Form 7 / Gravity Forms React Hook Form + Supabase Edge Function
WooCommerce Saleor, Medusa.js, 또는 Shopify Storefront API
ACF / 사용자 정의 필드 타입화된 스키마가 있는 Supabase 테이블
WP Migrate DB 일회성 Supabase 마이그레이션 스크립트
Smush / ShortPixel Next.js Image 컴포넌트 (내장)
Elementor / WPBakery React 컴포넌트 (그리울 일이 없습니다)

2단계: 새 스택 설정 (2주차)

# Next.js 프로젝트 생성
npx create-next-app@latest my-site --typescript --tailwind --app --src-dir

# Supabase 설치
npm install @supabase/supabase-js @supabase/ssr

# 환경 변수 설정
cp .env.example .env.local

당신의 .env.local:

NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key
SUPABASE_SERVICE_ROLE_KEY=your-service-role-key

Vercel에 즉시 배포하세요. 네, 의미 있는 것을 구축하기 전에. 처음부터 라이브 미리보기 URL을 사용하면 작업 방식이 바뀝니다. 이해 관계자들이 진행 상황을 볼 수 있고, 배포 문제를 조기에 포착합니다.

데이터 마이그레이션: WordPress에서 콘텐츠 빼내기

대부분의 마이그레이션 가이드가 흐릿해지는 바로 이 부분입니다. 구체적으로 말씀드리겠습니다.

1단계: WordPress 데이터 내보내기

내장된 WordPress XML 내보내기를 사용하지 마세요. 불완전하고 구조가 좋지 않습니다. 대신 WP-CLI와 직접 데이터베이스 쿼리를 사용하세요:

# 포스트를 JSON으로 내보내기
wp post list --post_type=post --format=json --fields=ID,post_title,post_content,post_excerpt,post_date,post_status,post_name > posts.json

# 페이지 내보내기
wp post list --post_type=page --format=json --fields=ID,post_title,post_content,post_excerpt,post_date,post_status,post_name > pages.json

# 사용자 정의 포스트 타입 내보내기
wp post list --post_type=your_cpt --format=json > cpt.json

# Post meta 내보내기 (ACF 필드 등)
wp eval 'global $wpdb; $results = $wpdb->get_results("SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key NOT LIKE \"_%\""); echo json_encode($results);' > postmeta.json

2단계: 변환 및 Supabase에 로드

마이그레이션 스크립트를 작성하세요. TypeScript를 선호합니다:

import { createClient } from '@supabase/supabase-js'
import posts from './exports/posts.json'

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

async function migratePosts() {
  for (const post of posts) {
    const { error } = await supabase.from('posts').insert({
      wp_id: post.ID,
      title: post.post_title,
      slug: post.post_name,
      content: convertWpContentToMdx(post.post_content),
      excerpt: post.post_excerpt,
      published_at: post.post_date,
      status: post.post_status === 'publish' ? 'published' : 'draft',
    })
    
    if (error) console.error(`Failed to migrate post ${post.ID}:`, error)
  }
}

function convertWpContentToMdx(html: string): string {
  // turndown이나 rehype를 사용하여 WordPress HTML을 MDX로 변환
  // 숏코드, 임베드, Gutenberg 블록 처리
  // 마이그레이션 복잡성의 80%이 여기에 있습니다
}

convertWpContentToMdx 함수는 가장 많은 시간을 소비할 부분입니다. WordPress 콘텐츠는 HTML, 숏코드, Gutenberg 블록 주석, 임베드된 oEmbed URL이 뒤섞여 있습니다. turndown 같은 라이브러리는 기본 HTML-마크다운 변환을 처리하지만, 숏코드와 블록에 사용자 정의 규칙이 필요합니다.

3단계: 미디어 마이그레이션

import { createClient } from '@supabase/supabase-js'
import fetch from 'node-fetch'

async function migrateMedia(mediaItems: any[]) {
  for (const item of mediaItems) {
    const response = await fetch(item.source_url)
    const buffer = await response.buffer()
    
    const { error } = await supabase.storage
      .from('media')
      .upload(`uploads/${item.slug}.${item.mime_type.split('/')[1]}`, buffer, {
        contentType: item.mime_type,
      })
    
    if (error) console.error(`Failed to upload ${item.slug}:`, error)
  }
}

Next.js로 새 프론트엔드 구축

Supabase에 데이터가 있으면, 프론트엔드 구축은 재미있는 부분입니다. Next.js App Router를 사용한 일반적인 블로그 포스트 페이지입니다:

// src/app/blog/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server'
import { notFound } from 'next/navigation'
import { MDXRemote } from 'next-mdx-remote/rsc'

export async function generateMetadata({ params }: { params: { slug: string } }) {
  const supabase = createClient()
  const { data: post } = await supabase
    .from('posts')
    .select('title, excerpt, og_image')
    .eq('slug', params.slug)
    .single()

  if (!post) return {}

  return {
    title: post.title,
    description: post.excerpt,
    openGraph: { images: [post.og_image] },
  }
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const supabase = createClient()
  const { data: post } = await supabase
    .from('posts')
    .select('*')
    .eq('slug', params.slug)
    .eq('status', 'published')
    .single()

  if (!post) notFound()

  return (
    <article className="prose lg:prose-xl mx-auto">
      <h1>{post.title}</h1>
      <time dateTime={post.published_at}>
        {new Date(post.published_at).toLocaleDateString()}
      </time>
      <MDXRemote source={post.content} />
    </article>
  )
}

캐싱 플러그인, 성능 플러그인, SEO 플러그인이 없음을 주목하세요. 메타데이터 API가 SEO를 처리합니다. 서버 컴포넌트가 성능을 처리합니다. CDN이 캐싱을 처리합니다. 모두 내장되어 있습니다.

백엔드로 Supabase 설정

Supabase 스키마는 WordPress의 일반적인 wp_posts / wp_postmeta 구조가 아니라 실제 데이터 요구사항 중심으로 설계되어야 합니다. 더 깔끔한 스키마입니다:

-- 포스트 테이블
create table posts (
  id uuid default gen_random_uuid() primary key,
  title text not null,
  slug text unique not null,
  content text,
  excerpt text,
  featured_image text,
  status text default 'draft' check (status in ('draft', 'published', 'archived')),
  author_id uuid references auth.users(id),
  published_at timestamptz,
  created_at timestamptz default now(),
  updated_at timestamptz default now(),
  metadata jsonb default '{}'
);

-- 카테고리
create table categories (
  id uuid default gen_random_uuid() primary key,
  name text not null,
  slug text unique not null,
  description text
);

-- Row Level Security
alter table posts enable row level security;

create policy "Published posts are viewable by everyone"
  on posts for select
  using (status = 'published');

create policy "Authors can manage their own posts"
  on posts for all
  using (auth.uid() = author_id);

metadata jsonb 컬럼은 탈출 해치입니다. 자체 컬럼을 보장하지 않는 모든 사용자 정의 필드는 여기에 있을 수 있습니다. 인덱싱되고, 쿼리 가능하고, 무한히 유연합니다. ACF 필드 같지만 플러그인 없이.

인증 및 사용자 데이터 처리

WordPress 사이트에 사용자 계정이 있으면, Supabase Auth는 마이그레이션을 깔끔하게 처리합니다. 비밀번호 해시를 마이그레이션할 수 없습니다 (WordPress는 phpass를 사용하고 Supabase는 bcrypt를 사용합니다). 하지만 다음을 할 수 있습니다:

  1. 사용자 이메일과 프로필을 Supabase에 가져오기
  2. 모든 사용자에게 처음 로그인할 때 "비밀번호 재설정" 흐름 트리거
  3. 또는 비밀번호가 필요하지 않도록 매직 링크 인증 사용

Supabase는 이메일/비밀번호, Google, GitHub, Apple, 수십 가지 다른 OAuth 제공자를 상자 안에서 지원합니다. 플러그인이 필요 없습니다.

SEO 보존: 구축한 것을 잃지 마세요

이것은 협상할 수 없습니다. 잘못된 마이그레이션은 몇 년의 SEO 자산을 한 밤에 파괴할 수 있습니다. 체크리스트입니다:

  1. 모든 오래된 URL을 새로운 URL에 매핑합니다. WordPress는 기본적으로 /2024/01/post-title/을 사용합니다. 새 사이트는 /blog/post-title/을 사용할 수 있습니다. 모든 단일 오래된 URL은 301 리다이렉트가 필요합니다.

  2. Next.js에서 리다이렉트를 구현합니다:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // 날짜 기반 WordPress URL을 깔끔한 슬러그로
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // 카테고리 페이지
      {
        source: '/category/:slug',
        destination: '/blog/category/:slug',
        permanent: true,
      },
    ]
  },
}
  1. 모든 메타 제목, 설명, 구조화된 데이터를 보존합니다. 마이그레이션 전에 Yoast에서 내보냅니다.
  2. 출시 직후 새 사이트맵을 Google Search Console에 제출합니다.
  3. 30일 동안 이전 사이트를 서브도메인 (old.yoursite.com)에서 실행된 상태로 유지합니다 (대체로).

성능 벤치마크: 이전과 이후

Social Animal에서 수행한 마이그레이션의 실제 숫자입니다 (이는 마이그레이션 프로젝트 전반에 걸친 평균입니다):

메트릭 WordPress (이전) Next.js + Supabase (이후) 개선
Lighthouse 성능 점수 38 94 +147%
최대 콘텐츠풀 페인트 (LCP) 4.2s 0.9s -79%
첫 입력 지연 (FID) 180ms 12ms -93%
누적 레이아웃 시프트 (CLS) 0.25 0.02 -92%
첫 바이트까지의 시간 (TTFB) 1.8s 0.15s -92%
총 페이지 무게 3.2MB 420KB -87%
HTTP 요청 47 8 -83%

이들은 선택된 것이 아닙니다. 일관적입니다. 30개 이상의 플러그인을 제거하고 각각이 자체 CSS와 JS를 주입하고, 동적 PHP 렌더링을 글로벌 CDN의 정적/서버 렌더링 React 컴포넌트로 대체하면, 결과는 예측 가능합니다.

이러한 종류의 결과가 프로젝트에 어떤 모습인지 궁금하신 경우, 가격 페이지에서 헤드리스 마이그레이션 프로젝트의 일반적 비용을 분석합니다.

비용 비교: WordPress vs 헤드리스 스택

WordPress (연간) Next.js + Supabase (연간)
호스팅 $1,200 - $6,000 (WP Engine/Kinsta) $0 - $240 (Vercel Pro)
데이터베이스/백엔드 호스팅에 포함 $0 - $300 (Supabase Pro)
플러그인 라이선스 $1,500 - $4,000 $0
보안 도구 $300 - $500 $0 (내장)
CDN $0 - $600 $0 (Vercel에 포함)
유지 관리 개발자 시간 $6,000 - $18,000 $1,000 - $4,000
합계 $9,000 - $29,100 $1,000 - $4,540

헤드리스 스택은 연간 70-85% 더 저렴하게 운영됩니다. 마이그레이션 자체는 분명히 선행 비용이 있습니다. 복잡도에 따라 전문적으로 빌드하는 경우 일반적으로 $15,000-$60,000입니다 (헤드리스 CMS 개발 서비스 자세한 정보 참조). 하지만 더 나은 성능과 SEO의 수익 영향을 고려하기 전에도 운영 비용 감소만으로 6-18개월 내에 자신을 갚습니다.

FAQ

마이그레이션 후 콘텐츠를 관리하려면 React/Next.js를 배워야 하나요?

아니오. 대부분의 팀은 Next.js를 Sanity, Contentful, 심지어 WordPress 자체 (순수 헤드리스 CMS로 사용)와 같은 헤드리스 CMS와 쌍으로 사용합니다. 콘텐츠 편집자는 코드를 건드릴 일이 없습니다. 깔끔한 편집 인터페이스를 받고, 프론트엔드는 API를 통해 콘텐츠를 가져옵니다. 팀이 이미 알고 있는 WordPress 편집자를 유지하고 싶다면, 절대적으로 할 수 있습니다. WordPress 프론트엔드를 제거하고 콘텐츠 백엔드로 사용하세요.

일반적인 WordPress에서 Next.js 마이그레이션은 얼마나 오래 걸리나요?

콘텐츠 중심 사이트 (블로그 및 표준 페이지 포함): 4-6주. 전자상거래, 사용자 계정, 사용자 정의 포스트 타입, 복잡한 기능이 있는 사이트: 8-14주. 가장 큰 변수는 콘텐츠 복잡도입니다. 숏코드에 크게 의존하거나 깊게 사용자 정의된 Gutenberg 블록이 있는 사이트는 더 오래 걸립니다.

마이그레이션 중에 Google 순위를 잃나요?

올바르게 리다이렉트를 처리하면 안 됩니다. 301 리다이렉트는 90-99%의 링크 공정성을 보존합니다. 일반적으로 마이그레이션 후 첫 1-2주 동안 약간의 하락이 보입니다 (Google이 다시 크롤링해야 함). 그 후에는 더 나은 Core Web Vitals 점수로 인한 순위 개선이 이어집니다. 핵심은 모든 단일 URL을 매핑하고 리다이렉트 맵이 완성될 때까지 출시하지 않는 것입니다.

높은 트래픽 사이트에 Supabase는 프로덕션 준비가 되어 있나요?

네. Supabase는 AWS 인프라에서 실행되며 수백만 요청을 처리하는 회사에서 프로덕션에 사용되었습니다. 그들의 데이터베이스는 단지 PostgreSQL입니다. 아마도 가장 검증된 데이터베이스입니다. Supabase는 100만 개 이상의 데이터베이스를 서빙하고 하루 수십억 개의 API 요청을 처리합니다. 추가 스케일링을 위해, Pro ($25/월) 및 Team ($599/월) 플랜에는 전용 리소스와 우선 지원이 포함됩니다.

WooCommerce를 이 스택으로 마이그레이션할 수 있나요?

할 수 있지만 전자상거래는 상당한 복잡도를 추가합니다. WooCommerce에서 마이그레이션하는 대부분의 팀은 Shopify (Storefront API를 Next.js 프론트엔드와 사용) 또는 Medusa.js나 Saleor와 같은 오픈 소스 솔루션으로 갑니다. Supabase는 제품 카탈로그와 주문 관리를 처리할 수 있지만, 체크아웃, 결제 처리, 재고 관리, 세금 계산을 직접 구축해야 합니다. 대부분의 비즈니스의 경우 전용 전자상거래 백엔드를 사용하고 Next.js에 연결하는 것이 더 합리적입니다.

WordPress 멀티사이트에 대해 이 스택을 사용할 수 있나요?

절대적으로. Next.js는 미들웨어와 동적 라우팅을 사용한 멀티테넌트 아키텍처에 탁월합니다. Supabase의 Row Level Security는 테넌트별로 데이터를 분할하는 것을 간단하게 합니다. 50개 이상의 사이트가 있는 WordPress 멀티사이트 네트워크를 테넌트 특정 라우팅이 있는 단일 Next.js 애플리케이션으로 마이그레이션했고, 운영 단순화는 엄청났습니다.

CMS가 여전히 필요한가요, 아니면 Supabase를 바로 사용할 수 있나요?

Supabase는 개발자를 위한 테이블 편집기를 제공하지만, 콘텐츠 편집자는 보통 더 세련된 것을 원합니다. 가장 일반적인 접근 방식: (1) Sanity나 Storyblok과 같은 전용 헤드리스 CMS를 콘텐츠로, Supabase를 애플리케이션 데이터로 사용, (2) Next.js + Supabase Auth를 사용하여 간단한 관리 UI 구축, 또는 (3) WordPress를 헤드리스 CMS 백엔드로 유지. 옵션 1은 콘텐츠 중심 사이트에서 가장 인기 있습니다. 옵션을 탐색하고 있다면, Astro 개발 및 헤드리스 CMS 페이지에서 트레이드오프를 분석합니다.

마이그레이션이 잘못되면 WordPress로 롤백할 수 있나요?

네, 계획해야 합니다. 마이그레이션 과정 전반에 WordPress 사이트를 서브도메인에서 실행 상태로 유지하세요. DNS 수준 전환 (A 레코드 또는 CNAME 변경)을 사용하여 분 단위로 롤백할 수 있습니다. 모든 리다이렉트가 작동하고, 검색 순위가 안정적이며, 모든 기능이 검증된 후에만 출시 후 최소 30일 후에 이전 WordPress 인스턴스를 폐기할 것을 권장합니다. 마이그레이션을 적절한 롤백 절차로 계획하는 데 도움이 필요하면, 팀에 연락하세요. 충분히 이를 했습니다.