Spring 트랜잭션 동기화로 레거시 알림톡 발송 시스템의 한계를 넘어서기

올리브영 배송스쿼드의 알림톡 발송 시스템은 주문, 결제, 배송 같은 핵심 고객 경험을 책임지지만, 레거시 구조가 복잡해지며 발송 플랫폼 변경과 확장에 한계를 드러냈다.

기존에는 주문/배송 상태 변경 로직 안에서 발송 서비스를 직접 호출했고, 실패는 try-catch로 흡수하는 구조였다. 하지만 알림톡 발송이 성공한 뒤 비즈니스 로직이 실패하면 이미 보낸 알림을 되돌릴 수 없고, 재실행 시 중복 발송 위험도 생겼다.

전환의 핵심은 트랜잭션 커밋 이후에만 메시지를 발행하는 구조였다. 처음에는 @TransactionalEventListener를 검토했지만, 레거시의 Spring 4.2 미만 환경과 의존성 충돌, NoClassDefFoundError 문제까지 겹치며 현실적인 적용이 어려웠다.

대신 **TransactionSynchronizationManager**를 활용해 커밋 후 콜백을 등록했다. 구현 방식은 이벤트 리스너가 아니라 콜백이지만, 데이터가 확정된 뒤에만 후속 처리를 시작한다는 점에서 동일한 효과를 얻었고, 알림톡 발송을 비즈니스 트랜잭션과 안전하게 분리할 수 있었다.

이후 흐름은 Kafka 기반 이벤트 아키텍처로 정리됐다.

• 레거시에서는 주문/배송 상태 변경 후 최소 정보만 담은 메시지를 발행
• Delivery Consumer가 메시지를 소비해 발송 책임을 전담
• 알림톡 유형에 따라 일반배송, 오늘드림, 픽업, 선물하기 등으로 분기
• 배송 유형 내부에서는 일반/교환/취소 여부 같은 조건까지 나눠 공통 쿼리를 정리
• 템플릿 구성과 발송 요청은 하나의 공통 API로 통일

알림톡이 약 40개에 달해 설계와 분류 작업이 쉽지 않았지만, 결과적으로 레거시처럼 서비스마다 흩어진 조회 로직을 공통 기준으로 통합했다. 실패한 메시지는 DB에 별도 저장해 재처리할 수 있도록 했고, 더 높은 안정성이 필요한 경우에는 Outbox Pattern이나 재시도 메커니즘도 고려할 수 있다고 정리했다.

개편 후에는 구조가 훨씬 단순해졌다. 발송 시점은 afterCommit으로 보장되고, 데이터 조회는 공통 기준으로 일원화됐으며, 알림 책임은 Delivery Consumer로 모였다. 그 결과 새 알림톡 추가도 템플릿 등록과 메시지 발행만으로 처리할 수 있어 유지보수성과 확장성이 크게 좋아졌다.

이 프로젝트를 통해 배운 점도 분명했다. 코드 작성보다 먼저 전체 흐름과 아키텍처를 이해해야 하고, MSA 환경에서는 한 서비스 내부가 아니라 시스템 간 데이터 흐름과 정합성을 함께 설계해야 한다는 점이다. QA와의 반복 테스트를 통해 작은 누락도 고객 경험에 큰 영향을 줄 수 있음을 확인했고, 레거시를 단순히 고치는 수준을 넘어 설계 관점으로 시야를 넓히는 계기가 됐다.