Vercel, Supabase, Firebase 같은 서버리스 서비스는 서버를 직접 관리하지 않아도 배포와 확장이 되니 무척 편합니다. 그런데 이 편리함의 뒤편에는 잘 알려지지 않은 함정이 하나 있습니다. 바로 서버리스 요금 폭탄입니다.
평소 월 몇만 원 하던 개인 프로젝트가, DDoS 공격 한 번이나 코드 버그 하나로 하루 만에 수천만 원 청구서로 돌아온 사례가 실제로 존재합니다. 전통적인 서버라면 트래픽이 몰려 사이트가 느려지거나 다운될 뿐이지만, 종량제 서버리스에서는 그 부하가 고스란히 요금으로 바뀝니다.
이 글에서는 서버리스의 종량제 과금이 어떻게 요금 폭탄으로 이어지는지, 실제로 얼마나 큰 청구가 나왔는지, 그리고 시스템을 설계할 때 무엇을 챙겨야 이런 사고를 막을 수 있는지 정리했습니다.
편한데 왜 요금이 터지나: 종량제 과금의 구조
서버리스의 과금은 대부분 사용한 만큼 낸다는 종량제(pay-as-you-go)입니다. 문제는 이 "사용량"의 상한이 사실상 없다는 데 있습니다. 트래픽이 무한히 늘어나면 요금도 무한히 늘어납니다.
대표적으로 요금이 쌓이는 항목은 다음과 같습니다.
- 대역폭(egress, 아웃바운드 트래픽): 사용자에게 나가는 데이터의 양. 요금 폭탄 사례의 압도적 다수가 여기서 터집니다.
- 함수 호출·컴퓨트: 서버리스 함수가 실행된 횟수와 시간.
- 요청 수(Edge Requests): 들어온 HTTP 요청 자체의 개수.
- 스토리지·읽기/쓰기: 데이터베이스나 파일 저장소의 입출력.
전통 서버는 CPU와 메모리가 포화되면 그 이상 처리하지 못하고 멈춥니다. 지갑에 줄 수 있는 피해가 자연스럽게 제한되는 셈입니다. 반면 서버리스는 자동으로 무한 확장되도록 설계돼 있어, 돈이 타는 속도까지 함께 무한 확장됩니다. 여기에 대부분의 서비스가 요청을 특정 금액에서 끊어주는 "회로 차단기"를 기본값으로 켜두지 않는다는 점이 겹칩니다.
실제 사례로 보는 서버리스 요금 폭탄
서버리스 과금 사고를 모아 놓은 ServerlessHorrors 같은 사이트를 보면, 이게 남의 일이 아니라는 게 실감이 납니다. 몇 가지만 추려 보겠습니다.
- Firebase, 하루 약 10만 달러: 어느 정도 인기를 끌던 WebGL 게임 업로드 사이트가 DoS 공격을 맞자, 단 하루 만에 청구액이 10만 달러(약 1억 4천만 원)까지 치솟았습니다.
- Netlify, 약 10만 4천 달러: 간단한 사이트가 DDoS성 대역폭 폭증으로 10만 달러가 넘는 연체 청구서를 받았습니다.
- Vercel, 약 4만 6천 달러: 트래픽이 폭증한 서비스가 여러 캐시 최적화를 적용한 뒤에도 대역폭 요금이 4만 6천 달러까지 늘었습니다. 또 다른 Vercel 사례에서는 스팸/공격성 트래픽으로 2만 3천 달러가 청구되기도 했습니다.
- Cloudflare, 약 3만 6천 달러: 사용자가 겨우 81명인 사이드 프로젝트가, 매 요청마다 실행되는 잘못된 로직과 폭주하는 큐 루프 때문에 3만 6천 달러를 청구받았습니다. 외부 공격이 아니라 자기 코드의 폭주가 원인이었다는 점이 무섭습니다.
- Firebase, 약 7만 달러: 평소 월 50달러를 내던 프로젝트에 어느 날 갑자기 7만 달러짜리 청구서가 날아왔습니다.
공통점이 보입니다. 사고의 원인은 대부분 대역폭, DDoS/DoS, 재귀 호출, 큐 루프, 잘못된 구현입니다. 대단한 규모의 서비스가 아니라, 사용자 수십 명짜리 개인 프로젝트도 순식간에 고액 청구로 이어질 수 있다는 뜻입니다.
[이미지: 서버리스 요금 폭탄 사례를 정리한 대시보드 화면]
DDoS·DoS가 서버리스에서 유독 위험한 이유
DDoS(분산 서비스 거부) 공격은 원래 서비스를 마비시키는 게 목적입니다. 그런데 종량제 서버리스에서는 목적이 하나 더 생깁니다. 바로 지갑을 태우는 것입니다.
예전에는 서버가 공격을 받으면 관리자가 플러그를 뽑아 버릴 수 있었습니다. 사이트는 내려가도 요금은 더 이상 오르지 않았습니다. 하지만 서버리스에서는 누가 /api를 분당 백만 번씩 호출하는지 실시간으로 알기 어렵고, 알아챘을 때는 이미 대역폭과 함수 호출 요금이 크게 쌓인 뒤인 경우가 많습니다.
여기서 두 가지가 문제를 키웁니다.
- 대역폭은 원가 대비 마진이 큽니다. 그래서 트래픽이 폭증하면 요금이 매우 가파르게 올라갑니다.
- 공격 트래픽과 정상 트래픽을 구분하기 어렵습니다. 하룻밤 사이에 서비스가 대박 난 것인지, 공격을 받는 것인지 플랫폼이 자동으로 판단하기 어렵기 때문에, 안전을 이유로 무작정 사이트를 내려주지도 않습니다.
실제로 일부 플랫폼은 무료 티어에서 DDoS를 당해 비상식적인 대역폭 청구서가 나와도, 이를 막기 위한 조치를 하지 않겠다고 명시하기도 했습니다. 결국 방어의 책임은 상당 부분 개발자 본인에게 있다는 뜻입니다.
Vercel 과금 구조와 지출 제어
Vercel은 프론트엔드와 Next.js 배포에 널리 쓰이는 서비스입니다. 2026년 기준 과금 구조의 핵심은 이렇습니다.
- Hobby(무료): 대역폭 100GB, Edge Requests 100만 회 등이 포함됩니다. 한도에 닿으면 초과 과금 대신 다음 결제 주기까지 프로젝트가 일시정지됩니다. 요금 폭탄은 없지만, 실제 사용자가 있는 서비스라면 사이트가 통째로 내려가는 셈이라 프로덕션용으로는 부적합합니다.
- Pro: 시트당 월 20달러이며 월 20달러 크레딧이 포함됩니다. Fast Data Transfer 1TB와 Edge Requests 1천만 회가 기본 제공되고, 이를 넘으면 종량제(온디맨드)로 과금됩니다.
중요한 건 지출 제어입니다. Vercel에는 Spend Management 기능이 있어 신규 팀은 기본적으로 200달러 예산과 50·75·100% 알림이 설정됩니다. 여기에 더해 "프로덕션 배포 자동 일시정지"를 직접 켜두면, 설정한 금액에 도달했을 때 모든 프로젝트를 멈출 수 있습니다.
주의할 점: Vercel의 지출 검사는 실시간이 아니라 몇 분 단위입니다. 그래서 한도를 넘긴 뒤에도 몇 분간은 트래픽이 계속 처리되며 요금이 쌓일 수 있습니다. 자동 일시정지를 켜더라도, 지출 한도는 실제로 감당 가능한 최대치보다 낮게 잡아 두는 편이 안전합니다.
또 하나, Pro·Enterprise에서는 기본값으로 100% 사용량에 도달해도 배포가 자동으로 멈추지 않습니다. 트래픽 급증 시에도 서비스를 계속 유지하려는 설계인데, 뒤집어 말하면 자동 일시정지 옵션을 직접 켜지 않으면 요금이 계속 올라간다는 뜻입니다.
Supabase 과금 구조와 Spend Cap
Supabase는 PostgreSQL 기반의 백엔드 서비스로, 데이터베이스·인증·스토리지·엣지 함수를 한 번에 제공합니다. 2026년 기준 과금 구조는 이렇습니다.
- Pro: 월 25달러 기본요금에 컴퓨트 크레딧 10달러가 포함됩니다. egress(아웃바운드 트래픽) 250GB, 데이터베이스 8GB, 월간 활성 사용자(MAU) 10만 명이 기본 제공됩니다.
- 초과 과금: egress는 캐시되지 않은 트래픽 기준 GB당 약 0.09달러입니다. 트래픽이 많은 미디어 서비스라면 이 항목이 요금을 가장 크게 좌우합니다.
Supabase의 큰 장점은 Spend Cap이 Pro 플랜에서 기본으로 켜져 있다는 점입니다. Spend Cap이 켜져 있으면 할당량을 넘긴 항목의 추가 사용이 다음 결제 주기까지 차단됩니다. 즉 초과분을 과금하는 대신 서비스를 제한하는 방식이라, 공격이나 코드 버그로 인한 예상 밖 요금을 상당 부분 막아 줍니다.
다만 이 안전장치에도 두 가지 트레이드오프가 있습니다. 첫째, Spend Cap을 끄면 그때부터는 egress·MAU 초과분이 그대로 과금됩니다. 성장을 위해 한도를 열어야 할 때는 이 위험을 함께 감수하는 셈입니다. 둘째, 무료 티어에서는 egress 한도(5GB)를 넘기면 API가 오류를 반환해 로그인과 가입이 즉시 멈추는 사례가 보고됩니다. 무료 티어를 실서비스에 쓰면 안 되는 이유입니다.
시스템 구축 시 반드시 챙길 고려사항
정리하면, 서버리스로 시스템을 올릴 때는 편리함만큼이나 비용 상한과 방어선을 함께 설계해야 합니다. 배포 전후로 아래를 점검하세요.
1. 지출 한도부터 켠다
가장 먼저 할 일입니다. Supabase는 Spend Cap을 켜진 상태로 유지하고, Vercel은 Spend Management에서 지출 금액과 자동 일시정지를 직접 활성화합니다. 한도는 감당 가능한 최대치보다 여유 있게 낮춰 잡습니다.
2. DDoS 방어와 요청 제한(Rate Limiting)을 앞단에 둔다
Cloudflare 같은 WAF/DDoS 방어를 서비스 앞에 배치하면, 공격 트래픽이 오리진에 도달하기 전에 걸러집니다. 특정 IP나 경로에 대한 초당 요청 수를 제한하는 rate limiting도 함께 걸어 둡니다.
3. 캐시와 CDN으로 대역폭을 줄인다
요금 폭탄의 대부분은 대역폭에서 터집니다. 이미지·동영상·정적 파일은 CDN 뒤에 두어 캐시 적중률을 높이고, 오리진에서 직접 나가는 트래픽을 최소화합니다. 캐시된 트래픽은 대개 훨씬 저렴합니다.
4. 무료 티어를 프로덕션에 쓰지 않는다
무료 티어는 한도 도달 시 서비스가 멈추거나 오류를 반환합니다. 실사용자가 있는 서비스라면 유료 플랜에 지출 제어를 얹는 조합이 안전합니다.
5. 내 코드의 폭주부터 막는다
Cloudflare 81명 사례처럼, 공격이 아니라 재귀 호출·무한 큐 루프·매 요청마다 도는 무거운 쿼리가 요금을 태우는 경우도 많습니다. 배포 전에 함수 호출과 DB 입출력이 폭증하는 지점이 없는지 점검하고, 성공·실패 양쪽 시나리오로 부하 테스트를 해 봅니다.
6. 실시간 알림과 모니터링을 건다
지출 알림(50·75·100%)과 사용량 대시보드를 반드시 활성화합니다. 다만 일부 과금 지표는 보고가 몇 시간 늦을 수 있으니, 알림은 최후의 안전장치가 아니라 보조 수단으로 봅니다. 진짜 방어선은 자동 일시정지와 앞단의 트래픽 차단입니다.
7. 아키텍처를 하이브리드로 검토한다
트래픽이 크고 예측이 어려운 서비스라면, 대역폭이 큰 정적·미디어 전송은 정액제 대역폭을 제공하는 CDN이나 VPS로 분리하는 것도 방법입니다. 성공하든 공격받든 요금 상한이 정해져 있다는 안정감이 생깁니다.
자주 묻는 질문
서버리스에서 DDoS를 맞으면 정말 수천만 원이 청구되나요?
지출 한도를 걸어두지 않으면 실제로 가능합니다. 종량제 과금은 트래픽이 늘어난 만큼 요금이 그대로 올라가기 때문에, 대역폭이나 함수 호출을 노린 공격이 며칠만 이어져도 평소 수만 원 하던 요금이 수천만 원으로 불어난 사례가 여럿 보고됐습니다. 그래서 배포 전에 지출 한도와 DDoS 방어를 반드시 설정해야 합니다.
Vercel과 Supabase는 지출 한도 기능이 있나요?
둘 다 있습니다. Supabase Pro는 Spend Cap이 기본으로 켜져 있어 할당량을 넘으면 해당 항목 사용이 다음 결제 주기까지 차단됩니다. Vercel은 Spend Management에서 지출 금액과 프로젝트 자동 일시정지를 직접 설정해야 하며, 검사 주기가 몇 분 단위라 한도를 실제 상한보다 낮게 잡는 것이 안전합니다.
무료 티어로 서비스를 운영해도 괜찮을까요?
실제 사용자가 있는 서비스라면 권장하지 않습니다. 무료 티어는 한도에 닿으면 초과 과금 대신 서비스 자체를 막아버리는 경우가 많습니다. 예를 들어 한도를 넘으면 API가 오류를 반환해 로그인과 가입이 통째로 멈추거나, 다음 결제 주기까지 사이트가 내려갑니다. 프로덕션에는 유료 플랜과 지출 제어를 함께 쓰는 편이 안전합니다.
마무리
서버리스는 분명 강력하고 편리한 선택지입니다. 다만 그 편리함은 비용 상한과 방어선을 스스로 설계했을 때 비로소 안전해집니다. 지출 한도 활성화, DDoS 방어와 요청 제한, CDN·캐시를 통한 대역폭 절감, 무료 티어 회피, 내 코드의 폭주 점검 — 이 다섯 가지만 배포 전에 챙겨도 대부분의 요금 폭탄은 예방할 수 있습니다.
새 서비스를 서버리스로 올리려는데 과금 구조와 방어 설계가 부담스럽거나, 이미 운영 중인 사이트의 비용·보안 리스크가 걱정된다면 Codeless-Studio가 도와드릴 수 있습니다. 저희는 사이트를 구축·리뉴얼할 때 과금 구조와 트래픽 방어까지 함께 설계하는 것을 원칙으로 합니다. 부담 없이 무료 상담부터 시작해 보세요.