오후 9시에 클라이언트 이메일이 온다: "다음 분기에 일본어를 추가할 수 있을까?" 마음이 철렁 내려간다. Multisite 네트워크는 이미 12개 언어로 느려지고 있다. 지난달 WPML 업데이트가 폴란드어 레이아웃을 망쳤다. 공유 wp_options 테이블이 840MB에 달하고 스테이징 환경을 복제하는 데 11분이 걸린다. 이 아키텍처를 이미 세 번 패치했고, 매번 다음 언어 출시가 더 어려워진다. 우리는 이 정확한 설정을 경험했다 — 91,000+ 페이지, 30개 언어, 엔터프라이즈 규모 — 그리고 Multisite와 WPML을 완전히 없앴다. 플러그인 갱신이 없다. 공유 테이블이 없다. 언어 간 간섭이 없다. 새로운 스택은 더 빠르게 배포되고, 호스팅 비용이 40% 저렴하고, 두려움 없이 확장된다. 여기가 우리가 실제로 배포한 아키텍처, 마이그레이션에서 깨진 것들, 그리고 작동하게 한 네 가지 결정이다.

우리는 더 이상 그런 식으로 하지 않는다. 오늘날 우리 프로덕션 시스템은 로케일당 118+ 페이지에 걸쳐 30개 언어를 제공한다 — 총 91,000+ 동적 페이지다 — WordPress Multisite 없이, WPML 없이, 둘 중 하나와 함께 오는 연간 라이선싱 불안 없이. 새로운 언어를 추가하는 데 약 45분이 걸리고 API 토큰으로 대략 $22이 든다.

이 글은 전체 분석이다. 아키텍처, 도구, 비용, 그리고 여러 엔터프라이즈 프로젝트에 걸쳐 개선한 마이그레이션 경로.

목차

WordPress Multisite가 규모에서 무너지는 이유

WordPress Multisite는 2010년에 단일 설치에서 여러 블로그를 실행하기 위해 설계되었다. 진정한 다국어 엔터프라이즈 배포를 위해 아키텍처 된 적이 없다. 규모를 밀어붙일 때 무슨 일이 일어나는지 보자:

공유 데이터베이스, 공유 문제. Multisite 네트워크의 모든 사이트는 접두사가 있는 테이블(wp_2_posts, wp_3_posts 등)을 가진 동일한 wp_ 데이터베이스를 공유한다. 사이트 간 콘텐츠 공유는 취약하다. 한 사이트의 플러그인 업데이트가 전체 네트워크에 장애를 일으킬 수 있다. 단일 형식이 잘못된 마이그레이션 스크립트가 12개의 언어 변형을 동시에 다운시키는 것을 본 적이 있다.

관리 복잡성이 증가한다. 각 하위 사이트는 자체 관리자 대시보드를 가지지만, 진정으로 격리되지 않는다. Super Admin은 모든 것을 본다. Site Admin은 너무 적게 본다. 모든 주요 WordPress 업데이트에서 깨지는 사용자 정의 역할 관리 없이 독일 콘텐츠 팀이 자신의 콘텐츠에만 액세스 할 수 있도록 하는 깔끔한 방법이 없다.

플러그인 호환성은 지뢰밭이다. 모든 플러그인이 Multisite 호환이 아니다. 스페인어 사이트에서 Multisite와 잘 어울리지 않는 양식 플러그인이 필요하면, 기능과 안정성 중 선택에 갇혀 있다. 이 결정을 10개 이상의 언어에 걸쳐 곱해보자.

진정한 API-first 아키텍처가 없다. WP REST API가 존재한다. 하지만 현대 다국어 사이트가 요구하는 로케일 인식, 에지 배포, CDN 캐시된 콘텐츠 제공을 위해 설계되지 않았다. 계층을 캐싱하고 사용자 정의 엔드포인트를 덧붙이다 보니 자신들의 유지보수 부담이 된다.

