Replit Agent로 만든 앱을 프로덕션으로 옮기는 법 — Vercel, Railway, Fly.io 비용·난이도·워크로드별 선택 가이드 2025

Replit Agent 써보셨나요? 자연어 몇 줄 입력했더니 로그인 기능에 DB까지 붙은 풀스택 앱이 뚝딱 나오는 경험, 솔직히 처음엔 좀 놀랐습니다. 프롬프트 몇 개로 이 정도가 나오다니 싶었는데, 막상 코드를 뜯어보니 환경 변수가 하드코딩되어 있거나 SQL 쿼리에 인젝션 가능성이 열려 있는 경우가 꽤 있더라고요. 아이디어 검증엔 완벽하지만, 그대로 프로덕션에 올리는 건 다른 이야기입니다.

"이걸 이제 어디다 올리지?" 하는 순간은 반드시 옵니다. Replit 플랫폼 안에서 돌리는 건 데모용으론 괜찮지만, 실제 사용자한테 URL 하나 던져주기엔 플랫폼 종속성도 걸리고 비용 구조도 불투명합니다. 참고로 Replit의 Hacker 플랜($7/월)은 Always-On 앱이 1개로 제한되고, 트래픽이 늘면 비용이 급격히 올라가는 구조예요.

이 글에서는 Replit Agent로 만든 앱을 프로덕션으로 옮길 때 Vercel, Railway, Fly.io 세 플랫폼을 비용·난이도·워크로드 기준으로 어떻게 고르면 되는지 실전 마이그레이션 흐름과 함께 정리했습니다. 2025년 기준 AI 생성 코드의 약 24.7%에 보안 결함이 존재한다는 연구 결과도 있어서 (출처: How to Secure Vibe Coded Applications in 2026 — DEV Community), 단순히 "어디에 올릴까"보다 "어떻게 안전하게 올릴까"까지 함께 다루겠습니다. Node.js/Python 기반 앱 개발 경험이 있고, Git·CLI·환경 변수 개념에 익숙한 분을 대상으로 합니다.

핵심 개념

Replit Agent가 만든 코드, 프로덕션에 그냥 올리면 안 되는 이유

Replit Agent는 인증·데이터베이스·호스팅을 통째로 내장해서 빠르게 앱을 만들어줍니다. 근데 이 편리함 뒤에 몇 가지 함정이 있어요.

첫째, .replit과 replit.nix 파일은 Replit 런타임 전용 설정입니다. 다른 플랫폼에서는 완전히 무의미하고, 오히려 빌드를 꼬이게 만들 수 있어요. 둘째, Replit 내장 Key-Value 스토어(Replit DB — SQLite 기반의 간단한 키-값 저장소입니다)는 표준 PostgreSQL이나 Redis가 아니라서 다른 플랫폼에서 그냥 접근할 수 없습니다. 마치 로컬 파일처럼 Replit 환경 안에서만 존재하는 거예요. 셋째 — 그리고 이게 제일 중요한데 — AI가 생성한 코드는 로직 오류율이 인간 작성 코드 대비 2.74배 높다는 연구 결과가 있습니다 (출처: DEV Community, 2026). SQL 인젝션이나 환경 변수 하드코딩 같은 취약점이 조용히 숨어 있을 수 있어요.

Vibe Coding: 자연어 프롬프트로 AI에게 코드 전체를 맡기는 개발 방식. 빠른 프로토타이핑에 강하지만, 보안·품질 검토 없이 프로덕션에 올리면 사고로 이어질 수 있습니다. 비유하자면, 요리사가 다 만들어놓은 음식을 시식도 안 하고 손님상에 올리는 것과 비슷합니다.

프로덕션 이전의 공통 준비 단계

플랫폼을 고르기 전에 어떤 플랫폼이든 공통으로 거쳐야 하는 단계가 있습니다.

# 1. Replit 프로젝트를 GitHub 레포지토리로 푸시
git init
git remote add origin https://github.com/your-org/your-app.git
git push -u origin main
 
# 2. Replit 전용 파일 제거 (필수!)
# git rm을 쓰면 삭제와 스테이징이 한 번에 처리됩니다
git rm .replit replit.nix
git commit -m "remove Replit-specific files"
 
# 3. 환경 변수 목록 정리 (Replit Secrets → 대상 플랫폼 이전)
# .env.example 파일을 만들어 KEY 목록만 커밋해두면 나중에 편합니다
 
# 4. 빌드·시작 명령어 재확인
# package.json의 "build"와 "start" 스크립트가 있는지 확인
# 예: "build": "next build", "start": "node server.js"
 
# 5. DB 마이그레이션 준비
# Replit DB → PostgreSQL 스키마 및 데이터 이전 계획 수립
# 각 플랫폼별 DB 프로비저닝 방법은 아래 섹션에서 다룹니다

