EC-CUBE에서 Shopify + Next.js로 마이그레이션: 일본 이커머스 가이드 2026

EC-CUBE에서 일본 온라인 스토어를 운영하고 있으며 자체 호스팅된 PHP 모놀리식 유지보수의 어려움을 느끼고 있다면, 혼자가 아닙니다. 저희는 지난 2년간 EC-CUBE(버전 2.x, 3.x, 4.x)에서 Next.js로 구축한 헤드리스 Shopify 스토어프론트로 여러 일본 전자상거래 회사를 마이그레이션하는 것을 도와왔습니다. 마이그레이션 후 모두가 같은 말을 했습니다: "우리는 이렇게 해야 했어."

하지만 여기가 중요한 부분입니다 -- 이 마이그레이션은 진정으로 복잡합니다. EC-CUBE는 일본 전자상거래 문화에 깊은 뿌리를 가지고 있습니다. 주소의 후리가나 필드, 일본 결제 방법(편의점 결제, 캐리어 청구, Pay-easy를 통한 은행 송금), 일본 우편 지역을 기반으로 하는 배송 계산과 같은 것들을 처리합니다. 단순히 스위치를 넘기고 Shopify로 이동할 수 없습니다. 전략이 필요합니다.

이 가이드는 2024년 저희가 처음으로 EC-CUBE 마이그레이션을 수행했을 때 있었으면 좋았을 전략 문서입니다.

목차

• 2026년에 EC-CUBE에서 마이그레이션해야 하는 이유
• EC-CUBE 아키텍처 이해하기
• 일본 전자상거래를 위한 Shopify Plus + Next.js
• 마이그레이션 전 감사 및 계획
• 데이터 마이그레이션 전략
• 일본 결제 방법 처리
• 배송 및 이행 매핑
• Next.js 스토어프론트 구축
• SEO 마이그레이션 및 URL 보존
• 일본 특화 UX 고려 사항
• 성능 벤치마크: EC-CUBE vs 헤드리스 Shopify
• 일정 및 비용 예상
• FAQ

2026년에 EC-CUBE에서 마이그레이션해야 하는 이유

EC-CUBE는 거의 20년 동안 일본 전자상거래의 중추였습니다. Lockon Co., Ltd.(현 EC-CUBE Co., Ltd.)가 개발했으며, 옵션이 제한적이었을 때 일본 시장을 지배했습니다. 하지만 환경은 극적으로 변했습니다.

비즈니스를 밀어내고 있는 것들을 살펴보겠습니다:

보안 유지보수는 악몽입니다. EC-CUBE 2.x는 몇 년 전에 수명이 끝났지만, 놀랍게도 많은 스토어가 여전히 이를 실행하고 있습니다. EC-CUBE 4.x 마저도 지속적인 패치가 필요합니다. 2024년 한 해만 해도 SQL 주입 취약점(CVE-2024-22345)을 포함하여 EC-CUBE 4에 대한 3가지 중요 보안 공지가 있었고, 이는 수천 개의 스토어에 영향을 미쳤습니다. 자체 호스팅을 하고 있다면, 그것은 당신이 해결해야 할 문제입니다.

PHP 호스팅 비용은 계속 올라갑니다. EC-CUBE를 일본의 VPS 또는 전용 서버(일반적으로 Sakura Internet, XSERVER 또는 AWS 도쿄)에서 실행하려면 인프라, SSL 인증서, 데이터베이스 유지보수 및 서버 모니터링 비용을 지불해야 합니다. 일반적인 중견 EC-CUBE 스토어는 호스팅 및 유지보수에만 월 ¥50,000–¥200,000을 소비합니다.

플러그인 생태계가 축소되고 있습니다. EC-CUBE 플러그인 마켓플레이스는 개발자를 잃고 있습니다. 많은 인기 있는 결제 및 배송 플러그인이 EC-CUBE 4.2+ 업데이트되지 않았습니다. 스토어가 타사 플러그인에 의존한다면, 업그레이드 경로가 없는 이전 버전에 고착될 수 있습니다.

모바일 성능이 좋지 않습니다. 대부분의 EC-CUBE 테마는 반응형이지만 무거운 시대에 설계되었습니다. 저희가 감사한 EC-CUBE 스토어의 평균 Lighthouse 점수는 모바일에서 25-40을 맴돕니다. Core Web Vitals이 일본에서 Google 순위에 직접 영향을 미칠 때 이것은 작동하지 않습니다.

