서버 지원 종료(EoS) 점검, 교체 계획만으로는 양호가 아닌 이유

📌 3줄 요약

1. SRV-179는 보안 패치가 더 이상 나오지 않는(EoS) OS·장비를 쓰고 있는지 보는 위험도 4.0 항목입니다.

2. 교체 계획을 세우고 보고해도 판정은 취약이고, 위험수용으로 관리하게 됩니다. 계획서가 양호를 만들어 주지 않습니다.

3. 2026년 10월 13일 Windows Server 2012·2012 R2의 유료 연장 보안 업데이트(ESU)가 최종 종료됐습니다. 지금 가진 서버의 버전과 지원 종료일을 대장으로 정리하는 것부터 시작하세요.

1편에서 패치 관리 절차를 아무리 잘 만들어도 통하지 않는 서버가 있다고 했습니다. 벤더가 더 이상 패치를 만들지 않는 서버입니다. 혹시 "아직 잘 돌아가니까"라는 이유로 몇 년째 그대로 둔 서버가 있지 않나요?

마침 일주일 전인 2026년 10월 13일, Microsoft 수명주기에서 큰 날짜 두 개가 겹쳤습니다. Windows Server 2012·2012 R2의 마지막 보안 업데이트가 나왔고, Windows Server 2022는 메인스트림 지원을 마쳤습니다. 둘 중 하나만 진짜 EoS입니다. 어느 쪽일까요?

---

🧭 SRV-179는 무엇을 보는 항목인가

SRV-179는 금융보안원 전자금융기반시설 보안 취약점 평가기준(제2026-1호)의 서버 분야 패치 관리 항목으로, 위험도는 4.0입니다. 서비스 지원이 끝난 버전의 시스템이나 장비를 쓰고 있는지를 점검하며, 판정 기준은 "지원 가능한 시스템을 쓰는가, 지원이 끝난 시스템을 별도 사후 관리 없이 쓰는가"입니다. 1편과 마찬가지로 네트워크에 연결되지 않은 오프라인 서버는 별도 내부 기준으로 관리하도록 예외를 두고 있습니다.

여기서 말하는 "지원"은 기술 지원 창구가 아니라 보안 패치입니다. 벤더마다 단계 이름은 다르지만, 결국 보안 패치가 나오는 구간과 끊긴 구간으로 나뉩니다.

주요 서버 OS의 지원 종료일은 아래와 같습니다. 날짜는 바뀔 수 있으니 실제 판단 전에는 각 벤더의 수명주기 페이지에서 다시 확인하세요.

OS	기본 보안 패치 종료	유료 연장 지원	현재 상태 (2026.10 기준)
Server 2012·R2	2023.10.10	ESU 2026.10.13 최종 종료	완전 종료
Server 2016	2027.01.12	—	약 3개월 남음
Server 2019	2029.01.09	—	연장 지원 중
Server 2022	2031.10.14	—	2026.10.13 메인스트림 종료, 연장 지원 중
RHEL 7	2024.06.30	ELS (7.9 대상)	ELS 없으면 종료
RHEL 8	2029.05.31	8.10 대상 연장 제공 예정	유지보수 단계
Ubuntu 20.04	2025.05.31	ESM(Ubuntu Pro) 2030.05	ESM 없으면 종료
Ubuntu 22.04	2027.05	ESM(Ubuntu Pro) 2032.05	표준 지원 중

도입부 질문의 답이 여기 있습니다. Windows Server 2022는 메인스트림만 끝났을 뿐 보안 업데이트는 2031년까지 나옵니다. 진짜 EoS는 Windows Server 2012·2012 R2입니다.

---

⚠️ EoS 서버가 위험한 이유

지원이 끝난 날부터 그 OS에서 새로 발견되는 취약점은 영원히 고쳐지지 않습니다. 더 나쁜 점은, 지원 중인 다음 버전에 패치가 나오면 그 패치를 분석해 옛 버전의 같은 약점을 찾아내는 일이 쉬워진다는 것입니다. 시간이 갈수록 공격자에게 유리해지는 구조입니다.

그래서 2026년 평가기준 개정에서도 패치 지원이 끝난 시스템의 위험관리 기준이 강화됐습니다. 이제 EoS 서버는 "언젠가 바꿀 서버"가 아니라 관리 근거를 요구받는 위험으로 다뤄집니다.

---

💡 EoS 판단에서 흔한 착각 5가지

