VPC 하나가 정말 더 쌀까? 서버리스와 단일 서버의 비용 구조 비교

웹 인프라2026년 7월 29일글: 홍서진, Duolabs14분 읽기blog cloud-cost model-openai-gpt-5.5 serverless technical-note vpc

Vercel에 앱을 올리고, Supabase에 데이터를 저장하고, Upstash Redis로 요청 제한을 걸고, QStash로 비동기 작업을 전달한다고 해보자. 서비스 이름만 네 개다. 이쯤 되면 자연스럽게 이런 생각이 든다.

차라리 한곳에 앱, PostgreSQL, Redis, 워커를 모두 넣으면 더 단순하고 싸지 않을까?

결론부터 말하면 월 청구액만 보면 단일 VM이 더 쌀 수 있다. 하지만 개인 프로젝트에서는 관리형 서비스의 무료 구간이 오히려 더 싸고, 업무 시스템에서는 운영 시간과 장애 복구까지 포함하면 결과가 다시 뒤집힐 수 있다.

비교할 때 가장 먼저 버려야 할 오해도 있다. VPC는 서버 한 대가 아니라 네트워크 경계다. 같은 VPC 안에 컴퓨트, 데이터베이스, 캐시, 로드 밸런서, NAT 게이트웨이를 각각 두면 비용 항목도 각각 생긴다. 단순해지는 것은 공급자 수와 네트워크 경로이지, 필요한 역할 자체가 아니다.

이 글은 2026년 7월 공개 가격을 기준으로 작은 웹 업무 시스템의 비용 구조를 비교한다. 환율과 세금은 제외하고 모두 달러로 표기했다.

먼저, 네 서비스는 무엇에 돈을 받는가

각 서비스는 같은 일을 중복해서 파는 것이 아니다.

서비스	맡는 역할	비용이 늘어나는 대표 요인
Vercel	웹 앱, API 실행, 배포, CDN	실행 시간, 요청, 전송량, 팀 요금제
Supabase	PostgreSQL, 인증, 파일, 백업	컴퓨트 크기, 저장 공간, 전송량, 사용자 수
Upstash Redis	공유 캐시, 요청 제한, 짧게 유지할 상태	명령 수, 데이터 크기, 전송량
QStash	비동기 HTTP 작업 전달, 예약 실행, 재시도	전달 시도 횟수, 전송량

이 구분은 비용 절감에도 중요하다. 주문 데이터는 PostgreSQL에 있어야 하지만, 모든 프로젝트에 Redis와 QStash가 필요한 것은 아니다. 인스턴스 간 공유 상태나 분산 요청 제한이 없으면 Redis를 빼도 된다. API 응답 뒤로 미룰 작업과 재시도가 없다면 QStash도 빼도 된다.

가장 싼 서비스는 무료 서비스가 아니라, 아직 필요하지 않아 만들지 않은 서비스다.

개인 프로젝트: 네 개를 써도 기본료는 0달러일 수 있다

공식 가격표의 무료 구간만 놓고 보면 다음과 같다.

항목	무료 구간의 핵심 내용
Vercel Hobby	월 0달러, 개인·비상업 프로젝트용
Supabase Free	월 0달러, DB 500MB와 월 활성 사용자 5만 명 포함
Upstash Redis Free	월 0달러, DB 1개, 256MB, 월 50만 명령
QStash Free	월 0달러, 하루 1,000메시지

작은 학습용 CRUD나 포트폴리오라면 네 서비스를 연결해도 현금 지출이 없을 수 있다. 이 단계에서는 월 12달러짜리 VM도 무료 조합보다 비싸다.

물론 0달러가 무제한을 뜻하지는 않는다. Vercel Hobby는 사용량 한도를 넘으면 추가 요금을 내고 계속 쓰는 방식이 아니라, 대체로 주기가 갱신될 때까지 해당 기능을 기다려야 한다. Supabase 무료 프로젝트는 일주일 동안 활동이 없으면 일시 중지될 수 있다. 무엇보다 Vercel은 Hobby를 개인·비상업 용도로 명시한다. 매출이나 고객 업무와 연결되는 순간 무료 조합을 운영 비용의 기준으로 삼으면 안 된다.

무료 구간은 학습 비용을 낮추는 장치이지, 상용 서비스의 영구 예산안이 아니다.

작은 상용 서비스: 관리형 조합은 월 45달러부터

작은 상용 서비스가 유료 플랜으로 올라간다고 가정해 보자.

Vercel Pro: 월 20달러, 20달러의 사용량 크레딧 포함
Supabase Pro: 월 25달러부터, 유료 조직에 월 10달러의 컴퓨트 크레딧 포함
Upstash Redis 사용량제: 명령 10만 건당 0.20달러
QStash 사용량제: 메시지 전달 10만 건당 1달러

