Lovable에서 Vercel로 — 프론트엔드 마이그레이션 기록

배경

WICHI는 GEO(Generative Engine Optimization) SaaS입니다. 프론트엔드는 Vite + React 18 + TypeScript + shadcn/ui 조합이고, 백엔드는 FastAPI, DB와 Auth는 Supabase, 서버 호스팅은 Railway입니다. 프론트엔드의 초기 버전은 Lovable로 만들었고, Lovable이 빌드와 배포, 커스텀 도메인 관리까지 담당하고 있었습니다.

이 글은 그 프론트엔드 호스팅을 Lovable에서 Vercel로 전환한 과정을 기록합니다. 전환 이유, 사전 계획, 실행 과정, 발생한 문제와 해결, 그리고 회고를 순서대로 다룹니다.

전환 전 아키텍처

전환 전 WICHI의 인프라 구성은 다음과 같았습니다.

레이어	기술	호스팅
프론트엔드	Vite + React 18 + TS + shadcn/ui	Lovable
백엔드 API	FastAPI + Python	Railway
DB / Auth	Supabase (PostgreSQL + Auth + RLS)	Supabase Cloud
DNS	Cloudflare	—
도메인	wichi.app	Cloudflare 관리

핵심 포인트는, Lovable이 담당하는 범위가 프론트엔드 빌드 + 호스팅 + 커스텀 도메인으로 한정되어 있었다는 것입니다. 백엔드, DB, Auth, 결제는 모두 Lovable과 독립적으로 운영되고 있었습니다. 이 덕분에 전환 범위가 제한적이었고, 마이그레이션 난이도가 낮았습니다.

왜 전환했나

Lovable은 초기 프로토타이핑 단계에서 유용했습니다. 프롬프트 기반으로 UI를 빠르게 뽑아낼 수 있었고, WICHI 프론트엔드의 첫 버전을 만드는 데 실질적으로 기여했습니다. 조코딩 해커톤에서 3일 만에 프론트엔드를 완성할 수 있었던 것은 Lovable 덕분입니다.

문제는 상용화 단계로 넘어가면서 드러났습니다.

Git-first 워크플로우 부재

Lovable은 자체 에디터에서 프롬프트로 UI를 수정하고, 변경 사항을 GitHub에 push하는 구조입니다. 반대 방향은 지원하지 않습니다. GitHub에서 직접 수정한 코드를 Lovable로 pull할 수 없습니다.

이로 인해 발생한 문제들을 정리하면 다음과 같습니다.

문제	설명
브랜치 충돌	Lovable은 main 브랜치에서 작업하고, Claude Code는 dev 브랜치에서 작업. 머지 시 충돌이 빈번
PR 기반 리뷰 불가	Lovable의 변경 사항은 직접 main에 push되므로 PR을 통한 코드 리뷰 프로세스를 적용할 수 없음
변경 이력 불투명	Lovable이 생성하는 커밋 메시지는 프롬프트 내용 요약 수준. 변경 의도를 정확히 파악하기 어려움
단방향 동기화	GitHub → Lovable 방향의 sync가 없어서, 외부에서 수정한 코드가 Lovable 에디터에 반영되지 않음

1인 개발이라도 PR 기반 워크플로우는 유효합니다. 코드 변경을 머지하기 전에 diff를 검토하고, 프리뷰 환경에서 확인하는 것은 실수를 줄이는 기본적인 안전장치입니다.

배포 제어 한계

프로덕션 환경에서는 배포 설정을 세밀하게 제어해야 합니다. Lovable 호스팅에서 직접 관리할 수 없었던 항목들을 나열하면 다음과 같습니다.

리다이렉트 규칙: SPA의 클라이언트 사이드 라우팅을 위한 fallback rewrite. 예를 들어 /dashboard/report/123 같은 딥 링크로 직접 접근할 때 index.html로 리다이렉트하는 설정
보안 헤더: X-Frame-Options, Content-Security-Policy, Strict-Transport-Security 같은 HTTP 보안 헤더 커스터마이징
캐시 정책: 정적 에셋의 캐시 만료 시간, Cache-Control 헤더 제어
환경변수 분리: Production, Preview, Development 환경별 환경변수 분리 관리
빌드 커맨드 커스터마이징: 빌드 전후 실행할 스크립트, 환경별 빌드 플래그 제어