WPML과 WordPress 다국어 플러그인의 실제 비용

이 부분에서 WordPress 다국어 이야기가 불편해진다. 숫자로 말해보자.

WPML 라이선싱: 연간 $199 Multilingual Agency 플랜의 진입점이다. 이것이 진지한 다국어 작업의 시작점이다. 그리고 사이트당 — 또는 Multisite의 경우 네트워크당이다. 다시 말하면, 영원히 그들의 갱신 주기에 묶여 있다는 뜻이다.

성능 영향: 페이지 로드 20-40% 느려짐. 여러 클라이언트 사이트에서 이를 벤치마크했다. WPML은 모든 페이지 로드에서 번역을 해석하고, 언어를 전환하고, 문자열 번역을 관리하기 위해 데이터베이스 쿼리를 추가한다. 콘텐츠가 많은 페이지에서는 수십 개의 추가 쿼리다. LCP 점수가 떨어진다. 사용자가 눈치챈다.

번역 관리 비용이 실제 살인자다. 전문 번역 기관은 단어당 $0.10-$0.20을 청구한다. 10개 언어에 걸쳐 약 50,000단어의 콘텐츠를 가진 엔터프라이즈 사이트의 경우:

  • 저가 추정: 50,000 × $0.10 × 10 = 연간 $50,000
  • 고가 추정: 50,000 × $0.20 × 10 = 연간 $100,000

이것은 초기 번역일 뿐이다. 모든 콘텐츠 업데이트, 모든 새 페이지, 모든 블로그 포스트 — 모두 번역 파이프라인을 다시 거쳐야 한다.

더 나은 방법이 있다.

현대적 아키텍처: Next.js + next-intl + Headless CMS

여기가 엔터프라이즈 배포에서 우리가 구축하고 검증한 스택이다:

┌─────────────────────────────────────────────┐
│              Edge / CDN Layer                │
│         (Vercel / Cloudflare)               │
├─────────────────────────────────────────────┤
│           Next.js Application               │
│    ┌─────────────────────────────────┐      │
│    │    next-intl (i18n routing)     │      │
│    │    /en/about  /de/ueber-uns    │      │
│    │    /ja/about  /ar/about        │      │
│    └─────────────────────────────────┘      │
├─────────────────────────────────────────────┤
│         Headless CMS / Supabase             │
│    ┌──────────┐  ┌──────────────────┐      │
│    │  Content  │  │  Translation     │      │
│    │  Models   │  │  Tables (i18n)   │      │
│    └──────────┘  └──────────────────┘      │
├─────────────────────────────────────────────┤
│        AI Translation Pipeline              │
│    (Claude API → Review → Publish)          │
└─────────────────────────────────────────────┘

핵심 통찰: 콘텐츠 관리를 번역 관리와 프레젠테이션으로부터 분리한다. 각 계층은 독립적으로 진화할 수 있다. 번역에 손을 대지 않고 CMS를 바꾼다. 콘텐츠를 마이그레이션하지 않고 프론트엔드 프레임워크를 바꾼다. 코드를 건드리지 않고 언어를 추가한다.

next-intl 구성

여기가 우리의 라우팅 설정이 실제로 어떻게 보이는지다:

// src/i18n/routing.ts
import { defineRouting } from 'next-intl/routing';

export const routing = defineRouting({
  locales: [
    'en', 'es', 'fr', 'de', 'pt', 'it', 'nl', 'sv', 'no', 'da',
    'fi', 'pl', 'cs', 'ro', 'tr', 'ar', 'hi', 'ja', 'ko',
    'zh-CN', 'zh-TW', 'th', 'vi', 'id', 'ms', 'ru', 'uk'
  ],
  defaultLocale: 'en',
  localePrefix: 'as-needed'
});

// src/middleware.ts
import createMiddleware from 'next-intl/middleware';
import { routing } from './i18n/routing';

export default createMiddleware(routing);

