PaaS 비교 2026 — Vercel · Netlify · Render · Fly.io · Railway · Northflank · Heroku · Cloud Run · App Runner · Coolify 어디에 배포할 것인가 정면 비교

• 프롤로그 — Heroku 가 떠난 자리에 누가 들어왔는가
• 1장. PaaS 의 정의 — 무엇이 PaaS 이고 무엇이 아닌가
  • 1.1 PaaS 의 다섯 축
• 2장. Vercel — Next.js 의 본가, 그리고 v0 까지
  • 2.1 Vercel 에 Next.js + Postgres + Redis 배포
  • 2.2 Vercel 의 적합 영역
• 3장. Netlify — Vercel 의 형, 살아남은 형
• 4장. Render — "Heroku 가 그리워? 우리가 Heroku 다"
  • 4.1 Render 에 Next.js + Postgres + Redis + Worker 배포
• 5장. Fly.io — Docker 우선, 글로벌 우선
  • 5.1 Fly 의 진짜 강점 — 멀티 리전 사소함
• 6장. Railway — 분당 자원 단위, 우아한 UX
  • 6.1 Railway 의 매력 — Code-Free 인프라
• 7장. Northflank — 멀티 클라우드, 시리어스 팀의 PaaS
• 8장. Heroku — 죽었다는 소문은 과장이었다
• 9장. Cloud Run — GCP 의 숨겨진 챔피언
  • 9.1 Cloud Run 에 Next.js 배포
• 10장. AWS App Runner / ECS Fargate — AWS 출구
• 11장. Coolify · Dokku — "PaaS 비용이 미쳤다, 내가 호스팅한다"
• 12장. 비용 매트릭스 — $5k/월 SaaS 의 실제 청구서
• 13장. 콜드 스타트의 진실
• 14장. 영속 디스크의 황혼과 부활
• 15장. 백그라운드 워커의 현실
• 16장. 멀티 리전 — 글로벌 SaaS 의 현실
• 17장. 결정 프레임 — 어느 PaaS 를 골라야 하는가
• 18장. 안티 패턴 모음
• 에필로그 — 도구가 아니라 워크로드를 보라
  • PaaS 선택 체크리스트
  • 다음 글 예고
• 참고 / References

프롤로그 — Heroku 가 떠난 자리에 누가 들어왔는가

2022 년, Salesforce 가 Heroku 의 무료 티어를 죽였다. 그날 트위터에서 한 세대의 인디 해커가 동시에 비명을 질렀다. "Heroku 가 죽었다. 이제 우리는 어디에 배포해야 하는가." 그 비명에서 시작된 4 년의 PaaS 황금기가 2026 년 봄, 어느 정도 모양을 잡았다.

오해는 풀고 시작하자. Heroku 는 죽지 않았다. Salesforce 가 무료 티어를 죽이고 가격 정책을 한 번 정리했을 뿐, 2026 년 현재 Heroku 는 살아 있고 Heroku-24 스택과 Postgres 17 까지 지원한다. 다만 "기본값" 의 자리는 잃었다. 새 프로젝트의 기본값은 더 이상 Heroku 가 아니다.

그 빈 자리를 차지한 후보가 너무 많다. Vercel 은 Next.js 의 사실상 본가가 되어 v0 와 ai-sdk 까지 흡수하며 "프레임워크 우선 PaaS" 라는 카테고리를 만들었다. Render 는 "Heroku 가 그리워? 우리가 Heroku 다" 를 슬로건처럼 외치며 영속 디스크, 크론, 백그라운드 워커, Postgres 를 한 곳에 묶었다. Fly.io 는 Docker 우선 글로벌 PaaS 로 멀티 리전 배포를 사소한 일로 만들었다. Railway 는 분당 자원 단위 과금과 우아한 UX 로 새 세대를 데려갔다. Northflank 는 멀티 클라우드와 BYOC, 그리고 더 고급 프리미티브 — Job, Cron, Volume, Build Pipeline — 로 시리어스 팀의 눈을 끌었다. Netlify 는 Vercel 의 형이지만 동생에게 자리를 빼앗긴 후 JS 프레임워크 호스팅에 집중하며 살아남았다.

그리고 클라우드 사람들이 사랑하는 다크호스가 있다. Cloud Run — GCP 의 서버리스 컨테이너 — 은 100ms 단위 과금과 0 으로의 스케일 다운으로 일부 워크로드에서는 다른 모든 PaaS 를 가격으로 박살낸다. AWS App Runner 와 ECS Fargate 는 AWS 출구를 원하는 팀의 선택. Coolify 와 Dokku 는 "PaaS 비용이 미쳤다, 내가 직접 호스팅하겠다" 는 부류의 선택.

이 글은 이 PaaS 들을 같은 축으로 정면 비교한다. 비교 후, 네 시나리오 — Next.js 앱 배포, API + Postgres + Redis + 워커 스택, 글로벌 멀티 리전 SaaS, $5k/월 트래픽 풀스택 앱 — 에서 어느 도구를 골라야 하는지 묻는다. 가격은 빠르게 움직인다. 모든 숫자는 2026 년 5 월 기준 이고, 구조의 차이에 초점을 둔다. 6 개월 뒤 숫자가 바뀌어도 의사 결정 프레임은 유효해야 한다.

같은 카테고리의 PaaS 라도 과금 모델 과 런타임 모델 이 다르면 한 달 청구서는 10 배까지 벌어진다. 그리고 떠나는 비용은 들어오는 비용의 10 배다.

1장. PaaS 의 정의 — 무엇이 PaaS 이고 무엇이 아닌가

2026 년에 "PaaS" 라는 단어를 쓰려면 먼저 경계선을 그어야 한다. 좁은 의미의 PaaS — Platform as a Service — 는 Heroku 가 정의한 것이다. git push heroku main 한 줄로 코드가 빌드되고 배포되고 도메인이 붙는다. 인프라는 보이지 않는다. 데이터베이스, 캐시, 큐는 애드온으로 한 줄 추가된다.

이 정의에서 Vercel · Netlify · Render · Fly.io · Railway · Northflank · Heroku · Coolify · Dokku 는 모두 PaaS 다. 코드를 푸시하면 배포된다.

