Movable Type에서 Next.js로의 마이그레이션: 일본 기업을 위한 가이드

Japanese 기업 웹사이트를 다뤄본 경험이 있다면, Movable Type을 거의 확실히 접했을 것입니다. Six Apart의 CMS는 2000년대 중반부터 일본 시장을 강하게 장악하고 있으며, 대형 제조업체의 기업 사이트부터 정부 포털, 대학 웹사이트까지 모든 것을 지원하고 있습니다. 하지만 현실은 이렇습니다 -- 2026년이고, 웹은 훨씬 앞으로 나아갔습니다. 당신의 Movable Type 설치는 아마 그렇지 못했을 것입니다.

지난 2년간 여러 일본 기업 사이트를 Movable Type에서 벗어나도록 도왔고, 솔직히 말해서: 이것은 간단한 프로젝트가 아닙니다. 문자 인코딩의 독특함, 일본 기업 사이트만의 콘텐츠 구조, 그리고 일반적인 WordPress에서 Next.js로의 마이그레이션과 다른 조직 문제들이 있습니다. 이 가이드는 제가 어렵게 배운 모든 것을 다룹니다.

Movable Type to Next.js Migration Guide for Japanese Companies

일본 기업이 Movable Type을 떠나는 이유
Movable Type 아키텍처 이해
헤드리스 CMS 백엔드 선택
콘텐츠 감사 및 데이터 추출
일본 콘텐츠 특성 처리
Next.js 프론트엔드 구축
일본 검색을 위한 SEO 마이그레이션 전략
배포 및 인프라
타임라인 및 예산 계획
FAQ

일본 기업이 Movable Type을 떠나는 이유

명백한 것부터 시작하겠습니다: Movable Type은 죽지 않았습니다. Six Apart Japan은 여전히 유지 보수하고 있으며, 2024년 말에 출시된 Movable Type 8은 일부 현대적 기능을 추가했습니다. 하지만 여러 이유로 기울어진 상황입니다.

성능 문제

Movable Type은 정적 발행 모델을 사용합니다 -- 콘텐츠가 변경될 때 HTML 파일을 다시 빌드합니다. 이것은 사이트에 15,000페이지가 있고 콘텐츠 편집자가 리빌드 완료를 기다리며 20분을 소비할 때까지는 좋아 보입니다. 저는 편집자들이 프로세스가 너무 느려서 재구축을 밤사이에 예약하는 일본 기업 사이트를 본 적이 있습니다.

ISR(증분 정적 재생성) 또는 온디맨드 재검증을 사용하는 Next.js는 이를 완전히 해결합니다. 페이지는 개별적으로 밀리초 단위로 재생성됩니다.

소유 비용

2026년 기준으로 일본의 Movable Type 라이선싱은 엔터프라이즈 라이선스 기준으로 연간 약 ¥600,000-¥1,200,000입니다. 이는 호스팅, 플러그인 또는 커스텀 개발 전에 단순히 CMS 라이선스만으로 연간 약 $4,000-$8,000 USD입니다. microCMS(일본에서 인기 있으며, 비즈니스 플랜부터 월 ¥4,900)와 Vercel의 Next.js를 페어링하는 것과 비교하면, 수학이 매우 달라집니다.

개발자 부족

이것이 공개적으로 아무도 이야기하지 않는 큰 문제입니다. Perl(Movable Type의 언어)을 알고 MT 템플릿에서 작업하려는 개발자를 찾는 것이 정말 어려워지고 있습니다. 제가 만난 MT 경험 개발자의 평균 나이는 45세 이상입니다. 한편, Next.js 개발자는 어디에나 있습니다 -- 2026년 일본 기술 회사가 채용하는 프레임워크입니다.

보안 및 규정 준수

Movable Type은 적극적으로 일본 사이트를 공격받은 악명 높은 XMLRPC 취약점(CVE-2021-20837)을 포함하여 수년 동안 여러 심각한 CVE를 가지고 있었습니다. 2025-2026년에 강화되는 일본의 개정된 APPI(개인정보 보호법) 요구사항으로, 기업들은 자신의 보안 태세를 재평가하고 있습니다.

Movable Type 아키텍처 이해

마이그레이션하기 전에, 마이그레이션할 대상을 이해해야 합니다. Movable Type의 데이터 모델은 WordPress나 대부분의 현대 CMS와 다릅니다.

