OpenJDK 17 지원 종료: 주요 일정, 선택 사항 및 지원

주요 내용

• OpenJDK 17에는 단일 지원 종료일이 정해져 있지 않으며, 공급업체의 지원 기간은 2026년 9월부터 적어도 2029년 10월까지 이어집니다.
• 지원이 종료되면 CVE 패치 제공이 중단되며, 규정 준수 감사 통과 및 보험 갱신이 더 어려워집니다.
• 이전을 준비하지 못한 팀은 런타임이나 코드를 변경하지 않고도 타사 확장 지원을 통해 CVE 패치를 계속 받을 수 있습니다.

만약 여러분의 프로덕션 워크로드가 여전히 OpenJDK 17을 사용 중이라면, 여러분만 그런 것은 아닙니다. Java 17이 “안전한” LTS 선택지였던 데에는 이유가 있습니다. 안정적이고, 지원이 잘되며, 호환성도 뛰어나기 때문이죠. 문제는 이제 “지원”이라는 개념이 사용 중인 배포판에 따라 다른 의미를 가지게 되었으며, 지원 기간도 각기 다르다는 점입니다.

이 글에서는 OpenJDK 17의 EOL이 실제로 어떤 의미를 갖는지, 가장 널리 사용되는 빌드별 구체적인 일정은 무엇인지, 문서에 나와 있는 것보다 마이그레이션이 더 어려운 이유는 무엇인지, 그리고 코드베이스 준비가 완료되기 전에 마감일이 다가왔을 때 실제로 어떤 선택지가 있는지 다룹니다.

OpenJDK 수명 주기 및 지원 개요

OpenJDK는 오라클이 관리하는 Java SE의 오픈소스 참조 구현체입니다. 하지만 이는 “Oracle JDK”와는 다른 개념이며, 바로 이러한 차이 때문에 EOL 계획 수립이 혼란스러워지는 것입니다.

업스트림 OpenJDK 커뮤니티는 다음 기능 릴리스가 출시될 때까지 약 6개월 동안 주요 릴리스를 지원합니다. 장기 지원(LTS)은 다운스트림 영역에 속하며, 각 벤더가 자체 빌드를 패키징하고 패치를 적용하여 관리합니다. 자바가 6개월 주기의 릴리스 주기로 전환된 이후로는 특정 버전에만 LTS 지정이 이루어집니다. 자바 17이 그 중 하나이며, 자바 21과 자바 25는 더 최근의 LTS 릴리스입니다.

현재 LTS 버전의 현황은 다음과 같습니다:

채택 속도는 여전히 이러한 시점에 비해 상당히 뒤처져 있다. JRebel이 발표한 ‘2025 자바 개발자 생산성 보고서’에 따르면, 응답자의 61%가 여전히 자바 17을 사용하고 있는 것으로 나타났습니다. 전체 표본을 살펴보면, 72%가 무료 공개 지원 기간이 만료된 오라클 배포판을 사용하고 있다고 답했으며, 이 중 35%는 자바 8을, 32%는 자바 11을 사용하고 있었습니다. 귀사의 팀도 마이그레이션을 계획 중인 버전과 더불어 적어도 하나의 EOL(지원 종료) 버전을 관리하고 있을 가능성이 높습니다.

OpenJDK 17 주요 일정

가장 중요하게 이해해야 할 점은, OpenJDK 17의 종료일(EOL)이 단일하게 정해져 있지 않다는 것입니다. 각 배포판마다 자체적인 일정을 따릅니다.

현재 대부분의 팀이 주목해야 할 두 가지 시점은 2026년 9월 오라클 프리미어 지원 종료일과 2027년 12월 레드햇 지원 종료일입니다. 유니버설 구독(Universal Subscription)이 없는 상태에서 오라클 JDK 17을 사용 중이라면, 무료 보안 업데이트는 2024년 9월에 중단되었습니다. 업데이트를 계속 받으려면 유료 오라클 Java SE 유니버설 구독이 필요합니다.

Oracle과 OpenJDK 빌드의 라이선스 및 지원 조건이 어떻게 다른지에 대한 자세한 내용은 당사의 ‘OpenJDK 대 Oracle JDK’ 가이드를 참조하십시오.

