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

> Java 21 LTS가 출시되면서 **Virtual Threads(가상 스레드, Project Loom)**가 정식 기능이 되었습니다.<br>많은 개발자들이 "이제 WebFlux(Reactive)의 복잡함 없이도 고성능 비동기 처리가 가능하다!"며 환호했죠.<br>하지만 실무 도입 1년이 지난 지금, 해외 커뮤니티에서는 **예상치 못한 성능 저하와 OOM(Out of Memory)** 사례들이 보고되고 있습니다.<br>오늘은 단순한 찬양글이 아닌, **실전에서 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: 무조건 도입하면 안 되는 이유와 실전 트러블슈팅

댓글 0

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

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