착각	흔한 생각	실제
메인스트림	메인스트림 지원이 끝나면 EoS다	Microsoft는 연장 지원 기간에도 보안 업데이트를 준다. EoS는 연장 지원까지 끝난 시점이다
메이저 버전	RHEL 9이면 다 지원된다	Red Hat의 패치는 현재 활성화된 마이너 릴리스 기준이다. 오래된 마이너 버전에 멈춰 있으면 별도 연장 상품 없이는 패치를 못 받을 수 있다
OS만 확인	OS 버전만 보면 된다	항목 이름이 "시스템 및 장비"다. DB, WAS, 실행 환경, 네트워크 장비 펌웨어도 각자 지원 종료일이 있다
교체 계획	교체 계획을 보고하면 양호다	계획을 세우고 보고해도 판정은 취약이다. 대신 위험수용으로 관리된다
연장 지원	돈을 내면 계속 연장할 수 있다	유료 연장에도 끝이 있다. Windows Server 2012의 ESU는 3년차가 마지막이었고, 4년차는 없다

네 번째 착각이 이 항목의 가장 큰 반전입니다. 많은 조직이 "교체 예산을 내년에 잡았으니 올해는 넘어가자"는 식으로 대응하는데, 평가기준은 이것을 양호로 보지 않습니다. 계획과 보고는 취약을 관리하는 방법이지, 취약을 없애는 방법이 아닙니다.

반대로 연장 지원은 의미가 있습니다. 평가기준도 버전만 보지 않고 ESU 같은 연장 지원으로 실제로 보안 업데이트를 받고 있는지를 함께 확인하도록 하고 있습니다. 다만 연장 지원으로 지원 가능 시스템이 되는지는 최종적으로 평가자가 판단하므로, 적용 증빙을 갖춰 두세요.

---

🛠 조치 방법

1단계. 버전 확인 (일반 계정으로 가능)

# 리눅스 공통: 배포판 이름과 버전
cat /etc/os-release

# RHEL 계열: 마이너 버전까지 확인
cat /etc/redhat-release

# Ubuntu: ESM 같은 지원 서비스 연결 상태와 패키지 지원 현황
pro status
pro security-status

# 윈도우 (PowerShell): OS 이름과 빌드
Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber

결과를 벤더 수명주기 페이지와 대조합니다. 버전이 지원 중이라고 나와도 끝이 아닙니다. 최근 보안 업데이트가 실제로 설치되고 있는지를 1편의 방법(미적용 업데이트 목록, 빌드 번호)으로 함께 확인해야 사실상 지원 상태를 알 수 있습니다. 저장소 갱신이 실패하거나 몇 달째 새 보안 업데이트가 안 보인다면 의심해 볼 신호입니다.

2단계. EoS 관리대장 만들기

OS뿐 아니라 DB, 미들웨어, 장비 펌웨어까지 한 표로 모읍니다. 이 대장이 그대로 점검 증적이 됩니다.

자산	버전·지원 종료일	연장 지원	조치·승인
web01	Ubuntu 20.04 / 2025.05 종료	ESM 적용 (2030.05까지)	2027년 상반기 24.04로 전환 예정
app01	Server 2012 R2 / 2026.10 완전 종료	불가	교체 계획 보고, 보호 조치, 위험수용 승인
db01	RHEL 9.x / 2032.05 종료	불필요	최신 마이너 유지 확인

3단계. 연장 지원 검토

바로 교체할 수 없다면 연장 지원이 있는지부터 봅니다. Ubuntu는 Ubuntu Pro로 ESM을 켜면 표준 지원이 끝난 LTS도 5년 더 보안 업데이트를 받습니다. Red Hat은 RHEL 7.9에 대해 ELS를, RHEL 8.10 이후에는 새 연장 상품을 제공합니다. Microsoft ESU는 제품마다 기간이 정해져 있고, Windows Server 2012는 이미 끝났습니다.

💡 팁 연장 지원은 교체까지 버티는 다리입니다. 연장 종료일도 대장에 함께 적어 두고, 그 날짜보다 앞서 교체 일정을 잡으세요. 연장 지원은 보통 중요도가 높은 보안 수정만 제공하므로, 일반 버그 수정까지 기대하면 안 됩니다.

4단계. 연장 지원이 불가능할 때: 보호 조치와 위험수용

교체 전까지는 공격 받을 수 있는 면을 최대한 줄여야 합니다. 아래 조치를 적용하고, 그 내용을 위험수용 승인 문서에 함께 남깁니다.

