[스프링] 스프링 이벤트는 언제 써야할까?

기존 프로젝트에서 Service 간 의존성이 생기는 부분이 고민이었고,
이를 해결하기 위해 스프링 이벤트를 적용해 봤습니다.

 

✅ 프로젝트 상황

"내부 알림 기능"이 서비스에 필요했습니다.

즉, 유저가 서비스에 접속했을 때 알림이 쌓여 있고 이를 확인할 수 있는 화면이 필요했습니다.

 

알림 화면

 

사용자에게 알림이 도착하는 상황은 다음 3가지 경우였습니다.

1. 리뷰 요청
2. 프로젝트 팀원 초대
3. 팀원 초대 수락

---

📍 Alarm 테이블

해당 기능에 필요한 알람 테이블은 다음과 같이 설계했습니다.

 

Alarm 테이블

 

주요 필드로는 

• `receiver_id`: 알람은 받는 사람 ID
• `sender_id`: 알람을 보낸 사람 ID
• `targetId`: 알림이 발생한 3가지 상황 각각에서 연관된 엔티티의 ID
• `message`: 알람 멘트
• `alarm_type`: 알람이 발생한 상황(리뷰 요청, 팀원 초대, 초대 수락)

 

이를 엔티티로 구현하면 다음과 같습니다.

 

Alarm 엔티티

---

📍 리뷰 요청 알림 생성 로직

알림이 생성되는 3가지 상황 중, 제가 담당한 "리뷰 요청" 알림 생성 로직에 대해 설명드리겠습니다.

ReviewService와 AlarmService

 

한 유저가 다른 유저에게 리뷰를 요청하면, ReviewService의 requestReview 함수가 호출됩니다.

그리고 그 함수 내부에서, AlarmService의 createAlarm 함수를 호출합니다.

 

즉, ReviewService 내부에서 AlarmService의 함수를 호출하기 위해, AlarmService 객체를 필드로 가지고 있게 됩니다.

 

프로젝트 팀원 초대와 초대 수락 상황에서도 마찬가지입니다.

 

ProjectService의 각 함수가 호출되고, 그 함수 내부에서 AlarmService의 createAlarm 함수를 호출합니다.

ProjectService도 AlarmService 객체를 필드로 가지고 있게 됩니다.

 

---

그럼 각 도메인(Review, Project)의 서비스 메서드를 호출하는 게 아니라,
바로 AlarmService의 메서드를 호출하면 안 되는 걸까요?

 

그렇게 하게 되면 또 다른 문제가 발생합니다. 

• 예를 들어 '프로젝트 팀원 초대' 상황에서는 단순히 알림만 보내는 것이 아니라, ProjectMember 객체도 새로 생성해서 DB에 저장해야 합니다. 그런데 이 작업을 AlarmService에서 처리하게 되면, ProjectMember 생성과 저장 로직이 AlarmService로 들어가게 되고, 이는 또 다른 의존성 문제로 이어집니다.
• 알람 생성을 하기 전에 targetId가 유효한지 검증해야 합니다. targetId에는 proejct, reviewForm, reviewRecord의 ID가 올 수 있습니다. 만약 이 유효성 검사를 AlarmService에서 처리한다면 AlarmService가 proejctRepository, reviewFormRepository, reviewRecordReposistory를 모두 의존해야 합니다. 다른 도메인의 레포지토리에 직접 참조하여야 DB에서 조회해 오는 것도 또 다른 의존성 문제입니다.

 

---

✅ 문제점

위 상황을 도식화하면 아래와 같습니다.

 

이벤트 적용 전 모습

 

 

이처럼 Service가 다른 Service에 의존하면 어떤 문제점이 있을까요?

 

1. 도메인 간의 강한 결합도
2. 단일 책임 원칙(SRP) 위배
3. 좋지 않은 확장성

 

---

📍 도메인 간의 강한 결합도

현재 Review-Alarm과 Project-Alarm 도메인 사이에 결합도가 강하다고 볼 수 있습니다.

만약 Alarm 객체를 생성하는 로직을 변경하면, 이는 ReviewService와 ProjectService에도 영향을 줍니다.

 

---

📍 단일 책임 원칙(SRP) 위배

단일 책임 원칙이란, 클래스가 단 하나의 책임만 맡아야 한다는 원칙입니다.

즉, "어떤 클래스를 변경해야 하는 이유는 오직 하나"라는 의미입니다.

 

현재 ReviewService에는 2가지의 책임이 있습니다.

Review 관련 비즈니스 로직을 처리하는 책임 + Alarm을 생성하는 책임

 

createAlarm 메서드를 호출하는 행위는 결국 "리뷰 요청 알림을 생성하라!"는 명령을 내리는 것입니다.
즉, 알람 생성이라는 행위가 ReviewService 내부에서 일어나고 있다는 사실만으로도, 알림 생성에 대한 책임이 ReviewService에 존재한다고 볼 수 있습니다.

 

---

📍 좋지 않은 확장성

현재는 특정 상황이 발생했을 때 서비스 내부 알람만 생성하는 구조입니다.

 