EC-CUBE 아키텍처 이해하기

마이그레이션하기 전에, 마이그레이션할 대상을 이해해야 합니다. EC-CUBE의 아키텍처는 버전에 따라 크게 다릅니다:

기능	EC-CUBE 2.x	EC-CUBE 3.x	EC-CUBE 4.x
프레임워크	사용자 정의 PHP	Silex (Symfony 마이크로)	Symfony 4/5
데이터베이스	PostgreSQL/MySQL	PostgreSQL/MySQL	PostgreSQL/MySQL
템플릿 엔진	Smarty	Twig	Twig
플러그인 아키텍처	훅/오버라이드	이벤트 기반	Symfony 번들
ORM	사용자 정의	Doctrine	Doctrine
API	없음 (사용자 정의 빌드)	제한된 REST	REST + 제한된 GraphQL

데이터베이스 스키마는 흥미롭고 고통스러운 부분입니다. EC-CUBE는 정규화되었지만 EC-CUBE 특정 스키마에 제품 데이터, 고객 데이터 및 주문 이력을 저장합니다. dtb_product, dtb_product_class, dtb_customer 및 dtb_order 테이블이 핵심입니다.

EC-CUBE 4.x는 Doctrine 엔터티를 사용하므로 데이터 추출이 약간 더 간단합니다. 하지만 2.x에 있다면 인코딩 문제가 있는 원시 SQL 내보내기를 준비하세요 (Shift-JIS 또는 EUC-JP 레거시 데이터가 여전히 일반적입니다).

일본 전자상거래를 위한 Shopify Plus + Next.js

저는 투명하게 말하고 싶습니다: Shopify가 유일한 옵션은 아닙니다. commercetools, Medusa 또는 BASE나 STORES.jp와 같은 최신 일본 플랫폼으로 마이그레이션할 수 있습니다. 하지만 중견 규모의 일본 전자상거래 운영의 경우, 헤드리스 Next.js 프론트엔드와 결합된 Shopify Plus는 최적의 지점을 제공합니다.

Shopify의 일본 현지화가 성숙했습니다. 도쿄 사무소 개설 이후 완전한 일본어 지원을 출시한 이후, Shopify는 대부분의 일본 특화 격차를 해결했습니다. Shopify Payments는 이제 JCB 카드를 기본적으로 지원합니다. 관리 인터페이스는 완전히 현지화되었습니다. 그리고 중요하게도, Shopify Plus는 식음료에 대한 경감세율 시스템을 포함한 일본 세금 계산을 지원합니다.

Next.js는 성능 우위를 제공합니다. Next.js(Shopify Storefront API 또는 Hydrogen의 기본 데이터 계층 사용)로 구축한 헤드리스 스토어프론트를 사용하면 엣지에서 정적 및 서버 렌더링 페이지를 제공할 수 있습니다. 저희는 Next.js Shopify 빌드에서 모바일에 대해 90+ 이상의 Lighthouse 성능 점수를 일반적으로 보입니다. 이는 EC-CUBE의 전형적인 30-something 점수에서 엄청난 도약입니다.

Storefront API는 복잡성을 처리합니다. Shopify의 Storefront API(이 작성 당시 버전 2025-04)는 메타필드, 현지화된 콘텐츠, 다중 통화 및 사용자 정의 제품 옵션을 지원합니다 -- EC-CUBE의 유연성을 복제하는 데 필요한 모든 것입니다.

Next.js 기반 헤드리스 아키텍처가 특정 스토어에 합리적인지 평가하는 경우, 답은 거의 항상 카탈로그 크기와 사용자 정의 요구로 귀결됩니다. 100개 이하의 제품으로 간단한 변형? 표준 Shopify 테마가 괜찮을 수 있습니다. 복잡한 제품 구성, 대규모 사용자 정의 또는 여러 스토어프론트? 헤드리스로 이동하세요.

마이그레이션 전 감사 및 계획

코드 한 줄을 건드리기 전에 이 감사를 완료하세요:

1. 카탈로그 복잡성 매핑

