회고
시간 관리
제출 시간이 매우 촉박했기 때문에 주도적으로 팀원들에게 시간 관리를 요청했다. 남은 시간을 기준으로 필요한 작업의 소요 시간과 비율에 따라 일정을 세분화했다.
2시까지: 팀원들의 현재 문제 사항을 고민하고 논의 6시까지: 문제 사항 해결 및 5단계 수준의 Swagger 작성 요구사항에 대해 논의 8시까지: 요구사항 대비 전체 진척도와 반영률을 점검 11시부터: 발표 자료 준비 및 PPT 제작 진행
비록 작업을 완전히 마무리하지는 못했지만, 제출을 시도하는 과정에서 파일 첨부에 시간이 소요되어 제출에 실패하고 말았다. 아쉬움이 남지만, 오늘 하루 동안 많은 진척이 있었다고 생각한다.
MSA스러운 서비스 분리
주문 생성 시 배송 경로를 포함해 AI 서비스에 최종 발송 기한을 예측하여 메시지를 보내야 하는 요구사항이 있었다. 이를 처리하는 방법에 대해 팀 내에서 두 가지 방안을 고민했다.
- 주문 서비스에서 관리
주문 프로세스의 일부로 보고 주문 서비스가 AI와 메시지 서비스를 요청하여 관리하는 방법 - 배송 서비스에서 관리
필요한 데이터를 보유하고 있는 배송 서비스에서 배송이 생성될 때 AI와 메시지 서비스를 요청하는 방법
팀 내에서는 두 방법 모두 나름의 장단점이 있다고 논의했다. 관리의 효율성과 오버헤드 문제에 대한 고려가 필요했다.
이후 튜터님께 조언을 구한 결과, 두 방법 모두 상황에 따라 적용될 수 있는 방식이라고 말씀하셨다. 특히 “서로의 도메인이 상대방의 역할을 알지 않는 것이 더 MSA스러운 설계”라고 강조하셨다. 이 부분이 매우 중요하게 느껴졌다.
- 주문 서비스에서 관리하는 방식: 모놀리식 프로젝트를 MSA로 전환하는 과정에서 적용되기 쉬운 방법
- 배송 서비스에서 관리하는 방식: 이상적이고 고도화된 MSA 구조에서 더욱 적합한 방법
이러한 조언을 통해 MSA에서의 서비스 분리 설계 중요성을 다시금 생각해보게 되었다.
GitHub Commit
Auth Refactoring
- chore: 누락된 gradle 파일 제거
- fix: Swagger가 ExceptionHanlder를 불러와 발생하는 에러 수정
- fix: 권한 검증시 null 조건 오류 수정
- docs: Auth Swagger 문서 작성
- refactor: 사용자 검색결과 페이지 건수 제한