[스프링] 1. 직접 호출과 이벤트의 경계

"이 로직을 이벤트로 분리해야 하나?" 이 질문에 명확한 기준 없이 코드를 짜면, 이벤트를 안 써서 결합이 심해지거나, 이벤트를 남발해서 흐름을 쫓을 수 없게 된다. 분리의 기준을 세우려면 먼저 이벤트가 어떤 문제를 해결하는지, 그리고 @EventListener가 실제로 어떻게 동작하는지를 정확히 알아야 한다.

직접 호출이 만드는 문제

옷을 등록하면 이미지를 S3에 올리고, 팔로워에게 알림을 보낸다고 하자. 가장 직관적인 방법은 서비스에서 전부 직접 호출하는 것이다.

@Transactional
public ClothesDto create(ClothesCreateRequest request, MultipartFile image) {
    Clothes clothes = clothesRepository.save(Clothes.create(request));
    String imageKey = s3Service.put(image);
    clothes.updateImageKey(imageKey);
    notificationService.notifyFollowers(clothes.getOwner(), "새 옷 등록");
    return ClothesDto.from(clothes, s3Service.getUrl(imageKey));
}

코드 자체는 읽기 쉽다. 하지만 이 서비스가 어떤 의존 구조를 만드는지 보면 문제가 드러난다.

ClothesService가 모든 것을 직접 알고 있다. 여기에 피드 자동 생성, 포인트 적립이 추가되면 화살표가 계속 늘어난다. 핵심 로직(옷 등록)에 부가 로직(S3, 알림)이 결합된 구조다.

장애 전파의 문제

이 구조에서 알림 서비스가 죽으면 어떻게 되는지 보자.

분홍 영역에서 알림이라는 부가 로직이 터졌는데, 핵심 로직(옷 등록)까지 함께 롤백됐다.

트랜잭션 오염

더 미묘한 문제가 있다. s3Service.put(image)는 HTTP로 외부 서버에 파일을 보내는 작업이다. 이 작업이 @Transactional 안에서 실행되면 무슨 일이 생기는지 보자.

주황 영역 동안 DB 커넥션이 불필요하게 잡혀 있다. 동시 요청이 몰리면 커넥션 풀이 고갈된다. 게다가 S3 업로드 성공 후 커밋이 실패하면, 파일은 올라갔는데 DB에는 데이터가 없는 불일치가 생긴다.

외부 호출이 트랜잭션 안에 있으면 안 되는 이유다. 이 문제는 2편에서 깊이 다룬다.

이벤트 분리의 효과

이벤트 방식에서는 "옷이 등록됐다"는 사실만 알리고, 부가 로직은 그 사실에 관심 있는 리스너가 각자 처리한다.

@Transactional
public ClothesDto create(ClothesCreateRequest request) {
    Clothes clothes = clothesRepository.save(Clothes.create(request));
    eventPublisher.publishEvent(new ClothesCreatedEvent(clothes.getId()));
    return ClothesDto.from(clothes);
}

ClothesService는 이제 S3도 알림도 모른다. 이 사실에 관심 있는 리스너가 알아서 반응한다.

@Component
public class ClothesImageListener {
    @EventListener
    public void uploadImage(ClothesCreatedEvent event) {
        s3Service.put(event.getClothesId(), ...);
    }
}

위의 직접 호출 의존 구조와 비교하면 차이가 명확하다.

ClothesService에서 나가는 화살표는 DB와 이벤트 발행뿐이다. 리스너가 아무리 늘어나도 서비스 코드는 바뀌지 않는다. 점선 화살표는 이벤트를 통한 간접 연결을 뜻한다 — 서비스와 리스너는 서로를 모른다.

@EventListener의 동작 원리

이벤트를 설계에 쓰려면 @EventListener가 내부적으로 어떻게 동작하는지 정확히 알아야 한다. 잘못 이해하면 설계 의도와 다르게 동작해서 버그가 된다. 핵심 특성은 세 가지다.

동기 실행

publishEvent()를 호출하면, Spring은 등록된 리스너를 즉시, 같은 스레드에서 실행한다. publishEvent() 다음 줄은 모든 리스너가 끝나야 실행된다.

eventPublisher.publishEvent(event);  // 리스너가 전부 끝날 때까지 여기서 멈춤
log.info("이 줄은 리스너가 끝난 뒤에 실행된다");

