Firebase Realtime database를 현업에 적용시켜보니...

몇개월만에 글을 쓰는건지 모르겠다.

그동안 많이 바빴다. 회사 일이 너무 바빴다. 추후에 이야기를 하겠지만 개인적인 이유때문에 퇴사를 하였고 며칠 좀 쉬었다. ㅎ... 그런 이유들 때문에 그동안 블로그에 게시글을 올리지 못했고 지금은 여유가 생겼으니 새 글을 올려보려고 한다.

나의 퇴직 후 첫번재 게시글은 파이어베이스를 현업에 적용시켜 보니 만났던 문제점에 대한 글이다.

1. 인증기능

처음 개발할때는 파이어베이스 인증 기능을 구현해야한다고 했지만 퇴사하기 전에 무슨 정신인지 처음부터 인증 기능은 아예 염두에 두지 않은것처럼 이야기하였다. 내가 멍청해서 그렇지... 

각설하고 회원가입, 로그인, 비밀번호 재설정등등... 아니 편한 설명을 위해 로그인만 예로 들겠다.

일반적으로 로그인이라는 행동을 하기 위해선 서버의 개입이 필요하다. 서버에서 발행한 세션(쿠키)든 jwt이든간에 서버에서 특정 값을 줘야한다. 그런데 파이어베이스 로그인은 그렇지 않다. 파이어베이스는 그냥 클라이언트에서 로그인을 한다. 뿐만아니라 회원가입, 패스워드 변경등 모든 인증 관련된 동작이 서버 없이 클라이언트에서 동작한다. (물론 구글쪽 서버가 있지... 개떡같이 말해도 찰떡같이 이해하면 당신은 원빈)

이런 동작 구조를 설명을 해주니 어이가 없어서 헛웃음을 치셨다. 

firebase.auth().signInWithEmailAndPassword(email, password).catch(function(error) {
  // Handle Errors here.
  var errorCode = error.code;
  var errorMessage = error.message;
  // ...
});

firebase.auth().signInWithEmailAndPassword(email, password).catch(function(error) {
  // Handle Errors here.
  var errorCode = error.code;
  var errorMessage = error.message;
  // ...
});

그렇다. 놀랍게도 이건 클라이언트 측 코드다. 서버에 있어야할 코드가 클라이언트에 있는것이다. 놀랍게도 이 코드는 정상적인 코드이다. 파이어베이스 메소드이기 때문이다.

2. RDB와 NoSQL의 차이

NoSQL은 테이블과 스키마의 개념이 없다. RDB는 유연성과 확장성이 떨어지지만 NoSQL은 많이 유연하다. RDB는 C, R, U, D 가 기본적인 명령어지만 Firebase는 Set, update, remove, 그리고 R에 해당하는 on, once 메소드가 그 역할을 대신한다. 그마저도 1:1로 대응하는 기능은 아니다.

이런 차이가 기존의 SQL을 다뤘던 개발자들에게 큰 혼란을 가져다 준다. 

3. 클라이언트에서 직접 CRUD?

1번과 일맥상통하는 부분일 수 있다. 기존 방식은 클라이언트가 서버로 DB 조작 요청을 하고 서버는 이 요청을 유효성 검사 하여 처리를 한다.

하지만 파이어베이스는 이런 방식이 아니다. 클라이언트에서 직접 로그인을 하고, DB를 다룰땐 직접 CRUD를 한다. 그동안 서버 없이 직접 DB를 다루면 위험하다는 학계의 정설(ㅋ?ㅋ)을 정면으로 반박해버린다. (물론 파이어베이스 콘솔에서 직접 보안 규칙을 작성하긴 한다.)

4. 클라이언트 코드가 많아진다.

Firebase가 다른 서버리스 플랫폼과 차별화된 이유를 내 멋대로 하나 뽑으라면 클라이언트에서 직접 서버의 동작을 처리한다는것이다.

기존 방식은 클라이언트에서 http 통신 안에 여러값들을 담아 서버에 요청을 하는 것이라면 파이어베이스로 서버 동작을 하려면 클라이언트에서 직접 조작을 한다. 

당연하게도 이는 클라이언트 코드가 엄청나게 많아진다. 

5. admin 서버 개발은?

내가 채팅을 개발할때 채팅 그 자체는 Firebase를 사용했지만 RDB도 어느정도 의지를 하였다. 

채팅 기능 개발은 그럭저럭 했지만 진짜 문제는 admin 서버에서 검색 기능을 구현할때였다. 검색 조건 중 RDB와 Firebase 둘 다 검색을 해야하는 기능이 있었다. 문제는 NoSQL은 Json 구조적 특성때문에 검색 기능이 빈약하다는 것이다.

채팅 특성상 유저가 많을수록 데이터는 엄청나게 많이 불어나고 특정 String이 들어간 채팅만을 검색한다는것은 어렵다. 또한 검색 조건이 RDB와 FIrebase Realtime Database 둘다 검색해야 하는 조건, 그리고 이 둘을 AND조건으로 검색해야하는 조건은 골머리 아프기 그지없다.

아무리 DB 모델링을 잘 한다 하더라도 한계가 있지 않을까 싶다.

결론

Firebase Realtime database는 좋은 서비스임에는 반박할 여지가 없다. 매우 좋아하는 서비스이기도 하다. 강력하게 추천도 할 수 있다. 하지만 신중히 채택하라고 하고싶다. 레퍼런스도 부족하고 파이어베이스를 잘 모르는 팀원 혹은 상사가 팀에 있다면 골치도 아프다.

실제 프러덕션에 필요한 기능중에 Firebase Realtime database 기능을 이용하고 싶다면 반드시 프로토타입을 만들고 의견 제시를 해야한다.

나처럼 프로토타입을 만들지 않고 무턱대고 프러덕션에 적용시켜 버리면 따라올 위험들이 분명히 존재한다. 너무 많이 존재한다.

웹소켓을 이용한 채팅은 그렇지 않냐고 물어볼 수 있는데 내 생각은 다르다. 웹소켓을 이용한 채팅 예제는 기존에도 많이 있다. 파이어베이스 자료는 비교하지도 못할만큼 자료가 많다. 파이어베이스를 무턱대고 적용시키는것보다 위험은 적을수밖에 없다.