따라서 Vercel과 Supabase의 최소 고정비는 월 45달러다. 예를 들어 Redis 명령이 월 100만 건이고 QStash 전달 시도가 월 10만 건이면 각각 2달러와 1달러이므로 단순 합계는 월 48달러다. Vercel과 Supabase의 포함량을 넘는 사용료, 세금은 별도다.

여기서 QStash의 '메시지'는 작업 등록 건수와 완전히 같지 않다. 대상 API가 실패해 한 번 재시도되면 전달 시도가 두 번이므로 두 건으로 계산된다. 장애가 길어질수록 비용과 로그가 함께 늘어나는 구조다.

Supabase도 월 25달러로 모든 것이 끝나는 것은 아니다. 공식 설명상 프로젝트마다 전용 Postgres 인스턴스가 있고 컴퓨트 시간은 별도로 계산된다. 다만 유료 조직에 제공되는 월 10달러 컴퓨트 크레딧이 기본 Micro 인스턴스 한 개의 약 10달러 비용을 상쇄하므로, 첫 번째 작은 프로젝트는 보통 25달러 예시가 성립한다. 프로젝트를 추가하거나 컴퓨트 크기를 올리면 계산이 달라진다.

단일 VM: 월 12~24달러라는 강력한 숫자

한 공급자의 VM 한 대에 웹 앱, PostgreSQL, Redis, 워커를 함께 실행하면 서비스별 기본료를 하나의 컴퓨트 요금으로 합칠 수 있다.

비교 가능한 공개 가격의 예로 AWS Lightsail Linux VM은 다음과 같다.

월 요금	메모리	SSD	포함 전송량
12달러	2GB	60GB	3TB
24달러	4GB	80GB	4TB

인스턴스 스냅샷은 GB당 월 0.05달러다. 80GB 전체를 스냅샷으로 보관한다고 단순 가정하면 월 4달러가 추가되어, 4GB VM과 스냅샷 한 벌은 월 28달러다.

앞의 관리형 조합 45달러와 비교하면 월 17달러, 연 204달러 차이다. 현금 청구액만 보면 단일 VM이 이긴다. 트래픽이 꾸준하고 한 대의 용량 안에 들어오며 운영 경험이 있다면 이 차이는 충분히 의미가 있다.

다만 이 비교에는 중요한 비대칭이 있다. 단일 VM의 28달러에는 다음 작업을 수행하는 사람의 시간이 들어 있지 않다.

운영체제와 런타임 보안 업데이트
PostgreSQL 백업, 보관, 실제 복구 시험
디스크 부족과 메모리 압박 감시
인증서, 방화벽, 접근 권한 관리
장애 원인 조사와 재기동
배포 실패 시 되돌리기
한 장애가 앱·DB·캐시·워커를 동시에 멈추는 상황에 대한 대응

연 204달러를 아끼기 위해 이 작업에 쓰는 시간의 내부 원가가 204달러를 넘는다면, 총비용에서는 관리형 조합이 더 싸다. 반대로 운영 자동화가 이미 있고 장애 허용 수준이 높다면 단일 VM의 현금 절감 효과가 그대로 남는다.

가용성을 맞추면 단일 서버의 가격 우위는 줄어든다

단일 VM은 싼 대신 하나의 장애 영역이다. 앱과 DB를 분리하고 로드 밸런서를 추가하면 더 이상 '한 대 가격'으로 비교할 수 없다.

AWS가 공개한 Lightsail 다계층 애플리케이션 예시도 컨테이너 서비스 7달러, 관리형 데이터베이스 15달러, 로드 밸런서 18달러로 합계 월 40달러다. 여기에 캐시, 작업 큐, 백업 정책을 추가하면 45달러 관리형 조합과의 차이는 더 작아진다.

즉 두 선택지를 공정하게 비교하려면 기능뿐 아니라 가용성 수준도 맞춰야 한다.

비교	단일 VM	관리형 조합
가장 낮은 월 청구액	유리	상용 기본료가 있음
장애 영역 분리	직접 구성	서비스별로 분리됨
백업·패치 책임	사용자	공급자가 상당 부분 담당
사용량 급증	용량 증설 필요	사용량 기반 확장에 유리
비용 예측	고정형이라 쉬움	여러 미터를 함께 봐야 함
개발 초기 속도	운영 기반이 있으면 빠름	기반이 없어도 빠름

“VPC 하나”가 반드시 비용을 줄이지는 않는다

VPC 자체는 논리적으로 격리된 네트워크다. 그 안에 여러 관리형 자원을 배치하면 보안 경계와 통신 경로는 정리되지만, 컴퓨트·DB·캐시·큐 비용이 하나로 합쳐지는 것은 아니다.

오히려 사설 서브넷을 정석대로 구성하면서 예상하지 못한 네트워크 고정비가 생기기도 한다. AWS의 미국 오하이오 리전 예시에서 NAT 게이트웨이는 시간당 0.045달러다. 730시간을 단순 적용하면 데이터 처리 비용 전에도 약 월 32.85달러다. 1GB 처리마다 0.045달러가 더해지고 인터넷 전송 비용도 별도일 수 있다.

