[ 문제 상황 ]

✅ 모놀리식 구조: 주문 완료 단계가 1500라인 이상의 단일 트랜잭션으로 구성됨

✅ 높은 도메인 간 결합도: 모든 로직이 하나의 서비스에서 처리되어 변경이 어려움

✅ 확장성 제한: 새로운 기능 추가 시 기존 코드 변경이 필수적이므로 리스크 증가

✅ 부분 실패 시 롤백 부담 증가: 일부 단계에서 실패해도 전체 트랜잭션이 롤백되어 불필요한 리소스 낭비

[ 고안부분 및 해결방법 ]

제가 가장 도전적이라고 느꼈던 프로젝트는 스타벅스 사이렌오더의 주문 완료 단계 개발경험입니다.

이 프로젝트는 결제 확정, 장바구니 재정렬, 리워드 적립 등 다양한 비즈니스 로직이 포함된 도메인을 다루었습니다. 특히 사이렌오더는 일평균 50만 건 이상의 주문이 발생하는 시스템이기에, 대규모 트랜잭션 처리를 유지하면서 데이터 정합성을 확보하고 성능 병목을 방지하는 것이 도전 과제였습니다.

주문 완료 단계에서 저는 도메인 주도 설계(DDD)를 기반으로 각 기능을 Aggregate로 분리하여 도메인의 결합도를 낮추는 데 집중했습니다. 이를 통해 핵심 로직인 결제 확정과 주문 상태 업데이트를 독립적으로 관리할 수 있도록 설계하였으며, 실시간 처리가 필요 없는 로직인 알림톡 발송과 리워드 적립은 Kafka를 활용해 비동기 처리 방식으로 전환하여 시스템의 응답 속도를 향상시켰습니다. 또한 1500 line 이 넘던 로직을 100 line 이하로 줄여 한 눈에 알아보기 쉽게 리팩토링하였습니다. 처리속도 또한 평균 2초정도 소요되던 기능이 1초 이내로 처리가 돼, 기존기능 대비 50% 이상 성능향상을 이루었습니다.

데이터 정합성 유지를 위해 클라우드 생성 데이터를 온프레미스 DB에 저장하는 비동기 메시지 저장 방식을 채택했습니다. 이 접근법은 마이그레이션되지 않은 기능에 대해서도 동일하게 동작할 수 있도록 보장했습니다.

[ 회고 ]

1. 데이터 정합성 및 비즈니스 분리가 핵심인 DDD 구조, 두 가지 모두 만족할 수 있는 구조를 만들기위해 많이 고민했습니다. 데이터 정합성 비동기 처리가 저에게 가장 큰 과제였습니다. 추가적으로, 결제 대사 배치, 데이터 변경을 추적할 수 있는 이벤트의 상태를 관리 하는 것으로 해결 할 수 있다 생각이됩니다.
2. MSA 로 전환하는 과정에서 여러 개의 도메인 분리와 함께 테스트하는 과정이 쉽지 않았습니다. 하지만, 주문 완료라는 로직을 분리해내면서 APP, POS, Web 등 채널별로 달랐던 로직을 하나로 응축할 수 있었고 타 도메인 처리의 영향으로 주문 완료가 실패하는 경우를 없애 뿌듯했습니다.
3. Hexagonal, clean Architecture 에 기반한 개발로 신규 비즈니스 추가 개발에도 간편하고 신속하게 대응할 수 있었습니다. MSA로 분리하는 과정은 쉽지 않았지만, 장점을 제대로 느껴볼 수 있었고 이론으로만 접했던 유지보수성 향상 코드를 직접 느낄 수 있는 값진 경험이었습니다.