본문 바로가기
해피 코딩/프로젝트

Chapter 4. 최종 회고

by happy-coding 2024. 9. 24.
🔥 Chapter 4. 대규모 AI 시스템 설계 프로젝트가 마무리되었기 때문에, 프로젝트 정리 및 회고를 진행하려고 한다.

[ 팀원 소개 및 역할 ]

  • 팀장 - 서병준
    • 주문 API
    • 배송 API
    • 배송 담당자 API
    • 배송 경로 기록 API
    • AI API
  • 팀원 - 조아영
    • 허브 API
    • 허브 경로 API
    • 회사 API
    • 제품 API
    • 발표
  • 팀원 - 한수빈
    • 인증 및 인가
    • Gateway
    • 유저 API

[ 담당한 기능 ]

  • 🎁 주문 API
    • 주문이 생성, 삭제되면 배송 및 배송 경로 기록이 함께 생성, 삭제됩니다.
    • 주문, 배송, 배송 경로 기록이 같은 라이프 사이클을 가지고 있습니다.
    • feginClient를 사용하여 Auth Application에서 데이터를 검증합니다.
  • 🚛 배송 API
    • 배송에 대한 현재 상태를 가지고 있으며, 배송 경로 기록에 의해서 바뀌게 됩니다.
  • 🚴 배송 담당자 API
    • 허브 이동 담당자와 업체 이동 담당자가 존재합니다.
    • 두 타입 간의 업무는 명확히 구분됩니다.
    • 허브 이동 담당자는 업체 배송을 할 수 없으며, 업체 배송 담당자는 허브 이동을 담당할 수 없습니다.
  • 🗒️ 배송 경로 기록 API
    • 배송 경로 기록은 최초에 모든 경로가 생성되어야 합니다.
    • 각각의 허브 이동 간의 상태가 변화합니다.
  • 🕵️ AI API
    • Gemini API 연동하여 사용합니다.
    • 해당 질문과 답변은 모두 저장되어야 합니다.

🚨 Trouble Shooting

MSA의 Application 분리로 인한 배송 담당자를 어디서 생성해 줘야 하는가?
  • 상황
    • 배송 담당자는 유저의 권한이 "DELIVERY_PERSON"일 경우에만 생성이 가능합니다.
    • 이 부분을 처음 구현할 때에는 배송 담당자 생성을 요청하는 곳이 User였습니다.
    • User를 생성할 때 입력받은 권한이 배송 담당자일 경우 FeginClient를 통하여 Auth Application에서 Delivery Application으로 이동합니다.
    • Delivery Application에서 배송 담당자를 생성 및 저장하고 다시 유저가 속한 Auth Application으로 돌아와 로직이 종료됩니다.
  • 문제 발생
    • 이 경우 저장을 요청하는 곳과 실제로 저장되는 곳이 일치하지 않아 User가 DeliveryPerson에 의존하게 되는 문제가 발생합니다.
  • 해결 방안
    • 배송 담당자 생성을 DeliveryPerson에서 요청합니다. feginClient를 통하여 User에서 해당 유저가 존재하는지, 권한이 “DELIVERY_PERSON”인지 검증합니다. 인가 시 DeliveryPerson에서 저장을 완료해 줍니다.