핵심 데이터 구조

MT 개념	설명	Next.js/헤드리스 동등물
Blog	최상위 콘텐츠 컨테이너	사이트 또는 워크스페이스
Entry	블로그 게시물 또는 아티클	콘텐츠 항목 (블로그 타입)
Page	정적 페이지	콘텐츠 항목 (페이지 타입)
Category	계층 분류법	카테고리/태그 시스템
Template	MT 태그가 있는 HTML 템플릿	React 컴포넌트 + 레이아웃
Custom Field	확장된 항목 필드	콘텐츠 모델 필드
Asset	업로드된 미디어 파일	미디어/자산 라이브러리
Website	블로그를 위한 상위 컨테이너	다중 사이트 구성

Movable Type의 템플릿 언어는 <mt:EntryTitle> 및 <mt:Entries>와 같은 태그를 사용합니다. 이것들은 현대 스택의 어떤 것과도 1:1로 매핑되지 않습니다 -- 프레젠테이션 레이어를 처음부터 재구축하게 됩니다.

데이터베이스 레이어

MT는 MySQL, PostgreSQL 및 SQLite를 지원합니다. 대부분의 일본 엔터프라이즈 설치는 MySQL을 사용합니다. 데이터베이스 스키마는 잘 문서화되어 있지만... 이상합니다. 사용자 정의 필드는 키-값 패턴을 사용하는 별도의 mt_entry_meta 테이블에 저장되므로 추출이 간단하지 않습니다.

항목 테이블의 모습입니다:

SELECT 
  entry_id,
  entry_title,
  entry_text,
  entry_text_more,
  entry_excerpt,
  entry_created_on,
  entry_modified_on,
  entry_basename,
  entry_status
FROM mt_entry
WHERE entry_blog_id = 1
  AND entry_status = 2  -- 2 = published
ORDER BY entry_created_on DESC;

entry_text와 entry_text_more 분할에 주목합니다. MT는 본문 콘텐츠를 두 필드로 나눕니다 -- 초기 블로깅 시대의 패턴으로, 마이그레이션 중에 연결해야 합니다.

Movable Type to Next.js Migration Guide for Japanese Companies - architecture

헤드리스 CMS 백엔드 선택

Next.js는 프론트엔드 프레임워크입니다. 하지만 콘텐츠를 관리할 곳이 필요합니다. 일본 회사의 경우, 저는 이것을 4가지 현실적인 옵션으로 좁혔습니다.

microCMS

일본 기업의 기본 선택이며, 이유가 있습니다. 일본 회사에서 만들었으며, 일본어 UI 기본 지원, 일본어 고객 지원, 일본 내 데이터 레지던시를 가지고 있습니다. 가격은 월 ¥4,900부터 시작합니다 (Hobby는 소규모 프로젝트의 경우 무료입니다). API는 깔끔하고, 웹훅 지원은 Next.js ISR과 잘 작동하며, 콘텐츠 편집자는 영어 실력이 필요하지 않습니다.

Newt

일본 회사가 만든 또 다른 헤드리스 CMS로 최근 인기를 얻고 있습니다. microCMS보다 약간 더 개발자 친화적이며 콘텐츠 모델링 유연성이 더 좋습니다. 사이트의 복잡한 콘텐츠 구조가 있는 경우 좋은 옵션입니다.

Contentful

전 세계 엔터프라이즈 선택입니다. 강력한 로컬라이제이션 지원, 우수한 API, 성숙한 생태계를 가지고 있습니다. 일본 기업의 단점: 지원은 영어이고, UI는 영어이며, 가격은 USD입니다. 2026년 가격 기준 Team 플랜 $300/월에서 일본의 대안보다 훨씬 비쌉니다.

Sanity

Sanity를 언급하는 이유는 기술적으로 우수하고, 커스터마이징 가능한 Studio를 일본어 라벨로 구성할 수 있기 때문입니다. 하지만 학습 곡선이 더 가파르고, Sanity 경험이 있는 일본 개발자를 찾기 어렵습니다.

CMS	일본어 UI	일본 데이터 레지던시	시작 가격	최적 용도
microCMS	✅	✅	¥4,900/월	대부분의 일본 기업 사이트
Newt	✅	✅	¥3,300/월	복잡한 콘텐츠 모델
Contentful	❌	❌ (EU/US)	~$300/월	글로벌 엔터프라이즈
Sanity	부분	❌	$99/월 (Team)	개발자 중심 팀