경계선에 있는 도구도 있다. Cloud Run 은 컨테이너를 푸시하면 자동으로 스케일링되는 서버리스 컨테이너 플랫폼이다. 좁은 의미의 PaaS 보다는 한 단계 낮은 추상화 — Postgres 도, 빌드 파이프라인도 별도로 붙여야 한다 — 지만, 사실상 PaaS 처럼 쓰인다. AWS App Runner 도 같은 카테고리다. ECS Fargate 와 Kubernetes 는 PaaS 보다 한 단계 낮은 CaaS — Container as a Service — 또는 IaaS 에 가깝다.

이 글은 좁은 PaaS 와 Cloud Run / App Runner 까지를 다룬다. ECS Fargate 와 EKS 는 비교 표에서 잠깐 등장하지만 본격적인 비교 대상은 아니다.

1.1 PaaS 의 다섯 축

같은 축에서 비교하지 않으면 비교가 아니다. 다섯 축을 먼저 정의한다.

• 빌드 모델 — Buildpack? Dockerfile? 프레임워크 자동 감지? Nixpacks?
• 런타임 모델 — 항상 켜져 있는 서버? 0 으로 스케일 다운? 요청당 인스턴스?
• 영속성 — 영속 디스크? Postgres? Redis? Object Storage?
• 과금 — 인스턴스 시간? CPU 초? 요청 수? 대역폭? 무료 티어?
• 운영 — 로그? 메트릭? 시크릿? 미리보기 환경? 롤백? 멀티 리전?

이 다섯 축으로 각 PaaS 를 한 줄로 요약하면 다음과 같다.

표만 봐도 패턴이 보인다. Vercel · Netlify · Cloud Run 은 "0 으로 스케일 다운, 영속 디스크 없음" 진영, Render · Fly.io · Railway · Northflank · Heroku 는 "항상 켜짐, 영속 디스크 있음" 진영. 이 한 줄의 차이가 모든 가격 계산과 워크로드 적합도를 결정한다.

2장. Vercel — Next.js 의 본가, 그리고 v0 까지

Vercel 은 2026 년 현재 가장 시끄러운 PaaS 다. Next.js 의 사실상 본가이고, ai-sdk 의 본가이고, v0 — UI 를 만들어 주는 AI — 의 본가이고, AI Gateway 라는 새 카테고리까지 만들었다.

좋은 점. Next.js 를 쓰면 다른 옵션을 고민할 필요가 거의 없다. git push 한 번으로 빌드되고, 미리보기 환경이 PR 마다 자동으로 생기고, 엣지에 자동 배포되고, 이미지 최적화와 분석이 기본으로 붙는다. 솔로 개발자 입장에서 "그냥 배포" 의 정의가 Vercel 이다.

문제. 가격이다. 2024 년 말 Vercel 은 과금 모델을 한 번 갈아엎었다. 기존의 "함수 호출 수 · GB-Hr · 대역폭" 모델에서 Active CPU 모델로 바꿨다. Active CPU 는 CPU 가 실제로 일을 한 시간만 과금하는 것이다 — 외부 API 응답을 기다리는 시간이나 DB I/O 대기 시간은 빠진다. 이론적으로는 더 싸다.

실제로는 어떤가. 가격 페이지의 숫자 — Active CPU 시간 $0.128, Provisioned Memory $0.0106 per GB-Hr, Edge Requests 100만 건당 $2 — 만 보면 합리적이다. 그러나 트래픽이 늘면 청구서가 빠르게 부푼다. 특히 큰 페이지를 Server Components 로 그리는 Next.js 앱은 페이지당 Active CPU 시간이 길어진다.

$5k/월 매출의 SaaS 가 Vercel 에서 얼마를 쓰는가. 커뮤니티 보고 — Reddit r/nextjs, Twitter 의 SaaS 빌더들 — 를 평균하면 트래픽 1–5 만 MAU 대에서 월 $150–$600 사이가 나온다. 그 위로는 Pro 의 $20/석 베이스와 사용량 초과분이 누적되어 빠르게 커진다.

Vercel 의 진짜 함정은 영속성이 없다 는 점이다. Postgres 는 Vercel Postgres — 사실은 Neon 의 OEM — 이고, Redis 는 Vercel KV — 사실은 Upstash 의 OEM — 다. 이들은 추가 비용이고, 트래픽에 따라 청구서가 따로 또 부푼다. Vercel 안에서 모든 것을 닫고 운영하면 결국 Neon 과 Upstash 의 직접 가격보다 비싸진다.

2.1 Vercel 에 Next.js + Postgres + Redis 배포

가장 간단한 워크플로우는 이렇다.

# 1. 로컬에서 Next.js 앱 만들기
npx create-next-app@latest my-saas

# 2. Vercel 에 연결
cd my-saas
vercel link

# 3. Vercel Postgres (= Neon) 와 Vercel KV (= Upstash) 추가
vercel storage create postgres
vercel storage create kv

# 4. 환경 변수 자동 주입 확인
vercel env pull .env.local

# 5. 푸시하면 끝
git push

vercel.json 도 거의 필요 없다. 미리보기 환경, 도메인, HTTPS, 이미지 최적화는 자동이다. 백그라운드 워커가 필요하면? Vercel Cron 또는 Vercel Queues — 베타 — 를 쓰거나, 외부 큐 — Inngest, Trigger.dev — 를 붙여야 한다. Vercel 안에서 "항상 켜진 워커" 를 돌릴 방법은 없다.

2.2 Vercel 의 적합 영역

Vercel 은 Next.js · React Router · SvelteKit · Astro 처럼 프레임워크 빌드가 정형화된 앱에 최적이다. SSG 중심 사이트 — 회사 블로그, 마케팅, 문서 — 도 무료 티어로 충분하다. AI 인터페이스 — 채팅, 코드 보조, 콘텐츠 생성 — 은 ai-sdk 와 AI Gateway 가 워크플로우를 짧게 만든다.

반면 항상 켜진 Express/Fastify 서버, Postgres + Redis + 워커가 같은 박스에서 도는 모놀리스, WebSocket 이 중심인 실시간 앱, gRPC 같은 워크로드는 Vercel 에 맞지 않는다. 굳이 우겨 넣을 수는 있지만 가격과 운영이 다 별로다.

