MAU기반 서버 비용 추정

서비스를 바닥부터 구축하는 업무를 진행중입니다.
관련하여 FE관점에서 MAU에 따른 개략적 서버비용을 판단한 경험을 공유하겠습니다.

해당 아티클을 읽으시면 아래와 같은 지식을 얻을 수 있습니다.

• MAU기반으로 트래픽 모델링 해보기
• 트래픽 기반으로 서버 비용 추정하기

---

1. 전제 & 목표

• 규모 가정: MAU 2000,
• 핵심 기능: 예약 목록/정렬&필터, 결제, 검색, 지도, 공유하기(og) 등
• 품질 목표(SLO)
  • LCP P75 < 2.5s, INP: p75 < 200, CLS: P75 < 0.1, TTFB P75 < 300ms,
  • SSR 실패 시 CSR 폴백 < 1%

---

2. 트래픽 모델링

트래픽 모델링은 비슷한 경쟁업체의 MAU나 사업 구상 시 예상한 MAU를 파악하면 개략적인 파악이 가능합니다.
MAU 2000이라는 가정 하에 저희가 주의깊게 보아야 하는 수치는 DAU/MAU, Concurrent Users, TPS, QPS 입니다.

2.1 중요 지표

2.1.1 MAU/DAU

정의: 특정 앱이나 서비스에 활동한 순 사용자 수를 의미합니다.
계산: MAU가 2000이면 DAU는 MAU * 0.4(40%로 추정 시) = 800 으로 추정됩니다.

• MAU 2000, DAU 800

2.1.2 Concurrent Users

정의: 특정 시점에 활동 중(ex 5분 내 이벤트 1회 이상)인 고유 세션 수
가정: DAU 800, 피크 시점엔 DAU의 5%가 동시에 활동
계산: DAU peak_concurrency_ratio = 800 0.05 = 40명

• Concurrent Users = 40

2.1.3 Pageviews · Backend Calls · QPS/TPS

정의

• QPS (Queries Per Second): 초당 요청 수(읽기/조회 중심). 1 페이지 로딩에서 n개의 백엔드 호출이 나가면 그만큼 QPS를 유발.
• TPS (Transactions Per Second): 초당 쓰기/변경 트랜잭션 수(예약/결제/작성 등).

가정

• 일일 1인 평균 페이지 뷰: pages_per_user = 20
• 페이지당 API 호출 수: backend_calls_per_page = 1.5
• 피크 계수: peak_factor = 5
• 쓰기 사용자 비율: write_user_ratio = 10%
• 쓰기 사용자 당 쓰기 횟수: writes_per_writer= 2
• seconds_per_day: 86400

계산 결과

• Pageviews/day = DAU × pages_per_user = 16,000 PV/일

• BackendCalls/day = Pageviews/day × backend_calls_per_page = 16,000 × 1.5 = 24,000 calls/일

• avg_QPS = (BackendCalls/day)/seconds_per_day = 0.278 QPS

• peak_QPS = avg_QPS _peak_factor = 1.39 QPS

• Writes/day = DAU_ 0.1 * 2 = 160 writes/일

• avg_TPS = (Writes/day)/seconds_per_day ≈ 0.00185 TPS

• peak_TPS = avg_TPS * peak_factor ≈ 0.00926 TPS

이제 서버 사용량을 추정할 수 있는 지표들을 얻게 되었습니다.
위 데이터를 기반으로 개략적인 서버 사용량을 추정해보겠습니다.

---

3. 서버 사용량 추정

위에서 도출한 지표(DAU, QPS/TPS, PV 등)를 바탕으로, 실제로 얼마만큼의 컴퓨트(Compute), 네트워크(Network), 스토리지(Storage) 자원이 필요한지 단계별로 계산 해 보겠습니다.

3.1 네트워크 대역폭

SSR HTML per day
Pageviews/day가 16,000회로 추정되었고, 이의 평균크기를 50KB로 잡으면 계산식은 아래와 같습니다.

• SSR HTML = 16,000 * 50 KB = 800,000 KB = 800 MB/day

API per day
BackendCalls/day가 24,000으로 추정되었고, 이의 평균 크기를 10KB(압축)로 가정 계산식은 아래와 같습니다.

• API = 24,000 * 10 KB = 240,000 KB = 240 MB/day

월간 환산
이 둘의 합산은 30일 기준으로 다음과 같습니다.

• 30일 기준: 1.04 GB * 30 = 31.2 GB / monthly

이는 버셀의 team/pro플랜의 기본 제공량인 1TB 대비 매우 작으며, EC2 egress로 잡아도 몇 달러 미만 급입니다.

vercel Monthly credit

3.2 SSR 계산(Compute) - CPU 시간 & GB-시간

SSR은 캐시에 미스(hit되지 않을) 때만 CPU가 사용됩니다.
따라서 ISR 히트율에 따라 월간 SSR 렌더 횟수와 CPU 리소스 사용량이 결정됩니다.

