Firebase

Firebase helps you build and run successful apps

— 구글 I/O 등 공식 키노트에서 세상을 구원할 구원투수인 것처럼 외쳐대는 메인 캐치프레이즈.

백엔드 개발자 필요 없다더니, 백엔드 고칠 때마다 오열하며 구글에 통장을 바치는 악마의 서비스. 결제 한도 알림만 믿고 무한 루프 쿼리 돌렸다가 하룻밤 사이에 대기업 연봉 날아가는 상상함1

1. 개요

구글이 서비스 중인 모바일 및 웹 애플리케이션 개발 플랫폼. 개발자가 직접 서버 인프라를 구축하고 리눅스 포트를 열며 엔진엑스를 주무르는 고통스러운 과정을 생략하게 해 주는 BaaS(Backend as a Service)의 끝판왕이다. 실시간으로 데이터를 동기화해 주는 실시간 데이터베이스(Realtime Database)와 후속작 격인 클라우드 파이어스토어(Cloud Firestore)라는 강력한 NoSQL 라인업을 앞세워 폭발적인 인기를 끌었다. 특히 모바일 앱 개발 진영인 플러터나 리액트 네이티브 생태계에서는 거의 반필수적인 공용 유틸리티 취급을 받고 있다. 다만 공짜 점심은 없다는 우주의 진리답게, 서비스 규모가 조금만 커져도 괴랄한 쿼리 구조와 숨 쉬듯 청구되는 과금 압박 때문에 개발자를 깊은 고뇌에 빠지게 만든다.(...)

2. 초기 생산성의 악마: 날먹의 시작

자바스크립트나 코틀린, 스위프트 코드 단 몇 줄만으로 사용자 로그인 인증(Auth)을 처리하고, 실시간으로 채팅 데이터를 밀어 넣어주는 경험은 가히 혁명적이다. 프론트엔드 개발자나 기획자 혼자서 해커톤에 나가 서비스를 완성하는 빌드가 가능해진 것도 이 파이어베이스 덕분이다. AWS에서 IAM 권한 부여하고 EC2 인스턴스 띄우느라 사투를 벌일 시간에 파이어베이스는 firebase.initializeApp() 선언 한 줄로 백엔드 인프라 세팅을 끝내버린다. 이 압도적인 초기 생산성이야말로 수많은 스타트업과 개인 개발자들이 파이어베이스라는 악마의 덫에 발을 들이게 만드는 가장 큰 요인이다.

3. 성장기의 벽: SQL의 그리움과 불친절한 쿼리

서비스가 성장해 나가면서 복잡한 비즈니스 로직이 추가되는 순간, 아름다웠던 허니문은 끝나고 지옥문이 열린다. 관계형 데이터베이스인 RDBMS에 익숙한 개발자가 파이어베이스의 문서형 DB인 파이어스토어를 만지다 보면 '이게 왜 안 됨?'을 하루에 수십 번씩 외치게 된다. 테이블 간의 JOIN은 당연히 존재하지 않으며, 여러 필드에 걸쳐 다중 범위 쿼리를 날리는 지극히 상식적인 기능조차 복합 색인(Index)을 일일이 생성해 주지 않으면 에러를 뿜어낸다. 결국 똑같은 데이터를 여러 문서에 중복 저장해 가며 꾸역꾸역 동작하게 만드는 역정규화(Denormalization) 노가다를 강요받게 되며, 이 시점부터 개발자들은 서서히 PostgreSQL이나 MySQL의 품이 그리워 울부짖기 시작한다.(...)2

4. 과금 구조: 읽는 것도 돈이요, 쓰는 것도 돈이라

가장 큰 문제는 과금 모델이다. 무료 등급인 Spark 요금제를 벗어나 종량제인 Blaze 요금제로 넘어가는 순간부터 문서 읽기, 쓰기, 삭제 횟수가 고스란히 달러화로 치환되어 청구된다. RDBMS처럼 단순히 디스크 용량이나 CPU 사용량으로 돈을 내는 게 아니라 데이터 전송 건수 하나하나가 과금 대상이다 보니, 최적화가 안 된 프론트엔드 코드가 메인 페이지를 켤 때마다 수천 개의 문서를 읽어 들이도록 설계되어 있다면 그야말로 트래픽 대참사가 벌어진다. 이 과금 지옥을 피하기 위해 클라이언트 사이드에서 캐싱 처리를 이중삼중으로 하느라 뇌가 녹아내리는 경험을 선사한다.

