AI로 만든 앱을 내보내고 직접 호스팅하는 법
AI로 만든 앱을 직접 호스팅하려면, 먼저 코드를 꺼내야 해요(다운로드하거나 여러분이 소유한 GitHub 저장소로 동기화). 그다음 앱의 시크릿을 환경 변수로 다시 만들고, 데이터베이스를 옮기거나 새로 만든 뒤, 앱의 성격에 맞는 호스트에 배포하세요. 단순한 프런트엔드라면 정적 호스트, 백엔드가 있다면 서버나 컨테이너를 실행하는 플랫폼이에요. 코드는 보통 가장 쉬운 부분이에요. 데이터, 시크릿, 그리고 빌더가 뒤에서 조용히 대신 실행해 주던 서비스들이 실제 작업이 있는 곳이에요.
왜 내보내야 할까
코드를 가지고 떠나는 데는 좋은 이유도 있고, 별로 좋지 않은 이유도 있어요.
좋은 이유:
- 소유권과 보험. 여러분의 저장소에 있는 코드 사본은 빌더가 요금, 기능, 약관을 바꿔도 여러분을 보호해요.
- 개발자에게 인계. 엔지니어링 팀은 자신들이 쓰는 도구와 리뷰 과정에서 Git으로 된 코드를 원할 거예요.
- 특정 요구사항. 데이터 거주 위치, 특정 클라우드 제공자, 회사 보안 정책, 빌더가 제공하지 않는 인프라 등이요.
- 규모나 비용. 직접 인프라를 운영하는 것이 정말로 이득이 되는 규모일 때요.
별로 좋지 않은 이유: 사용자가 몇 명 없는 작은 앱을 매달 소액 아끼려고 옮기는 경우예요. 직접 호스팅하면 일이 여러분에게 넘어와요. 업데이트, 백업, 모니터링, 보안 패치 같은 것들이요. 그것이 맞는 선택일 수도 있어요. 다만 알고서 결정하세요.
현실적인 절충안은 지금 있는 곳에서 계속 만들고 호스팅하되, 처음부터 여러분 소유의 GitHub 저장소로 동기화해 두는 것이에요. 운영 부담 없이 보험을 얻을 수 있어요. Git이 낯설다면 GitHub가 무엇인지를 먼저 읽어 보세요.
내보내기에 무엇이 들어 있고 무엇이 없는가
내보내기를 믿고 쓰기 전에 열어서 확인하세요. 보통은 다음과 같아요.
| 포함됨 | 보통 포함되지 않음 |
|---|---|
| 소스 코드(프런트엔드, 백엔드) | 시크릿 값(API 키, 비밀번호) |
설정 파일(package.json, Dockerfile, 빌드 설정) | 설치된 의존성(node_modules 등). 다시 설치됨 |
| 데이터베이스 스키마와 마이그레이션 파일(앱이 사용하는 경우) | 데이터베이스의 실제 데이터 |
| 프로젝트의 정적 자산 | 별도 스토리지에 올라간 사용자 업로드 파일 |
| 빌더가 관리하는 서비스: 호스팅, 도메인, 데이터베이스 서버, 파일 스토리지 |
시크릿은 의도적으로 빠져요. 이메일로 보내거나 커밋할 수 있는 아카이브에 실제 키가 들어 있으면 안 되기 때문이에요. 의존성은 잠금 파일에서 다시 만들어지므로 빠져요.
1단계: 코드 꺼내기
흔한 방법은 두 가지예요.
- 프로젝트 아카이브 다운로드. 빠르고, 일회성 이동이나 백업에 충분해요.
- GitHub로 동기화. 지속적으로 쓸 거라면 더 나아요. 전체 이력이 남고, 어디서든 클론하기 쉬우며, 대부분의 호스트가 푸시할 때마다 GitHub 저장소에서 바로 배포해요.
어느 쪽이든 컴퓨터(또는 클라우드 개발 환경)에 클론하거나 압축을 풀고 README가 있는지 찾아보세요. 없다면 떠나기 전에 빌더의 AI에게 작성해 달라고 하세요.
이 플랫폼 밖에서 이 프로젝트를 실행하기 위한 README를 작성해 줘. 스택, 필요한 런타임 버전, 설치와 빌드 명령, 시작 명령과 포트, 코드가 읽는 모든 환경 변수(이름과 용도만, 값은 제외), 그리고 데이터베이스 마이그레이션을 실행하는 방법을 포함해 줘.
이 프롬프트 하나가 몇 시간을 아껴 줘요. 암묵적이던 설정 부분을 글로 쓰게 강제하기 때문이에요.
2단계: 먼저 로컬에서 실행하기
어디에든 배포하기 전에, 앱이 혼자서 실행된다는 것을 확인하세요.
- README가 명시한 런타임을 설치하세요. Node.js, Python, Java, .NET 등 맞는 버전으로요.
- 의존성을 설치하세요(
npm install,pnpm install,pip install -r requirements.txt, 또는 이에 준하는 명령). - 환경 변수를 넣은 로컬
.env파일을 만드세요. 가능하면 테스트 키를 쓰고, Git에 올라가지 않게 하세요. 환경 변수와 시크릿이 무엇인지에서 개념을 설명해요. - 데이터베이스에 연결하세요. 로컬 Postgres나 관리형 제공자의 무료 개발용 데이터베이스를 쓰면 돼요.
- 마이그레이션을 실행한 다음 앱을 시작하고 주요 흐름을 직접 눌러 보세요.
여기서 깨지는 것은 호스트에서도 깨져요. 그리고 내 컴퓨터에서 디버깅하는 것이 훨씬 쉬워요. 흔한 놀라움은 다음과 같아요. 빌더의 미리보기 주소가 하드코딩되어 있거나, 빌더가 자동으로 주입하던 환경 변수가 없거나, 플랫폼에만 존재하던 서비스(파일 스토리지, 이미지 리사이징)가 있는 경우예요.
3단계: 데이터 옮기기
앱에 실제 사용자가 있다면 코드보다 데이터가 더 중요해요.
- 데이터베이스 내보내기. Postgres라면
pg_dump가 파일을 만들고, 이를pg_restore나psql로 새 데이터베이스에 복원할 수 있어요. 직접 접근 권한이 없다면 빌더의 AI에게 실행해 달라고 하고, 만들어진 결과가 무엇인지 설명해 달라고 하세요. - 업로드 파일 옮기기. 사용자가 올린 이미지나 문서는 데이터베이스와 분리된 객체 스토리지에 있어요. 새 스토리지(예: S3 호환 버킷)로 복사하고, 저장된 URL에 예전 호스트가 들어 있다면 업데이트하세요.
- 전환 계획 세우기. 라이브 앱이라면 간단한 방법은 짧은 점검 시간을 두는 거예요. 쓰기를 멈추고, 마지막 내보내기를 받고, 새 호스트에 복원하고, DNS를 전환한 다음, 다시 열어요. 각 단계를 먼저 적어 두세요.
- 실제 이전 전에 복원 테스트하기. 임시 데이터베이스에 복원해 보세요.
Postgres가 익숙하지 않다면 Postgres가 무엇인지에서 기본을 다뤄요.
4단계: 어디에 호스팅할지 고르기
호스트를 앱의 형태에 맞추세요. 아래 이름은 2026년 9월 기준 각 범주의 잘 알려진 제공자 예시이며 순위가 아니에요. 현재 기능과 가격은 각 사이트에서 확인하세요.
| 앱 형태 | 필요한 것 | 예시 호스트 |
|---|---|---|
| 정적 사이트 또는 SPA (HTML, CSS, JS만) | CDN이 있는 파일 호스팅 | Netlify, Vercel, Cloudflare Pages, GitHub Pages |
| 풀스택 프레임워크 (Next.js 등) | 서버 또는 서버리스 함수 | Vercel, Netlify, Render, Railway |
| API 또는 백엔드 (Node, Python, Java, C#) | 항상 켜져 있거나 0으로 확장되는 서버 | Render, Railway, Fly.io, 클라우드 컨테이너 서비스 |
| Dockerfile이 있는 모든 앱 | 컨테이너 런타임 | Fly.io, Render, Railway, AWS, Google Cloud, Azure |
| 완전한 통제 | 직접 관리하는 가상 서버 | DigitalOcean, Hetzner, Linode, 또는 어떤 클라우드 VM |
다음도 필요할 거예요.
- 관리형 데이터베이스. 많은 앱 호스트가 Postgres를 제공하고, Neon이나 Supabase 같은 전문 서비스는 단독으로 제공해요. 관리형은 가치가 있어요. 백업과 업데이트를 다른 사람이 해 주니까요.
- 업로드용 객체 스토리지. 앱에 업로드 기능이 있다면 필요해요.
- 이메일 발송, 결제, AI 제공자. 보통 같은 API 키를 새 호스트에 설정하기만 하면 돼요.
절충점을 공정하게 말하자면, 플랫폼 호스트(위 네 줄)는 설정과 유지보수가 빠르지만 통제권이 적고 트래픽이 늘면 비용도 올라갈 수 있어요. 가상 서버는 꾸준한 부하에서 더 저렴하고 완전히 통제할 수 있지만, 패치, TLS, 백업, 모니터링, 복구를 여러분이 떠안아요. 팀에서 그 일을 맡을 사람이 없다면 플랫폼을 고르세요. 호스팅의 기본을 알고 싶다면 웹 호스팅이 무엇인지를 보세요.
5단계: 배포하고 전환하기
- 저장소를 호스트에 연결하거나 컨테이너 이미지를 푸시하세요.
- 호스트 대시보드에서 환경 변수를 설정하세요. README에 있는 모든 변수를 실제 값으로요.
- 빌드 명령과 시작 명령, 포트를 설정하세요. 많은 호스트가
PORT환경 변수로 포트를 전달해요. 앱은 그 포트를 듣고,localhost만이 아니라 모든 인터페이스(0.0.0.0)에서 수신해야 해요. - 새 데이터베이스에 대해 마이그레이션을 실행하세요.
- DNS를 건드리기 전에 호스트의 임시 URL에서 테스트하세요.
- 예전 URL을 가리키는 외부 서비스를 업데이트하세요. 결제 웹훅, 로그인용 OAuth 리디렉션 URL, 이메일 링크, 허용 오리진 등이요.
- DNS 레코드를 새 호스트로 바꿔 도메인을 옮기세요. 커스텀 도메인 연결하는 법에서 레코드를 설명해요.
- 확실해질 때까지 이전 배포를 잠시 유지한 다음 내리세요.
여섯 번째 단계는 가장 자주 잊히는 단계예요. 이전 뒤에 로그인이나 결제가 조용히 실패한다면, 대부분 아직 예전 호스트를 가리키는 콜백 URL이 원인이에요.
6단계: 운영 책임 가져오기
직접 호스팅하면 빌더가 처리하던 일이 여러분의 일이 돼요. 최소한 다음이 필요해요. 테스트된 복원이 가능한 자동 데이터베이스 백업, 오류 추적, 가동 시간 알림, 의존성 업데이트, 누가 각 계정에 접근할 수 있는지에 대한 기록이에요. AI 프로토타입을 프로덕션으로 가져가는 법에서 이 목록을 더 자세히 다뤄요.
내보내기 체크리스트
- 여러분이 소유한 저장소에 코드가 있고, 실행·빌드·환경 변수를 다룬 README가 있음
- 깨끗한 클론에서 앱이 로컬로 실행됨
- 데이터베이스를 내보내고 복원을 테스트했으며, 업로드 파일을 복사함
- 앱 형태에 맞는 호스트를 골랐고, 관리형 데이터베이스와 스토리지를 함께 준비함
- 새 호스트에 모든 환경 변수를 실제 값으로 설정함
- 웹훅, OAuth 리디렉션, 이메일 링크를 업데이트함
- DNS를 전환했고, 이전 배포는 잠시 유지한 뒤 제거함
- 백업, 모니터링, 접근 권한 목록을 갖춤
Mythex에서 내보내기
Mythex에서는 여러분이 만든 코드를 소유해요. Pro 요금제에서는 프로젝트 설정 → 내보내기에서 프로젝트를 아카이브로 내려받거나, GitHub를 연결해 여러분의 저장소에 푸시하고 풀할 수 있어요. 무료 요금제는 코드를 읽기 전용으로 볼 수는 있지만 내보내기나 동기화는 할 수 없어요. 내보내기에서는 시크릿과 node_modules가 빠지므로 새 호스트에서 시크릿을 다시 만들어야 해요. 내보내서 다른 곳에서 실행하기와 GitHub, 내보내기와 가져오기 문서에 단계가 나와 있어요. Mythex에서 계속 호스팅하면서 GitHub 동기화를 여러분만의 사본과 인계 경로로만 써도 돼요. 옮기기로 했다면 새 호스트가 라이브가 된 뒤에 Mythex 앱을 게시 취소하세요.
자주 묻는 질문
AI 앱 빌더에서 코드를 내보낼 수 있나요?
도구와 요금제에 따라 달라요. 어떤 빌더는 프로젝트 전체를 내려받거나, 여러분이 소유한 GitHub 저장소로 동기화하게 해 줘요. 다른 빌더는 앱을 플랫폼 안에 두죠. 몇 달을 투자하기 전에 확인하고, 내보내기에 무엇이 포함되고 무엇이 빠지는지 꼭 읽어 보세요.
내보내기에 데이터베이스와 API 키도 포함되나요?
보통 코드는 내보내지만 데이터와 시크릿은 포함되지 않아요. 비밀 키는 대개 의도적으로 빠지고, 데이터베이스 내용은 Postgres라면 pg_dump 같은 별도의 내보내기가 필요해요. 호스트를 옮기기 전에 둘 다 계획해 두세요.
내보낸 앱은 어디에 호스팅해야 하나요?
정적 프런트엔드는 Netlify, Vercel, Cloudflare Pages 같은 정적 호스트에 잘 맞아요. 자체 서버가 있는 앱은 Render, Railway, Fly.io처럼 코드나 컨테이너를 실행하는 플랫폼이나, 직접 관리하는 가상 서버가 필요해요. 앱에 데이터베이스가 있다면 관리형 데이터베이스도 필요해요.
직접 호스팅하는 것이 빌더에 계속 머무는 것보다 저렴한가요?
규모가 클 때는 그럴 수 있어요. 작은 앱이라면 데이터베이스, 이메일, 모니터링, 유지보수에 쓰는 여러분의 시간까지 계산하면 차이가 작은 경우가 많아요. 매달 몇 달러를 아끼려고 옮기기보다는 통제권이나 특정 요구사항 때문에 옮기세요.