RHEL 8 지원 종료: 일정, 위험 요소 및 향후 조치

주요 내용

• RHEL 8은 2029년 5월 31일에 지원 종료됩니다. 해당 날짜 이후에는 유료 연장 지원 애드온을 구매하지 않는 한, Red Hat은 더 이상 보안 패치나 버그 수정 사항을 제공하지 않습니다.
• 2029년 이후에도 구체적인 계획 없이 이 운영 체제를 계속 사용한다면, PCI DSS, HIPAA, SOC 2 및 시기적절한 패치 적용을 요구하는 대부분의 다른 규정 준수 기준을 충족하지 못하게 됩니다.
• 주요 선택지는 RHEL 9로 업그레이드하거나, AlmaLinux나 Rocky와 같은 호환되는 배포판으로 전환하거나, 마이그레이션 시간을 확보하기 위해 연장 지원 서비스를 구매하는 것입니다.
• TuxCare의 ELS와 같은 타사 확장 지원 서비스를 이용하면, 긴급 마이그레이션 없이도 EOL 이후에도 RHEL 8에 패치를 계속 적용할 수 있으며, 리눅스 커널, OpenJDK, OpenSSL, Python 등 주요 패키지도 지원됩니다.

현재 RHEL 8을 운영 환경에서 사용 중이라면, 이미 한 가지 중요한 시점을 넘겼습니다. 2024년 5월에 정식 지원이 종료되었기 때문입니다. 이는 현재 유지보수 지원 단계에 들어섰음을 의미하며, 이 단계는 이전보다 조용하지만 지원 범위가 축소됩니다. 레드햇은 심각한 CVE에 대한 패치를 제공하지만, 플랫폼에 대한 새로운 개발 작업은 수행하지 않습니다. 다음으로 중요한 날짜는 2029년 5월 31일입니다. 이 날을 기점으로 RHEL 8은 지원 종료(EOL)에 도달하며 패치 제공이 완전히 중단됩니다.

이 글에서는 각 라이프사이클 단계가 시스템에 실제로 어떤 의미를 지니는지, 각 전환 단계에서 무엇을 포기하게 되는지, 2029년이 다가오는 것을 방치할 경우 발생할 수 있는 실질적인 위험 요소들, 그리고 예산에 반영되지 않은 대규모 전면 교체 없이도 적용 가능한 대안을 포함해 다양한 선택지를 다룹니다.

RHEL 8의 지원 종료는 무엇을 의미하나요?

레드햇(Red Hat) 환경에서 ‘지원 종료(End of Life)’는 단순한 경고나 업그레이드를 고려해 보라는 정중한 제안이 아닙니다. 이는 레드햇이 해당 메이저 버전에 대한 새로운 업데이트 제공을 완전히 중단하는 시점을 의미합니다. CVE 패치도, 버그 수정도, 지원 티켓에 대한 응답도 더 이상 제공되지 않습니다. 해당 버전은 레드햇이 공식적으로 ‘연장 지원 단계(Extended Life Phase)’라고 부르는 단계로 넘어가게 되며, 이 단계에서는 여전히 문서를 열람하고 기존 패키지를 다운로드할 수 있지만, 새로운 패키지는 더 이상 빌드되지 않습니다.

각 단계가 실제로 어떤 결과를 가져오는지 정확히 파악하는 것이 중요합니다. 그 차이가 상당하기 때문입니다:

• 전체 지원 단계: Red Hat은 보안 에라타, 긴급 및 고우선순위 버그 수정, 새로운 하드웨어 지원, 그리고 마이너 릴리스의 일부 소프트웨어 개선 사항 등 모든 내용을 제공합니다. RHEL 8은 2019년 5월부터 2024년 5월까지 이 단계에 있었습니다.
• 유지보수 지원 단계: 중요(Critical) 및 중요(Important) 등급의 보안 권고(RHSA)와 긴급 버그 수정(RHBA)만 제공됩니다. 새로운 하드웨어 지원은 제공되지 않으며, 기능 개발도 진행되지 않습니다. RHEL 8은 2029년 5월 31일까지 지원됩니다.
• 지원 기간 연장 단계: 패치 지원 측면에서 사실상 종료된 상태입니다. 문서를 읽고 기존 패키지에 접근할 수는 있지만, '확장 지원(Extended Life Cycle Support)' 추가 기능을 구매하지 않는 한 새로운 업데이트는 제공되지 않습니다.

