#2_모델링 이렇게 해도 되나?

혼돈의 모델링

기존 커머스는 유저가 있고, 카테고리가 있고, 상품이 있고, 장바구니, 주문, 등등으로 나누면 되었는데 매칭 서비스의 경우 기존 커머스 DB 구조와는 맞지 않았다.(테이블은 적지만 더 복잡해진 느낌?)

 

가장 큰 차이점은 두 가지였다.

 

하나는 유저와 관련된 정보가 매우 많다는 것이고(사용자의 취향을 모두 저장하므로)

다른 하나는 유저가 곧 상품이라는 것이다. (사람을 '상품'취급하는 것이 이상해 보일 수도 있지만 사람과 사람을 이어주는 것이므로 그런 의미로 서로 받아주시면 감사하겠다)

 

우리는 우선 유저의 회원가입정보와 함께 가입 시 유저가 작성한 취향 정보도 모두 하나의 테이블에 넣었다.(이때의 결정이 이후 디비를 갈아엎는 원흉이 되었다.) 그리고 중복선택이 가능한 항목들은 모두 다대다 테이블로 이었다.

 

추가로 만남 요청 기능을 만들 예정이었기 때문에 관련 테이블을 추가하였다. 성별과 mbti는 정규화를 위해 따로 빼두어 유저와 1대다 구조로 만들었다. 그렇게 만든 초기 모델링은 아래와 같다.

 

 

모델링을 하면서 가장 어려웠던 점은 '이렇게 해도 되나?'라는 의구심이었다. 유저들이 작성한 서베이 항목들을 모두 정규화하여 관리해야 하는지 아니면 유저 한 테이블에 모두 관리해야 하는지, 무엇이 효율적인지 가늠하기가 어려웠다.

 

모두 정규화를 한다면 유저 테이블은 가벼워지겠지만 뷰 로직을 짜는데 골치가 아파질 것 같았다. 이번 경험을 통해 모델링에는 정답이 없다는 생각이 들었다.

 

 

 

이대로면 우리 모두 가입을 못해..!

결국 문제가 터졌다. 우리는 소셜 로그인 기능을 활용하여 회원가입을 하고 가입 즉시 서베이, 즉 개인의 술 취향을 입력하도록 진행하였는데, 생각해보니 서베이는 회원가입 이후에야 진행할 수 있음을 알게 되었다. 이것이 왜 문제냐면 기존에 유저 테이블의 항목은 모두 필수 값이기 때문에 서베이를 입력하지 않으면 유저 테이블에 들어올 수 없다. 즉, 소셜 로그인은 가능한데 회원가입이 불가능한 상태가 된 것이다.(???)

 

회원가입과 서베이를 하나의 테이블로 묶은 것이 이번 모델링의 가장 큰 실수였다. 나는 이 문제를 팀원들에게 공유하고 부랴부랴 모델링을 수정하였다. 우선 유저 테이블을 분리하여 회원가입이 가능하도록 바꾸었고, 기존 서베이 항목들은 서베이라는 테이블을 만들어 따로 관리하도록 만들었다.

 

테이블을 분리하고 이름이 바뀌면서 기존 다대다 항목들의 중간 테이블 명도, 칼럼 명도 모두 수정해야 했다. 후다닥 수정을 마친 우리는 바로 PR을 올렸고 문제 발견 후 몇 시간 안에 디비 구조를 올바르게 바꿀 수 있게 되었다.

 

그렇게 수정한 모델링 구조는 다음과 같다.

중간에 중복체크 항목 중 하나가 빠져 다대다 테이블이 줄었고 서베이와 유저테이블이 분리된 최종적인 형태가 되었다.

 

 

 

마무리

이번 일로 느낀 점은 처음 모델링 설계가 굉장히 중요하다는 것이고 유저가 서비스를 이용하는 첫 시점부터 그다음 액션들을 유기적으로 살펴봐야 한다는 것이었다. 막연한 느낌으로 모델링을 한다면 이후 이를 수정하고 고치는데 더 많은 시간을 할애할 수도 있겠다는 생각이 들었다.

 

이번 실수로 모델링에 대한 시야가 좀 더 넓어진 것 같고, 무엇보다 다행스러운 점은 뷰를 작성하기 전에 문제를 발견하여 그나마 수고를 덜었다는 점이다.

 

그리고 좋았던 점은 이런 모델링 실수도 '다시 바로 잡을 수 있다는 것'과 '어떻게 바로 잡을 수 있는지' 이번 실수를 통해 배울 수 있었던 점이다. 이런 과정이 내게는 성취와 재미로 다가왔다.