[So.SSul]Firebase의 데이터 모델 살펴보기

---

우리 팀 CrimsonFoot의 두 번째 토이 프로젝트 So.SSul은 릴레이 소설 애플리케이션이다. 소설을 쓰고 싶은 사람은 많지만 글이라는 것이 쉽게 쓰이는 것이 아니기 때문에 누구나 시도는 해볼 수 있지만 끝을 보기는 어렵다. 우리 애플리케이션에서는 한 문장씩 마음 맞는 사람끼리 모여 소설 이어쓰기를 하며 소설 하나를 협업으로 만들 수 있다.

사실 이렇다 보니 우리 앱에는 데이터베이스를 탑재할 서버가 필요해졌다. 우리 팀에는 백엔드 개발자가 없기 때문에 직접 서버 구축을 하기는 조금 그랬다. 어차피 공부와 경험을 목적으로 하는 토이 프로젝트이기 때문에 백엔드 공부도 하면서 개발하면 좋았겠지만 그래도 어떻게든 서비스를 최대한 빨리 완성하여 우리 팀에 작은 성공의 경험을 느끼게 하고 싶었기 때문에 So.SSul의 백엔드로 Google의 Firebase를 사용하기로 했다. 일종의 클라우드 서비스인데 이런 서비스를 PaaS(Platform as a Service)라고 한다.

위키백과에 나오는 PaaS의 정의는 다음과 같다. 출처

서비스로서의 플랫폼(Platform as a Service, PaaS)은 클라우드 컴퓨팅 서비스 분류 중 하나다. 일반적으로 앱을 개발하거나 구현할 때, 관련 인프라를 만들고 유지보수하는 복잡함 없이 애플리케이션을 개발, 실행, 관리할 수 있게 하는 플랫폼을 제공한다. SaaS의 개념을 개발 플랫폼에도 확장한 방식으로, 개발을 위한 플랫폼을 구축할 필요 없이, 필요한 개발 요소를 웹에서 쉽게 빌려쓸 수 있게 하는 모델이다.

구글이나 네이버, 다음 등에서 제공하는 공개 API가 PaaS의 일종이다. 구글의 '앱 엔진'이나 Bungee Labs 의 '번지커넥트' 등은 직접 온라인 서비스를 개발에서 배포, 관리 까지 할 수 있는 플랫폼을 제공하고 있다.

Amazon의 AWS나 Microsoft의 Azure도 있었으나 다들 처음부터 과금을 해야 하기도 하고 우리 앱이 그렇게 헤비한 서비스들을 사용할 것 같지 않아서 가볍게 Firebase로 시작했다.

데이터베이스에 대해서 배운 것이라고는 김연희 저 『데이터베이스 개론』 한 권 읽어 본 것이 전부이지만 적어도 데이터베이스를 쓰기 위해서는 데이터베이스 설계를 먼저 해야 한다는 것 정도는 알고 있었다. 그래서 설계에 앞서 Firebase의 데이터 모델은 어떤지 공식 문서를 통해 알아보기로 했다.

---

Firebase는 어떤 데이터베이스인가?

공식 문서에 따르면 Firebase는 NoSQL 데이터베이스라고 한다. NoSQL 데이터베이스는 무엇인가? 말 그대로 No SQL, 즉 SQL이 아니라는 뜻도 있다고 하고 Not Only SQL SQL만 있는 것이 아니라는 뜻도 있다고 한다. 그러면 SQL은 무엇인가?

SQL은 Structured Query Language의 약자이다. 이 질의어는 관계형 데이터베이스(RDB)를 조작하기 위해 사용된다. 관계형 데이터베이스는 데이터를 행과 열로 이루어진 표로 표현하며 행은 그 데이터의 인스턴스, 즉 개별 데이터를 표현하며 열은 데이터의 속성을 표현한다. 그리고 각 속성에 들어갈 수 있는 값의 형식이 정해져 있다. 테이블 자체를 뜯어고치지 않는 이상 이것은 바꿀 수가 없는 것이다. 이것을 스키마(Schema)라고 한다.

또한 관계형 데이터베이스는 말 그대로 데이터들 간에는 관계가 있어 관계 있는 데이터들은 서로를 참조할 수 있다. 그래서 데이터의 중복성을 피할 수 있다.

그러나 NoSQL 데이터베이스인 Firebase는 스키마, 관계성 이런 거 전혀 없고 오직 데이터를 key와 value로 표현한다. JSON이나 Dictionary 같이 표현하는 것이다. 다만 Firebase는 순수한 key-value 형식이 아닌 MongoDB와 같은 DocumentDB이다.

NoSQL은 무결성, 안정성에 있어 SQL을 따라가기 힘들지만 속도가 빠르고 데이터를 유연하게 저장할 수 있다.

---

그래서 실제로는 어떤 식으로 쓰지?

Firebase는 Document DB이다. 데이터는 문서에 저장되고 문서는 컬렉션에 저장된다. 여기서 주의할 점은 컬렉션은 오로지 문서만 포함한다. 문서 내에 데이터는 당연히 key:value 형식으로 저장된다. 다만 JSON처럼 value가 언제나 문자열로 취급되지는 않는 것 같다.

그리고 Firebase의 패턴 한 가지는 데이터를 계층적으로 구조화할 때 컬렉션-문서-컬렉션-문서 이렇게 교대로 계층이 이루어지도록 해야 한다는 것이다. 공식 문서에 따르면 문서 내의 문서와 컬렉션 내의 컬렉션은 참조할 수 없다고 한다. 참조할 수 없는 데이터가 무슨 소용일까?

어쨌든 구글 공식문서에서 예제로 들고 있는 채팅방 데이터 베이스를 보면 구조가 다음과 같다.

• 채팅방(컬렉션)
  • 채팅방1(문서)
    • 메세지1
    • 메세지2
    • 메세지3
    • …
  • 채팅방2(문서)
    • 메세지1
    • 메세지2
    • 메세지3
    • …

이런 식이다. 그러나 공식문서에서는 이런 식으로 하면 각 채팅방의 문서 크기가 너무 커지기 때문에 권장하지 않는다고 한다. Firebase에서 한 문서의 크기 제한은 1MB이다. 고로 메세지 몇 번 주고 받으면 용량 초과로 제대로 작동하지 않을 것이다. 공식 문서에서 제안한 계층화는 다음과 같다.

• 채팅방(컬렉션)
  • 채팅방1(문서)
    • 이름: “채팅방 1”
    • 메세지들(컬렉션)
      • 메세지1(문서)
      • 메세지2(문서)
      • 메세지3(문서)
      • …
  • 채팅방2(문서)
    • 메세지들(컬렉션)
      • 메세지1(문서)
      • 메세지2(문서)
      • 메세지3(문서)
      • …

보면 컬렉션 - 문서 - 컬렉션 패턴이 잘 나와있다. 첫 번째 예제에서는 메세지라는 문서 하나에 모든 메세지를 순차적으로 저장했는데 두 번째 예제에서는 ‘메세지들’이라는 컬렉션을 만들어서 한 문서에 한 메세지씩 저장하고 있다. 이렇게 할 경우 문서 용량이 초과될 일도 없고 채팅방 자체가 무거워질 필요도 없다.

이제 이런 테크닉을 알았으니 본격적으로 So.SSul의 데이터베이스를 설계해봐야겠다.