비 LTS인데 왜 지금 봐야 할까요

결론부터 말씀드리면, Java 26 신기능 중 HTTP/3 지원(JEP 517)은 프리뷰가 아닌 정식 확정 기능으로 들어왔습니다. 비 LTS라도 정식 확정된 기능은 다음 LTS에 그대로 인계됩니다. 지금 코드베이스를 점검하지 않으면, Java 27 LTS로 올라갈 때 갑자기 대응해야 하는 상황이 됩니다.

Oracle은 2026년 9월 Java 27 출시 전까지만 Java 26에 업데이트를 제공합니다. (출처: Oracle 공식 블로그, 2026.03.17) 즉 프로덕션 적용보다는, 지금 미리 테스트 환경에서 신기능을 검증해두는 것이 핵심입니다.

6개월 릴리스 주기는 Java 9 이후 17번째 정시 납기를 달성했습니다. (출처: Oracle Java Blog, 2026.03.17) 예측 가능성이 생겼다는 뜻입니다.

▲ 목차로 돌아가기

G1 GC 처리량 개선 — 숫자로 직접 확인했습니다

JEP 522는 G1 가비지 컬렉터의 카드 테이블 구조를 하나에서 둘로 늘렸습니다. 당장 코드를 바꿀 필요도 없고, JVM 플래그 하나 추가할 것도 없습니다. Java 26으로 올리면 자동으로 적용됩니다.

핵심 아이디어는 단순합니다. 애플리케이션 스레드는 첫 번째 카드 테이블에 동기화 없이 자유롭게 쓰고, GC 옵티마이저 스레드는 두 번째 테이블을 따로 처리합니다. 일시정지 목표를 초과할 것 같으면 두 테이블을 원자적으로 교체(swap)합니다.

여기서 눈여겨볼 수치가 있습니다. 추가 메모리 비용이 힙 1GB당 약 2MB입니다. Java 20 이전에 G1이 같은 용도로 소비하던 메모리의 8분의 1 수준입니다. (출처: 위키독스 JEP 522 분석, 2026.03) 성능은 올라가고 메모리는 줄었습니다.

객체 참조를 자주 변경하는 웹 서버나 DB 연동 애플리케이션이라면 5~15% 처리량 향상이 트래픽 기준으로는 같은 하드웨어에서 더 많은 요청을 처리할 수 있다는 의미입니다.

▲ 목차로 돌아가기

HTTP/3 지원, 코드 변경 없이 된다고요?

JEP 517이 Java 26에서 정식 확정됐습니다. Java 11에 도입된 HttpClient API가 드디어 HTTP/3을 지원합니다. 기존 코드의 HttpClient를 그대로 쓰면 됩니다. API 구조가 바뀌지 않았기 때문입니다.

단, 여기서 생각보다 조건이 붙습니다. HTTP/3은 TCP가 아닌 UDP 기반 QUIC 위에서 돌아가기 때문에, 기존 HTTP/1.1·HTTP/2 연결을 HTTP/3으로 “업그레이드”하는 게 불가능합니다. Java는 이 문제를 4가지 협상 전략으로 해결했습니다.

기본값은 ③ 발견 방식입니다. 전 세계 웹 트래픽의 약 3분의 1이 이미 HTTP/3을 쓰고 있는 상황에서 (출처: 위키독스 JEP 517 분석, 2026.03), Java가 뒤늦게 따라간 건 맞습니다. 하지만 Go나 Node.js 생태계와 달리 4가지 전략을 구현해 완전한 솔루션을 제공했다는 점이 눈에 띕니다.

마이크로서비스 간 통신이나 서드파티 API 호출이 잦은 서버라면, 발견 방식 기본값 하나만으로도 지연 시간 개선이 생깁니다. 서버가 HTTP/3을 지원하는 경우에 한해서입니다.

▲ 목차로 돌아가기

AOT 캐시가 ZGC와 만났을 때 생기는 일

