OpenJDK 11 지원 종료: 일정, 위험 요소 및 대응 방안 (2026년 가이드)

주요 내용

• OpenJDK 11에 대한 무료 보안 패치 제공은 2024년 말에 종료되었습니다. 연장 지원 계약을 체결하지 않았다면, 그 이후에 발견된 모든 CVE 취약점은 현재 실행 환경에서 패치되지 않은 채로 남아 있습니다.
• 실제 지원 종료(EOL) 날짜는 특정 공급업체 빌드를 사용하는지에 따라 달라지며, 커뮤니티 전체에 적용되는 단일 날짜가 아닙니다.
• Java 17이나 21로 업그레이드하는 것이 장기적으로는 올바른 선택이지만, 라이브러리 종속성과 인증된 애플리케이션 스택 때문에 생각보다 쉽지 않습니다.
• 벤더나 TuxCare와 같은 제3자 업체가 제공하는 확장된 수명 주기 지원을 통해, 자체 일정에 맞춰 마이그레이션을 계획하는 동안에도 OpenJDK 11에 대한 패치 적용을 지속할 수 있습니다.

현재 프로덕션 환경에서 OpenJDK 11을 사용 중이라면, 이미 위험한 고비를 넘긴 셈입니다. 2024년 말부터 무료 커뮤니티 패치 제공이 중단되었으며, 그 이후에 공개된 모든 CVE는 유료 지원을 받지 않는 한 해당 런타임 환경에서 수정되지 않은 채로 남아 있습니다.

OpenJDK 11의 지원 종료는 더 이상 대비해야 할 미래의 일이 아닙니다. 이미 현실이 되었으며, 이로 인해 보안 상태는 서서히 악화되고 있습니다. 이 가이드에서는 구체적인 일정을 살펴보고, 커뮤니티 지원이 종료되면 어떤 변화가 발생하는지, 그리고 “그냥 Java 17로 업그레이드하면 되겠지”라는 말이 이번 분기 내에 실현 불가능한 상황일 때 선택할 수 있는 현실적인 대안들을 안내합니다.

OpenJDK 수명 주기 개요

OpenJDK에는 단일하고 통일된 지원 주기가 없는데, 이것이 바로 팀들이 가장 먼저 부딪히는 난관입니다.

상류 프로젝트인 OpenJDK 자체는 릴리스당 6개월간의 업데이트만 보장합니다. 그 외의 모든 일정은 Red Hat, Oracle, Amazon, Azul, Microsoft, Eclipse Adoptium과 같은 하류 벤더에서 제시하는 것입니다. 각 벤더는 자체 빌드를 배포하며, 각자 EOL(지원 종료) 날짜를 정합니다.

이 차이는 대부분의 사람들이 생각하는 것보다 훨씬 중요합니다. ‘제품 수명 종료(EOL)’와 ‘지원 종료’라는 용어는 CVE(공통 취약점 및 노출)가 보고되기 전까지는 서로 바꿔 쓰이곤 하지만, 일단 CVE가 보고되면 그 차이가 갑자기 엄청난 의미를 갖게 됩니다. EOL은 대개 “해당 공급업체로부터 더 이상 무료 업데이트를 받을 수 없다”는 뜻입니다. 반면 지원 종료는 “유료든 무료든 어디에서도 도움을 받을 수 없다”는 것을 의미합니다. OpenJDK의 경우, 현재 공급업체의 EOL이 도래하더라도 다른 곳에서 유료 지원을 받을 수 있습니다. 이것이 바로 공급업체 및 타사 확장 지원 프로그램의 핵심입니다.

다음은 각 라이프사이클 단계에서 실제로 얻을 수 있는 내용을 대략적으로 정리한 지도입니다:

참고할 점: Java 8, 11, 17, 21, 25에 붙은 “LTS” 표기는 공급업체의 관례일 뿐, 상류 OpenJDK의 약속은 아닙니다. 오라클이 이를 시작했고, 나머지 생태계도 이를 따랐습니다. 프로젝트 자체는 사용자의 서버에 무엇이 설치되어 있든 상관없이 6개월마다 업데이트됩니다.

