1인 개발 배포 비교: Cloudflare, Vercel, Railway 선택법

배포 화면에는 blog, tool-api, dashboard, worker-daily-report 네 서비스가 있습니다. 앞의 두 개는 Cloudflare, 세 번째는 Vercel에서 실행되고 마지막 하나는 Railway와 Workers 사이에서 결정하지 못했습니다. 막히는 지점도 build 횟수, Workers CPU, Vercel 청구, 컨테이너와 함수 선택으로 서로 다릅니다.

1인 개발이라도 콘텐츠 사이트, 도구, SaaS dashboard, 예약 작업이 함께 존재합니다. 중요한 비교는 어느 브랜드가 이기는지가 아니라 각 서비스에 맞는 runtime과 비용·운영 기준입니다.

1. 네 서비스가 서로 다른 제한에 도달하는 상황

blog는 Cloudflare Pages의 Astro 정적 사이트입니다. 콘텐츠, 스타일, 설정을 바꿀 때마다 deployment가 실행되어 Free의 월 500 builds에 가까워집니다. 20,000 files에는 여유가 있지만 Pages Functions로 구현한 댓글과 검색은 Workers 할당량을 사용합니다.

tool-api는 login과 persistence를 처리하는 경량 Workers API입니다. traffic이 늘면 100,000 requests/day가 부족할 수 있고 계산이 많은 요청은 10 ms CPU를 넘을 수 있습니다. Workers Paid는 월 5달러부터이며 요청과 CPU는 정적 호스팅과 다른 모델입니다.

dashboard는 Vercel의 Next.js full-stack app입니다. Preview deployment는 편리하지만 usage page는 Functions, Images, Builds, Analytics 등을 나눠 표시합니다. 추가 paid seat는 1인당 월 20달러입니다. Hobby에는 Active CPU 4 hours, Provisioned Memory 360 GB-hrs, 1 million invocations가 포함됩니다.

worker-daily-report는 매일 보고서를 만들고 email로 보냅니다. Workers도 예약 코드를 실행하지만 장시간 또는 계산량이 큰 job은 CPU와 memory 경계에 맞지 않을 수 있습니다. Railway는 Node process를 실행할 수 있지만 RAM, CPU, egress, volume을 관리해야 합니다. Hobby는 월 5달러에 5달러 사용량이 포함됩니다.

공통 원칙은 workload 형태에 따라 분리하는 것입니다. 정적 콘텐츠, 경량 함수, 전체 앱, 장기 작업을 한 공급자에 억지로 넣을 필요는 없습니다.

2. 네 플랫폼의 핵심 제한

2.1 Cloudflare Pages: 정적 asset은 무료, 함수는 Workers 할당량 사용

Cloudflare Pages는 정적 asset hosting과 global delivery가 중심입니다. 현재 Free의 주요 제한은 다음과 같습니다.

• 월 500 builds이며 Git push와 수동 build가 할당량을 사용합니다.
• site당 20,000 files이며 이미지나 생성 page가 많으면 총수를 확인합니다.
• asset 하나는 최대 25 MiB이며 큰 영상과 data file은 object storage에 둡니다.
• Free는 project당 100 custom domains입니다.
• build timeout은 20분입니다.

Pages Functions의 request와 CPU는 Pages 정적 할당량이 아니라 Workers plan에 포함됩니다.

• 정적 asset은 Pages 제한 안에서 제공됩니다.
• 댓글, 검색, API proxy는 Workers 할당량과 가격을 사용합니다.
• Astro와 Hugo에 잘 맞으며 Next.js는 현재 adapter와 runtime 지원을 확인합니다.

Pages는 콘텐츠 사이트와 정적 도구의 좋은 시작점입니다. 동적 요청이나 복잡한 계산이 많다면 별도의 Workers workload로 계산합니다.

2.2 Cloudflare Workers: 요청과 CPU 경계가 있는 경량 함수

Workers는 경량 API, edge logic, 도구 backend를 위한 Cloudflare runtime입니다. 현재 제한은 다음과 같습니다.

• Free는 100,000 requests/day입니다.
• Free의 HTTP request는 CPU 10 ms이며 network I/O 대기 자체는 CPU 시간에 포함되지 않습니다.
• Workers Paid 구독은 월 5달러입니다.
• Standard는 월 10 million requests를 포함합니다.
• Standard는 월 30 million CPU milliseconds를 포함합니다.
• Free와 Paid 모두 isolate당 memory 128 MB입니다.

