출시 전 Firebase 비용 줄이기

출시 전에는 피드, 검색 결과, 대시보드, 알림, 프로필처럼 자주 반복되는 화면을 먼저 적으세요. 각 화면에서 읽는 문서 수, 다운로드하는 파일, 실행되는 callable function, realtime listener로 생기는 새로고침을 함께 세어봅니다.

이 작업은 제공자를 바꾸는 것보다 빠르게 큰 개선점을 찾게 해줍니다. 게시글, 작성자, 카운터, 댓글을 각각 읽는 피드는 실제 트래픽이 오기 전에 더 저렴한 구조로 바꿀 수 있습니다.

목록 화면에는 authorName, thumbnailUrl, commentCount, likeCount, lastActivityAt, status처럼 바로 표시할 필드를 목록 문서에 저장하세요. 원본 데이터는 필요하면 별도로 유지하되, 한 줄을 그리기 위해 관련 문서를 여러 번 가져오는 구조는 피하는 것이 좋습니다.

페이지 크기도 의도적으로 제한하세요. 무한 스크롤, 검색 자동완성, 관리자 테이블은 한 명의 활발한 사용자가 정상 사용 중에도 수천 read를 만들지 않도록 한도를 가져야 합니다.

Storage 다운로드, Cloud Functions, 긴 보관 기간은 두 번째 비용 파도가 될 수 있습니다. 이미지는 업로드 전에 리사이즈하고, 공개 자산은 캐시하며, 임시 파일은 삭제하고, 로그나 export는 제품에 필요한 기간만 유지하세요.

점검 후에는 보수적인 트래픽과 낙관적인 트래픽을 모두 계산기에 넣어보세요. 그래도 Firestore read나 관계형 리포팅이 비용 대부분을 차지한다면 아키텍처를 확정하기 전에 Cloud Run + Cloud SQL과 비교하는 것이 좋습니다.