RHEL 7.8에 ELS가 적용될까?

 

취약점 점검이나 EOS 현황 조사를 하다 보면 이런 답변을 자주 듣습니다.

"그 서버 ELS 걸려 있어요. 2029년까지 지원됩니다."

계약서를 확인해보면 실제로 맞습니다. ELS 구독은 유효하고, 만료일도 2029년입니다. 그런데 서버에 들어가서 rpm -qa --last를 찍어보면 마지막 패치가 몇 년 전입니다. 계약은 살아 있는데 패치는 없는, 이상한 상태입니다.

원인은 대부분 하나입니다. 서버가 7.9가 아니기 때문입니다.

 

이 글에서는 RHEL 7 ELS의 적용 조건이 무엇인지, 왜 7.8에는 패치가 오지 않는지, 그리고 우리 서버가 실제로 패치를 받고 있는지 확인하는 방법을 정리했습니다.

---

🎯 먼저 용어부터 정리합니다

현장에서 가장 많이 꼬이는 지점이 용어입니다. 벤더마다 이름이 달라서 대화가 어긋납니다.

용어	어느 제품	의미
ESU (Extended Security Updates)	Microsoft	Windows Server 등의 연장 보안 업데이트
ESM (Expanded Security Maintenance)	Ubuntu	Ubuntu Pro의 연장 유지보수
LTS (Long Term Support)	Ubuntu 등	장기 지원 릴리스. RHEL에는 없는 개념
EUS (Extended Update Support)	Red Hat	특정 마이너 버전의 지원 기간 연장
ELS (Extended Life-cycle Support)	Red Hat	메이저 버전의 표준 라이프사이클 종료 후 연장
ELC (Extended Life Cycle)	Red Hat	RHEL 9부터 EUS·E4S 등을 통합한 신규 모델

RHEL에는 LTS도 ESU도 없습니다. "RHEL LTS 지원 중"이라는 표현이 나오면 실제로 무엇을 구독했는지부터 확인해야 합니다.

그리고 EUS와 ELS는 성격이 정반대입니다.

 

구분	EUS	ELS
연장 대상	마이너 버전 (예: 8.4)	메이저 버전 (예: 7)
시점	표준 라이프사이클 안	표준 라이프사이클 종료 후
EoS로 봐야 하나	아니오	표준 지원은 종료된 상태가 맞음

이 구분이 왜 중요하냐면, 점검 보고서에 "지원 종료 여부"를 적을 때 결론이 달라지기 때문입니다.

---

🧩 RHEL 7은 지금 어느 구간에 있나

RHEL은 10년 라이프사이클을 Full Support → Maintenance Support → Extended Life Phase(ELP) 세 단계로 나눕니다.

 

RHEL 7은 2024년 6월 30일에 Maintenance Support가 끝나고 Extended Life Phase로 넘어갔습니다. 그리고 이 ELP 구간에서 Red Hat은 버그 수정, 보안 수정, 하드웨어 활성화, 근본 원인 분석을 제공하지 않습니다. 기존 설치 건에 대한 제한적 기술 지원만 남습니다. 즉 ELS 애드온이 없으면 2024년 7월 1일부터 이미 보안 패치가 끊긴 상태입니다.

 

ELS를 구매하면 이 구간에서 패치를 계속 받을 수 있습니다. Red Hat Customer Portal FAQ 기준으로 RHEL 7 ELS는 2024년 7월 1일부터 2029년 5월 31일까지 제공됩니다.

💡 검색하면 "2028년 6월 30일"로 적힌 자료가 꽤 나옵니다. 2024년 최초 공지가 "4년"이었고 일부 파트너·클라우드 문서가 그 시점에 작성됐기 때문입니다. 현재 Red Hat 공식 문서 기준은 2029년 5월 31일입니다. 보고서에 날짜를 쓸 때는 Red Hat Customer Portal을 직접 확인하세요.

---

🔍 핵심 — ELS는 7.9 전용입니다

여기가 이 글의 전부라고 해도 됩니다. Red Hat FAQ는 이렇게 명시합니다.

 

ELS는 마지막 마이너 릴리스에서만 지원됩니다. 이 경우에는 RHEL 7.9입니다.

 

Red Hat 블로그도 같은 내용을 반복합니다. ELS 혜택을 받으려면 조직은 RHEL 7.9에 있어야 한다고 못박고 있고, AWS 마켓플레이스의 RHEL 7 ELS 상품 설명에도 RHEL VM은 7.9여야 ELS를 사용할 수 있다고 조건이 걸려 있습니다.

정리하면 이렇습니다.

