TIL - 물류 시스템 서비스 API 명세서 회의 (11.03)

📝 MSA 프로젝트 설계 회의 회고

오늘은 팀원들과 함께 MSA 기반 프로젝트의 핵심 아키텍처를 논의하는 중요한 회의를 진행했다. 여러 기술적 고민과 선택의 순간들이 있었고, 그 과정에서 많은 것을 배울 수 있었다.

🔐 인증/인가 처리 - 가장 큰 고민

회의 시작부터 가장 뜨겁게 논의된 주제는 바로 인증과 인가를 어디서 처리할 것인가였다.

고민의 시작

처음엔 두 가지 방향성이 맞섰다:

• Gateway에서 모든 URL별 권한을 매핑해서 처리할 것인가?
• 아니면 각 마이크로서비스 내부에서 세부 권한을 체크할 것인가?

그리고 만약 Gateway에서 인증만 처리한다면, 토큰을 그대로 넘겨줄지 아니면 Passport(통행권) 개념으로 유저 데이터만 넘겨줄지도 애매했다.

튜터님의 조언과 최종 결정

튜터님께 질문을 드렸고, 명쾌한 답변을 들을 수 있었다:

✅ 최종 결정 사항:

• 모든 프로젝트에 Spring Security 적용
• Gateway에서는 userId와 userRole 정도만 전달
• 각 서비스마다 @PreAuthorize 같은 선언적 방식으로 권한 체크
• 보안 로직이 명확히 분리되고 테스트도 쉬워진다!

그에 따른 새로운 과제

이 결정으로 인해 공통 모듈이 필요해졌다. 공통 모듈에는:

• Spring Security의 SecurityContextHolder에 사용자 정보를 넣어 @PreAuthorize 등이 동작할 수 있게 하는 기능

🚫 블랙리스트 관리 전략

토큰 블랙리스트를 어떻게 관리할지도 고민이었다.

고민 포인트:

• DB에서 영구 관리할 것인가?
• Redis로 임시 관리할 것인가?
• 애초에 Access Token이 짧으면 블랙리스트가 꼭 필요한가?

결론:

• Redis에 기본적으로 저장
• 하지만 영속성은 마스터와 관리자만 RDB에 저장
• 일반 유저 생성/삭제 문제와 분리해서 관리하는 것이 합리적

👤 회원 관리 설계

• 회원 정보 수정은 현재 방식 유지
• 탈퇴는 요청 방식으로 변경하거나 소프트 삭제로 처리 검토

💬 슬랙 메시지 처리

슬랙 연동 관련해서도 재미있는 고민이 있었다:

• 과연 메시지를 수정할 일이 있을까?
• 수정하면 새로운 메시지를 다시 발송해야 하나?
• 슬랙 API 연결 후 실제로 테스트해보고 결정하기로!

📦 주문-배송 설계의 복잡성

이 부분이 가장 복잡하고 흥미로웠다.

1. 주문에서 배송 ID 처리

고민: 주문이 생성되면 배송 ID를 어떻게 받아올 것인가?

선택지:

• 같은 애플리케이션이면 서비스 의존해도 되지 않을까?
• 하지만 MSA니까 최대한 분리하는 게 좋지 않을까?

결론: 일단 개발하면서 팀원들과 논의하며 결정하기로! (그리고 가격 필드는 우선 제거)

2. 재고 차감 시점과 멱등성

재고 차감 전략:

• 재고를 확인하면서 동시에 차감하는 것이 좋겠다는 결론
• 주문 하나당 멱등키 하나로 중복 처리 방지

멱등키 논의 과정: 처음엔 "OrderItem이 이미 유니크하니까 멱등키가 필요 없지 않을까?"라고 생각했지만, 재고의 차감과 증감 모두 있기 때문에 Order ID만으로는 처리할 수 없다는 결론에 도달.

튜터님께 질문: Timeout 이슈로 인한 중복 처리 방지를 위한 멱등키가 주문 도메인에 속해야 할지, 상품 도메인에 속해야 할지 질문드리기로!

3. 상품과 허브의 관계

핵심 질문: 한 아이템이 여러 허브에 존재할 수 있나?

결론:

• Inventory에 Hub ID를 포함
• Product ID는 유지
• 재고 정보는 상품 안으로 통합해서 처리

=> 이 부분은 요구사항을 보니 담당허브가 있어서 한 아이템이 여러 허브에 존재하지 않는다는 것을 알았다.

=> 이 부분으로 인해 주문할 때 배송 담당자에게 같은 허브끼리 묶어서 보내기로 합의 하였다.

4. 배송 로직의 복잡도

가장 머리가 복잡했던 부분!

시나리오:

주문 생성 
→ 여러 주문 아이템 
→ 각 아이템마다 상품 ID 
→ 상품 ID로 소속 허브 확인 
→ 같은 허브면 하나의 배송으로 묶음

배송 생성 프로세스:

• 주문 생성 시 각 상품의 소속 허브 확인
• 같은 허브에 있는 상품끼리 묶어서 배송 생성
• 배송지가 여러 개면 배송 생성 API 여러 번 호출
• 처리는 비동기로!

5. 배송 기록과 최종 배송

정리된 내용:

• 상품마다 배송이 생성되고, 생성된 것마다 경로가 하나씩 생김
• 배송 기록은 허브 간 이동 경로만 남김
• 최종 허브에서 수령 업체까지는 별도 처리

배송 담당자 지정:

• 최종 허브 → 수령 업체 구간의 배송 담당자는 일단 랜덤으로!
• 이상적으로는 작업이 배정되지 않은 담당자를 우선 선택하는 알고리즘이 좋겠지만...
• 우선은 심플하게 가자는 결론

🤔 회고

오늘 회의를 통해 MSA 설계가 단순히 서비스를 나누는 것이 아니라는 걸 뼈저리게 느꼈다. 각 서비스 간의 책임과 경계를 어떻게 나눌 것인지, 데이터를 어떻게 주고받을 것인지, 일관성을 어떻게 유지할 것인지... 고민할 것이 정말 많았다.

 

아직 결정하지 못한 것들도 많지만, 팀원들과 튜터님의 도움으로 하나씩 해결해나갈 수 있을 것 같다. 다음 회의에서는 멱등키 도메인 소속 문제와 배송 담당자 할당 알고리즘을 더 깊게 논의해봐야겠다.

 

현재 스파르타 하면서 굉장히 많이 성장 중이다. 나는 그저 우물 안의 개구리라는 것을 뼈저리게 느끼고 있는 중이다. !