이 중 특히 SPA rewrite는 필수였습니다. React Router를 사용하는 SPA에서 리다이렉트 규칙 없이는 새로고침이나 딥 링크 접근 시 404가 발생합니다. Lovable 호스팅에서는 이 설정을 직접 건드릴 수 없었고, Lovable 측에서 자체적으로 처리해주는 방식이라 문제 발생 시 디버깅이 어려웠습니다.

종속성 문제

코드에 Lovable 전용 의존성이 남아 있었습니다.

lovable-tagger: Lovable 에디터에서 컴포넌트를 식별하기 위한 태깅 플러그인. Vite 빌드 파이프라인에 플러그인으로 등록되어 있었음
Lovable 에디터와의 연동을 위한 설정 코드

이 의존성들은 Lovable 외부 환경에서는 불필요하고, 다른 호스팅으로 이전할 때 제거해야 하는 항목들입니다. 의존성이 깊어질수록 이전 비용이 올라가므로, 이른 시점에 제거하는 것이 유리했습니다.

비용 구조

Lovable 구독 비용은 월 $25 ($300/yr)입니다. Vercel의 Hobby 플랜은 무료이며, WICHI 프론트엔드의 트래픽 수준(정적 사이트, 초기 단계)에서는 무료 티어의 한도(월 100GB 대역폭)를 초과할 가능성이 없었습니다.

비용 절감 자체가 전환의 핵심 동기는 아니었습니다. Git-first 워크플로우와 배포 제어가 주된 이유였고, 비용 절감은 부수적 효과였습니다.

전환 판단 기준

전환 결정 시 고려한 기준과 판단을 정리하면 다음과 같습니다.

기준	Lovable 유지	Vercel 전환	판단
워크플로우	하이브리드 (Lovable + Claude Code)	Git-first 단일 도구	Vercel 우위
배포 제어	제한적	완전 제어 (`vercel.json`)	Vercel 우위
PR Preview	불가	PR마다 자동 생성	Vercel 우위
롤백	수동 복원	이전 배포로 즉시 롤백	Vercel 우위
비주얼 에디터	사용 가능	사용 불가	Lovable 우위
마이그레이션 리스크	없음	낮음 (표준 Vite 프로젝트)	수용 가능
다운타임	없음	DNS 전환 시 1~5분	수용 가능

Lovable이 우위인 항목은 비주얼 에디터 하나뿐이었습니다. 상용화 단계에서 비주얼 에디터의 가치보다 Git-first 워크플로우와 배포 제어의 가치가 더 높다고 판단했습니다.

전환 계획

전제 조건 확인

마이그레이션을 시작하기 전에 확인한 전제 조건들입니다.

코드 소유권: GitHub 레포지토리(vista-sphere-pro)에 전체 소스 코드가 있고, Lovable 외부에서 빌드 가능한 상태인지 확인. 표준 Vite 프로젝트이므로 npm run build로 정상 빌드 확인 완료
Lovable 전용 의존성 범위: lovable-tagger가 devDependency에만 등록되어 있고, 런타임 코드에는 Lovable 종속 로직이 없는지 확인
환경변수 목록: 프론트엔드가 참조하는 환경변수 전수 조사. VITE_API_URL, VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY 등. 확인 결과 코드에 fallback 값이 하드코딩되어 있어 Vercel에 별도 설정이 필수는 아니었으나, 환경 분리를 위해 설정하기로 결정
DNS 설정 현황: Cloudflare에서 wichi.app의 CNAME이 Lovable 호스팅을 가리키고 있는지 확인. TTL 값 확인

작업 순서

계획한 작업 순서는 다음과 같았습니다.

