Java 21이 정식 출시되면서 가장 주목받은 기능 중 하나는 Virtual Thread입니다.
기존 Java 서버는 요청마다 플랫폼 스레드를 사용하기 때문에 동시 요청이 증가하면 스레드 수와 메모리 사용량이 빠르게 늘어나는 문제가 있었습니다.
Java 21의 Virtual Thread는 이러한 문제를 해결하기 위해 등장한 경량 스레드(Lightweight Thread)입니다.
최근 Spring Boot 3.2 프로젝트에서 Virtual Thread를 테스트하며 느낀 점과 적용 시 고려해야 할 사항을 정리해 보았습니다.
기존 Java Thread는 운영체제 스레드(OS Thread)와 1:1로 연결됩니다.
즉, 요청이 많아질수록 스레드 생성 비용과 메모리 사용량이 증가합니다.
반면 Virtual Thread는 JVM이 관리하는 경량 스레드입니다.
쉽게 말해
기존 방식
🔹 요청 1개 = OS Thread 1개
Virtual Thread
🔹 요청 1개 = Virtual Thread 1개
OS Thread를 훨씬 효율적으로 활용할 수 있습니다.
Spring Boot 3.2에서는 설정 한 줄만 추가하면 됩니다.
spring:
threads:
virtual:
enabled: true
생각보다 너무 간단해서 놀랐습니다.
설정 자체는 10초도 걸리지 않습니다.
결론부터 말하면
"모든 프로젝트가 빨라지는 것은 아니다"
입니다.
Virtual Thread가 효과를 발휘하는 영역은 CPU 작업이 아니라 I/O 작업입니다.
예를 들어
✅ DB 조회
✅ 외부 API 호출
✅ 파일 처리
✅ 메일 발송
✅ 정산 API 연동
같이 기다리는 시간이 많은 작업에서는 확실한 효과를 기대할 수 있습니다.
최근 정산 시스템 구축 과정에서
흐름을 처리하는 API를 테스트했습니다.
실제 병목은 계산 로직보다
PG API 응답 대기
DB 조회
외부 시스템 호출
에서 발생했습니다.
Virtual Thread 적용 후에는 요청이 몰리는 상황에서도 응답 지연이 줄어드는 것을 확인할 수 있었습니다.
Virtual Thread를 적용하면 많은 요청을 받을 수 있습니다.
하지만 DB 커넥션 풀이 그대로라면 의미가 없습니다.
예를 들어
동시 요청 1000개
DB Connection Pool 20개
라면 결국 대부분의 요청은 DB 연결을 기다리게 됩니다.
Virtual Thread는 만능 해결책이 아니라는 점을 다시 느꼈습니다.
Virtual Thread는 Java 21 이상이 필요합니다.
Spring Boot 3.2부터 공식 지원됩니다.
오래된 라이브러리는 Virtual Thread 환경에서 예상치 못한 문제가 발생할 수 있습니다.
특히
는 테스트가 필요합니다.
설정만 변경하고 운영에 반영하는 것은 위험합니다.
반드시
📊 TPS
📊 응답 시간
📊 CPU 사용량
📊 메모리 사용량
📊 DB Connection Pool
을 함께 확인해야 합니다.
개인적으로는
"Java 21 + Spring Boot 3.2 이상이라면 검토할 가치가 충분하다"
고 생각합니다.
특히
에서는 적용해 볼 만합니다.
다만 모든 프로젝트를 무조건 Virtual Thread로 바꾸기보다는 현재 서비스의 병목 지점이 어디인지 먼저 확인하는 것이 중요합니다.
Virtual Thread는 Java 생태계에서 상당히 큰 변화입니다.
과거에는 동시성 문제를 해결하기 위해 Reactive Programming, WebFlux 같은 복잡한 접근이 필요했지만, 이제는 상대적으로 익숙한 방식으로도 높은 동시성을 처리할 수 있게 되었습니다.
다만 기술 자체보다 중요한 것은 서비스의 특성을 이해하는 것입니다.
Virtual Thread도 결국 하나의 도구일 뿐이며, 어떤 문제를 해결하려고 하는지 먼저 정의하는 것이 더 중요합니다.