물론 모든 VPC 구성이 NAT 게이트웨이를 요구하는 것은 아니다. 핵심은 'VPC 하나'라는 표현만으로 비용을 추정할 수 없다는 점이다. 실제 비용은 그 안에 몇 개의 인스턴스와 관리형 자원, 가용 영역, 게이트웨이를 두는지에 따라 결정된다.

비용은 세 줄로 나눠 봐야 한다

아키텍처 비용을 판단할 때는 다음 세 줄을 따로 적는 편이 좋다.

1. 플랫폼 청구액

월 기본료, 실행 시간, 명령 수, 메시지 수, 저장 공간, 전송량이다. 가격 계산기가 보여주는 숫자다.

2. 운영 인건비

배포, 패치, 모니터링, 백업 검증, 장애 대응에 들어가는 시간이다. 청구서에는 없지만 사라지지 않는다.

3. 실패 비용

복구하지 못한 데이터, 긴 중단 시간, 고객 대응, 다른 개발을 멈춘 기회비용이다. 평소에는 0으로 보이지만 사고가 난 달에 한꺼번에 나타난다.

간단한 식으로 쓰면 이렇다.

월 총비용 = 플랫폼 청구액 + 운영 시간의 원가 + 장애·복구의 기대비용

관리형 서비스는 첫 번째 줄이 크고 두 번째와 세 번째 줄을 줄이는 선택이다. 단일 VM은 첫 번째 줄을 줄이는 대신 나머지 두 줄을 더 직접 떠안는 선택이다.

상황별로 고르면 결론은 단순하다

개인 학습·포트폴리오

Vercel, Supabase, Upstash의 무료 구간을 활용하는 편이 현금과 시간 모두에서 유리하다. 네 서비스를 모두 연결하는 것이 학습 목표라면 좋은 참조 구현이 된다. 실제 기능이 목적이라면 Redis와 QStash는 필요가 생길 때 추가한다.

작은 사내 도구·제한된 사용자

운영 담당자가 있고 잠깐의 중단을 감수할 수 있으며 사용량이 일정하다면 단일 VM이 합리적일 수 있다. 다만 백업 파일이 있다는 사실과 복구할 수 있다는 사실은 다르므로, 정기적인 복구 시험 비용까지 예산에 넣어야 한다.

고객이 사용하는 상용 서비스

월 45달러의 기본료가 개발자 몇 시간과 장애 위험을 줄여준다면 관리형 조합이 경제적일 가능성이 높다. Vercel Hobby는 이 용도에 맞지 않으므로 Pro 이상을 기준으로 계산한다. 비용 통제를 위해 각 서비스의 예산 상한과 알림을 켜고, 같은 리전에 가깝게 배치해 지연과 전송량을 줄인다.

트래픽이 크고 꾸준한 서비스

사용량 기반 요금이 계속 커지는 시점에는 고정 용량 인프라가 다시 유리해질 수 있다. 이때는 '서비스가 네 개라 복잡하다'가 아니라, 최근 몇 달의 명령 수·메시지 수·전송량·운영 시간을 근거로 손익분기점을 계산해야 한다.

내가 고른 현실적인 시작점

작은 프로젝트라면 처음부터 완성형 인프라를 사지 않는다.

앱과 DB만으로 시작한다.
여러 실행 인스턴스가 공유해야 할 짧은 상태가 생기면 Redis를 붙인다.
요청이 끝난 뒤 처리할 작업과 실패 재시도가 필요해지면 QStash를 붙인다.
무료 구간을 넘거나 상용 목적이 되면 0달러 가정을 버리고 유료 플랜으로 다시 계산한다.
매달 청구액과 운영에 쓴 시간을 함께 기록한다.

이 순서라면 서비스가 네 개라는 이유만으로 과잉 설계하지 않고, 단일 VM이 싸 보인다는 이유만으로 운영 책임을 숨기지도 않는다.

결론

개인 프로젝트에서는 Vercel·Supabase·Upstash 조합이 월 0달러로 시작할 수 있어 단일 VM보다 싸다. 작은 상용 서비스에서는 관리형 조합이 월 45달러부터라서, 월 12~24달러 VM보다 청구액이 높아질 수 있다.

그러나 그 차이는 단순한 브랜드 비용이 아니다. 배포, 백업, 패치, 복구, 확장에 대한 책임을 얼마나 직접 맡을지의 가격이다. 그리고 VPC 하나는 이 책임을 자동으로 없애 주지 않는다.

따라서 질문은 “서버가 하나인가, 서비스가 네 개인가?”보다 다음처럼 바꾸는 편이 정확하다.

월 17달러를 아끼기 위해 우리가 직접 맡게 되는 운영 업무는 무엇이며, 그 업무의 연간 비용은 204달러보다 작은가?

이 질문에 숫자로 답할 수 있을 때, 비로소 어느 쪽이 더 싼지 알 수 있다.