1인 개발자를 위한 백엔드 스택: Cloudflare Workers, Supabase, Node.js 선택 방법

도구의 frontend가 끝났습니다. 이제 /api/submit, /api/checkout-webhook, /api/report-cron을 구현하고 users, usage_events, files를 저장해야 합니다. 무엇을 Workers, Supabase, 별도 Node 서비스에 둘까요?

백엔드 스택은 한 플랫폼으로 끝나지 않습니다. 요청 진입, 업무 데이터, 파일, 장기 작업, 인증, Webhook을 나눕니다. Workers는 edge와 가벼운 로직, Supabase는 Auth와 Postgres, Node.js는 edge runtime 밖의 무거운 작업을 담당합니다. 다음 표를 backlog와 비교합니다.

1. 백엔드 역할표: 무엇을 어디에 둘까

API, Webhook, Cron, 데이터, 파일 목록부터 봅니다.

역할	권장 시작점	이유	주의점
요청 진입	Cloudflare Workers	글로벌 edge와 낮은 latency	CPU·메모리·의존성 초과 작업 분리
가벼운 API	Workers / Edge Functions	전달, 검증, 짧은 I/O	Workers는 edge, Edge Functions는 Supabase project 중심
Webhook	Workers 또는 Edge Functions	callback, 서명, idempotent write	무거운 작업은 queue로 이동
인증	Supabase Auth	Auth, RLS, 권한, social login	service role/secret을 browser에 노출하지 않음
업무 데이터	Supabase Postgres	관계, transaction, query, trigger	D1도 migration, constraint, 권한 필요
객체 저장	Supabase Storage / R2	upload, image, export, backup	접근, egress, CDN, 도구로 선택
장기 작업	Node.js worker / task platform	browser, 큰 파일, native module, consumer	전체 lifecycle을 동기 HTTP에 묶지 않음
Node 서비스	Node.js	npm, 장기 연결, 완전한 runtime	deploy, monitoring, patch, scaling 운영

모든 것을 Workers에 넣으라는 표가 아닙니다. Workers에는 한계, Supabase에는 quota와 pause, Node.js에는 운영 비용이 있습니다. Node 도입은 늦출 수 있지만 신호는 알아야 합니다.

데이터 위치 결정

• 업무 데이터 → 관계, transaction, query, trigger, foreign key가 필요하면 Supabase Postgres 또는 관계형 DB.
• 파일 → 권한, egress, CDN, region, toolchain에 따라 Supabase Storage 또는 R2.
• Cache → KV. D1은 가벼운 관계형 edge 데이터에 쓸 수 있지만 업무 source of truth를 대신하지 않습니다.

D1, Postgres, R2, S3, SQLite 비교는 저장소 글에서 다룹니다. 여기서는 유형만 배분합니다.

Webhook과 장기 작업 분리

Stripe/GitHub Webhook은 Workers 또는 Edge Functions가 받습니다. handler는 서명을 확인하고 idempotency record를 쓴 뒤 빠르게 응답합니다. browser, 큰 파일, 여러 단계 외부 대기는 Queue, Workflow, Container, Node.js로 넘깁니다.

Workers Paid HTTP CPU는 기본 30초, 최대 5분입니다. 1시간 이상 간격의 Cron은 CPU 15분까지 가능합니다. client 연결 중 HTTP wall-clock은 고정되지 않지만 disconnect, retry, resource, runtime update 때문에 장기 작업을 request에 묶으면 불안정합니다.

무료 플랜 경계

2026년 7월 Workers Free는 하루 100,000 request, 10 ms CPU, 128 MB, 50 subrequest입니다. Supabase Free는 50,000 MAU, 500 MB DB, 5 GB egress, 1 GB 파일, active project 2개입니다.

시작 예산이지 장기 약속이 아닙니다. Supabase Free는 1주 미사용 시 pause되고 Workers는 Free 초과 시 Paid가 필요합니다. 안정된 사용자나 결제가 생기면 usage alert, 비용표, degrade 전략을 둡니다.

2. Cloudflare Workers에 맞는 작업과 맞지 않는 작업

Workers의 경계는 JavaScript 여부가 아니라 CPU, memory, subrequest, bundle size입니다.

2026년 7월 Workers Free 제한