flowchart TD
    A["1. Vercel에 repo 연결\n(다운타임 없음)"] --> B["2. 환경변수 설정\n(다운타임 없음)"]
    B --> C["3. Preview 배포로 풀 테스트\n(다운타임 없음)"]
    C --> D{"테스트 통과?"}
    D -->|Yes| E["4. DNS CNAME 변경\n(다운타임 1~5분)"]
    D -->|No| F["문제 해결 후 재테스트"]
    F --> C
    E --> G["5. CORS 설정 업데이트\n(다운타임 없음)"]
    G --> H["6. Lovable 전용 코드 정리\n(다운타임 없음)"]
    H --> I["7. 검증 및 모니터링"]

핵심 원칙은 다운타임을 DNS 전환 한 단계로 제한하는 것이었습니다. Vercel에서 먼저 스테이징 배포를 완료하고 풀 테스트를 통과한 후에 DNS를 전환하면, 실제 다운타임은 DNS 전파 시간으로 한정됩니다.

다운타임 최소화 전략

DNS 전환 시 다운타임을 최소화하기 위해 사전에 준비한 항목들입니다.

준비 항목	설명
TTL 사전 하향	DNS 전환 하루 전에 CNAME 레코드의 TTL을 60초로 낮춤. 전환 후 DNS 캐시가 빠르게 만료되도록
Vercel 스테이징 검증	`*.vercel.app` 도메인에서 전체 기능 테스트 완료 후 전환
롤백 계획	DNS CNAME을 다시 Lovable으로 되돌리면 즉시 롤백 가능. Lovable 구독 해지는 전환 확인 후
전환 시간대	트래픽이 가장 적은 시간대에 실행

실행

1단계: Vercel 프로젝트 설정

Vercel에 GitHub 레포지토리를 연결하고 기본 설정을 완료합니다.

Vercel 대시보드에서 “Import Project” → GitHub 레포 선택
Framework Preset: Vite (자동 감지)
Build Command: npm run build (기본값)
Output Directory: dist (기본값)
Root Directory: / (기본값)

특별한 설정 없이 표준 Vite 프로젝트로 인식되었습니다.

2단계: 환경변수 설정

Vercel 대시보드의 Environment Variables 섹션에서 설정합니다. Vercel은 Production / Preview / Development 세 가지 환경을 분리하여 환경변수를 관리할 수 있습니다.

환경변수	Production	Preview	설명
`VITE_API_URL`	프로덕션 API URL	스테이징 API URL	백엔드 API 엔드포인트
`VITE_SUPABASE_URL`	Supabase URL	동일	Supabase 프로젝트 URL
`VITE_SUPABASE_ANON_KEY`	Anon Key	동일	Supabase 공개 키

코드에 fallback 값이 하드코딩되어 있어서 환경변수를 설정하지 않아도 빌드와 실행은 가능했습니다. 하지만 환경 분리를 위해 명시적으로 설정했습니다. 나중에 스테이징 백엔드를 별도로 운영할 경우, Preview 환경변수만 바꾸면 됩니다.

3단계: `vercel.json` 설정

SPA 라우팅을 위한 rewrite 규칙과 보안 헤더를 설정합니다.

{
  "rewrites": [
    { "source": "/((?!api/).*)", "destination": "/index.html" }
  ],
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "X-Content-Type-Options", "value": "nosniff" }
      ]
    }
  ]
}

rewrites 규칙이 핵심입니다. React Router를 사용하는 SPA에서 /dashboard, /report/123 같은 경로로 직접 접근하거나 새로고침할 때, Vercel이 해당 경로의 정적 파일을 찾지 못하면 404를 반환합니다. rewrite 규칙으로 모든 경로를 index.html로 리다이렉트하면, React Router가 클라이언트에서 라우팅을 처리합니다.

4단계: Preview 배포 테스트

Vercel에 연결하면 기본적으로 *.vercel.app 도메인에서 Preview 배포가 생성됩니다. 이 스테이징 환경에서 전체 기능을 테스트합니다.

테스트 체크리스트:

이 단계에서 OG 이미지 문제가 발견되었습니다. 아래 “문제 해결” 섹션에서 다룹니다.

5단계: `lovable-tagger` 제거

Lovable 전용 의존성을 제거합니다.

npm uninstall lovable-tagger