하지만 만약 서비스 내부 알람과 함께 이메일 알림도 함께 보내고 싶다면 어떻게 해야 할까요?

결국 EmailService를 새로 만들고, ReviewService와 ProjectService 안에서 emailService.createEmailAlarm() 같은 메서드를 호출하게 될 것입니다.

 

이후에 SMS 알림까지 추가하고 싶어 진다면, 또다시 SmsService를 만들고, ReviewService와 ProjectService가 이 서비스에도 의존해야 합니다.

 

이런 식으로 알림 수단이 늘어날 때마다 서비스는 점점 더 많은 책임을 가지게 됩니다.

 

---

✅ 스프링 이벤트

이렇게 의존성 문제가 있을 때, 사용할 수 있는 것이 바로 스프링 이벤트입니다!

 

📍 목적

의존성 분리를 위해

 

📍 구성요소

• 이벤트(event): 특정 조건이 충족되었을 때 발생하는 사건
• 발행자(publisher): 이벤트를 발행시킴
• 구독자(subscriber): 이벤트를 감지하고 특정 동작 수행

📍 흐름

• `ApplicationEventPublisher`가 `publishEvent()`로 이벤트 발행
• `ApplicationContext`가 발행된 이벤트를 `@EventListener`가 붙어있는 메서드에 전달
• `@EventListener` 메서드 로직 실행

---

✅ 스프링 이벤트 적용 후 문제 해결

스프링 이벤트를 적용한 후의 모습을 도식화하면 다음과 같습니다.

이벤트 적용 후 모습

 

스프링 이벤트를 적용하면 과연 앞서 언급했던 3가지 문제가 해결될까요?

 

하나씩 살펴보겠습니다.

---

📍 해결: 도메인 간의 강한 결합도

중간에 `EventListener`가 생기면서 ReviewService와 ProjectService는 AlarmService에 의존하지 않아도 됩니다.

즉, Alarm 생성 로직이 변경되더라도 ReviewService와 ProjectService에 영향이 가지 않는 거죠.

 

---

📍 해결: 단일 책임 원칙(SRP) 위배

기존에는 "알람을 생성해라!"라고 하고 있기 때문에 ReviewService와 ProjectService에 알람 생성의 책임이 있다고 했습니다.

 

하지만, 이벤트 기반으로 수정하면 "리뷰 요청/팀원 초대/ 초대 수락 이벤트가 발생했다!"라고 단순히 이벤트를 발생시키기만 하면 됩니다.

알람 생성에 대한 책임은 더 이상 지지 않습니다.

 

---

 

📍 해결: 좋지 않은 확장성

 

앞서 말했듯이 이메일 알림과 문자 알림이 추가된다면 어떻게 될까요?

 

단순히 `EventListener` 로직만 추가하면 됩니다!

 

ReviewService와 ProjectService의 로직은 전혀 수정하지 않아도 됩니다.

여전히 이벤트를 발생시키기만 하면 되죠.

 

---

✅ 코드 수정 - @EventListener 활용

이제 스프링 이벤트를 적용하기 위해 기존 코드를 수정해 보겠습니다.

 

---

📍 Event 클래스 생성

 

알람이 필요한 세 가지 상황(리뷰 요청, 팀원 초대, 초대 수락)에 대해 이벤트 클래스를 만들어줍니다.

 

---

📍 ReviewService에 EventPublisher 주입

 

ApplicationEventPublisher를 통해 ReviewService에서 이벤트를 발행합니다. 

 

---

📍 EventListener 클래스 생성

 

마지막으로 이벤트를 처리해 주는 EventListener 클래스를 생성합니다.

`@EventListener` 어노테이션을 메서드에 달아서, 각 이벤트가 발생했을 때 어떤 로직을 실행할지 정의해 줍니다.

---

✅  @EventListener 문제

앞선 코드에서 `@EventListener`라는 어노테이션을 사용했습니다.

하지만, 이 어노테이션에는 몇 가지 문제가 있습니다.

 

---

📍 기본적으로 동기로 동작

단순히 `@EventListener` 어노테이션만 달아주면 이 메서드는 동기로 동작합니다.

 

하지만 동기 방식에서는 다음과 같은 문제가 발생할 수 있습니다.

1. 서비스 내부 알림 + 이메일 알림 보낸다고 가정
2. 동기로 동작하면 서비스 내부 알림 생성 후, 이메일 알림 보냄
3. 이메일 알림이 오래 걸리면 사용자는 이 시간을 모두 기다려야 함

 

이런 문제를 방지하기 위해, 해당 리스너 메서드에 `@Async` 어노테이션을 함께 사용하여
비동기로 처리되도록 명시해 주는 것이 좋습니다.

 

---

📍Event를 발행시킨 로직도 같이 롤백 

초대 수락 알람이 생성되는 과정에서 만약 예외가 발생했다고 합시다. 

 

1. 프로젝트 멤버 초대를 받은 유저가 초대 수락
2. ProjectService에서 팀 멤버를 새로 생성하여 저장
3. 초대를 수락했다는 이벤트를 발생시킴
4. AlarmEventListener에서 알람 생성하여 저장하려 했는데, Exception 발생
5. 그럼 팀 멤버를 새로 생성하는 과정도 같이 롤백됨

 

