![event](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/3e447b01-be59-4aae-9a98-9a3265f94886_event.webp)

> 스프링에서 Event랑 `@Async`를 쓰다 보면 처음엔 편한데, 프로젝트가 조금만 커져도 “이게 언제 실행되는거지?”, “트랜잭션 커밋 전에 나가버린거 아냐?” 같은 이슈가 바로 나옵니다. 그래서 이번에는 제가 정리했던 내용을 기준으로, Event / `@Async`가 정확히 어떻게 동작하는지랑 운영에서 자주 터지는 포인트를 같이 정리해보겠습니다.

# Spring Event는 기본적으로 “동기”로 동작합니다

처음에 제가 착각했던 부분이 이거였습니다.  
Event라고 해서 자동으로 비동기로 도는게 아닙니다.

- 기본 설정에서는 이벤트를 publish한 **그 스레드에서 리스너가 그대로 실행**됩니다.
- 그래서 리스너에서 시간이 오래 걸리는 작업을 하면, publish한 쪽도 같이 느려집니다.

즉, Event는 “관심사 분리”에는 좋지만, “응답속도”가 자동으로 빨라지는 기능은 아닙니다.

# 이벤트를 쓰면 좋은 상황이 있습니다

이벤트는 보통 “핵심 로직”이랑 “부가 로직”을 분리할 때 가장 효과가 좋습니다.

예를 들면:

- 주문 생성(핵심) 이후에  
  - 슬랙 알림 보내기  
  - 포인트 적립하기  
  - 통계 적재하기  
  - 감사 로그 남기기  
같은 것들이 계속 붙는 상황입니다.

이걸 다 `OrderService.createOrder()` 안에 넣기 시작하면, 결국 서비스 메서드가 너무 길어지고 결합이 커집니다.  
이럴 때 이벤트로 분리해두면 “리스너 추가”만으로 기능을 붙일 수 있습니다.

다만 이 방식도 단점이 있는데, 흐름이 코드에서 한 눈에 안보이는 문제가 있습니다.  
그래서 결제 승인처럼 **즉시 실패 전파가 중요한 핵심 플로우**는 이벤트로 대충 넘기면 위험합니다.

# 이벤트 구현은 이렇게 합니다 (POJO 이벤트)

요즘은 `ApplicationEvent` 상속 없이 POJO(또는 record)로 많이 합니다.

```java
public record OrderCreatedEvent(
    Long orderId,
    Long userId,
    int totalAmount
) {}
```

이벤트 발행은 `ApplicationEventPublisher`로 합니다.

```java
@Service
@RequiredArgsConstructor
public class OrderService {
  private final ApplicationEventPublisher publisher;

  @Transactional
  public Long createOrder(CreateOrderCommand cmd) {
    Long orderId = /* 주문 저장 */;
    publisher.publishEvent(new OrderCreatedEvent(orderId, cmd.userId(), cmd.totalAmount()));
    return orderId;
  }
}
```

여기서 바로 의문이 생깁니다.

- “트랜잭션 커밋 전에 이벤트가 처리되면 어떡하지?”
- “리스너에서 DB 조회하면 아직 커밋 전이면 못 읽는거 아닌가?”

이 문제 때문에 실무에서는 `@TransactionalEventListener`를 같이 쓰는 경우가 많습니다.

# @TransactionalEventListener는 “언제 실행할지”를 정할 수 있습니다

예를 들어 커밋 이후에만 실행되게 하려면 이렇게 합니다.

```java
@Component
public class OrderEventListener {

  @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
  public void afterCommit(OrderCreatedEvent event) {
    // 커밋 성공 이후에만 실행됩니다.
  }
}
```

`phase` 옵션은 대충 이렇게 이해하면 됩니다.

- `BEFORE_COMMIT`: 커밋 직전
- `AFTER_COMMIT`: 커밋 성공 이후 (제일 많이 씁니다)
- `AFTER_ROLLBACK`: 롤백 이후
- `AFTER_COMPLETION`: 커밋/롤백 상관 없이 트랜잭션 종료 이후

제가 보통 추천하는 조합은:

- 외부 알림/외부 API 호출(메일, 슬랙, 외부 결제 후속 처리 등) → `AFTER_COMMIT`  
  (커밋이 실패했는데 알림부터 나가면 더 큰 문제가 생깁니다)
- 실패 케이스 후처리(보상 로그, 실패 알림 등) → `AFTER_ROLLBACK`

## 트랜잭션이 없으면 실행이 안될 수 있습니다

`@TransactionalEventListener`는 트랜잭션이 없으면 phase 의미가 없어서, 실행이 안되는 케이스가 있습니다.  
그럴 때는 아래 옵션을 씁니다.