Movable Type에서 마이그레이션하는 대부분의 일본 회사의 경우, 저는 microCMS 또는 Newt를 권장합니다. 모든 것이 일본어인 마찰력 감소는 생각할 수 있는 것보다 가치가 있습니다. 우리는 헤드리스 CMS 개발 사례를 통해 이 모든 것을 광범위하게 작업했습니다.

콘텐츠 감사 및 데이터 추출

여기가 실제 작업이 시작되는 곳입니다. 감사 단계를 건너뛰지 마십시오 -- 감사 없이 추출로 바로 뛰어든 마이그레이션 실패를 본 적이 있습니다.

단계 1: 모든 것을 인벤토리합니다

MT 데이터베이스에 연결하고 카운트를 실행합니다:

-- 블로그별 항목 수 계산
SELECT 
  b.blog_name,
  COUNT(e.entry_id) as entry_count
FROM mt_entry e
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
WHERE e.entry_status = 2
GROUP BY b.blog_name;

-- 블로그별 사용자 정의 필드 수 계산
SELECT 
  b.blog_name,
  em.entry_meta_type,
  COUNT(*) as field_count
FROM mt_entry_meta em
JOIN mt_entry e ON em.entry_meta_entry_id = e.entry_id
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
GROUP BY b.blog_name, em.entry_meta_type;

단계 2: 콘텐츠 내보내기

MT는 기본 제공 내보내기 형식을 가지고 있지만 제한적입니다. 저는 Python 스크립트로 직접 데이터베이스 추출을 선호합니다:

import mysql.connector
import json
import html

def extract_mt_entries(config):
    conn = mysql.connector.connect(**config)
    cursor = conn.cursor(dictionary=True)
    
    cursor.execute("""
        SELECT 
            e.entry_id,
            e.entry_title,
            e.entry_text,
            e.entry_text_more,
            e.entry_excerpt,
            e.entry_basename,
            e.entry_created_on,
            e.entry_modified_on,
            GROUP_CONCAT(c.category_label) as categories
        FROM mt_entry e
        LEFT JOIN mt_placement p ON e.entry_id = p.placement_entry_id
        LEFT JOIN mt_category c ON p.placement_category_id = c.category_id
        WHERE e.entry_status = 2
        GROUP BY e.entry_id
    """)
    
    entries = cursor.fetchall()
    
    for entry in entries:
        # 텍스트와 text_more 결합
        body = (entry['entry_text'] or '') + (entry['entry_text_more'] or '')
        entry['full_body'] = body
        # 인코딩 처리
        entry['entry_title'] = entry['entry_title']
    
    with open('mt_export.json', 'w', encoding='utf-8') as f:
        json.dump(entries, f, ensure_ascii=False, default=str, indent=2)
    
    return entries

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

MT는 일반적으로 /path/to/mt/support/uploads/ 아래의 파일시스템에 자산을 저장합니다. 다음을 수행해야 합니다:

모든 파일을 인벤토리하고 mt_asset의 데이터베이스 레코드와 일치시키기
새 CMS 또는 CDN(Cloudinary, imgix, 또는 CMS의 기본 제공 스토리지)에 재업로드
콘텐츠 본문 HTML의 모든 참조 업데이트

이것은 지루합니다. 시간을 예산으로 책정하세요.

일본 콘텐츠 특성 처리

이 섹션이 제가 이 글을 쓴 이유입니다. 일반 마이그레이션 가이드는 이러한 문제를 다루지 않습니다.

문자 인코딩

이전 Movable Type 설치(MT5 전)는 때때로 데이터베이스가 명목상 UTF-8이어도 EUC-JP 또는 Shift_JIS 인코딩으로 콘텐츠를 저장했습니다. 실제 데이터를 확인하세요:

# 인코딩 문제 감지
import chardet

def check_encoding(text_bytes):
    result = chardet.detect(text_bytes)
    if result['encoding'] != 'utf-8':
        print(f"경고: 검출된 {result['encoding']} "
              f"{result['confidence']:.0%} 신뢰도 포함")
    return result

인코딩 불일치를 발견하면, 새 CMS로 가져오기 전에 모든 것을 UTF-8로 변환하세요. 기업 사이트의 깨진 문자화け (文字化け)은 경력 제한 이벤트입니다.

