¶ 4권 — 무료 클라우드 서비스로 배포하기: Vercel·Render로 첫 서비스 올리기
막 시작한 스타트업이나 사이드 프로젝트가 "어디에 얼마를 내고 서버를 둘 것인가"보다 먼저 "지금 당장 돈을 내야 하는가"를 판단하는 단계를 다룬다.
무료 티어부터 시작할 것을 권하는 이유는 다음 세 가지다.
- 초기 단계에는 안정적으로 오래 버티는 서버보다 아이디어의 작동 여부를 가장 빨리 확인하는 것이 목표다.
- 요즘 무료 티어는 실제로 몇 달~몇 년을 무리 없이 운영할 수 있을 만큼 관대해졌다.
- 무료 티어의 제약(트래픽 상한, 슬립 정책, 데이터 보존 기간) 자체가 나중에 유료 인프라를 설계할 때 무엇을 우선할지 미리 알려주는 예행연습이 된다.
¶ 카테고리별로 나누어 생각하기
초기 스타트업이 흔히 저지르는 착각은 서버 하나에 프론트엔드·백엔드·DB를 전부 올리는 것이 간단하다는 생각이다.
무료 티어 생태계에서는 반대로 각 카테고리를 가장 잘하는 서비스에 나눠 맡기는 편이 더 단순하고, 각 서비스의 무료 한도를 최대한 활용할 수 있다.
프론트엔드(정적/SSR)
Vercel Hobby가 사실상 표준이다. GitHub 연결만으로 커밋마다 자동 빌드·배포와 HTTPS 인증서 발급이 이뤄지는 대신, "비상업적·개인 프로젝트 전용"이라는 약관 제약을 처음부터 인지해야 한다.
백엔드
| 서비스 | 특징 |
|---|---|
| Render | 상시 서버가 필요할 때 선택. 15분 무입력 시 스핀다운·재기동 약 1분, 무료 PostgreSQL은 30일 후 만료 |
| Fly.io | 컨테이너 기반 글로벌 배포에 적합. 다만 2024년 10월부로 상시 무료 티어가 폐지되어 사실상 짧은 체험판에 가까움 |
| Google Cloud Run | 트래픽 없을 때 완전히 0으로 스케일다운하는 서버리스 방식이 필요할 때 검토 |
DB
Render의 만료형 무료 PostgreSQL에 의존하기보다 수명이 긴 매니지드 DB를 별도로 붙이는 편이 안전하다.
| 서비스 | 용도 | 무료 한도 |
|---|---|---|
| MongoDB Atlas M0 | 문서형이 필요할 때 | 무기한 무료, 512MB |
| Neon | 관계형+브랜칭 기능이 필요할 때 | 0.5GB, 월 100 CU-시간, 5분 유휴 시 스케일다운 |
| Upstash Redis | 가벼운 키-값 저장이 필요할 때 | 월 50만 커맨드 |
¶ 실제 배포 흐름
전형적인 배포 흐름은 다음 순서로 진행된다.
- 저장소 준비(프론트/백엔드 분리)
- 프론트엔드 배포(Vercel, main 푸시는 프로덕션·그 외는 프리뷰 자동 생성)
- 백엔드 배포(Render, Git Push 자동 배포)
- DB 연결(연결 문자열을 코드에 하드코딩하지 않고 각 서비스의 환경 변수로 등록)
- CORS·환경 변수 정리
- 콜드스타트를 감안한 첫 요청 동작 확인
핵심 원칙은 "하나의 서버에 모든 것을 올리지 않는다"는 것이다. 각 서비스가 무료 한도 안에서 독립적으로 스케일·장애 격리되므로 이후 유료 전환도 카테고리별로 선택적으로 할 수 있다.
TodoBox는 이 원칙을 더 단순화해 별도 백엔드·DB 서버를 두지 않고, Next.js(프론트+API Route)는 Vercel에, 인증·DB·스토리지·서버리스 함수는 Supabase 하나에 맡기는 조합을 택한다.
¶ TodoBox를 Vercel에 배포하기
GitHub 저장소를 Vercel 프로젝트로 Import하면 Next.js를 자동 감지해 빌드 명령을 채워준다. 이어서 Supabase 연결 정보를 환경 변수로 등록한다.
NEXT_PUBLIC_SUPABASE_URL,NEXT_PUBLIC_SUPABASE_ANON_KEY: 클라이언트 노출용SUPABASE_SERVICE_ROLE_KEY: 서버 전용
Production/Preview/Development 환경별로 다른 값을 지정할 수 있다.
배포 이후에는 3권에서 세운 dev/main PR 흐름이 Vercel의 배포 방식과 그대로 맞물린다. main 머지는 프로덕션 배포로, dev→main PR이 열려 있는 동안은 PR 전용 프리뷰 배포 URL이 자동 생성되어, 리뷰어가 코드만 보지 않고 실제 동작 화면을 확인한 뒤 승인할 수 있다.
¶ TodoBox의 백엔드/DB: Supabase 활용
Supabase는 관리형 PostgreSQL 위에 인증·스토리지·서버리스 함수를 얹어 하나의 콘솔에서 다루게 해주는 플랫폼이다.
Auth
이메일 회원가입/로그인 기본 기능에 더해 구글·카카오 소셜 로그인을 연동한다. 소셜 로그인이든 이메일 가입이든 동일한 auth.users 테이블로 통합 관리된다.
Storage
목적에 따라 버킷을 분리하는 것이 원칙이다.
- 공개 버킷: URL만 알면 누구나 볼 수 있음
- 비공개 버킷: RLS(Row Level Security) 정책·서명된 URL로 통제
Edge Functions
Deno 런타임 기반 서버리스 함수다. TodoBox는 마감일 알림 이메일 발송 로직을 만들어 배포하고, pg_cron·pg_net을 조합해 정해진 시각마다 자동 실행되도록 스케줄링함으로써 별도의 배치 서버 없이 알림 기능을 완결시킨다.
¶ 그 외 선택지들
Vercel+Supabase 조합이 유일한 정답은 아니다.
| 서비스 | 특징 |
|---|---|
| Firebase | 구글의 BaaS. 모바일 연동·실시간 동기화에 강점이 있으나 DB가 NoSQL(Firestore) |
| PlanetScale | MySQL 호환에 브랜치 기반 무중단 마이그레이션이 강점이나 인증·스토리지는 제공하지 않음 |
| Neon | DB 자체에 집중 |
| Netlify | Vercel과 경쟁하는 프론트엔드 배포 플랫폼 |
¶ 무료 티어의 한계를 미리 인지해야 하는 이유
무료 티어는 "공짜"가 아니라 "조건부 자원"이며, 다음 세 축으로 한계를 미리 파악해야 한다.
- 트래픽·사용량 상한을 넘기면 즉시 과금되기보다 일시 정지되는 방식이 많다.
- 슬립·콜드스타트 정책은 사용자 체감 지연으로 직결된다.
- 데이터 보존 기간과 삭제 정책은 "지워지면 안 되는 데이터"를 처음부터 만료 없는 매니지드 DB에 둬야 하는 이유가 된다.
커스텀 도메인 연결 자체는 대부분 서비스에서 무료이며 실제 비용은 도메인 구매비뿐이다.
¶ 언제 유료 전환을 검토해야 하는가
다음 네 가지 신호 중 하나라도 해당하면 무료 티어를 넘어설 시점이 가까워진 것으로 판단한다.
- 매출이 발생하는 서비스가 되었을 때
- 사용량 상한의 70~80%에 지속적으로 도달할 때
- 콜드스타트가 실사용자 경험·이탈률에 영향을 줄 때
- 데이터 보존이 비즈니스에 필수적일 때
서비스마다 다른 성격의 제약을 갖는다.
| 서비스 | 제약 성격 |
|---|---|
| Vercel | 콜드스타트가 없는 대신 비상업적 이용 제약이 먼저 걸림 |
| Render | 상업적 제약은 없지만 슬립 정책이 체감에 직접 영향 |
| Supabase | 7일 무활동 시 프로젝트가 일시 정지(수동 재개 필요) |
¶ 핵심 포인트
이 장을 관통하는 결론은 무료 티어 자체보다 "언제 벗어나야 하는지 아는 능력"이 훨씬 중요하다는 것이다.
- 슬립 정책 방치는 서서히 매출 손실로 돌아온다.
- 약관 미인지는 계정 정지라는 급작스러운 리스크로 돌아온다.
- 데이터 보존 무시는 예정된 장애 시나리오로 돌아온다.
반대로 너무 이른 유료 전환·대형 인프라 투자도 검증되지 않은 가설에 고정비를 묶는 과잉투자이므로 똑같이 경계해야 한다.
¶ 참고할 만한 사례
- 국내 사례로 AI 할일관리 앱 "아이두(Aido)"는 별도 인프라 인력 없이 Vercel과 커스텀 도메인 연결만으로 정식 출시 서비스를 운영했다.
- 해외 사례로 Notion 사이트 빌더 "Potion.so"는 1인 창업자가 Vercel 위에서 시작해 2년 만에 도메인 4,000개·MRR $6,300 규모로 성장한 뒤 약 $300,000에 인수되었다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.