```java
@TransactionalEventListener(
  phase = TransactionPhase.AFTER_COMMIT,
  fallbackExecution = true
)
public void on(OrderCreatedEvent event) { }
```

`fallbackExecution=true`면 트랜잭션이 없어도 실행되긴 합니다.  
다만 이 경우에는 “AFTER_COMMIT” 의미는 사실상 사라지고 그냥 실행된다고 보면 됩니다.

# @Async는 “별도 스레드”에서 실행됩니다

`@Async`는 별도 스레드에서 메서드를 실행하는 기능이고, 내부적으로 `TaskExecutor`(스레드풀)를 씁니다.

사용하려면 보통 아래를 추가합니다.

```java
@EnableAsync
@Configuration
public class AsyncConfig { }
```

그리고 메서드에 `@Async`를 붙입니다.

```java
@Component
public class NotificationService {

  @Async
  public void sendOrderCreatedMessage(Long orderId) {
    // 별도 스레드에서 실행됩니다.
  }
}
```

여기서도 “처음엔 되는데 운영에서 터지는 지점”이 몇 개 있습니다.

# @Async에서 자주 터지는 포인트들

## 1) 프록시 기반이라서 “자기 자신 호출”은 안됩니다

`@Async`는 AOP 프록시 기반이라서, 같은 클래스 안에서 `this.asyncMethod()`로 호출하면 비동기로 안도는 경우가 있습니다.  
그래서 보통은 `@Async` 메서드를 다른 Bean으로 분리합니다.

## 2) `void` 리턴이면 예외가 호출자에게 전달되지 않습니다

`@Async void` 메서드는 예외가 호출한 쪽으로 전달되지 않습니다.  
그래서 운영에서 조용히 실패하는 경우가 생깁니다.

필요하면 `AsyncUncaughtExceptionHandler`를 설정해두는게 안전합니다.

## 3) 트랜잭션/영속성 컨텍스트는 공유되지 않습니다

비동기 스레드에서는 기존 요청 스레드의 트랜잭션/영속성 컨텍스트가 그대로 이어지지 않습니다.  
그래서 이벤트/비동기에서 엔티티를 그대로 들고가면 lazy 로딩 같은게 터질 수 있습니다.

그래서 저는 보통 이렇게 잡습니다.

- 이벤트에는 엔티티를 넘기지 않습니다.
- ID나 스냅샷 DTO만 넘깁니다.
- 리스너에서 필요하면 새 트랜잭션으로 다시 조회합니다.

# Event + @Async 조합은 이런 식으로 씁니다

실무에서 제일 흔한 패턴은:

- 이벤트는 `AFTER_COMMIT`에 받습니다.
- 리스너는 `@Async`로 돌립니다.

```java
@Component
@RequiredArgsConstructor
public class OrderAsyncEventListener {

  private final SlackClient slackClient;

  @Async
  @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
  public void on(OrderCreatedEvent event) {
    slackClient.send("#orders", "주문 생성: " + event.orderId());
  }
}
```

이렇게 하면 커밋 성공 이후에, 별도 스레드에서 외부 알림을 보내게 할 수 있습니다.

# 근데 이 방식은 “내구성”을 보장하지 않습니다

여기서 또 중요한 포인트가 있습니다.

Spring Event는 기본적으로 **프로세스 내부 이벤트**라서,

- 서버가 내려가면 유실될 수 있고
- 재시도/중복 처리/내구성이 기본 제공되지 않고
- 멀티 인스턴스 환경에서는 브로드캐스트가 아닙니다

즉, “절대 유실되면 안되는 작업”이면 Event/Async로 끝내면 안됩니다.

이런 경우에는 보통:

- Outbox 패턴 + 메시지 브로커(Kafka/RabbitMQ/SQS)
- DB 작업 큐 테이블 + 워커
- 배치 재처리

같은 구조로 넘어가야 합니다.

# 결론

Event는 결합도를 줄이는 데 좋고, `@Async`는 느린 후처리를 분리하는 데 좋습니다.  
근데 둘 다 “편해보여서 막 쓰면” 운영에서 바로 터질 수 있습니다.

제가 기준으로 잡는건 이렇습니다.

1. 외부 호출은 가능하면 `AFTER_COMMIT` 이후에 합니다.
2. 이벤트 페이로드는 ID/스냅샷 DTO로 최소화합니다.
3. `@Async`는 예외가 조용히 묻히지 않게 로그/메트릭을 잡습니다.
4. 스레드풀(TaskExecutor) 튜닝을 운영 기준에 맞게 합니다.
5. 유실이 허용되지 않으면 Outbox/Queue로 넘어갑니다.


Spring Event와 @Async 정리 (동작 방식, 트랜잭션, 운영 포인트)

댓글 0

복잡한 MSA는 이제 그만! Spring Modulith로 시작하는 모듈러 모놀리스