JEP 516은 앞서 Java 24에서 도입된 AOT(Ahead-of-Time) 객체 캐시를 모든 GC에서 쓸 수 있도록 확장했습니다. 이전까지는 G1으로 훈련한 캐시를 ZGC에서 재사용하는 게 안 됐습니다. GC마다 캐시를 저장하는 방식이 달랐기 때문입니다.

이게 실무에서 왜 중요하냐면, ZGC는 tail latency(요청 처리 시간의 꼬리 분포)에 민감한 서비스에서 선택하는 GC입니다. 저지연이 중요한 실시간 시스템에서 ZGC를 쓰면서도 AOT 캐시로 시작 시간을 단축하는 조합이 Java 25까지는 불가능했습니다.

컨테이너 환경에서 Java의 약점이 “느린 시작”이었는데, AOT 캐시 + ZGC 조합은 그 약점을 정면으로 공략합니다. Go나 Node.js와의 시작 시간 격차가 실질적으로 좁혀지는 지점입니다.

▲ 목차로 돌아가기

final 경고가 단순 경고가 아닌 이유

JEP 500은 리플렉션으로 final 필드를 변경하려 할 때 경고를 내보냅니다. 지금까지 DI 프레임워크, 직렬화 라이브러리, 모킹 도구들이 Field.setAccessible(true) 후 Field.set()으로 final 필드를 바꾸는 방식을 광범위하게 써왔습니다.

그런데 이 경고가 단순한 보안 정책 강화가 아닙니다. Project Valhalla와 직결된 선행 조건입니다. Valhalla가 목표로 하는 value class(힙 할당 없이 사용하는 경량 객체 타입)는 JVM이 객체의 불변성을 완전히 신뢰할 수 있어야 구현 가능합니다. final이 리플렉션으로 언제든 바뀔 수 있는 현재 상태에서는 value class 최적화가 불가능하기 때문입니다.

다시 말해, JEP 500 경고를 무시하고 넘어가면 Java 27 이후 Valhalla 기반 최적화가 들어오는 시점에 코드베이스 전체에서 예외가 터질 수 있습니다. 지금이 대응 타이밍입니다.

▲ 목차로 돌아가기

Vector API 11번째 인큐베이터 — 기다림의 진짜 이유

Vector API(JEP 529)는 Java 16에서 첫 인큐베이터로 등장한 이후 Java 26에서 열한 번째 인큐베이터를 기록했습니다. 5년이 지났는데 아직 정식 확정이 안 됐습니다. 왜일까요?

공식 문서에 이유가 나와 있습니다. Vector API는 Project Valhalla의 value type이 프리뷰 단계에 들어올 때까지 인큐베이션 상태를 유지한다고 명시되어 있습니다. (출처: OpenJDK JEP 529 공식 문서) Value type이 도입되면 벡터를 힙 할당 없이 진정한 값 객체로 표현할 수 있게 되는데, 그 이전에 API를 확정해버리면 나중에 더 나은 구조로 바꿀 수 없게 됩니다.

그래도 Vector API는 지금도 쓸 수 있습니다. AI 추론, 데이터 분석, 과학 컴퓨팅 워크로드에서 SIMD 명령어를 활용해 동등한 스칼라 연산보다 훨씬 빠른 성능을 냅니다. 인큐베이터 상태라도 API가 불안정하다는 뜻이 아니라, 향후 value type 도입 시 API 형태가 더 좋아질 수 있다는 의미입니다.

▲ 목차로 돌아가기

Lazy Constants와 Structured Concurrency 현황

Lazy Constants (JEP 526) — 두 번째 프리뷰

Java 25에서 “Stable Values”라는 이름으로 첫 프리뷰를 거쳤고, Java 26에서 “Lazy Constants”로 이름을 바꿔 두 번째 프리뷰로 들어왔습니다. 이름만 바뀐 게 아닙니다. API 구조도 크게 정리됐습니다.