루비 텍스트 (Furigana)

일본 기업 사이트는 자주 루비 주석을 사용합니다 -- 한자 문자 위의 작은 읽기 보조. MT 템플릿은 종종 사용자 정의 태그를 사용하여 이를 처리합니다. Next.js에서는 표준 HTML <ruby> 요소를 사용합니다:

// components/RubyText.tsx
export function RubyText({ base, reading }: { base: string; reading: string }) {
  return (
    <ruby>
      {base}
      <rp>(</rp>
      <rt>{reading}</rt>
      <rp>)</rp>
    </ruby>
  );
}

콘텐츠 마이그레이션 스크립트가 기존 루비 마크업을 보존하도록 하세요.

일본 날짜 형식

일본 기업 사이트는 종종 日本 시대 형식(和暦)으로 날짜를 표시합니다: 령和8年1月15日 대신 2026-01-15. Next.js 컴포넌트에서 이를 처리합니다:

function formatJapaneseDate(dateString: string): string {
  const date = new Date(dateString);
  return date.toLocaleDateString('ja-JP-u-ca-japanese', {
    era: 'long',
    year: 'numeric',
    month: 'long',
    day: 'numeric',
  });
}

세로 텍스트 레이아웃

일부 일본 사이트, 특히 출판이나 전통 산업에서는 세로 텍스트(縦書き)를 사용합니다. CSS가 이를 처리합니다:

.vertical-text {
  writing-mode: vertical-rl;
  text-orientation: mixed;
}

Next.js는 이를 잘 처리하지만, 브라우저 전체에서 철저히 테스트하세요.

Next.js 프론트엔드 구축

콘텐츠를 추출하고 CMS를 선택했으므로, 이제 구축할 시간입니다. 여기는 일본 기업 사이트에 권장하는 아키텍처입니다.

정적 생성을 사용한 App Router

Next.js 15의 App Router를 사용하여 온디맨드 재검증을 통해 대부분의 페이지에 대해 정적 생성을 사용합니다. 일본 기업 사이트는 일반적으로 콘텐츠가 많고 업데이트가 드뭅니다 -- 정적 생성과 온디맨드 재검증에 완벽합니다.

// app/news/[slug]/page.tsx
import { getArticle, getAllArticleSlugs } from '@/lib/cms';

export async function generateStaticParams() {
  const slugs = await getAllArticleSlugs();
  return slugs.map((slug) => ({ slug }));
}

export default async function NewsArticle({ 
  params 
}: { 
  params: Promise<{ slug: string }> 
}) {
  const { slug } = await params;
  const article = await getArticle(slug);
  
  return (
    <article>
      <h1>{article.title}</h1>
      <time dateTime={article.publishedAt}>
        {formatJapaneseDate(article.publishedAt)}
      </time>
      <div dangerouslySetInnerHTML={{ __html: article.body }} />
    </article>
  );
}

i18n 구성

많은 일본 기업 사이트는 일본어 및 영어 버전을 모두 필요로 합니다. Next.js App Router는 경로 그룹 또는 미들웨어 기반 로케일 감지로 이를 처리합니다:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const pathname = request.nextUrl.pathname;
  const locale = pathname.startsWith('/en') ? 'en' : 'ja';
  
  request.headers.set('x-locale', locale);
  return NextResponse.next();
}

우리는 Next.js를 사용하여 수십 개의 이중 언어 일본 기업 사이트를 구축했습니다 -- 우리의 Next.js 개발 팀이 뉘앙스를 통해 당신을 안내할 수 있습니다.

일본 검색을 위한 SEO 마이그레이션 전략

이것은 협상 불가능합니다. 일본 기업은 Google 검색 순위에 의해 생존과 죽음을 합니다 (Yahoo! Japan은 2010년부터 Google의 검색 엔진을 사용했으므로, 실제로는 단지 Google입니다). 실패한 마이그레이션은 유기 트래픽을 몇 개월 동안 떨어뜨릴 수 있습니다.

URL 매핑

Movable Type은 구성 가능한 패턴으로 URL을 생성합니다. 일본 사이트에서 본 일반적인 것들:

/blog/2024/01/entry-basename.html
/news/category/entry_basename.html
/archives/000123.html (가장 오래된 패턴)

