두번째 팀 프로젝트로는 촬영 장소 서비스를 제공하는 아워플레이스를 선정했다.
구현하려는 목표는
1. 카카오 소셜 로그인
2. 상품 목록(카테고리, 검색, 정렬)
3. 상품 상세(세부정보와 예약 캘린더)
4. 예약 신청 및 조회 기능이다.

내가 맡은 카카오 소셜 로그인과 예약캘린더,예약 신청 및 조회 기능을 만드는 과정을 되돌아보고 기억하고 싶은 내용을 적어보려한다.

ERD 작성

• 이번에는 dbdiagram.io가 아닌 erdcloud를 사용해 모델링을 해보았다. 테이블 색을 지정할 수 있고 더 직관적인 관계표시가 가능했던 반면에, 내용을 수정하거나 화면을 이동할때 속도가 느리다는 치명적인 단점이 있었다. 이정도 성능으로 서비스를 하고 있을리가 없다는 생각에 방법을 찾아보았지만 해결할 수 없었다. 개인적으로 너무 답답한 수준이었기 때문에 다음번엔 dbdiagram을 다시 사용하거나 새로운 툴을 찾아볼 예정이다.

상품 엔티티

• 서비스 특성상 상품(products)이 곧 장소(places)이다. 상세 페이지에 들어가는 정보를 기준으로 장소 엔티티의 속성을 결정했고 정규화를 통해 초록색 테이블들을 만들었다. 최대한 복잡하게 생각하지않고 기본적인 정규화를 하는 것에 집중했다.

• 장소의 크기, 층수, 주차대수 등은 숫자와 단위로 이루어져 있어서 한번에 저장하기 위해 문자열 타입으로 했다. (ex: 35평 / 116m²). 기능 구현을 해보는 프로젝트여서 그렇게 했지만, 실무에서 해당 데이터를 이런식으로 DB에 저장하진 않을 거 같았다. 데이터를 활용해 각종 통계나 분석을 해야한다면 핵심 데이터인 숫자만 저장해야하지 않을까? 추후 데이터의 활용성을 생각한다면 컬럼이나 테이블이 더 늘어나더라도 감안해야 된다고 생각한다.

주문(예약) 엔티티

• 예약 엔티티의 속성은 홈페이지의 예약 과정과 예약 내역 화면을 참고해 정했다. 예약 기간을 어떻게 표현할 것인지를 가장 많이 고민했었다. 처음엔 시작과 종료시간에 날짜는 넣지 않고 따로 DATE 속성을 만드려고 했지만, 피드백을 통해 시작시간과 종료시간에도 명확한 날짜정보가 들어가게 하는 것으로 정했다.

• 이전 프로젝트의 주문(order)관련 엔티티 모델링을 참고하여 예약상태(book_status) 테이블을 만들기로 했다. 예약별로 상태가 존재할텐데 정규화된 예약상태 테이블과 관계를 지정해주고자 했다.

고객(사용자) 엔티티

• 카카오 소셜 로그인 기능을 구현하기 위해 필요한 부분만 넣기로 했다. 우선 카카오 API 문서를 읽으며 우리가 카카오에서 받을 수 있는 정보의 종류를 확인했다. 카카오 닉네임, 이메일, 프로필 사진 등을 필수동의 정보로 받고, 이메일과 연령대는 선택동의정보로 받는 것으로 했다.

• 모델링 시점부터 받을 수 있는 정보를 확인하고 경우의 수를 생각했기 때문에 Django models.py 작성시 nullabe 옵션을 명확하게 지정할 수 있었다.

---

Django app과 models.py

users app

• 유저의 고유키 구분은 kakao_id를 기준으로 하기로했다. 나머지는 모두 nullabe하게 옵션을 주려고 했는데, 문자열 필드는 null이 아닌 blank 옵션으로 했다. DB는 null과 blank를 명확하게 구분하지만, Django에서 문자열은 nullable 옵션을 지양한다는 내용을 다시 한번 공식 문서로 확인했다.
  심지어 Oracle DB를 사용할땐 null=True 옵션을 주더라도 empty string으로 저장된다고 한다!
  

places

• 개인적으로 on_delete 말고 다양한 ForeignKey 옵션을 사용해보고 싶었는데 이번엔 하지 못했다. 역참조시 이름을 설정하는 related_name이나, 외래키를 nullable하게 해주는 set_null 옵션 등이 있다는 것을 알았다. 다음번엔 필요할때 적재적소에 다른 옵션도 적용해보고 싶다.

books

• 이 부분에서 실수가 있었는데, 원래 기획했던대로 status_code를 외래키로 설정하지 않고 book_status 테이블에서 외래키를 설정해버렸다. 이 부분을 해결하는 과정에서 migration 파일을 자세히보며 많이 배울 수 있었다. models.py에 작성한 class가 migration 파일로 변환이 되어 DB에 적용되는 과정을 볼 수 있었던 소중한 실수였다.

---

DB에 데이터 입력

• 데이터 생성 작업을 팀원과 함께하기위해 google spreadsheets를 활용했고, 저번처럼 db_uploader.py를 작성해 csv파일로 데이터를 db에 입력했다.

• 문서나 파일을 공유하고 공동작업을 하니 생산성이 훨씬 높아졌고 각자의 로컬 DB 데이터 차이를 최소화할 수 있었다. 효율성이 높아지니 MySQL Workbench나 Table plus 툴을 많이 사용하지 않고 터미널로 확인하는 것으로도 충분했다.

---

느낀점

• 이전 프로젝트에서 큰 Blocker 역할을 했던 DB와 모델링 부분이 해소가 되어서 더 빠르게 초기세팅 및 개발에 착수 할 수 있었다. 현업에서는 긴 기간동안 경험많은 시니어들이 모델링을 한다고 하는데, 현재 우리 프로젝트팀의 상황과 목표를 고려해 버릴 것은 버리며 최소한으로 스키마를 설계했다.

• 한편으로는 나 스스로 데이터베이스와 모델링에 굉장히 관심이 많다는 것을 알 수 있었다. 현업의 모델링을 이해하기에는 전문성이 부족하다는 것을 느꼈다. Django 프로젝트를 위한 모델링이 아닌, 실제 서비스를 위한 DB와 모델링에 대해 더 알고싶다. 앞으로는 데이터베이스의 기본적인 개념과 이론 공부를 병행하면서 실제 프로젝트에 적용해봐야겠다.