OpenJDK 릴리스 유형

OpenJDK는 6개월 주기로 출시되지만, 벤더들은 릴리스가 LTS인지 여부에 따라 이를 매우 다르게 취급합니다.

LTS 릴리스

LTS 릴리스는 공급업체가 수년간 유지 관리를 약속하는 버전입니다. Java 8, 11, 17, 21, 25가 현재의 LTS 버전입니다. 이러한 버전에는 주요 공급업체로부터 보안 패치, 버그 수정 사항, 분기별 중요 패치 업데이트가 역포트됩니다. 프로덕션 환경에서 시스템을 운영 중이라면 거의 확실히 LTS 릴리스를 선택해야 합니다. 바로 이것이 LTS 릴리스가 존재하는 이유입니다.

커뮤니티 지원에는 일반적으로 무료 보안 패치와 버그 수정이 포함되지만, 각 버전의 공식 지원 종료(EOL) 날짜에 종료됩니다. 그 이후에는 공급업체별 또는 타사 확장 지원 프로그램을 통해서만 업데이트를 받을 수 있습니다.

OpenJDK 커뮤니티 외에도, 여러 벤더와 배포판 업체들은 각기 다른 OpenJDK 버전에 대한 자체 빌드와 지원 일정을 제공합니다. 이러한 일정은 제각각이며, OpenJDK와 Oracle JDK의 주요 차이점을 이해하면 장기적인 지원 전략에 적합한 배포판을 선택하는 데 도움이 될 수 있습니다.

비 LTS 릴리스

비 LTS 릴리스(Java 9, 10, 12, 13, 14, 15, 16, 18, 19, 20, 22, 23, 24, 26)는 6개월간 업데이트를 제공받은 후 공식 지원에서 제외됩니다. 이 릴리스들은 프로덕션 워크로드가 아닌, 기능을 조기에 접하고자 하는 개발자들을 위한 것입니다. New Relic의 '2024년 자바 생태계 현황' 보고서에 따르면, 프로덕션 애플리케이션 중 비 LTS 버전을 실행하는 비율은 2% 미만입니다. 이는 당연한 결과입니다. 비 LTS 버전을 사용한다는 것은 사실상 6개월마다 강제 업그레이드를 감수하겠다는 뜻이기 때문입니다.

확장 지원 등급

표준 LTS 외에도, 벤더들은 유료 연장 지원 단계를 추가로 제공합니다. 오라클은 LTS 버전에 대해 5년간의 프리미어 지원(Premier Support)을 제공한 뒤, 3년간의 연장 지원(Extended Support)을 이어가고, 그 후에는 보안 수정 사항이 포함되지 않는 무기한 유지 지원(Sustaining Support)을 제공합니다. 레드햇(Red Hat)도 유사한 구조를 제공하며, OpenJDK 11의 경우 별도의 유료 추가 옵션인 ELS-1 단계를 별도로 제공합니다. TuxCare의 OpenJDK용 Endless Lifecycle Support와 같은 타사 서비스는 이를 한 단계 더 발전시켜, 사용자가 처음 배포한 벤더 빌드와 관계없이 필요한 기간 동안 지속적인 CVE 패치를 제공합니다.

알아두면 좋은 팁: “LTS” 지원 기간은 오라클이 정한 기간이 아니라, 여러분이 빌드를 다운로드한 공급업체가 명시한 기간을 따릅니다. OpenJDK의 Microsoft 빌드, Amazon Corretto, Azul Zulu, Eclipse Temurin은 모두 동일한 Java 버전에 대해 서로 다른 지원 종료일을 가지고 있습니다. 지원 기간이 아직 몇 년이나 남았다고 가정하기 전에, 해당 공급업체가 공개한 라이프사이클 페이지를 반드시 확인하시기 바랍니다.

OpenJDK 11 지원 종료: 실제로 중요한 날짜들