적합한 작업:

• authentication, lookup, 단순 business logic을 처리하는 경량 API.
• 댓글과 검색을 위한 Pages Functions.
• cache, routing, authorization을 추가하는 API proxy.

적합하지 않은 작업:

• 긴 report 생성과 batch processing.
• 무거운 계산, 대용량 memory 처리, ML inference.
• isolate runtime과 맞지 않는 전통적인 connection pool.

Workers는 작은 도구 backend에 맞지만 성장 후의 request와 CPU를 미리 계산해야 합니다. 상주 process와 resource-heavy job은 다른 runtime으로 옮깁니다.

2.3 Vercel: Next.js에 강하지만 청구서는 seat만이 아님

Vercel은 Next.js 통합과 Preview deployment가 강점입니다. Hobby 함수 resource와 다른 사용량을 분리해 확인합니다.

• Active CPU 4 hours.
• Provisioned Memory 360 GB-hrs.
• 1 million function invocations.
• on-demand concurrency 또는 Elastic build machine 사용 시 build CPU minute당 0.0035달러입니다.
• 추가 paid team seat는 월 20달러입니다.
• deployment는 Free 100/day, Pro 6,000/day입니다.
• upload는 Free 5,000/day, Pro 40,000/day입니다.

청구 항목은 여러 개입니다.

• Functions: CPU, memory, invocation.
• Images: transformation, cache read, cache write.
• Builds: 과금 대상 설정의 CPU.
• Analytics: Web Analytics와 Speed Insights.
• Observability: event 기반 monitoring과 add-on.

주의할 지점:

• preview가 많으면 build usage와 deployment 수가 늘고 과금 machine이나 concurrency에서는 추가 비용이 생깁니다.
• Image Optimization에는 별도의 included usage와 on-demand rate가 있습니다.
• Analytics와 Observability도 따로 확인합니다.

Vercel은 Next.js full-stack product의 실용적인 시작점입니다. plan 가격, usage category, team seat를 각각 모니터링해야 합니다.

2.4 Railway: resource 사용량으로 과금하는 컨테이너 runtime

Railway는 서비스, worker, database를 위한 PaaS입니다. 구독과 resource usage를 분리해 과금합니다.

• Hobby는 월 5달러, Pro는 월 20달러입니다.
• Hobby는 월 5달러 resource usage를 포함합니다.
• Pro는 월 20달러 resource usage를 포함합니다.
• RAM은 GB-month당 10달러입니다.
• CPU는 vCPU-month당 20달러입니다.
• network egress는 GB당 0.05달러입니다.
• volume storage는 GB-month당 0.15달러입니다.
• Free 기본 상한은 service당 RAM 0.5 GB, 1 vCPU, volume 0.5 GB입니다.

운영 판단은 여전히 필요합니다.

• 실제 RAM, CPU, egress, volume 사용량을 모니터링합니다.
• resource와 log alert를 설정합니다.
• rollback과 rebuild에 영향을 주는 image-retention window를 확인합니다.
• health check, restart, backup을 정의합니다.

비용 주의점:

• 5달러 또는 20달러의 included credit를 넘은 만큼 청구됩니다.
• service를 멈추지 않으면 RAM, CPU, storage를 계속 사용합니다.
• egress와 persistent volume은 서로 독립적으로 늘어납니다.

Railway는 Node 서비스, background job, database에 적합합니다. 인프라 작업을 줄이지만 서비스 책임을 없애지는 않습니다.

3. workload별 플랫폼 결정표

3.1 콘텐츠 사이트와 문서

콘텐츠 사이트는 대부분 정적 asset이며 동적 기능이 적습니다.

workload	권장 시작점	주요 기준
Astro 또는 Hugo 정적 사이트	Cloudflare Pages	월 500 builds, 20,000 files
Next.js SSG	Cloudflare Pages 또는 Vercel	adapter, build time, build 설정
댓글 또는 검색	Pages Functions	request와 CPU는 Workers에 포함

Astro나 Hugo에는 Pages가 자연스럽습니다. 자세한 내용은 Cloudflare Pages 배포 가이드와 Cloudflare Free 제한을 참고합니다.

