Java 26, 왜 지금 봐야 하나요

2026년 3월 17일, Java 26이 예정대로 GA 상태가 됐습니다. 오라클의 6개월 릴리스 주기가 딱 맞아 떨어진 17번째 릴리스입니다. (출처: OpenJDK 공식 일정, openjdk.org/projects/jdk/26)

솔직히 말하면, “또 나왔네” 하고 넘기기 쉬운 릴리스입니다. Non-LTS니까요. 하지만 이번엔 넘기면 나중에 후회할 항목이 몇 가지 있습니다. AI 워크로드를 자바로 돌리는 분이라면 Vector API(JEP 529)와 Lazy Constants(JEP 526), AOT 오브젝트 캐싱(JEP 516)이 서로 맞물리는 방식을 봐야 합니다. 레거시 자바 코드베이스를 유지하는 분이라면 Thread.stop() 완전 삭제(JEP 504 아님, JDK-8368226)가 조용히 운영 시스템을 멈출 수 있습니다.

오라클이 공개한 수치로 보면, Java 26에서 수정된 JIRA 이슈는 총 2,535개입니다. 이 중 1,729개는 오라클이 처리했고, 806개는 Alibaba, Amazon, Google, IBM, NVIDIA, Red Hat 등 외부 커뮤니티가 기여했습니다. (출처: blogs.oracle.com/java/the-arrival-of-java-26) 단순 마이너 패치가 아닌 이유가 여기 있습니다.

▲ 목차로 돌아가기

AI 추론 성능을 직접 바꾸는 기능 3가지

① AOT 오브젝트 캐싱이 드디어 모든 GC에서 됩니다 (JEP 516)

이전까지 AOT 캐시는 ZGC와 함께 쓸 수 없었습니다. ZGC의 고급 메모리 레이아웃이 캐시 포맷과 호환되지 않았기 때문입니다. Java 26부터는 객체를 메모리에 직접 매핑하는 대신 순차적으로 로드하는 방식으로 바꿔, 어떤 GC를 쓰든 AOT 캐시의 모든 최적화를 그대로 받을 수 있습니다. (출처: JEP 516, openjdk.org/jeps/516)

AI 프레임워크 초기화는 무겁습니다. 스타트업 시간이 줄어든다는 건, 컨테이너 환경에서 콜드 스타트 지연이 체감으로 줄어든다는 뜻입니다.

② Vector API 11번째 인큐베이터 — Python 대비 수치가 다릅니다 (JEP 529)

“자바로 AI 추론을 하면 Python보다 느리다”는 말이 당연하게 퍼져 있지만, 수치는 다르게 나옵니다. Medium에서 실측한 벤치마크에서 동등한 수치 연산 작업 기준 Java의 평균 실행 시간은 2,847ms, Python은 89,432ms였습니다. (출처: medium.com/codeelevation, 2025.09) 약 31배 차이입니다.

Vector API는 x64와 AArch64 CPU의 SIMD 명령어(한 번에 여러 값을 동시에 연산하는 명령어)를 Java 코드에서 직접 쓸 수 있게 해줍니다. 행렬 곱과 같이 AI 추론에서 반복되는 수치 연산에서 동등한 스칼라 연산보다 높은 성능을 달성할 수 있다고 오라클 공식 문서에 나옵니다. (출처: oracle.com/kr/news/announcement/oracle-releases-java-26-2026-03-17) 다만 아직 인큐베이터 상태(11번째)라 프로덕션에 바로 쓰기엔 API가 바뀔 수 있다는 점은 감안해야 합니다.

③ Lazy Constants — AI 파이프라인 초기화 비용을 줄이는 방식 (JEP 526)

final 필드는 클래스 로딩 시점에 초기화되어야 합니다. 무거운 모델 설정 객체나 임베딩 테이블처럼 처음 실행 경로에서는 쓰이지 않을 수 있는 값도 무조건 미리 만들어야 했습니다. Lazy Constants는 처음 접근할 때 한 번만 초기화되지만 JVM이 여전히 진짜 상수로 취급해 constant folding 최적화를 그대로 적용합니다. (출처: JEP 526, openjdk.org/jeps/526)

AI 추론 파이프라인처럼 초기화 객체가 많고 무거운 환경에서 스타트업 메모리 효율과 실행 속도를 동시에 개선하는 패턴입니다. 아직 2차 프리뷰이고 Java 27에서 확정될 가능성이 높습니다.

▲ 목차로 돌아가기

HTTP/3 정식 지원 — 숫자로 보면 달라집니다

