JDK 26 / Oracle 공식 발표
비-LTS 릴리스
Java 26, 10개 JEP인데 바로 쓸 수 있는 건 따로 있습니다
2026년 3월 17일, 오라클이 예정대로 Java 26을 출시했습니다. 10개의 JEP — 그런데 이 중 5개가 아직 프리뷰나 인큐베이터 상태입니다. “신기능 10개”라는 타이틀만 보고 프로덕션에 적용했다가는 다음 릴리스에서 코드를 전부 뜯어고쳐야 할 수도 있습니다. 지금 바로 쓸 수 있는 것과 기다려야 하는 것, 공식 문서 기준으로 구분했습니다.
Java 26가 지금도 중요한 이유 — LTS가 아닌데도
Java 26은 LTS(Long-Term Support) 버전이 아닙니다. LTS는 바로 이전 버전인 Java 25가 가져갔습니다. 오라클이 Oracle JDK 26에 제공하는 업데이트 기간은 2026년 9월, Java 27 출시 때까지 딱 6개월입니다. (출처: Oracle Java Blog, 2026.03.17)
“그럼 굳이 지금 볼 필요 없다”고 생각하기 쉽습니다. 그게 바로 이 글을 쓰게 된 이유입니다. Java의 6개월 릴리스 주기에서 비-LTS 버전은 단순한 중간 점검이 아닙니다. 다음 LTS에 확정으로 들어갈 기능들이 여기서 검증받습니다. 지금 Java 26의 프리뷰 기능을 이해해두지 않으면, 내년 LTS(아마도 Java 27 또는 29)가 나왔을 때 “이게 언제 들어왔지?” 하고 당황하게 됩니다.
실제로 JRebel의 Java 26 분석에서도 “비-LTS 릴리스는 다음 LTS를 정의할 기능들의 proving ground”라고 표현했습니다. (출처: JRebel Blog, 2026.03.17) 즉, 지금 Java 26을 보는 건 Java의 미래를 먼저 보는 일입니다.
지금 프로덕션에 써도 되는 JEP 4가지
Java 26의 10개 JEP 중 프리뷰·인큐베이터가 아닌, 바로 적용 가능한 기능은 4가지입니다. OpenJDK 공식 페이지에서 확인한 목록 기준입니다. (출처: OpenJDK 공식, 2026.03.17)
① JEP 516 — AOT 객체 캐싱, 이제 어떤 GC도 됩니다
Java 애플리케이션의 고질병인 워밍업 지연을 줄이는 AOT(Ahead-of-Time) 캐싱이 Java 26부터 ZGC를 포함한 모든 GC에서 동작합니다. 기존엔 특정 GC에서만 쓸 수 있어서 레이턴시 민감 서비스 팀들은 사실상 이 기능을 못 썼습니다. 컨테이너 환경에서 콜드 스타트 지연이 문제라면 지금 당장 적용 효과를 확인해볼 수 있습니다.
② JEP 522 — G1 GC 처리량 향상, 수치로 말합니다
G1 GC의 애플리케이션 스레드와 GC 스레드 간 동기화를 줄여 처리량을 끌어올렸습니다. JRebel 분석에 따르면 오브젝트 레퍼런스 변경이 많은 워크로드에서 최대 15% 처리량 향상이 측정됩니다. (출처: JRebel Blog, 2026.03.17) 코드 한 줄 바꾸지 않고 JDK 버전만 올려도 효과가 납니다.
③ JEP 517 — HTTP/3 지원, 이제 서드파티 없이 됩니다
Java 11에서 도입된 HTTP Client API가 드디어 HTTP/3를 지원합니다. TCP 기반 HTTP/2의 헤드-오브-라인 블로킹 문제를 해결한 QUIC 기반 프로토콜이라, 불안정한 네트워크 환경이나 고처리량 마이크로서비스 간 통신에서 체감 차이가 납니다. Bouncy Castle 같은 서드파티 없이 표준 라이브러리만으로 HTTP/3 서버와 통신할 수 있습니다.
④ JEP 504 — Applet API 제거
Java 17에서 제거 예고(deprecated for removal)가 됐던 Applet API가 Java 26에서 완전히 삭제됐습니다. 레거시 코드베이스에 Applet 관련 클래스가 조금이라도 남아 있다면 컴파일 오류가 납니다. 지금이 코드 점검 적기입니다.
| JEP | 기능 | 상태 | 체감 효과 |
|---|---|---|---|
| 516 | AOT 객체 캐싱 (Any GC) | 확정 | 콜드 스타트 감소 |
| 522 | G1 GC 처리량 향상 | 확정 | 최대 15% 처리량 |
| 517 | HTTP/3 지원 | 확정 | 레이턴시 개선 |
| 504 | Applet API 제거 | 제거 | 레거시 코드 점검 필수 |
| 500 | final 필드 변경 경고 | 확정 | 경고 → 미래엔 오류 |
Vector API가 11번이나 인큐베이터인 진짜 이유
Vector API는 Java 16에서 처음 등장해 JDK 26까지 11번째 인큐베이터를 달고 있습니다. “5년 동안 뭘 한 거야?”라는 말이 나올 법합니다. 그런데 JavaCodeGeeks의 분석을 보면 생각이 달라집니다.
💡 공식 JEP 문서와 실제 동작 결과를 같이 놓고 보니 이런 차이가 보였습니다
JEP 529 공식 문서에는 이렇게 적혀 있습니다: “Vector API는 Project Valhalla의 제네릭 특수화가 프리뷰로 제공될 때까지 인큐베이터 상태를 유지한다.” (출처: OpenJDK JEP 529) 의도적으로 멈춘 겁니다.
핵심은 Java 제네릭의 구조적 한계입니다. 현재 Java의 제네릭은 기본 타입을 지원하지 않아서 Vector<int>가 아니라 Vector<Integer>, IntVector, FloatVector 같은 서브클래스로 구현돼 있습니다. Valhalla가 기본 타입 제네릭을 지원하게 되면 이 구조가 통째로 바뀝니다. 지금 이 모양으로 확정하면 나중에 API 전체를 바꿔야 한다는 얘기입니다.
그렇다고 Vector API가 쓸 수 없는 건 아닙니다. --add-modules jdk.incubator.vector 플래그를 붙이면 지금도 동작하고, JIT 컴파일러가 실제 SIMD 명령으로 내려보냅니다. 수치도 나옵니다. JavaCodeGeeks 분석에 따르면 AVX-512 장비에서 벡터화된 닷 프로덕트 연산은 스칼라 동등 코드보다 10~16배 빠릅니다. (출처: JavaCodeGeeks, 2026.03.27) 성능 수치는 진짜입니다. 불안정한 건 API 형태뿐입니다.
⚠️ 프로덕션 도입 전 주의
jdk.incubator.* 네임스페이스의 API는 Maven Central에 올라온 라이브러리가 의존해선 안 된다는 게 OpenJDK의 공식 원칙입니다. Spring, Guava 같은 범용 라이브러리가 이 API를 transitively 의존하게 되면 API 변경 시 다운스트림이 전부 깨집니다. 팀 내부 성능 크리티컬 모듈에 직접 쓰는 건 괜찮지만, 배포 라이브러리에는 금물입니다.
JEP 500이 숨기고 있는 신호
JEP 500(Prepare to Make Final Mean Final)은 표면적으로 “리플렉션으로 final 필드를 바꾸면 경고가 뜬다”는 기능입니다. 별거 아닌 것처럼 보이지만, 이 기능이 Java 26에서 확정된 데는 훨씬 큰 배경이 있습니다.
💡 “final 경고” 뒤에 숨어 있는 Valhalla 준비 작업
Hanno Embregts의 Java 26 분석에서 이런 문장이 나옵니다: “JEP 500과 529의 조합은 Valhalla의 첫 번째 기능을 위한 준비 작업을 공개적으로 진행하는 것”이라고. (출처: hanno.codes, 2026.03.17) 경고가 뜨는 건 에코시스템에 “여기 바꿔야 한다”는 충분한 사전 통보를 주는 절차입니다.
Valhalla의 값 클래스(Value Classes)는 힙에 올라가는 객체지만 동일성(identity)이 없습니다. 두 인스턴스의 필드 값이 같으면 같은 것입니다. 이걸 안전하게 최적화하려면 final이 정말로 변경 불가여야 합니다. 지금은 setAccessible(true)로 뚫을 수 있어서 JVM이 100% 믿지 못합니다. JEP 500이 이 구멍을 막는 첫 번째 단계입니다.
실무 관점에서 보면, Mockito나 직렬화 라이브러리처럼 리플렉션으로 final 필드를 건드리는 코드를 쓰는 팀은 지금 경고를 봐야 합니다. Java 27~28에서 오류로 격상될 가능성이 공식 문서에도 “향후 제한” 표현으로 명시돼 있습니다. (출처: OpenJDK JEP 500)
프리뷰 5개, 지금 넣으면 생기는 일
Java 26의 프리뷰·인큐베이터 JEP는 5개입니다. 프리뷰 기능을 쓰려면 컴파일과 실행 시 --enable-preview 플래그가 필요하고, 다음 Java 버전에서 API 형태가 바뀔 수 있습니다. 즉, 지금 프리뷰 기능에 의존하는 코드를 작성하면 Java 27 업그레이드 때 수정 작업이 생긴다는 뜻입니다.
JEP 530 — 패턴 매칭 기본 타입
instanceof와 switch에서 int, long 같은 기본 타입을 직접 패턴 매칭. 박싱 오버헤드 제거. 4번째 프리뷰라 Java 27 확정 가능성 높음.
JEP 525 — 구조화된 동시성
멀티스레드 작업을 단일 단위로 묶어 스레드 누수와 취소 지연 감소. onTimeout() 메서드 추가. Virtual Threads와 조합 시 강력.
JEP 526 — 지연 상수(Lazy Constants)
LazyConstant 인터페이스로 첫 접근 시에만 초기화되는 진짜 상수 정의 가능. JVM이 static final처럼 최적화.
JEP 524 — PEM 암호화 객체 인코딩
TLS 인증서, 개인키를 PEM 형식으로 읽고 쓰는 표준 API. Java 26에서 클래스명 변경(PEMRecord → PEM), CryptoException 추가.
⚠️ 프리뷰 기능 사용 시 현실적 체크리스트
프리뷰 기능은 javac --enable-preview --release 26와 java --enable-preview 플래그가 모두 필요합니다. CI/CD 파이프라인과 배포 스크립트를 함께 수정해야 하고, Java 27 전환 때 API 변경 여부를 반드시 재확인해야 합니다. 개인 프로젝트나 내부 도구라면 써도 되지만, 공개 라이브러리나 고객사 프로덕션 코드에는 넣지 않는 게 맞습니다.
Java 27에서 뭐가 바뀌는지 미리 알아야 하는 이유
Java 27은 2026년 9월 출시 예정입니다. 지금까지 공식 타겟으로 잡힌 JEP는 하나입니다. JEP 527 — 양자 컴퓨팅에 내성을 갖춘 TLS 1.3 하이브리드 키 교환입니다. (출처: JRebel Blog, 2026.03.17)
더 중요한 건 Java 27에서 기대되는 후보 JEP들입니다. JRebel 분석에 따르면 JEP 401(값 클래스와 객체, Project Valhalla 첫 번째 프리뷰)이 Java 27에 들어올 가능성이 있다고 InfoQ가 인용했습니다. 이게 확정되면 Vector API도 드디어 인큐베이터를 벗어날 준비를 시작할 수 있습니다.
💡 지금 Java 26의 프리뷰를 봐야 하는 실용적 이유
JEP 530(기본 타입 패턴 매칭)은 이번이 4번째 프리뷰입니다. 오라클 공식 블로그 기준으로 통상 4번째 프리뷰는 다음 버전에서 확정되는 패턴이 많습니다. 지금 실험해두면 Java 27 업그레이드 때 즉시 쓸 수 있습니다. 구조화된 동시성(JEP 525)도 6차 프리뷰입니다. 이 역시 Java 27 확정을 바라보고 있습니다.
솔직히 말하면, 개인 견해로는 Java 26을 바로 프로덕션 JDK로 올리는 건 권장하지 않습니다. 6개월 지원 기간 안에 Java 27이 나오는 데다가, 보안 패치나 버그픽스는 LTS인 Java 25에서 계속 제공됩니다. 하지만 개발 환경에서 미리 돌려보고 Java 27 전환 계획을 세우는 용도로는 지금이 최적의 타이밍입니다.
| Java 버전 | LTS 여부 | 지원 기간 | 주요 포인트 |
|---|---|---|---|
| Java 25 | LTS | 장기 | 현재 프로덕션 권장 |
| Java 26 | 비-LTS | ~2026.09 | 개발·테스트 환경 활용 |
| Java 27 | 미확정 | 2026.09 예정 | Valhalla 첫 프리뷰 기대 |
자주 나오는 질문 5가지
마치며
Java 26을 한 줄로 요약하면 “준비 중인 플랫폼의 공개 중간 점검”에 가깝습니다. 화려하게 쓸 수 있는 신기능이 많은 버전은 아닙니다. 10개 JEP 중 절반이 아직 미완성이고, LTS가 아니라는 점도 그렇습니다.
그런데 바로 그 점이 흥미롭습니다. JEP 500과 JEP 529가 같은 버전에 동시에 들어온 건 우연이 아닙니다. Valhalla를 위한 준비 작업이 공식 릴리스 채널을 통해 진행 중이라는 신호입니다. Vector API가 언제 인큐베이터를 벗어나는지, 값 클래스가 언제 프리뷰로 오는지를 추적하는 데 Java 26이 실마리를 줍니다.
지금 당장 쓸 수 있는 건 JEP 516(AOT 캐싱 확장), JEP 522(G1 처리량), JEP 517(HTTP/3) 세 가지입니다. 나머지는 알아두되 기다리는 게 맞습니다. 개발 환경에서 미리 돌려보고, 2026년 9월 Java 27을 기다리는 것 — 그게 지금 Java 26을 대하는 가장 현실적인 자세입니다.
본 포스팅 참고 자료
- Oracle 한국 공식 — Java 26 출시 발표 (2026.03.17)
- Oracle Java Blog — The Arrival of Java 26 (2026.03.17)
- OpenJDK 공식 — JDK 26 Feature List & Schedule
- JRebel Blog — What’s New in Java 26 (2026.03.17)
- JavaCodeGeeks — Vector API at Eleven Incubations (2026.03.27)
- OpenJDK JEP 529 — Vector API (Eleventh Incubator)
- OpenJDK JEP 500 — Prepare to Make Final Mean Final
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Java 26 기준(2026.03.17 GA), Oracle JDK 26 및 OpenJDK 공식 자료를 바탕으로 작성됐으나, 이후 업데이트나 수정이 발생할 수 있으므로 중요한 의사결정 전에는 반드시 공식 문서를 직접 확인하시기 바랍니다.
댓글 남기기