작년 말, 스타트업 CTO 친구 하나가 술자리에서 이런 말을 했다. “서버리스 했다가 AWS 청구서 보고 심장 멎는 줄 알았어.” Lambda 콜드 스타트에 낚이고, API Gateway 비용에 데이고, DynamoDB 설계 잘못 잡았다가 쿼리 비용이 폭탄이 된 케이스였다. 반면 나는 같은 기간 동안 서버리스로 풀스택 SaaS를 론칭해서 월 인프라 비용 $47에 MAU 8,000명을 운영하고 있다. 차이가 뭐냐고? 삽질의 양이다. 내가 먼저 다 틀렸으니까, 여러분은 안 틀려도 된다.
이 글은 서버리스 아키텍처를 풀스택 개발에 실제로 적용하면서 겪은 현장의 이야기다. AWS, Vercel, Supabase, Cloudflare Workers까지 2026년 현재 가장 실전적인 스택 조합과 함께, 절대로 하면 안 되는 실수까지 전부 털어놓는다.
- 🔥 서버리스가 진짜 유리한 상황 vs 독이 되는 상황
- 📊 2026년 주요 서버리스 플랫폼 비용·성능 비교표
- ⚙️ 풀스택 서버리스 실전 아키텍처 설계 (Next.js + Supabase + Vercel)
- 🌍 국내외 실제 도입 사례로 보는 설계 패턴
- 🚫 절대 하지 말아야 할 실수 체크리스트
- ❓ 독자 FAQ: 콜드 스타트, 비용 폭탄, 인증 설계
서버리스가 진짜 유리한 상황 vs 독이 되는 상황
서버리스(Serverless)는 “서버가 없다”는 말이 아니다. 서버 관리를 플랫폼에 위임한다는 뜻이다. 핵심은 이벤트 기반 실행(Event-Driven Execution)과 사용량 기반 과금(Pay-per-invocation)이다.
2026년 현재 AWS Lambda 기준으로 보면, 첫 100만 건 호출은 무료, 이후 100만 건당 $0.20이다. 메모리 1GB 기준 1초 실행 시 $0.0000166667. 트래픽이 간헐적이고 예측 불가능한 스타트업엔 이게 EC2 t3.medium ($0.0416/시간) 대비 압도적으로 유리하다.
그런데 문제는 항상 트래픽이 있는 서비스다. Lambda는 트래픽이 상시 발생하면 EC2보다 비싸진다. 내 계산으론 월 4,000만 건 이상 호출이 지속되면 EC2 전환이 낫다. 이 기준선을 모르고 무작정 서버리스 했다가 청구서 폭탄 맞는 거다.
2026년 주요 서버리스 플랫폼 비용·성능 벤치마크 비교
2026년 기준으로 풀스택 개발자가 실제로 선택할 수 있는 서버리스 플랫폼은 크게 다섯 갈래다. 직접 프로젝트에 써보고, 커뮤니티 벤치마크(Cloudflare 공식 블로그, Vercel Engineering Blog, InfoQ 2026 서버리스 리포트)를 교차 검증해서 정리했다.
| 플랫폼 | 콜드 스타트 (p95) | 실행 단가 | 무료 티어 | 엣지 지원 | 풀스택 궁합 |
|---|---|---|---|---|---|
| AWS Lambda | 300~800ms (Node.js) | $0.20/100만 건 | 100만 건/월 | Lambda@Edge | ⭐⭐⭐⭐ |
| Vercel Functions | 50~150ms | $0.40/100만 건 (Pro) | 100GB-Hrs/월 | Edge Runtime ✅ | ⭐⭐⭐⭐⭐ |
| Cloudflare Workers | 0~5ms (V8 Isolate) | $0.30/100만 건 | 10만 건/일 | 엣지 네이티브 | ⭐⭐⭐⭐ |
| Supabase Edge Functions | 100~300ms (Deno) | $2/100만 건 | 50만 건/월 | 제한적 | ⭐⭐⭐ |
| Google Cloud Run | 500ms~2s (컨테이너) | $0.24/100만 건 | 200만 건/월 | △ | ⭐⭐⭐ |
결론부터 말하면: 2026년 풀스택 서버리스 입문자에게 최적 조합은 Vercel + Supabase다. 콜드 스타트가 가장 짧고, Next.js App Router와의 통합이 네이티브 수준이며, Supabase의 Row Level Security(RLS)로 백엔드 인증 로직의 70%를 날릴 수 있다.
풀스택 서버리스 실전 아키텍처 설계: Next.js + Supabase + Vercel
내가 실제로 운영 중인 SaaS의 아키텍처를 그대로 공개한다. MAU 8,000명, 월 API 호출 약 230만 건, 인프라 비용 $47/월 기준이다.
레이어 구조는 이렇다:
[클라이언트 (Next.js 15 App Router)]
↓ RSC (React Server Components) 렌더링
[Vercel Edge Network]
↓ API Routes (서버리스 함수, Node.js Runtime)
[Supabase]
├── PostgreSQL (RLS 적용)
├── Auth (JWT + Magic Link)
├── Realtime (WebSocket)
└── Storage (이미지, 파일)
↓ 외부 연동
[Stripe Webhooks → Vercel API Route → Supabase DB]
[Resend (이메일 API) → Vercel Cron Jobs]
핵심 포인트 3가지:
- RSC(React Server Components)를 적극 활용해라. Next.js 15에서 RSC는 서버에서 데이터를 fetch해서 HTML로 내려주므로, 별도의 API Route를 만들 필요가 없다. Supabase 클라이언트를 서버 컴포넌트에서 직접 호출하면 왕복 레이턴시가 사라진다.
- Vercel Cron Jobs로 배치 작업을 처리해라. Pro 플랜 기준 최소 1분 간격, Free 플랜은 1일 1회. 별도의 cron 서버가 필요 없다. Resend와 조합하면 뉴스레터, 리마인더 자동화가 코드 20줄로 끝난다.
- Supabase RLS를 제대로 세팅해라. 이게 핵심이다. Row Level Security를 켜면 데이터베이스 단에서 사용자 권한 체크가 이뤄진다. 백엔드 함수에서 권한 검증 로직 따로 안 짜도 된다는 뜻이다. 단, RLS 정책을 잘못 쓰면 데이터 유출 사고난다. 이건 뒤에서 자세히 다룬다.
국내외 실제 도입 사례: 설계 패턴 분석
이론만 늘어놓으면 재미없으니까 실제 사례 얘기를 해보자.
① Notion의 API 레이어 (부분 서버리스 전환)
Notion은 2025년부터 일부 API 엔드포인트를 Cloudflare Workers로 이전했다. 이유는 단순하다. 전 세계 사용자에게 엣지 레이턴시 30ms 이하를 보장하기 위해서다. Workers의 V8 Isolate 모델은 컨테이너 기반 Lambda보다 콜드 스타트가 100배 가까이 빠르다. 단, Workers는 Node.js 호환성이 완전하지 않아서 npm 패키지를 그대로 쓰지 못하는 경우가 있다. Notion은 이 제약 때문에 핵심 비즈니스 로직은 여전히 기존 서버에 두고 엣지는 캐싱과 라우팅 레이어로만 쓴다.
② 카카오 if(kakao) 2025 발표: 서버리스 이벤트 처리
카카오의 경우 메시지 발송 이벤트 처리에 AWS Lambda + SQS 조합을 도입해서 트래픽 피크 시 자동 스케일링을 구현했다고 밝혔다. 특이한 점은 Lambda를 직접 HTTP로 노출하지 않고, SQS(Simple Queue Service)를 버퍼로 끼워서 트래픽 폭증 시 함수 동시 실행(Concurrency) 제한에 걸리는 문제를 해결했다는 것이다. Lambda의 기본 리전별 동시 실행 한도는 1,000개다. 이걸 모르고 설계하면 트래픽 피크 때 함수 실행이 throttle 걸린다.
③ 국내 스타트업 ‘스택플로우’ 사례 (지인 케이스)
내 지인이 운영하는 B2B SaaS인데, 초기에 EC2 기반으로 시작했다가 서버리스로 전환했다. 전환 후 인프라 비용이 월 $380에서 $62로 줄었다. 다만 전환 과정에서 세션 기반 인증을 JWT로 바꾸는 작업이 가장 고통스러웠다고 했다. 서버리스는 상태(State)가 없으므로(Stateless), 기존 세션 방식은 쓸 수 없다. 이 마이그레이션만 2주 걸렸다.
절대 하지 말아야 할 실수: 서버리스 풀스택 체크리스트
- ❌ Lambda에 무거운 의존성 패키지 번들링하기 — 패키지 사이즈가 클수록 콜드 스타트가 길어진다. Moment.js 대신 date-fns 쓰고, 트리 쉐이킹(Tree-shaking) 필수. Lambda 패키지 용량 제한은 압축 기준 50MB다.
- ❌ API Gateway 없이 Lambda URL 직접 노출 — 인증 레이어 없이 Lambda Function URL을 공개하면 DDoS에 그대로 노출된다. 반드시 WAF 또는 Cloudflare 앞단에 붙여라.
- ❌ Supabase RLS 비활성화 채로 운영 — 개발 편의성 때문에 RLS를 끄는 경우가 많다. 프로덕션 배포 전 반드시 RLS 정책 켜고 테스트. anon 키가 유출되면 RLS 없이는 전체 데이터 노출이다.
- ❌ DynamoDB 파티션 키 설계 실수 — 파티션 키를 userId 하나로만 잡으면 핫 파티션(Hot Partition) 문제가 생긴다. 복합 키(PK + SK) 패턴과 GSI(Global Secondary Index)를 처음부터 설계해라.
- ❌ Vercel 무료 플랜에서 Cron Job 의존 — Free 플랜 Cron은 1일 1회 제한이다. 분 단위 배치가 필요하면 처음부터 Pro로 시작하거나, Inngest 같은 서드파티 워크플로우 툴을 써라.
- ❌ 환경 변수 하드코딩 — .env 파일을 깃허브에 올리는 건 2026년에도 여전히 일어난다. Vercel 환경 변수 대시보드, AWS Secrets Manager를 써라. 절대 코드에 API 키 박지 마라.
- ❌ 콜드 스타트 무시하고 UX 설계 — 중요한 첫 화면 API가 Lambda로 처리되는 구조라면, Provisioned Concurrency를 켜거나 엣지 함수로 이동해라. 첫 로드에서 800ms 지연은 이탈률을 15% 높인다 (Google UX Research 2026 기준).
FAQ
Q1. 콜드 스타트가 너무 신경 쓰이는데, 완전히 없애는 방법이 있나요?
완전히 없애는 건 불가능하다. 다만 줄일 수 있다. 방법 세 가지: ① Cloudflare Workers로 이동 — V8 Isolate 방식이라 JVM이나 컨테이너 부팅이 없어서 콜드 스타트가 0~5ms 수준이다. ② Lambda Provisioned Concurrency 활성화 — 미리 워밍업된 실행 환경을 예약해두는 방식. 비용이 추가되지만 콜드 스타트가 사실상 사라진다. 시간당 $0.0000041 추가. ③ Next.js App Router + RSC 전환 — 클라이언트에서 Lambda를 직접 호출하는 구조 자체를 없애버리면 콜드 스타트 문제도 없어진다.
Q2. 서버리스 환경에서 WebSocket(실시간 기능)은 어떻게 구현하나요?
서버리스는 기본적으로 Stateless라 WebSocket을 직접 유지하기 어렵다. 선택지는 두 가지다: ① Supabase Realtime — PostgreSQL 변경사항을 WebSocket으로 브로드캐스트해준다. 채팅, 알림 기능에 충분하다. ② Ably, Pusher, PartyKit 같은 관리형 WebSocket 서비스를 쓰는 것. 서버리스 함수는 메시지를 트리거하는 역할만 하고, 연결 유지는 서비스에 위임한다. PartyKit은 2026년 현재 Cloudflare Durable Objects 기반으로 서버리스 WebSocket의 새로운 대안으로 급부상 중이다.
Q3. 기존 Express.js 백엔드를 서버리스로 마이그레이션할 때 어디서부터 시작해야 하나요?
한 번에 다 옮기려다 죽는다. 스트랭글러 피그 패턴(Strangler Fig Pattern)을 써라. 새로운 기능부터 서버리스로 만들고, 기존 Express는 살려두는 거다. 실용적인 순서: ① 인증/로그인 엔드포인트를 Supabase Auth로 교체 → ② 정적 자산과 SSR을 Vercel로 이동 → ③ 트래픽이 낮고 독립적인 API 엔드포인트부터 Lambda로 분리 → ④ 마지막으로 핵심 비즈니스 로직 이전. 이 과정에서 반드시 통합 테스트를 먼저 작성해두고 각 단계마다 회귀 테스트를 돌려라. 마이그레이션 실수의 90%는 테스트 없이 이전하다 생긴다.
종합 평점: ★★★★☆ (4.2/5)
2026년 현재 서버리스 풀스택은 이미 성숙기에 접어들었다. 과거처럼 “실험적”이라는 말 붙일 단계가 아니다. Vercel + Supabase 조합은 초기 스타트업부터 중규모 SaaS까지 커버하고, AWS Lambda + Cloudflare Workers 혼합 전략은 엔터프라이즈에서도 증명됐다. 문제는 기술이 아니라 설계 실수다. 이 글에서 나열한 체크리스트 항목 하나하나가 다 누군가의 야근이고, 누군가의 장애 보고서다.
에디터 코멘트 : 서버리스는 공짜 점심이 아니다. 서버 관리 비용을 설계 복잡도로 치환한 거다. 이 트레이드오프를 이해하고 시작하는 팀과 모르고 시작하는 팀은 6개월 후 인프라 청구서 앞에서 완전히 다른 표정을 짓게 된다. 지금이라도 늦지 않았다. 설계부터 다시 봐라.
📚 관련된 다른 글도 읽어 보세요
- Siemens vs Allen-Bradley PLC: The Definitive 2026 Comparison Every Automation Engineer Needs
- 2026 PLC 자동화 트렌드 최신 기술 동향 총정리 – 현장 엔지니어가 체감한 변화
- Full-Stack Framework Trends 2026: What Every Engineer Should Actually Be Building With Right Now
태그: 서버리스 아키텍처, 풀스택 개발, Next.js Supabase, AWS Lambda 최적화, Vercel 배포, 서버리스 비용 절감, 2026 클라우드 개발
Leave a Reply