Next.js SSG에서는 오래된 지원 여부를 반복하지 말고 현재 framework support와 build behavior를 확인합니다. Vercel은 native workflow를 제공하며 정적 출력 중심이면 Cloudflare도 후보입니다.

댓글과 검색은 Pages Functions로 구현할 수 있지만 request와 CPU는 Workers에 속합니다. 정적 delivery와 동적 execution을 분리합니다.

3.2 정적 도구와 동적 도구

generator나 converter는 browser에서 끝날 수 있지만 login과 persistence가 들어가면 동적 product가 됩니다.

workload	권장 시작점	주요 기준
browser 전용 도구	Cloudflare Pages	build와 file 제한
경량 동적 API	Cloudflare Workers	Free 100,000 requests/day, CPU 10 ms
Next.js full-stack 도구	Vercel	Functions, Images, Builds, Observability

browser 안에서만 계산하면 Pages에 맞습니다. 작은 API는 요청이 가볍고 isolate에 맞는 동안 Workers에 둘 수 있습니다.

Next.js full-stack 도구는 Vercel workflow의 이점을 얻지만 preview, image, function runtime, monitoring을 따로 계산합니다.

3.3 SaaS dashboard

SaaS dashboard에는 application logic, authorization, data access, collaboration이 필요합니다.

workload	권장 시작점	주요 기준
Next.js full-stack	Vercel	Functions, Images, Builds, Analytics
다른 framework	Workers 또는 Vercel	현재 framework 및 runtime 지원
team collaboration	Vercel 또는 Railway	seat, permission, plan

Next.js dashboard라면 Vercel이 직접적인 시작점입니다. Pro를 전부 포함된 요금으로 보지 말고 Function, Image, preview Build, Analytics, Observability, team seat를 확인합니다. Cloudflare 가격 비교도 참고할 수 있습니다.

다른 framework에서는 현재 adapter와 runtime feature를 비교합니다. Workers는 edge logic, Vercel은 지원되는 serverless framework에 맞습니다.

database hosting은 별도 결정입니다. Supabase, managed Postgres, D1, Railway Volume에는 독자적인 비용과 신뢰성 경계가 있습니다.

3.4 장기 작업과 컨테이너 서비스

report 생성, file 처리, queue consumer, persistent API는 짧은 함수와 다른 runtime이 필요합니다.

workload	권장 시작점	주요 기준
Node service 또는 worker	Railway	RAM, CPU, egress, volume
database	Railway 또는 managed database	volume 비용, backup 정책
background job	Railway	usage alert, restart 정책

Railway는 전체 runtime에서 상주 Node process를 실행합니다. 대신 limit, log, health check, restart, backup을 관리합니다.

Railway Volume으로 data를 유지할 수 있지만 storage price만으로 database 전략이 완성되지는 않습니다. backup과 restore test가 필요합니다.

예약 작업에는 usage alert와 최대 resource profile을 정합니다. 상주하거나 memory를 많이 쓰는 worker는 Hobby credit를 넘을 수 있습니다.

4. 비용 모델과 경고 기준

4.1 Cloudflare 비용 모델

Cloudflare는 Pages 정적 delivery와 Workers 동적 execution을 분리합니다.

Pages 정적 asset:

• Pages product limit 안에서는 정적 asset의 transfer에 usage 기반 요금이 없습니다.
• 월 500 builds에 가까우면 불필요한 deployment를 줄입니다.
• 20,000 files에 가까우면 큰 asset을 object storage로 옮깁니다.
• Pages Functions는 별도 무제한 동적 할당량이 아니라 Workers quota를 사용합니다.

Workers execution:

• Free는 100,000 requests/day와 HTTP request당 CPU 10 ms를 포함합니다.
• Workers Paid는 월 5달러 구독부터 시작합니다.
• Standard는 월 10 million requests를 포함합니다.
• Standard는 월 30 million CPU milliseconds를 포함합니다.

경고 기준:

• Pages hard limit에 도달하면 추가 build가 막힐 수 있습니다.
• request나 CPU가 늘면 Workers Free에서 Paid로 전환해야 합니다.
• Pages 정적 배포가 무료여도 Pages Functions가 무제한은 아닙니다.

일반적인 시작점은 Pages와 Workers Free 조합입니다. traffic이나 CPU가 급해지기 전에 Paid 전환 조건을 정합니다.

