Java 26이 나왔다 — 먼저 숫자부터 봐야 합니다

2026년 3월 17일, Oracle이 Java 26(Oracle JDK 26)을 정식 출시했습니다. 발표 자료는 “10개 JEP, AI·암호화 강화, 개발자 생산성 향상”을 전면에 내세웠는데, 이 타이틀만 읽으면 깔끔한 릴리스처럼 보입니다. 직접 JEP 목록을 열어보니 달랐습니다.

10개 JEP 중 정식(final)으로 확정된 것은 5개입니다. 나머지 4개는 여전히 프리뷰(preview), 1개는 인큐베이터(incubator) 상태입니다. 프리뷰와 인큐베이터 기능은 API가 변경될 수 있고, 기본적으로 --enable-preview 플래그를 달아야 쓸 수 있습니다. 프로덕션에 그대로 올리면 다음 버전에서 뭔가 바뀔 수 있다는 뜻입니다.

그리고 Java 26은 LTS(Long-Term Support) 버전이 아닙니다. Oracle의 공식 지원 종료 시점은 2026년 9월 — 지금으로부터 딱 6개월입니다. (출처: Oracle Java SE Support Roadmap) 이 두 가지를 먼저 알고 나머지 기능들을 봐야 판단이 생깁니다.

▲ 목차로 돌아가기

10개 JEP 완전 정리 — 정식·프리뷰·인큐베이터 구분

Java 26의 JEP 10개를 상태별로 구분하면 다음과 같습니다. (출처: OpenJDK 공식 JDK 26 페이지)

정식으로 확정된 5개 중 핵심은 HTTP/3(JEP 517), AOT 객체 캐싱(JEP 516), G1 GC 처리량 개선(JEP 522)입니다. 특히 HTTP/3은 API 레벨에서 추가 라이브러리 없이 네이티브로 처리가 됩니다. 이 세 가지는 Java 26으로 올리자마자 효과를 볼 수 있는 변화들입니다.

반면 구조화된 동시성(JEP 525)은 6번째 프리뷰입니다. JDK 19부터 진행해온 기능인데 아직 정식이 아닙니다. Java 27에서 확정이 예상되지만 공식 발표된 건 아닙니다. (출처: InfoQ, Java 26 Delivers Language Innovation, 2026.03.17)

▲ 목차로 돌아가기

final 필드, 지금까지 사실 바꿀 수 있었습니다 (JEP 500)

Java에서 final 필드는 한 번 할당되면 바꿀 수 없다고 알고 있는 경우가 많습니다. JDK 5부터 지금까지 그게 사실이 아니었습니다. java.lang.reflect.Field의 setAccessible(true)를 호출한 다음 set()을 쓰면 final 필드도 언제든 덮어쓸 수 있었습니다. 아무 경고도 없이요.

class C {
final int x;
C() { x = 100; }
}
java.lang.reflect.Field f = C.class.getDeclaredField("x");
f.setAccessible(true);   // final 필드를 mutable 상태로 전환
C obj = new C();
System.out.println(obj.x);  // 100
f.set(obj, 200);
System.out.println(obj.x);  // 200 — final인데 바뀝니다
f.set(obj, 300);
System.out.println(obj.x);  // 300 — 또 바뀝니다

JDK 26 이전까지 이 코드는 아무 경고 없이 돌아갔습니다. JDK 26부터는 f.set()이 불법으로 간주되는 케이스에서 런타임 경고가 출력됩니다. 아직 예외를 던지지는 않지만, 공식 문서에 “향후 릴리스에서 deny가 기본값이 된다”고 명시돼 있습니다.

Hibernate·Mockito·Jackson이 직접 영향권에 들어옵니다

리플렉션으로 final 필드를 건드리는 라이브러리는 생각보다 많습니다. Mockito가 final 클래스를 모킹하거나, Hibernate가 엔티티를 역직렬화할 때, Jackson이 불변 객체를 바인딩할 때 이 패턴을 씁니다. 지금 당장 Java 26으로 올리면 표준 에러 스트림에 경고가 찍히기 시작합니다.

해결 방법은 JVM 기동 옵션에 한 줄을 추가하는 것입니다. 예를 들어 클래스패스 전체에 대해 final 필드 변경을 허용하려면 --enable-final-field-mutation=ALL-UNNAMED를 넣으면 됩니다. 모듈 단위로 제어하려면 --enable-final-field-mutation=모듈명으로 지정할 수 있습니다. (출처: JEP 500 공식 문서)

직접 영향 여부를 확인하려면 --illegal-final-field-mutation=debug로 실행하거나 JDK Flight Recorder로 jdk.FinalFieldMutation 이벤트를 확인하면 됩니다. 이벤트가 한 건이라도 잡히면 라이브러리 업데이트 또는 JVM 옵션 추가가 필요합니다.