• PV_month = 16,000 × 30 = 480,000
• SSR_renders_per_month = PV_month × (1 − h)
• cpu_time_per_render = 0.1초(=100ms)
• cpu_hours_per_month = SSR_renders_per_month × cpu_time_per_render / 3600
• GB_hours_per_month = cpu_hours_per_month × memory(GB)

예를 들어, h=0.9, memory=1GB인 경우
→ SSR_renders_per_month = 48,000,
→ cpu_hours_per_month = 48,000 × 0.1 / 3600 = 1.33시간,
→ GB_hours_per_month = 1.33 GB-hr 로 계산됩니다.

이제 히트율을 각 0.4, 0.7, 0.9로 가정하여 CPU시간 및 GB-시간을 예상해 보겠습니다.

히트율 h	SSR 렌더/월	CPU 시간/월	GB-시간(메모리 512MB 가정)
0.9	48,000	~1.33h	~0.68 GB-h
0.7	144,000	~4.00h	~2.05 GB-h
0.4	288,000	~8.00h	~4.10 GB-h

이제 해당 지표들을 가지고 비용 산정을 진행해 보겠습니다.

3.3 비용 산정 예시

3.3.1 서버리스 기준(vercel 가정)

vercel기준 compute과금은 "Active CPU(시간) + Provisioned Memory(GB-시간)"으로 계산되며 서울(icn1)기준으로는 CPU는 $0.169/시간, 메모리는 $0.014/GB-시간 으로 명시되어 있습니다.

vercel regional-pricing

히트율 h	CPU 시간	CPU 비용	메모리 GB-h	메모리 비용	월 합계
0.9	1.33h	$1.33×0.169 = $0.225	0.68	0.68×0.014 = $0.0095	≈ $0.23
0.7	4.00h	4.00×0.169 = $0.676	2.05	2.05×0.014 = $0.0287	≈ $0.70
0.4	8.00h	8.00×0.169 = $1.352	4.10	4.10×0.014 = $0.0574	≈ $1.41

결과는 월 $0.23 ~ $1.41 수준이며 team 플랜의 월 $20크레딧 안에서 여유롭습니다.

비용산정

vercel team 계정 시 시트당 $20

• compute: $0.23 ~ $1.41 < $20(기본 제공)
• data transfer: 31.2 GB < 1TB(기본제공)

달 $20로 운영 가능

3.3.2 IaaS VM 기준

CPU(vCPU 2코어)

• 피크 요청량(SSR 대상)

  • PV_day = 16,000, peak_factor = ×5 → peak_RPS ≈ 0.926
  • ISR 히트율 h=0.7 가정 → 피크 SSR RPS = 0.926 × (1−0.7) = 0.278

• 평균 SSR 실행시간: t = 0.1 s (100ms, p75 기준 가정)

• 필요 코어(러프)

  필요 vCPU ≈ (피크 SSR RPS × t) / 목표 코어 활용률
            = (0.278 × 0.1) / 0.6
            ≈ 0.046 vCPU

  → 이론상 0.05코어만으로도 커버 가능.
  → 콜드스타트/GC/다운스트림 대기/스파이크 버퍼를 고려하여 vCPU 2코어 배정(여유 40× 이상).
  → HA를 위해 2대 구성(2 vCPU × 2대).

메모리 (4GB)

• 런타임/프레임워크/SSR 템플릿: ~300–600MB
• 동시 fetch 버퍼/JSON 파싱/압축: ~200–500MB
• 코드·모듈·JIT·캐시: ~300–800MB
• 로그/메트릭 버퍼, TLS, 일시 스파이크: ~300–600MB
  → 합 1.5–2.5GB 예상 → p95·GC 여유 고려 4GB 권장.

디스크 (40GB)

• OS/런타임/빌드 산출물: 8–12GB
• 릴리즈 2~3개 보관(롤백): 5–10GB
• 로컬 로그 버퍼: 2–5GB
• 코어덤프/여유: 5–10GB
  → 합 25–35GB → 마진 포함 40GB.

네트워크 참고

• 대역폭(HTML+API, 압축 후): ~31.2GB/월

필요한 vm

위치	수량	cpu (core)	memory (GB)	disk (GB)
KIDC	2대	2	4	40

이외에도 LB, 캐시, 오토스케일, 모니터링, 로드벨런서 등을 위한 추가 vm이나 관리가 필요합니다

3.4 최종 산정

위 추정금액 및 필요한 리소스에 의거하여, 예시로 든 MAU 2000정도의 서비스는 Vercel로 배포하는게 비용과 성능 측면에서 효율적인걸 확인할 수 있었습니다.

---

마무리

전달받은 MAU를 기반으로 트래픽 모델링을 측정하고, 서버 자원을 추정하는 아티클을 작성해 보았습니다.
해당 글이 조금이나마 도움이 되셨기를 바라며, 읽어주셔서 감사합니다.

References

• 모르면 승진 안되는 시스템 디자인
• https://vercel.com/docs/plans/pro-plan