당신의 Wix 사이트가 문제가 아닙니다. 마이그레이션 워크플로우가 문제입니다.

Wix는 자신이 만들어진 목적에 충실합니다.

저장소(repo)를 열거나, 프레임워크(framework)를 선택하거나, 호스팅(hosting)을 설정하거나, CMS를 연결하거나, 배포(deployment)를 배울 필요 없이 누군가가 웹사이트를 온라인에 올릴 수 있게 해줍니다.

그것은 유용합니다.

많은 기업에게 Wix 사이트는 실수가 아닙니다. 그것이 그들이 웹사이트를 갖게 된 이유 그 자체입니다.

문제는 보통 나중에 시작됩니다.

사이트가 성장합니다. 비즈니스가 변합니다. 마케팅 팀은 더 나은 랜딩 페이지(landing pages)를 원합니다. SEO(검색 엔진 최적화)가 더 중요해집니다. 누군가는 커스텀 결제 로직(custom checkout logic)을 원합니다. 누군가는 블로그가 다르게 동작하기를 원합니다. 누군가는 더 나은 성능을 원합니다. 누군가는 대시보드(dashboard), 가격 페이지(pricing page), 게이트 구역(gated area), 헤드리스 CMS(headless CMS), 또는 제대로 된 배포 워크플로우(deployment workflow)를 원합니다.

그러면 갑자기 팀에서 이렇게 말합니다:

이 Wix 사이트를 React로 옮길 수 있을까요?

그 질문은 단순하게 들립니다.

하지만 그렇지 않습니다.

이 작업의 실제 버전을 위한 깔끔하고 보편적인 "Next.js로 내보내기" 버튼 같은 것은 존재하지 않습니다.

당신은 단순히 픽셀(pixels)을 옮기는 것이 아닙니다.

당신은 콘텐츠, 레이아웃 결정, SEO 가정, 양식(forms), 미디어, 트래킹(tracking), 비즈니스 로직, 그리고 대개 아무도 문서화하지 않은 몇 가지 지저분한 의외의 요소들을 포함한 실제 운영 중인 웹사이트를 옮기는 것입니다.

그것이 바로 Wix-to-React 마이그레이션(migration)이 프레임워크(framework)의 문제가 아니라 워크플로우(workflow)의 문제인 이유입니다.

이 작업의 순진한 버전

순진한 버전은 다음과 같이 들립니다:

이 Wix 사이트를 가져와서 React로 다시 만드세요.

AI 에이전트(AI agent)라면 시도해 볼 수 있습니다.

페이지를 열고, 레이아웃을 검사하고, 컴포넌트(component)를 생성하고, 텍스트를 복사하고, 스타일링(styling)을 근사치로 구현하여 스크린샷상으로 충분히 비슷해 보이는 무언가를 만들어낼 수 있습니다.

데모용으로는 괜찮습니다.

하지만 마이그레이션(migration)을 위해서는 충분하지 않습니다.

첫 번째 스크린샷이 웹사이트 그 자체는 아니기 때문입니다.

웹사이트는 또한 다음과 같은 것들을 포함합니다:

언급하는 것을 잊어버린 모든 페이지들
모바일 레이아웃(mobile layouts)
네비게이션 상태(navigation states)
이미지 및 파일
리다이렉트(redirects)
메타데이터(metadata)
양식(forms)
블로그 포스트
제품 페이지
CMS 컬렉션(collections)
트래킹 스크립트(tracking scripts)
접근성 문제(accessibility issues)
특정 페이지에만 존재하는 이상한 간격
메뉴 뒤에 숨겨진 비즈니스 콘텐츠
깨져서는 안 되는 SEO URL

만약 이 작업을 단순한 디자인 복제(design clone)로 취급한다면, 운영 측면의 작업(operational work)을 놓치게 됩니다.

이 작업을 운영적 마이그레이션 (operational migration)으로 취급한다면, 과업은 훨씬 더 명확해집니다.

진짜 질문

진짜 질문은 이것이 아닙니다:

React가 이 페이지를 재현할 수 있는가?

당연히 할 수 있습니다.

더 나은 질문은 이것입니다:

이전 과정에서 정확히 무엇이 살아남아야 하는가?

그 질문이 전체 워크플로우 (workflow)를 바꿉니다.

5개의 정적 페이지로 구성된 브로슈어 사이트는 별개의 문제입니다.

블로그 콘텐츠, 멤버 영역, 양식 (forms), 스토어, 예약, 그리고 SEO 히스토리가 포함된 Wix 사이트는 전혀 다른 문제입니다.