이 순서를 지키지 않으면 어느 플랫폼이든 배포 초반에 삽질을 하게 됩니다. 저도 처음엔 .replit 파일 그대로 올렸다가 Railway 빌드가 계속 실패해서 한참 헤맸어요. 에러 메시지도 딱히 친절하지 않아서 원인을 찾는 데 꽤 걸렸습니다.

실전 적용

예시 1: Railway로 이전하기 — 풀스택 앱의 정석 루트

Replit에서 Railway로 옮기는 건 세 플랫폼 중에 가장 쉽습니다. Railway가 공식 마이그레이션 가이드까지 따로 만들어둔 데는 이유가 있어요. 백엔드 + DB가 붙은 앱이라면 Railway가 현실적으로 가장 빠른 선택입니다.

# Railway CLI 설치
npm install -g @railway/cli
 
# 로그인 - 브라우저가 열리며 GitHub 계정으로 인증됩니다
railway login
 
# 현재 디렉토리를 Railway 프로젝트로 초기화
# 대화형으로 새 프로젝트 생성 또는 기존 프로젝트 연결을 선택합니다
railway init
 
# 현재 브랜치를 프로덕션에 배포
railway up

배포 후 Railway 대시보드 → Variables 탭에서 Replit Secrets에 있던 값들을 KEY=VALUE 형식으로 그대로 붙여넣으면 됩니다. PostgreSQL은 프로젝트 캔버스에서 우클릭 → Database → Add PostgreSQL로 1분 안에 프로비저닝됩니다. DATABASE_URL 환경 변수도 자동으로 주입되니까 별도 설정이 필요 없어요.

Railway의 Railpack이 Node.js, Python, Go 등 언어를 자동으로 감지해주기 때문에 Dockerfile 없이도 배포가 됩니다. 이게 Fly.io와 가장 큰 차이점이에요. 비유하자면 Railway는 "알아서 해줄게"이고, Fly.io는 "네가 직접 설정해"에 가깝습니다.

예시 2: Vercel로 이전하기 — Next.js라면 여기가 홈그라운드

Next.js 앱이라면 솔직히 Vercel 먼저 고려하는 게 맞습니다. Next.js를 만든 팀이 Vercel이니까, 최적화 수준이 다릅니다. App Router, Image Optimization, Edge Runtime — 전부 Vercel 위에서 제일 잘 돌아가요.

# Vercel CLI 설치
npm install -g vercel
 
# vercel.json 예시 (빌드 명령어가 기본값과 다를 때만 필요합니다)
# 예를 들어 pnpm을 쓰거나 output 경로가 커스텀인 경우에 추가합니다
# {
#   "buildCommand": "pnpm build",
#   "outputDirectory": ".next"
# }
 
# 프로덕션 배포 - 처음 실행 시 대화형으로 프로젝트 설정을 진행합니다
vercel --prod

주의할 점은, Vercel은 서버리스 함수 기반이라 실행 시간 제한이 있고 (최대 300초), 백엔드 서버나 DB를 직접 포함하지 않습니다. Replit Agent가 만든 Express 백엔드가 있다면 별도로 Railway나 Fly.io에 올려야 해요. 프론트엔드는 Vercel, 백엔드는 Railway로 분리하는 구성도 실무에서 꽤 흔합니다. 처음엔 두 플랫폼을 동시에 관리하는 게 번거롭게 느껴지지만, 각자 잘하는 걸 맡기니 결과적으로 훨씬 안정적이더라고요.

서버리스 함수: 서버를 직접 관리하지 않고 함수 단위로 실행되는 컴퓨팅 모델. Vercel의 기본 실행 단위로, 항상 켜진 서버와 달리 요청이 올 때만 실행됩니다. "항상 켜진 서버" 없이도 API를 운영할 수 있는 게 장점이지만, 실행 시간 제한이 있다는 점을 꼭 기억해두면 좋습니다.

예시 3: Fly.io로 이전하기 — 글로벌 배포나 AI 워크로드라면

Fly.io는 솔직히 처음 쓸 때 fly.toml 설정 파일에서 한 번쯤 막히게 됩니다. [[services]] 블록의 포트 설정이 앱 코드와 맞지 않으면 헬스체크가 계속 실패하거든요. 근데 이 진입 장벽만 넘으면, 글로벌 엣지 배포가 필요하거나 GPU 인스턴스(A100, L40S)를 써야 하는 AI/ML 워크로드라면 선택지가 많지 않습니다.

# flyctl 설치 (macOS)
brew install flyctl
 
# 앱 초기화 - Dockerfile을 자동 감지하고 fly.toml을 생성합니다
fly launch
 
# 환경 변수 설정 - Replit Secrets 값을 여기서 이전합니다
fly secrets set DATABASE_URL=postgres://...
fly secrets set API_KEY=your-secret-key
 
# 배포
fly deploy

Fly.io는 Dockerfile이 필수입니다. Replit Agent가 만든 앱에 Dockerfile이 없다면 먼저 추가해야 해요. fly launch 실행 시 언어를 감지해서 기본 Dockerfile을 제안해주긴 하는데, 이걸 그대로 쓰기 전에 한 가지 꼭 확인해야 할 사항이 있습니다.