export const config = {
  matcher: ['/', '/(de|es|fr|ja|...)/:path*']
};

이것은 깔끔한 URL 구조를 제공한다: /en/services, /de/dienstleistungen, /ja/サービス. 각 로케일은 자신의 정적으로 생성된 페이지를 가지며, 에지에서 제공된다. 언어 해석을 위한 런타임 데이터베이스 쿼리가 없다.

Supabase 번역 테이블

우리는 간단하지만 효과적인 스키마를 가진 Supabase에 번역을 저장한다:

CREATE TABLE translations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  namespace TEXT NOT NULL,
  key TEXT NOT NULL,
  locale TEXT NOT NULL,
  value TEXT NOT NULL,
  updated_at TIMESTAMPTZ DEFAULT now(),
  UNIQUE(namespace, key, locale)
);

CREATE INDEX idx_translations_locale ON translations(locale);
CREATE INDEX idx_translations_namespace ON translations(namespace, locale);

이 스키마는 30개 언어 × 수천 개의 번역 키를 문제 없이 처리한다. 쿼리는 간단하고, 캐시 가능하며, 빠르다.

번역 파이프라인 설정하기

번역 파이프라인은 이 아키텍처가 정말 보상을 받는 곳이다. 우리의 워크플로우는 다음과 같다:

  1. 콘텐츠는 Headless CMS에서 영어로 작성된다
  2. 빌드 스크립트는 모든 번역 가능한 문자열을 JSON 파일로 추출한다
  3. Claude API는 대상 로케일당 각 JSON 파일을 번역한다
  4. 리뷰 단계(선택 사항, 중요 콘텐츠의 경우)는 인간 편집자가 번역을 승인하도록 한다
  5. 번역은 저장소로 커밋되거나 Supabase로 푸시된다
  6. Next.js는 ISR 또는 전체 재빌드를 통해 영향받은 페이지를 재빌드한다
// scripts/translate.ts
import Anthropic from '@anthropic-ai/sdk';
import { readFileSync, writeFileSync } from 'fs';

const anthropic = new Anthropic();

async function translateFile(sourcePath: string, targetLocale: string) {
  const source = JSON.parse(readFileSync(sourcePath, 'utf-8'));
  
  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 4096,
    messages: [{
      role: 'user',
      content: `Translate the following JSON values (not keys) to ${targetLocale}. 
      Maintain the exact JSON structure. Use natural, professional language 
      appropriate for a corporate website. Preserve any HTML tags or 
      interpolation variables like {name}.
      
      ${JSON.stringify(source, null, 2)}`
    }]
  });
  
  const translated = JSON.parse(message.content[0].text);
  writeFileSync(
    sourcePath.replace('/en/', `/${targetLocale}/`),
    JSON.stringify(translated, null, 2)
  );
}

이것은 단순화되었지만, 핵심 아이디어를 포착한다. 프로덕션에서는 요청을 배치 처리하고, 속도 제한을 처리하고, 출력 구조를 검증하고, 자동화된 품질 검사를 실행한다.

AI 번역: 모든 것을 바꾼 경제학

여기서 수학이 재미있어진다.

우리 사이트의 전통적인 번역 (118+ 페이지, 언어당 약 50,000단어):

  • 언어당: $5,000-$10,000 (기관 요금)
  • 30개 언어: $150,000-$300,000
  • 연간 업데이트: $50,000-$100,000

Claude를 사용한 AI 번역:

  • 언어당: API 토큰에 ~$22
  • 언어당 시간: ~45분
  • 30개 언어: 총 ~$660, ~22.5시간
  • 새로운 언어 추가: 45분, $22

그것은 오타가 아니다. 언어당 22달러다.

