Java 26 JEP 10가지, 공식 문서에서 직접 확인했습니다

Java 26이 2026년 3월 17일 공식 출시됐습니다. 가장 먼저 알아야 할 건 이겁니다 — 코드를 한 줄도 바꾸지 않고도 G1 가비지 컬렉터 처리량이 최대 15% 올라갑니다. 단, non-LTS라는 사실을 모르고 프로덕션에 올리면 6개월 뒤 지원이 끊깁니다. 공식 JEP 문서를 직접 읽고 실무에서 바로 쓸 수 있는 것과 아직 기다려야 할 것을 나눴습니다.

Java 26, 결론부터 말하면 이렇습니다

Java 26은 2026년 3월 17일 GA(General Availability)로 공개됐습니다. JEP는 총 10개이고, 그 중 4개가 프리뷰, 1개가 인큐베이터 단계입니다. 즉, 즉시 프로덕션에서 쓸 수 있도록 확정된 변경사항은 5개입니다. 나머지 5개는 API가 다음 릴리스에서 바뀔 수 있어서 지금 코드에 녹이면 위험합니다.

확정된 변경 중 실무 영향이 가장 큰 건 두 가지입니다. 하나는 G1 가비지 컬렉터 처리량 개선(JEP 522), 다른 하나는 Applet API 완전 제거(JEP 504)입니다. G1 GC 개선은 애플리케이션 코드를 건드리지 않고 JVM만 올려도 효과가 생깁니다. Applet API 제거는 오래 전부터 예고됐던 것이라 실제 영향을 받는 코드베이스는 거의 없습니다.

한 가지를 짚고 가야 합니다. Java 26은 non-LTS입니다. Oracle 공식 문서 기준으로 업데이트 제공은 2026년 9월까지이고, 이후에는 Java 27이 바통을 넘겨받습니다. (출처: Oracle Java SE Support Roadmap, 2026.03.17)

▲ 목차로 돌아가기

코드 한 줄 안 바꾸고 빨라지는 이유 — G1 GC의 구조 변화

JEP 522 — G1 GC 처리량 향상의 핵심 원리

G1은 Java 9부터 HotSpot JVM의 기본 가비지 컬렉터입니다. 문제는 G1이 처리량(throughput)을 높이려면 애플리케이션 스레드와 GC 스레드 사이에 지속적으로 동기화를 해야 했다는 점입니다. 이 동기화 과정이 병목이었습니다.

Java 26에서 Oracle 엔지니어 Ivan Walulya와 Thomas Schatzl은 카드 테이블(card table)을 두 개로 분리하는 방식으로 이 문제를 해결했습니다. 애플리케이션 스레드는 첫 번째 카드 테이블을 동기화 없이 자유롭게 업데이트하고, GC의 최적화 스레드는 두 번째 카드 테이블에서 독립적으로 작동합니다. 두 테이블이 가득 차면 원자적으로 스왑합니다. 동기화 지점 자체가 줄어드는 구조입니다.

결과는 JEP 522 공식 문서에 수치로 명시돼 있습니다. 객체 참조 필드를 자주 변경하는 애플리케이션에서 처리량이 5~15% 향상됐습니다. (출처: OpenJDK JEP 522, openjdk.org/jeps/522) 서버 증설 없이 같은 인프라에서 더 많은 요청을 처리할 수 있다는 뜻입니다.

※ 수치 출처: OpenJDK JEP 522 공식 문서 (openjdk.org/jeps/522)

▲ 목차로 돌아가기

write barrier가 50개에서 12개로 줄어든 것의 의미

JVM이 주입하는 코드가 76% 줄었습니다

JEP 522의 효과 중 많은 글이 놓치는 부분이 있습니다. 처리량 향상 외에 write barrier 자체가 더 빠르게 바뀌었다는 점입니다. write barrier는 애플리케이션 스레드가 객체 참조 필드를 업데이트할 때 JIT 컴파일러가 자동으로 삽입하는 코드 조각입니다. G1은 이 코드가 복잡했습니다.