Java 17은 오라클이 LTS 출시 주기를 2년으로 전환한다고 발표하면서 출시된 LTS 버전입니다. Java 21부터 LTS 버전 간 간격이 3년에서 2년으로 단축되었습니다. 주기가 짧아짐에 따라 기업들은 이제 3년이 아닌 2년마다 업그레이드 압박을 받게 되었지만, 대부분의 팀은 이에 맞춰 마이그레이션 일정을 조정하지 못하고 있습니다.

OpenJDK 17의 지원 종료 시 실제로 어떤 일이 일어날까요?

JVM은 계속 실행됩니다. 바로 이 점 때문에 팀들은 EOL(지원 종료) 날짜를 무시하게 되는 것입니다. 첫날부터 문제가 발생하는 일은 없으니까요. 어제까지 정상적으로 작동하던 애플리케이션은 내일도 전혀 변함없이 보입니다. 달라지는 것은 상류에서 일어나는 일들입니다. 더 정확히 말하자면, 더 이상 일어나지 않는 일들입니다.

제품 수명 종료(EOL) 이후에는 세 가지 요인이 배경에서 점차 위험을 축적하기 시작합니다.

1. 보안 패치 중단

이것이 가장 큰 문제입니다. EOL(지원 종료) 이후에는 유지보수 담당자가 해당 버전에 CVE 수정 사항을 역포트하는 작업을 중단합니다. JVM 내부, 표준 라이브러리, TLS 구현, 역직렬화 경로 등에서 발견된 새로운 취약점들은 해당 빌드에서는 전혀 수정되지 않습니다. 이러한 취약점들은 Java 21과 25에서 수정될 뿐입니다. 사용 중인 버전은 그대로 유지될 뿐입니다.

JVM은 결코 사소한 대상이 아닙니다. 지난 10년 동안 자바는 가장 활발하게 악용된 취약점 유형 중 일부와 관련되어 왔으며, 분기별 중요 패치 업데이트 주기마다 CVE가 계속해서 보고되고 있습니다. 사용 중인 버전이 해당 목록에서 제외되면, 지원 종료(EOL) 시점부터 최종적으로 마이그레이션을 완료할 때까지 발생하는 패치되지 않은 문제들이 계속 누적될 수밖에 없습니다.

2. 규정 준수가 점점 더 어려워지고 있다

PCI DSS, HIPAA, SOC 2, FedRAMP, ISO 27001 등 대부분의 규정 준수 프레임워크는 지원되는 소프트웨어를 최신 패치가 적용된 상태로 운영해야 한다는 명시적 또는 묵시적 요구 사항을 포함하고 있습니다. 감사관들은 이 부분에 대해 점점 더 구체적인 기준을 제시하고 있으며, 감사 결과 보고서에서 “업그레이드를 계획 중이었습니다”라는 답변은 만족스러운 답변이 될 수 없습니다.

지원 종료(EOL)된 Java 버전을 사용하면 다음과 같은 상황에 처하게 됩니다:

• 자동 취약점 스캔 실패 – Nessus, Qualys, Wiz 및 이와 유사한 도구들은 기본적으로 지원 종료(EOL)된 런타임을 경고로 표시합니다.
• 매 감사 주기마다 예외 사항을 문서화하고 그 근거를 제시하는 데 추가적인 시간을 할애해야 함
• 사이버 보험 갱신을 복잡하게 만드는 요인 – 현재 여러 주요 보험사들이 EOL(지원 종료) 소프트웨어가 운영 환경에 사용되고 있는지 직접 묻고 있다
• “그것이 근거가 없다는 것을 알고 있었기 때문에” 정보 유출 공개 위험을 초래했다는 점은, 사고 발생 후에 설명하기 매우 어려운 사정입니다.

현실 점검:2025년 버라이즌 DBIR 보고서에 따르면, 초기 침입 경로로서 취약점 악용 사례가 전년 대비 34% 증가했으며, 현재 보안 침해 사고의 20%를 차지하는 것으로 나타났습니다. 패치가 적용되지 않은 런타임 환경이 바로 이러한 공격의 표적이 됩니다.

3. 의존성 부패는 서서히 진행되는 문제이다

이 점은 이미 미리 대비했다고 생각하는 팀들을 당황하게 만듭니다. 자바 런타임 버전이 17로 유지된다 해도, 나머지 스택이 그 버전과 함께 고정되는 것은 아닙니다.

