⌨️ ERD 설계 회고
우리가 가장 힘들어했던 ERD 설계에서의 회고를 한번 해보려 한다. 이번에도 기술적인 것보단, 익숙지 않은 것들에 대한 어려움이 큰 부분을 차지했었다.
1. ERD
우선 ERD 다이어그램에서 볼 수 있듯이 우리의 프로젝트는 부트캠프에서 한 달이 채 안 되는 시간에 완성도를 높이기엔 힘든 크기였다고 생각한다. (더 고도화의 단계까지 바라본다면)
1.1. ERD 단계에서의 마찰
ERD를 설계할 때면 항상 마찰이 있었다. 물론 이것이 감정적으로 치고받고 하는 것이 아니라 긍정적인 토론인 점은 참 다행이다.
연관관계를 매핑한다거나 이럴 때는 크게 문제가 없다.
문제 상황은
1. 조인테이블 생성 및 관리 측면에서의 중복 테이블 생성
2. 정규화 원칙을 철저히 지키자 <-> 개발을 떠나 서비스 측면에서는 어느 정도의 반정규화가 필요하다
3. 칼럼을 계산해서 셀렉트 <-> 계산 값을 저장해 둔 것을 셀렉트
같은 경우였고
우리의 경우 늘 해결이 안 되는 문제가 생긴 부분이 좋아요(추천 etc., 좋아요 류들..)를 구현하는 것이었다.
나머지는 대립이 발생해도 어느 한쪽으로 의견이 기울었으나 위의 사례에서는 첨예하게 대립했기에 위 사례를 가지고 복기해보려 한다.
1.2. 좋아요 구현
뜬금없이 ERD에 대한 회고를 하다가 웬 좋아요 구현?이라고 생각할 수 있다.
우리가 진행하는 프로젝트에서는 유동적으로 로직에 따라 ERD를 변경하기도 했으나, 일반적인 경우라면 ERD에 따라 로직을 구현할 것이라 생각이 든다. 따라서 ERD의 구조에 따라 이 좋아요는 완전히 다르게 로직이 짜인다.
a) ElementCollection을 활용한 좋아요 구현
우선 내가 생각해 본 좋아요의 구현이다.
약식으로 구현했지만 설명하자면 이렇다.
하나의 리뷰에 하나의 좋아요라는 공간이 열린다. 거기에 여러 사람들이 좋아요를 누르면 누른 사람을 그 공간에 담아서 숫자를 세서 저장해 두는 것이다.
따라서 ERD만 봐도 좋아요를 보여주려는 로직은 ReviewLike 테이블의 like_num을 셀렉트 하면 되는 것이 한눈에 보인다.
좋아요를 여러 번 누르는 것을 방지하는 로직 또한 ReviewLike_User에서 user_id를 판단하여 존재한다면 지우고 없다면 저장하고 식으로 구현하는 것이 가능하다.
하지만 이 방식은 우리 팀원들끼리의 의견을 나눌 때 DB에 너무 많은 무리를 준다고 이야기를 했다. 지속적으로 DB에 read와 delete가 발생하기 때문이다.
b) 복합키를 활용한 좋아요 구현
역시 회고는 바로바로 하는 것이 좋긴 하다.. 기억이 잘 나지 않긴 하는데 아래와 같은 느낌이었다.
이거는 이제 리뷰와 유저에서 FK를 받아 복합키로 좋아요를 생성하자는 의견이었다.
그리고 이제 좋아요의 수는 ReviewLike를 Count 하자는 내용이었다.
아쉽게도 이거는 서버에 무리를 주는 방식이라고 설명을 해줬으나, 온전히 이해는 하지 못했었다.
이것에 대한 나의 반박은 이랬다.
좋아요의 개수가 몇만 개 단위로 올라가면 카운트하는데 너무 오랜 시간이 걸리지 않을까요?
그리고 매번 카운트에 연산 리소스를 쓴다면 서버에 너무 무리가 갈 것 같습니다.
하지만 어느 방법으로도 좋아요가 구현이 가능했기에 우리는 우선 이미 구현한 것을 따로 바꾸지는 않기로 했었다.
2. ERD는 역시 중요하다
2.1. 개발 프로세스 전반에 영향을 끼친다.
위에서 뜬금없이 좋아요 구현으로 빠진 것 같지만 사실 이 얘기를 하고 싶었다.
ERD가 어떻게 구현되었는지에 따라 개발 전반에 많은 영향을 끼치는 것 같다.
NoSQL에서는 어떨지 모르겠지만, 적어도 RDBMS에서의 로직은 ERD를 벗어난 로직을 구현할 수 없다.
테이블이 없는데 갑자기 내가 원하는 것을 선택해서 아주아주 핏 하게 효과적으로 값을 뽑을 수 없다는 말이다.
필연적으로 테이블이 존재하고, 서로의 연관 관계를 통해 타고 타고 들어가서 접근해서 값을 가져올 수밖에 없다.
바꿔 말하면 ERD가 잘 설계되어있다면 가볍고 심플한 로직으로도 원하는 결과에 도달할 수 있을 것이고,
아니라면 종착지까지 도달하는 데에 많은 노고가 들 것이란 생각이다.
그래서 항상 느끼지만 ERD 설계에서는 충분히, 넘칠 정도로 많은 시간을 두어 고민을 하는 것이 좋다고 생각된다.
3. 피드백
- ERD 회고 자체에 대해 조금 더 꼼꼼히 생각해 보기 -> 내용이 내가 고민했던 것에 비해 너무 적게 나왔음.. 기억을 짜내보자
- 장단점의 대한 결과가 없다. 좋아요 구현 a, b안에 대한 어느 정도 러프한 장단점은 구두로 이야기하고 넘어갔지만 실제로 수치화된 데이터가 없다. 어떻게 수치화 할지..? 이런 부분들에 대한 성능 테스트는 어떻게 진행해야 할 지 알아보기
- 충분한 고민과 근거를 가지고 결과를 도출했으나, 증빙이 없다 증빙을 조금 더 구체적으로 제시해서 결과에 대한 신빙성을 길러주자
