Firebase Hosting과 Cloud Run 비용 비교

Firebase Hosting은 정적 사이트, SPA, 마케팅 페이지, 문서, 캐시 가능한 asset에 좋은 기본 선택지입니다. 핵심 비용 요인은 저장량과 외부 전송량입니다. Cloud Run은 요청마다 서버 렌더링, 커스텀 API, 인증 확인, DB 작업, AI 호출, 웹훅 처리가 필요한 경우에 비교해야 합니다.

현실적인 추정을 하려면 트래픽을 정적 asset 조회, 동적 페이지 요청, API 호출, 파일 다운로드로 나누세요. 공개 shell은 Firebase Hosting에 두고 동적 경로만 Cloud Run으로 보내는 구성도 가능하므로, 가장 저렴한 답은 단일 제품이 아니라 혼합 구조인 경우가 많습니다.

Hosting과 CDN 동작은 프레임워크 선택보다 비용 흐름을 더 크게 바꿀 수 있습니다. 버전이 붙은 JavaScript, CSS, 이미지, font에는 긴 cache header를 두면 반복 전송을 줄일 수 있습니다. HTML이나 자주 바뀌는 페이지는 짧은 캐시가 필요할 수 있지만, 기본 배포값을 그대로 두기보다 의도적으로 정해야 합니다.

Cloud Run 비용은 요청 수, 할당 CPU와 메모리, 응답 시간, 동시성, warm 상태로 유지하는 최소 인스턴스에 따라 커집니다. 페이지를 미리 렌더링하거나 edge에서 캐시할 수 있다면 방문마다 컨테이너 비용을 내지 않도록 하세요. 모든 요청에 개인화된 백엔드 로직이 필요하다면 정적 hosting 전송량과 Cloud Run을 따로 추정하세요.

제품이 대부분 정적이고 asset 다운로드가 예측 가능하며 SSL과 커스텀 도메인을 빠르게 붙이는 것이 중요하면 Firebase Hosting으로 시작하기 좋습니다. hosting 계층이 사실상 애플리케이션 서버라면, 예를 들어 SSR, API, 이미지 생성, 결제 callback, AI workflow, 백엔드 orchestration이 중심이라면 Cloud Run을 검토하세요.

출시 전에는 계산기에 두 가지 시나리오를 넣어보세요. 정상적인 실제 사용자 트래픽과, 봇, 재시도, 소셜 공유, 캠페인으로 생기는 spike case입니다. 외부 전송량 GB, Cloud Run 요청 시간, DB read, 파일 다운로드, 최소 인스턴스 시간 중 무엇이 먼저 움직이는지 보면 구조 선택이 더 분명해집니다.