실질적인 의미는 다음과 같습니다: 2029년 RHEL 8의 지원 종료(EOL) 시점이 되면, 개발 관점에서 볼 때 커널은 이미 10년이나 된 상태가 될 것이며, 2024년 이후로는 새로운 기능이 추가되지 않을 것입니다. 패치 적용이 중단되는 동안 위협 환경이 진화하기에는 너무 긴 시간입니다.

RHEL 8 지원 주기 일정

다음은 RHEL 8의 라이프사이클을 레드햇의 릴리스 역사상 다른 버전들과 비교한 내용입니다. 10년이라는 기간은 최신 RHEL 버전들 전반에 걸쳐 일관되게 적용되며, 달라지는 점은 현재 해당 기간 내에서 어떤 위치에 있는지입니다.

RHEL 7을 2024년 지원 종료 시한이 다가오는 압박감을 느낄 만큼 오랫동안 사용해 왔다면, RHEL 8의 2029년 지원 종료 시한은 낯설지 않을 것입니다. 마이그레이션에 대한 부담은 똑같지만, 단지 5년 뒤로 미뤄졌을 뿐이니까요. 이번의 차이점은 RHEL 9가 2022년부터 정식 출시되어 업그레이드 대상이 안정적이고 충분히 검증되었다는 점입니다. 대부분의 팀은 수년의 준비 기간을 가졌습니다. 유지보수 지원 종료 시점과 ELS( 확장 지원 ) 적용 종료 시점 사이의 간격 말입니다. 활성 유지보수 종료와 확장 지원 종료 사이의 간격은 오해하기 쉽습니다. 하지만 어떤 관점으로 보든, 마이그레이션 프로젝트에 프로젝트 관리자가 있든 없든 2029년은 어김없이 찾아옵니다.

RHEL 버전이 단종되는 이유

2029년이라는 마감일을 보고 아직 시간이 충분하다고 생각하는 이해관계자들에게 EOL 결정의 배경이 되는 비즈니스 논리를 설명할 때, 이를 이해하는 것이 도움이 됩니다.

엔지니어링 대역폭에는 한계가 있다

레드햇은 각 활성 주요 버전을 관리하기 위해 커널 유지보수 담당자, 보안 분석가, 품질 보증(QA) 파이프라인, 지원 엔지니어로 구성된 전담 팀을 운영하고 있습니다. 지원되는 버전이 하나씩 늘어날 때마다 이러한 업무 부담은 기하급수적으로 증가합니다. 어느 시점이 되면, 10년 전 코드베이스에 최신 위협에 대응하는 패치를 적용하는 데 드는 비용이 해당 버전의 구독 수익으로 충당하기에는 너무 커집니다. 결국 비용 대비 효과가 맞지 않게 되자, 레드햇은 선을 긋게 됩니다.

보안 모델은 진화하고 있다

2019년의 위협 환경은 2029년을 앞둔 현재의 위협 환경과는 전혀 다릅니다. 커널 강화 강화, 암호화 기본값 업데이트, 개선된 SELinux 정책 생성 같은 보안 강화 조치들은 최신 릴리스에 기본으로 포함되지만, 구형 커널 기반에는 종종 원활하게 역포트(backport)할 수 없습니다. 결국, 현재의 규정 준수 기준을 충족하기 위해 구버전에 패치를 적용하는 일은 아무리 많은 공력을 들이더라도 결국 손해만 보는 일이 됩니다.

Red Hat 보안 라이프사이클 개요에서 플랫폼의 진화가 취약점 관리 현황에 어떤 영향을 미치는지 자세히 알아보실 수 있습니다.

현대적인 워크로드에는 현대적인 툴체인이 필요합니다