자바 11은 자바 8에 이어 두 번째 LTS 릴리스로 2018년 9월에 출시되었습니다. 지원 기간은 사용 중인 빌드에 따라 크게 달라지며, 아래 표에서 볼 수 있듯이 일부 벤더는 대부분의 팀이 예상하는 것보다 훨씬 더 긴 지원 기간을 제공하고 있습니다.

실제 상황은 대부분의 팀이 예상하는 것보다 훨씬 다양합니다. ELS-1 구독 없이 Red Hat 빌드를 사용 중인 경우, 무료 패치 제공은 2024년 10월 31일에 종료되었습니다. 이 플랫폼에서 더 광범위한 소프트웨어 스택을 관리하는 팀의 경우, 다가오는 RHEL 8 지원 종료 일정을 파악하는 것이 운영 계획 수립에 있어 마찬가지로 중요합니다. 오라클의 프리미어 지원은 2023년 9월로 더 일찍 종료되었습니다. 하지만 코레토(Corretto), 테무린(Temurin) 또는 아줄 줄루(Azul Zulu)를 사용 중이라면, 여전히 공급업체의 유효 지원 기간 내에 있을 수 있습니다. 실제 위험 노출 여부는 단순히 버전 번호뿐만 아니라, 어떤 빌드를 실행 중인지와 패치 수준이 얼마나 최신인지에 따라 달라집니다.

주의하세요: “지원되는 버전을 사용 중입니다”라는 말은 종종 “6개월 전에 최신 빌드를 다운로드한 후 한 번도 업데이트하지 않았습니다”라는 뜻입니다. OpenJDK 공급업체들은 분기별로 중요 패치 업데이트(Critical Patch Updates)를 배포합니다. 만약 사용 중인 빌드의 패치 수준이 90일 이상 지난 것이라면, 기술적으로 여전히 지원 대상인 버전이라 하더라도 패치되지 않은 CVE 취약점이 존재하게 됩니다.

OpenJDK 8은 어떨까요?

자바 8의 경우도 비슷한 양상이지만, 그 일정은 대부분의 예상보다 더 길어졌습니다. 오라클의 자바 8 무료 공개 업데이트는 2019년 1월을 기해 상용 사용자 대상 서비스를 종료했습니다. 하지만 여러 벤더들은 그 이후로도 오랫동안 자체 빌드를 계속 제공해 왔습니다.

레드햇(Red Hat)의 OpenJDK 8 지원은 RHEL 구독자를 대상으로 최소 2026년까지 이어지며, 아줄(Azul), 아마존 코레토(Amazon Corretto), 이클립스 테무린(Eclipse Temurin)은 각기 다른 수준의 적극적인 유지보수를 통해 빌드를 계속 제공하고 있습니다. 2026년 초 기준으로, Java 8은 여전히 운영 환경 워크로드에서 상당한 비중을 차지하고 있었으며, 일부 설문조사에서는 Java 11과 거의 비슷한 수준인 것으로 나타났습니다.

자바 8과 자바 11의 차이점은 자바 8이 “지원 종료(EOL)” 시점을 훨씬 더 오래 넘긴 상태라는 점입니다. 따라서 여전히 자바 8을 사용 중인 조직들은 이 결정에 대해 더 신중한 태도를 보이는 경향이 있습니다. 반면 자바 11을 사용하는 팀들은 종종 지원 종료 시점이 눈 깜짝할 사이에 다가온 탓에, 이제 막 전환에 대한 논의를 시작하는 단계에 있는 경우가 많습니다.

Java 8과 Java 11 워크로드를 모두 관리하고 있다면, 고려해야 할 사항은 비슷합니다. 수명이 긴 LTS 릴리스 기간 동안 누적되는 CVE의 양은 경각심을 불러일으킵니다. Java 8의 CVE 이력은 패치 없이 운영 중인 Java 11이 앞으로 어떤 상황에 직면하게 될지 보여주는 유용한 참고 자료가 됩니다.

자바 11과 8은 여전히 어디에나 있습니다