현재 버전	ELS 구독	실제 패치 수신	판정
7.9	있음 + repo 활성화	✅ 수신	연장 지원 중
7.9	있음 + repo 미활성화	❌ 미수신	돈만 내는 상태
7.8 이하	있음	❌ 미수신	적용 대상 아님 · 실질 EoS
7.9	없음	❌ 미수신	EoS

 

7.8은 세 번째 줄입니다. 구독은 유효하지만 적용 대상이 아닙니다.

---

⚠️ 왜 7.8에는 패치가 오지 않나요

"7.8도 패치는 나오는데 7.9만 케이스 오픈이 되는 것 아니냐"는 이야기를 자주 듣습니다. 절반만 맞습니다.

RHEL은 마이너 버전별로 패치를 따로 내주지 않습니다. Maintenance Support 이후로는 마지막 마이너 릴리스 하나에만 에라타가 나갑니다. rhel-7-server-rpms 리포지토리는 항상 그 최신 마이너를 바라봅니다.

 

 

그래서 결론이 조금 이상하게 들립니다.

7.8은 "패치가 안 나오는" 게 아니라, 패치를 적용하면 7.9가 됩니다.

yum update를 돌리는 순간 7.9로 올라갑니다. 지금 7.8에 머물러 있다는 건 그동안 패치를 적용하지 않았거나, 뒤에서 설명할 버전 고정(release lock) 이 걸려 있다는 뜻입니다.

 

7.8을 유지한 채 패치만 받는 경로는 없습니다. 7.8 전용 리포지토리도 존재하지 않습니다.

⚠️ EUS와 헷갈리기 쉬운 부분입니다. EUS는 특정 마이너 버전을 고정한 채 그 버전용 에라타를 따로 받는 구조가 맞습니다. 하지만 RHEL 7.8은 EUS 대상 릴리스가 아니었고, ELS는 애초에 마지막 마이너 전용입니다. 구조가 다릅니다.

---

📋 우리 서버 상태 확인하기

계약서가 아니라 서버에서 확인해야 합니다.

 

1. 현재 마이너 버전

cat /etc/redhat-release
# Red Hat Enterprise Linux Server release 7.8 (Maipo)   ← 7.9가 아니면 여기서 끝

2. 버전 고정 여부 (가장 흔한 원인)

subscription-manager release --show
# Release: 7.8

여기에 7.8이 찍혀 있다면 원인을 찾은 겁니다. 과거에 호환성 문제로 --set=7.8을 걸어두고 그대로 잊힌 경우가 대부분입니다. 이 상태에서는 yum update를 아무리 돌려도 7.9로 올라가지 않습니다.

3. ELS 애드온 보유 여부

subscription-manager list --consumed

출력에서 Extended Life Cycle Support 관련 항목과 만료일(End Date)을 확인합니다.

4. ELS 리포지토리 활성화 여부

subscription-manager repos --list-enabled | grep -i els

아무것도 안 나오면 구독만 있고 패치 경로는 열려 있지 않은 상태입니다. Satellite로 관리되는 환경이라면 Content View에 ELS 리포지토리가 포함되어 있는지도 같이 봐야 합니다.

5. 실제 마지막 패치 시점

rpm -qa --last | head -20

가장 강력한 증적입니다. 여기 찍힌 날짜가 2020년이면, 계약이 무엇이든 그 서버는 5~6년간 패치를 받지 않은 겁니다.

# ELS 패키지가 하나라도 들어와 있는지
rpm -qa | grep el7_9 | wc -l

---

체크리스트

확인 항목
/etc/redhat-release가 7.9인가	☐
subscription-manager release --show에 버전 고정이 걸려 있지 않은가	☐
ELS 애드온이 실제로 consumed 되어 있는가	☐
ELS 리포지토리가 활성화되어 있는가	☐
최근 패치 적용 이력이 ELS 시작(2024.07) 이후에 있는가	☐
Self-support가 아닌 Standard 또는 Premium 구독인가	☐
아키텍처가 x86_64 또는 s390x인가	☐
ELS 만료일(2029.05.31) 이전에 마이그레이션 계획이 잡혀 있는가	☐

 

마지막 두 항목도 놓치기 쉽습니다. ELS 애드온은 Standard·Premium 구독에만 붙일 수 있고 Self-support에는 적용되지 않습니다. 커버 아키텍처도 x86 64비트와 IBM Z(s390x)로 제한됩니다.

---

🛠 조치 순서