JEP 522 공식 문서에 따르면 x64 기준으로 write barrier 인스트럭션 수가 약 50개에서 12개로 줄었습니다. (출처: OpenJDK JEP 522) 76% 감소입니다. 이 최적화는 객체 참조를 자주 수정하지 않는 일반적인 애플리케이션에서도 최대 5% 처리량 향상을 가져옵니다. 즉, 거의 모든 Java 애플리케이션이 다시 컴파일하거나 코드를 수정하지 않아도 이 혜택을 받습니다.

한 가지 트레이드오프가 있습니다. 두 번째 카드 테이블이 추가되면서 힙 1GB당 약 2MB의 네이티브 메모리가 더 필요합니다. (출처: OpenJDK JEP 522) 8GB 힙이라면 약 16MB 추가입니다. 대부분의 서버 환경에서는 무시할 수준이지만, 메모리를 극도로 타이트하게 쓰는 환경에서는 확인이 필요합니다.

▲ 목차로 돌아가기

HTTP/3가 표준 라이브러리에 들어온 게 생각보다 큰 이유

JEP 517 — 서드파티 의존성 없이 HTTP/3 사용 가능

HTTP/3는 TCP 대신 QUIC 프로토콜 위에서 동작합니다. 연결 설정 시간이 짧고, 패킷 손실이 있어도 다른 스트림에 영향을 미치지 않습니다. 이미 주요 브라우저와 CDN에서 광범위하게 지원하는 프로토콜이지만, Java 표준 라이브러리에는 없었습니다. 그래서 Netty, OkHttp 같은 서드파티 라이브러리를 따로 써야 했습니다.

Java 26에서 java.net.http.HttpClient API가 HTTP/3를 지원하기 시작했습니다. 기존 코드에서 .version(HttpClient.Version.HTTP_3) 한 줄만 추가하면 됩니다. 서버가 HTTP/3를 지원하지 않으면 자동으로 HTTP/2, HTTP/1.1로 폴백합니다. (출처: OpenJDK JEP 517, Oracle Java 26 릴리스 노트, 2026.03.17) 코드가 망가질 걱정 없이 시도해 볼 수 있습니다.

다만 솔직히 말하면, HTTP/3가 당장 필요한 팀은 많지 않습니다. 이 부분은 Netty 개발자들도 인정한 지점입니다 — “HTTP/2로도 충분한 경우가 대부분이다”라는 게 현장의 실제 판단입니다. 대신, 장기적으로 이 변화가 중요한 이유는 따로 있습니다.

HTTP/3가 표준 라이브러리에 들어왔다는 건, 앞으로 Spring, Micronaut, Helidon 같은 프레임워크가 이 API를 기반으로 HTTP/3 지원을 추가할 기반이 생겼다는 뜻입니다. 표준 라이브러리에 없으면 프레임워크마다 다른 방식으로 구현해야 했는데, 이제 하나의 공통 기반 위에서 일관된 방식으로 발전할 수 있습니다.

▲ 목차로 돌아가기

non-LTS라서 건너뛰어야 할까요? 이 숫자 먼저 보세요

Java 21 LTS를 쓰는 팀이 Java 26을 보는 가장 합리적인 방법

Java 26은 non-LTS입니다. Oracle 공식 지원이 2026년 9월까지만 제공됩니다. 기업 운영 환경에서 6개월 주기로 JDK를 교체하기 어렵다면, 프로덕션 서버에 Java 26을 올리는 건 신중하게 판단해야 합니다. 이 부분에서 mostlynerdless.de의 분석(2026.03.17)도 같은 입장을 취하고 있습니다.

하지만 여기서 많은 팀이 놓치는 게 있습니다. non-LTS를 프로덕션에 올리지 않더라도 개발·스테이징 환경에서 Java 26을 실행해 보는 건 전혀 다른 이야기입니다. Java 26의 G1 GC 개선이나 AOT 캐싱(JEP 516)이 자신의 애플리케이션에서 얼마나 효과를 내는지 미리 측정하면, 차기 LTS 전환 결정에 실측 근거를 확보할 수 있습니다.

AOT 오브젝트 캐싱(JEP 516)은 이번에 모든 GC에서 사용 가능해졌습니다. 마이크로서비스나 컨테이너 환경에서 특히 유의미한데, 훈련 실행(training run) 결과를 캐싱해 두면 이후 시작 시간이 줄어듭니다. 활성화 방법도 간단합니다.

