WordPress 해킹당했나요? Next.js + Supabase로 마이그레이션하는 최고의 해결책

클라이언트가 같은 이야기의 변형을 들고 오는 횟수를 더 이상 세지 못했습니다: "우리 WordPress 사이트가 해킹되었습니다. 정리했습니다. 다시 해킹되었습니다. 끝입니다." 마지막 경우는 WooCommerce 스토어가 정상적으로 보이는 플러그인 업데이트 내부에 숨겨진 신용카드 스키머에 감염된 중견 전자상거래 회사였습니다. 누군가 눈치채기 전 3주 동안 고객 결제 데이터를 유출하고 있었습니다. 그것은 예외 상황이 아닙니다. 그것은 WordPress 생태계의 평범한 화요일입니다.

이 글은 WordPress를 비난하는 것이 아닙니다. 웹의 상당한 부분을 정상적인 이유로 구동했습니다. 하지만 2005년에 접근 가능하게 만든 아키텍처는 2025년에 자동화된 공격의 자석이 되는 것과 같은 아키텍처입니다. 해킹된 경험이 있거나, 그 자체로 공격 벡터인 보안 플러그인에 돈을 쓰는 것이 지쳐있다면, 이것이 근본적으로 더 안전한 것으로 이동하기 위한 플레이북입니다.

목차

• WordPress 보안 문제는 아키텍처적입니다
• 2025년 일반적인 WordPress 공격 벡터
• 헤드리스 아키텍처가 전체 공격 범주를 제거하는 이유
• Next.js + Supabase: 보안 우선 스택
• 공격 표면 비교: WordPress vs 헤드리스
• 마이그레이션 플레이북: WordPress에서 Next.js + Supabase로
• 마이그레이션 후 보안 강화
• WordPress 보안 vs 마이그레이션의 실제 비용
• FAQ

WordPress 보안 문제는 아키텍처적입니다

한 가지 명확히 하겠습니다: WordPress 핵심 팀은 훌륭한 보안 작업을 합니다. WordPress 핵심, 최신 상태로 유지되면, 합리적으로 안전합니다. 하지만 누구도 WordPress 핵심만 실행하지 않습니다. 평균 WordPress 사이트에는 20-30개의 플러그인이 설치되어 있습니다. 각각은 직접 작성하지 않은 종속성이며, 알지 못하는 사람이 유지 관리하며, 데이터베이스, 파일시스템, 사용자 데이터에 접근 권한이 있습니다.

"WordPress 보안 모범 사례" 기사에서 자주 놓치는 것은 이렇습니다: 문제는 WordPress 사이트 소유자가 부주의하다는 것이 아닙니다. 문제는 WordPress의 아키텍처가 기본 기능을 얻기 위해 제3자로부터 서버에 직접 실행 가능한 PHP 코드를 설치하도록 요구한다는 것입니다. 그것은 집을 작업하는 모든 계약자에게 영구적으로 집의 열쇠를 주는 것과 같습니다.

WPScan의 취약성 데이터베이스는 2024년에 7,900개 이상의 새로운 WordPress 취약성을 추적했으며, 플러그인이 대략 96%를 차지합니다. Sucuri의 2024년 위협 보고서에 따르면 WordPress는 정리한 모든 CMS 감염의 약 95%를 차지했습니다. Patchstack은 2024년 중대 WordPress 취약성의 33%가 공개 당시 사용 가능한 패치가 없었다고 보고했습니다.

이러한 버그는 더 나은 코딩 관행으로 수정할 수 없습니다. 이것들은 아키텍처 자체의 당연한 성질입니다.

2025년 일반적인 WordPress 공격 벡터

수정에 대해 이야기하기 전에, 실제로 무엇을 방어하고 있는지 목록화해봅시다. 저는 개인적으로 수십 개의 손상된 WordPress 사이트를 분류했고, 공격은 예측 가능한 패턴으로 분류됩니다.

플러그인을 통한 SQL 주입