3장. Netlify — Vercel 의 형, 살아남은 형

Netlify 는 Vercel 보다 먼저 시작했다. 2014 년 창업, "JAMstack" 이라는 단어를 만든 회사다. Vercel 이 2017 년에 시작해 Next.js 를 등에 업고 추월하기 전까지 Netlify 가 그 자리에 있었다.

2026 년 Netlify 는 작은 형의 자리다. Next.js 의 본가는 Vercel 에 빼앗겼고, 가격 모델도 비슷한 방향으로 따라갔다. 그래도 Netlify 가 살아남은 이유는 두 가지다.

첫째, Next.js 외 프레임워크에 더 친화적이다. Astro, Remix, SvelteKit, Hugo, Eleventy, Gatsby — 모두 Netlify 에서 잘 돌아간다. Vercel 도 다른 프레임워크를 지원하지만 "Next.js 가 1 등 시민, 그 외는 2 등" 의 분위기가 있다. Netlify 는 그 분위기가 덜하다.

둘째, 빌드 환경의 안정성이다. Netlify 의 빌드 시스템은 오래되었고 그만큼 깊이가 있다. 큰 모노레포의 SSG 빌드를 안정적으로 굴리는 데는 Netlify 가 여전히 우세하다는 보고가 많다.

가격은 Vercel 과 거의 평행하다. Free 티어 — 100GB 대역폭, 빌드 분 300 — , Pro $19/월/석. 함수 호출과 Edge Functions 도 비슷한 단위로 과금한다. Netlify Blobs — Object Storage — 와 Netlify Forms — 폼 제출 처리 — 는 Vercel 에 없는 작은 차별점이다.

문제는 같다. 영속 디스크가 없고, 워커가 약하고, Postgres 와 Redis 는 별도다. Netlify Postgres 는 2026 년 베타에 있지만 Neon 의 OEM 이라는 점에서 Vercel Postgres 와 같은 위치다.

언제 Netlify 를 고르는가. Next.js 가 아닌 프레임워크의 SSG/SSR 사이트, 모노레포 SSG, 이미 Netlify 에서 잘 돌고 있는 사이트의 마이그레이션 비용이 부담되는 경우. 새 Next.js 프로젝트라면 굳이 Netlify 를 고를 이유는 없다.

4장. Render — "Heroku 가 그리워? 우리가 Heroku 다"

Render 는 2019 년에 등장한 PaaS 다. 처음부터 "Heroku 의 후계자" 를 명시적으로 표방했다. 2022 년 Heroku 무료 티어 사망 이후 가장 큰 수혜자가 Render 였다.

Render 의 슬로건이 통하는 이유. Heroku 가 잘 했던 것 — Postgres, Redis, 백그라운드 워커, 크론, 영속 디스크, 단순한 가격 — 을 Render 가 모두 한 곳에서 제공한다. render.yaml 한 파일에 웹 서비스 + 워커 + 크론 + Postgres + Redis 를 선언하면 그대로 굴러간다.

2026 년 가격 모델은 단순하다. Web Service · Background Worker · Private Service 는 인스턴스 시간 과금이다. Starter $7/월, Standard $25/월, Pro $85/월 정도가 기본 라인이다. Postgres 는 Starter $7/월 (256MB RAM, 1GB storage), Standard $20/월 부터 시작한다. Redis 도 비슷한 라인. Persistent Disk 는 GB 당 월 $0.25. Cron Job 은 무료 — 실행 시간만 과금.

$5k/월 SaaS 의 Render 청구서를 추정하면, Web Service 한 대 ($25) + Worker 한 대 ($25) + Postgres Standard ($20) + Redis Starter ($10) + 디스크 10GB ($2.5) = 월 $82.5. 같은 워크로드를 Vercel + Neon + Upstash 로 짜면 $150–$300 사이가 일반적이다. Render 가 단순히 더 싸다.

Render 의 함정. 첫째, 콜드 스타트가 아니라 "슬립" 이 있다 — Free 티어에 한해. 무료 인스턴스는 15 분 비활성이면 잠들고, 다음 요청에서 20–30 초 정도 깨어나는 시간이 든다. 유료 티어는 항상 켜져 있다. 둘째, 글로벌 멀티 리전 배포는 약하다. Render 는 리전 — Oregon, Ohio, Virginia, Frankfurt, Singapore — 을 선택하지만 한 서비스를 여러 리전에 동시에 띄우는 것은 비교적 최근 기능이고 Fly.io 만큼 매끄럽지 않다.

4.1 Render 에 Next.js + Postgres + Redis + Worker 배포

# render.yaml
services:
  - type: web
    name: app
    runtime: node
    buildCommand: pnpm install && pnpm build
    startCommand: pnpm start
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: app-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          type: redis
          name: app-redis
          property: connectionString
  - type: worker
    name: worker
    runtime: node
    buildCommand: pnpm install && pnpm build:worker
    startCommand: pnpm start:worker
  - type: redis
    name: app-redis
    ipAllowList: []
    plan: starter

databases:
  - name: app-db
    plan: starter
    region: oregon

이 파일을 푸시하면 끝이다. Vercel 의 미니멀리즘과 Heroku 의 풀스택을 합친 느낌이다.

5장. Fly.io — Docker 우선, 글로벌 우선

Fly.io 는 다른 PaaS 와 출발이 다르다. 처음부터 Docker 와 멀티 리전 이 일급 시민이었다. 2026 년 현재 Fly.io 의 사용자 경험은 크게 두 번 갈아엎혔다 — 첫 번째는 Nomad 기반 Apps v1, 두 번째는 Firecracker MicroVM 기반 Machines / Apps v2.

Fly Machines 의 본질. Fly Machine 은 Firecracker MicroVM 하나다 — KVM 의 가벼운 가상 머신, AWS Lambda 가 쓰는 것과 같은 기술. 시작 시간은 250ms 수준, 정지·재개 — fly machine stop / start — 가 가능하고, 한 앱이 여러 리전에 여러 Machine 을 가질 수 있다. 가격은 Machine 의 CPU/메모리 시간으로 과금하되, 정지 상태에서는 거의 무료에 가깝다 (스토리지 비용만).

