WordPress를 시작할 때는 좋았지만, 이제... 이런 말을 몇 번이나 들었는지 헤아릴 수 없습니다. 그리고 나서 목록이 나옵니다. 사이트가 로드되는 데 6초가 걸립니다. 연락처 양식 플러그인이 마지막 업데이트 후 깨졌습니다. 2022년 이후 유지보수되지 않은 플러그인에 치명적인 취약점이 있습니다. 원본 테마를 만든 개발자가 사라졌습니다. 익숙한가요?

여기 문제가 있습니다 -- WordPress는 웹의 40% 이상을 구동하고 있으며, 그럴 만한 이유가 있습니다. 접근하기 쉽고 거대한 생태계를 가지고 있으며, 많은 비즈니스를 빠르게 온라인에 올렸습니다. 하지만 시작하는 데 도움이 되는 도구와 당신과 함께 확장하는 도구 사이에는 차이가 있습니다. 이 글을 읽고 있다면, 아마도 그 벽에 부딪혔을 것입니다. WordPress에서 headless 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의 2024 Core Web Vitals 데이터에 따르면 WordPress 사이트의 세 가지 CWV 메트릭 모두에서 33% 통과율을 보이는 반면, 최신 JavaScript 프레임워크로 구축된 사이트의 경우 52%입니다.

보안 취약점이 밤잠을 설치게 합니다

WPScan의 2024 취약점 데이터베이스는 그 해 7,000개 이상의 새로운 WordPress 취약점을 추적했습니다 -- 대부분 플러그인과 테마입니다. 사용자 데이터, 결제 또는 민감한 정보를 처리하는 사이트를 운영 중이라면, 각 플러그인은 공격 표면입니다. Patchstack은 2024년 WordPress 보안 취약점의 97%가 플러그인에서 왔다고 보고했습니다.

본질적으로 수십 명의 독립적인 개발자 -- 대부분 플러그인을 부업으로 유지 관리합니다 -- 에게 보안 상태를 신뢰하고 있습니다.

개발 팀이 작업하기를 싫어합니다

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

WordPress 세금: 플러그인 지옥이 실제로 비용을 얼마나 드는가

이것에 숫자를 붙여 보겠습니다. 중간 규모의 WordPress 사이트(예를 들어, 블로그, 사용자 계정, 사용자 정의 기능이 있는 e-커머스 사이트 또는 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가 의미 있는 스택인 이유

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

하지만 2025년에 WordPress에서 마이그레이션하는 팀의 경우, Next.js + Supabase는 이기기 어려운 완벽한 지점을 제시합니다. 이유는 다음과 같습니다.

Next.js: 모든 것을 하는 프론트엔드

Next.js 15(2024년 10월부터 안정적)는 기본적으로 서버 컴포넌트를 제공하므로 정적 사이트의 성능과 동적 사이트의 유연성을 모두 얻을 수 있습니다. 블로그 게시물을 빌드 타임에 정적으로 생성하고, 동적 페이지를 서버 렌더링하고, 대화형 컴포넌트를 클라이언트 렌더링할 수 있습니다 -- 모두 동일한 앱에서.

WordPress에서 온 팀의 주요 이점은:

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

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

Supabase: WordPress가 원했던 백엔드

Supabase는 PostgreSQL을 기반으로 구축된 오픈 소스 Firebase 대안입니다. 제공하는 것:

  • PostgreSQL 스키마에서 자동 생성되는 REST 및 GraphQL API가 있는 완전한 Postgres 데이터베이스
  • 기본 제공 인증 (이메일, OAuth, 매직 링크, SSO)
  • 세분화된 접근 제어를 위한 행 수준 보안 정책
  • WebSocket을 통한 실시간 구독
  • 서버리스 백엔드 로직을 위한 에지 함수
  • CDN 전달이 있는 파일 업로드를 위한 저장소

WordPress 마이그레이션의 경우 특히 Supabase는 WordPress가 MySQL을 사용하고 데이터 모델이 놀랍도록 잘 PostgreSQL에 매핑되기 때문에 훌륭합니다. 사용자 정의 게시물 유형은 테이블이 됩니다. 게시물 메타는 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. 모든 양식, 통합 및 제3자 연결을 문서화합니다
  5. 사용자 정의 기능 식별 테마의 functions.php에 있는 것

플러그인 매핑 연습은 중요합니다. 일반적인 대체물은 다음과 같습니다:

WordPress 플러그인 Headless 대체물
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 / Custom Fields 입력된 스키마가 있는 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

# 게시물 메타 내보내기 (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-to-Markdown 변환을 처리하지만 단축코드 및 블록에 대한 사용자 정의 규칙이 필요합니다.

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
);

-- 행 수준 보안
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에서 수행한 마이그레이션의 실제 숫자입니다(이것은 2024-2025년 12개 마이그레이션 프로젝트의 평균입니다):

