MarbleUs Project #1 기능 정의 및 테이블 설계

table of contents

1. 프로젝트 소개

2. 사용자 기능 정의서

3. 테이블 설계

Week#1

1. 프로젝트 소개

현실판 부루마블 게임을 기반으로 하는 여행 게시판.
주사위를 굴려 랜덤하게 도착하는 한국의 주요 도시 및 지역들을 여행을 조금더 풍요롭게해 줄 미션을 수행하며 실제로 여행하고 이를 해당 도시게시판에 블로깅하는 게임적인 요소가 가미된 여행 커뮤니티 게시판을 기획하였다.

해당 서비스는 크게 두가지로 구성된다.
첫째, 게임부. 게임부는 유저가 실제로 여행을 계획하는 단계에서 주사위를 굴리고 그 눈만큼을 유저의 캐릭터가 이동하게 되고 도착한 도시에서 미션을 수행하며 실제 여행을 다녀오고 이를 블로깅을 통해 인증한다면 리워드로 스탬프를 받고 다음 도시를 여행하기 위해 주사위를 굴린다. 캐릭터가 한바퀴를 돌게되면 레벨이 1 상승한다. 만약 같은 도시를 또 방문하게 된다면 유저는 두가지 선택을 할 수 있다. 1. 주사위를 다시 굴려 다른 지역을 여행하기, 2. 해당 도시를 새로운 레벨2의 미션을 수행하며 다시 여행하기.

둘째, 커뮤니티 게시판. 유저가 게임을 굳이 플레이하지 않더라도 해당 서비스는 여행 커뮤니티 게시판으로서 그역할을 지속한다. 해당 게임보드에 존재하는 도시 및 도들은 해당 여행 리뷰들을 게시한 게시판의 역할을 하고 유저들은 태그를 바탕으로 경험과 재미를 공유하는 커뮤니티 활동을 지속할 수 있다.

2. 사용자 기능 정의

1. Bare Minimun(기본 필수 기능)

• 인증 및 보안

  • Jwt 토큰 인증 방식: 회원가입/로그인을 통해 서버는 Access&Refresh 토큰을 발급하고 이를 통해 로그인 인증을 수행한다.
  • OAuth2.0 기반 Google로그인 지원
  • 로그인/비로그인의 권한 분리: 로그인 사용자: 마이페이지, 블로깅 / 비로그인 사용자: 주사위 굴리기 및 도착도시와 미션내용 확인만 가능(회원가입을 유도하기 위함)
  • https 프로토콜 적용

• 공통 기능

  • 인기글 정렬: 게시글의 조회수에 따라 페이지네이션처리 후 정렬
  • 데이터 초기화: 각 DB의 데이터를 일괄 삭제
  • 데이터 전체 초기화: 모든 DB데이터 초기화
  • 게시물 조회수 카운트
  • 예외처리: 예외 발생시 메세지를 유저 친화적으로 정리
  • 작성/수정시간 기록: 데이터의 생성 수정 시간 기록

• 맴버쉽

  • 회원 가입/탈퇴
  • 회원 프로필 이미지 등록
  • 회원간의 프로필 조회
  • 닉네임 자동 생성 후 수정 가능

• 메인 게임부

  • 공통기능:
    - 주사위 굴리기
    - 도시별/맴버별 랜덤 미션 배정
    - 랜덤여행 결과 공유
    • 회원기능:
      - 마이페이지
      - 게시물 열람

• 게시판

  • 도시 게시판:
    - 도시 여행후 블로깅:
    에디터 사용 이미지 및 파일 업로드
    - 태그를 이용한 카테고리별 정렬
    - 날씨정보
    - 작성된 블로그 상세 페이지 보기
    - 블로그 작성/수정/삭제
    - 북마크 기능
    - 작성된 블로그 댓글 작성/조회/수정/삭제
    

• 마이페이지(여권)

  • 필수 기능
    - 회원 정보 조회
    - 회원 정보 수정
    - 책갈피 클릭 시 페이지 이동
    - 내가 쓴 후기 조회
    - 내가 쓴 후기 삭제
    - 내 북마크 조회
    - 내 북마크 삭제
    - 유저 팔로우 조회
    - 유저 팔로우 추가
    - 유저 팔로우 삭제
    -팔로우 수/팔로워 수 조회

3. 테이블 설계

설명 및 회고

설계가 무엇보다 어렵고 중요하다는걸 많이 깨달았다. 특히 백앤드 프로그래머로써 테이블 설계가 얼마나 중요한지 느꼈다. 테이블 설계에 있어 가장 중점을 두었던 점은 최대한 수정과 업데이트에 용이하도록 만드는 것 그리고 내부 쿼리수를 최대한 줄이는 설계가 핵심이었다.

예를들어, city게시판을 만드는데 있어 각각의 도시 게시판을 만들고 블로그들을 콜럼으로 관리할 것인가 아니면 도시게시판 자체도 컬럼으로 관리할 것인가가 첫번째 난관이였다. 전자의 경우에는 조인되는 추가 쿼리를 줄이고 블로그의 수가 많아지는 경우를 대비할 수 있다는 장점이 있다는 생각이 들었지만 단점이 명확해 보여 후자를 선택하였다. 단점으로는 블로그만 분리해서 쿼리를 할 수 없어 불필요한 네트워크 비용을 발생시킬 수 있다는 생각을 했다(다양한 쿼리를 발생시켜야 하는데 복잡성이 올라서 속도 저하를 초래할 수 있다).

또는 미션 부분에서 각각의 도시의 특수한 미션들과 공통된 미션, 두가지 성질을 가진 미션들이 있는데 이를 어떻게 관리할 것인가. 처음에는 mission과 special_mission 두가지로 테이블을 나누고 공통미션은 시티와 조인테이블을 만들어 매핑하여 다양한 도시에서 공통된 미션을 사용 할 수 있게 하고 일대다의 형태로 시티와 special_mission을 묶어 special_mission이 시티에 고정값으로 종속되도록 설계하였으나 거의 비슷한 내용의 두 미션테이블이 쓸데없는 복잡성을 나았고 결국 이또한 성능 저하로 이어질 가능성이 대두되었다. 따라서, 미션을 모두 공통으로 두고 타입을 이넘으로 관리하며 부여하여 이 두가지 미션의 역할을 모두 충족시킬 수 있도록 하였다.

또한 이미지 또한 처음에는 member_image와 blog_image의 두 조인테이블을 만들어 분류하기 쉽게 관리하고자 하였는데 이 또한 불필요한 쿼리 수의 증가로 이어짐을 발견하여 이미지에 맴버와 블로그의 Nullable한 Fk를 두어(매핑하여) 관리하는 식으로 변경하였다.