이후 vite.config.ts에서 lovable-tagger 플러그인 등록 코드를 삭제합니다. lovable-tagger는 Lovable 에디터에서 컴포넌트를 식별하기 위한 태깅 목적의 devDependency였으므로, 제거해도 런타임 동작에 영향이 없습니다.

제거 후 npm run build로 로컬 빌드가 정상적으로 완료되는지 확인했습니다.

6단계: DNS 전환

가장 신경 쓴 단계입니다. Cloudflare에서 wichi.app의 CNAME 레코드를 Lovable 호스팅에서 Vercel로 변경합니다.

sequenceDiagram
    participant User as 사용자
    participant CF as Cloudflare DNS
    participant L as Lovable 호스팅
    participant V as Vercel

    Note over CF: 전환 전: CNAME → Lovable
    User->>CF: wichi.app 요청
    CF->>L: CNAME 해석 → Lovable
    L->>User: 응답

    Note over CF: CNAME 변경 실행
    CF->>CF: CNAME → Vercel로 변경

    Note over CF: 전환 후: CNAME → Vercel
    User->>CF: wichi.app 요청
    CF->>V: CNAME 해석 → Vercel
    V->>User: 응답

    Note over CF: DNS 전파: TTL 60초 기준, 대부분 1분 이내 전환 완료

실행 절차:

Vercel 대시보드에서 커스텀 도메인(wichi.app) 추가
Vercel이 제공하는 CNAME 타겟 주소 확인
Cloudflare DNS에서 wichi.app의 CNAME 레코드를 Vercel 타겟으로 변경
Vercel 대시보드에서 도메인 검증 및 SSL 인증서 자동 발급 확인
curl -I https://wichi.app으로 응답 헤더 확인 (Vercel 서버 확인)

사전에 TTL을 60초로 낮춰둔 덕분에 DNS 전파는 약 2분 만에 완료되었습니다.

7단계: CORS 설정 업데이트

DNS 전환 후, 백엔드(FastAPI)의 CORS 설정을 업데이트합니다.

변경 항목	Before	After
허용 도메인 추가	—	`*.vercel.app` (Preview 배포 대응)
허용 도메인 유지	`wichi.app`	`wichi.app` (도메인 변경 없으므로 유지)
허용 도메인 제거	Lovable 도메인	—

wichi.app 도메인 자체는 변경되지 않았으므로, 프로덕션 환경의 CORS는 영향 없이 유지됩니다. 추가가 필요한 것은 Vercel의 Preview 배포 도메인(*.vercel.app)입니다. PR마다 생성되는 Preview URL에서 백엔드 API를 호출할 수 있어야 스테이징 테스트가 가능합니다.

8단계: 검증

전환 완료 후 검증 항목입니다.

https://wichi.app 정상 접근 확인
SSL 인증서 유효성 확인 (Let’s Encrypt, Vercel 자동 발급)
모든 주요 페이지 접근 및 기능 테스트
OG 이미지 정상 로딩 확인
백엔드 API 호출 정상 확인 (CORS 문제 없음)
Google Search Console에서 사이트 접근 가능 확인
GA4 이벤트 정상 수집 확인

문제 해결

OG 이미지 종속 문제

증상: Preview 배포에서 OG 이미지가 깨져 있었습니다. SNS에서 URL을 공유할 때 이미지가 표시되지 않는 상태.

원인: OG 이미지가 Lovable의 GCP Storage에 호스팅되어 있었습니다. HTML의 <meta property="og:image"> 태그가 Lovable GCP 버킷의 URL을 직접 참조하고 있었습니다.

# Before: Lovable GCP Storage URL
<meta property="og:image" content="https://storage.googleapis.com/lovable-uploads/..." />

Lovable 구독을 해지하면 이 URL이 무효화될 수 있습니다. 또한 외부 서비스에 의존하는 OG 이미지는 해당 서비스의 장애나 정책 변경에 영향을 받습니다.

해결: OG 이미지를 프로젝트 내부의 public/ 디렉토리로 이전했습니다.

# After: 자체 호스팅
<meta property="og:image" content="https://wichi.app/og-image.webp" />

