서버 보안 패치 관리 방법, 리눅스·윈도우 한 번에 정리 2026

📌 3줄 요약

1. SRV-118은 보안 패치를 검토하고, 계획하고, 적용하는 절차가 실제로 돌아가는지 보는 위험도 4.0 항목입니다.

2. 설치된 패키지 목록(rpm -qa)이나 옛 명령(wmic)으로는 현황을 알 수 없습니다. 아직 적용하지 않은 보안 업데이트 목록과 OS 빌드 번호를 봐야 합니다.

3. 커널 같은 패치는 재부팅해야 반영되고, 바로 적용할 수 없는 패치는 보호 방안과 근거를 기록으로 남기면 됩니다.

매달 패치를 꼬박꼬박 설치하는데 점검에서는 "보안 패치 미적용"이 나온 적 있나요? 혹은 점검 담당자가 rpm -qa 결과를 보여 달라고 해서 수천 줄짜리 목록을 넘겨준 적은요?

패치는 "설치했다"로 끝나지 않습니다. 무엇이 아직 안 깔렸는지, 깔린 것이 실제로 동작 중인지, 못 깐 것은 왜인지를 설명할 수 있어야 합니다. 패치·EoS 2부작의 1편에서는 그 확인 방법을 리눅스와 윈도우에서 정리합니다.

---

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

SRV-118은 금융보안원 전자금융기반시설 보안 취약점 평가기준(제2026-1호)의 서버 분야 패치 관리 항목으로, 위험도는 4.0입니다. 주요정보통신기반시설 기준의 U-64(유닉스)·W-38(윈도우) 주기적 보안 패치 적용에 대응하고, 윈도우는 W-27 최신 OS 빌드 적용과도 연결됩니다.

이 항목은 패치를 하나라도 빠뜨렸는지만 보지 않습니다. 최신·긴급 패치를 검토하고, 계획을 세우고, 계획대로 이행하거나 보호 방안을 마련했는지를 봅니다. 그래서 검토 절차가 없고 패치도 적용하지 않은 상태가 가장 확실한 취약입니다. 네트워크에 연결되지 않은 오프라인 서버는 별도 내부 기준으로 관리하도록 예외가 있습니다.

단계	할 일	남길 증적
정보 수집	벤더 보안 공지 확인 (Red Hat 보안 권고 RHSA, Ubuntu 보안 공지 USN, Microsoft 보안 업데이트 가이드)	확인 일자, 해당 공지 목록
검토	우리 서버에 해당하는지, 긴급도와 서비스 영향은 어떤지 판단	검토 결과, 적용 일정
적용	테스트 환경 확인 후 운영 반영	작업 승인, 적용 결과
반영 확인	재부팅 필요 여부 확인, 실행 중인 버전 확인	적용 후 버전·빌드 캡처
예외 관리	바로 적용할 수 없는 패치는 보호 방안(접근 제한, 기능 비활성화 등) 마련	미적용 사유, 보호 방안, 승인

---

⚠️ 패치가 밀리면 생기는 일

보안 패치가 나왔다는 것은 취약점이 공개됐다는 뜻이기도 합니다. 공개된 취약점은 공격 도구로 빠르게 만들어지기 때문에, 패치를 미룬 기간만큼 서버는 누구나 알고 있는 약점을 안고 운영됩니다.

반대로 검토 없이 바로 운영 서버에 넣으면 호환성 문제로 장애가 날 수 있습니다. 그래서 이 항목이 "적용 여부"보다 "검토·계획·이행 절차"를 보는 것입니다. 빠르게 넣는 것과 안전하게 넣는 것 사이의 균형을 절차로 증명하라는 뜻입니다.

---

💡 설치했는데 취약 나오는 5가지 이유

함정	흔한 오해	실제	해결
설치 목록	rpm -qa 결과가 패치 현황이다	설치된 패키지 목록일 뿐, 무엇이 빠졌는지는 알 수 없다	미적용 보안 업데이트 목록을 조회
wmic	wmic qfe list로 패치 목록을 본다	WMIC는 단계적으로 제거되어 2026년 Windows 11에서 완전히 빠졌다. 최신 서버에서도 기본 설치되지 않는다는 보고가 있다	PowerShell로 대체
서비스팩	서비스팩 버전을 보면 된다	지금 윈도우는 매월 누적 업데이트 방식이라 서비스팩이 없다. OS 빌드 번호가 기준이다	빌드 번호를 업데이트 기록과 대조
재부팅	설치가 끝나면 적용된 것이다	커널·glibc 같은 패치는 재부팅해야 반영된다. Ubuntu 자동 보안 업데이트도 기본은 재부팅하지 않는다	재부팅 필요 여부를 확인하고 일정 수립
미적용 = 취약	패치 하나라도 못 깔면 무조건 취약이다	판단의 핵심은 검토 절차다. 적용하지 못한 이유와 보호 방안이 기록돼 있으면 설명할 수 있다	예외 사유·보호 방안·승인을 문서화