작은 정적 사이트라면, 모든 것을 Next.js로 다시 구축하고 넘어가면 그만일 것입니다.

하지만 Wix CMS 또는 Wix Stores를 사용하는 사이트라면, 결정해야 할 사항들이 있습니다:

Wix에서 데이터를 마이그레이션할 것인가?
Wix를 헤드리스 백엔드 (headless backend)로 유지할 것인가?
다른 곳에 CMS를 다시 구축할 것인가?
URL 구조를 보존할 것인가?
양식 (forms)을 수동으로 다시 만들 것인가?
제품을 새로운 이커머스 (ecommerce) 시스템에 매핑할 것인가?
Wix SDK 통합을 유지할 것인가?

이것들은 코드 생성 (code-generation)에 관한 질문이 아닙니다.

이것들은 마이그레이션 설계 (migration design)에 관한 질문입니다.

만약 이 질문들을 건너뛴다면, React 앱은 멀쩡해 보일지 몰라도 비즈니스 워크플로우 (business workflow)는 망가질 수 있습니다.

왜 에이전트에게 이 기술이 필요한가

AI 에이전트들은 React 컴포넌트를 작성하는 데 꽤 능숙합니다.

하지만 과업이 개방적이고 '완료'의 정의가 모호할 때는 신뢰도가 떨어집니다.

Wix 마이그레이션이 바로 그러합니다.

워크플로우 (workflow)가 없다면, 에이전트는 가장 뻔한 일을 할지도 모릅니다:

홈페이지를 연다
시각적 레이아웃을 복사한다
몇 개의 컴포넌트를 만든다
이것을 마이그레이션이라고 부른다

하지만 진짜 마이그레이션에는 훨씬 더 지루한 순서가 필요합니다:

인벤토리 파악 (inventory) -> 분류 (classify) -> 추출 (extract) -> 재구축 (rebuild) -> 데이터 마이그레이션 (migrate data) -> 검증 (verify) -> 공백 보고 (report gaps)

이것은 화려하지 않습니다.

하지만 이것이 유용한 마이그레이션과 예쁜 목업 (mockup) 사이의 차이점입니다.

이 지점에서 Terminal Skills가 관련성을 갖게 됩니다.

Terminal Skills는 AI 에이전트(AI agents)를 위한 재사용 가능한 기술(skills)의 카탈로그입니다. 핵심은 에이전트에게 단 하나의 마법 같은 명령어를 주는 것이 아닙니다. 핵심은 에이전트에게 반복 가능한 운영 절차(operating procedure)를 제공하는 것입니다.

정확히 이 문제를 해결하기 위한 유용한 기술은 다음과 같습니다:

wix-to-react

기술 페이지는 여기에 있습니다:

중요한 부분은 워크플로우(workflow)의 형태입니다.

이 워크플로우는 에이전트에게 Wix-to-React 전환을 단 한 번의 복제(one-shot clone)가 아니라, 검사(inspection), 결정(decisions), 보존 규칙(preservation rules), 그리고 검증(verification)을 포함하는 마이그레이션(migration)으로 취급하도록 지시합니다.

Wix-to-React 워크플로우가 가장 먼저 해야 할 일

첫 번째 단계는 코드를 작성하는 것이 아니어야 합니다.

첫 번째 단계는 인벤토리(inventory, 목록 작성)여야 합니다.

에이전트가 무언가를 구축하기 전에, 다음 질문에 답해야 합니다:

페이지가 몇 개 존재하는가?
어떤 페이지가 공개(public)되어 있는가?
어떤 페이지가 숨겨져 있거나 메뉴를 통해서만 연결되는가?
어떤 콘텐츠가 정적(static)인가?
어떤 콘텐츠가 Wix CMS에서 오는가?
블로그 포스트가 있는가?
제품(products)이 있는가?
양식(forms)이 있는가?
예약(bookings), 이벤트(events), 또는 회원 전용(members-only) 영역이 있는가?
어떤 스크립트(scripts)가 설치되어 있는가?
어떤 URL을 보존해야 하는가?
어떤 에셋(assets)을 다운로드해야 하는가?

이것은 단순한 잡무가 아닙니다.

이는 전형적인 마이그레이션 실패 사례를 방지합니다:

홈페이지는 재구축되었지만, 웹사이트의 절반이 사라졌다.

홈페이지는 보통 가장 만들기 쉬운 페이지입니다.

위험은 지루한 페이지들에 있습니다:

감사 페이지 (thank-you pages)
오래된 캠페인 랜딩 페이지 (old campaign landing pages)
정책 페이지 (policy pages)
블로그 상세 템플릿 (blog detail templates)
카테고리 페이지 (category pages)
제품 변형 (product variants)
비즈니스 프로세스에 연결된 양식 (forms)

이러한 페이지들을 인벤토리화하지 않으면, 쉽게 유실될 수 있습니다.

두 번째 단계는 분류(classification)입니다

무엇이 존재하는지 알게 되었다면, 이를 분류해야 합니다.

Wix 사이트의 모든 부분을 동일한 방식으로 마이그레이션해서는 안 됩니다.

저는 다음과 같이 분류하겠습니다:

정적 마케팅 페이지 (Static marketing pages)

이 페이지들은 보통 React 또는 Next.js에서 직접 재구축해도 안전합니다.

예시:

홈페이지 (homepage)
소개 페이지 (about page)
서비스 페이지 (service pages)
연락처 페이지 (contact page)
가격 페이지 (pricing page)
랜딩 페이지 (landing pages)

에이전트(agent)는 이를 컴포넌트 (components), 섹션 (sections), 레이아웃 (layouts), 그리고 재사용 가능한 콘텐츠 블록 (reusable content blocks)으로 다시 구축할 수 있습니다.

CMS 기반 콘텐츠 (CMS-driven content)

여기에는 데이터에 대한 결정이 필요합니다.

예시:

블로그 포스트 (blog posts)
사례 연구 (case studies)
팀원 (team members)
위치 (locations)
서비스 지역 (service areas)
리소스 라이브러리 (resource libraries)

이를 다른 CMS로 마이그레이션하거나, 파일로 유지하거나, 데이터베이스 (database)로 옮기거나, Wix SDK를 통해 Wix를 헤드리스 백엔드 (headless backend)로 사용할 수 있습니다.

하지만 이 결정은 명시적이어야 합니다.

비즈니스 로직 (Business logic)

이 부분이 스크린샷 클론 (screenshot clone)이 심각하게 실패하는 지점입니다.

예시:

양식 (forms)
예약 (bookings)
이커머스 (ecommerce)
멤버 영역 (member areas)
게이트 다운로드 (gated downloads)
결제 흐름 (payment flows)
이메일 자동화 (email automations)

이것들은 시각적 요소가 아닙니다.

이것들은 워크플로우 (workflows)입니다.

기존 사이트가 Wix Forms 또는 Wix Stores를 사용한다면, 새로운 React 앱에는 이를 대체할 계획이 필요합니다.

SEO 및 분석 (SEO and analytics)

페이지 디자인에는 나타나지 않기 때문에 잊기 쉽습니다.

하지만 매우 중요합니다.

마이그레이션 시 다음 항목들을 보존하거나 매핑 (map)해야 합니다:

페이지 제목 (page titles)
메타 설명 (meta descriptions)
캐노니컬 URL (canonical URLs)
오픈 그래프 이미지 (open graph images)
헤딩 (headings)
구조화된 데이터 (structured data)
리다이렉트 (redirects)
분석 이벤트 (analytics events)
픽셀 (pixels)
전환 추적 (conversion tracking)

비즈니스가 이미 Wix 사이트를 통해 트래픽을 얻고 있다면, 마이그레이션은 단순한 디자인 작업이 아닙니다.

그것은 트래픽 보존 작업입니다.

UI를 재구축하는 것은 쉬운 부분입니다

인벤토리 (inventory) 조사와 분류가 완료되면, React 작업은 훨씬 쉬워집니다.

에이전트는 다음과 같은 것들을 생성할 수 있습니다:

레이아웃 시스템 (layout system)
공유 헤더 및 푸터 (shared header and footer)
재사용 가능한 섹션 컴포넌트 (reusable section components)
페이지 템플릿 (page templates)
이미지 컴포넌트 (image components)
콘텐츠 로더 (content loaders)
라우트 구조 (route structure)
SEO 메타데이터 헬퍼 (SEO metadata helpers)
양식 컴포넌트 (form components)

이것이 바로 React와 Next.js가 빛을 발하는 지점입니다.

비주얼 빌더 (visual builder) 내부에서 모든 페이지를 수동으로 편집하는 대신, 시스템을 구축할 수 있습니다.

예를 들어:

components/
  Header.tsx
  Footer.tsx
...

목표는 Wix를 코드로 재현하는 것이 아닙니다.