이제 솔직하게 말하고 싶다. 2026년의 AI 번역이 모든 사용 경우에 완벽하지는 않다. 법적 문서, 의료 콘텐츠, 매우 미묘한 마케팅 카피 — 이들은 여전히 인간 검토의 이점이 있다. 하지만 기업 웹사이트, 제품 설명, 문서, 블로그 콘텐츠의 경우? 품질은 놀랍게도 좋다. 우리는 일본어, 아랍어, 독일어로 우리의 AI 번역 콘텐츠를 검토한 원어민을 가졌으며, 피드백은 지속적으로 "문구 선호도가 있는 전문 품질"로 착지한다.

실제 이점은 비용일 뿐만 아니라 속도다. 새로운 영어 페이지를 게시하고 30개 언어로 사용 가능하게 하려면, 주가 아니라 몇 시간을 보면 된다. 기관 조정 없음. 번역 메모리 관리 없음. 용어에 대한 왕복 없음.

다국어 콘텐츠를 위한 Headless CMS 옵션

여기서 선택지가 있으며, 올바른 선택은 팀과 규모에 따라 다르다. 우리가 평가한 것은 다음과 같다:

| 플랫폼 | i18n 지원 | 자체 호스팅 | 가격 책정 (2026) | 최고의 경우 | |----------|-------------|-------------|-----------------|----------|| | Sanity | 네이티브 필드 수준 | 클라우드 + 자체 호스팅 | 무료 계층, $15+/월 프로 | 구조화된 콘텐츠, 실시간 협업 | | Payload CMS | 네이티브, TypeScript | 예 | 무료 / OSS | 전체 제어를 원하는 개발자 팀 | | Strapi | 플러그인 기반 i18n | 예 | 무료 / OSS | Strapi 생태계에 이미 있는 팀 | | Storyblok | 네이티브 필드 수준 | 클라우드 전용 | $106+/월 | 시각적 편집, 마케팅 팀 | | Supabase (raw) | 커스텀 스키마 | 예 | 무료 계층, $25+/월 | 최대 유연성, 개발자 중심 팀 |

우리의 Headless CMS 개발 프로젝트의 경우, 일반적으로 콘텐츠가 많은 사이트에는 Sanity 또는 Payload를 권장하고, 팀이 번역 파이프라인을 최대한 제어하려 할 때는 Supabase 직접을 권장한다.

중요한 구별: Headless 접근 방식으로, CMS는 콘텐츠 저장소와 편집 워크플로우를 처리한다. 번역 관리는 응용 프로그램 계층에 산다. 이 분리는 CMS 공급업체의 다국어 콘텐츠 작동 방식에 대한 아이디어에 묶여 있지 않다는 것을 의미한다.

단계별: 30개 언어 사이트 구축하기

다국어 웹사이트 개발을 위해 우리가 따르는 실제 프로세스는 다음과 같다:

1단계: 로케일 전략 정의

코드를 작성하기 전에 다음을 결정하자:

  • 실제로 어떤 언어가 필요한가? (분석을 확인하자)
  • 로컬화된 URL (/de/kontakt)을 사용할 것인가 아니면 하위 도메인 (de.example.com)을 사용할 것인가?
  • 지역 변형 (en-US vs en-GB)이 필요한가 아니면 언어 코드만 필요한가?
  • 어떤 콘텐츠는 번역되고 어떤 것은 로케일별인가?

우리는 경로 기반 라우팅 (/de/, /ja/)을 기본값으로 사용한다. SEO에 더 간단하고, 단일 도메인에서 배포하기 더 쉽고, Next.js 미들웨어와 자연스럽게 작동하기 때문이다.

2단계: Next.js를 next-intl로 설정

설치 및 구성:

npm install next-intl

메시지 디렉토리 구조:

messages/
├── en.json
├── de.json
├── ja.json
├── ar.json
└── ... (30개 로케일 파일)

각 파일은 네임스페이스된 번역을 포함한다:

{
  "navigation": {
    "home": "Home",
    "about": "About Us",
    "services": "Services",
    "contact": "Contact"
  },
  "hero": {
    "title": "Enterprise Web Development",
    "subtitle": "Built for performance, designed for scale"
  }
}

