JDK 21 vs 25, 2026년 LTS 선택 기준 정리

JDK 21 vs 25, 2026년 LTS 선택 기준 정리

2026년 7월 기준 Java 최신 LTS는 JDK 25, 직전 LTS는 JDK 21입니다. 결론부터 말하면 신규 프로젝트는 JDK 25로 시작하고, 이미 JDK 21에서 안정 운영 중이라면 2026~2027년 사이에 25 전환을 계획하는 것이 가장 균형 잡힌 선택입니다. 특히 Oracle JDK 21의 무상 상업 사용(NFTC) 기간이 2026년 9월에 종료되기 때문에, Oracle JDK를 무료로 써온 조직이라면 올해 하반기가 사실상 결정 시점입니다.

이번 글에서는 두 LTS의 핵심 차이, 21→25 업그레이드에서 주의할 호환성 변화, 상황별 선택 기준을 정리합니다.

JDK 21 vs JDK 25 한눈에 비교

항목	JDK 21	JDK 25
GA	2023년 9월 19일	2025년 9월 16일
포함 JEP	15개	18개
핵심 키워드	Virtual Threads, Pattern Matching, Generational ZGC	Compact Object Headers, AOT 최적화, Scoped Values
Oracle 무상 사용(NFTC)	2026년 9월까지	2028년 9월까지
Amazon Corretto 지원	2030년 10월까지	2032년 10월까지

JDK 21 - 동시성 모델의 전환점

JDK 21의 무게중심은 Virtual Threads입니다. 스레드 풀 튜닝 없이 thread-per-request 모델을 저렴하게 쓸 수 있게 되면서, I/O 중심 서버 애플리케이션의 동시성 설계가 근본적으로 바뀌었습니다. New Relic의 2024년 보고서 기준 Java 21은 출시 후 6개월 채택률이 Java 17 대비 287% 높았을 만큼 확산 속도도 이례적이었습니다.

// JDK 21 - Virtual Threads
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i ->
            executor.submit(() -> callExternalApi(i)));
}

여기에 Pattern Matching for switch, Record Patterns, Sequenced Collections가 데이터 지향 코딩 스타일을 강화했고, Generational ZGC가 짧게 사는 객체를 더 자주 수집해 저지연 GC 선택지를 넓혔습니다.

JDK 25 - 운영 효율의 성숙 단계

JDK 25는 화려한 신문법보다 메모리·시작 시간·관측성 개선이 중심입니다.

• Compact Object Headers(JEP 519): 객체 헤더를 64비트로 줄여 메모리 사용량과 데이터 지역성을 개선합니다. 컨테이너 밀도가 중요한 환경에서 특히 유효합니다.
• AOT Command-Line Ergonomics / Method Profiling(JEP 514·515): AOT 캐시를 쉽게 만들어 애플리케이션 시작 시간을 단축합니다.
• Scoped Values 정식화(JEP 506): Virtual Threads 시대의 ThreadLocal 대안입니다.
• JFR CPU-Time Profiling / Method Timing & Tracing(JEP 509·520): 운영 환경 프로파일링 정확도가 올라갑니다.
• Generational Shenandoah 제품화(JEP 521): 저지연 GC 선택지가 하나 더 늘었습니다.

Virtual Threads의 대표적 약점이던 synchronized pinning 문제도 JDK 24(JEP 491)에서 완화됐기 때문에, 25는 "가상 스레드를 일상 코드 스타일로 쓸 수 있게 다듬은 기준선"이기도 합니다. 문법 쪽에서는 Compact Source Files(JEP 512)와 Flexible Constructor Bodies(JEP 513)가 정식화됐습니다.

// JDK 25 - Compact Source Files (JEP 512)
void main() {
    IO.println("Hello, JDK 25");
}

21 → 25 업그레이드에서 주의할 것

21에서 25로 가는 길의 진짜 변수는 신기능이 아니라 누적된 기본값 강화입니다.

1. Security Manager 영구 비활성화(JDK 24) - 정책 파일 기반 샌드박스에 의존하던 코드는 대체 보안 통제 설계가 필요합니다.
2. 32-bit x86 포트 제거(JDK 25, JEP 503) - 해당 플랫폼 의존이 남아 있으면 25로 갈 수 없습니다.
3. JNI·네이티브 접근 통제 강화 - --enable-native-access 정책을 미리 설계하지 않으면 경고가 누적되고, 향후 버전에서 예외로 강화될 수 있습니다.
4. 동적 에이전트 로딩 경고 - APM 에이전트를 attach 방식으로 붙이는 환경이라면 -XX:+EnableDynamicAgentLoading 정책화가 필요합니다.

업그레이드 전에 jdeprscan --release 25로 제거 예정 API를, jdeps로 JDK 내부 API 의존을 먼저 스캔해 두면 문제 면적을 크게 줄일 수 있습니다.

상황별 선택 기준

신규 프로젝트 → JDK 25. Spring Framework 7.x는 생산 환경에 JDK 25 이상을 권장하고, Spring Boot 4.1은 Java 26까지 호환됩니다. 실제로 제가 운영 중인 kraft.io.kr도 Java 25 + Spring Boot 4.1 조합에서 Virtual Threads를 문제없이 사용하고 있습니다.

JDK 21 안정 운영 중 → 2026년 안에 경로 결정. Oracle JDK 무료 사용 기준이라면 2026년 9월 전에 ① JDK 25로 업그레이드하거나 ② Amazon Corretto 같은 OpenJDK 배포판으로 전환해야 합니다. Corretto는 JDK 21을 2030년 10월까지 무상 지원하므로 "배포판만 바꾸고 21을 유지"하는 전략도 유효합니다.

JDK 8/11 레거시 → 중간 착지 후 25. 모듈 시스템, 강한 캡슐화, Java EE/CORBA 제거 이슈가 한꺼번에 몰리므로 25로 직행하기보다 17 또는 21에서 의존성·반사 접근 문제를 먼저 정리한 뒤 올리는 편이 실패 확률이 낮습니다.

마무리

다음 LTS는 2027년 9월 예정인 JDK 29입니다(Java 26·27·28은 비-LTS). 즉 2026~2028년 Java 표준화의 축은 사실상 21 → 25 → 29로 이어집니다. JDK 21도 여전히 훌륭한 운영 기준선이지만, 지원 수명·라이선스 창·프레임워크 생태계 정렬까지 종합하면 지금 새 기준선을 정하는 조직의 답은 JDK 25입니다.

Java 버전 전체를 아우르는 선택 기준은 2026년 Java 버전 선택 가이드에서, 25의 신규 기능을 코드로 더 깊이 보고 싶다면 Java 25 LTS 신규 기능 정리에서 확인할 수 있습니다.