순서	내용	비고
1	버전 고정 해제	subscription-manager release --unset
2	7.9로 마이너 업데이트	yum clean all && yum update 후 재부팅
3	ELS 리포지토리 활성화	subscription-manager repos --enable=rhel-7-server-els-rpms
4	누적 CVE 일괄 패치	수년치가 한 번에 들어오므로 검증 범위가 큼
5	전환 전까지 보완통제	망분리·접근통제·IPS 시그니처·불필요 서비스 차단
6	마이그레이션 계획 수립	ELS는 다리일 뿐, 2029.05.31 이후는 방법 없음

 

리포지토리 ID는 환경에 따라 다를 수 있으니 subscription-manager repos --list | grep els로 먼저 확인하세요.

2번이 가장 부담스러운 단계입니다. 7.8에서 7.9는 마이너 업데이트라 메이저 업그레이드보다는 낫지만, 몇 년치 패키지가 한 번에 올라가기 때문에 개발 환경에서 먼저 돌려보고 애플리케이션 회귀 테스트를 거치는 게 안전합니다.

---

🚫 이런 판단은 하지 마세요

① 계약서만 보고 "지원 중"으로 보고하기

ELS 구독 목록만 뽑아서 현황표를 채우면 7.8 서버가 전부 "지원 중"으로 들어갑니다. 감사나 심사에서 서버 한 대만 열어봐도 바로 뒤집힙니다. 구독 현황과 서버 실제 버전을 조인해서 봐야 합니다.

② 스캐너 결과만으로 판단하기

Nessus 같은 스캐너의 Unsupported OS 계열 플러그인은 대개 표준 EoL 날짜를 기준으로 뜹니다. ELS 구독 여부까지 보지 않기 때문에, 7.9 + ELS 정상 서버에서도 결함이 올라올 수 있습니다. 반대로 스캐너가 조용하다고 해서 패치를 받고 있다는 뜻도 아닙니다. 양방향으로 다 틀릴 수 있습니다.

③ ELS 적용했으니 끝났다고 생각하기

ELS의 수정 범위는 RHSA로 정의된 CVSS 7 이상의 Critical·Important·Moderate CVE와 Red Hat이 선별한 긴급 버그 수정으로 한정됩니다. 그 아래 등급은 영구 미수정으로 남습니다. 취약점 점검에서 조치 불가 항목이 계속 나올 수밖에 없는 구조이니, 위험 수용 근거를 미리 정리해두는 편이 낫습니다.

④ CentOS 7과 같은 선상에 놓기

CentOS 7은 2024년 6월 30일에 완전히 EOL 됐고 ELS 같은 연장 옵션 자체가 없습니다. RHEL 7과 묶어서 "둘 다 ELS 검토"로 적으면 안 됩니다. CentOS 7은 마이그레이션 외에 선택지가 없습니다.

---

📝 보고서·소명 문구 예시

"EoL 여부: 예/아니오" 단답으로 쓰면 반드시 다툼이 생깁니다. 상태를 그대로 서술하는 편이 깔끔합니다.

 

7.8인 경우

대상 서버 OS: Red Hat Enterprise Linux 7.8
ELS 구독: 보유 (만료 2029-05-31)
적용 여부: 미적용 — ELS는 최종 마이너 릴리스(7.9) 전용이므로
           7.8은 패치 공급 대상에 해당하지 않음
실제 상태: 최종 패치 적용일 YYYY-MM-DD, 이후 보안 패치 미수신
판정: 벤더 지원 종료(EoS)에 준함
조치 계획: ① 7.9 마이너 업데이트 → ② ELS 리포지토리 활성화
           → ③ 누적 CVE 패치 (목표일 YYYY-MM-DD)
잔여 위험 통제: 전환 완료 전까지 망분리 및 접근통제 유지

 

7.9 + ELS 정상 적용인 경우

대상 서버 OS: Red Hat Enterprise Linux 7.9
ELS 구독: 보유 (만료 2029-05-31), rhel-7-server-els-rpms 활성화 확인
판정: 표준 라이프사이클은 종료되었으나 벤더 연장 지원으로 보안 패치 공급 중
제약: 수정 범위가 CVSS 7 이상 CVE로 한정되어 일부 항목은 조치 불가
마이그레이션: RHEL 9 전환 계획 수립, ELS 만료 이전 완료 목표
증적: 구독 화면 캡처, repos --list-enabled 출력, rpm -qa --last 출력

---

💬 자주 나오는 질문

Q. 담당자가 "7.8도 패치는 다 되고, 7.9만 케이스 오픈 서비스가 추가되는 것"이라고 하는데요?

케이스 오픈만 7.9 전용인 게 아닙니다. 패치 자체가 7.9 대상입니다. Red Hat FAQ의 "ELS is only supported on the last minor release. In this case, RHEL 7.9" 문장을 그대로 보여주는 게 가장 빠릅니다.

 

