톰캣(Tomcat) 스레드 고갈은 옛말! 스프링 부트 3 '가상 스레드(Virtual Threads)' 실전 도입과 Pinning 해결법

안녕하세요, 여러분의 든든한 IT 길잡이 데브프리입니다.

 

스프링 부트(Spring Boot) 백엔드 개발 생태계에서 최근 가장 혁명적인 변화를 꼽으라면, 단연코 Java 21의 '가상 스레드(Virtual Threads)' 정식 도입일 것입니다. Spring Boot 3.2 버전부터 이 가상 스레드를 공식 지원하기 시작했고, 이제는 application.yml에 단 한 줄의 설정(spring.threads.virtual.enabled=true)만 추가하면 기존의 무거운 톰캣(Tomcat) 스레드 풀의 한계를 완벽하게 뛰어넘을 수 있게 되었습니다.

 

과거에는 대규모 트래픽을 감당하기 위해 러닝 커브가 험악한 WebFlux(비동기 논블로킹)로 넘어가야만 했습니다. 하지만 이제는 우리가 익숙한 MVC(동기 블로킹) 코드를 그대로 유지하면서도 WebFlux급의 엄청난 동시성 처리 성능을 누릴 수 있게 된 것이죠.

 

하지만 "설정 한 줄만 켜면 알아서 빨라지겠지?"라고 안일하게 접근했다가는 실서버에서 원인 모를 병목 현상과 마주하게 됩니다. 오늘은 현업에서 가상 스레드를 도입할 때 가장 흔하게 터지는 'Thread Pinning(스레드 고정)' 에러를 논리적으로 분석하고, 성공적인 도입을 위한 3가지 베스트 프랙티스를 팩트 기반으로 짚어드릴게요.

 

1. 가상 스레드(Virtual Threads)의 핵심 원리

기존의 자바 스레드(Platform Thread)는 운영체제(OS)의 스레드와 1:1로 매핑되어 아주 무겁고 비쌌습니다. 톰캣이 기본적으로 200개의 스레드만 만들어두는 이유도 메모리를 너무 많이 먹기 때문이죠.

 

반면 가상 스레드는 OS 스레드(Carrier Thread) 위에서 자바 가상 머신(JVM)이 수만 개의 가벼운 스레드를 뗐다 붙였다(Mount/Unmount) 하며 관리합니다.

플랫폼 스레드가 무거운 대형 트럭이라면, 가상 스레드는 골목길을 자유롭게 누비는 수만 대의 날렵한 스쿠터와 같습니다.

데이터베이스(DB) 응답을 기다리거나 외부 API 호출 결과를 기다릴 때(I/O Blocking), 기존 스레드는 멍하니 멈춰서 자원을 낭비했습니다. 하지만 가상 스레드는 기다리는 시간 동안 재빨리 OS 스레드에서 내려오고(Unmount), 그 자리에 다른 급한 가상 스레드를 올려보내어(Mount) 작업을 처리합니다. 이 찰나의 교체 작업 덕분에 CPU를 단 1%도 놀리지 않고 꽉 채워서 쓸 수 있게 됩니다.

 

2. 실전 트러블슈팅: 가상 스레드를 켰는데 왜 서버가 멈출까?

기대를 안고 실서버에 가상 스레드를 켰습니다. 그런데 트래픽이 몰리기 시작하자, 갑자기 모든 API 응답이 멈춰버리고 서버가 기절(Stall)하는 현상이 발생합니다.

왜 터졌을까? (Thread Pinning 현상의 덫)

문제의 원인은 바로 기존 코드나 외부 라이브러리 깊숙한 곳에 숨어있는 synchronized 블록 때문입니다.

 

가상 스레드가 작업을 하다가 synchronized 블록이나 JNI(Java Native Interface) 코드를 만나면, JVM 구조상 가상 스레드가 기반이 되는 OS 스레드(Carrier Thread)에 강력하게 접착제처럼 들러붙어 버립니다. 이것을 'Pinning(고정)'이라고 부릅니다.

 

이 상태에서 DB 쿼리나 API 통신처럼 오래 걸리는 작업(I/O)이 발생하면, 가상 스레드는 OS 스레드에서 내려오지(Unmount) 못합니다. 결국 OS 스레드마저 함께 멈춰버리고, 이런 요청이 몇 개만 겹쳐도 JVM의 모든 OS 스레드가 마비되며 서버 전체가 뻗어버리는 대참사가 일어납니다.

가상 스레드가 synchronized 블록을 만나면 OS 스레드에서 내려오지 못하고 물리적으로 고정(Pinning)되어 심각한 병목 현상을 유발합니다.

해결 과정 (어떻게 튜닝해야 할까?)

1. Pinning 지점 추적하기
2. 서버를 띄울 때 JVM 옵션으로 -Djdk.tracePinnedThreads=full (또는 short)를 추가하세요. 그러면 어떤 클래스의 몇 번째 줄에서 Pinning이 발생하여 스레드를 갉아먹고 있는지 스택 트레이스에 아주 명확하게 찍힙니다.
3. ReentrantLock으로 교체하기
4. 스프링 부트 로직 내에 synchronized 키워드가 있다면 이를 모두 java.util.concurrent.locks.ReentrantLock으로 교체해야 합니다. ReentrantLock은 Pinning을 유발하지 않고 가상 스레드를 정상적으로 Unmount 시켜줍니다. (참고로 JDK 24의 JEP 491부터는 synchronized의 Pinning 문제가 아키텍처 레벨에서 해결될 예정이지만, 현재 주력 LTS인 Java 21을 쓰신다면 반드시 코드를 수정해야 합니다.)

 