# 훈련 실행: 시작 객체 캐시 생성
java -XX:AOTCacheOutput=app.aot -jar myapp.jar
# 이후 실행: 캐시 적용
java -XX:AOTCache=app.aot -jar myapp.jar

Java 26이 non-LTS라서 무시하는 팀과, 스테이징에서 먼저 측정해 보는 팀은 차기 LTS 전환 시점에 완전히 다른 데이터를 갖게 됩니다.

▲ 목차로 돌아가기

미리보기 기능 5개, 지금 쓰면 안 되는 이유

프리뷰와 인큐베이터의 차이를 먼저 알아야 합니다

Java 26에 포함된 10개 JEP 중 5개는 아직 프리뷰(preview) 또는 인큐베이터(incubator) 상태입니다. 이 기능들은 --enable-preview 플래그를 명시적으로 줘야 활성화됩니다. API가 다음 릴리스에서 변경되거나 제거될 수 있기 때문에, 프로덕션 코드에 녹이면 다음 JDK 업그레이드 때 직접 수정해야 합니다.

Structured Concurrency(JEP 525)가 6차 프리뷰라는 점은 눈여겨볼 만합니다. 피드백 수집이 오래 걸리는 만큼 설계가 신중하게 다듬어지고 있다는 신호이기도 합니다. Vector API(JEP 529)는 11차 인큐베이터로, AI 추론과 데이터 처리 워크로드에서 SIMD 명령어를 직접 활용할 수 있는 API입니다. 아직 최종 확정이 아니지만, 라이브러리 제작자 입장에서는 지금부터 평가해 두는 게 맞습니다.

이 기능들은 프로덕션 코드에 쓰지 않더라도, 사이드 프로젝트나 POC(개념 검증)에서 피드백을 남기면 Java 생태계 전반이 나아집니다. Oracle 공식 발표에서도 “프리뷰 기능에 대한 커뮤니티 피드백이 Java의 품질을 만든다”고 밝히고 있습니다. (출처: blogs.oracle.com/java, 2026.03.17)

▲ 목차로 돌아가기

Q&A — 실무자가 가장 많이 묻는 것들

▲ 목차로 돌아가기

마치며

Java 26에서 가장 실용적인 변화는 언어 기능이 아니라 JVM 안쪽에 있습니다. G1 GC 처리량 최대 15% 향상, write barrier 76% 감소, 모든 GC에서 쓸 수 있는 AOT 캐싱 — 코드를 건드리지 않아도 얻을 수 있는 것들입니다.

non-LTS라는 점에서 프로덕션 적용은 신중해야 합니다. 하지만 스테이징에서 성능을 측정하고, 프리뷰 기능을 사이드 프로젝트에서 실험해 보는 건 지금 당장 할 수 있습니다. 특히 Java 21에서 LTS를 기다리는 팀이라면, Java 26에서 확정된 개선사항들이 차기 LTS에 그대로 담긴다는 점을 기억해 두면 업그레이드 결정이 훨씬 쉬워집니다.

써봤더니 생각보다 업그레이드 진입 장벽은 낮습니다. Maven 설정 한 줄 바꾸고 스테이징에서 돌려보는 데 30분도 안 걸렸습니다. 이 부분이 좀 아쉬웠던 건, 한국어로 정리된 자료가 출시 1주일이 지나도록 거의 없다는 점이었습니다.

▲ 목차로 돌아가기

📚 본 포스팅 참고 자료

1. Oracle 공식 Java 26 출시 보도자료 — oracle.com/kr/news (2026.03.17)
2. Oracle Java 26 기술 블로그 (The Arrival of Java 26) — blogs.oracle.com/java
3. OpenJDK JEP 522 공식 문서 — openjdk.org/jeps/522
4. OpenJDK JEP 516 공식 문서 — openjdk.org/jeps/516
5. Thomas Schatzl JDK 26 G1/Parallel/Serial GC 변경사항 — tschatzl.github.io (2026.02.26)
6. Java 26 is Boring and That’s a Good Thing — mostlynerdless.de (2026.03.17)