뉴 릴릭(New Relic)의 데이터에 따르면, 수십만 개의 운영 환경 애플리케이션에서 수집된 자료를 바탕으로 볼 때, Java 11과 Java 8을 합친 비중이 전체 운영 워크로드의 약 62%를 차지하며, 이 중 Java 11은 33%, Java 8은 28.8%를 차지합니다.

여기에는 단순한 조직의 관성 때문만이 아니라 실질적인 이유가 있습니다. Java 11과 8은 거의 모든 산업 분야의 웹 애플리케이션, 백엔드 서비스, 미들웨어 플랫폼, 내부 도구를 뒷받침하는 안정적이고 잘 정립된 버전입니다. 이들 중 상당수는 자체적인 라이프사이클 제약 조건을 가진 프레임워크에 의존하고 있습니다. 예를 들어, 미들웨어 플랫폼이 Java 11에서만 인증된 경우, 런타임 업그레이드는 운영 팀이 단독으로 결정할 수 있는 문제가 아닙니다.

비즈니스에 필수적인 애플리케이션이거나, 문서화가 제대로 되어 있지 않거나, 개발 당시보다 인원이 절반으로 줄어든 팀이 유지보수하고 있는 경우, 해당 애플리케이션을 재작성하거나 업그레이드하는 것이 항상 가능한 것은 아닙니다. 이는 실패가 아니라, 엔터프라이즈 소프트웨어가 작동하는 방식의 현실입니다.

커뮤니티 지원이 종료되면 어떻게 되나요?

지원 종료(EOL) 다음 날에는 별다른 일이 일어나지 않습니다. JVM은 계속 실행되고, 애플리케이션도 정상적으로 작동합니다. 바로 그게 문제입니다. 오류가 발생해도 아무런 징후가 없기 때문에, 나중에 패치할 수 없는 CVE로 드러나게 됩니다.

실제로 변경되는 내용은 다음과 같습니다:

• 사용 중인 Java 버전에 대한 CVE 패치 제공이 중단됩니다: EOL 이후에 발견된 취약점은 무료 채널을 통해 해당 런타임 환경에서 수정되지 않습니다. 취약점은 누적되며, 새로운 취약점이 공개될 때마다 보안 위험은 커집니다.
• 규정 준수 프레임워크가 걸림돌이 되기 시작합니다:SOC 2, PCI DSS, HIPAA 및 FedRAMP는 모두 알려진 취약점에 대한 문서화된 패치 관리를 요구합니다. 지원 종료(EOL)된 런타임을 사용한다고 해서 자동으로 감사에 불합격되는 것은 아니지만, 이를 방어하는 일은 점점 더 어려워집니다.
• 의존성 드리프트가 가속화되고 있습니다: 라이브러리와 프레임워크는 자체 생태계가 발전함에 따라 구형 Java 버전에 대한 지원을 중단하므로, 고정된 런타임 환경 주변의 소프트웨어는 호환성이 서서히 저하됩니다.
• 컨테이너 기본 이미지의 업데이트 중단: Docker Hub의 openjdk:11 이미지는 커뮤니티 지원 종료(EOL)보다 훨씬 전에 사용 중단되었습니다. 여전히 이 이미지를 가져오고 있다면, 알려진 취약점이 포함된 고정된 스냅샷을 가져오고 있는 것입니다.
• 공급업체의 책임은 귀하에게 이전됩니다: 대부분의 엔터프라이즈 소프트웨어 계약에는 지원되는 소프트웨어의 운영에 관한 조항이 포함되어 있습니다. EOL(지원 종료) 런타임 환경에서 소프트웨어를 사용하게 되면, 그 위험은 귀하가 직접 감수하게 됩니다.

왜 “그냥 업그레이드하면 되잖아”라는 말이 말처럼 쉽지 않은가

“Java 17이나 21로 업그레이드하라”는 일반적인 조언은 프레젠테이션 자료에서는 올바른 답이지만, 실제 많은 코드베이스에서는 잘못된 답입니다. 팀들이 아마도 그렇게 해서는 안 된다는 것을 알면서도 OpenJDK 11을 계속 사용하는 이유는 다음과 같습니다.