비동기로 동작하지 않는다. 리스너가 오래 걸리면 발행자도 그만큼 기다린다.

같은 트랜잭션

발행자가 @Transactional 안에서 이벤트를 발행하면, 리스너도 같은 트랜잭션 안에서 실행된다. 이게 어떤 결과를 만드는지 보자.

이벤트로 "분리"했다고 생각했는데, 리스너 예외가 발행자의 트랜잭션을 롤백시킨다. 트랜잭션 관점에서는 여전히 하나인 셈이다. 직접 호출과 똑같은 장애 전파 문제가 그대로 남아 있다.

실행 시점

publishEvent() 호출 시점에 리스너가 실행된다. 트랜잭션이 커밋되기 전이다. 이 시점에서 DB 변경은 아직 확정되지 않았다.

초록 영역에서 S3 업로드는 성공했는데, 분홍 영역에서 커밋이 실패했다. 파일은 S3에 올라갔는데 DB에는 데이터가 없다. 커밋 전에 외부 시스템을 호출했기 때문에 생기는 불일치다.

이 세 가지 특성 — 동기 실행, 같은 트랜잭션, 커밋 전 실행 — 을 이해하면, 왜 @TransactionalEventListener가 필요한지 자연스럽게 보인다. 2편에서 자세히 다룬다.

분리의 판단 기준

모든 로직을 이벤트로 빼는 건 정답이 아니다. 세 가지 질문으로 판단한다.

핵심 로직과 부가 로직

첫 번째 질문은 "이 로직이 실패하면 전체가 실패해야 하는가?"이다.

• 옷 등록 시 DB 저장이 실패하면? → 전체 실패해야 한다. 핵심 로직
• 옷 등록 시 알림 발송이 실패하면? → 옷은 등록되어야 한다. 부가 로직
• 옷 등록 시 S3 업로드가 실패하면? → 상황에 따라 다르다
  • 이미지가 필수면 핵심 로직에 가깝다
  • 이미지 없이도 등록 가능하면 부가 로직이다

핵심 로직은 같은 트랜잭션 안에 두고, 부가 로직은 이벤트로 분리하는 것이 기본 원칙이다.

변경 가능성

두 번째 질문은 "이 로직이 추가/삭제될 때 기존 코드를 수정해야 하는가?"이다.

옷 등록 후 해야 할 일이 하나씩 늘어난다고 하자.

• 팔로워 알림 → 서비스에 코드 추가
• 피드 자동 생성 → 서비스에 코드 추가
• 포인트 적립 → 서비스에 코드 추가

매번 ClothesService를 수정해야 한다. 이벤트 구조에서는 리스너만 추가하면 된다. 확장 가능성이 높은 부분은 이벤트가 유리하다.

응답 시간 영향

세 번째 질문은 "이 로직이 API 응답 시간에 포함되어야 하는가?"이다.

• 이미지 URL을 응답에 담아야 하면 → S3 업로드가 끝나야 응답 가능
• 알림은 사용자가 기다릴 필요 없다 → 응답 후 뒤에서 처리해도 된다

응답에 포함되지 않아도 되는 로직은 이벤트 + 비동기(@Async)로 분리할 수 있다. 이 조합은 3편에서 다룬다.

세 가지 질문을 의사결정 흐름으로 정리하면 이렇다.

"아니오"가 나올수록 이벤트 분리의 근거가 강해진다.

이벤트가 과한 경우

이벤트는 결합을 끊는 도구지만, 남용하면 다른 문제가 생긴다.

흐름 추적의 어려움

직접 호출은 IDE에서 메서드 호출을 따라가면 전체 흐름을 파악할 수 있다. 이벤트는 publishEvent()에서 끊긴다. 어떤 리스너가 반응하는지 알려면 이벤트 클래스를 검색해야 한다.

리스너가 1개뿐이고 앞으로도 추가될 가능성이 없다면, 이벤트로 분리하는 건 간접 호출 레이어만 추가한 셈이다. 직접 호출이 더 명확하다.

핵심 로직의 잘못된 분리

"옷 저장"을 이벤트 리스너로 빼는 건 잘못된 분리다. 핵심 비즈니스 로직은 서비스 메서드 안에 있어야 한다. 이벤트는 핵심 로직이 끝난 뒤의 후속 작업에 쓰는 도구다.

자주 하는 실수

---