[Spring/클론 코딩] todo mate를 따라 만들어보자(1) - IA와 데이터베이스 ERD 설계
jimddong
2025. 1. 24. 23:12
반년간 교환학생을 다녀온 뒤, 개발에 대한 감각이 많이 무뎌진 것 같다고 스스로 느끼곤 했다.
앞으로 무얼해야할까 고민하다 혼자서 웹/앱 서비스를 구현해보는 건 어떨지 고민하게 되었다. 처음에는 아예 새로운 서비스를 구현해보고자 하는 마음에 우선 내 아이디어에서 시작해보았다.
내가 좋아하고, 만들고 싶었던 걸 떠올리다 나온 것은 '내가 좋아하는 다이어리 꾸미기(다꾸)를 웹이나 앱으로 만들어보자!'었다. 매일 쓴 일기에 그 주변을 꾸미고, 월간 캘린더, 거기다 내가 구현해보고팠던 채팅 기능까지(웹소켓을 공부해보고 싶었기 때문...) 넣으면 어떨지 생각해보았다. 그런데 자꾸만 어쩐지 겹쳐지는 투두 메이트의 잔상...
사실 난 투두 메이트를 굉장히 애용하는 사람이다. 그만큼 내가 투두를 이용하면서 느낀 아쉬운 점도 많았다. 내가 개발자라면.. 이 기능도 괜찮을 것 같은데? 하며 말이다 (ㅋㅋ) 기존의 투두 메이트는 이름 그대로 'mate'에 집중하여 사람들과 소통할 수 있는, 그리고 다른 친구들이 하루 하루 그리고 한 달 동안 성취해내는 체크 리스트를 보면서 나도 자극 받고 열의를 다질 수 있는 어플이라 느꼈다. 하지만 나는 다꾸러(아직 파릇파릇한 다꾸 어린이 수준이지만...)로서 다이어리 꾸미기나 기록에도 집중한 나만의 투두 메이트를 만들어 보고 싶었다 ㅎㅎ
생각했던 추가 기능은 일기나 그 날의 할 일에 자신이 원하는 위치를 넣게끔 하는 기능을 추가하면 어떨지(약속 등은 시간뿐만 아니라 장소도 기록해두면 기억하기 편하니까), 단체 채팅방도 추가하면 어떨지 등등... 또한 가능하다면 다꾸할 수 있게끔 스티커들도 추가해본다든지..였다!
아이디어가 여기 저기 떠돌아다니지만 우선 투두 메이트를 클론 코딩하며 무뎌진 나의 개발 감각을 일깨워보려한다! 그리고 원했던 기능들도 추가할 것이다. 또한 사실 서버 구현말고도 리액트로 웹앱 등까지 욕심 내보고 싶다. 서버 개발자가 되기를 원하지만 프론트 쪽을 너무 몰라도 문제인 것 같다고 부쩍 느끼고 있기 때문... 서버에는 내가 서툰, 안 써본 기술들을 적용해보기도 하고 좀 더 코드를 고민하며 짜보려 한다. 여튼 그만큼 꽤 힘들 것 같기도 하지만, 힘든 만큼 성장할 수 있다 생각하고 최선을 다해 임해보려 한다!
잔말 말고 시작!
IA
개발하기에 앞서 내가 생각한 나만의 투두메이트 IA(Information Architecture)를 그려봤다.
(검색 기능에 친구 그룹을 찾는다든지 하는 다양한 기능들도 있었지만, 나는 친구 아이디로 조회하는 기능만 우선 넣을 것이다.)
그리고 위 목록들은 내가 구현할 수 있는 기능들로 정리해보았다. 사실 기존 투두에서는 내가 적은 할 일 리스트나 일기를 나만 보게 하거나 특정 팔로워에게만 보이게 설정할 수 있다. 하지만 우선적으로는 모두에게 보이게끔 권한을 설정하려한다. (나에겐 일단 꽤나 어려울 것 같음...)
데이터베이스 ERD
StarUML 사용
그리고 나서는 IA와 투두 메이트 화면을 와이어프레임 삼아 고민해보며 데이터베이스 erd를 설계했다.
ex. 멤버 1이 멤버 2를 팔로우한다. ⇒ follower_id는 멤버 1의 id, followed_id는 멤버 2의 id 예를 들어, 멤버 10명이 한 명당 5명을 팔로우 했을 때에는 50개의 Follow 객체가 생기는 것이다. (여기서 서로 맞팔로우를 한다면 100개)
멤버 및 팔로우 엔티티
기타 또 고민한 문제들, 그리고 하나하나 생각해보며 어떤 방법이 나을지 정리했다.
🚨 멤버 조회 시 팔로워 수와 팔로잉 수를 프로필에서 나타내기
투두에는 마이페이지에서 자신의 팔로워 수와 팔로잉 수를 확인할 수 있다. 이 수를 어떻게 조회하고 보여줘야할지 고민했다.
실시간으로 계산해서 보여주기 => 데이터 많아지면 느려질 수도 있음.
특정 멤버의 팔로워 수는 followed_id가 해당 멤버의 id인 Follow 객체의 수를 count 하면 됨.
반대로 팔로잉 수는 follower_id가 해당 멤버의 id인 Follow 객체 수를 센다.
미리 저장 (Member 속성으로 follower_count, following_count 두기) - 관계 변경 시 마다 member 업데이트하기
이 방법 중에서 고민해봤는데, 우선 데이터를 많이 넣지는 않을 것이니 1번으로 구현할 예정이다.
🚨 채팅방 구현
단체 채팅방까지 구현하고 싶어 이것 저것 생각해보았다.
우선,
한 멤버는 여러 채팅방에 들어갈 수 있다.
또한 한 채팅방에는 여러 멤버가 참여할 수 있다.
⇒ 이는 다대다 관계이므로, 이를 일대다 테이블로 풀어주기 위해 중간 테이블을 추가했다.
추가적으로 했던 고민... 💭 채팅 기능 구현에 웹소켓을 쓸 것인데 메시지 엔티티를 추가해야할까? A. Yes! - 웹소켓은 실시간 메시지 소통에 효과적, 하지만 메시지를 영구 저장하지는 않는다. - 메시지를 저장해서 나중에 또 조회하려면 Message 테이블 필요함.
Message 엔티티
메시지를 누가 보냈는지 확인하기 위해, 메시지 엔티티에서 채팅방 아이디와 멤버 아이디를 같이 외래키로 두어야하는지 처음에 고민했었다. 하지만 생각해보니 이건 아니었음..! 이유는 아래와 같다.
누가, 어느 채팅방에서 보냈는지 조회하는 방법
member_id와 chatroom_id 가져오기(FK) - 다대다 관계를 다시 정의(중복 정의)하는 것과 비슷 - member_id와 chatroom_id 조합이 있는지 message 테이블에서 찾아봐아하는 추가 로직 필요 ⇒ 매번 확인 시 비효율적, 무결성 유지⬇️
member_chatroom_id를 가져오기(FK) - 간결, 무결성 유지🙆🏻♀️
채팅방 구현 관련 erd
+. 메시지를 보낸 날짜, 시각은 created_at 속성 활용할 것이다.
실제 우리가 이용하고 있는 서비스에서 제공하는 기능들은 가만 보면 다 개발자들이 고심하고 고심해서 설정한 것이란 것..!
몸소 깨달을 수 있었다. 위 erd는 점차 코드를 짜다보면 달라지기도 할 것이다. 얼른 엔티티 코드를 작성해봐야겠다!
