[TIL] 프로젝트 3일차!!

🌞 오늘은 어떤 하루였지..

오전에는 열심히 택배사 도메인 관련 MVP 구현에 집중했다.
기본적인 CRUD 구현이었지만 여러 가지를 생각하면서 구현을 했더니 시간이 생각보다 많이 걸렸다.

그렇게 택배사로 오전을 전부 보내고 오후에는 출고지(물류센터) CRUD를 구현했다.
CRUD를 구현하면서 필요한 내용들은 생각하고 메모해두면서 진행했더니 오후도 시간이 뚝딱 지나갔다.

TBD 구조로 프로젝트를 시작했는데 푸쉬를 완료하고 팀원의 피드백을 받으면서 수정이 필요한 부분을 고쳐나갔다.
그러면서 추가적으로 어떤 로직들이 필요한 지 생각해보고 까먹지 않기 위해 메모로 남겨두었다.

저녁 이후로는 배송과 송장 관련 MVP 구현에 집중했는데, 다른 도메인이 완성되지 않은 상태라서 개발을 진행하는데 생각보다 애를 먹었다..
ENUM 컬럼인데 빈 ENUM 값이 들어가면서 에러가 계속해서 발생하면서 그 에러를 잡는다고 3시간 정도 보낸 것 같다.
해결되지 않을 거 같던 에러가 해결되고 나니 뿌듯하기도 하면서 진이 쭉 빠졌다..

 

💡 새롭게 알게 된 내용은 뭐가 있더라..?!

택배사가 몇 개의 물류센터와 계약할 수 있을지 제한을 걸어야 할까?

1. 제한을 두는 것이 합리적인 경우

유스케이스 기반 논리

• 현실 반영 : 대부분의 중소형 택배사는 물류센터 수가 제한되어 있다. (지역 기반 1~3개 수준)
• 불필요한 중복 등록 방지 : 한 택배사에 50개 이상 출고지가 등록되면 관리 복잡도가 증가한다.
• 관리 포털 UX 개선 : 물류센터 선택 시 드롭다운 목록이 과도하게 길어지지 않도록 제어할 수 있다.
• 데이터 오염 방지 : 실수로 동일한 출고지를 여러 번 등록하는 것을 방지하는 효과가 있다.

성능 측면

• JOIN, COUNT, EXISTS 연산에서 불필요하게 많은 SENDER 데이터가 연결되면 성능 이슈 유발이 가능하다.

보안, 통제 측면

• 입점 제약이나 계약 정책에 따른 제한 : 한 택배사당 물류센터 등록 수를 제한해 관리적 통제를 할 수 있다.

2. 제한을 두지 않는 것이 더 합리적인 경우

유연성 측면

• 대형 택배사는 수십 개 이상의 물류센터를 실제로 운영하고 있다. (CJ대한통운, 로젠 등)
• 고객이 직접 등록하는 형태면 지나치게 제한하면 불편함을 초래할 수 있다.

미래 확장성

• 처음에는 3개로 제한했지만, 나중에 상황 변화로 5개 이상 필요할 수 있다. → 코드/DB 구조 변경이 필요하다.
• 정책 변경 가능성을 고려하면, 제한을 두는 대신 "경고"나 "관리자 알림" 같은 부드러운 통제도 가능하다.

 

🗓️ 내일은 뭐 하지?!

✔️ MVP 구현 마무리
✔️ 팀원 코드 리뷰
✔️ 트러블 슈팅 정리
✔️ TIL 작성