4.2 Vercel 비용 모델

Vercel은 여러 infrastructure와 developer experience resource를 분리합니다.

Hobby function resource:

• Active CPU 4 hours.
• Provisioned Memory 360 GB-hrs.
• 1 million invocations.
• on-demand concurrency 또는 Elastic build machine은 build CPU minute당 0.0035달러입니다.

usage category:

• Functions: Active CPU, Provisioned Memory, invocation.
• Images: transformation, cache read, cache write.
• Builds: 과금 설정의 preview 및 production build.
• Analytics: Web Analytics, Speed Insights.
• Observability: event와 monitoring.

team seat:

• 추가 paid seat는 1인당 월 20달러입니다.
• seat 비용에 다른 infrastructure나 add-on 초과분은 포함되지 않습니다.

경고 기준:

• preview deployment가 많으면 build usage와 deployment가 늘어납니다.
• image 처리에는 별도의 included amount와 가격이 있습니다.
• Analytics와 Observability를 별도로 확인합니다.
• Function CPU, memory, invocation을 현재 plan과 비교합니다.

usage page를 category별로 읽는 것이 안전합니다. Next.js 개발 시간을 줄여도 청구서는 여러 항목으로 나올 수 있습니다.

4.3 Railway 비용 모델

Railway는 구독과 측정된 resource usage를 결합합니다.

plan과 included usage:

• Hobby는 월 5달러이며 5달러 사용량을 포함합니다.
• Pro는 월 20달러이며 20달러 사용량을 포함합니다.
• Free는 service당 최대 RAM 0.5 GB, 1 vCPU, volume 0.5 GB와 소액의 월 credit를 제공합니다.

resource rate:

• RAM은 GB-month당 10달러입니다.
• CPU는 vCPU-month당 20달러입니다.
• network egress는 GB당 0.05달러입니다.
• volume storage는 GB-month당 0.15달러입니다.
• 삭제한 deployment image는 plan의 retention window 동안만 이용할 수 있습니다.

경고 기준:

• included credit를 넘은 사용량은 차액으로 청구됩니다.
• service를 중지하지 않으면 RAM, CPU, storage를 계속 소비합니다.
• egress와 volume은 구독과 별개로 증가합니다.

Railway는 VPS 설정을 줄여 주지만 resource monitoring은 남습니다. production 전에 alert와 rollback window를 확인합니다.

5. 유지보수: 배포 빈도, 로그, rollback, 협업

변경이 잦은 프로젝트에서는 build와 deployment quota가 중요합니다. 협업에는 seat와 permission이 추가됩니다.

deployment와 build 빈도

• Cloudflare Pages Free는 월 500 builds와 동시 build 1개를 허용하며 Git preview build도 할당량을 사용합니다.
• Vercel은 Free 100 deployments/day, Pro 6,000/day이며 preview가 많으면 build usage도 늘어납니다.
• Railway는 같은 형식의 deployment 횟수를 제시하지 않지만 삭제한 image는 plan별 rollback window 동안만 남습니다.

Pages build와 Vercel deployment가 iteration을 막기 전에 모니터링합니다. Vercel build machine과 concurrency가 과금 대상인지도 확인합니다.

로그, rollback, team access

• Cloudflare Pages는 build log, deployment history, rollback을 제공합니다. collaborator의 현재 account 및 permission 조건을 확인합니다.
• Vercel은 preview, history, log, Analytics, paid seat를 제공합니다. 추가 seat는 월 20달러입니다.
• Railway는 log와 metrics를 제공합니다. health check, restart rule, backup, workspace collaboration은 명시적으로 설정합니다.

가장 중요한 서비스에서 반복 작업을 가장 많이 줄이는 workflow를 선택합니다. Next.js app에는 preview가, 콘텐츠 사이트에는 예측 가능한 정적 build가 더 중요할 수 있습니다.

6. 다음 단계: database, storage, CI/CD

배포 플랫폼은 stack의 한 층일 뿐입니다. database, storage, CI/CD, monitoring, alerting은 별도 결정이 필요합니다. 다음 글에서는 Supabase, Postgres, Railway Volume, object storage를 비교합니다.

목표는 공급자 수를 줄이는 것이 아닙니다. traffic이 늘기 전에 각 workload의 limit, 비용, 운영 책임을 설명할 수 있는 runtime에 배치해야 합니다.