3단계: 번역 파이프라인 구축

다음을 수행하는 스크립트를 만든다:

  1. 영어 소스 파일을 읽는다
  2. Claude API로 번역을 보낸다
  3. 출력 JSON 구조를 검증한다
  4. 로케일 파일을 작성한다
  5. 자동화된 품질 검사를 실행한다 (누락된 키, 깨진 보간 변수)

4단계: hreflang 및 SEO 구현

많은 다국어 구현이 이 부분에서 실패한다. 모든 페이지는 적절한 hreflang 태그가 필요하다:

// src/components/LocaleHead.tsx
export function LocaleHead({ currentLocale, path }: Props) {
  const locales = routing.locales;
  
  return (
    <>
      {locales.map((locale) => (
        <link
          key={locale}
          rel="alternate"
          hrefLang={locale}
          href={`https://example.com/${locale}${path}`}
        />
      ))}
      <link
        rel="alternate"
        hrefLang="x-default"
        href={`https://example.com${path}`}
      />
    </>
  );
}

5단계: RTL 언어 처리

아랍어, 히브리어, 또는 기타 RTL 언어(우리는 아랍어 지원)를 지원하는 경우, 방향성 CSS가 필요하다:

// src/app/[locale]/layout.tsx
export default function LocaleLayout({ children, params: { locale } }) {
  const direction = ['ar', 'he', 'fa'].includes(locale) ? 'rtl' : 'ltr';
  
  return (
    <html lang={locale} dir={direction}>
      <body className={direction === 'rtl' ? 'font-arabic' : 'font-sans'}>
        {children}
      </body>
    </html>
  );
}

Tailwind CSS v4는 기본적으로 rtl: 변형을 지원하므로, 방향 스타일이 관리 가능하다.

6단계: 배포 및 모니터링

Vercel에서 Next.js를 사용하면, 각 로케일의 페이지는 정적으로 생성되고 사용자에게 가장 가까운 엣지 노드에서 제공된다. 독일 사용자가 /de/dienstleistungen을 클릭하면 100ms 이내에 Frankfurt 엣지 노드에서 응답을 받는다. 데이터베이스 쿼리 없음. WPML 조회 없음. 정적 HTML만 있다.

마이그레이션 경로: WordPress에서 Headless 다국어로

현재 WordPress Multisite 및 WPML을 사용 중인 경우, 여러 클라이언트 프로젝트에서 개선한 마이그레이션 경로는 다음과 같다.

1-2주: 콘텐츠 내보내기 및 감사

  • WP REST API를 통해 모든 콘텐츠 내보내기(WPML 번역 포함)
  • 콘텐츠 유형을 Headless CMS 모델에 매핑
  • 고아 번역 및 콘텐츠 간격 식별
  • 301 리디렉션을 위해 모든 URL 패턴 문서화

2-4주: Headless CMS 설정 및 콘텐츠 임포트

  • 선택한 Headless CMS에서 콘텐츠 모델 구성
  • 영어 소스 콘텐츠 임포트
  • Supabase 번역 테이블 설정
  • 모든 대상 언어에 대해 AI 번역 파이프라인 실행

4-6주: 프론트엔드 구축

  • Next.js 애플리케이션을 next-intl로 구축
  • 모든 페이지 템플릿 구현
  • hreflang 태그 및 사이트맵 생성 구성
  • 새 콘텐츠를 위한 자동화된 번역 파이프라인 설정

6-8주: 테스트, 리디렉트, 출시

  • 크로스 브라우저 및 크로스 로케일 테스트
  • 이전 URL 패턴에서 301 리디렉트 구현
  • Google Search Console에 업데이트된 사이트맵 제출
  • 출시 후 인덱싱 및 트래픽 패턴 모니터링

전체 타임라인: 4-8주 (콘텐츠 볼륨 및 복잡성에 따라). 또한 유사한 패턴을 따르는 TYPO3에서 Next.js로의 마이그레이션도 처리했다.