프레임워크는 구형 JDK에 대한 지원을 중단합니다. Spring Boot는 매년 새로운 메이저 버전을 출시하며, 기준 버전을 정기적으로 상향 조정합니다. 라이브러리 유지보수 담당자들은 지원 종료(EOL)된 JVM에 대한 테스트를 중단합니다. 컨테이너 베이스 이미지는 최신 JDK를 기준으로 재빌드됩니다. 그러다 어느 순간, 전이적 의존성을 가진 라이브러리가 Java 21 이상에서만 지원되는 기능을 요구하는 의존성 업데이트에 직면하게 되고, 2년 동안 미뤄왔던 업그레이드를 최악의 타이밍인 바로 이번 스프린트 내에 갑자기 진행해야만 하는 상황이 발생합니다.

업그레이드가 항상 쉬운 것만은 아닌 이유

Java 17에서 21이나 25로 넘어가는 과정은 과거 대부분의 주요 버전 전환보다 확실히 수월합니다. 그렇다고 해서 비용이 적게 드는 것은 아닙니다. 바로 이 부분에서 팀들이 실제로 난관에 부딪히게 됩니다.

의존성이 모두 준비되지 않았습니다

자바 버전 업그레이드는 단순히 JVM을 교체하는 것만이 아닙니다. 특정 바이트코드 수준에 고정되어 있거나, 버전 간에 변경된 내부 구조에 의존하는 모든 라이브러리, 프레임워크 및 내부 아티팩트까지 모두 포함됩니다.

17 → 21 경로에서 흔히 발생하는 고장 유형은 다음과 같습니다:

• 반사(Reflection)를 많이 사용하는 라이브러리가 더 엄격한 캡슐화 규칙에 부딪히다
• ASM, 일부 Byte Buddy 버전, 구버전 Hibernate 등 오래된 바이트코드 조작 도구들은 대대적인 업그레이드가 필요합니다.
• 다음 코드를 사용하여 sun.misc.Unsafe 사용 중단 경고가 표시되거나 아예 제거된 API에 부딪히게 되는 경우
• 버전 업그레이드를 동시에 수행해야 하는 빌드 도구(Maven Surefire, Gradle, JaCoCo)
• 병렬 업데이트가 필요한 컨테이너 이미지 및 CI 러너

4년 된 모놀리식 아키텍처를 사용하는 팀은 대개 업그레이드 브랜치가 CI에 반영된 후에야 이러한 문제점의 대부분을 발견하게 됩니다. 이에 대한 예산을 미리 책정해 두세요.

테스트 커버리지가 생각만큼 좋지 않을 가능성이 높습니다

JVM을 업그레이드하면 단위 테스트로는 포착되지 않는 버그가 드러납니다. 버전마다 가비지 컬렉션 동작이 달라지고, 기본 설정도 변경됩니다. JIT 컴파일러가 내리는 결정도 달라집니다. 로케일 처리, 시간대 처리, 정규식 엔진 동작 등 이 모든 요소들이 과거 업그레이드 과정에서 실제 운영 환경의 사고를 일으킨 바 있습니다.

테스트 스위트에서 실제 데이터베이스, 실제 I/O, 현실적인 부하 프로파일을 충분히 검증하지 않으면, 업그레이드는 CI에서는 통과하더라도 실제 운영 환경에서는 실패하게 됩니다. 이는 마이그레이션 계획에서 은근히 생략되기 쉬운 부분이며, “이미 업그레이드했는데 왜 모든 게 망가졌지?”라는 식의 사후 분석이 나오는 주된 원인입니다.

캘린더가 코드베이스와 일치하지 않습니다

기술적인 마이그레이션이 관리 가능한 수준이라 해도, 조직적인 현실은 종종 그렇지 않습니다. 엔지니어링 인력은 분기별로 배정됩니다. 업그레이드 작업은 신규 기능 개발, 보안 백로그, 그리고 그 주에 팀의 주의를 끄는 각종 사고 처리와 경쟁해야 합니다. 서류상으로는 3개월로 예상된 마이그레이션이 실제로는 9개월이 걸리게 되는 이유는, 아무도 이 작업에 방해받지 않고 전념할 수 없기 때문입니다.

현장의 실화: 흔히 볼 수 있는 패턴입니다. 팀이 1분기에 Java 17 → 21 업그레이드를 계획했다가 Spring Boot의 메이저 버전 충돌 문제를 겪어 2분기로 연기하고, SOC 2 감사 준비 과정에 휘말리다 보니 결국 전체 일정이 4분기로 미뤄집니다. 그때쯤이면 Java 25가 출시되어 목표가 다시 바뀌게 됩니다. 실제로 예정된 기간 내에 작업을 완료하는 팀들은 EOL(지원 종료) 날짜를 ‘언젠가 처리할 백로그 항목’이 아니라, 담당자가 지정된 엄격한 프로젝트 마일스톤으로 취급합니다.