무엇이든 구축하기 전에 완전한 URL 매핑을 생성하세요:

// scripts/generate-redirects.ts
interface RedirectMap {
  source: string;
  destination: string;
  permanent: boolean;
}

function generateRedirects(mtEntries: MTEntry[]): RedirectMap[] {
  return mtEntries.map(entry => ({
    source: buildMTUrl(entry),  // 이전 MT URL 패턴
    destination: `/news/${entry.entry_basename}`,  // 새로운 Next.js URL
    permanent: true,  // 301 리다이렉트
  }));
}

이것을 next.config.ts에 넣으세요:

const nextConfig = {
  async redirects() {
    const redirects = await import('./redirects.json');
    return redirects.default;
  },
};

수천 개의 리다이렉트가 있는 사이트의 경우, 대신 미들웨어를 사용하세요 -- next.config.ts 리다이렉트는 실용적인 한계가 있습니다.

구조화된 데이터

일본 Google 결과는 리치 스니펫을 많이 특징으로 합니다. 아티클, FAQ 및 조직 정보에 JSON-LD를 추가하세요:

function ArticleJsonLd({ article }: { article: Article }) {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: article.title,
    datePublished: article.publishedAt,
    dateModified: article.updatedAt,
    author: {
      '@type': 'Organization',
      name: article.companyName,
    },
    inLanguage: 'ja',
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
    />
  );
}

배포 및 인프라

일본 관중에게 레이턴시는 중요합니다. 작동하는 것:

플랫폼	일본 엣지 노드	최적 용도	월별 비용 (일반)
Vercel	Tokyo	대부분의 Next.js 사이트	$20-150/월
AWS (CloudFront + Lambda@Edge)	Tokyo, Osaka	엔터프라이즈 규정 준수	$100-500/월
Google Cloud Run + Cloud CDN	Tokyo	GCP-네이티브 팀	$50-200/월
Cloudflare Pages	Tokyo + 많음	간단한 정적 사이트	Free-$25/월

Vercel은 저의 기본 권장사항입니다. Next.js를 위해 특수하게 제작되었고, Tokyo 엣지 노드를 가지고 있으며, DX는 비교할 수 없습니다. 엄격한 데이터 레지던시 요구사항(정부, 금융)이 있는 회사의 경우, ap-northeast-1 (Tokyo)의 AWS가 안전한 선택입니다.

최소한의 상호작용이 있는 콘텐츠가 많은 사이트에 대해 Next.js 대신 Astro를 고려하고 있다면, 그것은 유효한 선택입니다 -- 우리의 Astro 개발 기능을 확인하세요.

타임라인 및 예산 계획

완료한 실제 마이그레이션을 기반으로, 예상할 수 있는 것입니다:

단계	기간	주요 활동
발견 및 감사	2-3주	콘텐츠 인벤토리, 이해관계자 면접, URL 매핑
CMS 설정 및 콘텐츠 모델링	2-4주	스키마 설계, 콘텐츠 마이그레이션 스크립트
콘텐츠 마이그레이션	3-6주	데이터 전송, 미디어 마이그레이션, QA
프론트엔드 개발	6-10주	Next.js 구축, 컴포넌트 라이브러리, i18n
SEO 및 QA	2-3주	리다이렉트 테스트, 성능 튜닝, 교차 브라우저 QA
단계적 롤아웃	1-2주	DNS 전환, 모니터링, 핫픽스

총계: 1,000-10,000페이지가 있는 일반적인 일본 기업 사이트의 경우 16-28주.

예산 측면에서, 복잡도에 따라 ¥5,000,000-¥15,000,000 ($33,000-$100,000 USD)을 살펴볼 수 있습니다. 많은 것처럼 보일지 모르지만, 고려하세요: 당신은 이미 MT 라이선싱 및 전문화된 개발을 위해 연간 ¥1,000,000 이상을 지불할 가능성이 높습니다. 마이그레이션은 감소된 운영 비용과 향상된 개발자 속도를 통해 2-3년 내에 자체 자금을 조달합니다.

당신의 특정 상황에 대한 자세한 견적이 필요하신가요? 우리에게 연락하세요 또는 참여 모델에 대해 가격 책정 페이지를 확인하세요.

FAQ

Movable Type을 Next.js와 함께 헤드리스 CMS로 계속 사용할 수 있습니까?