비용 비교: WordPress Multisite vs. Headless 다국어

3년에 걸친 10개 언어 엔터프라이즈 사이트의 정직한 비용 분석:

비용 범주 WordPress Multisite + WPML Next.js + Headless + AI 번역
CMS 라이선싱 (3년) $0 (WP는 무료) $0-$540 (Sanity 프로) 또는 $0 (Payload OSS)
WPML 라이선싱 (3년) $597 $0
전문 번역 (초기) $50,000-$100,000 $220 (AI, 10개 언어 × $22)
번역 업데이트 (3년) $30,000-$60,000 $500 (예상 AI 비용)
호스팅 (3년) $3,600-$7,200 (관리형 WP) $0-$720 (Vercel 무료-프로 계층)
개발 (초기 구축) $30,000-$60,000 $40,000-$70,000
유지보수 (3년) $18,000-$36,000 $6,000-$12,000
총 3년 비용 $132,197-$263,797 $46,720-$83,460

Headless 접근 방식의 개발 비용은 초기에 약간 높다 — 플러그인을 구성하는 대신 사용자 정의 인프라를 구축하고 있다. 하지만 진행 중인 절감액은 극적이다. WPML 갱신 없음. 번역 기관 청구서 없음. Multisite 유지보수 문제 없음.

성능 벤치마크

우리의 프로덕션 다국어 사이트에서 Lighthouse 감사를 실행하고 동등한 WordPress Multisite + WPML 구현과 비교했다:

메트릭 WordPress + WPML Next.js + next-intl
LCP (Largest Contentful Paint) 2.8-4.2s 0.8-1.2s
FID (First Input Delay) 120-280ms 10-40ms
CLS (Cumulative Layout Shift) 0.12-0.25 0.01-0.05
Time to First Byte (TTFB) 800-1,400ms 50-150ms
Lighthouse 성능 점수 45-65 95-100
언어당 페이지 ~118 ~118
총 인덱싱된 페이지 ~1,180 (10개 언어) ~91,000+ (30개 언어)

TTFB 차이 자체만으로 마이그레이션할 가치가 있다. 페이지가 정적으로 생성되고 에지 CDN에서 제공되면, WordPress를 부팅하고, WPML을 로드하고, 데이터베이스를 쿼리하고, 번역을 해석하고, 템플릿을 렌더링하기 위해 기다릴 필요가 없다. HTML은 그냥... 있다.

Astro로 구축한 사이트의 경우, 숫자는 기본 제로 JavaScript 렌더링 덕분에 더욱 공격적이다.

자주 묻는 질문

엔터프라이즈 웹사이트에 AI 번역이 충분히 좋은가? 대부분의 기업 콘텐츠 — 예. 2026년에 Claude 및 GPT-4는 비즈니스 콘텐츠, 제품 설명, 문서에 대해 원어민이 전문 품질로 평가하는 번역을 생성한다. 우리는 일본어, 아랍어, 한국어, 중국어(단순화 및 번체 포함)를 포함한 30개 언어에서 AI 번역을 배포했으며, 원어민 검토자로부터 긍정적인 피드백을 받았다. 법적, 의료, 또는 매우 규제된 콘텐츠는 여전히 인간 검토의 이점이 있을 수 있지만, 그것도 순수 인간 번역보다 AI + 인간 검토가 훨씬 저렴하다.

Headless 다국어 사이트에 새로운 언어를 추가하는 비용은 얼마인가? 우리의 파이프라인으로, 새로운 언어를 추가하는 비용은 Claude API 토큰에 약 $22이고 엔지니어링 시간 약 45분이 든다. 이는 모든 페이지 콘텐츠, 탐색, 메타데이터, UI 문자열을 번역하는 비용이다. 이것을 WPML의 사이트당 라이선싱에 더하기 기업 사이트의 전문 번역 비용 $5,000-$10,000과 비교해보자.

