호스트를 고르고 배포하기
대부분의 바이브 코딩 앱에는, 당신이 돌보아야 하는 서버가 필요 없다. 현대 플랫폼은 당신의 코드를 받아 몇 분 만에 라이브 을 준다. 흔한 선택지:
- 정적 사이트와 프론트엔드: Cloudflare Pages, Vercel, Netlify, GitHub Pages.
- 풀스택 앱과 (애플리케이션 프로그래밍 인터페이스, 한 프로그램이 다른 프로그램과 대화하는 데 쓰는 출입구): Cloudflare Workers, Vercel, Render, Fly.io, Railway.
- 더 무거운 백엔드: 컨테이너 플랫폼이나 작은 VPS(버추얼 프라이빗 서버, 데이터 센터에 늘 켜져 있는 컴퓨터의 한 조각을 빌려 쓰는 당신만의 몫).
올바른 수는 당신이 무엇을 만들었는지 AI에게 말하고 추천하게 두는 것이다. 시도해보라: "이건 Postgres 데이터베이스를 쓰는 Next.js 앱이다. 넉넉한 무료 티어가 있는, 가장 싸고 믿을 만한 호스트를 원한다. 배포 단계와 설정 파일을 달라." 선택을 실제로 제약하는 것들에 대해 구체적으로 말하라: 당신의 프레임워크, 데이터베이스가 있는지, 백그라운드 작업이나 파일 업로드가 필요한지, 그리고 예산. 정적 마케팅 페이지와 큐를 가진 풀스택 앱은 사는 집이 아주 다르다.
하나를 고르고 나면, 배포는 보통 명령 몇 개다:
# 예시: Wrangler를 통한 Cloudflare Workers
npm install -g wrangler
wrangler login
wrangler deploy
# 예시: Vercel
npm install -g vercel
vercel --prod
플랫폼 설정(wrangler.toml, vercel.json 등)은 AI가 생성하게 하고, 첫 배포가 던지는 에러를 설명하게 하라. 첫 배포는 거의 항상 무언가를 던진다 — 누락된 빌드 명령, 잘못된 출력 디렉터리, Node 버전 불일치, 빌드가 필요로 하는데 찾지 못하는 환경 변수(코드 바깥에서 앱에 건네지는, 이름이 붙은 설정값 — 현관 매트 밑에 둔 열쇠처럼 앱이 어디서 찾아야 하는지 알고 있는 것). 이 중 어느 것도 당신이 멍청한 짓을 했다는 뜻이 아니다; 플랫폼에 한 가지를 더 말해줘야 한다는 뜻이다. 에러를 그대로 다시 붙여 넣고 수정을 요청하되, 왜 일어났는지도 물어서 다음 번엔 덜 놀라게 하라. 두세 번 돌면 임시 URL에서 라이브가 된다. 축하하기 전에 그 URL을 열어 핵심 흐름을 클릭해 보라 — "배포가 성공했다"와 "앱이 동작한다"는 같은 주장이 아니다.
모든 배포는 같은 파이프라인을 걷는다. 프리뷰 단계가 당신의 안전망이다: 모든 변경이 진짜 사용자에게 닿기 전에, 클릭해 볼 수 있는 자기만의 URL을 갖는다.
내 컴퓨터 플랫폼
┌──────────────┐
│ 코드 작성 │
│ git commit │
│ git push │
└──────┬───────┘
│ push
▼
┌──────────────┐ 실패 ┌──────────────────┐
│ BUILD ├─────────▶│ 에러 읽고, │
│ 의존성 설치 │ │ 고쳐서 다시 push│
│ 컴파일 │◀─────────┤ (2~3회 반복) │
└──────┬───────┘ 재시도 └──────────────────┘
│ 통과
▼
┌──────────────┐
│ PREVIEW │ 임시 URL — 여기서 핵심 흐름을 클릭
│ *.pages.dev │ ── 공유 · 테스트 · 검증 ───┐
└──────┬───────┘ │
│ 괜찮아? ──── 아니오 ──────────────┘
│ 예
▼
┌──────────────┐
│ PRODUCTION │ 실제 도메인 · 실제 사용자
└──────────────┘