최신 언어 런타임, 컨테이너 툴링, 클라우드 네이티브 프레임워크는 점점 더 최신 버전의 glibc, 커널, systemd를 전제로 하고 있습니다. RHEL 8은 glibc 2.28과 커널 4.18을 제공하는데, 이는 여전히 많은 워크로드에 사용할 수 있지만 eBPF, 최신 컨테이너 런타임, 또는 최근 버전의 쿠버네티스를 사용하는 경우에는 실질적인 제약이 됩니다. 규정 준수 프레임워크와 감사 도구 역시 환경을 평가할 때 최신 플랫폼 지원을 전제로 하는 경향이 있습니다.

지원 종료 후 RHEL 8을 계속 사용할 경우의 위험

패치되지 않은 CVE 빠르게 쌓입니다

레드햇이 RHEL 8에 대한 RHSA(Red Hat Security Advisory) 발행을 중단하면, 공개되는 모든 커널 수준 또는 핵심 패키지의 CVE는 시스템에 영구적인 보안 취약점으로 남게 됩니다. 업스트림에서 수정 패치가 제공되지 않을 것입니다. RHEL 7의 EOL(지원 종료) 이후 기간을 예로 들면 상황을 잘 알 수 있습니다. EOL 이후 몇 달 만에, 마이그레이션을 완료하지 않았거나 확장 지원을 구매하지 않은 시스템들은 해결책이 없는, 악용 가능한 것으로 알려진 취약점 목록이 점점 늘어나는 상황에 처하게 되었습니다. 취약점 스캐너는 이러한 취약점을 즉시 탐지하겠지만, 이에 대한 수정 패치는 제공되지 않을 것입니다. 귀사의 팀보다 감사 담당자가 먼저 이를 발견하게 될 것입니다.

TuxCare의 ‘2025년 엔터프라이즈 리눅스 및 오픈소스 현황 보고서’에 따르면, 설문조사에 참여한 조직의 40%가 지난 12개월 동안 사이버 보안 사고를 겪었으며, 이 중 60%는 적용되지 않은 보안 패치와 관련이 있는 것으로 나타났습니다.

규정 준수 인증에 불합격 사례가 나타나기 시작하다

PCI DSS, HIPAA, SOC 2 Type II, ISO 27001, FedRAMP – 이 모든 규정은 적시에 보안 패치를 적용받는 소프트웨어를 운영할 것을 요구합니다. RHEL 8이 연장 지원 계약 없이 EOL(제품 수명 주기 종료)에 도달하는 순간, 기술적으로 규정 미준수 상태가 됩니다. 이는 단순한 이론상의 문제가 아닙니다. 지원이 종료된 OS 버전을 포함하고 있는 상태에서 SOC 2 보고서를 갱신하려는 40명 규모의 SaaS 기업은, 감사관이 실제 패치 적용을 대체할 적절한 조치로 인정하지 않는 보완 통제 방안을 작성하는 데 많은 시간을 소비하게 될 것입니다.

전체 스택에 대한 공급업체의 지원이 점차 약화되고 있습니다

ISV(독립 소프트웨어 공급업체) – 데이터베이스 공급업체, 미들웨어 공급업체, 보안 도구 제공업체 등 – 는 자사의 지원 정책을 해당 운영 체제의 수명 주기에 연동합니다. RHEL 8이 레드햇의 지원 대상 목록에서 제외되면, 이들 공급업체 중 상당수도 이에 발맞춰 조치를 취할 것입니다. 지원이 종료된 운영 체제에서 구동되는 오라클 DB나 SAP 인스턴스에서 운영 중 문제가 발생했을 때, 비로소 지원 계약이 더 이상 유효하지 않다는 사실을 깨닫게 된다면 이는 특히나 곤란한 상황이 될 것입니다.

사이버 보험은 점점 더 복잡해지고 있다

보험사들은 이 문제에 대해 더욱 세심하게 대응하고 있습니다. 현재 사이버 보험 가입 신청서에는 고객사의 환경에 EOL(지원 종료) 소프트웨어가 있는지 여부에 대한 질문이 일상적으로 포함되어 있으며, 보험 약관에는 알려진 패치되지 않은 취약점으로 인해 발생한 침해 사고에 대한 보험금 청구를 무효로 하는 조항이 점점 더 많이 포함되고 있습니다. EOL 상태임을 알면서도 구형 소프트웨어를 계속 사용하는 것은 명백한 책임 위험 요인으로, 보험사들은 이에 따라 보험료를 책정하거나 가입을 거절하기 시작했습니다.