public/og-image.webp에 이미지를 배치하면 Vercel 빌드 시 자동으로 정적 에셋으로 서빙됩니다. 외부 서비스 종속 없이 OG 이미지가 항상 유효합니다.

이 문제는 사전 분석에서 잡지 못한 항목이었습니다. Lovable의 GCP Storage 종속은 코드 레벨에서는 보이지 않고, HTML 메타 태그의 URL을 하나하나 확인해야 발견되는 문제입니다.

SPA rewrite 미적용

증상: Vercel에 배포 후 직접 URL로 접근하거나 새로고침 시 404 에러가 발생했습니다.

원인: vercel.json의 rewrite 규칙이 없었습니다. Lovable은 SPA 호스팅에 대한 rewrite를 자체적으로 처리해주고 있었기 때문에, 코드에 별도 설정이 없었습니다.

해결: vercel.json에 SPA rewrite 규칙을 추가했습니다. API 경로를 제외한 모든 요청을 index.html로 리다이렉트하는 규칙입니다.

환경변수 fallback

발견: 코드에 환경변수의 fallback 값이 하드코딩되어 있었습니다. 예를 들면 다음과 같은 패턴입니다.

const API_URL = import.meta.env.VITE_API_URL || "https://api.wichi.app"

이 패턴 때문에 Vercel에 환경변수를 설정하지 않아도 프로덕션 환경에서는 정상 동작합니다. 하지만 이것은 문제이기도 합니다. Preview 환경에서도 프로덕션 API를 호출하게 되므로, 스테이징과 프로덕션 간 격리가 되지 않습니다.

현재는 스테이징 백엔드가 별도로 없으므로 실질적인 문제는 아니지만, 추후 스테이징 환경을 분리할 때 코드에서 fallback 값을 제거하고 Vercel 환경변수에 의존하도록 변경해야 합니다.

전환 전후 비교

배포 파이프라인 비교

flowchart LR
    subgraph Before["Before: Lovable"]
        direction TB
        L1["Lovable 에디터에서 프롬프트 수정"] --> L2["Lovable 빌드"]
        L2 --> L3["자동 배포"]
        L4["Claude Code에서 코드 수정"] --> L5["git push"]
        L5 --> L6["Lovable에서 인식 안 됨"]
        L6 --> L7["수동 sync 필요"]
    end

    subgraph After["After: Vercel"]
        direction TB
        V1["코드 수정"] --> V2["git push / PR 생성"]
        V2 --> V3["Vercel 자동 빌드"]
        V3 --> V4["Preview Deploy 생성"]
        V4 --> V5["검토 후 merge"]
        V5 --> V6["Production 자동 배포"]
    end

Lovable 시절에는 두 개의 도구(Lovable 에디터 + Claude Code)가 각각 다른 경로로 코드를 수정하고, 이 두 경로의 동기화가 불완전했습니다. Vercel 전환 후에는 모든 코드 변경이 Git을 통해 단일 파이프라인으로 흐릅니다.

기능 비교

항목	Lovable	Vercel
배포 트리거	Lovable 에디터에서 수동	`git push` = 자동 배포
PR Preview	불가	PR마다 자동 생성, 고유 URL 부여
배포 이력	Lovable 내부에서 제한적 확인	대시보드에서 커밋 단위 추적, 빌드 로그 열람
롤백	수동 복원 (이전 상태로 되돌리기 어려움)	이전 배포 버전으로 원클릭 롤백
환경변수 관리	제한적	Production / Preview / Development 분리
빌드 설정	Lovable 내부 설정, 커스터마이징 제한	`vercel.json`으로 완전 제어
보안 헤더	설정 불가	`vercel.json`의 headers로 제어
CDN	Lovable 자체	Vercel Edge Network (글로벌)
도메인 SSL	Lovable 관리	Let’s Encrypt 자동 발급 및 갱신
빌드 로그	확인 어려움	실시간 빌드 로그 스트리밍

워크플로우 비교