메트릭 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 컴포넌트로 바꾸면 결과는 예측 가능합니다.

프로젝트에 대해 이러한 종류의 결과가 어떻게 보일지 궁금하다면 가격 페이지에서 headless 마이그레이션 프로젝트의 일반적 비용을 분석합니다.

비용 비교: WordPress vs Headless 스택

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

headless 스택은 연간 운영 비용이 70-85% 저렴합니다. 마이그레이션 자체는 명백히 초기 비용이 있습니다 -- 일반적으로 복잡성에 따라 전문가 구축의 경우 $15,000-$60,000입니다 (headless CMS 개발 서비스 세부사항 확인). 하지만 6-18개월 내에 감소된 운영 비용으로 자신을 갚습니다. 더 나은 성능 및 SEO의 수익 영향을 고려하기 전입니다.

FAQ

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

아니요. 대부분의 팀은 Next.js를 Sanity, Contentful 또는 WordPress 자체를 headless CMS로 사용하는 등의 headless CMS와 쌍을 이룹니다(REST API를 통해). 콘텐츠 편집자는 코드에 접근하지 않습니다. 깨끗한 편집 인터페이스를 얻고 프론트엔드는 API를 통해 콘텐츠를 가져옵니다. 팀이 이미 알고 있는 WordPress 편집자를 유지하고 싶다면, 절대적으로 할 수 있습니다 -- 단지 WordPress 프론트엔드를 제거하고 콘텐츠 백엔드로 사용하세요.

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

콘텐츠 중심의 사이트(블로그 및 표준 페이지)의 경우: 4-6주. e-커머스, 사용자 계정, 사용자 정의 게시물 유형 및 복잡한 기능이 있는 사이트의 경우: 8-14주. 가장 큰 변수는 콘텐츠 복잡성입니다 -- 단축코드에 크게 의존하거나 깊게 사용자 정의된 Gutenberg 블록이 있는 사이트는 깨끗하게 마이그레이션하는 데 더 오래 걸립니다.

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

리다이렉트를 제대로 처리하면 아닙니다. 301 리다이렉트는 ~90-99%의 링크 공정성을 유지합니다. 우리는 일반적으로 마이그레이션 후 처음 1-2주에 작은 하락을 본 후(Google이 다시 크롤링해야 함) 더 나은 Core Web Vitals 점수로 인한 개선된 순위를 봅니다. 핵심은 모든 단일 URL을 매핑하고 리다이렉트 맵이 완성될 때까지 시작하지 않는 것입니다.

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

네. Supabase는 AWS 인프라에서 실행되며 수백만 개의 요청을 처리하는 회사의 프로덕션에서 사용되었습니다. 그들의 데이터베이스는 단지 PostgreSQL일 뿐입니다 -- 아마도 존재하는 가장 검증된 데이터베이스. 2025년 현재 Supabase는 100만 개의 데이터베이스를 제공하고 있으며 매일 수십억 개의 API 요청을 처리합니다. 추가 스케일을 위해 Pro ($25/월) 및 Team ($599/월) 계획에는 전용 리소스 및 우선 지원이 포함됩니다.

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

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

WordPress multisite에 대해서는 어떤가요 -- 이 스택이 이것을 대체할 수 있나요?

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

여전히 CMS가 필요합니까, 아니면 Supabase를 직접 사용할 수 있습니까?

Supabase는 개발자용 테이블 편집자를 제공하지만 콘텐츠 편집자는 일반적으로 더 광택이 난 것을 원합니다. 가장 일반적인 접근 방식은: (1) 콘텐츠에는 Sanity 또는 Storyblok 같은 전용 headless CMS를 사용하고 애플리케이션 데이터에는 Supabase를 사용, (2) Next.js + Supabase Auth를 사용하여 간단한 관리 UI 구축, 또는 (3) WordPress를 headless CMS 백엔드로 유지합니다. 옵션 1은 콘텐츠 많은 사이트의 경우 가장 인기 있습니다. 옵션을 탐색하고 있다면 Astro 개발 및 headless CMS 페이지에서 장단점을 분석합니다.

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

네, 이를 계획해야 합니다. 마이그레이션 프로세스 전반에 걸쳐 WordPress 사이트를 서브도메인에서 실행 중으로 유지하세요. DNS 수준 전환(A 레코드 또는 CNAME 변경)을 사용하여 분 단위로 롤백할 수 있습니다. 시작 후 최소 30일 동안 이전 WordPress 인스턴스를 실행 중으로 유지할 것을 권장합니다. 모든 리다이렉트가 작동하고, 검색 순위가 안정적이며, 모든 기능이 확인된 후에만 해제하세요. 적절한 롤백 절차가 있는 마이그레이션 계획을 세우고 싶다면 팀에 연락하세요 -- 우리는 이것을 충분히 해 본 것 같아서 함정이 어디인지 알고 있습니다.