WordPress는 잘 알려진 스키마를 가진 MySQL 데이터베이스를 사용합니다. 사용자 입력을 수용하고 데이터베이스를 터치하는 모든 플러그인은 잠재적인 SQL 주입 포인트입니다. $wpdb->prepare() 함수가 존재하지만, 선택 사항입니다. 플러그인 개발자는 이를 잊거나, 잘못 사용하거나, 완전히 건너뜁니다.

저는 18개월 동안 버려진 연락처 양식 플러그인에서의 주입을 추적했지만 여전히 200,000개 이상의 사이트에 설치되어 있었습니다. 공격자는 UNION 기반 주입을 사용하여 wp_users 테이블을 덤프하고, 관리자 암호 해시를 가져오고, 약한 해시를 오프라인으로 크랙했습니다.

-- 로그에서 일반적인 WordPress SQL 주입의 예
GET /wp-content/plugins/vulnerable-plugin/ajax.php?id=1%20UNION%20SELECT%201,user_login,user_pass,4,5%20FROM%20wp_users--

PHP 객체 주입 및 원격 코드 실행

WordPress의 serialize()와 unserialize()의 광범위한 사용은 PHP 객체 주입의 기회를 만듭니다. 플러그인이 사용자 제어 데이터를 언시리얼라이즈할 때(많은 경우 그렇습니다), 공격자는 언시리얼라이제이션 프로세스 중에 임의의 코드를 실행하는 페이로드를 만들 수 있습니다.

2024년에, 인기 있는 백업 플러그인(5백만 개 이상 설치)의 중대 RCE 취약성은 인증되지 않은 공격자가 임의의 PHP 코드를 실행할 수 있게 했습니다. 수정에 11일이 걸렸습니다. 11일 동안 해당 플러그인을 실행하는 모든 사이트가 위험 상태였습니다.

플러그인 공급망 공격

이것이 가장 두렵습니다. 공격자는 많은 설치 기반을 가진 버려진 플러그인을 구입하고, 백도어를 포함한 "보안 업데이트"를 밀어붙이고, WordPress 자동 업데이트 메커니즘이 모든 해당 플러그인을 실행하는 모든 사이트에 맬웨어를 배포합니다. Display Widgets(300,000개 설치)과 Social Warfare(70,000개 설치)에서 발생했으며, 이것들은 감지된 것들뿐입니다.

wp-login.php에 대한 무차별 공격

모든 WordPress 사이트는 기본적으로 /wp-login.php와 /xmlrpc.php를 노출합니다. 자동화된 봇넷이 이 엔드포인트를 지속적으로 공격합니다. Wordfence는 2024년에 자신의 네트워크 전체에서 월평균 30억 개의 악의적인 요청을 차단했다고 보고했습니다. 속도 제한 및 2단계 인증이 있어도, 이러한 공격을 처리하기 위해 서버 리소스를 소비하고 있습니다.

테마 및 플러그인을 통한 교차 사이트 스크립팅(XSS)

WordPress의 저장된 XSS는 관리 대시보드와 공개 사이트가 같은 세션 컨텍스트를 공유하기 때문에 특히 위험합니다. 댓글, 양식 제출 또는 취약한 플러그인 설정을 통해 주입된 XSS 페이로드는 전체 관리자 접근으로 에스컬레이션될 수 있습니다.

헤드리스 아키텍처가 전체 공격 범주를 제거하는 이유

여기서 흥미로운 부분입니다. 헤드리스 아키텍처는 공격 표면을 단순히 줄이는 것이 아닙니다 -- 공격을 가능하게 하는 조건을 제거함으로써 전체 공격 범주를 제거합니다.

전통적인 WordPress 설정에서, HTML을 렌더링하는 같은 서버가:

• 20개 이상의 제3자 플러그인의 PHP 코드 실행
• 사용자 인증 관리
• 데이터베이스에 연결
• 관리 인터페이스 제공
• 파일 업로드 처리
• 양식 제출 처리

그것은 단일 애플리케이션을 위한 많은 책임입니다. Next.js와 Supabase를 포함한 헤드리스 설정에서, 이러한 책임은 격리된 서비스 전체에 분리됩니다:

• 프론트엔드(Vercel/Netlify의 Next.js): CDN에서 제공되는 정적 HTML/JS. 대부분의 경우 공개 인터넷에 노출된 서버측 런타임이 없습니다.
• 데이터베이스 + 인증(Supabase): 행 수준 보안을 가진 관리형 Postgres, 직접 최종 사용자에게 노출되지 않습니다.
• API 계층: 명시적, 최소한 엔드포인트를 가진 서버리스 함수.
• CMS(필요한 경우): 자신의 격리된 인프라에서 실행되는 헤드리스 CMS.

주입할 PHP가 없습니다. 쓰기 권한이 있는 플러그인 디렉토리가 없습니다. 관리자와 공개 사이트 간에 공유 세션이 없습니다. 봇이 공격할 wp-login.php가 없습니다.

존재하지 않는 공격 표면을 보호하기 위해 WAF이 필요하지 않습니다.

Next.js + Supabase: 보안 우선 스택

보안 관점에서 이 특정 조합이 왜 그렇게 잘 작동하는지에 대해 구체적으로 살펴봅시다.

Next.js: 코드를 실행하지 않는 프론트엔드

정적 생성(SSG) 또는 증분 정적 재생성(ISR)을 사용하여 Next.js 사이트를 빌드할 때, 배포되는 것은 CDN의 HTML, CSS, JavaScript 파일입니다. 실시간으로 요청을 처리하는 애플리케이션 서버가 없습니다. CDN에 SQL-인젝션할 수 없습니다.

동적 기능을 위해 Next.js 서버 작업과 경로 핸들러는 서버리스 함수로 실행됩니다. 각 함수는:

• 자신의 실행 컨텍스트에서 격리됨
• 상태 비저장(요청 간 공유 메모리 없음)
• 단기(콜드 스타트, 실행, 종료)
• 명시적 정의(엔드포인트의 자동 발견 없음)

// Next.js 경로 핸들러 -- 명시적, 타입화, 최소한
import { createClient } from '@/lib/supabase/server'
import { NextRequest, NextResponse } from 'next/server'
import { z } from 'zod'

const ContactSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  message: z.string().min(10).max(5000),
})

export async function POST(request: NextRequest) {
  const body = await request.json()
  const parsed = ContactSchema.safeParse(body)
  
  if (!parsed.success) {
    return NextResponse.json({ error: 'Invalid input' }, { status: 400 })
  }
  
  const supabase = await createClient()
  const { error } = await supabase
    .from('contact_submissions')
    .insert(parsed.data)
  
  if (error) {
    return NextResponse.json({ error: 'Submission failed' }, { status: 500 })
  }
  
  return NextResponse.json({ success: true })
}

WordPress 연락처 양식 플러그인과 비교해보세요. 이것은 WordPress의 작업 시스템으로 후킹해야 하고, 자신의 AJAX 핸들러를 포함하고, 자신의 nonce 확인을 관리하고, 자신의 SQL 쿼리를 구축해야 합니다. Next.js 버전은 움직이는 부분이 적고, Zod를 통한 검증된 입력, Supabase 클라이언트를 통한 매개변수화된 쿼리를 가집니다.

Supabase: 행 수준 보안을 가진 Postgres

Supabase는 하나의 살인 보안 기능을 가진 관리형 PostgreSQL 데이터베이스를 제공합니다: 행 수준 보안(RLS). 애플리케이션 코드가 접근 제어를 강제하도록 신뢰하는 대신(WordPress 모델), 데이터베이스 수준에서 보안 정책을 정의합니다.

-- 인증된 사용자만 자신의 데이터를 읽을 수 있음
CREATE POLICY "Users can view own profile"
  ON profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- 공개는 연락처 양식을 제출할 수 있지만 읽을 수 없음
CREATE POLICY "Anyone can submit contact form"
  ON contact_submissions
  FOR INSERT
  WITH CHECK (true);

CREATE POLICY "Only admins can read submissions"
  ON contact_submissions
  FOR SELECT
  USING (auth.jwt() ->> 'role' = 'admin');