▲ 목차로 돌아가기

Vector API 11번째 인큐베이터 — 정식화까지 갈 길이 남아 있습니다

Vector API(JEP 529)는 Java 26에서 11번째 인큐베이터 상태입니다. JDK 16(2021년 3월)에 처음 인큐베이터로 들어온 뒤 무려 5년이 지났습니다. 릴리스마다 “AI 추론·데이터 분석 성능 향상”을 강조하는데, JetBrains 공식 블로그는 이렇게 밝혔습니다. “This eleventh incubator contains no substantial changes compared to the previous version.” (출처: JetBrains Blog, 2026.03.18)

JDK 25에서 JDK 26으로 오면서 Vector API 구현에 실질적 변화가 없다는 뜻입니다. 성능 수치도 그대로입니다. 정식화가 늦어지는 이유는 Project Valhalla의 Value Classes가 완성되지 않았기 때문입니다. OpenJDK 공식 설명에 “The Vector API will continue to incubate until the necessary features of Project Valhalla become available as preview features”라고 나옵니다. (출처: openjdk.org/jeps/529) Valhalla 완성 전까지는 정식화 자체가 불가능합니다.

현재 JEP 401(Value Classes and Objects)이 JDK 27에 프리뷰로 타겟이 잡혀 있습니다. Valhalla가 JDK 27 프리뷰 → JDK 28이나 29 정식이라고 가정하면, Vector API 정식화는 빨라도 2027~2028년이 될 가능성이 높습니다. 이걸 모르고 “Java 26은 AI 추론 성능 개선”이라는 문구만 보고 AI 워크로드에 Java 26을 쓰기로 결정하면 API 변경 리스크를 안고 가게 됩니다.

그럼 AI 관련 작업에 Java 26은 실제로 어떻게 쓰나요?

AI 추론 연산을 JVM 위에서 돌릴 때 Vector API가 성능에 영향을 주지만, 지금 시점에서 Vector API를 직접 코드에서 쓰는 방법은 권장하지 않습니다. 대신 Apache Lucene, TensorFlow Java, ONNX Runtime Java 바인딩처럼 Vector API를 내부에서 이미 활용하는 라이브러리를 통해 간접 혜택을 받는 형태가 현실적입니다. 직접 API를 쓰고 싶다면 인큐베이터 모듈 선언을 추가해야 합니다. 다음 릴리스에서 API가 바뀔 수 있다는 점은 그때 가서 감수해야 합니다.

▲ 목차로 돌아가기

HTTP/3·PEM·AOT — 지금 당장 쓸 수 있는 변화들

HTTP/3 네이티브 지원 (JEP 517) — 코드 변경 최소화

Java의 내장 HTTP Client API가 HTTP/3를 지원합니다. QUIC 프로토콜 기반이라 헤드오브라인 블로킹이 없고, 네트워크 전환 중에도 연결이 유지됩니다. 기존 HTTP/2 코드에서 버전 지정만 바꾸면 됩니다. 기본값이 HTTP/2에서 HTTP/3으로 바뀐 건 아닙니다. HTTP/3를 쓰려면 opt-in 방식으로 버전을 명시해야 하는데, 이건 의도적인 설계입니다. 마이크로서비스 API 통신에서 지연 시간을 줄이려는 경우 직접 효과를 볼 수 있습니다.

AOT 객체 캐싱 (JEP 516) — 스타트업 속도에서 체감 차이

Project Leyden 계열의 이 기능은 JVM 시작 시 미리 초기화된 Java 객체를 캐시해 로드합니다. JDK 24에서 도입된 AOT 클래스 로딩·링킹(JEP 483)을 확장해서, 이번엔 ZGC를 포함한 모든 GC에서 작동합니다. 클라우드 함수(FaaS)나 컨테이너 환경처럼 인스턴스가 빠르게 올라와야 하는 경우에 실질적인 차이가 납니다. Oracle 공식 블로그에 “reduce application startup delays, scale their applications faster”라고 돼 있습니다. (출처: Oracle Blogs, The Arrival of Java 26, 2026.03.17)

G1 GC 처리량 개선 (JEP 522) — 코드 변경 없이 효과

G1 GC의 애플리케이션 스레드와 GC 스레드 간 동기화 오버헤드를 줄였습니다. 코드를 하나도 안 바꿔도 처리량이 올라갑니다. 현재 G1이 기본 GC이기 때문에, 별도 설정 없이 Java 26으로 올리는 것만으로 효과를 볼 수 있습니다. 얼마나 올라가는지 수치는 워크로드마다 달라서 공식 문서도 구체적인 퍼센트를 제시하지 않았습니다.

Applet API 완전 제거 (JEP 504) — 아직 코드에 남아 있다면 지금 확인해야 합니다