EC-CUBE 스토어의 모든 제품 유형, 변형 구조 및 사용자 정의 필드를 문서화하세요. EC-CUBE의 dtb_product_class 테이블은 Shopify의 변형 모델과 1:1로 매핑되지 않는 복잡한 변형 조합을 보유할 수 있습니다 (제품당 100개 변형 제한 및 3개 옵션 제한).

제품에 3개 이상의 옵션 유형(예: 사이즈, 색상, 재료, 각인)이 있는 경우, Shopify의 결합 리스팅 기능(2024년 출시) 또는 메타필드와 라인 아이템 속성을 사용한 제품 아키텍처 재구성을 사용해야 합니다.

2. 고객 데이터 인벤토리

EC-CUBE는 다음을 포함한 풍부한 고객 데이터를 저장합니다:

• 姓名 (성씨 / 이름, 별도 필드)
• フリガナ (이름의 후리가나)
• 郵便番号 (우편번호 및 자동 주소 채우기)
• 고객당 여러 배송 주소
• 포인트 잔액 (ポイント)
• 상세 주문 상태 추적이 있는 구매 이력

Shopify의 고객 모델은 이름 필드와 여러 주소를 기본적으로 처리합니다. 하지만 포인트/로열티 프로그램은 Smile.io와 같은 타사 솔루션이나 사용자 정의 메타필드 기반 시스템이 필요합니다.

3. 통합 인벤토리

EC-CUBE 스토어가 연결되는 모든 외부 시스템을 나열하세요:

• 결제 게이트웨이 (GMO Payment Gateway, SB Payment Service, PAY.JP)
• 배송 API (Yamato Transport, Sagawa Express, Japan Post)
• 회계 소프트웨어 (弥生会計, freee, MoneyForward)
• 재고/ERP 시스템
• 이메일 마케팅 (Mailchimp, SendGrid 또는 Benchmark Email과 같은 일본 서비스)

4. URL 구조 문서화

EC-CUBE 스토어에서 모든 URL을 내보내세요. 이것은 SEO 마이그레이션에 중요합니다. EC-CUBE의 기본 URL 패턴은 다음과 같습니다:

/products/detail/{product_id}
/products/list?category_id={id}
/mypage/
/cart/

모든 이것들에 대해 리다이렉트 맵이 필요할 것입니다.

데이터 마이그레이션 전략

저희가 사용하는 마이그레이션 파이프라인은 다음과 같습니다:

제품 데이터 내보내기

EC-CUBE 4.x의 경우, Doctrine의 CLI 도구를 사용하거나 제품을 JSON으로 내보내는 Symfony 명령을 작성할 수 있습니다:

// EC-CUBE 4.x 제품 내보내기 명령
$products = $this->productRepository->findAll();
$exportData = [];

foreach ($products as $product) {
    $variants = [];
    foreach ($product->getProductClasses() as $class) {
        $variants[] = [
            'sku' => $class->getCode(),
            'price' => $class->getPrice02IncTax(),
            'stock' => $class->getStock(),
            'class_category1' => $class->getClassCategory1()?->getName(),
            'class_category2' => $class->getClassCategory2()?->getName(),
        ];
    }
    
    $exportData[] = [
        'id' => $product->getId(),
        'name' => $product->getName(),
        'description' => $product->getDescriptionDetail(),
        'variants' => $variants,
        'images' => array_map(fn($img) => $img->getFileName(), $product->getProductImages()->toArray()),
    ];
}

EC-CUBE 2.x의 경우, 원시 SQL을 보고 있습니다:

SELECT 
    p.product_id,
    p.name,
    p.main_comment,
    pc.product_code,
    pc.price02,
    pc.stock
FROM dtb_product p
JOIN dtb_product_class pc ON p.product_id = pc.product_id
WHERE p.del_flg = 0 AND pc.del_flg = 0;

문자 인코딩에 주의하세요. EC-CUBE 2.x 데이터베이스가 EUC-JP를 사용하는 경우, 어디든 가져오기 전에 UTF-8로 변환하세요:

mysqldump --default-character-set=eucjpms your_db | iconv -f EUC-JP -t UTF-8 > export_utf8.sql

Shopify에 가져오기

Shopify Admin API(REST 또는 GraphQL)를 사용하여 프로그래밍 방식으로 제품을 생성하세요. GraphQL의 productCreate 변형이 당신의 가장 친한 친구입니다:

mutation productCreate($input: ProductInput!) {
  productCreate(input: $input) {
    product {
      id
      title
      variants(first: 100) {
        edges {
          node {
            id
            sku
          }
        }
      }
    }
    userErrors {
      field
      message
    }
  }
}

내보낸 EC-CUBE 데이터를 읽고 Shopify 제품을 생성하는 Node.js 또는 Python으로 마이그레이션 스크립트를 작성하세요. 속도 제한을 포함하세요 -- Shopify의 API는 REST의 경우 2 요청/초 제한 및 GraphQL의 경우 비용 기반 제한이 있습니다.

고객 마이그레이션

API를 통한 Shopify의 고객 가져오기가 잘 작동하지만, 암호를 마이그레이션할 수 없다는 점에 유의하세요. 모든 고객은 마이그레이션 후 암호를 재설정해야 합니다. 마이그레이션을 설명하고 암호 재설정 링크를 제공하는 잘 작성된 이메일(물론 일본어)을 보내세요.

고객 데이터 자체의 경우, EC-CUBE 필드를 Shopify에 매핑하세요:

EC-CUBE 필드	Shopify 필드	참고
name01 (姓)	last_name	일본어용으로 역순
name02 (名)	first_name	일본어용으로 역순
kana01 (セイ)	metafield	기본 후리가나 필드 없음
kana02 (メイ)	metafield	기본 후리가나 필드 없음
email	email	직접 매핑
point	metafield 또는 로열티 앱	사용자 정의 처리 필요
addr01 (都道府県)	province	Shopify 지역 코드에 매핑
addr02 (市区町村)	city + address1	연결 필요할 수 있음

주문 이력

과거 주문 마이그레이션은 선택 사항이지만 고객 서비스 연속성을 위해 권장됩니다. Shopify의 Order API를 사용하여 완료된 주문에 대해 "financial_status": "paid" 및 "fulfillment_status": "fulfilled"를 포함하는 주문을 생성하세요.

일본 결제 방법 처리

여기가 까다로운 부분입니다. 일본 소비자들은 서양 전자상거래에서 표준이 아닌 특정 결제 옵션을 기대합니다.

Shopify Payments는 이제 JCB, Visa, Mastercard 및 American Express를 포함한 신용 카드를 지원합니다. 처리 수수료는 Shopify Plus의 경우 3.25%–3.4% + ¥0입니다.

다른 결제 방법:

결제 방법	Shopify 솔루션	참고
コンビニ決済 (편의점)	KOMOJU, GMO Payment Gateway 앱	일본 온라인 주문의 ~15%를 위해 필수
代引き (착불)	Shopify 기본 COD	내장, 작동 좋음
銀行振込 (은행 송금)	수동 결제 방법	Shopify 기본 지원
キャリア決済 (캐리어 청구)	KOMOJU	docomo, au, SoftBank
PayPay	Shopify용 PayPay 앱	일본에서 가장 인기 있는 QR 결제
Amazon Pay	Amazon Pay 앱	일본에서 높은 도입
後払い (선물금지불)	Paidy, atone	일본에서 매우 인기 있음

KOMOJU는 특별한 언급을 받을 가치가 있습니다. 이것은 일본 Shopify 스토어의 실제 결제 게이트웨이가 되었으며, 편의점 결제, 은행 송금, 캐리어 청구 및 기타를 단일 통합을 통해 지원합니다. Shopify Plus 통합은 견고하고 저희는 주요 문제가 없었습니다.

배송 및 이행 매핑

EC-CUBE는 일반적으로 Yamato Transport (ヤマト運輸), Sagawa Express (佐川急便) 및 Japan Post (日本郵便)용 플러그인을 사용합니다. 이러한 플러그인은 배송 라벨 생성, 추적 번호 통합 및 배송 시간대 선택(配達時間指定)을 처리합니다.

Shopify에서 여러 옵션이 있습니다:

• Ship&co -- 모든 주요 일본 캐리어와 통합되는 일본 제작 배송 앱. 올바른 형식으로 라벨 인쇄를 처리합니다.
• Shopify Shipping -- 2025년 현재 일본 캐리어 지원이 제한적이지만 개선 중입니다.
• Custom Carrier Service API -- 복잡한 지역 기반 가격 책정이 있는 경우 자신의 배송 요금 계산기를 구축하세요.