Java 26에서 HTTP/3(JEP 517)가 드디어 정식 기능으로 올라왔습니다. 프리뷰 없이 바로 확정입니다. HTTP/3는 TCP 기반의 HTTP/1.1, HTTP/2와 달리 QUIC(UDP 위에서 동작)를 전송 프로토콜로 씁니다.

핵심 차이는 HOL(Head-of-Line) 블로킹 제거입니다. HTTP/2에서는 패킷 하나가 유실되면 해당 TCP 스트림 전체가 대기합니다. HTTP/3는 각 스트림이 독립적이어서 한 패킷 유실이 다른 스트림에 영향을 주지 않습니다. 추가로 Zero-RTT 재연결(이전에 통신한 서버에 첫 번째 패킷부터 데이터 전송 가능)도 지원됩니다. (출처: JEP 517, openjdk.org/jeps/517)

기존 HttpClient API를 그대로 쓰면서 최소한의 코드 변경으로 HTTP/3 서버와 통신할 수 있습니다. 다운스트림 API를 대량으로 호출하는 마이크로서비스, 불안정한 네트워크 환경에서의 서비스 통신에서 지연 시간 단축 효과가 큽니다.

인프라 쪽에서 QUIC를 아직 지원하지 않는다면 HTTP/3의 이점을 바로 볼 수 없습니다. 서버 측 준비 여부를 먼저 확인하는 게 순서입니다.

▲ 목차로 돌아가기

보안 강화: 양자컴퓨팅 대비 JAR 서명과 PEM API

이번 릴리스에서 보안 쪽 변경이 꽤 많습니다. 당장 운영 시스템에 영향을 줄 수 있는 것 두 가지를 먼저 짚겠습니다.

ML-DSA 서명 지원 — 양자컴퓨터 시대 대비

Java 26은 JAR 파일에 ML-DSA 알고리즘으로 서명하고 검증하는 기능을 추가했습니다(JDK-8349732). ML-DSA는 NIST가 표준화한 포스트 퀀텀 서명 알고리즘(RFC 9882)으로, 현재 RSA나 ECDSA 기반 서명이 양자컴퓨터에 의해 깨질 경우를 대비한 것입니다. 지금 당장 모든 JAR을 ML-DSA로 다시 서명할 필요는 없지만, 공급망 보안이 민감한 환경에서는 도입 타이밍을 검토할 만합니다. (출처: Oracle JDK 26 Release Notes, oracle.com/java/technologies/javase/26-relnote-issues.html)

PEM API 2차 프리뷰 — 지금까지 없었던 게 이상했습니다 (JEP 524)

PEM 파일은 TLS 인증서, 개인키, CA 체인을 담는 가장 흔한 포맷입니다. 그런데 Java는 지금까지 이걸 표준 API로 읽고 쓰는 방법이 없었습니다. Bouncy Castle 같은 외부 라이브러리나 직접 파싱 코드를 쓰는 게 일반적이었습니다. Java 26의 PEM API(2차 프리뷰)는 암호화 키, 인증서, CRL을 PEM 포맷으로 인코딩하고 다시 객체로 디코딩하는 표준 API를 제공합니다. (출처: JEP 524, openjdk.org/jeps/524)

Java 25 대비 변경 사항도 있습니다. PEM API 클래스가 레코드에서 일반 클래스로 변경됐고, 런타임 암호화 오류를 위한 CryptoException이 새로 생겼으며, DEREncodable이 BinaryEncodable로 이름이 바뀌었습니다.

▲ 목차로 돌아가기

마이그레이션 폭탄 — Thread.stop() 완전 삭제

이 부분이 이번 릴리스에서 가장 조용하지만 가장 위험한 변경입니다.

java.lang.Thread.stop()이 Java 26에서 완전히 제거됐습니다(JDK-8368226). 이 메서드는 JDK 1.2(1998년)부터 deprecated였고, JDK 18에서 삭제 예정 deprecated, JDK 20에서 호출하면 무조건 UnsupportedOperationException을 던지도록 재정의됐습니다. (출처: JDK-8368226, Oracle JDK 26 Release Notes)

문제는 오래된 코드베이스에서 과거 Java 버전 기준으로 컴파일된 JAR이 이 메서드를 호출하는 경우입니다. 소스 코드에서 제거됐어도 이미 컴파일된 바이트코드 안에 이 메서드 호출이 남아 있을 수 있습니다. JDK 26에서 실행하면 컴파일 에러가 아니라 런타임에 NoSuchMethodError가 납니다. 운영 중에 예외가 터진다는 뜻입니다.

같은 맥락에서 jrunscript 도구도 이번에 완전히 제거됐습니다(JDK-8367157). 스크립트 자동화 파이프라인에 jrunscript를 쓰고 있다면 교체가 필요합니다.