가장 확실한 방법은 테스트 서버에서 실증하는 것입니다. 버전 고정을 풀고 yum update를 돌린 뒤 cat /etc/redhat-release를 찍어보면 7.9로 바뀝니다. 7.8을 유지하면서 패치를 받는 경로가 없다는 게 눈으로 확인됩니다.

그래도 이견이 남으면 Red Hat에 케이스를 열어 "7.8 시스템이 ELS 적용 대상인지" 서면 회신을 받아두세요. 점검 보고서 근거 자료가 됩니다.

Q. 패치를 적용하면 7.8이 아니게 되는데, 버전 고정은 왜 쓰는 건가요?

Full Support 구간에서 마이너 릴리스가 6개월마다 나올 때, 애플리케이션 호환성 때문에 특정 마이너에 머무르려고 쓰는 기능입니다. 문제는 그 락을 걸어둔 사람이 퇴사하거나 인수인계가 끊기면 그대로 남는다는 겁니다.

라이프사이클 점검 시 release --show를 필수 확인 항목으로 넣어두시길 권합니다.

Q. 7.8에서 7.9로 올리면 서비스에 영향이 있나요?

마이너 업데이트라 메이저 업그레이드보다는 위험이 낮지만, 수년치 패키지가 한 번에 올라가므로 무시할 수준은 아닙니다. 커널·glibc·openssl이 모두 바뀝니다. 개발 환경 선적용, 스냅샷 확보, 롤백 절차 준비를 권합니다.

Q. ELS가 적용되어 있으면 취약점 점검에서 양호인가요?

"OS 지원 종료" 항목은 소명 가능합니다. 다만 개별 CVE 항목은 별개입니다. ELS 범위 밖 등급은 수정 패키지가 나오지 않으므로 조치 불가로 남고, 이건 위험 수용 또는 보완통제로 처리해야 합니다.

Q. ELS 종료일이 자료마다 다르던데요?

2024년 최초 공지가 "4년"이었고 당시 문서들이 2028년 6월 30일로 적었습니다. 현재 Red Hat Customer Portal 기준은 2029년 5월 31일입니다. 3자 문서(클라우드 벤더, 하드웨어 벤더 등)는 갱신이 늦을 수 있으니 날짜는 항상 Red Hat 원문에서 확인하세요.

Q. 클라우드에서 돌리는 RHEL 7도 ELS가 되나요?

AWS와 Azure 마켓플레이스에 RHEL 7 ELS 상품이 올라와 있습니다. 다만 7.9여야 한다는 조건은 동일하고, 별도 구독과 메터링 설정이 필요합니다.

---

🎉 정리

1. ELS는 마지막 마이너 릴리스(7.9) 전용이다. 7.8 이하는 구독이 있어도 적용 대상이 아니다.
2. 7.8은 패치가 안 나오는 게 아니라, 패치를 적용하면 7.9가 된다. 7.8을 유지한 채 패치받는 경로는 없다.
3. 7.8에 머물러 있는 진짜 원인은 대개 subscription-manager release --set 이다. 점검 항목에 넣어두자.
4. 계약서가 아니라 서버에서 확인한다. release --show, repos --list-enabled, rpm -qa --last 세 개면 판정이 끝난다.
5. 구독 보유와 패치 수신은 다르다. repo가 안 열려 있으면 돈만 내는 상태다.
6. ELS를 적용해도 CVSS 7 이상으로 범위가 한정된다. 나머지는 보완통제 영역이다.
7. ELS는 다리일 뿐이다. 2029년 5월 31일 이후는 방법이 없다. 그 전에 RHEL 9 또는 10으로 넘어가야 한다.

"지원 종료입니까?"라는 질문에 날짜만 보고 답하면 절반은 틀립니다. 같은 RHEL 7이라도 7.9 + ELS 활성화 서버와 7.8 방치 서버는 보안 상태가 완전히 다릅니다. 버전과 리포지토리까지 확인해야 그 서버의 실제 상태를 말할 수 있습니다.

---

🔗 참고 자료

• FAQ: Red Hat Enterprise Linux 7 reaches End of Maintenance Phase and transitions to Extended Life Phase — ELS 적용 조건, 제공 기간, 수정 범위
• Red Hat Enterprise Linux Life Cycle — 라이프사이클 단계 정의 및 ELC 신규 모델
• Announcing up to 4 years of Extended Life Cycle Support for RHEL 7 — 7.9 요건 및 수정 범위 확대
• What to know for Red Hat Enterprise Linux 7 End of Maintenance — EOM과 EOL의 차이
• RHEL 7 ELS on AWS Marketplace — 클라우드 환경 적용 조건