하루스터디 데이터베이스 설계 과정 및 느낀 점

2차 스프린트 및 MVP 기획이 드디어 끝이 났고, 이에 따라 저희 팀은 데이터베이스 및 엔티티 설계를 시작하게 되었습니다. 이번 글을 통해 하루스터디의 데이터베이스 설계 과정을 기록하고자 합니다. 데이터베이스 설계는 처음이었지만, 유의미한 경험들을 많이 했다는 생각이 들었기 때문입니다! 😀
 

요구사항에서 데이터 추출

사실 저는 이렇게 규모가 있는 프로젝트에서 데이터베이스 설계를 해본 적이 없습니다. 이전 레벨 1, 레벨 2 미션들에서는 테이블을 먼저 설계하지 않고 도메인 객체를 먼저 설계했는데, 큰 규모의 프로젝트에서는 이러한 시도를 하기보다는 전통적인 Layered Architecture를 따르는 편이 나을 것 같았습니다. 그래서 이런저런 레퍼런스를 찾아보게 되었고, 해당 과정에서 '요구사항에서 키워드를 추출해라' 라는 내용을 알게 되었습니다. 
 
처음에는 '왜 데이터베이스의 설계가 현실 세계의 키워드에서 비롯되어야 하는지?' 에 대해 고민했으나, 조금만 생각해보니 답을 찾을 수 있었습니다. 현실 세계의 구조가 안정적이기 때문입니다. 그리고 이는 객체지향 설계가 현실 세계의 구조를 '기반'으로 하는 이유와 동일합니다.
 
아무튼 이러한 논리를 기반으로 요구사항에서 키워드를 먼저 도출해보기로 결정했고, 다음과 같은 키워드들이 나왔습니다.

요구사항에서 도출된 키워드

 

설계는 비즈니스를 중심으로

이렇게 도출된 키워드(데이터)들을 기반으로 ERD를 설계하기 시작했는데요, 처음에는 단순히 연관된 데이터라면 하나의 테이블에 묶었습니다. 예를 들어서 사용자와 관련된 정보(스터디 상태, 현재 사이클 수, 닉네임)이라면 모두 하나의 테이블로 설계했습니다.
 
하지만 이 과정에서 팀원들과 '이 데이터는 자주 바뀌는데... 이 데이터들과 있어도 괜찮을까?', '이 데이터는 확장의 여지가 있는데, 이렇게 설계해도 괜찮을까?' 등과 같은 고민을 하기 시작했습니다. 비즈니스 관점으로 테이블을 바라보기 시작한 것입니다.
 
하루스터디의 경우 이후에 스터디 템플릿을 여러 개 제공할 예정인데, 현재는 pomodoro 방식의 스터디 템플릿만 제공합니다. 하지만 이런 구조를 그대로 데이터베이스 ERD로 차용한다면 문제가 생길 여지가 충분했습니다. 추후 템플릿이 추가되는 경우 테이블 구조가 완전히 바뀌어야 하기 때문입니다. 따라서 pomodoro 테이블과 study 테이블을 슈퍼타입 - 서브타입 관계로 변경했습니다. 비슷한 논리로 스터디에 참여하는 스터디원의 정보도 슈퍼타입 - 서브타입으로 변경했고, 실제 ERD는 다음과 같습니다.

초기 ERD

 

비즈니스 관점을 반영한 ERD

비즈니스적으로 변경될 수 있는 지점들을 고려했기 때문에 위 구조를 차용하면 추후 확장에 쉽게 대응할 수 있습니다. 스터디 템플릿 종류가 추가되어도 단순히 study의 PK를 외래키 참조하는 테이블만 하나 만들면 됩니다.
 

느낀 점

이번 설계 과정을 통해 '데이터베이스 설계 역시 비즈니스를 중심으로 모델링되어야 한다' 라는 생각이 깊게 박히게 되었던 것 같습니다. 하지만 아직 성능을 고려하지 않았기 때문에 테이블의 구조가 어떻게 바뀔진 또 모르겠습니다. 비즈니스 관점으로만 바라보면 위 테이블 구조는 괜찮지만, 쿼리를 적극 고려하지는 않았기 때문입니다.
 
성능 문제를 맞이하는 시점이 오면 또 다른 구조로 풀어내야겠죠 😅 결국 좋은 데이터베이스 구조는 1. 변경에 유연하게 대처하면서도, 2. 성능까지 가져갈 수 있는 구조인 것 같다는 생각이 드는데 어떻게 이런 구조를 가져갈 수 있을지 조금 더 공부를 해봐야겠습니다.