Day 094 - Baro5Nda(바로온다) 프로젝트 20%, 모래성을 쌓을 시간조차 고프다

1. 프로젝트 진행 상황 및 계획

🥇 Baro5Nda(바로온다) 주문 C 리팩토링(Refactoring) 끝내기 (진행 중, 25.01.09 완료 목표)
🥈 Baro5Nda(바로온다) 주문 RUD 구현 끝내기 (진행 중, 25.01.09 완료 목표)  

🥉 Baro5Nda(바로온다) 주문 CRUD를 팀 프로젝트에 합치기 (진행 전, 25.01.09 완료 목표)
4️⃣ Baro5Nda(바로온다) AOP 적용하기 (진행 전, 25.01.09 완료 목표)

5️⃣ Spring 심화 프로젝트 도전 과제 6단계 문서 작성 끝내기 (진행 중, 25.01.09 완료 목표)

6️⃣ 대출한 전자책 10% 이상 읽기 (진행 중, 25.01.09 완료 목표)  

7️⃣ Baro5Nda(바로온다) 주문 C 구현 끝내기 (완료)

8️⃣ API 명세서, ERD, 데이터베이스 스키마(Database Schema) 확정 짓기 (완료)

 

2. ERD(Entity Relationship Diagram)

필수 기능 요구 사항은 고객이 각 주문에 한 메뉴만 넣을 수 있다는 점이었기에 처음에는 주문한 메뉴 이름을 주문(ORDERS) 테이블에 넣었는데, 이 구조는 도전 기능인 장바구니 기능이 더해질 가능성을 고려하지 않았기 때문에 확장성 면에서 좋지 않았다. 이런 이유로 각 주문에 메뉴가 여러 개 들어가도 기존의 주문 테이블을 변경하지 않도록 'ORDER_ITEMS'라는 이름으로 새로운 중간 테이블을 만들었다. 다른 기능이 더해져도 기존 테이블에 영향을 미치지 않도록 고쳤다. 

 

'무언가가 변경될 듯싶다면, 확장할 수 있는 부분까지 고려해서 프로젝트를 설계해야 했다.'

 

3. 고민

Q1. 사장님이 메뉴 가격이나 이름을 변경했다면, 변경 전 주문 목록은 변경 사항이 반영되어야 하는가?

A1. 변경 전 주문 명세는 바뀌지 않고 그대로 보존되어야 했다. 예를 들어, 메뉴 A 가격이 9,000원이었는데 10,000원으로 바뀌어도 이전에 생성된 메뉴 A 주문 명세는 그대로 유지되어야 손님과 사장님 모두 과거 주문 명세를 확인할 때 혼란을 겪지 않았다. 손님은 9,000원을 냈는데 10,000원을 냈다고 착각할 수 있고, 사장님 또한 실제 매출과 주문 명세를 바탕으로 계산할 때 오차가 발생해서 앱을 신뢰하지 못할 수 있었다. 

 

Q2. 현재 별점(rating)은 후기(REVIEWS) 테이블 안에만 있는데, 별점을 활용하여 가게 평점 같은 통계를 낼 수 있는 방법은 없을까?

A2. 후기 테이블에서 각 후기가 속한 가게 식별자(store_id)를 바탕으로 별점을 집계하는 기능을 추가하면, 별점을 가게 단위로도 통계 낼 수 있을 듯했다. 이런 식으로 별점을 가게별로 평균을 내어 가게 평판을 평가하는 기능을 추가할 수 있지 않을까, 한 번 연관관계를 어떻게 설정하면 좋을지 곰곰이 생각해 보기로 했다. 

 

4. 회고 

주말과 공휴일을 제외한 말 그대로 순수한 훈련일 90일 중의 절반이 막 지나갔다. 이런저런 기술을 적용하고 기능을 구현하며 안개 같은 불안감은 늘 따라다니곤 했지만 유독 저번 주부터 갈수록 짙어졌다. 도대체 왜 이렇게 불안할까. 정신없이 기능 하나를 더 구현하고 기술 하나를 더 익히면 사라질까. 

 

아니었다. 

 

여태까지 해온 공부는 벽돌을 쌓듯 개념과 원리를 찬찬히 익히는 방식이었다면, 지금 하는 개발 공부는 속도전과 같았다. 고개 돌릴 새 없이 무작정 달리다가 문득, 어디쯤 왔을까 의문이 든 순간 여태까지 머리와 손에 익힌 모든 지식이 모래성 같아서 더 마음이 힘들어졌다. 사용법 숙지와 원리 이해는 다르고 원리 이해는 지식의 욕구인데 해소할 시간이 없으니 더 답답했나 보더랬다. 이번 프로젝트는 주어진 기간이 너무나 짧아서 사실 지금 당장 팀 전체에 의견을 꺼낼 용기가 차마 나지 않지만, 나중에 팀 프로젝트를 하거든 이 시간을 다 같이 꼭 보내자고 다짐했다. 

 

'자신의 속도로 공부하는 개인 학습 시간'

'달리기를 멈추고 뒤돌아서 숨을 고를 틈'

 

오늘은 주문 관련 테이블이 두 개로 늘어서 생각보다 오래 걸렸으나, 손님이 한 가게에서 다양한 메뉴를 주문했을 때를 고려하여 CRUD의 C를 구현했다. 

처음에는 틀만 잡을 생각으로 메뉴가 빠진 주문 요청서를 만들었다. 주문 생성을 요청하는 Reqeust Dto에 메뉴 이름이나 메뉴 식별자를 넣지 않은 탓 손님이 메뉴 가격을 적어야 하는 이상한 주문서가 나왔다.

이후 초안을 계속 고치면서 주문서가 서서히 영수증 모양을 닮아갔다. 별다른 오류 없이 '201 Created' 메시지가 떴을 때 속으로 얼마나 환호했는지 모른다. 

얼추 모양이 잡힌 뒤에는 손님이 메뉴의 가격을 주문서에 넣을 필요가 없으므로, 메뉴 식별자와 수량만 입력할 수 있도록 수정했다. 두 번째로는 일대다 연관관계로 메뉴의 식별자와 가격을 가져와서 총 수량과 총가격을 계산할 수 있도록 고쳤다. 구현할 때는 눈을 몇 번이고 질끈 감았는데, 막상 구현하고 나니 메뉴를 주문하는 맛이 꽤 쏠쏠했다. 이래서 '주문 기능 구현'의 악명을 뻔히 알면서도 자석처럼 끌렸나 보다.

 

주문은 잘 생성되지만, 당연히 만족스럽진 않았다. 일단 주문(ORDERS) 테이블에 주문한 메뉴 총 개수라든지 총가격을 저장해서 사장님이 매출을 확인할 수 있도록 테이블에 두 정보를 추가해야 한다. 총가격이나 총 개수뿐만 아니라 '주문 수락 대기 중'을 의미하는 'PENDING'도 같이 넣어서 응답해 줘야 한다. 세 번째로는 주문이 언제 요청되었는지 '생성일'과 '수정일'을 추가하고 응답할 때 생성일도 넣어야 한다. 추가하고 고칠 부분이 꼬리에 꼬리를 물듯 끝없이 나오는 지금, 어느 때보다 시간이며 체력 관리를 잘 해야 할 때이다. 노력하되 무리하지는 말자.