서비스가 커지면서 단순한 이벤트 처리 방식으로는 한계를 느끼기 시작했습니다.이번 포스팅에서는 기존 @EventListener 기반 구조에서 Redis Pub/Sub으로 리팩토링한 과정과,그 속에서 겪은 직렬화/역직렬화 이슈 해결기를 공유해보겠습니다. 1️⃣ 왜 Redis Pub/Sub을 도입했을까?초기에는 스프링의 @EventListener 를 사용해 결제 취소/실패 알림을 처리했습니다.스프링 이벤트는 단일 서버에서 간단한 후처리를 할 때 정말 편리하죠.하지만 서비스가 성장하면서 확장성과 비동기 처리의 한계가 드러났습니다. 🔹 EventListener vs Redis Pub/Sub 비교항목 @EventListener Redis Pub/Sub동작 범위애플리케이션 내부 프로세스분산 환경에서도 사용 가능비..