Java 26이 LTS가 아닌 이유 — 쓰기 전에 먼저 확인해야 할 것

Java 26은 공식적으로 비-LTS(Non-LTS) 버전입니다. 오라클이 업데이트를 제공하는 기간이 2026년 9월까지, 딱 6개월입니다. (출처: Oracle Java Blog, 2026.03.17) 즉, 이 글을 읽고 Java 26을 프로덕션에 도입한다면, 올해 9월 이전에 Java 27로 올려야 합니다.

장기 지원이 필요한 환경이라면 이미 LTS인 Java 21(2028년 9월까지 프리미어 지원) 또는 Java 25 LTS에 머무르는 게 맞습니다. Java 26은 “최신 기능을 빠르게 써보고 싶거나, 6개월 안에 27로 올릴 계획이 있는 팀”에게 적합합니다.

한 가지 더. Java 26은 17번째 6개월 주기 릴리스입니다. 오라클이 이 주기를 2017년부터 한 번도 놓치지 않고 지켜왔다는 건, 반대로 보면 6개월마다 마이그레이션 고민이 반복된다는 뜻이기도 합니다.

10개 JEP, 지금 쓸 수 있는 것과 기다려야 하는 것 한눈에 보기

“Java 26에 AI 기능이 들어갔다”는 보도를 보고 기대했다면, 조금 냉정하게 봐야 합니다. 10개 JEP 중 당장 프로덕션에서 별도 플래그 없이 쓸 수 있는 건 4개뿐입니다. 나머지 6개는 --enable-preview가 필요하거나 아직 인큐베이터 상태입니다. (출처: OpenJDK JDK 26 Feature List)

※ FINAL = 별도 플래그 불필요, PREVIEW = --enable-preview --release 26 필요, INCUBATOR = --add-modules jdk.incubator.vector 필요

G1 GC 515%와 AOT 41% — 수치를 그대로 믿으면 안 되는 이유

Java 26 홍보 자료에서 가장 인상적인 수치 두 가지가 나옵니다. 하나는 G1 가비지 컬렉터의 처리량이 515% 향상됐다는 것, 다른 하나는 AOT 캐시 적용 시 Spring Boot PetClinic 기준 시작 시간이 41% 단축됐다는 것입니다. (출처: Loiane Groner, 2026.03) 숫자만 보면 엄청난 것 같지만, 조건이 있습니다.

AOT 캐시(JEP 516)는 더 구체적인 조건이 붙습니다. 41% 개선은 Spring Boot PetClinic 앱에서 약 21,000개 클래스를 미리 캐시했을 때의 측정값입니다. 직접 확인하려면 아래 흐름을 따르면 됩니다.

# 트레이닝: 캐시 파일 생성
java -XX:AOTCacheOutput=app.aot -jar yourapp.jar
# 프로덕션: ZGC + AOT 캐시 동시 사용 (Java 26에서 처음 가능)
java -XX:+UseZGC -XX:AOTCache=app.aot -jar yourapp.jar

주목할 점은 “ZGC와 AOT를 함께 쓸 수 있게 됐다“는 부분입니다. 이전 버전까지 AOT 캐시는 G1·Serial·Parallel GC에서만 작동했습니다. Java 26에서 GC에 구애받지 않는 포맷으로 변경돼 저지연이 필요한 ZGC 환경에서도 AOT 캐시를 활용할 수 있게 됐습니다. 저지연과 빠른 기동이 동시에 필요한 컨테이너 환경이라면 이게 실질적으로 가장 중요한 변화입니다.

JEP 500: final이 드디어 진짜 final이 됩니다 — 지금 코드 점검 필요

Java에서 final 키워드가 붙은 필드는 변경이 불가능하다고 배웁니다. 그런데 사실은 아니었습니다. JDK 5 이후 지금까지, Field.set()을 통한 딥 리플렉션으로 final 필드를 바꾸는 게 가능했습니다. 일부 직렬화 라이브러리나 테스트 프레임워크가 이 방식을 활용해왔습니다. (출처: OpenJDK JEP 500)

// Java 26에서 이런 코드는 런타임 경고 발생
Field f = Config.class.getDeclaredField("env");
f.setAccessible(true);
f.set(cfg, "dev"); // ← WARNING: Final field 'env' mutated

JDK 17 이후 모듈 시스템이 강화되면서 이미 많은 경우가 차단됐지만, 이번 JEP 500은 “모듈에 상관없이 모든 final 필드 변경을 막겠다”는 방향으로 가는 첫 단계입니다. Mockito, Jackson, Spring의 특정 모듈이 이 패턴을 쓰는지 의존성 목록을 한 번 점검해볼 필요가 있습니다.

Vector API 11번째 인큐베이터 — AI 기능이라더니 왜 아직도 실험 중인가

Java 26 발표 자료에는 “AI 추론 워크로드 가속화”라는 표현이 나옵니다. 그 주체가 Vector API(JEP 529)입니다. SIMD(단일 명령 다중 데이터) 연산을 CPU의 벡터 명령(AVX-512, NEON 등)으로 컴파일해 스칼라 연산 대비 뛰어난 성능을 낸다는 기능입니다. 그런데 이 API가 처음 등장한 게 JDK 16, 2021년입니다. 그리고 Java 26에서 11번째 인큐베이터입니다. (출처: OpenJDK JEP 529)