라이브러리 및 프레임워크 종속성

놀랍게도 많은 양산용 자바 애플리케이션이 수년 동안 최신 JDK에 맞춰 재컴파일되거나 테스트되지 않은 라이브러리에 의존하고 있습니다. 자바 11에서 17로 업그레이드하면 다음과 같은 문제가 발생하기 시작합니다:

• 구형 라이브러리가 암묵적으로 의존하던 API를 제거했습니다
• 더 강화된 캡슐화(Java 9에서 도입되어 이후 더욱 엄격해짐)로 인해 구형 바이트코드 조작 라이브러리가 호환되지 않게 됨
• Lombok, Mockito, Byte Buddy의 구버전과 같은 라이브러리 간의 호환성 문제
• JDK에서 완전히 제거된 JAXB, JAX-WS 및 기타 Java EE API

20명으로 구성된 엔지니어링 팀이 마이그레이션 작업 도중에 있다고 상상해 보세요. 이들은 애플리케이션 코드, 빌드 도구, CI 파이프라인을 업그레이드했습니다. 그런데 3년 전 퇴사한 엔지니어가 마지막으로 관리했던 내부 SSO 라이브러리에서 오류가 발생합니다. IllegalAccessError 첫 번째 통합 테스트에서 문제가 발생했습니다. 라이브러리를 포크하기로 결정하기까지 일주일 동안 디버깅을 해야 했는데, 이건 단지 하나의 종속성 문제일 뿐입니다.

인증된 애플리케이션 스택

엔터프라이즈 소프트웨어 공급업체들은 자사 제품이 특정 Java 버전에 호환되도록 인증합니다. ERP 시스템, 뱅킹 플랫폼, 보험 인수 도구, 의료 소프트웨어 등은 대개 “Java 8 및 11”만 지원한다고 명시한 지원 매트릭스를 갖추고 있으며, 그 외 버전은 지원하지 않습니다. 기본 JDK를 업그레이드하면 지원 계약이 무효화됩니다. 이러한 경우 런타임 업그레이드는 코드의 복잡성 때문이 아니라 계약 조항 때문에 차단되는 것입니다.

이주 비용 및 위험 수용 능력

마이그레이션은 문제를 일으키기 마련입니다. 이는 팀들이 과거 모든 LTS 버전 전환 과정에서 배운 교훈입니다. 규모가 상당한 코드베이스를 Java 11에서 17로 마이그레이션하려면, 모든 직접 및 간접 의존성(대개 200개 이상의 라이브러리)을 점검하고, 빌드 도구와 CI 파이프라인을 업데이트하며, 전체 회귀 테스트 및 부하 테스트를 재실행하고, 서비스 간 협업을 조정하며, 제거된 API를 중심으로 리팩토링을 수행해야 합니다. 10개의 서비스를 운영하는 팀의 경우, 이는 엔지니어링 리소스의 4분의 1을 소모하는 작업입니다. 200개의 서비스를 운영하는 팀에게는 1년 동안 진행되는 대규모 프로젝트가 됩니다.

현실 점검: 벤더들은 30분짜리 스크린캐스트로 Java 8에서 17로의 업그레이드를 보여주는 “간편 마이그레이션” 가이드를 공개하는 것을 좋아합니다. 이러한 데모는 종속성이 다섯 개뿐인 깔끔한 Spring Boot 애플리케이션을 사용합니다. 하지만 실제 운영 환경의 코드베이스는 수년에 걸쳐 복잡성이 누적되었고, 더 이상 사용되지 않는 내부 라이브러리 포크가 여러 개 있으며, 아마도 출처를 아무도 모르는 JAR 파일도 적어도 하나는 있을 것입니다. 데모가 아닌, 이러한 현실을 고려하여 계획을 세우십시오.

OpenJDK 11의 지원 종료 후 취해야 할 조치

앞으로 나아갈 현실적인 길은 세 가지가 있으며, 어떤 길이 옳은지는 실제로 얼마나 많은 이주 여유가 있는지에 달려 있습니다.

