본 글은 Crisp Chat의 Reasons Not To Use Firebase 를 일부 인용하며 제가 겪었던 이야기를 풀어서 작성하였습니다.

0. 배경설명

때는 2021년 7월 정도의 일이었습니다.
당시에 뚝섬에 있는 스타트업의 서비스팀에 인턴으로 합류하게 되었습니다.

어느 스타트업에서나 그렇듯 개발자는 부족했고 빠른 제품을 만들어야 했기 때문에 백엔드 개발자 없이 firebase를 사내 백엔드로 사용하였습니다.

하지만 회사의 MAU가 약 20000에 도달하고 서비스가 확장해가며 firebase의 여러 문제들에 직면하게 되었습니다.

때마침 서비스팀에 백엔드 개발자 분들이 추가로 합류하게 되며 2021년 9월 부터 12월 까지 firebase제거 작업에 들어가게 되었습니다.

1. what is firebase

Firebase는 사용자의 사랑을 받는 앱과 게임을 빌드하고 성장시키는 데 도움이 되는 앱 개발 플랫폼입니다. 이 플랫폼은 Google이 지원하며 전 세계 수백만 개 회사에서 신뢰를 받고 있습니다. - firebase 공식설명

공식설명에서 설명하듯, Google에서 기술적으로 지원을 하며 기존의 개발자들이 하나의 어플리케이션을 개발함에 있어서 고려해야할 수많은 사항들에 있어서 도움을 주는 서비스 입니다.

예를 들어 내가 모바일 앱을 만든다고 가정할때, app 개발 뿐 아니라 인증, 데이터베이스, api, console, analitics 등등의 수많은 요소들을 고려해야합니다.

하지만 빠르게 MVP(Minimum Viable Product)를 만들어 내고 유저들을 확보해야하는 초기 스타트업이나 팀들에게는 이런 모든 요소를 충족시키면서 개발하기에는 어려움이 있습니다. (시간, 인력, 자본 등등)

하지만 해당 firebase를 사용하면 해당 문제들을 획기적으로 (어느정도) 해결할 수 있습니다.

FireBase는 백엔드 기능을 클라우드 서비스 형태로 제공하기 때문에 서버리스 애플리케이션 개발이 가능하며 이 밖에도 수많은 기능들을 지원하기 때문에 결국 백엔드 개발자의 역할을 다소 간소화 되어 서비스를 개발할 수 있습니다.

그러면 Firebase의 장점을 먼저 설명해 보겠습니다.

2. Pros

0) 서버개발 시간에 대한 극단적인 단축

위의 사진에서 확인에서 확인 할 수 있듯 서버 개발에 있는 모든 비용이 극단적으로 단축이 됩니다. 해당 말풍선에 있는 기능들의 구현에 있어서 firebase가 지원을 해주기 때문입니다.(과연...)

1) 비교적 간단하게 구현이 가능하다.

이미 개발이 되어있는 상태라면, 이미 다른 개발자분들이 작성한 기능들을 통해서 그 동작을 어렵지 않게 유추할 수 있었습니다.

저는 백엔드에 대해서 깊은 학습을 진행하지 않았지만 큰 러닝커브를 가지지 않고 필요한 기능들을 구현할 수 있었습니다.

2) 구글의 산하에 있다...!

공식문서가 비교적 친절했으며, 적어도 제가 firebase를 통한 개발을 할때, 공식문서를 통해서 모든 문제를 해결할 수 있었습니다.
빠르게 업데이트가 진행되며 제가 느끼기에 설명이 굉장히 친절했다고 느꼈습니다.

3) 다양한 기능 제공

대표적으로 console 기능과 analitics 기능이 있습니다.
초기 스타트업에서 admin 기능을 구현하는것에 인력과 자원을 투자하는것은 어려운 결정입니다. 이 밖에도 수많은 challenge들이 있기 때문입니다.
그럼에도 이런 기능을 사용할 수 있는것은 전사적으로 큰 비용을 절감할 수 있습니다.

또한 analitics 기능 또한 유용합니다. 보통 분석도구를 사용하신다면 GA를 사용하시는 경우가 많을텐데 event들에 대해서 정확하게 규정하기 전이라면 충분히 firebase에서 기본으로 제공하는 analitics 만으로도 괜찮은 측정이 가능하리라 생각합니다.

물론 이 밖에도 많은 장점들이 있지만 글의 목적상 단점을 적어보도록 하겠습니다.

3. Cons