기술적으로 네 -- Movable Type 7+는 프론트엔드에 콘텐츠를 제공할 수 있는 Data API가 있습니다. 하지만 느리고, 문서가 거의 없으며, 재검증을 위한 웹훅이 없습니다. 저는 한 프로젝트에서 이 접근 방식을 시도했고 이를 권장하지 않습니다. MT의 API 제한을 해결하는 데 적절한 헤드리스 CMS로 마이그레이션하는 것보다 더 많은 시간을 보낼 것입니다.

MT 리빌드 모델을 Next.js ISR과 어떻게 처리합니까?

그들은 근본적으로 다릅니다. MT는 한 번에 전체 사이트 섹션을 다시 빌드합니다 (배치 정적 생성). Next.js ISR은 개별 페이지를 온디맨드로 재생성합니다. 이것은 편집자가 리빌드를 기다리는 대신 즉시 발행 시간을 얻음을 의미합니다. 정신 모델 전환은 실제로 편집자에게 더 쉽습니다 -- 그들은 단순히 발행을 누르고 페이지는 몇 초 내에 라이브됩니다.

마이그레이션 중 MT 플러그인은 어떻게 됩니까?

모든 MT 플러그인은 교체 또는 재구현이 필요합니다. contact 양식과 같은 일반적인 것들 (MT 기반 양식 플러그인)은 Next.js 양식 처리 또는 Formspree와 같은 서비스로 교체됩니다. 검색 플러그인은 Algolia 또는 CMS의 기본 제공 검색으로 교체됩니다. 감사 단계에서 전체 플러그인 인벤토리를 만드세요.

마이그레이션 중 Google 순위가 떨어집니까?

그럴 수 있지만, 그럴 필요는 없습니다. 중요한 요소는: 모든 URL에 대한 301 리다이렉트, 동일하거나 개선된 페이지 제목 및 메타 설명 유지, 내부 링크 구조 보존, 업데이트된 사이트맵 제출입니다. 저는 순위가 실제로 개선된 마이그레이션을 봤습니다. 새로운 사이트가 더 빠르고 Core Web Vitals 점수가 더 좋았기 때문입니다.

일본 SEO 관련 요소인 Yahoo! Japan을 어떻게 처리합니까?

Yahoo! Japan은 2010년부터 Google의 검색 엔진을 사용했으므로, Google SEO 전략이 Yahoo!도 다룹니다. 유일한 예외는 Yahoo! Japan 자신의 속성(Yahoo! News 등)인데, 이들은 별도의 제출 프로세스가 있습니다. 일반 유기 검색의 경우, Google에 집중하면 당신은 모두 다룹니다.

모든 콘텐츠를 마이그레이션하거나 이를 정리할 기회로 사용해야 합니까?

항상 정리하세요. 완료한 모든 일본 기업 사이트 마이그레이션에서 콘텐츠의 30-50%는 오래되었거나 중복되거나 트래픽이 0이었습니다. 죽은 콘텐츠를 마이그레이션하는 것은 시간을 낭비하고 당신의 사이트의 주제 권위를 약화시킵니다. 분석 데이터를 사용하여 마이그레이션할 가치가 있는 페이지를 식별하고 나머지는 놔두세요 (404가 아닌 410 Gone 응답으로).

마이그레이션 중 Movable Type과 Next.js를 병렬로 실행할 수 있습니까?

네, 권장합니다. 마이그레이션된 섹션에 대해 새 Next.js 사이트를 제공하기 위해 서브도메인 또는 경로 기반 라우팅을 사용하고, MT이 나머지를 처리합니다. 이렇게 하면 위험한 빅뱅 전환을 하는 대신 단계적으로 마이그레이션할 수 있습니다. nginx 또는 Cloudflare Workers의 역 프록시 구성이 이를 간단하게 만듭니다.

Movable Type의 기본 제공 접근 제어 및 회원 기능은 어떻게 됩니까?

MT 사이트가 회원 로그인, 게이트된 콘텐츠 또는 역할 기반 접근을 사용한다면, Next.js에서 인증을 구현해야 합니다. NextAuth.js (이제 Auth.js)는 이에 대해 잘 작동하거나, Clerk 또는 Auth0과 같은 서비스를 사용할 수 있습니다. 이것은 복잡도와 비용을 추가합니다 -- 첫 날부터 계획에 포함하세요.