하루 100,000 request, invocation당 10 ms CPU, 128 MB memory, 50 subrequest, 압축 3 MB입니다. CPU 초과는 1102입니다. client 연결 중 HTTP wall-clock은 고정되지 않으며 응답 또는 disconnect 뒤 ctx.waitUntil()은 최대 30초입니다.

Workers Paid Standard 제한

계정당 월 최소 5달러로 1,000만 request와 3,000만 CPU ms를 포함합니다. HTTP CPU 기본 30초, 최대 5분입니다. 추가 request는 백만당 0.30달러, CPU는 백만 ms당 0.02달러입니다. 10,000 subrequest, 10 MB, 128 MB입니다.

적합한 작업

• 요청 진입, edge proxy, 가벼운 API.
• Webhook 수신, 서명, idempotent enqueue.
• Cron, Queues, Workflows orchestration.
• KV/R2, cache header, redirect, A/B.

network I/O, 검증, orchestration이 중심이며 큰 buffer, browser process, native library가 없습니다.

부적합한 작업

• 지속 CPU → 분할, 비동기, Node.js/Container.
• 큰 파일 전체 buffer → stream 또는 direct upload.
• 장기 browser → Node.js + Playwright/Puppeteer.
• runtime 밖 dependency → Node.js 또는 container.

Node 호환 API가 있어도 모든 workload가 적합한 것은 아닙니다. resource, retry, duration, observability를 봅니다.

비용 경계

평균 5 ms면 월 1,000만 request가 5,000만 CPU ms입니다. 포함분 이후 추가 CPU는 약 0.40달러이며 KV, Queues, R2는 별도일 수 있습니다.

핵심 기능이 무료 quota 안에서만 성립하는지가 더 중요합니다. rate limit, cache, fallback을 준비합니다.

3. Supabase: Auth, Postgres, Storage, Edge Functions 경계

Supabase는 Postgres, Auth, Storage, Realtime, Edge Functions를 묶지만 각각 한계가 있습니다.

2026년 7월 Supabase Free 제한

project당 500 MB DB, 50,000 MAU, 5 GB egress, 5 GB cached egress, 1 GB 파일이며 active Free project는 2개입니다. 1주 미사용 시 pause되므로 검증용이지 production 가용성 약속이 아닙니다.

Supabase Pro 제공량

월 25달러부터 100,000 MAU, 8 GB disk, 250 GB egress, 250 GB cached egress, 100 GB 파일입니다. 월 10달러 compute credit가 포함되고 추가 resource는 과금됩니다.

적합한 작업

• email, OAuth, session, RLS.
• 관계, constraint, transaction, query.
• 접근 policy가 있는 파일.
• Postgres trigger, function, migration.
• Auth, Postgres, Storage와 밀접한 Edge Functions.

사용자 데이터 write, 관련 row update, upload metadata처럼 Supabase 중심이면 운영 component를 줄입니다.

Edge Functions 제한

TypeScript/Deno runtime이며 256 MB, request당 CPU 2초, idle timeout 150초입니다. 최대 wall-clock은 Free 150초, Paid 400초입니다.

wall-clock은 I/O 대기를 포함하지 CPU 예산이 아닙니다. browser, native multithread, video, 큰 파일은 전용 worker로 옮깁니다. background task도 같은 한계입니다.

Edge Functions와 Workers 선택

• Supabase 중심 로직 → Edge Functions.
• 독립 edge 진입 또는 proxy → Workers.

subscription update는 Edge Functions, 서명·rate limit·forward는 Workers가 직접적입니다. 긴 작업은 queue로 보냅니다.

Project pause

Free는 1주 미사용 시 pause됩니다. 가끔 쓰는 도구는 재개를 기다릴 수 있고 안정 제품은 Pro, backup, migration을 평가합니다.

4. Node.js가 여전히 필요한 때

Serverless는 운영을 줄이지만 완전한 runtime, system dependency, 상시 process 수요를 없애지 않습니다.

Node.js가 필요한 작업

• Playwright/Puppeteer.
• 큰 파일, 복잡한 parsing, temporary disk.
• native module 또는 edge 밖 npm.
• 상시 queue consumer, WebSocket, admin API.
• 통일된 resource와 observability가 필요한 backend.

screenshot, PDF, 수집, video, 큰 파일은 더 많은 CPU, memory, process, filesystem이 필요합니다.

Node.js 전환 신호

CPU, memory, duration, bundle, compatibility 한계가 반복되거나 browser, native module, 장기 연결, 안정된 queue가 필요하면 평가합니다.

