프로젝트 DUCKS - 세번째 회고

지난 시간에 기능 명세를 정한 후 테이블 설계를 진행했다. 생각했던것보다 훨씬 더 고민해야 되었던 부분이 많았던 것 같다. 우선은 회원과 권한, 커미션, 문의 채팅 메세지, 사진등의 리소스 정도의 테이블만 구상했다. 나름 핵심적인 기능을 담당하는 데이터를 저장하는 테이블이라서 하나하나 정하는데 오랜 시간을 잡아먹었다. 기획 단계가 어렵단 것을 새삼 느끼는 순간이었다.

 

1.어려웠던 점

기술적으로 어중간하게 알고 있었던게 어려웠던 점으로 작용했다. 비즈니스 로직에 쓰이는 테이블은 트랜잭션도 빈번하게 일어나고 이로 인해 테이블락이 걸릴 것을 우려한것 까지는 좋았다. 회원에 대한 권한을 체크할때 spring-security 를 통해서 회원과 권한을 체크하는 것 까지는 좋았다. 문의 메세지는 웹소켓을 이용해 구현하면 되지 않을까 생각하는것 까지는 좋았다. 리소스도 리소스 정보를 저장하는 테이블을 하나 만드는 방향으로 생각하는 것은 좋았다.

 

하지만 어떻게 구현할지 대략정인 방향은 정했을 뿐, 머릿속으로 어떻게 풀어가야 되지? 구조를 어떻게 잡아야하지? 이런 대략적인 흐름은 보이지가 않았다. 3년차인만큼 좀 뭔가 내세울 수 있을만큼의 코드를 내고 싶은 마음때문일까. 생각을 하면 할 수록 더 좋은 방법이 있을 것 같은 느낌이 들었다. 내가 생각하는 이 생각이 과연 옳을까라는 생각도 들을 때 팀원과 회의를 했는데도 마음 한켠에 불안감이 존재했다.

 

2.느낀 점

우선 구현하고자 하는 기능을 명확하게 알아야 겠다는 생각을 하게 되었다. 2주차때 회의를 통해 정한 기능들은 얼추정한거라 같은 기능을 생각했을때 팀원과 내가 생각하는 기능과 구현방법에 대한 간극이 존재했다. 기능이 다르니 테이블도 각자 생각한게 달라서 당초 예상했던 시간 보다 더 오랜시간을 설계에 쏟은것 같다. 

 

테이블 설계전략에 대해서도 생각하게 되었다. MSA에서 RDB를 사용하자니, 각 서비스에서 회원과 같은 공통적인 데이터들은 어떻게 관리를 하면 좋을까와 같은 여태 한번도 하지 않은 고민을 해볼 수 있었다. chatGPT님께 여쭤봤더니 MSA에서는 공통 유니크 칼럼을 사용하는 것도 장점이 있다고 한다. kafka와 같은 메세지 브로커를 사용한 비동기식 이벤트를 주고 받는 경우에는 공통 유니크 칼럼(global id와 같은 이름이라고 앞으로 부르겠다.)을 사용하면 global_id 를 가지고 특정한 리소스를 특정하는 것도 가능하다고 한다. 또 다른 기능마다 서비스가 있는 MSA특징상 JOIN을 하기 힘든데, global_id가 있으면 JOIN을 하지 않고도 외부서비스에서 쉽게 데이터를 연결할 수 있다고 한다. 한편으로 UUID 와 같은 랜덤하게 PK를 주는 경우에는 DB 성능에 부담이 가고, 특히 INNO DB는 특히 그럴 가능성이 많다고 한다. 

 

3.앞으로 해야할 일

일단 다음차시까지 ERD를 그리고 프로젝트 기본 세팅을 해야한다.  추가로 테이블 구성을 어떻게 해야할지 더 생각을 해봐야 한다. 그리고 미리미리 nosql도 공부를 해야할 것 같다. RDB 기준으로 테이블을 설계한 상태인데, nosql 쪽에 저장을 하는 데이터가 어떤것인지 알 수 있다면 RDB에 걸리는 부하가 조금은 줄어들지 않을까 싶다.  또 DB 생성 전략을 알아봐야겠다. 공부할 필요성을 느끼지 못해서 관심이 없어일까 생각보다 모르는 내용이 너무 많다.