![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 정리 (동작 방식, 트랜잭션, 운영 포인트)

> 2025년 백엔드 개발의 화두는 단연 **"모듈러 모놀리스(Modular Monolith)"** 였습니다. 무조건적인 마이크로서비스(MSA) 도입으로 인한 운영 피로도에 지친 개발자들이, 다시금 "잘 짜여진 모놀리스"로 눈을 돌리고 있기 때문입니다. 오늘은 이 트렌드의 중심에 있는 **Spring Modulith**에 대해 알아보겠습니다.

# 1. 왜 다시 모놀리스인가?

마이크로서비스는 확장성과 배포 독립성이라는 강력한 장점을 주지만, 그만큼 **복잡성 비용(Complexity Tax)** 을 요구합니다. 분산 트랜잭션, 네트워크 레이턴시, 로깅 통합 등 해결해야 할 과제가 산더미죠.

**"굳이 처음부터 네트워크로 찢어놓을 필요가 있을까? 논리적으로만 잘 분리하면 되지 않을까?"**

이 질문에서 시작된 것이 바로 **모듈러 모놀리스**입니다. 그리고 Spring 팀은 이를 공식적으로 지원하기 위해 **Spring Modulith** 프로젝트를 런칭했습니다.

# 2. Spring Modulith의 핵심 기능

Spring Modulith는 패키지 구조를 기반으로 애플리케이션의 모듈을 정의하고, 모듈 간의 의존성을 관리해줍니다.

### 아키텍처 검증 (Verification)

가장 강력한 기능입니다. 코드가 컴파일될 때, 모듈 간의 참조 규칙을 위반했는지 검사합니다.

```java
@Test
void verifyModularity() {
 ApplicationModules.of(Application.class).verify();
}
```

예를 들어, `Order` 모듈이 `Inventory` 모듈의 내부(Internal) 클래스를 몰래 가져다 쓰면, 테스트가 실패합니다. 개발자의 실수로 스파게티 코드가 되는 것을 원천 차단하죠.

### 문서 자동화 (Documentation)

코드를 분석해서 모듈 간의 관계를 보여주는 **C4 다이어그램(UML)** 을 자동으로 생성해줍니다. "문서와 코드가 따로 노는" 문제를 해결할 수 있습니다.

### 이벤트 기반 통신 (Event Externalization)

모듈 간의 결합도를 낮추기 위해 **Spring ApplicationEvent**를 주로 사용하는데, Spring Modulith는 이를 더욱 강화하여 트랜잭션이 성공했을 때만 이벤트를 발행하거나, 카프카(Kafka) 같은 외부 브로커로 이벤트를 자동으로 연동해주는 기능을 제공합니다.

# 3. 마이그레이션 전략: 언제 써야 할까?

- **스타트업 / 신규 프로젝트**: 처음엔 Monolith로 시작하되, Spring Modulith로 구조를 잡아두세요. 나중에 트래픽이나 다른 요소때문에 MSA로 전환해야 할 때, 모듈 단위로 떼어내서 MSA로 전환 하면 됩니다.
- **레거시 청산**: 엉망이 된 기존 Spring Boot 프로젝트에 도입하여 의존성 사이클을 끊어내는 용도로도 훌륭합니다.

# 마치며

**Architecture is about boundaries.** (아키텍처는 경계에 관한 것이다)

Spring Modulith는 우리가 잊고 지냈던 이 격언을 코드 레벨에서 강제해주는 훌륭한 도구입니다. 복잡한 인프라 없이도 깔끔한 아키텍처를 유지하고 싶다면 고려해볼만한 좋은 선택지라고 생각이 됩니다.

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

> Java 21 LTS가 출시되면서 **Virtual Threads(가상 스레드, Project Loom)**가 정식 기능이 되었습니다. 많은 개발자들이 "이제 WebFlux(Reactive)의 복잡함 없이도 고성능 비동기 처리가 가능하다!"며 환호했죠. 하지만 실무 도입 1년이 지난 지금, 해외 커뮤니티에서는 **예상치 못한 성능 저하와 OOM(Out of Memory)** 사례들이 보고되고 있습니다. 오늘은 단순한 찬양글이 아닌, **실전에서 Virtual Threads를 도입할 때 마주하게 될 함정들과 그 해결책**을 깊이 있게 다뤄봅니다.

![Virtual Threads Architecture](https://miro.medium.com/v2/resize:fit:1400/1*rQyC5L-g_k-b0iHqD3HqD3.png)

# 1. Virtual Threads의 환상과 실제

기존의 Java 스레드(Platform Thread)는 OS 스레드와 1:1로 매핑되는 비싼 자원이었습니다. 그래서 톰캣(Tomcat) 스레드 풀을 200개 정도로 제한해서 썼죠.
반면, **Virtual Threads는 JVM이 관리하는 경량 스레드**로, OS 스레드 하나 위에서 수천, 수만 개가 번갈아 가며 실행될 수 있습니다 (M:N 모델).

Spring Boot 3.2부터는 설정 한 줄이면 바로 적용할 수 있습니다.

```yaml
spring:
 threads:
 virtual:
 enabled: true
```

이 한 줄로 I/O Blocking이 발생할 때마다 JVM이 알아서 스레드를 스위칭해주니, 이론상 처리량(Throughput)이 폭발적으로 늘어나야 합니다. **하지만 현실은 달랐습니다.**

# 2. 치명적인 함정: Pinning (고정 현상)

Virtual Threads 도입 후 가장 많이 겪는 성능 이슈의 주범입니다.

### 🚨 현상
가상 스레드가 I/O 작업을 만나면 캐리어 스레드(OS 스레드)를 놓아주고 쉬어야 하는데, 특정 상황에서는 **OS 스레드를 붙잡고 놓지 않는 현상**이 발생합니다. 이를 **Pinning**이라고 합니다.

### 🔍 원인
1. **`synchronized` 블록 내부**: Java의 전통적인 동기화 블록 안에 있을 때.
2. **네이티브 메서드(JNI) 호출 시**.

```java
// ❌ Pinning 유발 코드 예시
synchronized (lock) {
 // 여기서 DB 조회 같은 I/O를 하면
 // 캐리어 스레드가 블로킹되어 전체 성능이 급락합니다.
 repository.findById(id);
}
```

많은 JDBC 드라이버나 구형 라이브러리들이 내부적으로 `synchronized`를 사용하고 있습니다. Virtual Threads를 켰는데 갑자기 전체 서버가 멈춘다면 99% 이 문제입니다.

### ✅ 해결책
* `synchronized` 대신 **`ReentrantLock`**을 사용하세요. `ReentrantLock`은 Pinning을 유발하지 않습니다.
* 라이브러리 버전을 최신으로 올리세요. (MySQL Driver, Jackson 등 주요 라이브러리들은 이미 패치되었습니다.)
* JVM 옵션 `-Djdk.tracePinnedThreads=full`을 켜서 Pinning이 발생하는 지점을 로그로 추적하세요.

# 3. 메모리 폭발: ThreadLocal의 배신

기존 스레드 모델에서는 스레드 수가 적었기 때문에 `ThreadLocal`에 무거운 객체(예: DateFormat, UserContext)를 캐싱하는 패턴이 흔했습니다.
하지만 Virtual Threads는 **수백만 개**가 생성될 수 있습니다.

### 🚨 시나리오
* 요청 하나당 Virtual Thread 하나 생성.
* 각 스레드가 1MB짜리 버퍼를 `ThreadLocal`에 할당.
* 동시 접속자 10,000명 → **10GB 메모리 순식간에 점유** → **OOM(Out Of Memory) 발생**.

### ✅ 해결책
* Virtual Threads 환경에서는 `ThreadLocal` 사용을 지양해야 합니다.
* 꼭 필요하다면 Java 21에 새로 도입된 **Scoped Values (JEP 446)**를 사용하세요. 불변성을 보장하며 메모리를 효율적으로 공유합니다.

# 4. 언제 써야 할까? (Blocking vs CPU Bound)

Virtual Threads는 **I/O Bound 작업**(DB 조회, API 호출)에 특화되어 있습니다.
반면, **CPU Bound 작업**(동영상 인코딩, 암호화, 복잡한 계산)에서는 오히려 성능이 떨어집니다.

* **Good**: RestController, DB CRUD, 마이크로서비스 간 통신
* **Bad**: 배치 프로세싱, 이미지 처리, 머신러닝 연산

CPU 작업이 많다면 가상 스레드의 컨텍스트 스위칭 비용이 더 큽니다. 이런 작업은 기존의 Platform Thread 풀을 따로 운영하는 것이 낫습니다.

# 마치며

Spring Boot의 Virtual Threads 지원은 분명 혁신적입니다. WebFlux의 끔찍한 디버깅 난이도에서 우리를 구원해주었으니까요.
하지만 **"켜기만 하면 빨라진다"는 오해**입니다.

1. 사용 중인 라이브러리가 **Pinning**을 유발하지 않는지 확인하세요.
2. **ThreadLocal** 사용량을 점검하세요.
3. CPU 집중 작업은 별도로 분리하세요.

이 3가지만 지킨다면, 여러분의 서버는 적은 리소스로도 엄청난 트래픽을 감당할 수 있게 될 것입니다. 🚀

Java Virtual Threads: 무조건 도입하면 안 되는 이유와 실전 트러블슈팅

> 2002년, 로드 존슨(Rod Johnson)이 쓴 책 한 권에서 시작된 프레임워크가 전 세계 자바 생태계를 지배하게 되었습니다. EJB(Enterprise JavaBeans)의 복잡함에 반기를 들고 일어난 Spring은 어떻게 진화해 왔을까요? Spring 1.0부터 최신 Spring 6.0까지, 각 시대를 관통하는 핵심 변화와 특징을 정리해 봅니다.

![Spring History](https://images.unsplash.com/photo-1461360228754-6e81c478b882?q=80&w=2074&auto=format&fit=crop)

# 1. Spring 1.0 ~ 2.0: XML의 시대 (2004~2006)

**EJB 없는 가벼운 개발(Lightweight)** 을 모토로 등장했습니다. 
핵심은 **DI(Dependency Injection)** 와 **AOP(Aspect Oriented Programming)** 였습니다.

- **특징**: 모든 빈(Bean) 설정을 applicationContext.xml이라는 거대한 XML 파일에 일일이 적어야 했습니다.
- **문제점**: 프로젝트가 커질수록 XML 파일이 수천 줄을 넘어가며 관리가 불가능한 수준(XML Hell)이 되기 시작했습니다.

# 2. Spring 2.5 ~ 3.0: 어노테이션의 혁명 (2007~2009)

개발자들의 XML 피로도가 극에 달했을 때, Spring은 **Java Annotation**을 적극적으로 도입하기 시작합니다.

- **@Component, @Autowired 등장**: XML에 bean 태그를 쓰는 대신, 클래스 위에 @Service, @Controller만 붙이면 되게 바뀌었습니다.
- **Java Config (Spring 3.0)**: XML을 완전히 버리고 Java 코드(@Configuration, @Bean)로 설정을 관리할 수 있게 되었습니다. 이것이 훗날 Spring Boot의 기반이 됩니다.

# 3. Spring 4.0: Spring Boot의 탄생 (2013)

Spring 역사상 가장 큰 분기점입니다. **설정보다 관례(Convention over Configuration)** 를 내세운 **Spring Boot**가 등장했습니다.

- **Java 8 지원**: 람다(Lambda) 식을 사용할 수 있게 되었습니다.
- **Spring Boot 1.0**: 내장 톰캣(Embedded Tomcat)을 탑재하여 main() 메서드 실행만으로 웹 서버를 띄우는 충격적인 경험을 선사했습니다.
- **자동 설정(Auto Configuration)**: spring-boot-starter-web 하나만 추가하면 수십 가지 설정을 알아서 해주는 마법이 시작되었습니다.

# 4. Spring 5.0: 리액티브 프로그래밍 (2017)

Node.js의 비동기 논블로킹 모델이 인기를 끌자, Spring도 이에 대응하기 위해 대대적인 변화를 줍니다.

- **Spring WebFlux**: 기존의 서블릿(Servlet) 기반 블로킹 모델(Spring MVC)과 별도로, 완전한 비동기 논블로킹 웹 프레임워크를 출시했습니다.
- **Project Reactor**: Mono, Flux 같은 리액티브 타입을 표준으로 도입했습니다.
- **JDK 9 모듈 시스템** 대응이 시작되었습니다.

# 5. Spring 6.0 & Boot 3.0: 클라우드 네이티브 (2022~현재)

클라우드와 서버리스(Serverless) 환경에 최적화하기 위해, Spring은 과감하게 **과거와의 단절**을 선언합니다.

- **Java 17 필수**: 최소 요구 사항이 Java 8에서 17로 껑충 뛰었습니다. (Java EE -> Jakarta EE로 패키지명 변경 대혼란)
- **GraalVM Native Image**: JIT 컴파일러 대신 AOT(Ahead-of-Time) 컴파일을 지원하여, JVM 없이 실행되는 **네이티브 바이너리**를 만들 수 있게 되었습니다.
 - 부팅 속도: 수 초 -> 0.1초
 - 메모리 사용량: 수백 MB -> 수십 MB

# 마치며: Spring은 늙지 않는다

20년이 넘은 프레임워크가 여전히 현역 1타 자리를 지키는 이유는 끊임없는 **자기 혁신** 때문입니다.
EJB를 죽이러 왔던 Spring이 이제는 Serverless와 AI 시대(Spring AI)를 준비하고 있습니다.

여러분의 프로젝트는 지금 어떤 Spring 버전에 머물러 있나요? 3.x? 4.x? 이제는 6.0으로 넘어올 때입니다. 🚀

Spring boot

이 주제의 기록

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

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

Java Virtual Threads: 무조건 도입하면 안 되는 이유와 실전 트러블슈팅

Spring Framework 변천사: XML 지옥에서 Native Image까지