“30초 초과”만 보지 않습니다. 제품별 한계가 다르며 resource, retry, idempotency, observability model에 안정적으로 맞는지가 핵심입니다.

Node.js가 필요 없는 때

• API forward 또는 edge routing.
• 가벼운 I/O 검증과 DB write.
• 큰 파일, native dependency, 장기 연결 없음.
• 서버 운영을 정당화할 수요 없음.

Workers 또는 Edge Functions로 충분합니다.

Node.js는 오래되지 않았다

edge는 제약과 낮은 운영·global 배포를 교환하고 Node.js는 인프라와 호환성·resource control·상시 process를 교환합니다. 역할이 다르며 실제 browser, 파일, dependency 수요가 생길 때 추가합니다.

5. Workers + Supabase: API client 또는 Hyperdrive

두 제품은 경쟁보다 edge 진입과 identity·업무 데이터를 결합합니다.

Workers와 Supabase 조합

Workers는 forward, validation, rate limit, cache를 하고 Supabase Auth/Postgres는 identity, 데이터, policy를 담당합니다. 서버 없는 첫 제품에 적합합니다.

Auth, Data API, Storage만 쓰면 supabase-js로 충분합니다. SQL, transaction, ORM이 잦으면 invocation마다 direct connection을 만들지 말고 driver와 pool을 씁니다.

연결 방식 표

방식	용도	설명
Supabase JS Client	Auth, Storage, 가벼운 query	API를 통해 JWT와 RLS 유지
Hyperdrive + driver	SQL, ORM, direct Postgres	connection pool과 일부 read cache
service role / secret key	신뢰 backend 관리	RLS bypass 가능, 격리된 server client만 사용

Hyperdrive는 Supabase Postgres 연결 latency와 pressure를 줄입니다. 권한 system이 아니며 role, table, RLS는 credential과 policy가 결정합니다.

Service role key 위험

고권한이며 RLS를 bypass할 수 있습니다. browser, mobile, public repository, log에 노출하지 않고 backend secret으로 둡니다.

관리용 server client를 분리해 user session이 Authorization을 덮지 않게 합니다. Webhook, batch, admin은 최소 권한과 audit가 필요합니다.

Edge Functions/Workers 경계

• Supabase 의존이 강함 → Edge Functions.
• 독립 진입, proxy, rate limit, routing → Workers.

데이터와 권한 중심, edge 기능, log/deploy 위치로 결정합니다. 고권한 key는 항상 backend secret입니다.

6. 데이터 소유: 업무 데이터, 파일, 캐시

D1, Postgres, KV, R2는 서로 다른 문제를 해결합니다.

데이터 소유 표

유형	시작점	기준
업무 사실	Supabase Postgres / D1 / 관계형 DB	관계, transaction, constraint, query, migration, 권한
파일	Supabase Storage / R2 / S3	접근, egress, CDN, lifecycle, tooling
캐시/설정	KV / Cache	빠른 read, 재구축, 허용 consistency

user, order, subscription, project, entitlement는 결제와 접근에 영향을 줍니다. constraint, migration, backup이 있는 DB에 둡니다. Postgres는 query, foreign key, trigger, transaction, MVCC를 제공합니다. D1도 별도 평가가 필요합니다.

파일을 1 GB 기준으로 나누지 않습니다. Supabase Storage는 Auth/RLS 파일, R2는 Cloudflare traffic/CDN 객체에 맞습니다. policy, egress, upload, 변환, SDK로 고릅니다.

cache는 업무 DB가 아닙니다. 주문과 권한이 cache에만 있으면 만료, 지연, 삭제가 실제 상태를 바꿉니다.

전체 저장소 비교는 후속 글에서 다룹니다.

7. 시리즈의 다음 단계

다음에는 deploy, DB와 storage, 결제, 인증과 권한을 다룹니다.

관련 BetterLink 글

Cloudflare Pages 배포, Cloudflare Free Plan Limits 2026, Workers API proxy, Supabase 시작, Supabase Edge Functions를 참고합니다.

먼저 자신의 역할표 만들기

이번 주의 동작 5개에 “응답 / identity / 업무 사실 / 파일 / 작업 / secret”을 표시하고 Workers, Supabase, Node.js 또는 보류로 배정합니다. platform보다 책임과 실패 경로가 안정성을 결정합니다.