Today I Learn ✍🏼
1. 배송 시나리오 문제
팀원 민철님이 작성한 배송 시스템의 Kafka 시나리오에서 오류를 발견했습니다.
배정이 완료된 이후에도 오후 4시에 스케줄링 작업으로 단순히 주문 상태를 '배정중'에서 '배정완료'로 변경하는 동작만 하고 있었습니다.
문제점: 스케줄링 작업에서 배송 기사를 배정하는 로직이 빠져 있었고, 데이터를 처리하는 방식도 비효율적이었습니다.
배송 프로세스 제시
저는 팀원들에게 오후 4시 스케줄링 작업에서 배정중 → 배정완료로 상태만 변경하는 대신, 두 가지 방법 중 하나를 선택하라고 가이드를 주었습니다:
- 배정 작업을 한 번에 Bulk Insert로 처리하거나,
- Kafka를 통해 하나씩 메시지를 보내서 처리하는 방식으로 변경.
시간이 부족했기에 이 문제는 우선순위를 낮추고, 주문 시스템 수정을 먼저 진행하기로 했습니다.
배송 시나리오 프로세스 해결 방안
- 오후 4시 스케줄링: 배송 서버는 오후 4시에 팬딩 상태인 주문 목록을 받아옵니다.
- 주문 처리: 주문 목록에서 하나하나 오더 아이디를 기준으로 주문을 조회하고, 배송 기사를 배정합니다.
- 주문 상태 변경: 각 주문의 상태를 '배차완료'로 변경한 후, Kafka를 통해 주문 상태 변경 메시지를 전송합니다.
- 실패 처리: 만약 처리에 실패한 주문이 있다면 해당 주문들을 목록에 넣고 다시 재시도합니다.
이 해결 방안은 문제 발생 시 재시도 로직을 포함하여 안정성을 강화하며, Kafka를 활용한 주문 상태 업데이트를 효율적으로 처리합니다.
2. DEV-product 코드 리뷰 및 개선
대현님의 코드를 리뷰하는 과정에서 몇 가지 문제를 발견했습니다:
- 팀 코드 규칙에 맞지 않게 작성한 부분이 있었습니다.(이미 허브app에서 가이드 코드 작업을 완성해둔 상태입니다)
- Git 사용에 미숙한 모습도 보였는데, 상품 서버와 관련 없는 코드가 PR로 함께 올라오기도 했습니다.
- DEV-product PR로 코드리뷰를 하지않고 코드리뷰를 Discusstion에 작성했습니다. Discustion 링크
이에 Git 브랜치 전략과 PR 관리 방법을 설명해주었고, 상품과 상품 재고 서비스를 분리하는 설계에 대해 다시 납득시켰습니다.
또한, 코드 정리 및 스타일 가이드 적용을 위해 구글 스타일과 소나 린트를 IntelliJ에 설치하도록 가이드했습니다.
지원 및 개선 활동
- 대현님에게 Git 사용법과 브랜치 전략, 풀/푸시 방법을 설명했습니다.
- 코드 스타일을 맞추기 위해 IntelliJ 자동 정렬 및 import 정리 단축키를 공유했습니다.
- 팀 코드 규칙에 맞게 상품 서버에서 상품과 상품 재고 서비스를 분리해서 다시 작성하도록 유도했습니다.
- Getter/Setter 자동 생성 원리를 컴파일된 클래스 파일을 통해 설명하며 이해를 도왔습니다.
3. 주문 시스템 개편
주문 시스템이 Stateless로 개편되면서 기존의 CRUD 기능들이 많이 사라져 있는 상태였고,
Kafka 메시지 송수신 로직도 공통 모듈로 구분이 되어 있지 않았습니다.
이를 해결하기 위해, 메시지 프로듀서, 메시지 컨슈머, 메시지 서비스를 각각 분리하고, 전략 패턴과 팩토리 메서드 패턴을 적용하라고 팀원들에게 지시했습니다.
4. 카프카 메시지 구조 개선
메시지 구조와 관련해서는 제가 직접 카프카 구조를 만들어 줄 수도 있었지만, 팀원들이 스스로 고민하도록 유도했습니다.
일요일 밤 12시부터 새벽 4시까지 팀원들은 메시지 구조를 고민했으며, 민철님과 대현님이 많이 깨달은 것 같았습니다.
월요일 아침 회의에서 한 번 더 설명해주고 PR을 받기로 했습니다.
이후 민철님이 노력한 코드를 제가 조금 수정해서,
최종적으로 결정된 Kafka 메시징 구조는 여기에 반영되었습니다.
7. 배운 점
- 카프카 메시지 구조 설계에 있어 팀원들이 직접 고민하고 개선하면서 더 나은 결과를 도출할 수 있었습니다.
- Git 브랜치 전략과 PR 관리 방법을 체계적으로 가르쳐주는 것이 협업의 효율성을 높이는 데 큰 도움이 됐습니다.
- 코드 스타일과 일관성 유지는 팀 협업에서 매우 중요하며, 이를 위해 코드 규칙과 스타일 가이드를 지속적으로 강조해야 합니다.
- 코드 리뷰나 개선점을 문서로 전달할 때, 공격적으로 느껴질 수 있다는 점을 깨달았습니다.
- 팀원마다 상황에 맞춰 구두로 설명하거나 전략적으로 접근하는 것이 더 효과적일 수 있다는 생각이 들었습니다.
- 특히, 말로 전달할 때는 문제없이 소통이 잘 이루어지는 반면, 채팅이나 문서로 전달할 때는 분위기가 싸우는 것처럼 느껴지는 경우가 있어서, 앞으로는 사람 스타일에 맞게 접근해야겠다고 생각했습니다.
'기술 블로그 (Tech Blog) > Project-coopang' 카테고리의 다른 글
mapper (0) | 2024.10.23 |
---|---|
gateway 라우팅 에러 해결하기 (0) | 2024.10.16 |
@Component, @Configuration + @ConfigurationProperties (0) | 2024.10.02 |
페이징 처리 (0) | 2024.09.23 |
DDD Layered Architecture의 application service와 domain service에 어떤 코드를 넣어야 하는 걸까? (0) | 2024.09.23 |