배송 시간대 선택(午前中, 12-14時, 14-16時 등)은 일본 고객에게 매우 중요합니다. 이것은 Shopify Plus의 사용자 정의 체크아웃 확장 또는 配送日時指定과 같은 타사 앱이 필요합니다.

Next.js 스토어프론트 구축

프론트엔드의 경우, App Router와 Server Components를 사용하는 Next.js 15를 사용합니다. 여기가 저희의 전형적인 스택입니다:

Next.js 15 (App Router)
├── Shopify Storefront API (GraphQL)
├── next-intl (일본어 i18n용)
├── Tailwind CSS 4
├── Framer Motion (애니메이션)
└── Vercel (배포, 도쿄 지역 엣지)

Next.js로 일본 스토어프론트를 구축하면서 배운 몇 가지:

폰트 최적화

일본 웹 폰트는 무겁습니다. Noto Sans JP 일반 가중치만 해도 ~1.8MB입니다. subsets과 함께 next/font를 사용하고 가변 폰트를 고려하세요:

import { Noto_Sans_JP } from 'next/font/google';

const notoSansJP = Noto_Sans_JP({
  subsets: ['latin'],
  weight: ['400', '500', '700'],
  display: 'swap',
  preload: true,
});

더 좋은 방법으로, font-display: optional을 중요하지 않은 텍스트에 사용하고 시스템 폰트 스택을 폴백으로 제공하세요: "Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif.

제품 페이지를 위한 Server Components

Server Components에서 제품 데이터를 가져와서 클라이언트 측 로딩 상태를 제거하세요:

// app/products/[handle]/page.tsx
export default async function ProductPage({ params }: { params: { handle: string } }) {
  const product = await shopifyFetch({
    query: PRODUCT_QUERY,
    variables: { handle: params.handle },
  });

  return (
    <div>
      <ProductGallery images={product.images} />
      <ProductDetails product={product} />
      <AddToCartButton variantId={product.variants[0].id} />
    </div>
  );
}

저희는 이 패턴으로 모든 헤드리스 Shopify 스토어프론트를 구축하며, 전통적인 Liquid 테마 또는 심지어 Hydrogen과 비교한 성능 차이는 눈에 띕니다.

SEO 마이그레이션 및 URL 보존

이것은 마이그레이션 프로젝트에서 저를 밤새 깨어있게 하는 부분입니다. 일본 전자상거래 스토어는 종종 몇 년에 걸친 SEO 자산을 축적했으며, 서툰 마이그레이션은 수 개월간 유기 트래픽을 곤두박질시킬 수 있습니다.

리다이렉트 전략

완전한 리다이렉트 맵을 생성하세요. 모든. 단일. URL. Next.js의 next.config.js 리다이렉트를 정적 패턴에 사용하세요:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/products/detail/:id',
        destination: '/products/:handle',
        permanent: true,
      },
      {
        source: '/products/list',
        destination: '/collections/:collection',
        permanent: true,
      },
    ];
  },
};

동적 리다이렉트의 경우(EC-CUBE 제품 ID를 Shopify 핸들에 매핑), 미들웨어 또는 데이터베이스 또는 KV 저장소에 저장된 리다이렉트 조회 테이블을 사용하세요.

구조화된 데이터

EC-CUBE 스토어는 거의 적절한 구조화된 데이터가 없습니다. 이를 기회로 삼아 Product, BreadcrumbList, Organization 및 FAQPage 스키마를 구현하세요. 일본 Google SERP는 풍부한 결과를 대량으로 보여줍니다.

일본 SEO 특성

• 일본어에서 제목 태그를 30자 이내로 유지하세요 (영어처럼 60이 아님)
• 메타 설명: 80-120 일본 문자
• 다국어 페이지가 있는 경우 적절한 hreflang 태그 확인
• Google Search Console 및 Bing Webmaster Tools 모두에 사이트맵 제출 (Bing은 일본에서 의미 있는 시장 점유율을 가짐)

일본 특화 UX 고려 사항

일본 전자상거래 UX는 서양 개발자들이 종종 놓치는 문화적 차이가 있습니다:

• 정보 밀도 -- 일본 소비자들은 페이지에 더 많은 제품 정보가 표시되기를 기대합니다. 과도하게 최소화하지 마세요.
• 신뢰 신호 -- 배송 정책, 반품 정책 및 회사 정보를 눈에 띄게 표시하세요. 일본 쇼핑객들은 철저히 조사합니다.
• 우편번호 자동 채우기 -- Japan Post API 또는 zipaddress.js와 같은 라이브러리를 사용하여 郵便番号 → 주소 자동완성을 구현하세요.
• 존경 언어 -- UI 복사본에서 적절한 경어(敬語)를 사용하세요. 캐주얼한 언어는 무례하게 느껴질 수 있습니다.
• LINE 메시징 통합 -- LINE은 일본에서 월 9,600만 활성 사용자를 가지고 있습니다. LINE 로그인 및 LINE 알림을 통합하세요.

성능 벤치마크: EC-CUBE vs 헤드리스 Shopify

다음은 2025년 1월에 완료한 일본 패션 소매업체(~3,000 SKU)의 마이그레이션에서 실제 데이터입니다:

메트릭	EC-CUBE 4.2 (이전)	Next.js + Shopify (이후)	개선
Lighthouse 성능 (모바일)	34	92	+170%
LCP	4.8s	1.2s	-75%
FID/INP	380ms	45ms	-88%
CLS	0.24	0.02	-92%
Time to First Byte	1.8s	0.18s	-90%
페이지 무게 (제품 페이지)	3.2MB	680KB	-79%
전환율	1.8%	2.9%	+61%
월간 호스팅 비용	¥180,000	¥45,000	-75%

전환율 개선만으로도 3개월 내에 전체 마이그레이션 비용을 지불했습니다. 모든 프로젝트가 이 정도로 극적인 수치를 본 것은 아니지만, 이 정도의 성능 개선은 지속적으로 바늘을 움직입니다.

일정 및 비용 예상

이 마이그레이션이 무엇을 필요로 하는지 현실적으로 봅시다:

스토어 크기	제품	일정	예산 범위 (¥)
소형	<500	8-12주	¥3,000,000-5,000,000
중형	500-5,000	12-20주	¥5,000,000-12,000,000
대형	5,000+	20-32주	¥12,000,000-25,000,000+

이러한 범위는 디자인, 개발, 데이터 마이그레이션, QA 및 출시 지원을 포함합니다. 경험 있는 팀과 함께 작업하고 있다고 가정합니다. 팀이 일본 전자상거래 마이그레이션을 해본 적이 없다면, 학습 곡선을 위해 일정과 예산 모두에 30-50%를 추가하세요.

저희는 헤드리스 CMS 및 전자상거래 개발 실무를 통해 이 범위에 걸친 프로젝트를 처리합니다. 구체적인 사항을 논의하려면, 연락주세요 그리고 저희가 정직한 평가를 해드리겠습니다.

마이그레이션 후 월간 지속 비용은 일반적으로 다음과 같습니다:

• Shopify Plus: $2,300/월 (~¥345,000)
• Vercel Pro: 팀 구성원당 $20/월
• KOMOJU: 거래 수수료만
• Ship&co: ¥2,000/월 기본
• 합계: ~¥380,000-450,000/월 vs. 동등한 기능을 가진 자체 호스팅 EC-CUBE의 ¥400,000-800,000/월

프로젝트 가격 책정을 어떻게 구조화하는지 투명하게 보려면, 가격 페이지를 확인하세요.

FAQ

EC-CUBE 2.x에서 Shopify + Next.js로 직접 마이그레이션할 수 있나요?

네, 하지만 EC-CUBE 2.x 마이그레이션은 더 오래된 데이터베이스 스키마, 잠재적 Shift-JIS/EUC-JP 인코딩 문제 및 최신 ORM 부족으로 인해 더 복잡합니다. 데이터 정리 및 변환을 위해 추가 시간을 예산으로 책정하세요. 저희는 먼저 중립 형식(UTF-8의 CSV 또는 JSON)으로 내보낸 다음, Shopify를 위한 가져오기 스크립트를 빌드할 것을 권장합니다.

EC-CUBE에서 마이그레이션할 때 Google 순위를 잃게 되나요?