# ⚠️ 이 단일 스테이지 예시는 빌드 도구가 필요 없는 순수 런타임 앱에만 적합합니다
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

위 Dockerfile의 npm ci --only=production은 devDependencies를 제외하는데, TypeScript나 Next.js처럼 빌드 도구가 devDependencies에 있는 앱이라면 빌드 단계에서 실패합니다. 이런 경우엔 아래처럼 멀티스테이지 빌드를 쓰는 것을 권장합니다.

# 멀티스테이지 빌드 - TypeScript/Next.js 등 빌드 과정이 있는 앱에 적합합니다
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci  # devDependencies 포함해서 설치 (빌드 도구 필요)
COPY . .
RUN npm run build
 
FROM node:20-alpine AS runner
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/server.js"]

Scale-to-Zero: 트래픽이 없을 때 인스턴스를 완전히 종료해 비용을 절감하는 방식. Fly.io가 지원하며, 첫 요청 시 콜드스타트가 발생할 수 있습니다. 사이드 프로젝트처럼 트래픽이 들쭉날쭉한 앱에 특히 유리합니다.

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

1. .replit, replit.nix 파일을 제거하지 않고 배포 — Railpack이나 Vercel 빌드가 이 파일을 보고 혼란을 일으킬 수 있습니다. 배포 전에 git rm .replit replit.nix로 반드시 제거하는 것을 권장합니다. rm으로 파일만 지우면 Git 스테이징이 별도로 필요하니, git rm으로 한 번에 처리하는 편이 깔끔합니다.

2. Replit 내장 Key-Value DB를 그대로 참조 — Replit DB는 Replit 환경 밖에서 접근이 불가능합니다. PostgreSQL이나 Redis로 교체하고 데이터 마이그레이션까지 완료한 뒤 배포하는 것을 권장합니다. 이 부분을 놓치면 앱은 뜨는데 데이터가 전혀 안 보이는 황당한 상황을 겪게 됩니다.

3. 환경 변수를 코드에 하드코딩 — AI 생성 코드에서 특히 자주 발견됩니다. 배포 전에 grep -r "sk-" . 같은 명령어로 API 키 패턴을 한 번 스캔해보시면 좋습니다. 각 플랫폼의 Secrets Manager(Railway Variables, Vercel Environment Variables, Fly Secrets)를 활용하는 것을 권장합니다.

마치며

Replit Agent는 아이디어를 빠르게 검증하는 데 탁월하지만, 프로덕션 이전은 플랫폼 선택부터 보안 검토까지 꼼꼼한 준비가 필요합니다.

앱 성격에 따라 한 줄로 정리하면 이렇습니다. Next.js 프론트엔드 중심이라면 Vercel, 백엔드·DB가 붙은 풀스택이라면 Railway(Hobby $5/월부터 시작 가능), 글로벌 배포나 AI 워크로드라면 Fly.io(소형 VM $3.15/월부터)로 시작해보시면 좋습니다. Vercel은 Hobby 플랜이 무료라 프론트엔드라면 부담 없이 시도해볼 수 있습니다.

지금 바로 시작해볼 수 있는 3단계:

1. Replit 프로젝트를 GitHub에 푸시하고 Replit 전용 파일을 제거합니다. git rm .replit replit.nix && git commit -m "remove Replit-specific files" 한 줄이면 됩니다.
2. 앱 성격에 맞는 플랫폼을 선택하고 CLI로 첫 배포를 시도해보시면 됩니다. Railway라면 railway init && railway up, Vercel이라면 vercel --prod, Fly.io라면 fly launch로 시작됩니다.
3. AI 생성 코드의 보안 취약점을 수동으로 점검하는 것을 권장합니다. 아래 체크리스트를 기준으로 훑어보시면 좋습니다:
   • API 키·비밀번호가 코드에 하드코딩되어 있지 않은가
   • SQL 쿼리가 파라미터 바인딩 없이 문자열 연결로 조합되지 않는가
   • 인증 미들웨어가 모든 보호 대상 라우트에 적용되어 있는가
   • 에러 메시지에 스택 트레이스나 내부 경로가 노출되지 않는가
   • 의존 패키지에 알려진 취약점이 없는가 (npm audit 또는 pnpm audit)

다음 글: Fly.io에서 Replit Agent 앱에 GPU 인스턴스를 붙여 AI 추론 서버로 전환하는 방법을 다뤄볼 예정입니다.

참고 자료

• Migrate from Replit to Railway | Railway 공식 문서
• Railway vs. Fly | Railway 공식 비교
• Replit Agent 공식 문서 | Replit
• Deploy an app | Fly.io 공식 문서
• Vercel vs Railway | Vercel Knowledge Base
• How to Host Your Replit AI Project on Vercel | Medium
• How to Secure Vibe Coded Applications in 2026 | DEV Community
• Replit 2025 연간 리뷰 | Replit Blog
• Deploy Replit Apps to Production | DeployHQ Guide