Lovable Cloud 외부에 배포하고 호스팅하기
Lovable 애플리케이션을 Lovable Cloud 외부에서 배포하고 호스팅하는 일반적인 방법을 관리형 플랫폼과 셀프 호스팅 인프라 예시와 함께 설명합니다.
이 가이드는 Lovable 애플리케이션을 Lovable Cloud 외부에서 배포하고 호스팅하는 실용적인 예시와 방법을 제공합니다.
Lovable Cloud의 배포, 호스팅, 소유권 옵션에서 설명한 개념을 기반으로 하며, 가장 일반적인 마이그레이션 경로에 초점을 맞춥니다. 각 시나리오를 독립적으로, 원하는 순서대로 적용할 수 있습니다.
이 가이드에서 호스팅은 애플리케이션이 실행되는 위치를, 배포는 코드가 빌드되어 해당 환경으로 전달되는 방법을 의미합니다.
모든 것을 Lovable Cloud에서 실행할 계획이라면 이 가이드는 필요 없습니다.
마이그레이션 전 확인 사항
이 가이드는 컴플라이언스 제약, 데이터 레지던시 요구사항, 또는 조직의 인프라 정책 등 특정 요구사항으로 인해 애플리케이션의 일부를 Lovable Cloud 외부에서 실행해야 하는 팀을 위한 것입니다.
Lovable Cloud는 이미 통합된 개발 및 프로덕션 환경을 제공합니다:
- 커스텀 도메인 및 자동 SSL이 포함된 프로덕션 호스팅
- 자동 배포 및 환경 관리
- Row Level Security가 적용된 관리형 인증
- 데이터베이스 및 파일 스토리지
- 모든 변경에 대한 자동 프리뷰 환경
- 프리뷰 및 개발 환경에서 디버깅 가능한 AI 에이전트
- 런타임 기능을 위한 관리형 AI 제공업체 접근
- 내장 OAuth 구성 및 토큰 자동 갱신
- 보안 스캐닝 및 컴플라이언스 대응 인프라
대부분의 팀은 마이그레이션할 필요가 없습니다.
사전 조건: GitHub에 프로젝트 연결
이 가이드의 모든 시나리오는 프로젝트를 GitHub에 연결해야 합니다.
GitHub을 연결하면:
- Lovable 프로젝트가 리포지토리와 지속적으로 동기화됩니다
- 외부 플랫폼이 GitHub에서 직접 배포합니다
- Lovable은 독립적으로 개발, 프리뷰, 도구를 계속 관리합니다
이후 내용은 프로젝트가 GitHub에 연결되어 있다고 가정합니다.
관리형 플랫폼에 프로덕션 프론트엔드 호스팅
Lovable Cloud 외부로 이전할 때 가장 흔한 첫 단계입니다.
프로덕션 프론트엔드를 관리형 호스팅 플랫폼에 배포하면서, 개발과 프리뷰에는 Lovable을 계속 사용합니다. 백엔드와 데이터는 Lovable Cloud에 남기거나 다른 곳으로 이전할 수 있습니다.
직접 관리해야 할 항목
프로덕션 프론트엔드를 Lovable Cloud 외부에서 실행하면 다음을 직접 관리해야 합니다:
- 프론트엔드 배포 파이프라인 및 롤백
- 프로덕션 환경 변수
- CDN 동작 및 캐싱
- 프론트엔드 가용성 및 업타임
- 프로덕션 로그 및 배포 이력
- 프로덕션 브랜치 또는 릴리스용 프리뷰 환경
Lovable은 자사가 관리하지 않는 프로덕션 인프라를 모니터링하거나 디버깅할 수 없습니다.
일반적인 접근 방식
- Git 기반 호스팅 플랫폼
GitHub 리포지토리에 직접 연결하여 푸시할 때마다 자동으로 빌드하고 배포하는 플랫폼입니다:- Netlify
- Cloudflare Pages
- Vercel
- AWS Amplify Hosting
- Azure Static Web Apps
- Google Firebase Hosting
- 오브젝트 스토리지 + CDN 호스팅
CDN 뒤에서 정적 파일을 호스팅하지만,dist/출력을 생성하고 업로드하는 빌드 파이프라인이 필요합니다.- AWS: S3 + CloudFront
- Google Cloud: Cloud Storage + Cloud CDN
- Azure: Azure Storage (Static Website) + Azure CDN 또는 Front Door
Git 기반 호스팅 플랫폼에 배포하기
GitHub 리포지토리에서 자동으로 빌드하고 배포하는 플랫폼에 적용되는 방식입니다.
오브젝트 스토리지 + CDN에 CI/CD로 배포하기
CDN 기반 호스팅은 앱을 빌드하고 dist/ 출력을 업로드하는 CI/CD 파이프라인이 필요합니다. 빌드 단계는 제공업체와 관계없이 동일하며, 배포는 제공업체별로 다릅니다. 각 플랫폼의 공식 문서 링크를 참고하세요.
자체 인프라에 프로덕션 프론트엔드 호스팅
프론트엔드 호스팅, 네트워킹, 런타임 환경을 완전히 제어해야 할 때 사용합니다. 흔히 셀프 호스팅이라고 합니다.
프론트엔드를 GitHub 리포지토리에서 빌드하고, 직접 관리하는 인프라에 배포합니다. 백엔드와 데이터는 Lovable Cloud에 남기거나 다른 곳으로 이전할 수 있습니다.
직접 관리해야 할 항목
프로덕션 프론트엔드를 직접 관리하는 인프라에서 실행하면 다음을 책임져야 합니다:
- 빌드 및 배포 자동화
- SSL/TLS 구성
- CDN 및 리버스 프록시 구성
- 모니터링, 로깅, 업타임
- 인프라 업데이트 및 보안
- 브랜치 또는 릴리스용 프리뷰 환경
Lovable은 자사가 관리하지 않는 프로덕션 인프라를 모니터링하거나 디버깅할 수 없습니다.
일반적인 접근 방식
- 컨테이너 기반 배포
예: Kubernetes (EKS, GKE, AKS), ECS, Nomad 또는 내부 컨테이너 플랫폼을 통한 Docker 배포 - 웹 서버를 실행하는 가상 머신
예: Nginx나 Apache가 실행 중인 Linux VM, 구성 관리 또는 내부 도구로 관리 - 내부 PaaS 플랫폼
예: 사내 배포 플랫폼 또는 프라이빗 클라우드 PaaS 솔루션
빌드 요구 사항
Lovable 프로젝트는 표준 Vite 애플리케이션이며 정적 프론트엔드로 빌드됩니다.
- 빌드 명령어:
npm run build - 출력 디렉터리:
dist/ - Node 버전: 22 권장
VITE_ 접두사가 붙은 환경 변수는 런타임이 아닌 빌드 타임에 포함됩니다.
백엔드로 Lovable Cloud를 사용하는 경우, npm run build 실행 전에 다음 변수를 설정해야 합니다:
VITE_SUPABASE_URLVITE_SUPABASE_PUBLISHABLE_KEY
이 값은 프로젝트의 .env 파일에서 확인할 수 있습니다.
컨테이너 기반 배포 (Docker)
VM 또는 정적 서버 배포
관리형 제공업체에 백엔드·데이터 호스팅 (Supabase 예시)
데이터베이스에 직접 접근하거나, 고급 데이터베이스 기능이 필요하거나, 인프라 소유권을 보다 명확하게 분리하면서도 완전한 운영 책임은 지지 않으려 할 때 선택하는 옵션입니다.
백엔드 서비스와 데이터베이스를 관리형 백엔드 제공업체로 이전합니다. 가장 직접적인 마이그레이션 경로는 관리형 Supabase로, Lovable Cloud의 기본 백엔드 아키텍처와 가장 유사합니다. 프로덕션 프론트엔드는 Lovable Cloud에서 실행하거나 다른 곳으로 이전할 수 있습니다.
마이그레이션 후:
- 프로덕션 프론트엔드가 새 백엔드를 가리켜야 합니다
- 개발 중에는 Lovable 에디터와 프리뷰 환경을 계속 사용할 수 있습니다
이 가이드에서 Supabase를 기본 마이그레이션 경로로 사용하는 이유는, Lovable 애플리케이션이 인증, 스토리지, Realtime, Edge Functions, Row Level Security 등 Supabase 호환 서비스에 의존하기 때문입니다.
다른 백엔드 플랫폼으로의 마이그레이션도 가능하지만, 제공업체에 따라 동등한 인증, 스토리지, 백엔드 서비스를 직접 구현해야 할 수 있습니다.
아래 상세 단계는 Lovable Cloud에서 관리형 Supabase 인스턴스로 프로젝트를 마이그레이션하는 방법을 설명합니다.
직접 관리해야 할 항목
백엔드를 Lovable Cloud 외부에서 실행하면, Lovable이 이전에 관리하던 백엔드 기능을 직접 책임져야 합니다:
- 데이터베이스 가용성, 스케일링, 백업
- 백엔드 모니터링 및 인시던트 대응
- Row Level Security 설정 및 유지보수
- 인증 제공업체 구성
- OAuth 자격증명, 리다이렉트 URL, 시크릿 로테이션
- 백엔드 환경 변수 및 설정
- 잘못된 설정과 노출된 시크릿에 대한 보안 스캐닝
- 백엔드 인프라의 컴플라이언스 수준
Lovable은 자사가 관리하지 않는 백엔드 인프라를 모니터링하거나 디버깅할 수 없습니다. 관리형 OAuth 구성 및 자동 토큰 갱신은 백엔드가 Lovable Cloud에서 실행될 때만 사용 가능합니다.
마이그레이션 대상 및 방법
| 앱 구성 요소 | 마이그레이션 방법 | 비고 |
|---|---|---|
| 데이터베이스 스키마 | SQL 마이그레이션으로 자동 | 테이블, 컬럼, 인덱스, RLS 정책, 함수, 트리거 포함 |
| 스토리지 버킷 | SQL 마이그레이션으로 자동 | 접근 정책 포함 |
| 인증 제공업체 | 수동 | 새 호스팅 환경에서 인증(예: Google OAuth, GitHub) 재설정 |
| 환경 변수 및 시크릿 | 수동 | 외부 서비스(예: Stripe)의 API 키, 토큰, 자격증명을 새 호스팅 환경에서 재설정 |
| 데이터 (테이블 내용) | 수동 | CSV로 내보내기/가져오기 |
| 스토리지 파일 | 수동 | 수동 다운로드/업로드 |
| 사용자 계정 | 수동, 부분적 | 데이터베이스에서 사용자 데이터를 내보낼 수 있지만, 비밀번호는 내보낼 수 없으므로 비밀번호 재설정 플로우가 필요합니다. 실제 사용자를 온보딩하기 전에 마이그레이션을 계획하는 것을 권장합니다. |
제공업체별 상세 내용은 Supabase 공식 문서를 참고하세요.
자체 인프라에 백엔드·데이터 호스팅 (Supabase 예시)
엄격한 컴플라이언스, 데이터 레지던시, 또는 인프라 제어 요구사항이 있을 때 사용하는 옵션입니다.
직접 운영하는 인프라에서 백엔드와 데이터베이스를 실행합니다. 가장 직접적인 셀프 호스팅 경로는 셀프 호스팅 Supabase로, Lovable 애플리케이션이 의존하는 인증, 스토리지, Realtime, Edge Function 서비스를 제공합니다.
프로덕션 프론트엔드는 Lovable Cloud에 남기거나 다른 곳으로 이전할 수 있습니다. 개발에 Lovable을 계속 사용하거나, 다른 도구로 완전히 전환할 수도 있습니다.
동등한 인증, 스토리지, Realtime, Edge 서비스를 직접 구현하지 않는 한, 단독 PostgreSQL 데이터베이스만으로는 충분하지 않습니다.
직접 관리해야 할 항목
백엔드를 직접 운영하는 인프라에서 실행하면, Lovable이 이전에 관리하던 백엔드 기능을 직접 책임져야 합니다:
- PostgreSQL 운영, 백업, 재해 복구
- 인증, 스토리지, Realtime 서비스 가용성 및 안정성
- Row Level Security 설계 및 적용
- 보안 패치 적용 및 버전 업그레이드 관리
- Edge Function 배포 및 실행
- 성능 튜닝 및 스케일링
- 모니터링, 알림, 인시던트 대응
- 인프라의 컴플라이언스 인증
Lovable은 셀프 호스팅 인프라의 어떤 부분도 모니터링, 운영, 디버깅하지 않으며, 셀프 호스팅 프로덕션 환경에 대한 프로덕션 프리뷰를 생성하지 않습니다.
Supabase를 셀프 호스팅할 때 일반적인 과정:
-
Supabase 공식 Docker 셀프 호스팅 가이드를 따라 자체 인프라에 Supabase를 배포합니다.
-
PostgreSQL, 인증, 스토리지, 필요한 서비스를 구성합니다.
-
Lovable 프로젝트의 마이그레이션 파일(
supabase/migrations/)을 셀프 호스팅 인스턴스에 적용합니다. -
애플리케이션 환경 변수를 셀프 호스팅 Supabase를 가리키도록 업데이트합니다:
VITE_SUPABASE_URL=https://your-self-hosted-domain.com VITE_SUPABASE_PUBLISHABLE_KEY=your-anon-key
상세 인프라 구성 및 운영 가이드는 Supabase 공식 셀프 호스팅 문서를 참고하세요.
Lovable을 사용한 Docker 배포 설정 생성
Lovable은 세 가지 패턴으로 Docker 및 Docker Compose 구성을 생성할 수 있습니다:
프론트엔드만
React 앱을 Nginx로 제공되는 정적 사이트로 패키징합니다. 프론트엔드만 이전할 때 사용합니다.
예시 프롬프트: "이 프로젝트를 Nginx를 사용한 프론트엔드 전용 배포로 Docker화해주세요"
백엔드만 (셀프 호스팅 Supabase)
프론트엔드를 번들하지 않고 전체 Supabase 스택을 실행합니다. 프론트엔드를 별도로 개발할 때 유용합니다.
예시 프롬프트: "프론트엔드 컨테이너 없이 셀프 호스팅 Supabase 백엔드만 위한 Docker Compose 설정을 생성해주세요"
풀 스택
프론트엔드와 셀프 호스팅 Supabase를 단일 Docker Compose 설정으로 번들합니다. 완전히 자체 포함된 배포에 사용합니다.
예시 프롬프트: "이 프로젝트를 셀프 호스팅 Supabase 백엔드가 Docker Compose에 번들된 형태로 Docker화해주세요"
셀프 호스팅 Supabase 수동 구성
에이전트는 교체가 필요한 플레이스홀더 시크릿을 생성합니다:
- JWT 시크릿 생성:
openssl rand -base64 32 - JWT 시크릿을 사용하여 API 키 생성 (Supabase 문서 참고)
docker-compose.yml에서 다음을 교체:JWT_SECRETPOSTGRES_PASSWORDANON_KEYSERVICE_ROLE_KEY
제한 사항
- 에이전트는 Docker 빌드를 실행하거나 테스트할 수 없습니다 (로컬에서 직접 확인해야 합니다)
- 에이전트는 실제 시크릿을 생성할 수 없습니다 (플레이스홀더를 수동으로 교체해야 합니다)