두 번째 함정은 점검 실무에서 특히 자주 부딪힙니다. 오래된 점검 스크립트나 가이드는 아직 wmic 명령을 쓰는 경우가 많은데, Microsoft는 이 도구를 몇 년에 걸쳐 단계적으로 없앴습니다. 점검 스크립트가 "명령을 찾을 수 없음" 오류로 멈춘다면 이것부터 의심하세요.

세 번째 함정에도 2026년에 새 변수가 생겼습니다. 1월 보안 업데이트부터 Windows Server 2025는 Windows 11과 별도의 KB 번호와 빌드 번호를 씁니다. 예전처럼 Windows 11 24H2의 빌드 번호와 나란히 놓고 비교하면 맞지 않습니다.

---

🛠 조치 방법: RHEL 9·Rocky Linux 9 계열

아래 명령은 sudo 권한으로 실행합니다. RHEL은 서브스크립션이 연결되어 있어야 보안 권고 정보가 내려옵니다.

# 1) 미적용 보안 업데이트 요약과 목록
sudo dnf updateinfo summary
sudo dnf updateinfo list updates security

# 2) 특정 권고의 상세 내용 (영향·CVE 확인용)
sudo dnf updateinfo info RHSA-XXXX:XXXX

# 3) 이미 적용한 보안 업데이트 이력 (증적용)
sudo dnf updateinfo list security --installed

검토가 끝나면 적용합니다. 운영 서버는 테스트 환경에서 먼저 확인한 뒤 진행하세요.

⚠️ 주의 패치 적용과 재부팅은 서비스 영향이 있는 작업입니다. 가상 서버라면 스냅샷을, 물리 서버라면 백업을 먼저 확보하고 작업 승인을 받은 시간에 진행하세요.

# 4) 보안 업데이트 적용
sudo dnf update --security

# 5) 재부팅이 필요한지 확인 (커널·핵심 라이브러리 갱신 시)
sudo dnf needs-restarting -r

# 6) 문제 발생 시: 작업 이력 확인 후 되돌리기
sudo dnf history
sudo dnf history undo <작업ID>

커널은 업데이트해도 이전 버전이 부팅 메뉴에 남아 있으므로, 새 커널로 문제가 생기면 이전 커널로 부팅해 되돌릴 수 있습니다.

💡 팁 보안 업데이트만 골라 설치하는 방식은 우선순위를 정할 때 유용합니다. 하지만 버그 수정으로 분류된 업데이트 중에도 안정성에 중요한 것이 있으므로, 정기 작업 때는 전체 업데이트를 함께 검토하는 편이 안전합니다. 보안 목록이 계속 0건이라면 "정말 없음"인지 저장소의 보안 메타데이터가 비어 있는지도 확인하세요.

---

🛠 조치 방법: Ubuntu 24.04 LTS

Ubuntu Server는 설치 직후부터 unattended-upgrades가 보안 업데이트를 하루 한 번 자동으로 설치합니다. 그래서 Ubuntu에서는 "설치가 됐는가"보다 "제대로 돌고 있는가, 재부팅은 했는가"를 확인하는 것이 핵심입니다.

# 1) 대기 중인 업데이트 목록
sudo apt update
apt list --upgradable

# 2) 자동 보안 업데이트가 실제로 동작하는지 (설치 이력)
sudo tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log

# 3) 지금 실행하면 무엇이 설치될지 미리 보기
sudo unattended-upgrade --dry-run -d

# 4) 재부팅이 필요한지, 어떤 패키지 때문인지
ls /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs

4번에서 파일이 보이면 패치는 설치됐지만 아직 반영되지 않은 상태입니다. 자동 재부팅은 기본으로 꺼져 있으니, 정기 재부팅 일정을 따로 잡아야 합니다. 또 unattended-upgrades는 공식 Ubuntu 저장소만 대상으로 하므로, 별도로 추가한 외부 저장소의 패키지는 수동으로 관리해야 합니다.

---

🛠 조치 방법: 윈도우

Windows Server 2022·2025 기준이며, PowerShell을 관리자 권한으로 실행합니다.

# 1) 현재 OS 빌드 확인 (CurrentBuild.UBR 형태로 읽음)
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
  Select-Object ProductName, DisplayVersion, CurrentBuild, UBR

# 2) 최근 설치된 업데이트 (wmic qfe 대체)
Get-HotFix | Sort-Object InstalledOn -Descending |
  Select-Object -First 5 HotFixID, Description, InstalledOn