💡 [데브프리의 실무 꿀팁: 내 코드엔 synchronized가 없는데 왜 Pinning이 터질까요?]

"제가 작성한 서비스 코드에는 synchronized를 단 하나도 안 썼는데, Trace 로그를 보니 Pinning이 폭포수처럼 찍힙니다!"

범인은 바로 우리가 사용하는 서드파티 라이브러리나 DB 드라이버(JDBC) 내부 깊숙한 곳에 숨어있는 옛날 코드들입니다. 예를 들어 구버전 MySQL JDBC 드라이버나 일부 로깅 라이브러리 내부에는 여전히 synchronized가 떡하니 들어있습니다.

따라서 가상 스레드를 도입할 때는 애플리케이션 코드 수정뿐만 아니라, DB 드라이버(MySQL 8.0.33+ / 8.3+ 이상 권장) 및 주요 라이브러리 패키지들을 최신 버전으로 업데이트해주는 작업이 필수적이라는 점을 꼭 기억하세요!

 

3. 가상 스레드 도입을 위한 실무 베스트 프랙티스

단순히 설정 옵션 하나를 켜는 것으로 끝나지 않습니다. 가상 스레드의 특성을 완벽히 이해하고 아래의 원칙들을 준수해야 합니다.

• 원칙 1: 절대 가상 스레드를 풀링(Pooling)하지 마세요.
• 기존에는 스레드 생성 비용이 비싸서 ThreadPool을 만들어 재사용했습니다. 하지만 가상 스레드는 객체를 하나 생성하는 것만큼 싸고 가볍습니다. 무조건 하나의 작업당 하나의 새로운 가상 스레드(Thread-per-task)를 생성하고 쓰고 버려야 합니다.
• 원칙 2: 동시성 제한은 스레드 풀 대신 Semaphore를 쓰세요.
• 특정 외부 API로 나가는 트래픽을 50개로 제한하고 싶을 때, 기존에는 사이즈가 50인 스레드 풀을 썼습니다. 가상 스레드 환경에서는 이렇게 하시면 안 됩니다. 가상 스레드는 무한정 생성되게 내버려 두고, 로직 내부에서 java.util.concurrent.Semaphore(50)을 사용해 접근 허가증을 50개만 발급하는 방식으로 제한을 걸어야 합니다.
• 원칙 3: ThreadLocal에 무거운 데이터를 담지 마세요.
• 가상 스레드는 10만 개, 100만 개까지 동시에 띄워질 수 있습니다. 만약 스프링 시큐리티 컨텍스트나 로깅 Mapped Diagnostic Context(MDC) 같은 ThreadLocal 영역에 바이트 배열이나 엄청나게 큰 컬렉션을 캐싱해 두면, 이것이 100만 배로 복제되면서 순식간에 힙 메모리가 터져버립니다.

 

4. 전문가의 확고한 결론 (Verdict)

Java 21의 가상 스레드(Virtual Threads), 실무에 언제 도입하고 언제 피해야 할까요?

• 👍 확실한 도입 타이밍:
• 외부 결제 API 통신, 데이터베이스 쿼리, 파일 읽기/쓰기 등 I/O 작업(네트워크 통신이나 디스크 접근)이 잦고 대기 시간이 긴 백엔드 서버(REST API, MSA 게이트웨이)라면 지금 당장 테스트를 거쳐 도입하세요. WebFlux를 배우지 않고도 톰캣 기반에서 수천~수만 단위의 동시 접속자를 여유롭게 받아낼 수 있는 최고의 가성비를 자랑합니다.
• 🛑 도입을 피해야 할 때:
• 동영상 인코딩, 복잡한 암호화 해싱 알고리즘, 대규모 데이터 정렬 등 CPU를 쉴 새 없이 100% 갉아먹는 CPU-Bound(연산 집약적) 서버라면 도입해 봤자 아무런 효과가 없거나 오히려 성능이 떨어집니다. 가상 스레드는 '대기하는 시간'을 효율적으로 써서 동시성을 높이는 기술이지, CPU 연산 속도 자체를 물리적으로 높여주는 마법이 아니기 때문입니다.

가상 스레드는 분명 자바 백엔드 생태계의 판도를 바꿀 엄청난 기술입니다. 하지만 그 동작 원리와 Pinning 같은 함정을 제대로 이해하지 못하면 안 쓰느니만 못한 결과를 낳게 됩니다. 오늘 정리해 드린 베스트 프랙티스를 점검하시고, 여러분의 스프링 부트 서버에 진정한 날개를 달아보시길 바랍니다.

 

항상 팩트에 기반한 객관적인 실무 가이드로 여러분의 삽질 시간을 줄여드리겠습니다. 다음 포스팅에서도 개발자들에게 유용한 도구 최적화 팁으로 찾아뵙겠습니다!

 

👉 대규모 트래픽 처리 중 내 서버가 뻗을 위험도는? 카프카(Kafka) 리밸런싱 타임아웃 계산기 [링크]