주문 서비스에 알림 발송, 포인트 적립, 통계 수집 코드까지 다 들어있으면 부가 기능이 추가될 때마다 핵심 로직이 점점 비대해집니다. 스프링 이벤트는 유튜브 구독처럼, 발행자가 이벤트만 발행하면 관심 있는 구독자가 알아서 받아 처리하는 구조로 결합도를 낮춰줍니다.
이번 영상에서는 ApplicationEventPublisher와 @EventListener를 활용한 이벤트 발행/구독 기본 흐름부터 시작해서, 직접 호출 방식과 이벤트 방식의 결합도 비교, @TransactionalEventListener의 4가지 페이즈(특히 AFTER_COMMIT을 써야 하는 이유 — 트랜잭션이 롤백돼도 알림이 먼저 나가는 사고 방지), @Async와 스레드 풀 설정으로 비동기 이벤트 처리, 그리고 동기 실행·트랜잭션 범위·과도한 사용 같은 주의사항까지 정리했습니다.
📌 이런 분들에게 추천합니다
- 서비스 클래스가 점점 비대해져서 분리할 방법을 찾고 있는 백엔드 개발자
- @EventListener와 @TransactionalEventListener의 차이가 헷갈리는 분
- 면접에서 "결합도를 낮추는 설계"를 코드 예시로 답하고 싶은 분
- 알림·포인트·통계 같은 부가 기능을 깔끔하게 분리하고 싶은 개발자
#스프링이벤트 #SpringEvents #EventListener #발행구독 #백엔드개발