1번 결과가 예를 들어 CurrentBuild 26100, UBR 32860이면 빌드는 26100.32860입니다. 이 숫자를 Microsoft의 해당 OS 업데이트 기록 페이지에 나온 최신 누적 업데이트 빌드와 비교합니다. 같거나 바로 전 달 빌드라면 정상 주기로 패치되고 있는 것입니다.

Microsoft의 정기 보안 업데이트는 매월 둘째 화요일(미국 시간)에 나옵니다. 내부 절차에 "매월 정기 업데이트 공개 후 몇 일 안에 검토, 몇 일 안에 적용"처럼 기한을 정해 두면, 점검 때 그 기한과 실제 적용일을 비교해 보여 줄 수 있습니다. 여러 대를 관리한다면 WSUS 같은 중앙 배포 도구의 승인·배포 이력이 그대로 증적이 됩니다.

⚠️ 주의 지금의 누적 업데이트는 서비싱 스택 업데이트와 묶여 배포되므로 일반적인 방법으로는 제거하기 어렵습니다. 롤백은 패치를 지우는 것보다 스냅샷·백업으로 되돌리는 것을 기본 계획으로 잡으세요.

---

🎉 정리

정리하면, SRV-118에서 증명해야 할 것은 "모든 패치를 깔았다"가 아니라 "패치를 놓치지 않는 절차가 돌아가고 있다"입니다. 설치 목록 대신 미적용 목록을 보고, 설치 뒤에는 재부팅과 빌드 번호로 반영을 확인하고, 못 깐 패치는 이유와 보호 방안을 남기면 됩니다.

그런데 이 절차가 아무리 완벽해도 통하지 않는 경우가 있습니다. 벤더가 더 이상 패치를 내놓지 않는 시스템입니다. 2편에서는 지원이 끝난(EoS) 시스템을 다루는 SRV-179로 이어집니다.

✅ 점검 체크리스트

대상	확인할 것
절차	벤더 공지 확인 주기, 검토·적용 기한, 긴급 패치 기준이 문서로 있는가
리눅스	미적용 보안 업데이트 목록(dnf updateinfo, apt list)을 정기적으로 확인하는가
리눅스	재부팅 필요 상태로 오래 방치된 서버가 없는가
윈도우	OS 빌드 번호가 최신 누적 업데이트 빌드와 맞는가
공통	점검 스크립트가 wmic처럼 사라진 명령에 의존하지 않는가
공통	적용하지 못한 패치의 사유·보호 방안·승인 기록이 있는가

💬 자주 묻는 질문

Q. 인터넷이 안 되는 내부망 서버는 어떻게 패치하나요?
외부 저장소 대신 내부 미러 저장소나 WSUS 같은 중앙 배포 서버를 두는 것이 일반적입니다. 아예 네트워크에 연결되지 않은 오프라인 서버라면, 평가기준도 별도 내부 기준으로 관리하도록 예외를 두고 있으니 그 기준을 문서로 갖춰 두세요.

Q. 패치 후 장애가 날까 봐 몇 달씩 미루고 있는데요?
미루는 것 자체보다 "왜, 언제까지 미루는지"가 없는 것이 문제입니다. 테스트 서버에서 먼저 적용해 보는 단계를 절차에 넣고, 미루는 동안의 보호 방안(접근 제한, 해당 기능 비활성화 등)을 기록해 두세요.

Q. 메인스트림 지원이 끝난 OS도 패치되나요?
Microsoft는 메인스트림 지원이 끝나도 연장 지원 기간에는 보안 업데이트를 계속 제공합니다. 예를 들어 Windows Server 2022는 2026년 10월 13일에 메인스트림 지원이 끝났지만 연장 지원은 2031년 10월까지입니다. 보안 업데이트까지 끝나는 시점이 진짜 EoS이고, 이 이야기는 2편에서 이어집니다.

🔗 참고 자료

· Red Hat: RHEL 9 보안 업데이트 관리와 모니터링
· Ubuntu Server 문서: 자동 업데이트
· Ubuntu 블로그: 업데이트 모범 사례와 재부팅 확인
· Microsoft 지원: WMIC 제거 일정
· Microsoft 지원: Windows Server 2025 누적 업데이트 예시 (KB 번호 변경 안내 포함)
· Microsoft: Windows Server 릴리스 정보와 지원 종료일

※ 이 글은 공개된 벤더 문서와 공개 가이드를 바탕으로 작성한 일반 가이드이며, 특정 조직과 무관합니다. 권고 번호와 빌드 번호는 설명용 예시입니다. 금융보안원 평가기준 원문은 배포가 제한된 문서이므로, 원문의 판단 문구와 점검 절차는 싣지 않았습니다. 실제 판정은 각 조직이 적용하는 최신 평가기준을 따르세요.