다국어 사이트를 위한 가장 좋은 WordPress Multisite 대안은 무엇인가? 엔터프라이즈 배포의 경우, Headless CMS (Sanity, Payload, 또는 Strapi)와 Next.js 및 next-intl을 쌍으로 하면 가장 유연하고 성능이 좋은 아키텍처가 제공된다. 진정한 콘텐츠/프레젠테이션 분리, 에지 배포 페이지, 그리고 CMS와 독립적으로 번역을 관리할 수 있는 능력을 얻는다. 50개 페이지 이하의 더 간단한 사이트의 경우, 로컬화 기능이 있는 Webflow가 작동할 수 있지만, 엔터프라이즈 규모에서 빨리 제한에 도달할 것이다.

30+ 언어 버전에 대한 SEO를 어떻게 처리하는가? 모든 페이지는 모든 언어 변형을 가리키는 적절한 hreflang 태그와 x-default 태그를 생성한다. 우리는 로케일당 XML 사이트맵을 생성하고 Google Search Console에 제출한다. 각 로케일은 메타 제목, 설명, Open Graph 태그의 자신의 세트를 가지며 — 모두 AI 파이프라인을 통해 번역된다. Google은 우리의 30개 언어 변형에서 91,000페이지 이상을 인덱싱했다.

SEO 순위를 잃지 않고 WordPress Multisite에서 Headless로 마이그레이션할 수 있는가? 예, 하지만 신중한 계획이 필요하다. 중요한 단계는: 이전 URL에서 새 로케일 접두사 URL로의 포괄적인 301 리디렉트 매핑, 출시부터 적절한 hreflang 구현, 그리고 즉시 업데이트된 사이트맵 제출이다. 일반적으로 1-3주의 인덱싱 전환 기간을 보고, 그 다음 향상된 Core Web Vitals 점수로 인한 순위 개선을 본다. WordPress에서 Next.js로의 마이그레이션 프로세스는 이를 위해 특별히 설계되었다.

2026년에 가장 좋은 WPML 대안은 무엇인가? Next.js 애플리케이션을 위한 next-intl, 또는 Nuxt 애플리케이션을 위한 nuxt-i18n. 둘 다 로케일 라우팅, 메시지 포맷, SEO 메타데이터를 기본적으로 처리한다 — WordPress 플러그인의 성능 오버헤드 없이. WPML과 달리, 연간 라이선스 수수료가 없고, 데이터베이스 오버헤드가 없으며, 다른 플러그인과 호환성 문제가 없다. i18n 로직은 프레임워크 레이어에서 코드에 살고 — 속할 곳이다.

30개 언어에 걸쳐 번역 품질을 어떻게 관리하는가? 우리는 다층 접근 방식을 사용한다: AI 번역을 기본 계층으로, 자동화된 품질 검사 (JSON 구조 검증, 보간 변수 보존, 길이 비교), 그리고 높은 가시성 콘텐츠(홈페이지 헤드라인, CTA)에 대한 선택적 인간 검토. 우리는 또한 언어별 용어집을 유지하며, AI에 전달되어 브랜드 용어, 제품 이름, 기술 어휘를 일관되게 처리하도록 한다.

이 접근 방식이 자주 콘텐츠를 업데이트하는 사이트에 실행 가능한가? 절대 — 사실, WPML보다 더 낫다. 영어 페이지를 게시하거나 업데이트하면, 번역 파이프라인이 자동으로 웹훅을 통해 실행될 수 있다. 새로운 번역은 몇 분 내에 생성되고, ISR (Incremental Static Regeneration)과 함께 Next.js에서, 업데이트된 페이지는 전체 사이트 재빌드 없이 라이브로 간다. 우리는 매일 블로그 포스트를 게시하고 시간 내에 30개 언어로 나타나고, 같은 날 검색 엔진으로 완전히 인덱싱되는 클라이언트들이 있다.