기다릴수록 업그레이드가 더 어려워집니다

이 문제는 충분히 주목받지 못하고 있습니다. EOL(지원 종료) 이후에도 RHEL 8을 계속 사용할수록, 향후 마이그레이션 비용은 점점 더 늘어납니다. 신입 직원들은 노후화된 도구에 익숙하지 않습니다. 구성 관리는 문서화되거나 테스트 가능한 상태에서 점점 벗어나게 됩니다. 새로운 NIC나 스토리지 컨트롤러 펌웨어가 RHEL 8에 대한 공식 인증을 받지 못한 경우, 하드웨어 교체 시 드라이버 호환성 문제에 부딪히게 됩니다. 결과적으로 시스템은 인력 확보, 운영, 마이그레이션이 동시에 더 어려워집니다.

RHEL 8 지원 종료 후의 대안

올바른 선택은 업그레이드에 수반되는 애플리케이션 계층 작업의 규모, 허용 가능한 가동 중단 시간, 그리고 현재 팀에 마이그레이션 프로젝트를 주도할 인력이 충분한지에 따라 달라집니다. 정답은 없지만, 현실적인 대안들은 분명히 존재합니다.

옵션 1: TuxCare의 무한 라이프사이클 지원(ELS)

2029년 5월까지 원활한 마이그레이션이 확실하지 않다면, TuxCare의 Endless Lifecycle Support(ELS) 에 대해 알아볼 필요가 있습니다. TuxCare는 이미 RHEL 7에 대해 ELS를 제공하며, Red Hat의 유지보수 지원이 종료된 후에도 지속적인 취약점 패치를 제공하고 있습니다. RHEL 8이 EOL(제품 수명 주기 종료)에 도달하면 동일한 지원 범위가 RHEL 8로 확대될 것으로 예상됩니다. 이 서비스는 Red Hat 구독 모델과 독립적이므로, 마이그레이션 프로젝트를 무리하게 서두르지 않고 합리적인 속도로 진행하는 동안에도 중요한 RHEL 8 워크로드를 최신 패치로 유지하고 감사 대비를 완료할 수 있습니다.

TuxCare의 RHEL ELS가 패키지 수준에서 정확히 어떤 내용을 포함하는지 알아두면 좋습니다. OS 수준의 ELS는 커널뿐만 아니라 OpenJDK, Python, httpd, OpenSSL, OpenSSH와 같은 자주 사용되는 패키지도 포함하므로, 스택의 핵심 구성 요소들이 동일한 구독으로 지원됩니다.

옵션 2: Leapp을 사용한 RHEL 9 현장 업그레이드

레드햇의 Leapp 유틸리티는 RHEL 8에서 RHEL 9로의 인플레이스 업그레이드를 처리하며, 깨끗하고 잘 관리된 시스템에서는 원활하게 작동합니다. 하지만 2019년부터 가동되어 온 시스템의 경우, 누적된 사용자 지정 설정, 타사 저장소, 그리고 아무도 제대로 문서화하지 않은 커널 모듈 등이 존재하기 때문에 그다지 원활하지 않습니다.

올바른 방법은 다음을 실행하는 것입니다 leapp preupgrade 첫째, 어떤 결정을 내리기 전에 잠재적인 걸림돌을 미리 파악해 줍니다. 발견된 걸림돌을 해결하는 데 필요한 시간을 충분히 확보해 두세요. 분명 몇 가지 문제가 있을 테니까요.

전문가 팁: leapp upgrade를 실행하기 전에 다음을 확인하십시오. /var/log/leapp/leapp-report.txt ~ 이후 leapp preupgrade – 단순히 “억제 요소”만 샅샅이 찾아보지 마세요. 억제 요소는 아니지만 심각도가 “높음”으로 분류된 항목들도, 특히 타사 커널 모듈이나 사용자 정의 PAM 구성과 관련해서는 업그레이드 후에도 문제를 일으킬 수 있습니다. 커밋하기 전에 이러한 문제들을 먼저 해결하세요.

옵션 3: RHEL 9 또는 RHEL 10에서 완전히 새로 재설치