보호 조치	내용
네트워크 격리	별도 구간으로 분리하고, 꼭 필요한 시스템과의 통신만 허용합니다.
접근 제한	관리 접속은 지정된 IP와 계정으로만 허용합니다(SRV-027 서비스 접근 IP·포트 제한과 연결).
기능 축소	업무에 필요 없는 서비스와 포트를 모두 닫습니다.
감시 강화	로그를 원격 서버로 보내고, 이상 접속에 알림을 겁니다.
정기 재검토	위험수용은 기한을 정해 승인받고, 기한마다 교체 진행 상황을 다시 보고합니다.

⚠️ 주의 네트워크 격리나 방화벽 정책 변경은 서비스 장애로 이어질 수 있습니다. 변경 전에 현재 통신 흐름과 정책을 백업하고, 원격으로 작업한다면 관리 접속이 끊기지 않는지 먼저 확인한 뒤 적용하세요.

---

🎉 정리: 패치·EoS 2부작

EoS 점검의 핵심은 "버전이 오래됐는가"가 아니라 "아직 보안 패치를 받고 있는가"입니다. 메인스트림 종료와 EoS를 구분하고, 연장 지원이 있으면 적용하되 그 끝도 함께 관리하고, 연장도 불가능하면 보호 조치와 위험수용으로 버티면서 교체를 서두르면 됩니다. 계획서만으로는 양호가 되지 않는다는 점만 기억하세요.

1편과 합치면 흐름이 이어집니다. 지원 중인 시스템은 패치 절차로 관리하고(SRV-118), 패치가 끊긴 시스템은 교체와 위험수용으로 관리합니다(SRV-179).

✅ 점검 체크리스트

구분	확인할 것
자산	OS·DB·미들웨어·장비의 버전과 지원 종료일이 대장으로 관리되는가
즉시 확인	Windows Server 2012·2012 R2가 남아 있는가 (2026.10.13 완전 종료)
임박	Windows Server 2016(2027.01), Ubuntu 22.04(2027.05) 전환 계획이 있는가
연장 지원	ESU·ELS·ESM을 쓰는 서버는 실제로 업데이트를 받고 있고, 연장 종료일이 기록돼 있는가
위험수용	교체 계획 보고, 보호 조치, 기한이 있는 위험수용 승인이 갖춰져 있는가

💬 자주 묻는 질문

Q. Azure로 옮긴 Windows Server 2012는 아직 무료 ESU를 받지 않나요?
Azure에서 무료로 제공되던 ESU도 같은 날(2026.10.13) 함께 끝났습니다. 이제 어떤 경로로도 Microsoft의 보안 업데이트를 받을 수 없습니다.

Q. Ubuntu 20.04에서 22.04를 건너뛰고 바로 24.04로 올릴 수 있나요?
Ubuntu의 LTS 업그레이드는 순서대로 진행해야 해서 20.04 → 22.04 → 24.04 두 단계를 거칩니다. 2026년 4월에 나온 26.04 LTS도 고려 대상이지만, 운영 서버라면 첫 포인트 릴리스가 나온 뒤 전환하는 경우가 많습니다.

Q. RHEL 호환 배포판도 같은 날짜를 따르나요?
Rocky Linux, AlmaLinux 같은 호환 배포판은 각자 수명주기를 발표합니다. 비슷한 일정인 경우가 많지만, 반드시 해당 배포판의 공식 공지로 확인하세요.

🔗 참고 자료

· Microsoft 지원: Windows Server 2012 R2 ESU 최종일(2026.10.13) 안내
· Microsoft: Windows Server 릴리스 정보와 지원 종료일
· Red Hat: RHEL 수명주기 정책
· Red Hat 블로그: RHEL 7 ELS 안내
· Ubuntu: 릴리스 주기와 지원 기간
· Ubuntu 블로그: 20.04 표준 지원 종료와 ESM
· 보도: 2026년 금융보안원 평가기준 개정 내용

 

---

※ 이 글은 공개된 벤더 문서와 공개 가이드를 바탕으로 작성한 일반 가이드이며, 특정 조직과 무관합니다. 관리대장의 서버명과 일정은 가상 예시입니다. 금융보안원 평가기준 원문은 배포가 제한된 문서이므로, 원문의 판단 문구와 점검 절차는 싣지 않았습니다. 지원 종료일은 2026년 10월 기준이며 벤더 사정에 따라 바뀔 수 있습니다. 실제 판정은 각 조직이 적용하는 최신 평가기준을 따르세요.