Firebase backend cover

Firebase를 실제 모바일 백엔드로 사용하면 일어날 수 있는 일들

안드로이드 개발자들을 위한 수준 있는 독립 컨퍼런스인 Droid Knights에서 “파이어베이스를 실제 모바일 백엔드로 사용하면 일어날 수 있는 일들”이라는 주제로 강연된 세션입니다.


소개

원래 Firebase를 모바일 백엔드로 사용하면 일어날 수 있는 문제를 중심으로 강연을 준비하고 있었는데, 강연 1~2주 전에 해당 이슈들이 해결돼서 Firebase를 모바일 백엔드로 사용하면 일어날 수 있는 일들과 함께 Firebase를 사용하면 어떤 허들이 있는지 통합적으로 말씀드리도록 하겠습니다.

Firebase는 전 세계적으로 열심히 홍보되고 있고 많은 분들이 코드랩 등에서 배우기도 했지만, 아직까지 크게 배워야 할 필요성을 느끼지 못하거나 실제 프로덕트에 적용해도 무방한지에 대해 의문이 있습니다. 이번 강연에는 이런 부분에 초점을 맞추겠습니다.

Firebase 소개

firebase-introduction

BaaS(Backend as a Service) 혹은 PaaS(Platform as a Service)는 작업 시간을 단축하기 위해 도입됐지만 실제로 서버 개발 인력을 없애더라도 누군가는 서버를 담당해야 하므로 프론트엔드 개발자들이 서버를 담당해야 하는 것이 현실입니다. 물론 AWS 등이 좋은 서비스를 많이 제공하고는 있지만 전문적인 지식과 경험을 가진 개발자가 필요한 것은 마찬가지이기 때문입니다. 물론 클라이언트 개발자의 역량을 넓힐 수 있다는 점에서는 좋을 것으로 생각합니다.

이런 개발 뉴스를 더 만나보세요

제가 Firebase를 사용하면서 가장 좋았던 점은 보안입니다. 최근 한 스타트업이 SQL 인젝션으로 문제가 됐는데, 그런 것도 막지 못 했냐고 생각할 분도 있겠지만 해커들은 어떻게든 보안을 뚫고 침입할 방법을 찾아내므로 Firebase를 쓰면서 이런 보안 부문이 가장 안심됐습니다.

Firebase = Database

firebase-database

Firebase는 데이터베이스입니다. NoSQL이자 키-밸류와 도큐멘트 스타일의 JSON을 쓰므로 DB를 설계하는 데 생각보다 머리가 아플 수 있습니다. 예를 들어 왼쪽 데이터처럼 Books 안에 UUID로 책들이 들어가 있는데, 클라이언트 쪽에서 “하루키”로 검색하는 것은 가능하지만, “하루키”가 “2002”년도에 쓴 책을 찾는 것은 가능하지 않습니다. 그래서 두 가지 방법으로 검색해야 하는데, 먼저 루트에 Books가 아닌 Books-2002라는 부모를 만들어서 이 노드를 검색하는 방법을 사용하던가, “하루키”라는 책을 다 불러온 다음 클라이언트 상에서 “2002”로 필터링하는 방법을 사용해야 합니다. 권한을 JSON 형태로 넣는 것도 허들로 작용했습니다.

또한, 기획자가 제목 중에 “bird”가 들어가는 것을 검색하고 싶어한다면 개발자가 Full-text 검색이 되지 않고 tag를 써야 한다고 설득해야 하는 상황도 생깁니다. 이런 내용을 Firebase 개발자에게 문의했더니 Apache의 오픈 소스를 추천했다고 합니다. 학습 곡선이 높으므로 좋은 답변은 아니겠죠.

Firebase로 만든 앱 개발 경험

firebase-example1

제가 만들었던 앱을 보면서 설명하겠습니다. 360도 사진을 클라우드에 올리고 공유하는 간단한 앱을 Firebase로 만들었습니다. 첫 번째 화면은 섬네일로 리스팅이 되는 기능입니다. 아래 업로드 버튼을 누르면 사진을 올릴 수 있고 이미지를 360도로 돌려서 볼 수 있습니다.

// example2

다른 중요한 기능은 링크를 공유하는 겁니다. 링크를 공유하면 앱으로 연결돼서 사진을 보거나 웹에서 볼 수 있고, SNS에서도 공유할 수 있도록 했습니다.

firebase-external-sever3

첫 번째로 맞닥뜨린 문제는 섬네일을 만드는 것이었습니다. 최근 Cloud Function에서 섬네일을 만드는 기능이 추가됐지만 앱 제작 당시에는 되지 않아 어려웠습니다.

두 번째 문제는 이미지 프리뷰 속도가 너무 느리다는 것이었습니다. Firebase Storage를 썼는데 목록을 가지고 오고 Google Cloud Storage URI에서 이미지 URL을 얻고, 이미지 URL에서 이미지를 얻어와야 했습니다. 보통이라면 이미지 URL이 있는데 Firebase에는 Google Storage URI를 저장하는 한 단계가 더 있습니다. 그 이유는 Google이 이미지를 요청할 때 요청자가 엑세스 권한을 가졌는지, 토큰이 만료되지는 않는지 확인하기 때문입니다. 그런데 이 서버가 해외에 있으므로 많은 단계에 의한 로스가 많이 발생했습니다. 특히 스크롤 뷰인 경우에 문제가 많았고, 토큰값이 계속 바뀌기 때문에 많이 사용하는 Picasso 등의 이미지 로더 라이브러리를 기본값으로 사용해서 캐싱할 수 없었습니다. 이 문제도 Firebase UI라는 라이브러리를 만들어서 글라이드 이미지 로더로 최근 해결이 가능해지긴 했습니다.

