모캠 History - 모캠리뉴얼 #1 데이터베이스 설계

오늘의 주제

오.늘.은. 모캠 리뉴얼 중에서도 가장 고통스러웠던 부분! 데이터베이스 재설계를 진행하며 겪었던 내용에 대해서 포스팅을 하려합니다. 기존에는 어떤게 되어있었고, 리뉴얼하면서 어떻게 변경되었는지! 알아보면서 그때는 생각하지 못했던 빠트린 점이 뭐가 있나... 고민해보는 시간을 갖도록 하겠습니다 :)

 

 

강의..어떻게 관리하면 좋을까?

물론 가장 큰 변경점은 데이터베이스 설계 부분입니다. 모두의캠퍼스에는 "학교-학과-교수-수업" 이라는 4개의 큰 카테고리가 연결되어 있습니다. 리뉴얼 전 설계된 데이터는 각 항목에 대해서 관계가 크게 작용하지 않습니다. 일반적으로 생각했을때 대학교라는 큰 틀안에 각 학과 혹은 단과대가 존재하고 속에 학과나 단과대가 존재하며, 그 안에는 교수의 정보, 각각의 교수 마다 담당하고 있는 수업인 존재하기 마련인데 RDB를 사용함에도 불구하고 카테고리간 관계가 정립되어 있지 않기 때문에 이 항목들의 관계를 재정의 하는 것, 그리고 추후에 추가될 기능에 대한 확장성을 리뉴얼 설계의 핵심으로 두고 진행하였습니다.

 

 

기존의 설계와 바뀐 설계에 대해서 간략하게 표를 만들어보면 다음과 같습니다.

변경 전

▽

▽

▽

데이터관리를 좀 더 추후에 유용하게 그리고 깔끔하게 관리하기 위하여 학교,학과,교수,수업 각각의 테이블로 전부 분리를 진행하였습니다. 

 

 

회원관리를 좀 더 명확하게

트레픽기반 서비스에서 가장 중요한 부분이라고 생각했다. 기존의 회원이 리뉴얼 된 서비스를 이용함에 있어서 불편을 느끼지 않도록 하는게 중요한 것 같다. 기존 서비스의 회원가입은 이메일과 SNS를 함께 사용하였지만, 과감하게 이메일 회원가입을 제거하지만 기존의 이메일 가입 유저는 서비스를 지속해서 사용할 수 있도록 계획하여 진행하였다. 회원 정보와 로그인 관리를 위해 두 종류의 토큰을 연결하여 사용하였고(OAuth와 같은 구조) 다중기기 로그인과 기기간 세션 동기화에 대한 문제를 고려하여 설계 하였다.

 

 

고민을 통해 설계된 회원관련 테이블 구조는 다음과 같다.

변경 전

▽

▽

▽

변경 후

하나의 테이블에서 통합 된 회원정보를 관리하던 구조에서, 역할에 따라 정보를 담을 수 있는 테이블 구조로 변경하였다 한명의 회원은 총 세개의 기기에서 로그인 및 서비스 이용이 가능하며 로그인 유지는 마지막으로 접속한 기기에서만 유지 될 수있도록 설계 및 개발을 진행하였습니다. 회원의 세션관리를 위해 JWT와 브라우저의 로컬스토리지를 이용하였고, 기기별 세션 동기화에 대해서는 Redis를 이용하여 동기화를 유지 할 수 있도록 하였습니다.

 

 

 

포인트 관리 어디까지 해야하지?

기존 서비스는 회원들에게 무제한에 가까운 서비스 이용을 제공하였다. 리뉴얼을 진행하면서 사용자의 좀 더 자발적인 자료 업로드를 이끌어 내고자 포인트 제도를 도입하였다. 간단하게 자료 업로드시 사용자는 포인트를 획득할 수 있고, 원하는 자료를 열람 및 다운로드시 포인트가 차감되는 형태이다. 직접적으로 cash와 관련된 내용은 아니었지만, 아무래도 서비스를 이용하는데 있어 포인트가 직결되기 때문에 포인트 생성과 소멸시 발생하는 로그성 데이터를 어느정도 수준까지 저장할지 고민하였고, 포인트 정책을 간단하게 관리 할 수 있는 방법에 대해서도 고민하게 되었다.

 

포인트와 관련해서 개발되어야 하는 기능은 위에서 말한 포인트를 통한 구매 그리고 구매한 자료에 대한 무료열람 특정 기능 수행시 자동으로 포인트가 발급되는 정도의 기능이었고 포인트 획득내역이나 사용내역에 대해서는 사용자가 따로 열람할 공간이 존재하지는 않았다. 전체적으로 포인트 사용과 획득에 대해서는 로그성 테이블을 통해 관리하였고, 각각의 기능별로 발생하는 히스토리에 대해서는 또 다른 테이블을 통해 데이터를 보관하였다. 같은 로직을 통해 반복되는 작업과 로그성 데이터를 생성하는 부분이 많았기에 프로시저를 이용하여 작동이 되도록 개발하였다.

 

사실, 프로시저를 사용하는 부분에 있어서도 사용유무에 대한 고민을 참 많이했다. 로그성 데이터라고 적긴 했지만 연산에 대해서도 조금의 과정이 있기 때문에(데이터베이스의 연산과정이 성능에 굉장히 치명적이라는 얘기를 들은적 있었기 때문에..?) 데이터베이스 성능 저하를 일으킬 여지가 분명이 있다고 판단하긴 하였지만.. 일단은 가장 큰 목적은 로그성 데이터를 축적하는 부분이었기 때문에 그냥 사용하기로 결정했다.

 

이렇게 기존에 있던 데이터베이스를 전부 재설계하고(뭐 별거 아닌거 같지만 위에 두 기능은 서비스의 전부라고 해도 과언이 아니다. 물론 서비스의 기능도 저 위의 두 개가 전부는 아니다) 좀 엉성하게 잡힌 기획에 대해서는 회의를 통해 의견공유를 더 하고난 후에 개발을 시작하게 되었다.