HackerNews에선 “Maybe 11th time’s the charm”이라는 댓글이 상위에 올라왔습니다. 커뮤니티 반응이 조금 씁쓸합니다. 실제로 Vector API는 JDK 내부에서 암호화, 해시, Base64 등에 쓰이고 있고 성능 효과도 입증됐지만, API 명세가 아직 확정이 아니라는 이유로 일반 개발자가 프로덕션에서 쓰는 건 권장되지 않습니다. 모듈을 추가(--add-modules jdk.incubator.vector)해야 컴파일도 됩니다.

“Java 26에 AI 기능이 들어갔다”는 말이 틀린 건 아닙니다. 다만 그 AI 기능을 실제로 쓰려면, 아직 기다려야 한다는 게 정확한 상황입니다.

HTTP/3 지원, 실제 코드 한 줄 차이인데 조건이 있습니다

JEP 517은 Java의 HttpClient에 HTTP/3(QUIC 기반) 지원을 추가한 것으로, 이번 Java 26에서 FINAL로 확정됐습니다. 코드상 변화는 딱 한 줄입니다.

// HTTP/2 (기존)
var client = HttpClient.newBuilder()
.version(HttpClient.Version.HTTP_2)
.build();
// HTTP/3 (Java 26 신규)
var client = HttpClient.newBuilder()
.version(HttpClient.Version.HTTP_3)
.build();

HTTP/3은 TCP 대신 QUIC 프로토콜을 사용해 연결 수립 속도를 줄이고 패킷 손실에 강한 특성이 있습니다. 모바일 네트워크나 지연이 불안정한 환경에서 특히 유리합니다. 단, 서버가 HTTP/3을 지원해야 효과가 납니다. 현재 AWS CloudFront, Cloudflare, Google Cloud Load Balancer 등 주요 CDN·클라우드는 HTTP/3을 지원합니다.

애플릿 API 완전 삭제 — 2000년대 코드라면 지금 바로 확인하세요

JEP 504로 java.applet, javax.swing.JApplet 등 애플릿 관련 클래스가 완전히 사라졌습니다. JDK 9에서 deprecated로 지정된 지 약 10년 만에 최종 제거입니다. 대부분의 현대 프로젝트에는 해당이 없지만, 2000년대 중·후반에 개발된 금융·공공기관 레거시 시스템 중 일부가 애플릿을 사용했기 때문에 마이그레이션 이력이 없다면 확인이 필요합니다.

마이그레이션 방향은 단순합니다. UI 컨테이너 용도로 쓰던 코드는 AWT 또는 Swing을 직접 사용하도록 바꾸면 되고, 오디오 재생에 사용했다면 Java 25에서 추가된 javax.sound.SoundClip으로 전환하면 됩니다. Java 26으로 올린 뒤 컴파일 오류가 난다면, 그게 레거시 청산의 신호입니다.

개인적으로 이 JEP는 “드디어”라는 말이 나옵니다. 브라우저에서 애플릿이 죽은 게 10년도 넘었는데, 그제야 JDK에서도 공식 삭제됐으니까요. 자바독(JavaDoc)에 다크 모드가 추가된 것도 이번 버전인데 — 이쪽이 더 많은 개발자의 일상에 영향을 줄 수도 있습니다.

Q&A

마치며

Java 26을 한 줄로 정리하면 “정리와 준비의 버전”입니다. 화려한 신기능보다는, 이미 오랫동안 프리뷰로 지켜봤던 것들이 하나씩 정착해가는 흐름입니다. 구조화된 동시성은 6번째 프리뷰, 패턴 매칭은 4번째 프리뷰 — 조금 더 기다리면 이 중 상당수가 Java 27이나 28에서 FINAL로 굳어질 것입니다.

실무 관점에서 가장 주목할 건 두 가지입니다. 첫째, ZGC + AOT 캐시 조합이 이제 가능해졌다는 점 — 컨테이너 기반 마이크로서비스에서 기동 지연과 GC 지연을 동시에 잡을 수 있게 됐습니다. 둘째, JEP 500의 final field 경고 — 지금은 조용하지만, 다음 LTS 버전에서 예외로 바뀌기 전에 미리 챙겨두지 않으면 나중에 더 큰 일이 됩니다.

Vector API가 11번이나 인큐베이터를 반복한다는 사실은, 반대로 보면 Java 팀이 기능 확정을 그만큼 신중하게 가져간다는 뜻이기도 합니다. 빠르게 치고 나가기보다, 생태계 전체의 호환성을 챙기는 방식이 자바다운 행보라는 생각도 듭니다.

본 포스팅 참고 자료

1. Oracle 한국 공식 발표 — oracle.com/kr/news, 2026.03.17
2. OpenJDK JDK 26 Project Page — openjdk.org/projects/jdk/26
3. Oracle Java Blog — The Arrival of Java 26 — blogs.oracle.com/java, 2026.03.17
4. OpenJDK JEP 529: Vector API (Eleventh Incubator) — openjdk.org/jeps/529
5. OpenJDK JEP 500: Prepare to Make Final Mean Final — openjdk.org/jeps/500
6. InfoQ — Java 26 Released — infoq.com, 2026.03.18