결국, 초대를 수락한 사용자 입장에서는 수락했음에도 수락되지 않는 상황이 발생하는 것입니다.

 

핵심 비즈니스 로직의 안정성을 보장하기 위해서는 이를 해결합니다.

그리고 해결 방법은 바로 `@EventListener` 대신 `@TransactionalEventListener`를 사용하는 것입니다!

---

✅  @EventListener vs. @TransactionalEventListener

`@EventListener` : 이벤트가 발행되는 시점에 바로 EventListener의 로직 실행

 

`@TransactionalEventListener` : 트랜잭션의 어떤 타이밍에 이벤트를 발생시킬지 정할 수 있음

• AFTER_COMMIT (기본값) - 트랜잭션이 성공적으로 마무리(commit)됐을 때 이벤트 실행
• AFTER_ROLLBACK – 트랜잭션이 rollback 됐을 때 이벤트 실행
• AFTER_COMPLETION – 트랜잭션이 마무리 됐을 때(commit or rollback) 이벤트 실행
• BEFORE_COMMIT - 트랜잭션의 커밋 전에 이벤트 실행

위와 같이 옵션을 설정하여 어느 시점에 이벤트를 실행할지 결정할 수 있습니다.

 

이제 `@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)`으로 변경하고

다시 초대 수락 알람이 생성되는 과정에서 만약 예외가 발생했다고 합시다. 

1. ProjectService에서 팀 멤버를 새로 생성하여 저장
2. 초대를 수락했다는 이벤트를 발생시킴
3. 트랜잭션 커밋
4. AlarmEventListener에서 알람 생성하여 저장하려 했는데, Exception 발생
5. 팀 멤버는 이미 커밋되었기 때문에 잘 저장됨

=> `@TransactionalEventListener`을 사용해 핵심 비즈니스 로직의 안정성을 보장할 수 있습니다.

 

---

✅ 코드 수정 - @Async & @TransactionalEventListener 활용

📍 @Async 사용

 

한 이벤트가 발생했을 때, 두 가지(내부 알람, 이메일 알람) 처리를 하고 싶다면

`@Async`를 붙여 비동기적으로 처리될 수 있도록 해야 합니다.

 

"리뷰 요청 보내기" 상황에서는 비즈니스 로직에서 CUD 작업을 하지 않습니다.

따라서 `@EventListener`를 굳이 `@TransactionalEventListener`로 변경하지 않아도 됩니다.

 

📍 @Async & @TransactionalEventListener 사용

 

반면에 "팀 초대 수락" 상황에서는 `@TransactionalEventListener`로 변경해줘야 합니다.

비즈니스 로직에서 `TeamMember`라는 객체를 새로 생성해 저장하기 때문입니다.

 

---

✅  @TransactionalEventListener만 사용하면 안 됨!

저렇게 해서 모든 작업이 끝난 줄 알았으나..

또 문제가 발생했습니다.

 

📍문제

팀 멤버 생성 후 트랜잭션에서 이미 Commit이 되었기 때문에 해당 트랜잭션에서는 조회밖에 수행할 수 없다는 것입니다.

즉, EventListener에서 데이터를 insert, delete, update 하면 반영이 안 됩니다.

 

📍해결

`@TrnasactionalEventListener`과 함께 `@Transactional(propagation=Propagation.REQUIRES_NEW)`를 붙여줘야 합니다.

 

`REQUIRES_NEW` 전파 옵션을 설정하면, 이벤트 리스너 내부의 알림 처리 로직이 별도의 새로운 트랜잭션에서 실행됩니다.
즉 메인 트랜잭션과는 분리되어 동작하므로 알림 생성 과정에서 예외가 발생해도 본래 비즈니스 로직은 롤백되지 않고 그대로 커밋됩니다.

 

---

✅  AOP vs. 스프링 이벤트

스프링 이벤트를 공부하다 보니 AOP랑 뭐가 다른 걸까? 하는 의문이 들었습니다.

 

AOP를 써서 "알람 생성"이라는 공통 관심사를 분리하면 되지 않나?

 

 

결론적으로 둘은 목적이 조금 달랐습니다.

• AOP: 공통된 부가적인 기능을 하나의 Aspect으로 분리
• 스프링 이벤트: 두 도메인 간의 의존성 분리

 

AOP에서 분리하고자 하는 것은 "공통"되면서 "부가적인 기능"입니다.

알람 생성은 리뷰 요청/ 프로젝트 팀원 초대 / 초대 수락 상황에서 "공통"된 기능은 맞습니다.

 

하지만, 부가적인 기능이라고는 볼 수 없습니다.

부가적인 기능이란 로그, 수행 시간 저장과 같이 핵심 기능을 보조하는 기능을 의미합니다.

알람 생성은 Alarm 객체를 생성해 DB에 저장하는 핵심 로직입니다! Aspect로는 부적절합니다.

 

따라서, 두 도메인 간의 의존성이 고민됐던 제 상황에서는 스프링 이벤트를 적용하는 것이 적절합니다.