핵심은 static final의 성능과 지연 초기화의 유연성을 동시에 얻는 것입니다. 기존에는 초기화를 나중으로 미루려면 가변 필드를 써야 했고, 그러면 JVM의 상수 접기(constant folding) 최적화를 포기해야 했습니다. Lazy Constant를 쓰면 첫 번째 get() 호출 시에만 초기화되고, 이후 JVM이 진짜 상수로 취급합니다.

이번 프리뷰에서 눈에 띄는 변화는 Lazy List와 Lazy Map의 팩토리 메서드가 List.ofLazy(), Map.ofLazy()처럼 표준 컬렉션 인터페이스 안으로 들어온 것입니다. IDE 자동 완성에서 바로 찾을 수 있게 됐습니다.

Structured Concurrency (JEP 525) — 여섯 번째 프리뷰

Java 21에서 가상 스레드(Virtual Threads)가 정식 확정됐고, Structured Concurrency는 그 위에서 동시성 코드를 더 안전하게 쓰기 위한 API입니다. 여섯 번째 프리뷰인 만큼 API 형태는 사실상 완성에 가깝습니다.

이번 변경에서는 Joiner 인터페이스에 onTimeout() 메서드가 추가됐고, allSuccessfulOrThrow()가 스트림 대신 리스트를 반환하도록 바뀌었습니다. (출처: OpenJDK JEP 525 공식 문서)

async/await 방식과 달리, 비동기 함수와 동기 함수를 구분하는 “colored function” 문제가 없습니다. 가상 스레드 기반으로 블로킹 코드를 그대로 써도 성능이 나옵니다. 복잡한 서비스 오케스트레이션 코드를 구현해야 한다면 지금 바로 테스트해볼 만합니다.

▲ 목차로 돌아가기

Java 26, 프로덕션에서 어떻게 활용해야 할까요

솔직히 말하면, 프로덕션 서비스를 Java 26으로 올리는 건 권장하지 않습니다. 2026년 9월 Java 27 출시와 함께 업데이트가 끊기기 때문입니다. 비 LTS의 특성상 보안 패치도 9월 이후로는 제공되지 않습니다.

하지만 아래 방식은 지금 당장 실무에 적용할 수 있습니다.

개인적으로 이 릴리스에서 가장 주목한 건 HTTP/3 정식 확정과 AOT + ZGC 조합입니다. 화려한 기능이 아니라도, 컨테이너 환경에서 Java의 경쟁력을 실질적으로 높이는 변화이기 때문입니다.

▲ 목차로 돌아가기

자주 묻는 질문

▲ 목차로 돌아가기

마치며

Java 26은 화려한 릴리스가 아닙니다. 직접 공식 문서를 들여다보면, 이 릴리스의 절반은 Project Valhalla를 위한 바닥 공사입니다. JEP 500이 final 불변성을 정비하고, JEP 526이 지연 초기화를 상수 수준으로 끌어올리고, Vector API가 value type을 기다리는 구조입니다.

그래서 오히려 지금 이 릴리스를 봐야 합니다. Java 27 LTS에서 Valhalla의 첫 번째 결과물이 나올 가능성이 높고, 그때 코드베이스가 대응되어 있지 않으면 갑자기 대규모 수정이 필요해질 수 있습니다.

G1 GC 처리량 5~15% 개선과 HTTP/3 정식 지원은 지금 당장 테스트 환경에서 확인해볼 수 있습니다. 프로덕션 전환을 Java 27 LTS까지 미루더라도, 지금 테스트하고 측정해두는 건 무조건 이득입니다.

본 포스팅 참고 자료

1. Oracle 공식 발표 — Java 26 출시 안내 (oracle.com/kr)
2. OpenJDK 공식 프로젝트 페이지 — JDK 26 JEP 목록 및 일정 (openjdk.org)
3. Oracle Java Blog — The Arrival of Java 26 (blogs.oracle.com/java)
4. 위키독스 — Java 26 출시: Valhalla를 향한 마지막 준비인가 (wikidocs.net)
5. Andrew Baker — Java 26: What Actually Matters and Why You Should Care (andrewbaker.ninja)