1) 사실 그정도로 단축은 아니야!

위의 Pros에서 사용한 사진의 원본입니다.
희망적으로 작업시간이 비약적으로 단축되는것은 맞으나 프론트엔드 개발에 대한 시간이 그만큼 증가합니다.

firebase를 사용할 관련 query에 대한 코드가 프론트엔드 개발의 모든 부분에 포함이 되어야 하기 때문입니다.

만약 database의 쿼리가 수정된다면, 바뀌게된 쿼리를 프론트엔드 로직에서 "모두" 찾아서 확인해야만 합니다. 아주 끔찍한 일이죠...🥲

+) 만약 쿼리를 바꿔주게 되면 여기서 또 어떤 문제가 발생할까요?
예를 들어서 기존에는 유저의 data에 주소 정보가 없었다고 합시다.
하지만 주소 정보가 추가되게 되었으며 FE의 어느 로직에 주소를 기반으로 유저를 찾는다고 합시다. 이때 FE에 firebase관련 사항들이 업데이트 되겠지만 firebase에서 data로서 저장되어있는 값들은 업데이트 되어 있지 않습니다. 이 경우 어떻게 해야할까요? 모든 user에 대해서 address를 추가해 주어야 할까요? 여기서 중요한 점은 FE배포와 DB의 변화가 동기적으로 연결이 안된다는 점입니다.

2) 스파게티 코드 유발 가능성이 너무 높았다...

{ //user
    name : "adult lee",
	team_ids : [...]
}

{ // team
    name : "velog",
	user_ids : [...]
}

다음과 같은 구조를 가질 때, 유저가 새로운 velog라는 팀에 들어가게 된다면, teams_ids를 확인하여 velog를 확인하고 추가한뒤, velog라는 팀을 조회하여 다시 user_ids를 확인하여 유저를 확인하고 추가합니다.
간단하게 확인해 보았지만 여기서 관계가 조금만 더 복잡해진다면 FE로직에 꽤나 복잡한 스파게티 코드가 발생할 확률이 굉장히 높아집니다.

3) 쿼리의 빈약함

앞서 말씀드렸지만 NoSQL로서 DB를 설계하는것은 꽤나 어려운 일입니다. 예를 들어 왼쪽의 Books안에는 책에 대한 정보들이 들어가 있습니다.
Client에서는 Haruki Murakami라는 author을 쉽게 찾을 수 있습니다. 하지만 firebase에서는 Haruki Murakami가 작성하였으며 1994인 책은 찾을 수 없습니다.

이를 실행하는 방법은 Haruki Murakami의 모든 책들을 가져온 다음 map, filter등등의 함수를 사용하여 클라이언트에서 코드로서 찾아내야만 합니다.

+) 물론 방법이 있습니다...

가장 좋은 해결방법은 다음과 같이 firebase를 설계하지 않는 것입니다. Nosql이면 Nosql답게 데이터를 정립하고 확장성 위주로 개발을 진행하는 것이 옳다고 합니다. 다만 저희는 Nosql로서 firebase를 사용하는 것이 아닌 새로운 인력이 충원됨에 따라 관계형 데이터 베이스로 옮기는 선택을 하게 되었습니다.

4. 결론

물론 제가 작성한 정보들 이외에도 firebase가 가진 문제들이 많습니다.
하지만 제가 느끼기에 당시 느꼇던 것들 위주로 정리해서 작성하였습니다.

Firebase는 모바일 앱 개발을 하기위해 초기 설계되었다고 합니다. 그렇기
때문에 앱 서비스를 주류로 시작한 우리 회사에선 그 상황에선 최선의 선택이 었다고 생각합니다. 하지만 서비스가 성장하면서 앱 뿐만 아니라 웹 서비스로 확장을 시도하고, 앱 내부에서도 웹뷰를 사용하는 등 다양한 플랫폼을 사용하게 되면서 결국엔 Firebase를 제거하자는 결론을 내리게 되었습니다.

그리고 결국 관계형 데이터 베이스를 사용하기로 하였습니다. 백엔드는 Node로 구성하며 TypeORM을 사용하여 postgre로 마이그레이션을 종료하였습니다.

물론 해당 과정들 중에서 FE개발자였기 때문에 핵심적인 역할을 수행하지는 않았으나 주로 FE로직에 있는 firebase쿼리문을 제거 하고 data fetch하는 부분을 도맡아서 개발하였으며, 일부 Api를 개발하였습니다.