JDK 26 (non-LTS)
Java 26, 바로 써도 된다는 말이 틀린 이유
Java 26은 2026년 3월 17일 정식 출시됐습니다. G1 GC 처리량 향상, HTTP/3 기본 지원, final 필드 경고 추가까지 — 기사 헤드라인만 보면 “써야 할 이유”로 가득합니다. 그런데 Oracle 공식 LTS 로드맵을 보면 이야기가 달라집니다. Java 26의 지원 기간은 딱 6개월입니다.
Java 26, 먼저 알아야 할 가장 중요한 사실
Java 26은 2026년 3월 17일 공개됐습니다. 기사마다 “새 기능 10가지”, “AI 연동 강화” 같은 헤드라인이 쏟아지는데, 정작 가장 중요한 한 줄은 대부분 빠져 있습니다. Oracle 공식 Java SE 지원 로드맵에는 이렇게 나옵니다.
“Java 26 (non-LTS) | GA: March 2026 | Premier Support Until: September 2026 | Extended Support: Not Available”
(출처: Oracle Java SE Support Roadmap, oracle.com/java/technologies/java-se-support-roadmap.html)
지원 기간이 6개월입니다. 프로덕션 워크로드에는 이 기간이 너무 짧습니다. 3월에 도입하면 9월에 Java 27로 다시 올려야 합니다. 그런데 대부분의 블로그 글은 이 부분을 “참고 사항” 정도로 처리하거나 아예 언급하지 않습니다.
💡 Oracle 공식 로드맵과 실제 지원 타임라인을 같이 놓고 보면, Java 26이 “새 버전”이라는 사실과 “6개월짜리 버전”이라는 사실이 동시에 성립합니다. LTS는 Java 25 (2025년 9월 출시, Premier Support 2030년까지)이고, 다음 LTS는 Java 29로 예정되어 있습니다.
결론부터 말씀드리면, 프로덕션에는 Java 25 LTS를 유지하고, Java 26은 CI 파이프라인에 추가해 하위 호환성을 테스트하는 용도가 맞습니다. 아래에서 그 이유를 하나씩 살펴봅니다.
G1 GC 개선 — 아무것도 안 해도 5~15% 빨라집니다
JEP 522: G1 GC Improve Throughput by Reducing Synchronization. 이번 릴리스에서 실질적으로 가장 체감 가능한 변경입니다. 기존에는 애플리케이션 스레드와 GC 스레드가 단일 카드 테이블을 공유했습니다. 쓰기 장벽(write barrier)이 발생할 때마다 두 스레드가 동기화해야 했고, 이 오버헤드가 누적됐습니다.
Java 26은 카드 테이블을 둘로 나눕니다. 각 스레드가 자기 테이블을 쓰고, 동기화 비용이 사라집니다. 결과는 레퍼런스가 많은 워크로드에서 처리량 5~15% 향상입니다. HTTP 요청, JPA 엔티티 로드, 서비스 레이어에서 생성하는 객체 — 대부분의 Spring Boot 애플리케이션이 여기 해당합니다. (출처: dev.to/paszekdev, Java 26 Is Out — Here’s What Actually Matters for Spring Boot Developers, 2026.03.17)
💡 G1은 JDK 9부터 기본 GC입니다. 설정 변경 없이 JDK만 올려도 이 개선이 적용됩니다. 추가 하드웨어 없이 처리량이 오릅니다.
한 가지 더. Java 25에서는 Compact Object Headers (JEP 450)가 도입됐습니다. 객체 헤더 크기가 12~16바이트에서 8바이트로 줄어 힙 사용량이 약 22% 감소합니다. Java 21에서 Java 25 LTS로 올라가는 것만으로도 G1 개선 + Compact Headers가 동시에 적용됩니다. Java 26의 G1 개선은 Java 25 LTS 기반 위에 추가로 쌓이는 것이지만, 앞서 말한 대로 6개월 지원 제약이 있습니다.
지금 Java 21에 있다면 Java 25 LTS로의 마이그레이션 계획을 세우는 것이 훨씬 실용적입니다.
final 필드는 처음부터 불변이 아니었습니다
JEP 500: Prepare to Make Final Mean Final. 이름이 재미있습니다. “final이 진짜 final이 되도록 준비한다”는 뜻입니다. 다시 말해, 지금까지 Java의 final은 실제로 불변이 아니었다는 뜻입니다.
JDK 5부터 deep reflection API(Field.setAccessible(true) + Field.set())를 쓰면 final 필드를 마음대로 바꿀 수 있었습니다. JEP 500 원문은 이렇게 정리합니다.
Field f = C.class.getDeclaredField("x");
f.setAccessible(true);
f.set(obj, 200); // final 필드를 200으로 변경
f.set(obj, 300); // 다시 300으로 변경 — 완전히 동작했습니다
(출처: OpenJDK JEP 500 공식 원문, openjdk.org/jeps/500)
Java 26부터는 이 패턴을 실행하면 다음과 같은 경고가 출력됩니다.
WARNING: Final field C.x has been mutated reflectively by class com.foo.Bar
WARNING: Use --enable-final-field-mutation=N to avoid a warning
WARNING: Mutating final fields will be blocked in a future release
지금은 경고(warn)지만, 미래 버전에서 예외(deny)로 바뀝니다. 타임라인은 아직 공개되지 않았습니다. 실질적으로 영향받는 라이브러리는 Hibernate 일부 설정, Mockito spy, Lombok, 직렬화 프레임워크 등입니다. Spring Framework 7.0은 이미 내부 리플렉션 사용을 정리해 두었습니다.
💡 지금 당장 할 일은 간단합니다. CI에 Java 26을 추가하고, --illegal-final-field-mutation=deny 플래그로 실행해보면 앞으로 문제가 될 코드가 어디에 있는지 미리 확인할 수 있습니다.
이 부분이 Java 26의 기능 중 가장 조용히 폭탄이 될 수 있습니다. 기능이 추가된 게 아니라 기존에 허용됐던 것이 막히는 방향이기 때문입니다.
HTTP/3가 JDK 안으로 들어왔습니다
JEP 517: HTTP/3 for the HTTP Client API. JDK 11에 추가된 HttpClient가 드디어 HTTP/3(QUIC 기반)를 지원합니다. 외부 라이브러리 없이 설정 한 줄로 활성화됩니다.
HttpClient client = HttpClient.newBuilder()
.version(HttpClient.Version.HTTP_3)
.build();
서버가 HTTP/3를 지원하지 않으면 HTTP/2로 자동 폴백합니다. Netty나 별도 QUIC 라이브러리 설정이 필요 없습니다. (출처: OpenJDK JEP 517 공식 원문, openjdk.org/jeps/517)
실제로 체감이 큰 케이스는 AI 추론 엔드포인트, 결제 게이트웨이 연동, 높은 동시성을 요구하는 외부 API 호출입니다. HTTP/3의 핵심 이점은 HOL(Head-of-Line) 블로킹 제거입니다. 하나의 느린 요청이 같은 커넥션 뒤에 줄 서 있는 요청 전체를 막는 현상이 없어집니다.
주의할 점은 WebFlux + Reactor Netty 조합에서는 이 설정이 적용되지 않는다는 겁니다. Netty는 자체적인 HTTP/3 로드맵을 따릅니다. RestClient를 JDK HttpClient 백엔드로 사용하는 경우에만 JEP 517의 혜택이 바로 적용됩니다.
Java 21 무료 라이선스, 2026년 9월에 끝납니다
Java 26 이야기를 하다가 왜 Java 21 이야기가 나오냐고 할 수 있습니다. Oracle 공식 로드맵을 보면 이 두 가지가 연결됩니다.
| 버전 | LTS 여부 | 무료 라이선스 종료 | Premier Support 종료 |
|---|---|---|---|
| Java 21 | ✅ LTS | 2026년 9월 | 2028년 9월 |
| Java 25 | ✅ LTS | 현재 무료 | 2030년 9월 |
| Java 26 | ❌ non-LTS | 해당 없음 | 2026년 9월 |
(출처: Oracle Java SE Support Roadmap, oracle.com/java/technologies/java-se-support-roadmap.html, 2026.03 기준)
Oracle JDK 21은 2026년 9월 이후부터 Java SE OTN 라이선스(상업적 사용 유료)로 전환됩니다. 지금 Java 21 Oracle JDK로 프로덕션을 운영 중이라면 이 시점 전에 Java 25 LTS 또는 OpenJDK 계열(Eclipse Temurin, Amazon Corretto 등)로 넘어가는 계획을 세워야 합니다.
💡 Oracle이 아닌 OpenJDK 배포판(Adoptium, Amazon Corretto, Microsoft Build of OpenJDK 등)은 각 배포판 자체 지원 정책을 따르므로 별도로 확인해야 합니다. Oracle JDK 기준 로드맵입니다.
Java 26이 새 버전이라는 사실보다, Java 21의 무료 라이선스가 6개월 안에 끝난다는 사실이 실제 프로덕션 환경에서는 훨씬 더 직접적인 의미를 가집니다.
UUID.randomUUID()를 지금도 쓰고 있다면
JEP는 아니지만 실무에서 바로 쓸 수 있는 변경 하나를 짚고 넘어갑니다. Java 26에서 UUID.ofEpochMillis(long timestamp) 메서드가 표준 라이브러리에 추가됐습니다.
기존 UUID.randomUUID()는 버전 4로, 128비트가 완전 무작위입니다. 데이터베이스 기본 키로 쓰면 모든 insert가 B-tree 인덱스의 무작위 위치에 들어가 인덱스 단편화가 생깁니다. 테이블이 커질수록 성능 저하가 가시화됩니다.
// 기존 방식 — 완전 무작위, B-tree 단편화 유발
UUID id = UUID.randomUUID();
// Java 26 방식 — 시간 순 정렬, 새 레코드는 항상 인덱스 끝에 삽입
UUID id = UUID.ofEpochMillis(System.currentTimeMillis());
UUID.ofEpochMillis()는 UUIDv7 사양을 따르며 첫 비트에 밀리초 타임스탬프가 들어갑니다. 새 레코드가 항상 인덱스의 끝에 삽입되므로 B-tree 재구성 빈도가 줄어듭니다. 외부 라이브러리(ulid, tsid 등) 없이 표준 API만으로 해결됩니다.
다만 이 메서드는 Java 26에서 추가된 것이므로, 앞서 언급한 대로 프로덕션에서 바로 쓰려면 버전 지원 계획이 먼저입니다. Java 29 LTS 이후를 타깃으로 삼거나, 지금은 미리 코드를 검토해두는 수준이 현실적입니다.
Q&A
Q1. Java 26을 프로덕션에 바로 올려도 될까요?
Q2. JEP 500 경고가 지금 당장 예외로 바뀌나요?
--illegal-final-field-mutation=deny로 실행해 영향받는 코드를 미리 찾아두는 것이 실용적입니다.
Q3. Java 21에서 Java 25 LTS로 올리면 뭐가 달라지나요?
Q4. Structured Concurrency는 언제 정식 확정되나요?
onTimeout()이 Joiner에 추가됐습니다. 확정 시점은 공식 발표가 없습니다. Vector API도 열한 번째 인큐베이터이며, Project Valhalla의 Value Classes를 기다리고 있습니다.
Q5. Applet API 제거(JEP 504)가 내 프로젝트에 영향이 있나요?
마치며
Java 26은 기능 면에서는 꽤 실속 있습니다. G1 GC 처리량 향상은 코드 한 줄 안 바꿔도 나오고, HTTP/3 지원은 외부 의존성 없이 쓸 수 있고, UUIDv7 메서드 추가는 오래된 인덱스 단편화 문제를 표준 API 수준에서 해결합니다.
그런데 non-LTS라는 사실이 이 모든 것 앞에 붙는 조건입니다. Oracle 공식 로드맵은 명확합니다. Java 26의 지원은 2026년 9월에 끝납니다. 지금 프로덕션에 Java 21 Oracle JDK를 쓰고 있다면 무료 라이선스 종료(2026년 9월)가 Java 26 출시보다 더 급한 숙제입니다.
Java 26에서 가장 주목해야 할 것은 JEP 500의 final 필드 경고입니다. 기능이 새로 생긴 게 아니라 기존에 허용됐던 것이 막히는 방향이고, Hibernate, Mockito, Lombok 같은 범용 라이브러리가 영향권에 있습니다. 지금 CI에 추가해 로그를 확인해두는 것이 이 버전을 가장 잘 쓰는 방법입니다.
솔직히 말하면, Java 26은 “써야 하는 버전”이 아니라 “준비해야 하는 버전”입니다. 다음 LTS인 Java 29(2027년 9월 예정)를 향해 기능이 하나씩 굳어지는 과정입니다. 지금은 LTS를 지키면서, 변화를 CI로 먼저 체험해두는 것이 제일 실용적인 선택입니다.
본 포스팅 참고 자료
- Oracle 공식 발표 — oracle.com/kr/news/announcement/oracle-releases-java-26-2026-03-17/
- OpenJDK JDK 26 공식 릴리스 페이지 — openjdk.org/projects/jdk/26/
- Oracle Java SE Support Roadmap — oracle.com/java/technologies/java-se-support-roadmap.html
- OpenJDK JEP 500 공식 원문 — openjdk.org/jeps/500
- Oracle Java 26 기술 블로그 — blogs.oracle.com/java/the-arrival-of-java-26
※ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 모든 수치 및 지원 일정은 Oracle 공식 문서 기준이며, Oracle의 단독 재량으로 변경될 수 있습니다. 본 포스팅 기준일: 2026년 3월 23일 / JDK 26 GA 기준 (2026.03.17).
댓글 남기기