요금이 갑자기 튄 상황
Firebase는 사용량만큼 과금되기 때문에, 코드 한 줄이 잘못되면 요금이 몇 배로 튈 수 있습니다. 전형적으로는 ‘목록 화면을 열 때마다 전체 컬렉션을 다시 읽음’, ‘실시간 리스너가 떼어지지 않고 계속 붙어 있음’, ‘원본 이미지를 썸네일 없이 매번 내려받음’ 같은 패턴입니다. 수치를 과장하지 않고, 우리가 실제로 자사 앱(RideTalk 등 Firebase 기반)에서 겪고 다뤄 온 유형을 정리합니다.
어디서 새는지 추적
읽기(reads) 횟수 줄이기
가장 큰 절감은 보통 ‘읽기’에서 나옵니다. 접근은 단순합니다.
- 전체 로드 → 페이지네이션: 목록을 통째로 읽지 말고 필요한 만큼만(limit + 커서).
- 실시간 리스너 정리: 화면을 떠날 때 리스너를 반드시 해제. 안 떼면 백그라운드에서 계속 과금.
- 캐시 활용: 자주 안 바뀌는 데이터는 로컬 캐시/오프라인 지속성으로 재읽기 방지.
- 집계 분리: 카운트·합계는 매번 전부 읽어 계산하지 말고 집계 필드로 유지.
Storage·Functions 줄이기
Before — 비용이 새는 구조
- 원본 고해상도 이미지를 목록에서도 그대로 로드
- 클라이언트가 호출할 때마다 무거운 함수 실행
- 로그·임시 파일이 Storage에 계속 쌓임
After — 줄인 구조
- 썸네일 생성·CDN 캐시로 목록은 가벼운 이미지만
- 함수는 꼭 필요한 트리거만, 결과는 캐시·집계
- 수명 규칙(Lifecycle)으로 오래된 파일 자동 정리
예산 알림·상한 걸기
구조를 고쳤어도 다시 샐 수 있으니 감시 장치를 둡니다. 이것이 요금 폭탄을 ‘사고’에서 ‘알림’으로 바꿔 줍니다.
줄인 뒤 운영
한 번 줄였다고 끝이 아닙니다. 기능이 늘면 사용량도 늘기 때문에, 월 1회 사용량 점검을 루틴으로 두는 편이 안전합니다. 방치된 앱이라면 먼저 방치된 앱 서버비 줄이기로 전체 그림을 잡은 뒤 항목별로 손대는 걸 권합니다.
자주 묻는 질문
Firebase 요금은 보통 어디서 가장 많이 새나요?
대부분 ‘읽기(reads)’입니다. 목록을 통째로 다시 읽거나 실시간 리스너를 떼지 않아 백그라운드에서 계속 읽는 경우가 가장 큽니다. 그다음이 큰 이미지 반복 다운로드와 비효율 함수 호출입니다.
얼마나 줄일 수 있나요?
구조에 따라 크게 다릅니다. 읽기 패턴만 바로잡아도 눈에 띄게 내려가는 경우가 많지만, 정확한 폭은 측정해 봐야 알 수 있어 구체 금액을 미리 약속하지는 않습니다.
코드를 크게 고쳐야 하나요?
꼭 그렇진 않습니다. 페이지네이션·리스너 해제·썸네일·예산 알림 같은 ‘자주 새는 지점’부터 손대면 큰 수정 없이도 효과를 봅니다. 전면 개편은 그다음입니다.
보안 규칙이 요금과도 관계있나요?
있습니다. 규칙이 열려 있으면 외부에서 임의로 읽고 쓰는 호출까지 과금될 수 있습니다. 비용 절감과 함께 보안 규칙 점검을 같이 하는 이유입니다.
무료 점검부터 시작하세요
Firebase 콘솔의 최근 사용량(reads·Storage·Functions)만 공유해 주시면, 어디서 새는지 먼저 짚고 줄일 수 있는 지점을 정리해 드립니다.
문의: appmonster.kr@gmail.com
함께 보기: 방치된 앱 서버비 줄이기 · Firebase 보안 규칙 점검 · Firebase 보안 규칙 실수 TOP 5 · 앱 서버·DB 백업