19. 그룹 기능 구현과 Firestore 데이터 구조 고민

지금까지는 아이디어를 결과로 보여준다는 느낌으로, 떠오르는 생각들을 바로 구현해 나갔었다.

설계를 해보려고 했는데 머릿속에 다 정리된 내용을 손으로 다시 하나하나 옮기려니

단순작업을 하는 느낌이었기 때문에 의지가 생기지 않았다.

 

그러다 그룹 기능을 구현하던 중 고민거리가 생겼다.

내가 의도하는 그룹의 기능은 일종의 밴드 그룹같은 느낌이다.

특정 유저끼리 모여서 그룹을 구성하면

그 그룹에서 매주 정기공연을 한다고 하자.

그럼 매주 정기 공연마다 연주할 악보 셋리스트가 달라질 것이다.

그래서 그룹을 만들면 일정을 만들고, 매 일정마다 어떤 악보들을 넣을지 고를 수 있도록 기능을 만들었다.

 

예를 들어, 위 화면 같은 경우,

테스트 라는 일정에서 '내 손을 잡아' 의 악보를 넣은 상황이다.

이렇게 일정마다 악보 리스트들을 저장하기 위해 가장 먼저 떠올린 방법은 리스트로 모든 일정을 저장하는 것이었다.

[
  {
    schedule_name: "테스트",
    set_lists: [
      {
        title: "내 손을 잡아",
        singer: "IU",
        sheet_id: "sss~~",
      },
      {...},
      {...},
    ]
  },
  {..},
  {..},
  ..
]

이렇게 리스트를 쓴 이유는 일정을 생성순으로 정렬하고 싶었기 때문이다.

생성할때마다 리스트에 추가해서 리스트에 저장된 순서대로 보여주는 게 가장 간단한 방법이라고 생각했다.

하지만 이렇게 저장했을 때의 문제가 있었다.

 

내가 생각한 첫번째 문제는, 화면상에 보여주는 일정은 하나,

셋리스트도 그 일정에 따른 셋 리스트만 보여주면 되는 상황이다.

 

그러나 이렇게 모든 데이터를 한번에 불러오게 되면

초기에 불필요한 데이터까지 너무 많이 불러오는 문제가 있다고 생각했다.

 

두번째 문제는 Firestore 라는 데이터베이스는 NoSQL 이다.

NoSQL은 중복으로 데이터를 저장하는 것을 허용하여

읽기는 빠르지만 쓰기가 오래걸리는 부분이 특징이다.

 

하지만 저렇게 한 묶음으로 데이터를 저장하면 데이터가 조금만 바뀌어도 쓰는 양이 많아진다고 생각했다.

그리고 저렇게 추가한 악보를 원 악보 제작자가 악보를 삭제한 경우

악보가 삭제되었다는 것을 어떻게 구현할지도 고민이었다.

이 한 묶음 전체 데이터 내부를 다 뒤져서 삭제하는 것도 꽤 큰 일이라는 생각이 들었다.

 

그래서 데이터를 읽을 때도, 쓸때도 적은 비용으로 데이터를 읽고 쓸 수 있도록 하는 대안으로 고민한 것이

set_lists를 collection 으로 빼는 것이다.

 

이렇게 컬렉션으로 set_lists를 구분했다.

다만 이 경우 시간순 정렬을 구분하려면 생성 시간 필드를 만들어서 정렬해야 하는 문제가 있긴 하다.

하지만 데이터를 읽을 때는 선택한 일정의 문서만 조회하면 되기 때문에 읽는 데이터의 크기도 줄어들고

쓸 때도 선택한 일정의 문서에서 쓰기만 하면되기 때문에 쓰는 것도 부담이 줄어든다고 생각했다.

그리고 악보 정보도 document referece를 이용해서 연결하도록 했다.

 

document reference를 쓰는게 맞는지는 확신이 아직은 안선다.

document reference를 이용하여 구현하면 이 doc의 문서 데이터를 가져올 때도 Firestore와 통신을 해야하기 때문이다.

그래서 악보가 5개면 5번 통신을 해서 가져오는 방식이다.

한번 통신때 필요한 데이터 양을 줄이려다 통신횟수를 늘려버리게 된 것은 아닐까 하는 생각도 있다.

일단 지금은 document reference 라는 기능을 사용해보는 것에 의의를 두기로 해서 이렇게 구현했다.

 

DB 사용을 관계형 디비로 맨 처음 사용해봤다가 이렇게 NoSQL로 하게 되니 굉장히 어색한 점이 많다.

프론트 화면을 다 만들고 나면 백엔드를 따로 다시 만들어볼까도 고민하게 된다.