JDK 9에서 사용 중단, JDK 17에서 제거 예고, JDK 26에서 완전 삭제. java.applet.Applet을 import하는 코드가 남아 있으면 JDK 26에서는 컴파일 자체가 안 됩니다. 레거시 시스템 중 교육용 Java 코드나 오래된 사내 툴에 잔재가 남아 있는 경우가 의외로 있습니다. 업그레이드 전 의존성 스캔이 필요한 이유입니다.

▲ 목차로 돌아가기

non-LTS인데 지금 올려야 할까요? 수치로 따졌습니다

Java 26은 non-LTS입니다. Oracle Premier Support는 2026년 9월까지입니다. LTS인 Java 25는 최소 8년 지원입니다. (출처: Oracle Java SE Support Roadmap) 이 수치만 보면 엔터프라이즈 운영 환경에서 Java 26을 쓸 이유가 없어 보입니다.

Java 26이 의미 있는 경우는 세 가지입니다.

케이스 1 개발·테스트 환경

Java 27(2026년 9월 예정)에서 구조화된 동시성·지연 상수·PEM 인코딩이 정식화될 가능성이 높습니다. Java 26에서 프리뷰 기능을 먼저 써보면서 팀이 미리 코드 패턴을 익힐 수 있습니다.

케이스 2 마이크로서비스·FaaS 환경

AOT 객체 캐싱(JEP 516)과 G1 GC 개선(JEP 522)은 정식 기능입니다. 6개월 단위로 인프라를 업데이트하는 팀이라면 스타트업 속도와 처리량 개선 혜택을 바로 챙길 수 있습니다.

케이스 3 HTTP/3 전환 검토 중인 팀

추가 라이브러리 없이 JDK 내장으로 HTTP/3을 쓸 수 있는 첫 번째 정식 릴리스입니다.

반대로 Java 26이 맞지 않는 경우도 있습니다. 운영 안정성이 최우선인 금융·공공 시스템, 대규모 레거시 코드베이스, 또는 Hibernate·Mockito를 많이 쓰는데 대응 리소스가 없는 팀이라면 Java 25 LTS에 머무는 편이 낫습니다. JEP 500 경고가 예외로 바뀌는 건 Java 26이 아니라 미래 릴리스에서 일어납니다. 당장 프로덕션이 멈추는 건 아닙니다. 하지만 준비 없이 미루다가 나중에 한꺼번에 대응하게 되는 시나리오는 피해야 합니다.

결론은 간단합니다. 운영 환경 주력 버전은 Java 25(LTS), 개발 환경과 신규 마이크로서비스는 Java 26 검토, 향후 Java 27 LTS 대비는 지금부터 Java 26 프리뷰 기능을 파악해두는 방식이 현실적입니다.

▲ 목차로 돌아가기

Q&A — 5가지 핵심 질문

▲ 목차로 돌아가기

마치며 — 총평

Java 26은 “작지만 알차다”는 평이 적합합니다. 10개 JEP 중 5개가 정식이고, HTTP/3·AOT 캐싱·G1 개선이 실질적입니다. 여기에 “final이 사실 final이 아니었다”는 오래된 문제를 공식적으로 해결하는 첫 단추를 끼웠습니다.

동시에 Vector API 5년째 인큐베이터, 구조화된 동시성 6번째 프리뷰, Project Valhalla 지연 — 이 패턴들은 Java 생태계의 신중함을 보여주기도 하고, 때로는 기다림의 피로를 주기도 합니다.

non-LTS라는 이유만으로 무시하기에는 정식 확정된 기능들이 실용적입니다. 반대로 LTS가 아니라는 사실을 모르고 운영 환경에 무작정 올리면 6개월 뒤 지원 종료가 발목을 잡습니다. 결국 Java 26은 어디에 쓰느냐가 전부입니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Oracle 공식 발표 — Oracle Releases Java 26
   https://www.oracle.com/kr/news/announcement/oracle-releases-java-26-2026-03-17/
2. OpenJDK 공식 JDK 26 프로젝트 페이지 (전체 JEP 목록·일정)
   https://openjdk.org/projects/jdk/26/
3. JEP 500: Prepare to Make Final Mean Final (공식 문서)
   https://openjdk.org/jeps/500
4. Oracle Blogs — The Arrival of Java 26
   https://blogs.oracle.com/java/the-arrival-of-java-26
5. InfoQ — Java 26 Delivers Language Innovation, Library Improvements and Performance Advancements (2026.03.17)
   https://www.infoq.com/news/2026/03/java26-released/
6. JEP 529: Vector API (Eleventh Incubator) — Project Valhalla 의존성 명시
   https://openjdk.org/jeps/529
7. Oracle Java SE Support Roadmap — 버전별 지원 종료 일정
   https://www.oracle.com/se/java/technologies/java-se-support-roadmap.html