공격자가 임의의 Supabase 쿼리를 만드는 방법을 찾더라도(PHP 실행 컨텍스트 없이는 이미 훨씬 어렵습니다), RLS 정책은 그들이 보면 안 되는 데이터에 접근하는 것을 방지합니다. 이것은 WordPress가 근본적으로 제공할 수 없는 방어 깊이입니다. 왜냐하면 그 권한 시스템이 PHP 코드에서 구현되기 때문입니다. 데이터베이스 계층이 아닙니다.

Supabase는 또한 이메일/암호, 매직 링크, OAuth 공급자 및 다중 인증에 대한 기본 지원을 가진 인증을 처리합니다. 플러그인이 필요하지 않습니다. 서버에서 실행되는 제3자 코드가 없습니다.

공격 표면 비교: WordPress vs 헤드리스

이를 나란히 놓겠습니다.

공격 벡터	WordPress	Next.js + Supabase
SQL 주입	높은 위험 -- 플러그인이 원시 쿼리를 구축	거의 0 -- Supabase 클라이언트를 통한 매개변수화된 쿼리, RLS을 백업으로
PHP/원격 코드 실행	높은 위험 -- 플러그인이 서버측 PHP 실행	해당 없음 -- PHP 런타임이 없음
플러그인 공급망	중대 위험 -- 자동 업데이트가 맬웨어 배포	해당 없음 -- 플러그인 생태계 없음
무차별 공격(로그인)	항상 노출(wp-login.php, xmlrpc.php)	Supabase 인증 또는 별도 대시보드를 통한 관리자 접근, 공개 로그인 엔드포인트 필요 없음
XSS(저장됨)	높은 위험 -- 공유 관리자/공개 컨텍스트	낮은 위험 -- React가 기본적으로 출력을 이스케이프, 관리자와 공개가 별도 앱
파일 업로드 악용	높은 위험 -- 업로드된 PHP 파일 실행 가능	낮은 위험 -- 업로드가 객체 스토리지(Supabase Storage/S3)로 이동, 코드로 실행되지 않음
데이터베이스 노출	서버 손상 시 직접 MySQL 접근	데이터베이스가 Supabase 인프라 뒤에 있음, RLS 정책을 최종 보호
원점 DDoS	서버가 모든 요청을 처리해야 함	정적 자산이 CDN에 있음, 원점이 거의 공격받지 않음
알려진 경로 열거	wp-admin, wp-content, wp-includes 모두 스캔 가능	예측 가능한 경로 없음, 노출된 관리 경로 없음

마이그레이션 플레이북: WordPress에서 Next.js + Supabase로

좋습니다, 설득되셨거나(혹은 해킹된 사이트가 설득했습니다). 실제로 이를 수행하는 방법은 다음과 같습니다. 우리는 Social Animal에서 이 마이그레이션을 충분히 실행했으므로 반복 가능한 프로세스를 가지고 있습니다.

1단계: 분류 및 콘텐츠 감시(1주차)

코드를 건드리기 전에, 실제로 무엇을 가지고 있는지 이해해야 합니다.

1. 모든 WordPress 콘텐츠 내보내기 WP-CLI 또는 REST API를 사용합니다. XML 내보내기에 의존하지 마세요 -- 메타 필드와 사용자 정의 게시물 유형이 누락됩니다.
2. 플러그인이 제공하는 모든 기능 카탈로그하기. 스프레드시트를 만드세요: 플러그인 이름, 무엇을 하는지, 실제로 필요한지 여부, 무엇이 교체되는지.
3. SEO 보존을 위한 URL 구조 매핑. 모든 기존 URL은 Next.js의 리디렉션 또는 일치하는 경로가 필요합니다.
4. 동적 기능 식별 -- 양식, 검색, 사용자 계정, 전자상거래 -- API 엔드포인트가 필요한 것.

