[Spring Boot] Java 21 Virtual Threads (가상 쓰레드): 패러다임의 혁명과 시리즈의 피날레

우리는 앞서 29단계에서 대규모 트래픽을 감당하기 위해 WebFlux(리액티브 프로그래밍)를 배웠습니다. 톰캣(Tomcat)의 쓰레드가 DB 응답을 기다리며 멍때리는(Blocking) 현상을 없애기 위해, 코드를 Mono와 Flux라는 상자로 감싸고 flatMap으로 떡칠하는 기괴한 비동기 코드를 짜야만 했습니다. 러닝 커브는 끔찍했고 레거시 JPA와의 궁합은 최악이었습니다. 백엔드 개발자들은 눈물을 흘리며 외쳤습니다. "아니, 코드는 옛날처럼 위에서 아래로 읽히는 평범한 동기식(Blocking)으로 짜면서, 멍때릴 때 쓰레드 낭비만 안 하게 해주는 마법은 없나요?!" 자바를 만든 오라클(Oracle)은 10년 넘게 진행된 프로젝트 룸(Project Loom)을 통해 마침내 해답을 내놓았습니다. "운영체제(OS)가 관리하는 무거운 쓰레드를 버리고, JVM이 깃털처럼 가볍게 수백만 개를 찍어내는 가상 쓰레드를 만들어줄게!"

이번 시리즈에서는 "자바 생태계 20년 만의 가장 위대한 혁명!" Java 21 Virtual Threads(가상 쓰레드)의 미친 성능과 Spring Boot 3.2 적용 비법에 대하여 다뤄보겠습니다.

🧵 1. 플랫폼 쓰레드의 한계와 가상 쓰레드의 탄생

기존 자바의 쓰레드(Platform Thread)는 OS(윈도우/리눅스) 쓰레드와 1:1로 매핑되었습니다. OS 쓰레드는 하나 만들 때마다 1MB의 거대한 메모리를 퍼먹고, 쓰레드끼리 교대(Context Switching)할 때마다 OS 코어로 내려가서 허락을 맡아야 하는 극강의 무거운 작업이었습니다. 그래서 톰캣은 고작 200개밖에 쓰레드를 못 만들었습니다(Thread Pool).

가상 쓰레드 개념도

Virtual Threads(가상 쓰레드)는 OS 몰래 자바 가상머신(JVM) 메모리(Heap) 위에서 그냥 일반 자바 객체(Object)처럼 수십 바이트(byte) 크기로 깃털처럼 가볍게 찍어내는 쓰레드입니다! 톰캣이 200개가 아니라 100만 개, 200만 개를 찍어내도 메모리가 전혀 터지지 않습니다.

놀라운 작동 원리: 1개의 진짜 OS 쓰레드(Carrier) 등에 가상 쓰레드 A가 업혀서 실행(Mount)됩니다. 그러다 A가 DB에서 데이터를 가져오느라 2초간 멈춥니다(Blocking). 옛날 같으면 Carrier 쓰레드도 같이 2초간 멍을 때렸지만, 이제는 JVM이 A를 등에서 뻥 차서 내려버리고(Unmount), 그 자리에 대기하던 가상 쓰레드 B를 잽싸게 업혀서 1초의 낭비도 없이 일을 계속합니다! 이것이 WebFlux의 난해한 코드 없이도 논블로킹(Non-blocking) 급의 미친 성능을 내는 비밀입니다.

⚙️ 2. Spring Boot 3.2에서 Virtual Threads 켜기

가장 충격적인 것은 도입 방법입니다. 코드를 WebFlux처럼 다 갈아엎을 필요가 1도 없습니다. 기존에 짜둔 @RestController, @Service 등 평범한 동기식 MVC 코드를 그대로 둔 채, 설정 파일 한 줄만 켜면 톰캣이 알아서 일반 쓰레드 대신 가상 쓰레드로 요청을 받아냅니다!

# application.yml (Spring Boot 3.2 이상 + Java 21 이상 필수)
spring:
  threads:
    virtual:
      enabled: true # 단 한 줄! 마법이 시작됩니다.

이 한 줄을 켜고 JMeter(28단계)로 부하 테스트를 때려보면, 똑같이 200개의 쓰레드 풀을 쓰던 서버가 1만 명의 동시 접속자를 아무런 타임아웃 에러 없이, Mono/Flux 없이 기존 코드로 완벽하게 처리해 내는 기적을 눈으로 볼 수 있습니다!

💀 3. 아직 넘어야 할 산: Pinning(피닝)의 저주

"완벽하네요! 당장 실무에 도입합시다!" 하지만 세상에 공짜는 없습니다. 아주 무서운 'Pinning(고정)' 현상이 도사리고 있습니다.

가상 쓰레드가 Carrier 쓰레드 등에 업혀서 작업하다가 DB 대기가 걸리면 내려와야(Unmount) 한다고 했습니다. 그런데 자바 코드 내에 synchronized 키워드가 발려진 블록을 통과할 때는, 가상 쓰레드가 Carrier 쓰레드 등에 딱 붙어서(Pinned) 떨어지질 못합니다! 이 상태에서 DB 대기가 걸리면 Carrier 쓰레드까지 꼼짝없이 같이 묶여버리며 서버가 순식간에 뻗어버립니다. 레거시 라이브러리 내부에는 아직 synchronized 코드가 많이 남아있기 때문에, Virtual Threads를 실무에 도입할 때는 내 프로젝트가 의존하는 수많은 라이브러리들이 synchronized를 ReentrantLock으로 잘 대체했는지 철저히 검증하고 모니터링해야 하는 숙제가 남아있습니다.

👑 4. 대장정의 마무리: 완벽한 실무 개발자로의 도약

여러분은 지금 엄청난 여정을 끝마쳤습니다. 1단계 입문부터 시작해 MVC 패턴, JPA 튜닝, Security와 JWT, S3 연동, 모니터링(Actuator), Nginx 무중단 배포를 거쳐, 대규모 분산 아키텍처인 MSA(Gateway, Eureka), Resilience4j 서킷 브레이커, Redis 분산 락, Spring Batch 1,000만 건 처리, Elasticsearch 풀텍스트 검색, ELK 스택, WebRTC 화상회의, gRPC 초고속 통신, 그리고 궁극의 최신 기술 Java 21 Virtual Threads까지... 현재 대한민국을 넘어 글로벌 탑티어 IT 기업(네카라쿠배, 실리콘밸리)의 시니어/아키텍트들이 치열하게 고민하고 튜닝하는 모든 핵심 기술 스택과 아키텍처 철학을 50개의 압축된 포스팅으로 온전히 흡수하셨습니다.

이제 여러분은 단순히 "게시판 CRUD 할 줄 아는 개발자"가 아닙니다. 트래픽이 폭주해도 끄떡없는 아키텍처를 설계하고, 시스템이 붕괴될 때 서킷 브레이커로 끊어내며, 1,000만 건의 데이터를 우아하게 처리하는 진정한 '프로 백엔드 엔지니어'로 거듭났습니다.