순서

• Firebase의 등장 배경
• 그래서 등장한 Firestore

Firebase의 등장 배경

정말 간단히 말하자면 클라이언트 개발자의 새로운 개발을 위해 생겼다고 볼 수 있다. 지금은 물론 구글의 인수 이후로 정말 날개를 단듯 MLkit이라던지 내부적으로도 많은 업데이트를 진행하고 있지만 기본적인 출발은 ‘시작을 빠르게’라는 취지로 누구나 웹 개발, 앱 개발을 더 이상 서버까지 고민하지 말고 만들자. 라는 출발이었다

그 출발은 괜찮았다 Firebase(이하 ‘파이어베이스’)의 요금은 정말로 합리적이었으며 내부적으로 제공하는 Storage와 Authentications등은 데이터베이스 하나로 파이어베이스를 사용하는 것이 아니라 그 외에 부가적인 부분에서도 많은 이득을 챙길 수 있게 되었다.

나와 같은 경우 처음 파이어베이스에 대해서 듣게 되었을땐 ‘정말로 이런 서비스가 가능한가?’라는 의문도 품었었다.

그러나 매끄럽게 가능했다. 파이어베이스 실시간 데이터베이스는 더욱 더 그러했다. 별다른 서버사이드 코드없이도 이제 프로토타입 그리고 어느정도 규모있는 앱까지는 충분히 만들어 볼만 했다.

‘어느정도’에 주목하자

물론 이 글을 읽는 당신이 개인 개발자고 개인으로서 결과물이 어느정도 훌륭해서 금전적인 이득을 얻는 수준의 ‘규모’에서는 전혀 문제될게 없었다.

그래서인지 해외에서도 개인이 앱을 만들어 먹고사는 ‘개인 개발자’에게 있어서는 정말로 괜찮은 서비스이었다.

왜 ‘규모’에 대해서 언급하냐면 Firebase의 데이터베이스는 괘랄하다 못해서 사실 별로였다.

아니 괜찮다며;;

아니 정말 괜찮은 서비스임에 분명했지만, Query의 부재 그리고 속도 등의 이슈로 규모가 조금 있는 서비스라면 사용을 자제하는것이 좋다고 생각이 들었다.

그래서 등장한 Firestore

지금은 물론 ‘Beta’서비스 이긴 하지만 말 그대로 ‘등 - 장’했다.

모름지기 개발자라면 ‘프레임워크, 라이브러리에 대한 의존성이 없어야해!’라고 말씀하셨던 선배님의 말씀이 떠오르지만 Firestore(이하 ‘파이어스토어’)에는 조금 의존을 해보고 싶었다.

그동안 존재하지 않았던 Query와 더욱 더 강력해진 Rule과 이제 더 이상은 파이어베이스를 사용하지 않아도 괜찮다!

파이어스토어의 몇가지 특징을 얘기하자면

• 빠른 NosSql 데이터 베이스
  • 콜렉션과 도큐먼트 기반의 확장성이 용이한 데이터 베이스 설계
• Query의 사용이 가능함 (Admin-sdk에서는 기능이 더욱 강함 ‘Skip’ 등)
• 파이어베이스부터 단련된 Rule!

등을 대표적으로 얘기할 수 있는데

이런 데이터베이스를 서버사이드 코드 없이 사용할 수 있다는것은 정말 개발자로 하여금 많은 일을 가능하게 만든다.

가령 기존 파이어베이스로 게시판을 만든다고 했다면 당연히 하지말라고 얘기했을 것이다 차라리 페이스북의 GraphQL을 사용하라고 하고싶었다.

그러나 이번엔 다르다 빠른 NoSql의 데이터베이스는 기존 정적인 게시판이 아닌 정말 넓은 확장성을 자랑하는 게시판을 만들 수도 있으며

게시판에서 빠질수 없는 검색등의 기능도 향상된 Query로 만들수 있으며

거기다가 Functions의 연동을 통한다면 기존에 우리가 사용하던 데이터베이스들에 내장되어있던 Skip등의 기능이 사용가능하다는 점이 있다.

내가 생각하는 가장 중요한 ‘Rule’

그러나 파이어베이스, 스토어 사용에 있어서 가장 중요한 점은 Rule이다 바로 Rule이 Rule을 어떻게 사용하느냐에 따라 여러분의 서비스는 굳이 의미 없는 파이어스토어 사용이 될 수 도있으며 반대로 매우 매끄러운 사용이 가능해진다

고작 Rule하나로?

그렇다 Rule은 상당히 중요하다. Rule이 파이어스토어의 존재 이유라고 할수 있을 정도로 중요하다. 예를들자면 당신의 블로그에 설정은 당신만이 할 수 있어야만 한다. 이것을 서버사이드에서 처리하자면

요즘 유행하는 Token방식의 인증으로 매기자면 Token 내부에 예를들면 ‘isAdmin’이라는 변수를 만들어놓고 새로 들어온 요청에 한해서 이것을 검증을 해서 그 다음 로직을 실행…..하게 해야한다.

그러나 파이어스토어는 이런 검증을 Rule에서 해결 가능하다. 요청하는 유저의 UID값을 받아온 뒤 Rule 내부에서 또 다시 Get을 한다음에 해당 블로그의 주인만 가려놓고 만약 맞다면 Allow를 아니라면 딱히 코드를 작성하지 않아도 Permission 에러를 뿜으며 실행되지 않을것이다.

응? 적고 보니까 Token 방식이 더 간단하네?

그렇다 당신이 ‘서버사이드’를 조금 공부했다면 사실 위에 방법이 더욱 쉬울 것이다. 나도 그랬다 사실 처음엔 이해가 안됐고 오히려 개발 시간이 서버를 갖는 것보다 오래 걸리기 때문에 짜증도 났다.

그러나 분명한건 이것은 서버의 관리 없이도 돌아간다는 점이다.

간혹 ‘서버리스’에 대해서 언급하면 꼭

그걸 왜함?? 어차피 서버 규모 커지면 그냥 서버가 더 이득임

라는 말을 찾아 볼 수 있는데 서버 개발자의 월급은 하늘에서 떨어지는줄 아는 사람이 많다. 생각보다 서버개발자의 임금은 높다. 데이터베이스를 매끄럽게 설계해야하는 그들은 당연히 받아가야할 임금을 받아가는 것이고 아까는 정말 단순하게 Token으로 인증하는 것을 말했지만 실제 데이터베이스 설계에선 어쩌면 더욱 많은 절차가 필요할지도 모른다.

그래서

일단 함 써보세요 진짜 Rule만 잘 이해하면 이만한 서버리스 프로젝트가 없을겁니다.

그러나 최근 AWS에 AppSync가 GraphQL을 도입해 비슷한 서비스를 하고 있으니 한번 찾아보시는 것도 추천합니다.