Java 장기 지원 정책의 한계와 개선 방향

Java 장기 지원(LTS) 정책의 한계와 개선 방향

오라클이 2017년 Java 9부터 6개월 릴리스 주기로 전환했을 때, 대부분의 엔터프라이즈 현장은 환영 대신 당혹감을 드러냈다. "반년마다 버전이 바뀌는데, 우리가 이걸 따라갈 수 있겠냐"는 반응이었다. 그 타협점으로 등장한 것이 LTS(Long-Term Support) 체계다. 그러나 2026년 현재, 이 LTS 체계는 처음 설계된 의도와 달리 업계 분열을 심화시키고 있다는 비판을 받고 있다.

LTS란 무엇인가, 그리고 무엇이 아닌가

Java LTS는 오라클이 최소 8년간 보안 패치·버그 수정을 제공하겠다고 약속한 버전을 가리킨다. Java 8(2014), Java 11(2018), Java 17(2021), Java 21(2023)이 이에 해당한다. 비LTS 버전은 다음 릴리스가 나오는 6개월 후 지원이 종료된다. 겉으로 보면 합리적인 구조지만, 실제 운영 현장에는 여러 균열이 존재한다.

가장 큰 문제는 벤더별 LTS 기간의 불일치다. 오라클 OpenJDK는 다음 LTS 버전이 출시되면 이전 버전 무료 업데이트가 즉시 중단된다. Java 17의 경우 2023년 9월 Java 21 출시와 동시에 오라클 OpenJDK 17의 무료 보안 패치가 끊겼다. 반면 Azul Zulu, Amazon Corretto, Eclipse Temurin(Adoptium)은 독자적인 일정으로 2029년까지 Java 17을 지원한다. 즉 "LTS"라는 단어 하나에 실제로는 4~5가지 서로 다른 지원 기간이 공존한다.

엔터프라이즈 현장의 버전 동결 현상

JRebel이 2025년 발표한 Java 생태계 보고서에 따르면, 기업 환경의 약 38%가 여전히 Java 8 또는 Java 11을 운영 환경에 사용 중이다. Java 8은 오라클 상업 지원 기준으로 2030년 이후까지 유지되지만, 오픈소스 빌드 기준으로는 이미 2019년 1월에 무료 업데이트가 종료됐다. 그런데도 많은 기업이 Java 8에 머무는 이유는 단순하다. 마이그레이션 비용이 LTS 갱신 비용보다 훨씬 크다고 판단하기 때문이다.

Spring Boot 2.x → 3.x 마이그레이션을 예로 들면, Spring Boot 3은 Java 17 이상을 요구하며 Jakarta EE 10 네임스페이스를 사용한다. javax. 패키지를 전부 jakarta.로 교체해야 하고, 의존 라이브러리 호환성도 전면 점검해야 한다. 수백만 줄짜리 코드베이스를 가진 금융·공공 시스템에서는 이 작업이 수 개월, 수십억 원 규모의 프로젝트가 된다.

"2년 주기 LTS"의 구조적 문제

Java 21(2023) 이후, 오라클은 LTS 주기를 3년에서 2년으로 단축했다. 다음 LTS는 Java 25(2025년 9월 예정)다. 이 결정의 배경에는 Kotlin·Python·Rust 등 경쟁 언어의 빠른 진화에 뒤처지지 않겠다는 의도가 있다. 그러나 엔터프라이즈 관점에서 2년 주기는 오히려 압박이다. 인증·검증·회귀 테스트 사이클을 고려하면, 2년마다 한 번씩 전사적 JDK 업그레이드를 수행하는 것은 현실적으로 불가능한 조직이 많다.

게다가 Virtual Threads(Java 21), String Templates(Java 21 preview → 22 preview → 23에서 철회), Unnamed Classes(Java 21 preview)처럼 preview 기능이 LTS에 포함됐다가 다음 버전에서 변경·제거되는 사례가 늘면서, "LTS = 안정"이라는 신뢰가 흔들리고 있다.

오픈소스 벤더들의 독자 노선

오라클의 정책 불확실성이 커지면서, Eclipse Adoptium(Temurin), Amazon Corretto, Azul Zulu, Microsoft Build of OpenJDK 등 비오라클 배포판의 점유율이 꾸준히 상승했다. Adoptium 통계에 따르면, Temurin의 월별 다운로드는 2022년 이후 매년 40% 이상 성장했다.

이들 벤더는 Extended LTS를 별도 상품으로 제공하기도 한다. Azul은 Java 8·11·17에 대해 2031~2035년까지 상업 지원을 제공하고, Amazon Corretto는 AWS 환경에서 Java 8·11을 2026년 이후에도 지원한다. 문제는 이로 인해 "어떤 JDK를 써야 하는가"라는 질문이 더욱 복잡해졌다는 점이다.

개선 방향 논의

커뮤니티 내에서 제기되는 개선안은 크게 세 가지로 수렴한다.

첫째, 단일 LTS 벤더 중립 기구 설립이다. Apache Software Foundation이나 Linux Foundation 산하에 OpenJDK LTS 관리 기구를 두고, 벤더와 독립적으로 보안 패치 기간을 보장하자는 제안이다. 이미 Adoptium Working Group이 이 방향으로 움직이고 있으나, 오라클의 참여가 제한적이라 한계가 있다.

둘째, LTS 정의 표준화다. "LTS"라는 레이블에 최소 지원 기간·보안 패치 의무·ABI 안정성 조건을 명시하는 공식 스펙을 JEP(JDK Enhancement Proposal)로 제안하자는 흐름이 있다. 그러나 오라클이 JEP 프로세스를 사실상 통제하고 있어 중립적 표준화가 쉽지 않다.

셋째, 마이그레이션 도구 고도화다. OpenRewrite 프로젝트는 Java 8→17, 11→21 자동 코드 변환을 지원하며, 2025년 기준 Java 17→21 마이그레이션 레시피까지 추가됐다. 도구 측면의 발전이 정책 측면의 혼란을 일부 상쇄하고 있다.

현실적 전망

단기적으로 Java 21이 Java 8·11의 뒤를 이어 엔터프라이즈 기본 버전으로 자리잡을 것으로 보인다. JetBrains의 2025 개발자 설문에서도 Java 21 사용 비율이 전년 대비 두 배 이상 증가했다. 그러나 LTS 정책의 벤더 종속성 문제와 마이그레이션 비용 구조는 단기간에 해결되기 어렵다. 결국 이 문제는 기술적 해법보다 오라클·커뮤니티·기업 간의 거버넌스 협상에서 풀려야 할 과제다.