# REST API를 통해 WordPress 콘텐츠 내보내기
curl -s "https://yoursite.com/wp-json/wp/v2/posts?per_page=100&page=1" | jq '.' > posts_page1.json
curl -s "https://yoursite.com/wp-json/wp/v2/pages?per_page=100" | jq '.' > pages.json
curl -s "https://yoursite.com/wp-json/wp/v2/media?per_page=100" | jq '.' > media.json

2단계: Supabase 스키마 및 데이터 마이그레이션(2주차)

콘텐츠 감시를 기반으로 Supabase 데이터베이스 스키마를 설계합니다. 단순히 WordPress 스키마를 복제하지 마세요 -- 메타데이터 테이블과 직렬화된 데이터 블롭으로 비어 있습니다.

-- 깔끔하고 목적 기반의 스키마
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')),
  published_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW(),
  author_id UUID REFERENCES auth.users(id)
);

-- 즉시 RLS 활성화
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Published posts are public"
  ON posts FOR SELECT
  USING (status = 'published');

CREATE POLICY "Authors can manage own posts"
  ON posts FOR ALL
  USING (auth.uid() = author_id);

WordPress JSON 내보내기를 새 스키마로 변환하고 Supabase에 삽입하는 마이그레이션 스크립트(Node.js 또는 Python)를 작성합니다.

3단계: Next.js 빌드(3주차-5주차)

Next.js 프론트엔드를 빌드합니다. 스택을 알고 있는 팀으로 작업하면 이것이 빠르게 진행됩니다. 도움이 필요하면, 우리의 Next.js 개발 팀이 이 마이그레이션을 충분히 해서 올바른 패턴에 대해 강한 의견을 가지고 있습니다.

주요 아키텍처 결정:

• 콘텐츠 페이지에 대한 정적 생성 -- 블로그 게시물, 랜딩 페이지, 소개 페이지. 이것들은 CDN의 HTML 파일이 됩니다.
• 동적 데이터에 대한 서버 컴포넌트 -- 캐싱을 사용하여 요청 시간에 Supabase에서 가져옵니다.
• 양식 제출을 위한 경로 핸들러 -- 연락처 양식, 뉴스레터 가입 등.
• 리디렉션을 위한 미들웨어 -- 모든 이전 WordPress URL을 처리합니다.

// next.config.ts -- WordPress URL 리디렉션 처리
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/category/:slug',
        destination: '/blog/category/:slug',
        permanent: true,
      },
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // wp-login.php -- 봇을 410으로 보냅니다
      {
        source: '/wp-login.php',
        destination: '/gone',
        permanent: true,
      },
      {
        source: '/wp-admin/:path*',
        destination: '/gone',
        permanent: true,
      },
    ]
  },
}

4단계: 테스트 및 SEO 검증(6주차)

• Screaming Frog를 새 사이트에 대해 실행하여 모든 이전 URL이 확인하거나 리디렉션되는지 확인합니다.
• 구조화된 데이터(JSON-LD)가 모든 페이지에 있는지 확인합니다.
• 모든 양식과 동적 기능을 테스트합니다.
• Lighthouse 및 Core Web Vitals 검사를 실행합니다 -- CDN에서 제공하고 있으므로 거의 확실히 개선 사항을 볼 수 있습니다.
• Vercel Analytics 또는 선호하는 도구를 사용하여 모니터링을 설정합니다.

5단계: 시작 및 DNS 전환(6주차-7주차)

Vercel 또는 Netlify에 배포하고, DNS를 업데이트하고, 모니터링을 설정합니다. 필요한 경우를 대비해 30일 동안 이전 WordPress 인스턴스를 오프라인이지만 접근 가능하게 유지합니다.

사이트에 상당한 트래픽이나 전자상거래 기능이 있는 경우, 헤드리스 CMS 통합을 고려하고 콘텐츠 기반 사이트에 대한 대안 프론트엔드로 Astro에 대해 우리에게 이야기하세요. 여기서 빌드 성능이 중요합니다.

마이그레이션 후 보안 강화

새 스택에 있으면, 다음은 보안 체크리스트입니다:

1. 모든 테이블에서 Supabase RLS을 활성화합니다. 예외 없음. 테이블에 정책이 없으면, 접근 불가능(좋은 기본값) 또는 넓게 열림(나쁜 것)입니다.
2. 모든 비밀에 환경 변수를 사용합니다. Vercel과 Netlify는 모두 이를 잘 처리합니다. API 키를 절대 커밋하지 마세요.
3. Supabase 데이터베이스 백업을 설정합니다. 특정 시점 복구는 Pro 계획($25/개월)에서 사용 가능합니다.
4. Next.js 미들웨어에서 콘텐츠 보안 정책 헤더를 구성합니다.
5. Vercel의 DDoS 보호를 활성화합니다(모든 계획에 포함됨).
6. 가동 시간 모니터링을 설정합니다 -- 우리는 Better Uptime을 사용하지만, Checkly과 Vercel의 내장 모니터링도 작동합니다.
7. 분기마다 Supabase RLS 정책을 감사합니다. Supabase의 SQL 편집기를 사용하여 다양한 사용자 컨텍스트를 가진 정책을 테스트합니다.

// middleware.ts -- 보안 헤더
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const response = NextResponse.next()
  
  response.headers.set('X-Frame-Options', 'DENY')
  response.headers.set('X-Content-Type-Options', 'nosniff')
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin')
  response.headers.set(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
  )
  response.headers.set(
    'Permissions-Policy',
    'camera=(), microphone=(), geolocation=()'
  )
  
  return response
}

WordPress 보안 vs 마이그레이션의 실제 비용

돈을 이야기해봅시다. 왜냐하면 그것이 실제로 결정을 운전하기 때문입니다.

비용 범주	WordPress(연간)	Next.js + Supabase(연간)
호스팅	$300-1,200(관리형 WP)	$0-240(Vercel Pro)
보안 플러그인(Wordfence/Sucuri)	$200-500	$0(필요하지 않음)
SSL/CDN	$0-200	$0(포함됨)
맬웨어 정리(해킹된 경우)	사건당 $500-2,500	해당 없음
보안 패치의 개발자 시간	$2,000-5,000	$500-1,000
데이터베이스(Supabase)	호스팅에 포함됨	$0-300(무료 계층~Pro)
총계	$3,000-9,400	$500-1,540

다운타임, 잃어버린 고객 신뢰, 고객 데이터가 손상된 경우 잠재적 규제 벌금의 비용을 고려하기 전에도 말입니다. 단일 GDPR 보고 가능 위반은 법률 및 규정 준수 오버헤드에 수만 달러를 소비할 수 있습니다.

마이그레이션 자체는 일반적으로 사이트 복잡도에 따라 $10,000-40,000의 비용이 듭니다. 대부분의 비즈니스의 경우, 이는 1-2년 내 감소된 보안 지출만으로 자신을 지불합니다 -- 그리고 프로세스에서 더 빠르고 더 유지 가능한 사이트를 얻습니다. 가격 페이지에서 마이그레이션 프로젝트에 대한 세부 사항을 확인하세요.

FAQ

WordPress가 정말 그렇게 안전하지 않습니까, 아니면 과장된 것입니까?

WordPress 핵심은 잘 유지됩니다. 문제는 사실상 아무도 핵심만 실행하지 않는다는 것입니다. 플러그인 생태계는 취약성의 96%가 존재합니다. WordPress 사이트 없이 유용한 WordPress 사이트를 실행할 수 없습니다. 것은 과장되지 않습니다 -- Sucuri는 2024년에 60,000개 이상의 WordPress 사이트에서 맬웨어를 정리했습니다. 아키텍처는 제3자 PHP 코드를 서버에서 신뢰하도록 요구하며, 이 신뢰는 지속적으로 악용됩니다.

마이그레이션 대신 더 나은 보안 플러그인을 사용할 수 없습니까?

보안 플러그인은 그 자체로 서버에서 깊은 시스템 접근으로 실행되는 PHP 코드입니다. Wordfence와 Sucuri는 잘 유지되지만, 아키텍처 문제에 대한 밴드-에이드입니다. 또한 서버 로드를 추가하고, 다른 플러그인과 충돌할 수 있으며, 수년에 걸쳐 자신의 취약성을 가졌습니다. 복잡도 문제를 해결하기 위해 복잡도를 추가하고 있습니다.