컨테이너에 적합하거나 인프라-어-코드(Infrastructure-as-Code) 방식으로 관리되는 워크로드의 경우, 현장 업그레이드보다 병행 재구축이 더 깔끔한 경우가 많습니다. 이를 통해 새로운 기준점을 확보할 수 있을 뿐만 아니라, 업그레이드 잔여물을 남기지 않고, 2019년부터 누적되어 온 기술적 부채를 해소할 수 있는 자연스러운 기회를 얻을 수 있습니다. 호스트당 처리 속도는 느릴 수 있지만, 대규모 환경에서는 더 안정적입니다.

옵션 4: RHEL 호환 배포판으로 전환하기

AlmaLinux, Rocky Linux 및 Oracle Linux는 동일한 패키지를 실행하며 대부분의 워크로드에 대해 인증을 받은 바이너리 호환 대안입니다. AlmaLinux와 Rocky는 무료이며, Oracle은 유료 지원 서비스를 제공합니다. 이 방법은 사용 중인 툴링에서 OS를 범용 제품으로 취급하고, Red Hat 전용 지원 계약이 필요하지 않은 경우에 적합합니다. 도입을 결정하기 전에 ISV 인증 여부를 반드시 확인하십시오. 모든 벤더가 이러한 대안을 공식적으로 지원하는 것은 아니며, 일부는 RHEL을 반드시 사용해야 한다고 명시하고 있습니다.

옵션 5: 레드햇의 자체 ELS 애드온

레드햇은 2029년 5월 지원 종료 시점을 넘어 2032년 5월까지 제한된 보안 지원 범위를 연장해 주는 ‘확장 수명 주기 지원(Extended Life Cycle Support)’ 부가 서비스를 제공합니다. 레드햇 생태계 내에서 계속 운영해야 하고 이에 대한 예산이 확보되어 있다면, 이 서비스가 가장 확실한 선택지입니다. 지원 범위는 유지보수 지원(Maintenance Support)보다 상당히 좁습니다(지원되는 패키지 수가 적고, 심각도가 가장 높은 CVE만 포함됨). 따라서 이 서비스는 업그레이드를 대체할 장기적인 대안이 아니라, 당분간 버틸 수 있는 가교 역할에 불과합니다.

선택 방법:

• 앱이 이미 RHEL 9에서 인증을 받았고 엔지니어링 인력이 충분하다면, 그냥 Leapp을 사용해 작업을 완료하세요. 이는 대부분의 단순한 환경에 있어 가장 적절한 해결책입니다.
• 오라클 DB, SAP, RHEL 9에서 아직 인증되지 않은 구형 미들웨어 등 특정 공급업체에 종속된 시스템을 운영 중이라면, 일정에 대해 초기에 현실적인 전망을 세우는 것이 좋습니다. 엔터프라이즈 소프트웨어의 인증 주기는 빠르게 진행되지 않으며, 서류상으로는 간단해 보이는 마이그레이션도 벤더 승인, 테스트, 변경 승인 절차를 고려하면 예상보다 시간이 더 소요되는 경우가 많습니다. 라이프사이클 지원 기간 연장은 바로 이러한 상황을 위해 마련된 것입니다. 이를 통해 압박감 속에서 서두르지 않고 제대로 작업을 수행할 수 있는 여유를 확보할 수 있습니다.
• 비용에 민감하고 레드햇(Red Hat) 지원 계약이 필요하지 않다면, AlmaLinux나 Rocky가 정말 좋은 선택지입니다. 결코 타협이 아닙니다. 이 배포판들은 탄탄한 커뮤니티와 상업적 지원을 바탕으로 한 신뢰할 수 있는 배포판입니다.

사전 계획: 현실적인 일정

지원 종료(EOL) 시한은 막상 다가오기 전까지는 꽤 먼 일처럼 느껴집니다. 2024년 초에 RHEL 7 마이그레이션을 시작한 팀들은 대부분 2024년 6월 마감 기한을 지키지 못했습니다. 마이그레이션 프로젝트는 거의 항상 초기 예상보다 더 오래 걸리는데, 특히 타사 애플리케이션 인증이 필요한 경우에는 더욱 그렇습니다.