Applet API 제거 (JEP 504)

JDK 17(2021년)에서 삭제 예정으로 표시됐던 Applet API가 Java 26에서 완전히 사라졌습니다. 5년의 유예 기간이 끝난 것입니다. 실무에서 Applet을 직접 쓰는 경우는 거의 없겠지만, 내부 레거시 기업 시스템 중에 간혹 남아 있을 수 있습니다.

▲ 목차로 돌아가기

Non-LTS인데 지금 올려도 될까요

Java 26은 LTS가 아닙니다. 오라클 업데이트 지원은 2026년 9월 JDK 27이 나올 때 끊깁니다. (출처: blogs.oracle.com/java/the-arrival-of-java-26) 그래서 “엔터프라이즈는 무시해도 된다”는 인식이 퍼져 있는데, 막상 들어보면 얘기가 조금 다릅니다.

Reddit의 Java 커뮤니티 논의에서 “유료 벤더(Oracle, Amazon Corretto, Azul 등)를 쓰는 경우 실제로는 어떤 버전이든 LTS에 준하는 지원을 받을 수 있다”는 의견이 올라와 있습니다. OpenJDK 공식 바이너리 기준으로는 non-LTS가 맞지만, 벤더 구독 기준으로는 다릅니다. (출처: reddit.com/r/programming, 2026.03.17)

그리고 프로덕션에 바로 적용 가능한 기능은 분명히 있습니다. HTTP/3, AOT 오브젝트 캐싱(ZGC 지원), G1 GC 처리량 개선은 프리뷰 없이 정식 확정됐습니다. 모든 JEP를 도입하는 것과 이 기능들만 써보는 것은 다른 문제입니다.

이번 릴리스의 전체 그림을 보면, Java 27에서 나올 Project Valhalla(값 타입 클래스)를 위한 사전 정지 작업이 많습니다. final 필드 변조 경고(JEP 500), Lazy Constants(JEP 526), 기본형 패턴 매칭(JEP 530) 모두 Valhalla의 선행 조건입니다. Java 26은 다음 LTS급 변화의 발판입니다.

G1 GC 처리량 개선 — 바로 써도 되는 기능 (JEP 522)

G1 GC가 애플리케이션 스레드와 GC 스레드 사이의 동기화를 줄여 처리량을 높였습니다. 추가 하드웨어 없이 더 많은 요청을 처리하고 인프라 비용을 줄이는 효과입니다. (출처: JEP 522, openjdk.org/jeps/522) 스레드가 많은 마이크로서비스 환경일수록 개선 폭이 크게 나타납니다.

JavaDoc에 다크 모드가 생긴 것도 이번 릴리스(JDK-8342705)입니다. 소소하지만 문서 작업이 많은 환경에서는 체감이 될 수 있습니다.

▲ 목차로 돌아가기

자주 나오는 질문 5가지

▲ 목차로 돌아가기

마치며

Java 26은 화려한 릴리스가 아닙니다. 10개 JEP 중 5개가 아직 프리뷰나 인큐베이터 상태입니다. 하지만 그게 이 릴리스의 전략입니다. HTTP/3 정식 지원, ZGC에서도 쓸 수 있는 AOT 캐싱, G1 GC 처리량 개선은 지금 바로 적용 가능합니다. 그리고 Thread.stop() 완전 삭제처럼 조용히 묻혀 있는 마이그레이션 위험은 JDK 26으로 올리기 전에 반드시 점검해야 합니다.

“AI 언어는 Python”이라는 생각이 있는데, Vector API가 완성되고 Valhalla 값 타입이 들어오면 그 전제가 흔들릴 수 있습니다. Java 26은 그 방향으로 가는 길목에 있는 릴리스입니다. 이 부분은 이번 글에서 제일 흥미롭게 봤습니다.

Java 25 LTS를 유지하면서 Java 27 LTS를 기다리는 전략이 안정적입니다. 하지만 신규 서비스나 컨테이너 환경이라면 AOT 캐싱과 HTTP/3만으로도 Java 26을 테스트해볼 이유가 충분합니다.

본 포스팅 참고 자료

1. Oracle 공식 Java 26 출시 발표 (oracle.com/kr)
2. OpenJDK 공식 JDK 26 프로젝트 페이지 (openjdk.org)
3. Oracle Java 기술 블로그 — The Arrival of Java 26 (blogs.oracle.com)
4. Oracle JDK 26 릴리스 노트 전문 (oracle.com)
5. JEP 516: Ahead-of-Time Object Caching with Any GC (openjdk.org)
6. JEP 529: Vector API (Eleventh Incubator) (openjdk.org)