Firebase 비용 비교 2026, Spark·Blaze 선택과 Firestore 계산
Firebase 비용은 가입자 수 하나로 정해지지 않으며, 같은 화면이라도 문서 조회 수와 새로고침 방식에 따라 청구 구조가 달라집니다.
작은 앱을 빠르게 만드는 팀이라면 Spark로 실험할 범위와 Blaze로 넘어갈 조건을 먼저 나누고, Firestore의 읽기·쓰기·삭제를 따로 계산하는 편이 안전합니다.
이 글은 웹·모바일 앱의 백엔드 도입을 검토하는 담당자를 위한 판단표이며, 실제 운영 계정에서 성능이나 최종 청구액을 시험한 체험기는 아닙니다.
- Spark는 결제 수단 없이 시작하는 무상 요금제이고, Blaze는 사용량 기반 요금제입니다.
- Firestore Standard는 문서 작업뿐 아니라 인덱스 읽기·저장·네트워크 전송도 계산해야 합니다.
- 일별 무상 할당을 월간 총량에서 한 번 빼면 이용 패턴에 따라 계산이 틀어집니다.
- 예산 알림만으로 Firestore 사용이 자동 중단된다고 믿지 말고, 접근 규칙과 비상 조치 담당자를 정하세요.
Firebase 비용의 공식 핵심 숫자: Firestore Standard
아래 세 요율은 2026년 10월 19일 Google Cloud 공식 가격표에서 확인한 미국 Iowa, us-central1의 Firestore Standard 기본 사용량 단가입니다.
지역 선택값은 Iowa이며 약정 사용 할인 열이 아닌 Default 열을 기준으로 했으므로, 서울 리전이나 Enterprise 에디션의 단가로 옮겨 쓰면 안 됩니다.
| 문서 작업 | 실제 기본 단가·통화 | 무상 할당 | 적용 조건 |
|---|---|---|---|
| 읽기 | 0.03 USD / 문서 100,000건 | 하루 50,000건 | Iowa Standard, 무상 할당 초과 문서 읽기 |
| 쓰기 | 0.09 USD / 문서 100,000건 | 하루 20,000건 | Iowa Standard, 무상 할당 초과 문서 쓰기 |
| 삭제 | 0.01 USD / 문서 100,000건 | 하루 20,000건 | Iowa Standard, 일반 문서 삭제 기준 |
이 표는 전체 Firebase 사용료가 아니라 문서 작업 세 종류의 요율만 보여주며, 저장 데이터와 인덱스·네트워크·백업 등은 별도입니다.
프로젝트당 무상 할당을 받는 데이터베이스는 하나이며, 이름을 별도로 지정한 데이터베이스는 같은 무상 할당을 받지 않는다고 공식 문서가 설명합니다.
무상 할당은 태평양 시간 자정 무렵 일별로 초기화되므로, 한국 업무일 기준 자정이나 월말만 보고 잔여량을 판단하면 어긋날 수 있습니다.
미국 달러 외 통화로 결제한다면 해당 통화의 Cloud Platform SKU 가격을 확인하고, 환율·세금·결제 조건을 별도로 대조하세요.
한국 부가세가 포함된 원화 확정 견적이나 서울 리전 최저가를 뜻하는 표가 아니며, 지역은 가격보다 데이터 처리 위치와 응답 요구부터 정하는 것이 좋습니다.
근거는 Firestore Standard 공식 가격표이며, Firebase 전체 상품의 범위는 Firebase 요금제 표에서 따로 확인할 수 있습니다.
Spark와 Blaze 비교: 무료 시작과 운영 승인은 다른 결정입니다
이 글이 필요한 사람은 첫 백엔드를 고르는 소규모 개발팀, 앱의 갑작스러운 청구 증가를 설명해야 하는 운영자, 결제 계정 승인을 맡은 관리자입니다.
| 선택지 | 비용 구조 | 보안·운영 부담 | 선택 또는 보류 기준 |
|---|---|---|---|
| Spark | 무상 할당 안에서 시작 | 사용 한도와 제공 상품을 먼저 확인 | 학습·작은 검증에 적합, 운영 용량 보장으로 해석하지 않기 |
| Blaze | 상품별 실제 사용량에 따라 청구 | 청구 책임자·알림·사용량 관찰이 함께 필요 | 계측한 작업량과 지원 조건이 맞을 때 전환 |
| 자체 서버와 관계형 DB | 선택한 인프라·관리 방식에 따라 달라짐 | 서버 보안·업데이트·복구까지 팀 책임 | 복잡한 조인과 기존 운영 자산이 핵심이면 별도 비교 |
Spark를 먼저 고를 조건
로그인 화면과 간단한 데이터 구조를 검증하는 단계라면 결제 연결을 서두르지 말고, 실제로 필요한 상품이 Spark에서 제공되는지부터 확인하세요.
무상 요금제라는 이유로 고객 서비스의 무제한 운영을 약속하면 안 되며, 예상치 못한 사용량 증가에서 어떤 제한이 생기는지 출시 전에 검토해야 합니다.
Blaze를 검토할 조건
Blaze를 선택할 때는 프로젝트 하나에 등록된 여러 앱의 이용량이 같은 프로젝트 요금제에 묶인다는 점부터 팀에 공유하세요.
한 앱의 시험 기능이 다른 앱의 예산에도 영향을 줄 수 있으므로, 개발·검증·운영 환경의 프로젝트 분리와 결제 책임 범위를 같이 설계하는 편이 낫습니다.
자체 백엔드 비교를 생략하면 안 되는 조건
문서형 데이터 모델에 맞지 않는 관계 조회와 집계가 핵심이라면, Firebase의 빠른 초기 구현만 보고 전체 시스템을 옮기는 결정은 보류하세요.
직접 운영하는 서버가 항상 저렴하다는 뜻은 아니며, 서버 비용에 장애 대응·복구 훈련·권한 관리 시간을 더한 뒤 같은 기능 범위를 비교해야 합니다.
도입 전 프로젝트·지역·접근 규칙을 실제로 확인하는 순서
아래는 Firebase 공식 웹 시작 문서와 Firestore 빠른 시작을 바탕으로 한 콘솔 확인 순서이며, 운영 데이터가 없는 별도 검증 프로젝트에서 먼저 진행하세요.
- Firebase 콘솔에 조직이 승인한 Google 계정으로 로그인하고 프로젝트 생성 화면에서 프로젝트 이름과 연결 조직을 확인합니다.
- 프로젝트 개요의 Web 아이콘을 누르며, 앱이 이미 있으면 Add app에서 웹을 고른 뒤 앱 별칭을 입력하고 Register app으로 등록합니다.
- 왼쪽 Databases & Storage > Firestore로 이동해 Create database를 선택하고 Standard 에디션과 데이터 처리 지역을 확인합니다.
- 보안 규칙의 시작 모드는 Production mode를 선택한 뒤 Create를 누르고, 웹·모바일 접근이 기본 거부되는 상태를 출발점으로 삼습니다.
- 같은 Firestore 화면의 Rules 탭에서 규칙을 확인하고 Rules Playground를 열어 문서 경로 cost-check/sample에 인증 없는 get 요청을 선택하고 Run으로 거부 결과를 시험합니다.
- Settings > Usage and billing에서 프로젝트의 사용량과 요금제를 확인하고, 결제 연결 여부와 책임자를 문서로 남깁니다.
프로젝트 생성과 데이터베이스 생성이 허용되는 조직 권한이 전제이며, 버튼이 보이지 않으면 관리자에게 승인된 역할을 확인하고 권한을 임의로 넓히지 마세요.
웹 앱 등록에서 받는 구성 객체는 앱이 어느 프로젝트에 연결되는지를 정하는 값이며, 등록 완료가 곧 데이터 접근 허용을 뜻하지는 않습니다.
웹 SDK를 쓰는 기존 자바스크립트 프로젝트라면 공식 안내의 npm install firebase로 패키지를 설치하고 initializeApp 다음 getFirestore로 연결합니다.
이 글에서는 개발 환경 버전과 인증 방식을 정하지 않은 상태에서 데이터 쓰기 코드를 바로 실행하도록 권하지 않으며, 먼저 접근 거부가 의도대로 작동하는지 확인합니다.
Production mode의 웹·모바일 요청 거부는 오류가 아니라 안전한 초기 상태이므로, 연결을 확인하겠다고 모든 사용자에게 쓰기를 허용하지 마세요.
규칙 적용 확인과 되돌리기
아래 예시는 모든 웹·모바일 읽기와 쓰기를 거부하는 규칙이며, 실제 서비스에 적용하면 정상 사용자의 접근도 막힌다는 점을 먼저 확인하세요.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}Rules Playground는 편집기 안의 규칙을 대상으로 모의 요청을 평가하므로, Run에서 거부가 확인됐다고 배포된 규칙까지 바뀌었다고 판단하면 안 됩니다.
규칙을 실제 적용할 때는 Rules 탭에서 내용을 확인한 뒤 Publish를 누르고, 새 요청과 기존에 열려 있던 앱 화면을 구분해 다시 검사하세요.
공식 문서는 새 쿼리·리스너 반영에 최대 1분, 이미 활성화된 리스너의 완전 반영에 최대 10분이 걸릴 수 있다고 안내합니다.
운영 규칙을 바꾸기 전에는 이전 규칙을 버전 관리하고, 이상이 있으면 승인된 이전 내용을 편집기에 복원해 Publish한 뒤 재검증하세요.
긴급 차단용 거부 규칙은 서비스 중단을 동반하며, 데이터베이스 삭제나 결제 계정 해제를 일반적인 되돌리기 버튼처럼 사용해서는 안 됩니다.
읽기 횟수는 페이지 수가 아니라 반환 문서와 갱신으로 계산합니다
Firestore는 문서를 읽고 쓰고 지우는 작업에 과금하며, 쿼리를 처리하기 위해 읽는 인덱스 항목도 조건에 따라 비용이 생깁니다.
목록 화면을 한 번 열었다고 읽기가 한 건인 것은 아니며, 반환 문서 수와 쿼리의 인덱스 조건을 함께 봐야 사용량을 설명할 수 있습니다.
실시간 리스너는 결과에 문서가 추가되거나 갱신될 때 읽기 비용이 발생하므로, 한 번 접속한 사용자 수만으로 조회 예산을 잡으면 부족할 수 있습니다.
문서가 변경되어 결과에서 빠지는 경우에도 읽기 과금이 생길 수 있지만, 문서 자체가 삭제되는 경우와는 과금 설명이 다르므로 이벤트 종류를 분리하세요.
오프라인 지속성이 켜진 웹·모바일 리스너는 연결이 30분 넘게 끊겼다 다시 붙으면 새 쿼리처럼 문서와 인덱스 읽기가 청구될 수 있습니다.
오프라인 지속성을 끈 경우에는 연결이 끊겼다가 다시 연결될 때마다 새 쿼리처럼 청구될 수 있어, 재접속을 반복하는 화면부터 관찰하는 것이 좋습니다.
공식 가격표는 결과가 없는 쿼리에도 최소 문서 읽기 요금이 발생할 수 있음을 설명하므로, 빈 목록 조회를 비용이 없는 작업으로 세면 안 됩니다.
개발자는 화면별 쿼리 제한과 갱신 빈도를 기록하고, 운영자는 사용량 증가가 사용자 증가인지 잘못된 반복 조회인지 나눠 보는 것이 좋습니다.
Security Rules에서 다른 문서를 확인하는 접근 조건도 추가 읽기와 연결될 수 있으므로, 보안 규칙을 복잡하게 바꿀 때는 조회 비용 변화까지 검토하세요.
문서 작업 비용 계산 예시: 하루와 월간을 나눠 검산하기
다음은 Iowa의 기본 단가와 무상 할당 적용 대상 데이터베이스 하나를 가정한 계산 예시이며, 실제 고객 이용 기록이나 공급자의 견적이 아닙니다.
하루 읽기 1,000,000건, 쓰기 100,000건, 일반 삭제 50,000건이 모두 해당 문서 작업으로 집계된다고 가정합니다.
| 항목 | 하루 청구 대상 계산 | 단가 적용 | 문서 작업 비용 |
|---|---|---|---|
| 읽기 | 1,000,000 − 50,000 = 950,000건 | 950,000 ÷ 100,000 × 0.03 USD | 0.285 USD/일 |
| 쓰기 | 100,000 − 20,000 = 80,000건 | 80,000 ÷ 100,000 × 0.09 USD | 0.072 USD/일 |
| 삭제 | 50,000 − 20,000 = 30,000건 | 30,000 ÷ 100,000 × 0.01 USD | 0.003 USD/일 |
| 합계 | 세 문서 작업만 합산 | 같은 이용량이 30일 이어진 경우 | 0.36 USD/일, 10.80 USD/30일 |
10.80 USD는 이 가정의 문서 작업 소계일 뿐이며, 저장 데이터·인덱스 읽기·추가 규칙 읽기·네트워크·다른 상품 사용료를 포함한 월 총액이 아닙니다.
매일 사용량이 같지 않다면 하루씩 초과분을 계산한 뒤 합산해야 하며, 사용하지 않은 날의 무상 몫을 바쁜 날에 이월한 것처럼 빼면 안 됩니다.
행사 당일에 읽기가 몰리는 서비스와 매일 고르게 접속하는 서비스는 월 총 읽기 수가 같아도 청구 대상이 달라질 수 있습니다.
문서 용량이 커지고 인덱스가 늘면 저장량과 전송량도 달라지므로, 읽기 단가가 작아 보인다는 이유로 이미지 원본과 큰 파일을 문서에 몰아넣는 설계는 피하세요.
아래 검산 코드는 문서 작업 세 종류만 다루는 계산 도구이며, 클라우드에 접속하거나 실제 Firebase 프로젝트를 변경하지 않습니다.
from decimal import Decimal
def daily_document_cost(reads, writes, deletes):
if min(reads, writes, deletes) < 0:
raise ValueError("counts must be non-negative")
amounts = [
(max(reads - 50_000, 0), Decimal("0.03")),
(max(writes - 20_000, 0), Decimal("0.09")),
(max(deletes - 20_000, 0), Decimal("0.01")),
]
return sum(Decimal(count) / Decimal(100_000) * rate
for count, rate in amounts)
# Iowa Standard, free-quota-eligible database only
usage_days = [(1_000_000, 100_000, 50_000)] * 30
subtotal = sum(daily_document_cost(*day) for day in usage_days)
print(f"document operations only: USD {subtotal:.2f}")
# Expected: document operations only: USD 10.80실제 검산에서는 매일의 작업 수로 usage_days를 채우고, 인덱스·보안 규칙·저장·전송 항목을 이 코드 바깥의 별도 예산표에 더하세요.
실무 시나리오 1: 작은 예약 앱을 처음 만드는 팀
예약 목록과 사용자별 예약 내역을 검증하는 팀이라면, 먼저 Spark에서 지원 상품과 무상 범위를 확인하고 개인정보 없는 샘플로 데이터 모델을 점검하세요.
예약 화면마다 전체 컬렉션을 다시 읽는 대신 필요한 기간과 표시 건수를 정하는 편이 낫지만, 실제 쿼리 가능 여부와 인덱스 요구는 앱 코드로 검증해야 합니다.
일별 조회가 많지 않아도 잘못된 반복 요청이 있으면 예상량이 달라지므로, 버튼을 한 번 눌렀을 때 요청이 몇 번 발생하는지 개발 도구에서 확인하세요.
이 조건이면 결제 연결보다 먼저 화면별 읽기 수와 권한 테스트를 정리하고, 제품 기능상 Blaze가 필요한 시점에 청구 책임자와 전환을 검토하는 것이 합리적입니다.
주민등록번호나 실제 고객 연락처를 편의상 시험 문서에 넣지 말고, 검증 프로젝트가 운영 데이터의 복사본으로 바뀌지 않도록 입력 범위를 제한하세요.
프로젝트 이름만 개발용으로 정한다고 격리가 보장되는 것은 아니므로, 앱 구성 객체가 가리키는 프로젝트와 데이터베이스 위치를 함께 확인해야 합니다.
실무 시나리오 2: 운영 중인 실시간 대시보드의 청구가 늘어난 팀
사용자 수는 비슷한데 청구가 증가했다면 월간 활성 사용자부터 탓하지 말고, 리스너 수·문서 갱신 횟수·재접속 패턴을 시간대별로 비교하세요.
한 화면에서 여러 컴포넌트가 같은 목록을 따로 구독하거나, 화면 이동 때 이전 구독이 남으면 사용자 수보다 실제 읽기 수가 더 빠르게 늘 수 있습니다.
이 경우는 곧바로 다른 데이터베이스로 이전하기보다, 같은 데이터를 여러 번 받는 경로를 줄이고 결과 제한과 구독 해제 처리를 검토할 만합니다.
변경 전후의 데이터 접근 결과가 같은지 확인하지 않고 캐시만 늘리면 예약 상태나 재고처럼 최신성이 중요한 값이 뒤늦게 보일 수 있습니다.
운영자는 사용량 그래프와 청구 그래프의 기간을 맞춰 보고, 개발자는 특정 배포 이후 읽기 수가 뛰었는지 비교해야 원인에 가까워집니다.
실제 쿼리 구조를 보지 않은 상태에서는 예상 절감률을 약속할 수 없으며, 최적화 후보 하나씩 적용하고 사용량과 화면 정확성을 같이 측정하세요.
보안·운영 체크리스트: 알림과 접근 차단을 혼동하지 마세요
Firebase 공식 비용 관리 문서는 일반 예산 알림이 서비스를 일시 중지하지 않는다고 설명하므로, 알림 이메일을 받는 것과 실제 차단 절차를 분리하세요.
일부 Firebase 상품에는 별도 지출 상한 예산이 있지만, 확인한 공식 문서의 지원 목록에는 Firestore가 없으므로 같은 기능이 적용된다고 가정하면 안 됩니다.
현재 안내의 지출 상한 지원 상품은 Firestore와 별개의 서비스들이며, 문서 조회 비용은 프로젝트 예산과 사용량 관찰·앱 측 제어를 함께 설계해야 합니다.
모바일·웹 SDK는 Security Rules를 평가하지만 서버 클라이언트 라이브러리는 이를 우회하고 별도 인증·IAM으로 접근하므로, 한쪽만 막았다고 전체 접근이 차단된 것은 아닙니다.
키를 숨기는 방법만 찾기보다 데이터 경로별 소유자와 요청 권한을 검증하고, 서버 관리자 권한이 클라이언트 코드로 넘어가지 않도록 경계를 지키세요.
거부 규칙을 긴급 적용하는 조치는 정상 사용자의 읽기까지 막을 수 있으므로, 장애 공지와 복구 승인자를 정한 뒤 실제 요청으로 영향 범위를 확인해야 합니다.
- 청구: 누가 예산 알림을 받고 근무 외 시간에는 누가 확인하는지 정합니다.
- 쿼리: 결과 제한, 중복 구독, 화면 종료 시 구독 해제, 재연결을 점검합니다.
- 권한: 인증 없는 요청과 다른 사용자의 데이터 요청을 각각 시험합니다.
- 서버: 관리용 접근과 앱 사용자의 접근을 구분하고 IAM 변경 이력을 확인합니다.
- 환경: 개발 프로젝트가 운영 데이터베이스에 연결되지 않는지 구성 값을 대조합니다.
- 복구: 규칙 원본과 데이터 복구 절차를 보관하고 복원 가능 여부를 검증합니다.
- 비용표: 문서 작업 외 저장·전송·인덱스와 다른 유료 상품을 별도 항목으로 남깁니다.
검토 회의에서 서비스가 싸다는 한 문장으로 끝내지 말고, 어떤 데이터와 어떤 접속 패턴에서 얼마가 달라지는지 설명할 수 있을 때 운영 전환을 승인하세요.
Firebase 도입을 잠시 보류할 신호
아직 사용자별 데이터 접근 범위를 설명하지 못하거나, 모든 요청을 허용해야만 시연이 된다면 요금제보다 권한 설계부터 다시 보는 것이 맞습니다.
다른 프로젝트의 무상 할당을 합치거나 약정 할인 단가를 기본 단가로 사용한 예산이라면, 운영 승인 전에 같은 지역·에디션·소비 모델로 다시 계산하세요.
월간 집계만 있고 특정 하루의 급증을 설명하지 못하면 과금 원인을 놓치기 쉬우므로, 서비스의 업무 주기와 일별 측정값부터 연결하세요.
데이터 처리 위치가 조직의 요구에 맞는지 확인되지 않았다면 가격이 낮은 리전을 먼저 선택하지 말고, 보안·법무 담당자의 검토를 거친 뒤 생성 위치를 정하세요.
Firestore로 관계형 시스템의 모든 조회를 그대로 옮기겠다는 계획도 재검토 대상이며, 핵심 화면의 조회 모델과 필요한 일관성·복구 요구를 먼저 비교해야 합니다.
반대로 단순한 문서 접근과 실시간 동기화가 제품의 중심이고 운영 책임을 정할 수 있다면, 작은 검증 범위에서 작업량을 측정한 뒤 확대하는 방식을 검토할 만합니다.
Firebase 비용 비교 자주 묻는 질문
Firebase는 사용자 수가 적으면 항상 무료인가요?
사용자 수 자체가 아니라 상품별 이용량과 요금제·기능 조건을 봐야 하며, 작은 사용자 집단도 반복 조회나 큰 전송량을 만들면 무상 범위를 넘을 수 있습니다.
Blaze로 바꾸면 모든 상품이 즉시 유료가 되나요?
Blaze는 상품별 사용량 과금 구조이며 무상 범위가 남는 상품도 있으므로, 결제 연결 여부와 개별 상품의 유료 조건을 따로 확인해야 합니다.
표의 0.03 USD를 서울 리전에도 적용해도 되나요?
아니며, 표는 Iowa의 Firestore Standard 기본 단가이므로 실제 데이터베이스 지역·에디션·통화에 맞는 공식 가격표를 다시 확인해야 합니다.
하루 무상 읽기를 월말에 한 번 빼면 안 되나요?
일별로 초기화되는 할당이므로 하루마다 초과량을 구한 뒤 합산해야 하며, 이용하지 않은 날의 몫을 다른 날에 이월한 것처럼 계산하면 안 됩니다.
예산 알림을 켜면 Firestore 청구가 자동으로 멈추나요?
일반 예산 알림은 서비스를 멈추지 않고 확인한 지출 상한 지원 목록에도 Firestore가 없으므로, 알림을 자동 차단 장치로 간주하면 안 됩니다.
Rules Playground에서 성공하면 실제 데이터도 저장됐나요?
모의 요청은 편집기의 규칙을 시험하는 기능이므로 실제 데이터 저장이나 배포 상태를 뜻하지 않으며, 적용 후에는 실제 앱 요청을 별도로 검증해야 합니다.
함께 보면 좋은 글
안드로이드스튜디오 설치 2026, 첫 앱 실행과 테스트 비용
데이터 플랫폼 구축 StackRender 데이터베이스 스키마 설계 2026, 도입 전 비교할 성능·비용 기준
클라우드 비용 최적화 실전 이커머스 재고 관리 2026, SKU·캐시·큐 비용 줄이는 기준
PlanetScale 백업 복원 2026, Postgres 데이터 플랫폼 복구·비용 기준
공식 출처와 확인일
- Firebase 공식 요금제 · 확인일 2026-10-19
- Firestore Standard 공식 가격표 · 확인일 2026-10-19
- Firebase 웹 앱 등록과 SDK 설치 · 확인일 2026-10-19
- Firestore Standard 빠른 시작 · 확인일 2026-10-19
- Firestore Security Rules 시작·시험·배포 · 확인일 2026-10-19
- Firebase 예상하지 못한 청구 방지 · 확인일 2026-10-19
가격·무상 범위·콘솔 메뉴·지원 기능은 바뀔 수 있으며, 계약과 실제 도입 전에는 사용 지역·결제 통화·조직 정책에 맞는 공식 문서를 다시 확인하세요.
이 글의 비용 계산과 조건부 판단은 일반 정보이며, 개별 서비스의 최종 비용·보안·법률 판단은 실제 사용량과 전문가 검토를 바탕으로 내려야 합니다.
댓글
댓글 쓰기