목표는 사이트를 유지보수 가능한 제품 (maintainable product)으로 만드는 것입니다.

이는 재사용 가능한 컴포넌트 (reusable components), 명확한 콘텐츠 소스 (content sources), 예측 가능한 라우트 (predictable routes), 그리고 팀이 이해할 수 있는 배포 워크플로우 (deployment workflow)를 의미합니다.

Wix SDK 옵션

한 가지 중요한 뉘앙스가 있습니다.

React로 전환한다고 해서 항상 Wix를 완전히 버려야 한다는 의미는 아닙니다.

어떤 팀들에게는 Wix가 여전히 유용한 비즈니스 데이터를 보유하고 있을 수 있습니다:

제품 (products)
CMS 컬렉션 (CMS collections)
예약 (bookings)
멤버 (members)
블로그 콘텐츠 (blog content)

이 경우, 마이그레이션은 다음과 같이 진행될 수 있습니다:

React/Next.js 프론트엔드 + 백엔드로서의 Wix

이 지점에서 @wix/sdk가 중요해질 수 있습니다.

모든 것을 즉시 뜯어내는 대신, 새로운 앱은 프론트엔드를 커스텀으로 구축하면서 Wix 데이터를 헤드리스 백엔드 (headless backend)로 사용할 수 있습니다.

이것이 모든 프로젝트에 정답인 것은 아닙니다.

하지만 실질적인 마이그레이션 옵션 중 하나입니다.

그리고 이것이 바로 에이전트 (agent)가 추측하는 대신 제시해야 할 결정 사항의 종류입니다.

좋은 워크플로우는 다음과 같이 말해야 합니다:

사이트가 Wix CMS, Stores, Blog 또는 Forms에 의존하는 경우, 해당 기능들을 재구축하기 전에 데이터를 외부로 마이그레이션할지 아니면 Wix를 백엔드로 유지할지 결정하십시오.

이는 다음과 같은 지시보다 훨씬 안전합니다:

Wix를 React로 변환하십시오.

생성보다 검증이 더 중요합니다

이 워크플로우에서 가장 위험한 부분은 잘못된 자신감 (false confidence)입니다.

에이전트는 그럴듯해 보이는 React 앱을 생성할 수 있습니다.

하지만 결과물을 확인하기 전까지 마이그레이션이 완료된 것은 아닙니다.

실질적인 검증 체크리스트에는 다음 사항이 포함되어야 합니다:

모든 중요한 URL이 일치하는 라우트 (route) 또는 리다이렉트 (redirect)를 가지고 있는지
데스크톱 및 모바일 레이아웃이 확인되었는지
이미지가 올바른 소스에서 로드되는지
네비게이션 (navigation)이 작동하는지
폼 (forms)이 실제 어딘가로 제출되는지
블로그 또는 CMS 페이지가 데이터로부터 렌더링되는지
메타데이터 (metadata)가 존재하는지
이전 URL들이 매핑되었는지
명백한 콘솔 에러 (console errors)가 나타나지 않는지
성능 (performance)이 수용 가능한 수준인지
접근성 (accessibility) 기본 사항이 깨지지 않았는지

예를 들어:

npm run build
npm run lint
npm run test

그 다음 실행 중인 사이트를 확인합니다:

npm run dev

그리고 브라우저에서 실제 페이지를 검사합니다.

이것은 제가 에이전트 워크플로우에서 계속해서 강조하는 동일한 패턴입니다:

inspect -> decide -> run -> verify -> report

코드 생성 (code generation) 부분은 단지 하나의 단계일 뿐입니다.

검증 (verification) 단계야말로 작업의 신뢰성을 확보하는 지점입니다.

Terminal Skills가 적합한 이유

이것이 제가 Terminal Skills라는 프레임워크 (framing)를 선호하는 이유입니다.

유용한 정보는 "AI가 React를 작성할 수 있다"가 아닙니다.

우리는 이미 그것을 알고 있습니다.

진정으로 유용한 정보는 다음과 같습니다:

워크플로우 (workflow)가 충분히 명확하게 패키징되어 있다면,
AI는 반복 가능한 마이그레이션 (migration) 워크플로우를 따를 수 있다.

wix-to-react 기술 (skill)은 에이전트 (agent)에게 더 구체적인 운영 경로를 제공합니다.

이것은 다음과 같은 모호한 요청을:

내 Wix 사이트를 React로 옮겨줘.

다음과 같이 구체적인 것에 가깝게 변환합니다:

Wix 사이트의 인벤토리 (inventory)를 작성하라.
정적 페이지 (static pages), CMS 콘텐츠, 비즈니스 로직 (business logic), 그리고 SEO 요구사항을 분류하라.
데이터를 마이그레이션할지, 아니면 Wix를 백엔드 (backend)로 사용할지 결정하라.
...

이것이 훨씬 더 낫습니다.

숨겨진 가정 (hidden assumptions)의 수를 줄여줍니다.

또한 에이전트를 감독 (supervise)하기 더 쉽게 만듭니다.

단순히 다음과 같이 묻는 대신:

사이트를 변환했나요?

여러분은 다음과 같이 물을 수 있습니다:

어떤 페이지들의 인벤토리를 작성했나요?
어떤 콘텐츠 소스들을 찾아냈나요?
어떤 Wix 기능들이 여전히 마이그레이션 결정이 필요한 상태인가요?
...

이것들이 더 나은 질문입니다.

그리고 더 나은 결과물을 만들어냅니다.

에이전트는 간극을 숨기는 것이 아니라 보고해야 합니다

Wix 마이그레이션 기술에서 제가 명시적으로 원하는 한 가지는 다음과 같습니다:

모든 Wix 기능이 시각적으로만 비슷하게 구현된 것이라면, 모든 기능이 마이그레이션된 것처럼 가장하지 마라.

이것은 매우 중요합니다.

기존 Wix 사이트에 예약 워크플로우가 있었는데, 새로운 React 앱에 "지금 예약하기"처럼 보이는 버튼은 있지만 아무런 동작도 하지 않는다면, 그것은 마이그레이션이 아닙니다.

그것은 시각적 플레이스홀더 (visual placeholder)일 뿐입니다.

플레이스홀더는 라벨이 붙어 있다면 괜찮습니다.

하지만 숨겨져 있다면 위험합니다.

훌륭한 최종 보고서에는 다음과 같은 내용이 포함되어야 합니다:

재구축된 페이지 (rebuilt pages)
건너뛴 페이지 (skipped pages)
복사된 에셋 (assets copied)
내보내진 데이터 (data exported)
내보내지지 않은 데이터 (data not exported)
재생성된 양식 (forms recreated)
여전히 플레이스홀더 상태인 양식 (forms still placeholder)
완료된 SEO 매핑 (SEO mappings completed)
여전히 필요한 리다이렉트 (redirects still needed)
수동 결정이 필요한 사항 (manual decisions required)

이러한 종류의 정직함은 지루할 수 있습니다.

하지만 바로 이것이 에이전트의 작업을 프로덕션 (production) 환경에서 사용 가능하게 만드는 핵심입니다.

현실적인 마이그레이션 계획

만약 제가 Wix에서 React로의 마이그레이션 (migration)을 위해 에이전트를 사용한다면, 워크플로우 (workflow)는 대략 다음과 같은 모습이기를 원할 것입니다.

Phase 1: Discovery (탐색)

Wix 사이트를 엽니다.

가시적인 페이지들을 매핑 (mapping) 합니다.

내비게이션 (navigation), 푸터 (footer) 링크, 사용 가능한 경우 사이트맵 (sitemap), 블로그 인덱스 (blog index), 제품 페이지, 그리고 모든 공개 경로 (public routes)를 확인합니다.

인벤토리 (inventory) 파일을 생성합니다.

Phase 2: Feature audit (기능 감사)

사이트가 다음을 사용하는지 식별합니다:

Wix CMS
Wix Blog
Wix Stores
Wix Bookings
Wix Forms
멤버 로그인 (member login)
커스텀 코드 (custom code)
제3자 스크립트 (third-party scripts)

이는 마이그레이션의 위험도를 결정합니다.

Phase 3: Content and asset extraction (콘텐츠 및 에셋 추출)

다음 항목을 다운로드하거나 문서화합니다:

이미지 (images)
로고 (logos)
아이콘 (icons)
카피 (copy)
메타데이터 (metadata)
블로그 콘텐츠 (blog content)
제품 데이터 (product data)
폼 필드 (form fields)

콘텐츠 소스가 명확해지기 전까지는 재구축 (rebuilding)을 시작하지 마세요.

Phase 4: React/Next.js rebuild (React/Next.js 재구축)

앱 구조를 생성합니다.

공통 컴포넌트 (shared components)를 구축합니다.

페이지를 재현합니다.

콘텐츠를 연결 (wire) 합니다.

메타데이터 (metadata)를 추가합니다.