Lifecycle 연장 지원

당장 마이그레이션을 진행할 수는 없지만 CVE에 대한 패치를 미루는 것도 감당할 수 없다면, 연장 지원이 가장 깔끔한 해결책입니다. 오라클(Oracle)이나 레드햇(Red Hat)과 같은 주요 벤더들은 명확한 기간이 정해진 유료 연장 지원 서비스를 제공하며, 더 유연한 지원이 필요한 조직의 경우 독립적인 공급업체들이 그 공백을 메워줍니다.

TuxCare의 OpenJDK용 Endless Lifecycle Support(ELS)는 6, 7, 8, 11, 17 버전을 지원하며, 여기에는 커뮤니티 지원 종료(EOL) 시점이 이미 지난 버전도 포함됩니다. 이 서비스는 현실적으로 준수하기 어려운 업그레이드 일정에 얽매이지 않으면서도 지속적인 보안 패치를 필요로 하는 팀을 위해 특별히 설계되었습니다:

• 커뮤니티 지원 종료(EOL)가 지난 OpenJDK용 역포트된 CVE 패치
• 벤더에 구애받지 않음 – 원래 Red Hat 빌드의 OpenJDK, Adoptium, Corretto 또는 사용자 지정 설치를 배포했는지 여부와 관계없이 작동합니다.
• 애플리케이션 코드를 변경할 필요가 없습니다
• 보장은 2년이나 3년 같은 정해진 기간이 아니라, 고객님이 필요로 하는 기간 동안 계속됩니다
• RHEL, CentOS, AlmaLinux, Rocky Linux, Oracle Linux, Debian, Ubuntu 등 엔터프라이즈 리눅스 계열 및 데비안 기반 배포판을 다룹니다.

TuxCare의 OpenJDK용 ELS는 런타임 수준 솔루션으로, Java 런타임에 특화된 패치를 제공합니다. 만약 그 기반에 EOL(지원 종료) 리눅스 배포판(예: CentOS 7)을 함께 사용 중이라면, TuxCare는 운영 체제용 별도의 ELS를 제공하며, 이는 OS 패키지 세트의 일부인 OpenJDK를 포함하여 전체 OS 패키지 세트를 포괄합니다. 이 두 제품은 별개의 제품입니다. OpenJDK용 ELS는 사용 중인 OS와 관계없이 런타임 환경을 지원하며, OS용 ELS는 배포판 전체를 지원합니다. 상황에 따라 한 가지, 다른 하나, 또는 두 가지 모두 필요할 수 있습니다.

단순히 Java 런타임에 대한 문제라면 – 지원되는 최신 OS에서 실행하는 경우라도 – TuxCare ELS for OpenJDK를 사용하면 OS 수준의 구독 없이도 이를 해결할 수 있습니다.

Java 17 또는 Java 21로 마이그레이션

기술적 역량이 충분하고 기존 기술 스택이 이를 수용할 수 있다면, 최신 LTS 버전으로 마이그레이션하는 것이 장기적으로 올바른 해결책입니다. New Relic에 따르면 2024년 기준 Java 17의 도입률은 운영 환경 애플리케이션의 35%에 달했으며, 출시 후 첫 6개월 동안 Java 21의 도입 속도는 Java 17보다 거의 3배나 빨랐습니다.

Java 17은 의미 있는 진전을 이룬 버전이지만, 이를 계획에 반영할 때 고려해야 할 별도의 지원 일정이 있습니다. OpenJDK 17을 장기적인 목표로 삼기 전에, 해당 버전의 EOL에 대해 자세히 알아보시기 바랍니다.

실용적인 시작점 몇 가지:

• 실행 jdeps --jdk-internals 제거된 내부 API의 사용 여부를 조기에 파악하기 위해 애플리케이션 JAR 파일을 분석합니다
• 대상 Java 릴리스를 지원하는 최신 버전이 있는지 모든 Maven/Gradle 종속성을 검토하십시오
• 전체 배포에 앞서 개발, 테스트 및 카나리아 배포 단계를 거쳐 마이그레이션을 진행하십시오
• “또 다른 도서관을 발견했다”는 식의 예상치 못한 상황에 대비해 예산에 여유를 두세요. 이런 일은 결코 가정이 아닙니다.