OpenJDK 17 지원 종료(EOL) 이후의 선택지

정답은 하나만 있는 것이 아닙니다. 가장 적합한 방법은 귀사의 엔지니어링 역량, 기술 스택의 폐쇄성 정도, 그리고 규정 준수 요건의 엄격성에 따라 달라집니다. 다음은 현실적으로 고려할 수 있는 옵션들입니다.

옵션 1: OpenJDK 17에 대한 타사 확장 지원

현재 일정상 업그레이드가 현실적으로 어렵다면, 타사 확장 수명 주기 지원 서비스를 이용하는 것이 런타임 환경을 변경하거나 코드를 리팩토링하지 않고도 CVE 패치를 계속 받아볼 수 있는 가장 깔끔한 방법입니다. 이 접근 방식은 RHEL, AlmaLinux, Rocky, Ubuntu, Debian 등 다양한 리눅스 배포판에서 OpenJDK 17을 실행 중인 팀에게 특히 효과적입니다. 이러한 환경에서는 OS 지원 수명 주기와 JDK 지원 수명 주기가 정확히 일치하지 않기 때문입니다.

TuxCare의 OpenJDK ‘무한 라이프사이클 지원’ 서비스는 OpenJDK 17, 11, 8, 7 버전을 포함한 대부분의 주요 엔터프라이즈 리눅스 배포판에 대한 지속적인 보안 패치를 제공합니다. 이 접근 방식은 간단합니다. 기존 빌드를 유지한 채 새로운 CVE가 발견될 때마다 패치를 계속 받아, 서두르지 않고 충분한 시간을 두고 본격적인 마이그레이션을 계획할 수 있습니다. 이 서비스는 패치가 적용되지 않은 런타임을 실행하는 것을 용납할 수 없는 규제상의 제약이 있는 팀을 위해 특별히 설계되었지만, 동시에 이번 분기 내에 모든 업무를 중단하고 주요 버전 업그레이드를 수행할 수도 없는 팀을 위한 것입니다.

옵션 2: Java 21 또는 Java 25로 업그레이드

대부분의 팀에게 있어 장기적으로 올바른 선택입니다. 엔지니어링 자원이 충분하다면, 최신 LTS 버전으로 업그레이드하면 수년간의 무료 공개 지원, 상당한 성능 향상, 그리고 지속적으로 발전하는 생태계와의 호환성을 확보할 수 있습니다. 오라클의 지원 로드맵에 따르면, Java 21은 2028년 9월까지, Java 25는 2030년 9월까지 프리미어 지원이 제공됩니다. 단, Corretto, Temurin 또는 다른 빌드를 사용 중인 경우, 공급업체의 구체적인 일정을 확인하시기 바랍니다.

다음과 같은 경우에는 이것이 올바른 결정입니다:

• 코드베이스의 규모가 작거나 테스트가 충분히 이루어져 있어 한 분기 내에 마이그레이션할 수 있습니다.
• CI 테스트는 단순히 컴파일 오류뿐만 아니라 실제 코드 실행 시 나타나는 동작상의 변화까지 포착해 줍니다.
• 주요 종속성들은 이미 Java 21 이상을 지원합니다.
• 여러 방향으로 흩어지지 않고, 집중적인 엔지니어링 스프린트를 계획할 수 있습니다.

옵션 3: 다른 OpenJDK 배포판으로 전환하기

Oracle JDK 17을 사용 중이시며 2024년 9월의 라이선스 변경 소식에 당황하셨더라도, 라이선스 문제를 해결하기 위해 당장 Java 21로 마이그레이션할 필요는 없습니다. Java 코드를 수정하지 않고도 Eclipse Temurin, Amazon Corretto 또는 Microsoft의 OpenJDK 빌드로 전환할 수 있습니다. 이들 모두 TCK 인증을 받았으며, 대부분의 워크로드에서 동작이 동일합니다.

오라클 JDK에서 벗어나는 추세는 이미 몇 년 전부터 이어져 왔습니다. 뉴 릴릭(New Relic)의 데이터에 따르면, 오라클의 JDK 시장 점유율은 2020년 75%에서 2024년 21%로 떨어진 반면, 이클립스 아도프티움(Eclipse Adoptium)은 전년 대비 50% 성장했습니다. 전환을 단행한 대부분의 팀은 이를 위해 자바 코드 한 줄도 수정할 필요가 없었습니다.