WordPress에서 Next.js로의 마이그레이션은 일반적으로 얼마나 오래 걸립니까?

표준 비즈니스 사이트(10-50개 페이지, 블로그, 연락처 양식)의 경우, 우리는 일반적으로 5-7주 내에 마이그레이션을 완료합니다. WooCommerce를 가진 전자상거래 사이트는 더 복잡하며 제품 카탈로그 크기 및 사용자 정의 기능에 따라 8-14주가 걸릴 수 있습니다. 더 간단한 사이트가 있으면, 우리에게 연락하세요하고 더 구체적인 일정을 제공할 수 있습니다.

WordPress에서 마이그레이션할 때 SEO 순위를 잃을까요?

올바르게 수행하면 아닙니다. 중대한 단계는 다음과 같습니다: 모든 URL 구조를 보존하거나 올바른 301 리디렉션을 설정하고, 구조화된 데이터 마크업을 유지하고, 콘텐츠를 그대로 유지하고, Google Search Console에 업데이트된 사이트맵을 제출합니다. 우리의 마이그레이션 클라이언트 대부분은 2-3개월 내 순위 개선을 보는데, 이는 CDN 서빙 정적 사이트로 이동할 때 Core Web Vitals 점수가 크게 개선되기 때문입니다.

콘텐츠 편집은 어떻습니까? WordPress는 기술이 아닌 사용자를 위해 쉽습니다.

이것은 정당한 우려입니다. 선택지가 있습니다: Supabase를 사용하여 사용자 정의 관리 대시보드 또는 Sanity, Contentful 또는 Payload CMS 같은 헤드리스 CMS를 사용하여 WordPress와 유사한 시각적 편집 경험을 제공합니다. 우리는 헤드리스 CMS 통합을 정기적으로 처리하고 팀의 필요에 맞는 올바른 적합을 권장할 수 있습니다.

Supabase는 프로덕션 사용에 안전합니까?

Supabase는 SOC 2 Type II 규정 준수를 가진 AWS 인프라에서 실행됩니다. 기본 데이터베이스는 강한 보안 기록을 가진 PostgreSQL입니다. 행 수준 보안 정책은 데이터베이스 수준에서 접근 제어를 강제합니다. 이는 실제로 WordPress의 PHP 기반 권한 시스템보다 더 안전합니다. Supabase는 또한 특정 시점 복구, 암호화된 연결, 유료 계획의 네트워크 제한을 제공합니다.

내 WordPress 사이트가 해킹되고 즉시 도움이 필요하면 어떻게 해야 합니까?

먼저, 사이트를 즉시 오프라인으로 설정하여 추가 손상과 데이터 유출을 중지합니다. 둘째, 법의학 증거를 보존합니다(데이터베이스 덤프, 접근 로그, 파일시스템 스냅샷). 셋째, 단순히 정리하고 다시 설정하지 마세요 -- 아마도 몇 주 내에 다시 감염될 것입니다. 그 사건을 마이그레이션의 촉매로 사용하세요. 우리 팀에 연락하세요하고 즉시 분류 및 마이그레이션 계획 모두에 도움을 드릴 수 있습니다.

한 번에 모든 것을 마이그레이션해야 합니까, 아니면 점진적으로 할 수 있습니까?

점진적 마이그레이션은 가능하지만 복잡도를 추가합니다. Next.js를 프론트엔드로 실행하면서 WordPress를 임시로 헤드리스 CMS 백엔드로 유지할 수 있습니다. 그런 다음 WordPress를 완전히 단계적으로 폐지합니다. 하지만, 이는 WordPress가 여전히 실행 중이고 전환 중에 여전히 보안 유지 관리가 필요함을 의미합니다. 대부분의 사이트의 경우, 정리된 전환이 더 빠르고, 저렴하고, 보안 위험을 더 빨리 제거합니다.