시나리오	Lovable	Vercel
UI 컴포넌트 수정	Lovable 에디터에서 프롬프트 → 수동 push	코드 수정 → PR 생성 → Preview 확인 → merge
배포 오류 발견	Lovable 에디터에서 수동 수정 후 재배포	Vercel에서 이전 배포로 즉시 롤백, 이후 수정
새 기능 개발	Lovable(main) + Claude Code(dev) 하이브리드	단일 도구(Claude Code)로 feature 브랜치 작업
환경변수 변경	Lovable 설정 페이지 (제한적)	Vercel 대시보드, 환경별 독립 관리
빌드 실패 디버깅	Lovable 내부 에러 메시지 (정보 제한적)	Vercel 빌드 로그에서 전체 출력 확인

가장 체감이 큰 변화는 PR = Preview Deploy입니다. 코드 변경을 머지하기 전에 실제 배포 환경에서 확인할 수 있다는 것은, 1인 개발에서도 실수를 줄여주는 안전장치입니다.

마이그레이션 체크리스트

전체 작업을 체크리스트로 정리합니다. 비슷한 마이그레이션을 수행할 때 참고할 수 있도록 범용적인 형태로 작성했습니다.

사전 준비

전체 소스 코드가 GitHub에 있고, 외부 환경에서 빌드 가능한지 확인
플랫폼 전용 의존성 목록 파악 (lovable-tagger 등)
환경변수 전수 조사 및 목록화
DNS 현재 설정 확인 (CNAME 타겟, TTL 값)
롤백 계획 수립

실행

Vercel에 repo 연결 및 기본 설정
환경변수 설정 (환경별 분리)
vercel.json 작성 (rewrite, headers)
Preview 배포에서 풀 테스트
플랫폼 전용 의존성 제거 (lovable-tagger)
OG 이미지 로컬 이전
DNS TTL 사전 하향 (60초)
DNS CNAME 변경 (Cloudflare → Vercel)
SSL 인증서 발급 확인

후속 처리

백엔드 CORS 설정 업데이트
프로덕션 풀 테스트
GA4 이벤트 수집 확인
Search Console 접근 확인
README 배포 문서 업데이트
이전 플랫폼 구독 해지

이슈 로그

마이그레이션 과정에서 발생한 이슈를 시간순으로 기록합니다.

시점	이슈	심각도	해결 방법	소요 시간
Preview 테스트	OG 이미지 깨짐	중간	`public/`로 이미지 로컬 이전	15분
Preview 테스트	딥 링크 404	높음	`vercel.json` rewrite 규칙 추가	10분
DNS 전환 후	SSL 인증서 대기	낮음	Vercel 자동 발급, 약 1분 대기	1분
전환 완료 후	Preview 배포에서 CORS 에러	중간	백엔드에 `*.vercel.app` 도메인 추가	5분

소요 시간

전체 작업은 반나절 정도 소요되었습니다.

작업	소요 시간
Vercel 프로젝트 설정 + 환경변수	15분
`vercel.json` 작성	10분
Preview 배포 테스트	30분
`lovable-tagger` 제거 + 빌드 확인	10분
OG 이미지 이전	15분
DNS 전환 + 전파 대기	15분
CORS 업데이트	5분
프로덕션 검증	30분
문서 업데이트	20분
합계	약 2.5시간

시간이 가장 많이 든 부분은 테스트와 검증이었습니다. 코드 변경 자체는 적었고, 대부분 설정 파일 수정과 외부 서비스(DNS, CORS) 업데이트였습니다. DNS 전파 대기도 TTL을 사전에 낮춰둔 덕분에 빠르게 완료되었습니다.

회고

Lovable이 여전히 적합한 경우

Lovable에서 벗어났다고 해서 Lovable이 나쁜 도구라는 뜻은 아닙니다. 도구는 용도에 맞게 쓰면 됩니다.

상황	Lovable 적합도	이유
해커톤 / 프로토타이핑	높음	프롬프트 → UI 변환 속도가 압도적. 3일 안에 작동하는 프론트엔드를 만들어야 할 때 최적
디자인 탐색 단계	높음	여러 UI 변형을 빠르게 시도하고 비교할 수 있음
비개발자의 MVP 제작	높음	코드를 직접 작성하지 않고도 배포 가능한 프론트엔드를 만들 수 있음
프로덕션 호스팅	낮음	배포 제어, 환경 분리, 롤백, PR Preview 등 프로덕션 요구사항에 한계
장기 유지보수	낮음	Git-first 워크플로우 부재, 플랫폼 종속 의존성