마감일을 지키는 팀들은 마이그레이션을 본격적인 프로젝트처럼 다룹니다. 프로젝트 매니저를 두고, 백로그를 관리하며, 2주마다 ISV 인증 상태를 확인하는 전담 인력을 배치하죠. 반면 마감일을 놓치는 팀들은 이 작업을 “시간 날 때” 처리하라고 선임 엔지니어에게 떠넘기는 팀들입니다. 그 엔지니어에게는 시간이 없습니다. 그들에게는 절대 시간이 없습니다. 그러다 어느새 2029년 3월이 되고, 누군가는 마치 속보라도 접한 듯 레드햇(Red Hat)의 EOL(지원 종료) 공지를 처음 접하게 됩니다.

RHEL 8에 적용할 수 있는 실용적인 접근 방식은 대략 다음과 같습니다:

• 24개월 이상 남은 경우: 모든 RHEL 8 호스트, 애플리케이션 및 ISV 종속성을 파악하십시오. 어떤 애플리케이션이 이미 RHEL 9에서 인증되었는지, 그리고 어떤 애플리케이션이 전환을 가로막는 장애 요인인지 확인하십시오.
• 18개월 후: RHEL 9(또는 선택한 대체 OS)를 비생산 환경의 워크로드에서 시범 운영해 보세요. 실행 leapp preupgrade 대표적인 시스템에 대해 조사하고 그 제약 요인을 기록한다.
• 12개월 전: 위험도가 가장 낮은 워크로드부터 시작하여 단계적으로 생산 환경 마이그레이션을 진행합니다. 확장 지원이 제공되는 RHEL 8을 계속 사용할 시스템을 결정하고 이에 따라 예산을 책정합니다.
• 6개월 전: 아직 미결인 연장 지원 계약을 최종 확정하십시오. 감사인과 준수 관련 문서를 확인하여 예상치 못한 문제가 발생하지 않도록 하십시오.
• 지원 종료 전(Pre-EOL): 모든 시스템은 마이그레이션되었거나 연장 지원 대상입니다. 패치되지 않은 상태로 운영되는 시스템은 없습니다.

관리해야 할 호스트가 몇 대를 넘어선다면, 단순한 업그레이드 작업조차 수 분기에 걸친 작업으로 변모시키는 운영상의 복잡성에 직면하게 될 가능성이 매우 높습니다. 프로젝트를 조기에 주도적으로 관리할수록, 그러한 복잡성이 업무에 미치는 차질은 최소화됩니다.

TuxCare의 ELS로 보안을 유지하세요

대부분의 RHEL 8 운영 환경에서는 대개 다음과 같은 상황이 발생합니다. 예정대로 마이그레이션을 시작했지만, 아직 RHEL 9 인증을 받지 못한 벤더 종속 애플리케이션에 부딪히게 되고, 결국 당초 계획보다 더 긴 준비 기간이 필요하게 되는 것입니다. 바로 이때부터 보안 지원 기간 연장은 더 이상 선택 사항이 아닙니다.

TuxCare는 2029년 5월 RHEL 8의 지원 종료일 이후에도 CentOS, RHEL 7 및 기타 다양한 지원 종료된 리눅스 배포판을 지원해 온 경험을 바탕으로, 고객의 시스템이 취약점에 대비해 지속적으로 패치되도록 관리합니다. 이를 통해 고객은 운영 환경에서 패치가 적용되지 않은 상태로 시스템을 가동할 염려 없이, 또한 막판에 당황하여 Red Hat 연장 구독을 서둘러 구매할 필요 없이, 충분한 시간을 두고 체계적으로 마이그레이션을 진행할 수 있습니다.

재부팅이 번거로운 환경에서는 KernelCare를 별도로 검토해 볼 가치가 있습니다. 이 제품은 시스템 가동 중단 없이 실행 중인 커널에 패치를 적용합니다. ELS와는 별개의 제품으로 별도로 구매해야 하지만, 두 제품을 함께 사용할 수 있습니다.

요약

기사 이름

RHEL 8 지원 종료: 일정, 위험 요소 및 향후 조치

설명

RHEL 8의 지원 종료 시기와 지원이 종료된 시스템을 계속 사용할 경우의 위험성, 그리고 지원 종료 후에도 보안과 규정 준수를 유지할 수 있는 최선의 방안을 알아보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고