드디어 고대하고 기대하며, 동시에 수 많은 걱정을 안은 채로 생애 첫 개발 프로젝트가 시작되었다. 100일도 안 지난 백엔드 꼬맹이가 과연 얼마나 해낼 수 있을까 싶은 생각을 떨칠 수가 없다.

1. 모델링(feat. Meeting, 미팅, meeTing...)

while(true)
	{printf("Meeting");}
return 0;

1) 마켓컬리

• 팀의 클론 대상은 마켓컬리. 식자재를 포함한 다양한 식품을 판매하는 commcial site.
• 우리는 미팅을 통해 많은 카테고리 중에서 '채소'를, 그리고 채소를 포함한 대분류 항목 4종류와 중분류 각 3종류씩을 목표로 정함

2) 모델링 ver 1.0

• 백엔드 회의에서는 모델링을 하면서 기능을 어디까지 구현할 것인가가 논점이었다.
• 우리는 시간과 각자의 실력을 고려하여, 각자 지난 과제를 통해 구현했었던 기능 1,2가지와 해보지 못했던(하고 싶은) 기능을 1가지씩 맡아서 구현해보기로 했다.
• 초기 모델링을 보자면, 장바구니 기능을 하는 cart가 있고, cart는 users와 products을 모두 참조하는 junction table 역할을 함과 동시에 제품 수량을 조절하는 기능이 추가된다.
• 주문현황(order)과 주문내역서(order_list) 테이블을 만들었는데, 이 부분은 쉽게 이해가 가지 않아서 멘토님의 리뷰를 받기로 했다.
• order 에 추가 될 배송상태(status) 기능을 추가 할 예정이다.

3) 모델링 ver 1.5

• 대분류인 menu 테이블을 추가했고, 테이블 관계에 따라 좀 더 설명이 쉽게(우리가 이해해가 쉽게) 배치를 조금 수정했다.
• order_list 도 유저의 로그인이 필요한 항목(비회원 기능은 제외함)이라 생각되어 의논을 통해 users의 PK를 갖게 했다.
• field 값은 테이블이 정립되면 수정키로 했다.

4) 모델링 ver 2.0

• 멘토님의 리뷰를 거치면서 많은 수정이 있었다. 우선 order와 order_list의 기능이 서로 바뀌었고, 테이블 네임도 [order->order_items], [order_list->orders] 로 수정되었다.
• 그리고 하나의 테이블로 구성했던 status 가 완전히 다른 기능을 가진 2개의 테이블로 확장되었다. orders에 역참조되는 status 는 결제전, 결제완료, 결제취소 와 같은 기능을 갖게 되고, order_items에 역참조되는 status는 배송전, 배송중, 배송완료를 갖게 된다.
• price와 weight field에는 Integer 였었는데, 리뷰 후 Decimal 로 변경되었다.
• created_at 과 updated_at은 따로 abstract속성의 class를 생성하여 상속받게 하는 것인데, 모델링을 할 때에는 적용되는 모든 테이블마다 작성해 주어야 했다.

2. Review

• 모델링을 완전히 완료하고 초기 세팅 후 migrate 하기까지 무려 4일이 걸렸다. 중간에 migration 에서 오타가 발생하기도 하고, 테이블을 빼먹는가하면, 컨벤션 관련 리뷰도 수정해 가면서 하다보니 금요일 오후에나 기능정의서를 작성 할 수 있었다.
• 살면서 한 회의보다 이번주에 한 회의 횟수가 더 많았다. 팀 전체 회의, 백엔드 회의, 아침 스탠딩 회의 등등 한달여만에 컴퓨터보다 사람과 얘기를 더 많이 했을 정도다.
• 하지만 그 어떤 시간보다 건설적이고 아는 지식을 바탕으로 소통을 하고 있다는 느낌이 무엇인지 어렴풋이 느껴지면서 전혀 지루하거나 귀찮지도 않았고, 오히려 '아, 이건 회의에서 얘기 해야겠다' 라던지, '어? 이거 지금 바로 숏미팅해서 얘기해야 겠는데?' 라며 한쪽에 정리해가고 있는 나를 발견했다.
• 회의다운 회의를 해본 적 없었지만, 지난 일주일은 그 공백을 메우기에 정서적으로, 멘탈적으로 매우 충분했다. 차고 넘쳐서 다 담지 못한 지식의 부재가 너무 안타깝긴 했지만.
• 다음 포스팅에서 완성된 기능정의서와 데이터 입력용 csv, uploader.py 를 살펴보겠다.