5. 관련 밈 및 드립

5.1. Firebase Bill Jumpscare (파이어베이스 파산 짤)

파이어베이스를 쓰는 주니어 개발자들의 연례행사 같은 드립. React의 useEffect 훅이나 컴포넌트 라이프사이클 함수 내부에 탈출 조건 없는 무한 재귀 형태의 firestore.get() 조회를 심어놨다가, 테스트 도중 하룻밤 사이에 수천만 번의 읽기 쿼리가 전송되면서 다음 날 아침 구글로부터 수만 달러 규모의 청구서를 받아 들고 사시나무 떨듯 떠는 밈이다. 레딧이나 스택 오버플로우에는 실제로 '무한 루프 실수로 60,000달러가 청구되었는데 어떻게 해야 하나요?' 같은 눈물 없이는 볼 수 없는 구걸 글이 주기적으로 올라오며, 구글 고객센터가 평생에 단 한 번만 해주는 '처음이자 마지막 면제' 자비를 얻어내기 위해 비는 꿀팁 전수가 개념글로 가곤 한다.(...)

5.2. 서버리스(Serverless)가 아니라 브레인리스(Brainless)

백엔드를 따로 두지 않고 오직 프론트엔드와 파이어베이스 SDK의 결합만으로 서비스를 개발하다가, 비즈니스 로직이 극도로 꼬여버린 상태를 풍자하는 밈이다. 원래 서버 안에서 든든하게 처리했어야 할 가공 및 보안 필터링 로직을 프론트엔드 자바스크립트의 .map(), .filter(), .reduce() 떡칠로 우겨넣어 브라우저가 비명을 지르게 만드는 현상을 꼬집는다. 보안 규칙(Security Rules) 설정을 짤 줄 몰라서 전체 DB의 읽기/쓰기 권한을 allow read, write: if true;로 열어두었다가 해커들에게 데이터베이스 전체를 털리는 엔딩이 백미다. 결국 프론트엔드 개발자의 뇌가 리스(Less) 상태가 된다.

6. 여담

  • 이름의 유래: 2011년 당시 실시간 채팅 API 서비스인 'Envolve'를 서비스하던 중, 개발자들이 채팅 기능은 안 쓰고 실시간으로 게임 데이터 등을 동기화하는 용도로 API를 남용하는 것을 보고 영감을 얻어 2012년 'Firebase'라는 이름의 백엔드 서비스로 피벗을 단행했다.
  • 구글의 모바일 허브: 2014년 구글에 전격 인수된 이후, 구글 산하의 각종 개발자 도구(AdMob, Google Analytics, FCM 등)가 모조리 파이어베이스 콘솔 내부로 뚱뚱하게 이식되었다. 덕분에 현재는 단순 BaaS를 넘어 모바일 앱 비즈니스 분석 전체를 아우르는 통합 플랫폼이 되었다.
  • 콜드 스타트의 공포: 백엔드 함수를 서버리스 형태로 실행시키는 Cloud Functions for Firebase는 가벼운 마음으로 입문했다가 무시무시한 콜드 스타트(Cold Start) 문제를 마주하게 된다. 오랫동안 호출이 없다가 첫 접속이 이뤄지면 도커 컨테이너가 새로 예열될 때까지 수 초 동안 API 응답이 멈추는 버벅임 현상이 나타난다.3

7. 관련 문서

각주

  1. 실제로 Firebase 콘솔에서 예산 경고 설정을 해둘 순 있으나, 이는 단순히 메일로 알려줄 뿐 결제를 강제로 차단하여 서비스를 즉시 중단해 주는 직관적인 안전장치를 제공하지 않기 때문에 방심하다 훅 가는 경우가 매우 흔하다. ↩

  2. 사실 관계형 쿼리 스타일의 정교한 데이터 관리가 필요해진 시점이라면 Supabase나 Nhost 같은 오픈소스 RDBMS 기반 BaaS 대체재로 도망치는 것이 업계 표준 수순으로 꼽힌다. ↩

  3. 이를 방지하기 위해 유료 요금제에서 최소 활성 인스턴스(Minimum Instances) 개수를 1개 이상으로 고정해 두면, 아무도 내 앱을 쓰지 않아도 매달 고정 비용이 따박따박 통장에서 빠져나가는 마법을 체험할 수 있다. ↩

이 문서를 가리키는 문서