전환하기 전에 확인해야 할 몇 가지 사항:

• 새로운 배포판의 Java 17 지원 종료(EOL) 날짜를 확인하십시오. 이 날짜는 1년에서 3년까지 차이가 있습니다.
• 벤더별 JVM 플래그나 확장 기능이 있는지 확인하십시오(드문 경우이지만, 검토해 볼 가치가 있습니다).
• 프로비저닝, 컨테이너 이미지 및 CI를 업데이트하여 새로운 소스에서 가져오도록 설정하십시오.
• 규정 준수 기록을 위해 변경 사항을 문서화하십시오

주의: 디스트로 변경은 전술적인 조치일 뿐, 장기적인 해결책은 아닙니다. Corretto 17과 마이크로소프트의 빌드는 경우에 따라 레드햇의 지원 기간보다 더 오래 지원되지만, 결국 모두 지원이 종료됩니다. 이번 변경을 통해 12~24개월의 유예 기간을 확보하는 데 활용하되, 실제 마이그레이션 계획을 중단할 명분으로 삼아서는 안 됩니다.

선택지 4: 위험을 (의도적으로) 감수하기

일부 팀은 진정으로 이러한 결정을 내리기도 하며, 특정 상황에서는 이를 정당화할 수 있습니다. 내부용 도구, 에어갭 환경, 일회용 워크로드 등 모든 경우가 패치된 런타임에 드는 엔지니어링 비용을 정당화할 수 있는 것은 아닙니다.

의식적으로 결정을 내리고, 이를 문서화한 뒤, 패치가 적용되지 않은 JVM이 대외적으로 노출된 엔드포인트에 남아 있지 않도록 위험을 세분화하십시오. 이와 함께 나머지 스택에 대한 자동화된 패치 관리 방식을 병행하여, 지원이 중단된 구성 요소가 기본적으로 가장 취약한 고리가 되지 않도록 하십시오. 또한, 패치 관리와 취약점 관리의 차이를 명확히 이해해야 합니다. 이 두 가지는 서로 다른 분야이며, 이를 혼동하는 것이 바로 지원이 중단된 구성 요소가 처음부터 간과되는 주된 원인입니다.

TuxCare를 통한 OpenJDK EOL 이후 보안 유지

자바 EOL(지원 종료)에 관한 불편한 진실은, “런타임은 여전히 작동한다”는 점이야말로 이를 우선순위에서 쉽게 제외하게 만드는 주된 이유라는 것입니다. 패치 제공이 중단되고, 종속성이 노후화되며, 감사 결과도 쌓여가다가, 어느 날 갑자기 작동하는 익스플로잇이 포함된 CVE가 발견되는데, 여러분의 버전은 패치 목록에 포함되지 않은 상태인 것입니다.

팀에서 OpenJDK 17을 사용 중인데, 계획상 마이그레이션 일정이 현실과 맞지 않는다면, 이는 드문 일이 아닙니다. 업그레이드는 장기적으로 볼 때 올바른 해결책입니다. 하지만 업그레이드를 제대로 수행할 준비가 되기까지 한두 분기 정도가 더 남은 상황이라면, 그동안 패치를 적용하지 않은 상태로 시스템을 운영하는 것은 상당한 위험을 수반합니다.

TuxCare의 OpenJDK를 위한 ‘무제한 라이프사이클 지원’은 바로 이러한 기간을 위해 마련되었습니다. 동일한 빌드와 워크플로우를 제공하며, 업스트림 지원 일정에 따라 만료될 예정인 CVE 패치도 계속 지원합니다. 이 서비스는 Enterprise Linux 및 Debian 기반 시스템 전반에 걸쳐 OpenJDK 버전 7, 8, 11, 17을 지원하며, 귀사가 필요로 하는 기간 동안 지속적으로 제공됩니다. 가격 정보를 확인하거나 TuxCare 전문가에게 문의하여 귀사의 환경에 적합한 지원 범위를 파악해 보십시오.

요약

기사 이름

OpenJDK 17 지원 종료: 주요 일정, 선택 사항 및 지원

설명

OpenJDK 17의 지원 종료일, 지원 일정, 공급업체별 차이점 및 업그레이드 옵션. EOL이 무엇을 의미하는지, 그리고 Java 17에 대비하는 방법을 알아보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고