<aside> 💡 목차
</aside>
예전에 안드로이드로 채팅 기능을 구현해본 경험이 있었습니다.
당시 Firebase를 사용해 서버리스로 개발했었는데, DB는 고사하고 자바도 제대로 모르던 초보시절이라 채팅에 대한 설계를 어떻게 가져가야할지 몰라서 아래 블로그의 코드를 (거의 그대로) 클론 코딩했던 경험이 있었습니다.
Reference: Firebase 기반 Android 메신저 앱 - DirectTalk9 [SW 개발이 좋은 사람:티스토리]
해당 블로그에서 설계된 구조는 각 채팅마다 읽은 사람의 리스트를 관리하고 이를 통해 읽지 않은 사람의 수를 보내주고 있었습니다.
그래서 Firebase도 MongoDB와 동일하게 NoSQL 중 document-oriented 기반으로 사용되어 문제없지 않을까..? 생각했습니다.
하지만 문제점이 많았습니다.
누군가가 채팅방에 접속하면 해당 유저가 읽지 않은 모든 채팅들에 해당 유저가 읽은 유저임을 추가해줬어야 합니다.
심지어 이 관리가 백엔드의 DB에만 적용되는 것이 아니라, 프론트엔드에서 관리하는 채팅 데이터들에도 갱신된 데이터를 전달할 필요가 있었어요.
말도 안되는 로직을 생각했었지만, 마땅히 해결책이 떠오르지 않았습니다.
그래서 멘토링 시간에 조언을 듣기로 했습니다.
역시나 이 방식은 말도 안되는 방식이니 “절대” 사용해선 안된다 라고 조언을 받았고, 로그아이디에 대한 학습을 하면 해답을 얻을 수 있을 것이라는 힌트를 받았습니다.
처음에는 로그아이디 자체가 어떤 표준화된 규격이 있는건가 해서 로그아이디가 뭔지 찾아봤습니다.
하지만 관련 개념들을 찾아볼 수 없었습니다.