필자는 프로젝트를 기획하면서 다음과 같은 기능 구현이 필요해졌다.
- 로그인
- 유저 정보 저장
- 피드 글 작성
- 등등
즉, 필자에겐 데이터를 저장, 관리할 서버가 필요해졌다는 것이다.
개인 서버 구축 방법을 찾아보자.
서버를 구축할 필요가 없다.
회사에서 클라우드 서버를 제공하는 서비스가 잘 돼있기 때문이다.
구글 사의 GCP(Google Cloud Platform), 아마존 사의 AWS(Amazon Web Service), 마이크로소프트 사의 Azure 서비스들이 흔하게 사용된다. 그리고 프로젝트에 따라 적절하게 선택하여 사용하면 된다.
초기 스타트업의 경우 AWS와 Firebase를 흔하게 사용한다.
필자는 결과적으로 Firebase를 선택했다. Firebase가 어떤 서비스인지 알아보자.
Firebase?
먼저, Firebase에 대해 알아보면 GCP라는 키워드가 보이게 된다.
면접에서도 GCP, AWS, Azure 중 어떤 서비스를 경험해봤는지에 대한 질문이 흔하게 나오기도 한다.
필자는 이 GCP와 Firebase, 두 플랫폼 간의 차이가 무엇인지 궁금했다.
그리고 그에 대한 해답은 Firebase의 공식 문서에 아주 잘 나와있다.
Firebase
mobile development platform
- 클라이언트 측 앱 개발자(웹 및 모바일)가 사용하는 모바일 개발 플랫폼이다.
- 새로운 모바일 앱을 구축하고, 새로운 기능으로 기존 앱을 보강하는데 사용한다.
GCP
suite of cloud computing services
- 백엔드 및 서버 측 개발자가 사용하는 클라우드 컴퓨팅 서비스 플랫폼이다.
- Google의 핵심 인프라, 데이터 분석 및 기계 학습을 활용하여 소프트웨어를 구축하는 데 사용된다.
그리고 이 Firebase 서비스는 GCP로 뒷받침되고 있다. 함께 사용하는 것도 당연히 가능하다.
해당 서비스는 Firebase의 Cloud Function으로 이용할 수 있다.
위 사진은 GCP flowchart이다.
다양한 Google Cloud Platform(GCP)의 각 컴포넌트를 선택할 때, 어떤 기준으로 선택하면 좋을지에 대해 간략하게 정리된 차트이다.
왼쪽으로 갈 수록 Highly customizable/오른쪽으로 갈 수록 Highly managed한 서비스이다.
Firebase, GCP 모두 Google의 Cloud Computing Service인 것은 동일하지만 Firebase는 위 플로우 차트 상에서 가장 오른쪽에 위치하며, 클라이언트 측 앱 개발자가 특별한 커스터마이징 없이 사용할 수 있는 클라우드 컴퓨팅 서비스인 것이다. Firebase의 경우 어느정도까지 서비스를 제공하냐면, 서버를 구축할 필요도, 서버 측면에서 CRUD 시스템을 구현할 필요가 없다. Firebase에서 제공하는 함수들을 그대로 사용하여 서버를 이용하면 될 뿐이다.
서버를 사용하는 앱을 구축할 때, 거진 클라이언트 개발에만 집중하면 된다는 것이다.
따라서 필자는 앱 개발을 진행했기에 이러한 서비스가 필요했고
타경쟁사 제품인 AWS나 Azure보다 진입 장벽이 낮고, 보다 직관적인 UI를 가진 Firebase 제품을 선택했다.
하지만 Firebase의 경우 타사 제품들에 비해 상대적으로 좀 더 비싼 가격을 책정하는데,
비용 측면에선 걱정할 필요가 없다. 앱 서비스의 규모가 웬만치 크지 않다면
프로젝트을 플레이스토어에 런칭하더라도 값을 지불하기 까지의 사용량에 도달하기 어렵기 때문이다.
필자가 사용한 Firestore 서비스의 가격 책정 기준은 문서 write/reads/delete 횟수가 가격책정의 기준이다.
각각 20K/50K/20K까지 무료이다. 매우 비효율적으로 Firebase를 사용하지 않는다면, 개인 프로젝트 수준이
이정도 사용량이 발생될 확률은 매우 낮다고 판단했다. 그리고 Firebase에서 aws로 이전하는 방법도 존재한다고 하니, 가벼운 프로젝트를 시작할 땐 Firebase로 시작하는 것도 괜찮겠다. 물론 처음부터 신중하게 판단하여 적용하는 것이 가장 좋다.
Firestore
구글 Firebase는 클라이언트 개발 시 사용할 수 있는 다양한 서비스를 제공한다.
큰 카테고리로 앱 빌드/앱 품질 향상/비즈니스 성장 도모가 보인다. 필자는 앱 빌드의 클라우드 DB 서비스, 유저 인증에 관련된 기능(인증), 이 정도 기능만 사용해도 필자가 진행한 프로젝트는 충분히 커버된다. 하지만 Firebase는 그 외에도
- ML Kit(머신 러닝 툴)
- Crashlytics(비정상 앱 종료 분석)
- Perfomance Monitoring(성능 분석)
- Analytics(앱 사용 및 사용자 참여도 통계)
- Cloud Messaging(실시간 채팅 구현)
등등등.. 앱 빌드를 포함해, 앱 출시 이후 유지 보수 및 관리를 하기 위한 갖가지 서비스까지 제공한다.
이러한 서비스 이용 비용보다 서버 구축 비용이 더 비싼 클라이언트 개발자들에겐 매우 좋은 서비스이다.
필자는 결과적으로 firebase의 NoSQL DB 서비스인 Firestore를 사용했다.
아직까지도 NoSQL에 대한 구체적인 정의는 없지만, 'Not Only SQL'이라는 표현이 가장 정의에 근접하다는 것 같다. NoSQL DB는 기존 관계형 DB의 SQL을 사용하지 않는 Schema-less 데이터베이스를 말한다. SQL을 사용하지 않는 이유는, SNS 등의 서비스들이 많이 등장했기 때문이다. 관계형 데이터(정형데이터)가 아닌 데이터, 즉 비정형데이터를 보다 쉽게 담아서 저장하고 처리할 수 있는 구조를 가진 DB들이 발전을 하게 됐고, 이러한 시대흐름 속에서 현재 NoSQL DB가 흔하게 사용되고 있다.
Firebase의 Firestore가 제공하는 NoSQL DB 서비스는 값을 key-value 타입으로 저장한다. 이 때 value 값으로 저장할 수 있는 데이터 타입은 map, array, Timestamp, String 타입을 포함해 primitive 타입인 Long, Boolean까지 저장할 수 있다. 이러한 타입을 Collection, Document라는 저장 단위로써 DB에 저장하여 사용한다. Firestore의 NoSqlDB 사용 난이도 자체는 매우 쉽다. 사실 상 데이터 타입에 잘 맞추어 저장하고, 타입에 잘 맞추어 받아와서 뷰에 활용하기만 하면 된다. 데이터를 받아와 처리하는 과정에서 blocking의 문제, 즉 코루틴 활용만 신경 써 주면 되는 편이다.
결론
필자는 Firebase라는 GCP의 서비스를 활용해서 서버 구축 없이도 소셜 서비스 앱을 만들고 출시까지 할 수 있었다. AWS, azure 등 타사 제품들은 경험해보지 못했지만, Firebase를 경험해보고 나니 나중에 사용할 일이 있다면 빠르게 적응할 수 있을 것이라는 생각이 들었다. 이것으로 Firebase에 대한 리뷰를 마친다. 다음은 coroutine 적응기에 대한 글이 될 것 같다.
