서버리스 비용 최적화의 핵심은 “가장 싼 플랫폼”을 고르는 것이 아니라, 호출 수·실행 시간·데이터 전송·로그 비용 중 어디가 커지는지 먼저 찾는 것입니다. 작은 SaaS나 AI 자동화 API를 만들 때는 Vercel Functions, AWS Lambda, Cloudflare Workers가 모두 좋아 보이지만, 실제 청구서는 트래픽 패턴에 따라 꽤 다르게 나옵니다.
이 글에는 제휴(어필리에이트) 링크가 포함될 수 있으며, 링크를 통해 가입·구매 시 소정의 수수료를 받을 수 있습니다. 추천은 실제 사용 경험에 기반합니다.
최근 7일 서버리스 로그를 내려받아 호출 수·실행 시간·외부 API 호출을 먼저 비교해보세요.
특히 Cursor나 Claude Code로 기능을 빠르게 붙이면 API 라우트가 늘고, n8n·Zapier 같은 자동화가 주기적으로 호출하면서 예상보다 빨리 무료 구간을 넘어갈 수 있습니다. 결론부터 말하면, 짧고 잦은 요청은 Cloudflare Workers, AWS 생태계와 이벤트 처리가 중요하면 Lambda, 프론트와 API를 한 저장소에서 빠르게 배포하려면 Vercel이 편합니다.
최근 7일 로그에서 호출 수, 평균 실행 시간, 외부 API 호출 횟수만 뽑아보세요. 이 세 값이면 비용이 새는 위치가 거의 보입니다.
처음 봐야 할 비용 항목은 4개입니다
서버리스는 서버를 직접 켜두지 않아도 되지만, 공짜 구조는 아닙니다. 비용은 대체로 요청 수, 실행 시간, 메모리, 데이터 전송량, 그리고 관측 도구 로그 저장량에서 생깁니다.
AI 기능을 붙인 서비스라면 여기에 OpenAI API, Anthropic API, 벡터DB, Supabase 호출 비용도 함께 봐야 합니다. 서버리스 함수 자체는 몇 천 원인데, 함수가 매번 LLM을 호출해 외부 API 비용이 더 커지는 경우가 흔합니다.
Vercel은 배포 속도가 빠르지만 로그와 대역폭을 같이 봐야 합니다
Next.js 기반 랜딩 페이지, 대시보드, 결제 웹훅을 한 번에 운영한다면 Vercel은 생산성이 좋습니다. GitHub에 푸시하면 미리보기 배포가 자동으로 뜨고, 팀원이 Cursor로 수정한 PR도 바로 확인할 수 있습니다.
다만 이미지 최적화, 대역폭, 함수 실행 시간이 함께 늘면 예상보다 청구가 커질 수 있습니다. API 라우트에서 큰 JSON을 자주 내려주거나, 매 요청마다 DB를 여러 번 조회하는 구조라면 캐싱부터 손봐야 합니다.
AWS Lambda는 세밀한 제어가 강점입니다
Lambda는 SQS, EventBridge, DynamoDB, API Gateway와 붙일 때 장점이 큽니다. 배치성 작업, 웹훅 처리, 이미지 변환, 백오피스 자동화처럼 이벤트 기반 흐름이 많다면 비용을 촘촘하게 조절할 수 있습니다.
대신 API Gateway, CloudWatch Logs, NAT Gateway 같은 주변 비용을 놓치기 쉽습니다. “Lambda는 싼데 AWS 청구서가 이상하다”면 함수가 아니라 로그 보관 기간이나 네트워크 구성이 원인일 수 있습니다.
Cloudflare Workers는 짧은 엣지 작업에 유리합니다
짧은 인증 체크, 리다이렉트, 캐시 프록시, 지역별 응답 분기처럼 실행 시간이 짧은 작업은 Cloudflare Workers가 가볍습니다. 전 세계 엣지에서 동작하기 때문에 간단한 API를 빠르게 응답시키는 데도 좋습니다.
반대로 긴 작업, 무거운 Node.js 라이브러리, 복잡한 백엔드 처리에는 제약을 먼저 확인해야 합니다. Workers KV, D1, R2까지 함께 쓰면 구조는 깔끔해지지만, 서비스별 과금 단위를 따로 관리해야 합니다.
비교표: 어떤 서비스가 어떤 상황에 맞나
| 선택지 | 잘 맞는 작업 | 주의할 비용 | 점검 도구 |
|---|---|---|---|
| Vercel Functions | Next.js 앱, SaaS 대시보드, 결제 웹훅 | 대역폭, 함수 실행 시간, 이미지 최적화 | Vercel Analytics, 로그 대시보드 |
| AWS Lambda | 이벤트 처리, 큐 기반 작업, AWS 연동 | CloudWatch Logs, API Gateway, NAT Gateway | AWS Cost Explorer, CloudWatch |
| Cloudflare Workers | 짧은 엣지 API, 캐싱, 프록시 | 요청 수, KV/D1/R2 사용량 | Cloudflare Analytics |
| Supabase Edge Functions | DB와 가까운 인증·웹훅 처리 | 함수 호출, DB 읽기/쓰기, egress | Supabase Dashboard |
가상의 예시: AI 요약 봇 API를 만든다면
예를 들어 Slack 메시지를 받아 요약하고 Notion에 저장하는 봇을 만든다고 가정해보겠습니다. n8n이 5분마다 Slack을 확인하고, 서버리스 함수가 OpenAI API를 호출한 뒤 Notion API로 결과를 넣는 구조입니다.
이 경우 함수 실행 비용보다 불필요한 주기 호출과 중복 LLM 요청이 더 큰 문제가 됩니다. 해결은 간단합니다. Slack 이벤트 기반으로 바꾸고, 같은 메시지 ID는 Redis나 Supabase 테이블에 저장해 재처리를 막습니다. Claude Code나 Codex에게 “이 함수에서 외부 API가 중복 호출되는 지점과 캐시 키 후보를 찾아줘”라고 시키면 코드 리뷰 시간을 줄일 수 있습니다.
추천 대상별 선택
개인 빌더·초기 SaaS
프론트와 API를 빠르게 붙여 검증해야 한다면 Vercel이 편합니다. 다만 무료 구간 안에 있다고 방심하지 말고, API 라우트별 평균 실행 시간과 응답 크기를 매주 확인하세요.
자동화·백오피스 작업이 많은 팀
Zapier, Make, n8n, Slack 웹훅처럼 이벤트가 많은 구조라면 AWS Lambda나 Cloudflare Workers가 더 경제적일 수 있습니다. 작업 시간이 짧고 트래픽이 전 세계에 흩어져 있으면 Workers, 내부 시스템과 AWS 리소스가 많으면 Lambda가 무난합니다.
이미 Supabase를 쓰는 프로젝트
인증, DB, RLS 정책을 Supabase에 두고 있다면 Edge Functions로 시작하는 것도 좋습니다. 단, 모든 로직을 한곳에 몰기보다 무거운 AI 작업은 큐나 별도 워커로 빼는 편이 안정적입니다.
가장 흔한 실수: 함수만 줄이고 로그는 방치한다
많은 팀이 메모리와 실행 시간만 줄입니다. 그런데 실제로는 디버그 로그가 과하게 쌓이거나, 실패한 재시도가 계속 발생해 비용을 키우는 일이 많습니다.
운영 로그는 필요한 필드만 남기고, 개발용 콘솔 출력은 배포 전에 제거하세요. CloudWatch나 Vercel 로그 보관 정책도 확인해야 합니다. 비용 알림은 최소 50%, 80%, 100% 구간으로 나눠 설정해두면 갑작스러운 청구를 막는 데 도움이 됩니다.
바로 적용할 체크리스트
- 최근 7일 기준 요청 수 상위 5개 함수 확인
- 각 함수의 평균 실행 시간과 p95 실행 시간 비교
- 외부 API 호출이 반복되는지 로그에서 샘플링
- 캐시 가능한 응답은 Cloudflare Cache, Vercel Edge Config, Redis 검토
- 로그 보관 기간과 디버그 출력 제거
- AWS Cost Explorer 또는 Infracost로 월 예상 비용 확인
FAQ
서버리스가 항상 VM보다 저렴한가요?
아닙니다. 호출이 드물고 실행 시간이 짧으면 유리하지만, 항상 켜진 작업이나 긴 배치에는 일반 서버, 컨테이너, 예약 작업이 더 나을 수 있습니다.
AI 기능이 들어가면 어디부터 줄여야 하나요?
함수 비용보다 LLM 호출 횟수를 먼저 보세요. 프롬프트 캐싱, 중복 요청 차단, 요약 결과 저장만 해도 체감 비용이 줄어드는 경우가 많습니다.
비용 예측을 자동화할 수 있나요?
가능합니다. AWS는 Cost Explorer와 Budgets, IaC를 쓰는 팀은 Infracost를 붙일 수 있습니다. Vercel과 Cloudflare는 대시보드 알림을 먼저 켜두는 것이 현실적인 출발점입니다.
다음 행동: 오늘은 플랫폼을 바꾸기보다 가장 많이 호출되는 함수 1개만 고르세요. 그 함수의 로그, 외부 API 호출, 캐시 가능 여부를 점검하면 서버리스 비용 최적화의 첫 성과를 빠르게 확인할 수 있습니다.
관련 링크
- 관련 태그 더 보기
- 카테고리 더 보기
- 검색 결과 더 보기
- 참고 링크