firebase-example4

단, 마지막 문제인 Share Link는 아직 해결되지 않았습니다. Firebase 호스팅을 사용해서 이미지 주소를 올려서 해결할 수 있을 것으로 생각했지만, SNS에서 참조하는 메타 값을 지원하지 않기 때문에 다이나믹하게 페이지를 생성해서 전달하지 못합니다. 앞서 말한 문제들은 결국 우회책으로 해결할 수 있었지만, 마지막 문제는 해결할 방법이 없기 때문에 결국 Firebase에 외부 서버를 추가했습니다.

firebase-external-sever1

외부 서버를 추가하면 Firebase를 왜 사용해야 하는지 의문이 들긴 했지만 얼마나 어려운지 알려드리기 위해서 작업을 계속 진행했습니다. admin SDK와 Node.js, Java SDK를 지원합니다. Android SDK를 사용한 경우 Gradle도 사용할 수 있어서 이 점은 편리합니다. 저는 Node.js를 사용해서 낮은 응답속도를 갖는 도쿄 VPS로 고정 이미지 주소와 On-the-fly 썸내일 생성 및 캐쉬, 다이나믹 엔드 페이지를 생성했습니다. 외부 서버를 위해서는 한 달에 5달러라는 추가적인 서버 비용과 Node.js, Express, ImageMagick, EJS, SSL 인증서, c0.io 등 많은 것이 필요했고 무엇보다 개발 기간이 2배가 소요됐습니다. 이걸 왜 써야 하는지 심각하게 고민이 들었습니다.

firebase-external-sever2

하지만 최근 베타 서비스로 영문에서만 접근한 Cloud Functions를 발견하게 됐습니다. Node.js만 사용할 수 있는데 이를 통해 Cloud Function을 만들 수 있습니다. 다른 서버를 만들면서 최근 Paas.com의 사례도 그렇지만 Node.js가 가벼운 애플리케이션을 만드는 데는 인기 있으므로 Node.js라는 선택이 개인적으로는 좋은 것 같습니다.

firebase-example3

Cloud Functions의 기능은 위 그림과 같습니다. 몇 가지 트리거들이 있는데 실시간 데이터베이스에 작동하는 트리거, 데이터를 저장하고 후처리할 수 있는 어드민 서버를 대신할 수 있는 기능이 있습니다. 사용자 인증 관련 트리거도 있습니다. Analytics 이벤트가 들어왔을 때 추가 액션도 할 수 있습니다. 추가적인 통계 데이터를 만들 수 있을 것 같습니다. 클라우드 스토리지에 바이너리 데이터가 들어오는 경우에 발동하는 트리거도 있고, Http request를 통한 요청도 REST API와 비슷하게 처리할 수 있어서 간단한 프로그램을 만들기 좋습니다. 또한 Google Cloud 인프라 간 메시지 전달 방식도 제공합니다.

제가 예전에 만들었던 앱도 서버 개발자 없이 Parse 서비스를 써서 개발했는데, 초기 시작하는 프로젝트나 사이드 프로젝트인 경우 부족한 것 없이 충분히 쓸 수 있다는 장점이 있었습니다.

Parse의 장점은 MongoDB를 사용해서 하이브리드 느낌으로 RDB 사용과 비슷하게 사용할 수 있었다는 점이었습니다. 다만 초당 요청 개수로 비용이 청구되기 때문에 비용이 많이 들었습니다. 하지만 Google의 경우 개발자가 초기 설정하는 데는 힘이 들 수 있지만, 실제 운영 시에는 동시 접속사가 아무리 많더라도 추가 비용이 들지 않는다는 장점이 있습니다.

Firebase을 사용하면서 처음 든 걱정은 Parse처럼 Firebase도 망하면 어쩌지 하는 걱정이었습니다. 물론 Facebook는 서드 파티를 줄이는 추세였기 때문에 Google의 사례는 다르다고 생각합니다. 또한 AWS가 국내에서 크게 확장하는 동안 잠잠하던 Google이 의욕적으로 서비스하는 플랫폼이 Firebase고, 개발 속도도 상당히 빠르기 때문에 프로덕트 레벨에서도 사용할 수 있을 것이라 생각합니다. 최소한 2-3년은 사용할 수 있는 서비스라고 생각합니다. 전체 프로젝트에 적용하기 부담스럽다면 작은 단위로 시작하는 것도 많은 도움이 될 것으로 생각합니다.


본 영상과 글은 Droid Knights의 비디오 스폰서인 Realm에서 제공합니다. 모바일 개발자가 더 나은 앱을 더 빠르게 만들도록 돕는 Realm 모바일 데이터베이스Realm 모바일 플랫폼을 통해 핵심 로직에 집중하고 개발 효율을 높여 보세요! 공식 문서에서 단 몇 분 만에 시작할 수 있습니다. 또한 Realm 홈페이지에서는 모바일 개발자를 위한 다양한 최신 기술 뉴스와 튜토리얼을 제공하고 있으니 즐겨찾기하고 자주 들러 주세요!

다음: Realm Java를 사용하면 안드로이드 앱 모델 레이어를 효과적으로 작성할 수 있습니다.

General link arrow white

컨텐츠에 대하여

2017년 3월에 진행한 Droid Knights 행사의 강연입니다. 영상 녹화와 제작, 정리 글은 Realm에서 제공하며, 주최 측의 허가 하에 이곳에서 공유합니다.

장도훈

도돌 앱을 개발했던 장도훈입니다. 인디 개발자로 다시 지내고 있습니다.

4 design patterns for a RESTless mobile integration »

close