[MOM 투표 서비스] 데이터 설계 우여곡절기
최초 구상
이전 글에서와 같이, 투표를 생성하여 투표하기를 할 때 어떤 데이터가 필요할지 러프하게 생각해 보았습니다. 가장 단번에 떠오르는 것은, 투표받을 사람과 각 사람 별 투표 개수였습니다. 데이터는 항상 받아서 클라이언트에 적용하기만 했지, 직접 만드는 것은 정말이지 일자무식이었습니다… 우선 interface를 만들어 나갔습니다. 그런데 생각해 보니 투표는 만든 유저 별로 다르게 생성되어야 하기 때문에 vote라는 콜렉션에서 무엇을 기준으로 다른 문서가 생성되게 할지도 생각해 봐야 했습니다. 이것은 투표를 만든 유저의 uid를 받아 각각 유니크하게 만들 수 있었습니다. 그리고 투표 생성 일시 정도가 떠올랐죠.
그렇게 처음에는
투표받을 사람: String[]
투표 개수: Number
유저 ID: String(uid)
생성 일시: Date
이런 식으로 데이터를 생각해보았고, 클라이언트에서 구현해보았습니다. 투표를 생성할 때 받을 수 있도록 방법을 찾아보았는데, Firestore에 데이터를 추가하는 방법은 정말… 정말로 간단했습니다! Firebase를 클라이언트에 초기 셋팅 해주었으면, Firebase의 메서드만 사용하면 될 뿐이었죠.(Cloud Firestore에 데이터 추가 | Firebase)
구상했던 대로 vote 컬렉션에 문서를 생성해보았습니다.
시각화를 통한 개선
그제서야 부족한게 무엇인지 눈에 들어왔습니다. DB에 데이터가 들어가니 허전한 것들이 보이더군요. 머리 속에서 생각만하는 걸로는 허점이 많이 들어났고 정리가 잘 되지 않았습니다. 역시 도식화가 필요했습니다. 저는 다른 개발자들처럼 멋지게 다이어그램을 그리는 것이 어려웠기 때문에... 가장 익숙한 피그마에서 낙서처럼 프로토타입 캡쳐 이미지에 데이터를 끄적이면서 구상하기 시작했습니다. 이 과정을 통해 왜 시각화가 필요한지 진정으로 깨닫게 되었습니다! 흐름에 따라 배치를 해보니 필요한 것들과 데이터의 생성 및 업데이트에 대해 좀 더 명확히 머릿속에 들어왔습니다.
우선 투표받을 사람은 이름만 있으면 되는게 아니라 각 이름 별로 개수를 카운팅 해야 했습니다. 즉, 투표받을 사람의 이름과 투표 개수를 담을 객체 배열이 되어야 했죠. 또한, 투표 상태가 필요했습니다. 최소한 진행 중인 상태와 종료인 상태를 가를 수 있어야 했죠. 이런 식으로 완전 부실한 상태로 뼈대를 만들어, 일일이 테스트해보며 무엇이 부족한지를 떠올리면서 부족한 데이터들을 만들어 갔습니다. 그렇게 만든 데이터로
후보자 등록 → 투표 등록 완료(데이터 생성)
투표하기 → 투표 완료(데이터 업데이트)
이 단순한 플로우를 수행하는 것도 저에게는 여간 어려운 일이 아니었습니다… 등록한 투표에 들어가 후보자를 선택하여 투표하기를 완료했을 때 선택된 후보자의 투표 개수만 카운트를 올리는 것부터 난관이었고, 이 플로우를 하다 보니 동시에 총 투표 개수도 올려줘야 한다는 것을 알게 되어 수정하고… 소위 말해 굉장한 삽질이었죠. 이 과정 중에 생각해 본 적 없지만 테스트를 하다보니 필요한 데이터들을 추가적으로 더 많이 구상하게 되었습니다. 가령 가장 투표 개수를 많이 받은 후보자를 우승자로 나타내는 데이터나, 투표 문서의 id 등이 있었습니다. 최초 설계 이후에도 기능들을 구현하며 기획을 추가 및 조정하는 등 많은 변화가 있었죠.
마치며
이렇게 근본 없이 데이터를 설계하다 보니 우여곡절이 많았는데, 문득 백엔드를 하시는 분들의 설계 구상 방식이 궁금해졌고, 새삼 대단하게 여겨졌습니다..! 저는 단순한 설계에도 너무 오랜 시간을 소요하긴 했지만, 이 과정이 무척 재밌었습니다! 추상적인 나의 생각이 데이터가 되어, 화면에서 변화를 나타내고 데이터베이스에 쌓여 유의미한 결과물을 보여줄 수 있는 재료가 되는 이 흐름의 매력에 빠져버렸습니다! 물론 이 역할만이 다가 아니겠지만, 이 분야에 대해 좀 더 많이 경험하고 더욱 공부하고 싶어지는 계기가 되었습니다.