[ 4L 회고 ]

  • Liked : 좋았던 것/잘 한 것
    • MSA를 사용하여 프로젝트를 경험해 봤다는 게 앞으로의 개발 인생에 있어서 좋은 경험이 될 것 같다.
    • 서로 다른 Application의 API 호출을 위한 FeignClient에 대한 사용 이해도와 숙련도가 높아졌다.
  • Lacked : 아쉬웠던 것/부족했던 것
    • 아직 MSA에 대한 이해가 부족하다는 것을 느꼈다.
    • MSA 개발 방식이 익숙하지가 않아 모놀리식과 비교하여 같은 기능을 만들더라도 시간이 더 많이 소요된다는 것이 아쉬웠다.
  • Learned : 배운 것
    • 이론으로만 이해하던 캡슐화, 의존성에 대한 개념의 중요성을 이번 프로젝트를 통해 느끼게 되었다.
    • 캡슐화 -  Sevice로직에서 Setter or Bulider를 지양하고, DDD의 관점에서 엔티티는 자신의 상태를 스스로 관리해야 한다
      • 엔티티의 무결성을 잃을 수 있다.
      • Setter를 통해 외부에서 임의로 상태를 변경하면, 도메인 규칙이나 비즈니스 로직을 위반할 위험이 있다.
      • 도메인 규칙이 외부로 분산되게 되어 유지보수 및 디버깅이 어려워질 수 있습니다.
      • 즉, 생성 및 수정은 자신의 Entity 내부에서 이뤄져야 한다.
    • 의존성 - 배달 생성자를 어디서 생성해야 올바른 방향인지를 알게 되었다.
    • Appilication Sevice Naming -  Application Sevice 중 Object Service가 있는데, 이는 서비스 명을 보고 해당 서비스가 어떤 역할을 하는지 유추할 수 없어서 좋은 Naming 방식이 아니라고 한다.
      • 서비스 명을 보고 해당 서비스의 역할을 유추할 수 있도록 Object Service의 root 에그리거트 이름을 따라가는 것이 좋은 방식이라고 한다.
    • Git Issue -  프로젝트의 작업, 개선 및 수정사항,  버그 추적을 위해 처음으로 GitHub에서 Issue를 발행하여 작업을 해보았다.
  • Longed for : 개선을 위해 시도해 볼 것
    • 다음번에는 FeginClient가 아닌, RabbitMQ를 사용하여 작업을 진행해 보고 싶다.
    • 검색 API - Search를 JPA를 사용하여 개발하였지만, 실제 현업에서는 검색 API를 개발할 경우 여러 필터 값 들이 존재하고, 해당 필터들이 or, and 조건이 유기적으로 변경되는 경우가 많다고 한다. 이를 위해 다음 프로젝트에서는 JPA가 아닌, QueryDSL로 구현을 해보도록 하자.

🌐 Infrastructure Design Document

왼쪽- 수정 전 / 오른쪽 - 수정 후

🤔 처음 계획에 비해서 인프라 설계도가 많이 단순해진 이유가 무엇인가요?
💁 처음에는 Application을 Entity 기준으로 잘게 나눠서 개발하기로 하였지만 막상 개발을 진행해 보니 생각보다 복잡하고 클린하지 않아서 좋은 방식이 아니라고 판단하게 되었다.
이로인해 팀의 정책을 다시 정하고 Applicaiton을 Entity기준으로 나누는 것이 아닌, DDD관점에서 나눠서 개발하는 방향으로 수정하였다.

[ 팀 프로젝트를 진행하며 느낀 점 ]

모놀리식과 MSA 각각의 방식이 다른 프로젝트를 하면서 느낀 가장 큰 차이는 프로젝트 진행속도라고 생각한다. 물론 개발 방식이 모놀리식에서 MSA로 바뀌고 팀원이 바뀐 만큼 개인의 역량 차이가 있을 수 있겠지만, 팀장으로서 느낀 포인트는 모놀리식에서는 문제 되지 않았던, 프로젝트의 진행속도가 지체되는 상황에 대하여 어떻게 해야지 조금이라도 프로젝트의 개발속도를 올리고 완성도 있는 프로젝트를 만들 수 있을지 올바른 방향을 제시하지 못했다고 생각한다.
이 부분이 팀장으로서 아쉬움이 남는 부분이었으며, 이 또한 새로운 경험이 되어 성장할 수 있는 기회라고 생각한다.

 

읽어주셔서 감사합니다 😊

 

😺 GitHub: https://github.com/B2B-Ai-Project/B2B-Ai-Project?tab=readme-ov-file#-order

'해피 코딩 > 프로젝트' 카테고리의 다른 글

Chapter 5. 최종 회고  (0) 2024.11.05
Chapter 3. 최종 회고  (0) 2024.09.09

관련글

티스토리툴바