Fly Postgres 와 Volumes. Postgres 는 Fly 가 직접 운영하는 것이 아니라 — 정확히는 2024 년에 매니지드 운영을 종료하고 — Supabase Postgres on Fly 또는 직접 Postgres MicroVM 을 띄우는 모델로 갔다. Volume — 영속 디스크 — 은 살아 있고, Machine 에 직접 마운트한다.

fly.toml 한 파일이면 충분하다.

# fly.toml
app = "my-saas"
primary_region = "nrt"

[build]
  dockerfile = "Dockerfile"

[env]
  PORT = "8080"

[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

  [[services.ports]]
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

[mounts]
  source = "data"
  destination = "/app/data"

fly deploy 한 번이면 끝이다. 멀티 리전을 원하면 fly scale count 1 --region nrt,sin,fra 같은 명령어 한 줄.

Fly 의 가격. 가장 작은 Machine — shared-cpu-1x · 256MB — 은 월 $2 안쪽. 일반 워크로드 — shared-cpu-2x · 1GB — 는 월 $5–$10 정도. 대역폭은 북미 · 유럽에서 GB 당 $0.02. $5k/월 SaaS 의 Fly 청구서는 Render 와 비슷하거나 약간 싸게 나오는 경우가 많다 — 다만 운영 자동화 — Postgres 백업, Redis HA — 를 본인이 더 많이 해야 한다.

Fly 의 함정. 첫째, 운영 부담이 크다. Render 가 자동으로 해 주는 것 — Postgres 백업, 모니터링, 알람 — 을 Fly 에서는 본인이 짜야 한다. 둘째, 로컬 디버깅이 어렵다. Firecracker MicroVM 의 특성상 SSH 가 아니라 fly ssh console 로 들어가고, 실수로 영속 디스크를 날리면 복구가 어렵다.

5.1 Fly 의 진짜 강점 — 멀티 리전 사소함

다른 PaaS 에서 한 앱을 도쿄, 싱가포르, 프랑크푸르트 세 리전에 동시에 띄우는 것은 일 — Render 는 최근에야, Vercel 은 엣지로만, Cloud Run 은 리전마다 별도 배포. Fly 에서는 한 줄. 글로벌 SaaS 의 지연 시간을 50ms 이하로 잡고 싶다면 Fly 가 가장 적은 마찰로 그것을 한다.

6장. Railway — 분당 자원 단위, 우아한 UX

Railway 는 2020 년에 시작했다. 처음부터 "Heroku 가 그리워? 우리도 그렇다" 진영이었고, 2026 년 현재 가장 우아한 UX 를 가진 PaaS 다. 대시보드를 보는 것만으로도 다른 PaaS 와 차이가 느껴진다.

Railway 의 차별점. 첫째, 자원 단위 분당 과금. Vercel 의 Active CPU 와 유사하지만, Railway 는 Web 서비스에도 동일하게 적용된다. CPU 분당 $0.000463, 메모리 GB 분당 $0.000231 정도. 한 서비스가 유휴 상태일 때 — 트래픽이 없을 때 — 청구가 거의 0 으로 떨어진다. 단, Railway 는 0 으로 완전히 스케일 다운하지는 않는다 — 인스턴스가 살아 있다.

둘째, Hobby Plan vs Pro Plan. Hobby 는 $5/월 베이스 — $5 만큼의 자원 크레딧이 포함되어 있다. Pro 는 $20/월 베이스 + 팀 협업 + 더 큰 인스턴스. 솔로 개발자는 Hobby 로 시작해 충분한 경우가 많다.

셋째, Postgres, Redis, MySQL, MongoDB 가 한 번의 클릭. 데이터베이스 인스턴스도 자원 단위 과금이라 작은 DB 는 월 $3–$5 수준.

$5k/월 SaaS 의 Railway 청구서. 트래픽 패턴에 따라 다르지만, 가벼운 SaaS — Web + Worker + Postgres + Redis — 는 월 $30–$80 사이가 흔하다. 무거운 SaaS — 큰 Postgres, 항상 켜진 워커 — 는 $150–$300. Render 와 비슷하거나 약간 싸다.

Railway 의 함정. 첫째, 분당 과금이 무거운 워크로드에서 비싸진다. 항상 켜진 큰 인스턴스를 굴리면 Render 의 평탄한 인스턴스 시간 과금이 더 예측 가능하다. 둘째, 백업과 멀티 리전이 약하다 — Render 보다도. 셋째, Free 티어가 사실상 없다 — $5 베이스가 진입 장벽이다.

6.1 Railway 의 매력 — Code-Free 인프라

Railway 의 진짜 매력은 대시보드다. Postgres 추가, Redis 추가, 환경 변수 공유, 사설 네트워크, 도메인 — 모두 클릭 몇 번. render.yaml 이나 fly.toml 같은 설정 파일을 쓰지 않아도 된다. 이것이 솔로 개발자에게 큰 차이다.

# Railway CLI 만으로도 가능
npm i -g @railway/cli
railway login
railway init my-saas
railway add postgresql
railway add redis
railway up

7장. Northflank — 멀티 클라우드, 시리어스 팀의 PaaS

Northflank 는 2020 년 런던에서 시작했다. 다른 PaaS 보다 한 단계 위의 추상화를 노렸다. 한 마디로 "PaaS 인데 Kubernetes 처럼 강력한".

Northflank 의 차별점. 첫째, 멀티 클라우드 / BYOC. 본인의 AWS · GCP · Azure 계정에 Northflank 를 띄울 수 있다. 데이터 주권이 중요하거나 기존 클라우드 크레딧을 쓰고 싶은 팀의 선택. 둘째, Job 과 Cron 의 일급 지원. Render 의 Cron 보다 더 풍부한 스케줄러. 셋째, Build Pipeline. Docker 빌드를 Northflank 안에서 실행하고 결과물을 다른 Northflank 서비스에 자동 배포.

가격은 Render 와 비슷한 라인이다. 작은 인스턴스 $5–$10/월, 표준 $25–$50/월. Postgres · Redis · MySQL · MongoDB 도 매니지드로 제공된다.

Northflank 의 함정. 첫째, 러닝 커브가 PaaS 중 가장 높다. UI 가 강력한 만큼 복잡하다. 둘째, 커뮤니티가 작다 — Render, Fly, Railway 보다 사용자가 적어서 검색해 나오는 답이 적다. 셋째, 솔로 개발자의 첫 선택으로는 과하다 — 보통은 시리어스 팀의 두 번째 PaaS.

언제 Northflank 를 고르는가. 본인 클라우드 계정에 배포하고 싶을 때, 데이터 주권 — GDPR, 한국 개인정보보호법, 의료/금융 규제 — 때문에 위치를 통제하고 싶을 때, Kubernetes 까지는 가지 않으면서도 PaaS 보다 더 많은 통제권이 필요할 때.

8장. Heroku — 죽었다는 소문은 과장이었다

Heroku 는 2007 년에 시작해, 2010 년 Salesforce 에 인수되어, 2022 년 무료 티어를 죽이며 많은 적을 만들었다. 그러나 죽지는 않았다. 2026 년 현재 Heroku 는 살아 있고, Heroku-24 스택 (Ubuntu 24.04 LTS 기반), Postgres 17, PCI · HIPAA 컴플라이언스, Salesforce 통합 까지 갖춘 엔터프라이즈 PaaS 다.

Heroku 가 살아 있는 이유. 첫째, 이미 Heroku 에서 잘 굴러가는 앱이 너무 많다. 큰 회사가 Heroku 에 5–10 년 운영한 모놀리스를 떠나는 비용이 들어오는 비용의 10 배다. 둘째, Salesforce 생태계와의 통합. SFDC 와 Heroku Connect 로 양방향 동기화하는 워크플로우는 Heroku 만 가능. 셋째, Eco · Basic Dyno 가 무료 티어 자리를 일부 복원했다 — Eco Dyno $5/월 에 1,000 시간, 슬립 가능. Basic Dyno $7/월 항상 켜짐.

가격. Eco $5, Basic $7, Standard-1X $25, Standard-2X $50, Performance-M $250. Postgres 는 Mini $5, Basic $9, Standard-0 $50, Standard-2 $200 ... . Redis 는 Mini $3, Premium $15 부터. 같은 워크로드를 Render · Railway · Fly 에서 짜면 보통 20–40% 싸다.

Heroku 를 새로 고를 이유. 한 가지뿐이다 — Salesforce 와의 통합. 그 외 새 프로젝트가 굳이 Heroku 를 고를 이유는 약하다.

9장. Cloud Run — GCP 의 숨겨진 챔피언

Cloud Run 은 PaaS 비교 글에서 자주 빠진다. 이유는 단순하다 — GCP 콘솔의 UX 가 다른 PaaS 보다 복잡하고, GCP 의 무료 크레딧을 다 쓴 사람만 진심으로 청구서를 본다. 그러나 청구서를 본 사람 중 다수가 Cloud Run 의 팬이 된다.

Cloud Run 의 본질. 컨테이너를 푸시하면 요청당 인스턴스 로 자동 스케일링된다. 요청이 없으면 0 으로 떨어진다. 요청이 들어오면 100ms 안에 깨어난다. 인스턴스가 한 번에 동시 처리할 수 있는 요청 수 — concurrency — 를 본인이 정할 수 있고, 기본값은 80 이다.

가격이 미친 이유. 100ms 단위 과금 + 0 으로 스케일 다운 + 매달 첫 240,000 vCPU-초 와 450,000 GiB-초 무료. 작은 SaaS — $5k/월 매출, 트래픽 일 1–5 만 — 의 Cloud Run 청구서는 종종 월 $5–$50 수준이다. 같은 워크로드의 Vercel 청구서는 $150–$600, Render 는 $80–$150.

Cloud Run 의 함정. 첫째, GCP 의 다른 서비스를 같이 써야 한다. Cloud SQL — Postgres — 은 별도 청구, Cloud Memorystore — Redis — 은 비싸다, Cloud Storage — Object — 은 별도. GCP 안에서 전부 닫으면 결국 다른 PaaS 와 비슷한 가격이 될 수 있다. 둘째, 요청당 인스턴스 모델은 WebSocket · gRPC streaming 에 부적합 — Cloud Run 2 세대가 일부 지원하지만 제약이 있다. 셋째, 콜드 스타트가 0 은 아니다 — 첫 요청은 100ms–수 초 사이 (이미지 크기와 의존성에 따라).

9.1 Cloud Run 에 Next.js 배포

# 1. Dockerfile 작성
# (Next.js 공식 Dockerfile 예시 사용)

# 2. Cloud Build + Cloud Run 동시 배포
gcloud run deploy my-saas \
  --source . \
  --region asia-northeast1 \
  --allow-unauthenticated \
  --memory 512Mi \
  --cpu 1 \
  --concurrency 80 \
  --min-instances 0 \
  --max-instances 100

# 3. Cloud SQL Postgres 연결
gcloud run services update my-saas \
  --add-cloudsql-instances PROJECT:REGION:INSTANCE \
  --set-env-vars DATABASE_URL=postgres://...

--min-instances 1 로 두면 콜드 스타트가 사라지지만, 항상 켜진 인스턴스 한 대의 시간 과금이 들어간다. 그래도 다른 PaaS 의 항상 켜진 인스턴스보다는 보통 싸다.

10장. AWS App Runner / ECS Fargate — AWS 출구

이미 AWS 안에 모든 것이 있는 팀이라면 다른 PaaS 를 추가로 도입하는 비용이 부담스러울 수 있다. 그 팀의 PaaS 출구가 App Runner 와 ECS Fargate 다.

App Runner. 컨테이너 또는 GitHub 저장소를 푸시하면 자동 빌드 · 배포. Cloud Run 과 비슷하지만 항상 켜진 모델이다 — 0 으로 스케일 다운하지 않는다. 가격은 vCPU 분당 $0.064, 메모리 GB 분당 $0.007 정도. $5k/월 SaaS 의 App Runner 청구서는 보통 $80–$200.

App Runner 의 위치. AWS 콘솔 안에서 다른 AWS 서비스 — RDS, ElastiCache, S3, SQS — 와 매끄럽게 통합된다. AWS 가 1 등 시민인 팀에서는 가치가 있다. 그러나 AWS 밖의 PaaS — Render, Railway, Fly — 가 같은 워크로드를 더 싸고 더 쉽게 한다.

ECS Fargate. Container as a Service. ECS 의 Task Definition 을 정의하고 Fargate 로 띄운다. PaaS 보다 한 단계 낮은 추상화 — VPC, ALB, IAM, Task Role 을 본인이 짜야 한다. 그러나 통제권은 그만큼 크다. 큰 팀의 메인 워크로드는 ECS Fargate 또는 EKS 에 있는 경우가 많고, App Runner 와 PaaS 는 보조 워크로드용이다.

가격 비교. 같은 1 vCPU + 2GB 메모리를 한 달 항상 켜진 상태로 굴리면, ECS Fargate 는 약 $36/월, App Runner 는 약 $40–$50/월. Render 의 Standard 가 $25/월, Fly 의 dedicated-cpu-1x 가 $30/월. AWS 가 약간 더 비싸지만 다른 AWS 서비스와의 통합 가치가 그 차이를 채울 수 있다.

11장. Coolify · Dokku — "PaaS 비용이 미쳤다, 내가 호스팅한다"

PaaS 비용이 거슬리는 부류는 항상 있다. "Hetzner VPS 가 월 $5 에 4 vCPU + 8GB 메모리를 주는데, Render 에서 같은 사양이 $85 인 것이 말이 되는가?" 그 부류의 도구가 Coolify 와 Dokku 다.

Coolify. 2022 년에 등장해 2025 년경 폭발적으로 성장한 오픈소스 셀프 호스팅 PaaS. 본인의 VPS — Hetzner, DigitalOcean, OVH — 에 Coolify 를 설치하면 그 위에서 Heroku 같은 경험이 가능하다. GitHub 연동, 자동 배포, 도메인, HTTPS — Let's Encrypt 자동 — , Postgres · Redis · MySQL · MongoDB 매니지드, 모니터링까지.

Coolify 의 진짜 가격. Coolify 자체는 무료다 (Pro $5/월 은 클라우드 호스팅된 Coolify 인스턴스의 가격). VPS 비용 — Hetzner CX31 (2 vCPU, 8GB) 가 월 $13 — 만 든다. 한 VPS 에 10 개 앱을 굴리면 앱당 월 $1.3 이다. Render 의 1/20 가격이다.

Coolify 의 함정. 첫째, 본인이 운영해야 한다. OS 업데이트, 보안 패치, 백업, 모니터링 — 모두 본인 일이다. 둘째, HA 가 약하다. 단일 VPS 에 모든 것이 있으면 그 VPS 가 죽을 때 모든 앱이 죽는다. Coolify 의 클러스터 기능 — 멀티 노드 — 은 베타. 셋째, 러닝 커브가 의외로 있다. PaaS 의 단순함을 기대하면 처음 두 주가 힘들다.

Dokku. 2013 년부터 살아 있는 오픈소스 미니 Heroku. Coolify 보다 더 단순하고, GUI 가 없고 (커뮤니티 GUI 는 있다), CLI 로만 동작한다. dokku apps:create my-app, git push dokku main — Heroku 의 CLI 와 거의 같다. 솔로 개발자가 자기 VPS 에 Dokku 를 깔고 5 개의 작은 앱을 굴리는 것은 2026 년에도 합리적인 선택이다.

언제 Coolify / Dokku 를 고르는가. 돈을 아끼고 싶고, 운영을 배우고 싶고, HA 가 절대적이지 않은 사이드 프로젝트. 본 업무 SaaS 에는 보통 부적합 — 한 번 다운되면 비즈니스 임팩트가 VPS 비용 절약을 압도한다.

12장. 비용 매트릭스 — $5k/월 SaaS 의 실제 청구서

다음은 같은 워크로드 — Next.js 14 앱 + Postgres (10GB, 약간의 워크로드) + Redis (256MB) + 백그라운드 워커 1 대 — 를 각 PaaS 에 배포했을 때의 추정 월 청구서다. 트래픽은 월 100만 페이지뷰, 일 평균 3 만 요청을 가정한다.

해석. 가격만 보면 Coolify · Dokku 가 압도적으로 싸다. 그러나 그것은 본인이 운영하는 비용 — 시간 + 위험 — 을 빼고 본 수치다. 매니지드 PaaS 중에서는 Railway 와 Fly.io 가 가장 싸고, Render 가 그 다음, Vercel · Heroku · App Runner 가 가장 비싸다.

가격은 한 축일 뿐이다. 다른 축 — 운영의 단순함, 워크로드 적합도, 마이그레이션 비용, 팀 합의 — 을 함께 보지 않으면 결정이 틀린다.

13장. 콜드 스타트의 진실

"콜드 스타트" 라는 단어가 2026 년에도 PaaS 논쟁의 중심에 있다. 진실은 이렇다.

0 으로 스케일 다운하는 플랫폼만 콜드 스타트가 있다. 항상 켜진 PaaS — Render, Railway, Heroku, Northflank — 에는 콜드 스타트가 없다. 다만 인스턴스가 죽고 재시작될 때의 시간이 있는데, 이것은 콜드 스타트보다는 짧다.

Vercel · Netlify · Cloud Run · Fly Machines (auto_stop) 는 콜드 스타트가 있다. 일반적인 콜드 스타트 시간:

• Vercel Functions — Node.js 작은 함수 100–500ms, 큰 SSR 1–3 초
• Netlify Functions — 비슷한 라인
• Cloud Run — 100ms–2 초, 이미지 크기에 큰 영향
• Fly Machines (auto_stop) — 250–500ms, Firecracker 의 강점
• AWS Lambda — Node 100–500ms, Java/Python 더 길다

콜드 스타트가 문제가 되는 워크로드. 실시간 채팅, 게임, 트레이딩, 결제 처리. 사용자가 첫 요청에서 2 초를 기다리는 것이 사업적으로 손해인 경우.

해법 세 가지. (1) Min instances ≥ 1 — Cloud Run 과 Fly Machines 모두 지원. 항상 켜진 인스턴스 한 대를 두어 첫 요청을 받게 한다. (2) Provisioned Concurrency — AWS Lambda 의 기능. (3) 항상 켜진 PaaS 로 옮긴다.

14장. 영속 디스크의 황혼과 부활

2018–2022 년 사이 PaaS 의 큰 추세는 "영속 디스크는 안티 패턴" 이었다. 모든 상태는 외부 — Postgres, Redis, S3 — 로 보내고 컴퓨트는 stateless 로 두는 것이 모범이었다. Vercel · Netlify 가 그 방향을 극단으로 밀었다.

2023–2026 년 추세는 일부 되돌아왔다. 영속 디스크가 필요한 워크로드가 다시 보였다.

• SQLite + Litestream — SaaS 의 가장 단순한 데이터 계층. 한 VM 안에 SQLite 와 앱이 같이 살고, Litestream 이 S3 로 비동기 백업. Fly.io 와 Render 는 이 패턴을 잘 지원한다.
• 벡터 DB self-hosted — pgvector, Qdrant, Weaviate 를 본인 인스턴스에 띄울 때 영속 디스크가 필요하다.
• 파일 처리 워크플로우 — 이미지 변환, 비디오 트랜스코드, 큰 파일 임시 저장.
• 로컬 캐시 — Redis 를 안 쓰는 경우의 디스크 캐시.

영속 디스크가 필요한가? Render, Fly.io, Railway, Northflank, Coolify · Dokku 를 본다. Vercel, Netlify, Cloud Run, App Runner 는 후보에서 빠진다.

15장. 백그라운드 워커의 현실

"백그라운드 워커" 는 SaaS 의 숨은 절반이다. 이메일 발송, 결제 웹훅 처리, 비디오 변환, 리포트 생성, 정기 데이터 동기화 — 모두 워커가 한다. PaaS 의 워커 지원 수준은 크게 갈린다.

일급 지원 — Render, Railway, Fly.io, Northflank, Heroku, Coolify. 워커 = 항상 켜진 프로세스. worker.js 를 시작하고 큐를 폴링하거나 메시지를 받으면 된다.

부분 지원 — Cloud Run Jobs, App Runner. Cloud Run Jobs 는 실행 가능한 워커지만 항상 켜진 워커는 아니다 — 호출되면 실행되고 끝난다. 큐 폴링 워커는 Cloud Run 에서는 어색하다.

약함 — Vercel, Netlify. Vercel Queues 가 베타에 있지만, 항상 켜진 워커 모델은 없다. 외부 워커 인프라 — Inngest, Trigger.dev, Defer, Hatchet — 를 붙이는 것이 일반적인 해법이다. 이것이 Vercel 의 진짜 비용 증가 요인이다.

워커가 무거운 SaaS — 이미지/비디오 처리, AI 추론, ETL — 라면 Vercel 보다는 Render · Fly · Railway 가 거의 항상 더 적합하다.

16장. 멀티 리전 — 글로벌 SaaS 의 현실

글로벌 사용자를 가진 SaaS 의 지연 시간을 50ms 이하로 잡고 싶다면 멀티 리전이 필요하다. 멀티 리전 지원의 현실은 이렇다.

가장 매끄러움 — Fly.io. fly scale count 1 --region nrt,sin,fra,iad 한 줄. 멀티 리전 Postgres 도 Fly 가 한때 잘 했고 (현재는 Supabase 와 협력 모델).

자동 엣지 — Vercel, Netlify. Edge Functions 와 정적 자산은 전 세계 엣지에 자동 배포. 그러나 데이터베이스는 엣지에 없다 — Neon, PlanetScale, Supabase 등이 멀티 리전 읽기 복제본을 제공.

리전 선택 가능 — Render, Railway, Northflank, Heroku. 한 서비스를 한 리전에 배포하지만 같은 서비스를 여러 리전에 동시 배포는 비교적 최근 기능이거나 베타. 글로벌 SaaS 의 첫 후보는 아니다.

자동 글로벌 — Cloud Run. --region 을 여러 개 지정하면 여러 리전에 같은 서비스를 띄울 수 있다. 단, Load Balancer 와 Cloud Run multi-region 설정을 본인이 짜야 한다.

글로벌 멀티 리전이 필수라면 Fly.io 가 가장 적은 마찰, Cloud Run 이 그 다음, Vercel + 글로벌 DB 가 그 다음이다.

17장. 결정 프레임 — 어느 PaaS 를 골라야 하는가

PaaS 선택의 단순한 결정 트리는 이렇다.

시작점: 어떤 앱인가?

1. Next.js · React Router · SvelteKit 위주의 SSG/SSR + 가벼운 API → Vercel (또는 Netlify). 다른 옵션은 가격이 비슷하거나 더 비싸고, Vercel 의 통합 가치가 크다.
2. 모놀리스 — Web + 워커 + DB + Redis 가 한 박스에서 도는 앱 → Render (또는 Railway). Heroku 같은 경험을 가장 잘 제공한다.
3. 글로벌 사용자, 멀티 리전 필수 → Fly.io. 가장 적은 마찰.
4. AWS 안에 모든 것이 있는 팀 → App Runner 또는 ECS Fargate. AWS 출구.
5. 본인 클라우드 / 데이터 주권 → Northflank.
6. 돈을 극단적으로 아끼고 운영 학습에 시간이 있는 솔로 → Coolify on Hetzner 또는 Dokku.
7. 이미 GCP → Cloud Run + Cloud SQL.
8. Salesforce 통합 → Heroku.

팀 규모로 다시 보면:

• 솔로 / 사이드 프로젝트 — Vercel (Hobby) · Fly · Railway · Coolify
• 2–5 명 작은 팀 — Vercel Pro · Render · Railway · Fly
• 5–20 명 시리어스 SaaS — Render · Railway · Northflank · Fly
• 20+ 명 / 컴플라이언스 필요 — Northflank · Heroku · App Runner · Cloud Run

시간으로 보면 (러닝 커브 짧은 순):

Vercel > Railway > Render > Heroku > Netlify > Fly > Cloud Run > Coolify > Northflank > App Runner > ECS Fargate.

18장. 안티 패턴 모음

PaaS 선택을 망치는 흔한 패턴을 정리한다.

1. 가격만 보고 결정 — Coolify on VPS 가 $13/월 이라고 본업 SaaS 를 거기에 올렸다가 한 번 다운에 비즈니스가 멈춘다. 매니지드 PaaS 의 $80 은 비싼 것이 아니라 보험료다.

2. "Vercel 이 다 한다" 가정 — Next.js 만 잘 하는 것이지 모든 워크로드를 잘 하는 것이 아니다. 항상 켜진 워커, 큰 모놀리스, WebSocket 중심 앱은 Vercel 밖이 더 낫다.

3. PaaS 안의 매니지드 DB 사용으로 시작 — Vercel Postgres, Render Postgres, Railway Postgres 는 시작하기 쉽지만 이전 비용이 크다. 처음부터 Neon / Supabase / PlanetScale 같은 독립 매니지드 DB 를 쓰면 PaaS 만 갈아끼울 수 있다.

4. 멀티 리전을 너무 일찍 도입 — 사용자가 한 대륙에 있는데 멀티 리전을 굳이 한다. 단일 리전 + CDN 으로 충분한 경우가 많다.

5. Free 티어를 본업에 사용 — Free 의 콜드 스타트, 슬립, 작은 리소스가 사용자 경험을 망친다. 본업은 유료 티어로 시작한다.

6. 콜드 스타트 무시 — Vercel · Cloud Run 의 콜드 스타트를 모르고 들어갔다가 첫 요청 1–3 초에 사용자가 떠난다. min instances ≥ 1 또는 항상 켜진 PaaS 로 옮긴다.

7. 백업과 모니터링을 PaaS 가 다 해 줄 것으로 가정 — Render · Railway 의 자동 백업은 일정 보관 기간만 보장한다. 본인이 추가 백업을 가져가지 않으면 사고 시 복구가 안 된다.

8. "PaaS 비용이 미쳤다" 라고 Kubernetes 로 이전 — PaaS 의 월 $200 이 미쳤다고 EKS 로 가면 EKS 의 $73/월 컨트롤 플레인 + 노드 비용 + 운영 시간 (= 주당 5 시간) 으로 결국 더 비싸진다. PaaS 가격이 거슬리면 먼저 같은 PaaS 카테고리 안에서 더 싼 곳 — Railway, Fly — 으로 옮기는 것을 시도한다.

에필로그 — 도구가 아니라 워크로드를 보라

PaaS 비교 글의 함정은 도구 중심 사고다. "Vercel vs Render" 가 아니라 "내 워크로드에 무엇이 맞는가" 가 질문이다. 같은 SaaS 라도 사용자 분포, 트래픽 패턴, 워커 부담, 데이터 크기, 컴플라이언스 요구가 다르면 답이 다르다.

2026 년의 풍경을 한 줄로 요약하면: Next.js = Vercel, 모놀리스 = Render, 글로벌 = Fly, 분당 과금 = Railway, 시리어스 멀티 클라우드 = Northflank, GCP = Cloud Run, AWS = App Runner, 셀프 호스팅 = Coolify. 이 8 개를 알면 새 프로젝트의 PaaS 결정은 거의 항상 5 분 안에 끝난다.

PaaS 선택 체크리스트

• 내 앱이 0 으로 스케일 다운 가능한 워크로드인가? (콜드 스타트 허용?)
• 영속 디스크가 필요한가?
• 항상 켜진 워커가 필요한가? 워커가 무거운가?
• 글로벌 사용자가 있는가? 50ms 이하 지연이 필수인가?
• 매니지드 Postgres / Redis 를 PaaS 안에서 받을 것인가, 외부 (Neon / Supabase / Upstash) 로 분리할 것인가?
• 컴플라이언스 — HIPAA, PCI, GDPR, 데이터 주권 — 가 필요한가?
• 팀 규모와 운영 가용 시간은 얼마인가?
• 떠나는 비용 — 다른 PaaS 로 이전 — 을 미리 계산했는가?
• 청구서가 트래픽 10 배 늘 때 어떻게 변하는가?
• 미리보기 환경, 롤백, 백업, 로그가 충분한가?

다음 글 예고

다음 글에서는 PaaS 위에 올라가는 매니지드 데이터베이스 — Neon · Supabase · PlanetScale · Turso · Cloudflare D1 · CockroachDB Serverless 를 같은 깊이로 비교한다. PaaS 결정의 절반은 DB 결정이다 — 그것을 분리해 보면 PaaS 결정이 더 자유로워진다.

참고 / References

• Vercel 가격 — https://vercel.com/pricing
• Vercel Active CPU 모델 — https://vercel.com/docs/pricing/billing
• Vercel AI SDK — https://sdk.vercel.ai
• Netlify 가격 — https://www.netlify.com/pricing
• Render 가격 — https://render.com/pricing
• Render 문서 — https://render.com/docs
• Fly.io 가격 — https://fly.io/docs/about/pricing
• Fly Machines — https://fly.io/docs/machines
• Fly Apps v2 — https://fly.io/docs/apps
• Railway 가격 — https://railway.com/pricing
• Railway Hobby vs Pro — https://docs.railway.app/reference/pricing
• Northflank 가격 — https://northflank.com/pricing
• Northflank BYOC — https://northflank.com/docs/byoc
• Heroku 가격 — https://www.heroku.com/pricing
• Heroku-24 스택 — https://devcenter.heroku.com/articles/heroku-24-stack
• Cloud Run 가격 — https://cloud.google.com/run/pricing
• Cloud Run 문서 — https://cloud.google.com/run/docs
• AWS App Runner — https://aws.amazon.com/apprunner
• AWS Fargate 가격 — https://aws.amazon.com/fargate/pricing
• Coolify — https://coolify.io
• Coolify 문서 — https://coolify.io/docs
• Dokku — https://dokku.com
• Neon — https://neon.tech
• Supabase — https://supabase.com
• Upstash — https://upstash.com
• Inngest (Vercel 워커 보완) — https://www.inngest.com
• Trigger.dev — https://trigger.dev
• Heroku 무료 티어 종료 발표 (2022) — https://blog.heroku.com/next-chapter