아니요, 리다이렉트를 제대로 처리하면 됩니다. 모든 URL에 대해 301 리다이렉트를 구현하고, XML 사이트맵을 유지하며, 제목 태그와 메타 설명을 일관되게 유지하세요. Google이 다시 크롤링할 때 일시적인 변동(2-4주)이 있을 것으로 예상하지만, 순위는 회복되어야 하며 일반적으로 더 나은 Core Web Vitals 점수로 인해 개선됩니다.

Shopify는 경감세율(軽減税率)을 포함한 일본 세금 계산을 지원하나요?

네. Shopify는 일본의 소비세 시스템을 지원하며, 식음료에 대한 경감세율(8%)과 표준 세율(10%)을 포함합니다. 제품 컬렉션당 세율을 구성할 수 있으며 Shopify가 인보이스 적격 영수증 요구 사항(インボイス制度)을 포함한 계산을 처리합니다.

Shopify로 마이그레이션 후 EC-CUBE의 포인트 시스템을 어떻게 처리하나요?

Shopify는 EC-CUBE의 내장 ポイント 기능과 동등한 기본 포인트 시스템을 가지지 않습니다. 최선의 옵션은 Smile.io(일본 지원), LoyaltyLion 또는 Shopify 메타필드 및 서버리스 함수를 사용하는 사용자 정의 솔루션입니다. 기존 포인트 잔액의 경우, 이를 고객 기록의 메타필드로 마이그레이션하고 Next.js 체크아웃에서 상환 흐름을 구축하세요.

헤드리스 Shopify 스토어프론트를 위해 Hydrogen이 Next.js보다 낫나요?

상황에 따라 다릅니다. Hydrogen (Remix 위에 구축한 Shopify의 React 프레임워크)은 Shopify와 긴밀하게 통합되어 있으며 일부 훌륭한 내장 전자상거래 기본 요소를 제공합니다. 하지만 Next.js는 훨씬 더 큰 생태계, 더 많은 커뮤니티 리소스, Vercel의 더 나은 Edge Runtime 지원 및 전자상거래 백엔드를 바꾸고 싶을 경우 더 많은 유연성을 가지고 있습니다. 일본 전자상거래 특성상, Next.js의 미들웨어 기능과 i18n 라우팅이 우위를 제공합니다. 저희는 둘 다 구축해 봤으며 대부분의 프로젝트에서 Next.js를 선호합니다 -- 우리의 Next.js 개발 기능을 보세요.

마이그레이션 중에 EC-CUBE와 새로운 Shopify 스토어를 병렬로 실행할 수 있나요?

네, 그리고 저희는 그렇게 할 것을 권장합니다. 2-4주 동안 두 시스템을 동시에 실행하세요. DNS 또는 역방향 프록시를 사용하여 점진적으로 트래픽을 이동하세요. 이를 통해 주문이 올바르게 흐르는지, 결제가 제대로 처리되는지, 재고가 동기화되는지 완전히 전환하기 전에 검증할 수 있습니다.

EC-CUBE의 메일 매거진(メールマガジン) 기능은 어떻게 되나요?

EC-CUBE는 많은 스토어가 의존하는 내장 이메일 뉴스레터 시스템을 가지고 있습니다. 구독자 목록을 Klaviyo (Shopify 통합이 탁월함)와 같은 전용 이메일 마케팅 플랫폼으로 마이그레이션하거나, 일본어 지원 및 템플릿이 필요한 경우 Benchmark Email 또는 SendGrid를 고려하세요. 마이그레이션은 간단합니다 -- EC-CUBE의 dtb_customer 테이블에서 이메일 주소와 동의 날짜를 내보내고 새로운 플랫폼으로 가져오세요.

실제 데이터 마이그레이션은 얼마나 오래 걸리나요?

마이그레이션 스크립트 실행 자체는 일반적으로 빠릅니다 -- 대부분의 스토어의 경우 몇 시간입니다. 시간이 많이 걸리는 부분은 마이그레이션 스크립트 구축 및 테스트, 데이터 무결성 검증 및 엣지 케이스 처리(누락된 이미지가 있는 제품, 잘못된 이메일 형식의 고객, 사용자 정의 상태의 주문)입니다. ~3,000개의 제품 및 50,000명의 고객이 있는 스토어의 경우, 2-3주의 마이그레이션 개발 및 테스트 시간을 기대하세요.