WICHI의 경우 Lovable은 “0에서 1로 가는 단계”에서 명확한 가치를 제공했습니다. 해커톤 3일 동안 프론트엔드의 첫 버전을 뽑아낸 것은 Lovable 없이는 어려웠을 것입니다.

노코드/로코드 플랫폼 졸업 시점

Lovable에 한정되지 않는, 노코드/로코드 플랫폼에서 전통적 호스팅으로 전환하는 일반적인 기준을 정리합니다.

다음 중 3개 이상에 해당하면 전환을 검토할 시점입니다.

PR 기반 코드 리뷰가 필요해졌다 — 팀이 2명 이상이거나, 1인이라도 변경 이력 추적이 중요해진 경우
배포 설정을 직접 제어해야 한다 — 리다이렉트, 보안 헤더, 캐시 정책, 환경변수 분리 등
롤백이 필요하다 — 배포 후 문제 발생 시 즉시 이전 버전으로 되돌려야 하는 경우
플랫폼 비용이 대안 대비 비합리적이다 — 무료 또는 저비용 호스팅으로 동일한 기능을 얻을 수 있는 경우
플랫폼 종속 의존성이 코드에 축적되고 있다 — 전용 SDK, 플러그인, 설정 코드가 늘어나고 있는 경우
다른 도구와의 통합이 필요하다 — CI/CD, 모니터링, A/B 테스트 등 외부 서비스 연동

마이그레이션에서 배운 것

사전 분석의 한계를 인정할 것. OG 이미지의 Lovable GCP 종속은 사전 분석에서 잡지 못했습니다. 코드 레벨의 의존성은 package.json과 import 문을 검색하면 찾을 수 있지만, HTML 메타 태그에 박힌 외부 URL이나 CDN 경로 같은 암묵적 종속은 놓치기 쉽습니다.

다운타임 제로는 비현실적이되, 최소화는 가능하다. DNS 전환이 포함된 마이그레이션에서 다운타임 제로는 사실상 불가능합니다. 하지만 TTL 사전 하향, 스테이징 사전 검증, 롤백 계획 수립으로 다운타임을 분 단위로 줄일 수 있습니다.

플랫폼 전환은 빠를수록 좋다. 플랫폼 종속 의존성은 시간이 지날수록 축적됩니다. 전환이 필요하다고 판단되면 빨리 실행하는 것이 비용이 적습니다. WICHI의 경우 Lovable 종속이 lovable-tagger 하나와 OG 이미지 URL 정도로 제한적이었기 때문에 반나절 만에 전환을 완료할 수 있었습니다. 종속이 더 깊어진 후였다면 더 오래 걸렸을 것입니다.

전환 후 달라진 일상

전환 후 일상적인 개발 워크플로우가 어떻게 바뀌었는지 정리합니다.

작업	Before	After
컴포넌트 수정	Lovable 에디터 → 프롬프트 → push	코드 수정 → PR → Preview 확인 → merge
배포	Lovable 에디터에서 수동 트리거	`git push` = 자동. 별도 작업 불필요
배포 실패	Lovable 에러 메시지 확인 (정보 제한)	Vercel 빌드 로그에서 전체 에러 스택 확인
긴급 롤백	이전 상태를 수동으로 복원 (시간 소요)	Vercel 대시보드에서 이전 배포 선택 → 즉시 롤백
새 기능 검증	로컬에서만 확인 가능	PR 생성 시 Preview URL로 실 환경 확인

특히 PR Preview는 1인 개발에서도 가치가 큽니다. “로컬에서는 되는데 배포하면 안 되는” 문제를 머지 전에 잡을 수 있습니다. Vercel의 Preview Deploy는 프로덕션과 동일한 환경에서 실행되므로, 환경 차이로 인한 문제를 사전에 발견할 수 있습니다.

배경