가능하다면 Java 21을 목표로 하는 것이 좋습니다. Java 21은 여러 벤더를 통틀어 남은 지원 기간이 가장 긴 버전 중 하나이며, 가상 스레드 기능을 포함하고 있어 고동시성 워크로드에서 스레드 풀 오버헤드를 크게 줄일 수 있습니다.

EOL 상태를 유지하고 위험을 감수하십시오

많은 팀이 조용히 이렇게 하고 있습니다. 이 길을 선택한다면, 신중하게 진행하십시오:

• 해당 결정을 공식적으로 문서화하고 보안 및 규정 준수 담당 임원진의 승인을 받으십시오
• 보완 통제 조치(WAF, 런타임 애플리케이션 자체 보호, 더 엄격한 네트워크 정책)를 구현한다
• 매주 Java 11 및 Java 8에 대한 CVE 피드를 모니터링하고, 각 취약점 공개 내용을 귀사의 실제 노출 위험과 대조하여 평가하십시오
• 마이그레이션이나 확장 지원 도입에 대한 확실한 마감 기한을 정하십시오. “나중에 하겠지”라는 생각은 결국 2028년이 되어도 여전히 Java 11을 사용하게 되는 결과를 초래합니다.

이 방법은 가장 위험한 길이며, 영원히 지속될 수는 없습니다. 하지만 현실적인 대안이 2주 만에 제대로 검증되지 않은 마이그레이션을 강행하는 것이라면, 문서화되고 통제된 대기 상태를 유지하는 것이 때로는 더 타당한 선택이 될 수 있습니다. 결정적인 차이는 ‘의도’에 있습니다.

현장의 목소리: EOL 전환을 가장 원활하게 이겨내는 팀은 전환일 12개월 전부터 계획을 세운 팀들입니다. 만약 2026년에 이 글을 읽고 있는데도 여전히 계획 없이 OpenJDK 11을 사용 중이라면, 여유로운 시간은 이미 끝났습니다. 이번 분기 안에 다음 세 가지 경로 중 하나를 선택하십시오.

OpenJDK 11 지원 종료(EOL) 이후의 다음 단계

OpenJDK 11에 대한 업스트림 커뮤니티 지원은 2024년 말에 종료되었으며, 향후 몇 년 동안 여러 벤더의 지원 기간도 차례로 종료될 예정입니다. 사용 중인 JVM은 이러한 일정을 신경 쓰지 않겠지만, 감사 담당자, CISO, 그리고 사고 대응 팀은 점점 더 이를 중요하게 여기게 될 것입니다.

마이그레이션이 가능하다면 Java 17보다는 Java 21을 목표로 삼으십시오. 지원 기간이 더 길 뿐만 아니라, 가상 스레드 기능은 고동시성 워크로드에 있어 의미 있는 개선 사항입니다. 당장 마이그레이션이 어렵지만 지속적인 보안 패치가 필요하다면, TuxCare ELS for OpenJDK를 고려해 보십시오. 이 솔루션은 다양한 엔터프라이즈 리눅스 및 데비안 기반 환경에서 Java 8, 11 및 지원 종료(EOL)가 지난 기타 버전을 지원하므로, 다음 규정 준수 검토 전에 검토해 볼 가치가 있습니다.

어떤 길을 선택하든, 의도적으로 선택하십시오. 최악의 결과는 아무런 조치도 취하지 않은 채 EOL(지원 종료) 상태인 Java 11을 계속 사용하는 것입니다.

요약

기사 이름

OpenJDK 11 지원 종료: 일정, 위험 요소 및 대응 방안 (2026년 가이드)

설명

OpenJDK 11 지원 종료 안내: 주요 일정, 보안 위험, 그리고 2026년 업그레이드 또는 지원 연장 옵션.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고