서버에 unattended-upgrades를 설정해 두면 보안 업데이트가 자동으로 설치되므로, 패치 관리가 끝난 것처럼 보이기 쉽습니다. 그러나 보안 패키지가 설치되는 것과 실행 중인 커널에 패치가 반영되는 것은 별개의 일입니다. ISMS-P 점검이나 내부 감사에서 패치 적용 여부를 물으면, 설치 기록과 재부팅 상태를 함께 제시해야 하는 경우가 많습니다.
이 글에서는 Ubuntu와 Debian 계열 서버를 기준으로 자동 업데이트 설정 확인, 적용 로그 읽는 법, 재부팅이 필요한 서버를 찾는 두 가지 방법인 reboot-required 파일과 needrestart를 정리합니다. RHEL 계열은 마지막 부분에서 대응 도구만 짚습니다. 여기서 소개하는 명령은 모두 상태를 읽기만 하므로 운영 서버에서 먼저 실행해도 서비스에 영향을 주지 않습니다.
자동 업데이트를 켰는데도 커널이 낡아 있는 이유
커널 패치는 설치만으로는 적용되지 않습니다. 새 커널 이미지가 설치되어도 실행 중인 커널은 이전 버전이므로, 재부팅해서 새 커널로 부팅해야 취약점이 실제로 막힙니다. 자동 업데이트는 패키지를 설치할 뿐이고, 기본 설정에서는 재부팅을 하지 않습니다.
따라서 자동 업데이트가 켜져 있다는 것과 커널 패치가 반영되었다는 것은 다른 상태입니다. 설치됨, 재부팅 대기, 재부팅 완료의 세 단계를 나누어 봐야 합니다. 대부분의 누락은 두 번째 단계, 즉 재부팅 대기 상태에서 발생합니다.
unattended-upgrades 설정부터 확인하기
Ubuntu에서 자동 업데이트 활성화 여부는 /etc/apt/apt.conf.d/20auto-upgrades 파일에 있습니다. 여기서 APT::Periodic::Unattended-Upgrade 값이 "1"인지, 목록 갱신 값이 "1"인지 확인합니다. 적용 대상 저장소는 /etc/apt/apt.conf.d/50unattended-upgrades의 Allowed-Origins에서 정하며, 보안 저장소(-security) 항목이 주석 처리되어 있지 않은지 반드시 확인해야 합니다.
설정 파일을 직접 고쳤다면 실제 설치 없이 적용 대상을 미리 보는 dry-run을 실행합니다. 명령은 sudo unattended-upgrade --dry-run --debug 입니다. 출력에 보안 저장소 패키지가 나타나는지 보면, 설정이 의도대로 동작하는지 판단할 수 있습니다.
자동 재부팅 옵션 확인
50unattended-upgrades에는 Automatic-Reboot 항목이 있으며, 기본값은 false입니다. 이 값이 false이면 보안 업데이트가 설치되어도 서버는 스스로 재부팅하지 않습니다. 자동 재부팅을 쓰려면 true로 바꾸고 Automatic-Reboot-Time으로 점검 시간대를 정해야 합니다.
자동 재부팅은 서비스 중단을 동반하므로, 이중화 여부와 점검 시간대를 운영 담당자와 먼저 합의한 뒤 켜야 합니다. 처음에는 개발이나 스테이징 서버에서 켜고 재부팅 후 서비스 복구 시간을 측정하는 편이 안전합니다.
적용 로그로 실제 설치 여부 확인하기
자동 설치 결과는 /var/log/unattended-upgrades/unattended-upgrades.log에 남습니다. 이 파일에서 업그레이드된 패키지 목록이 있는지 찾으면 자동 설치가 실행된 것입니다. 실패했다면 Exception이나 dpkg 오류 문구가 보입니다. 같은 폴더의 unattended-upgrades-dpkg.log에는 dpkg 수준의 설치 기록이 남습니다.
로그는 주기적으로 회전되어 이전 기록이 압축 파일로 남습니다. zgrep으로 압축 파일까지 함께 검색하면 몇 주 전의 설치 기록도 찾을 수 있습니다. 이때 설치 기록이 있다는 사실과 재부팅 후 반영되었다는 사실을 혼동하지 않아야 합니다.
가상 사례입니다. 운영 서버 12대를 점검하는데, 로그에는 최근 3주간 linux-image 패키지가 설치된 기록이 있었습니다. 그런데 uname -r 결과는 두 달 전 커널 버전이었고, 8대는 재부팅한 기록이 없었습니다. 설치는 되었지만 반영되지 않은 전형적인 경우입니다.
재부팅이 필요한 서버를 찾는 두 가지 방법
방법 1: /var/run/reboot-required 확인
Debian과 Ubuntu에서는 재부팅이 필요한 패키지가 설치되면 /var/run/reboot-required 파일이 생깁니다. 이 파일이 있으면 재부팅 대기 상태입니다. 어떤 패키지 때문인지는 /var/run/reboot-required.pkgs 파일에 나열됩니다. 점검 기록에는 두 파일의 내용을 함께 남기면 근거가 명확해집니다.
다만 이 파일이 없다는 것만으로 최신 커널이 실행 중이라고 단정하면 안 됩니다. 파일은 패키지 설치 시점에 만들어지므로, 설치된 커널과 실행 중인 커널을 직접 비교해야 확실합니다.
방법 2: needrestart로 커널과 서비스 확인
needrestart가 설치되어 있지 않다면 apt로 추가합니다. sudo needrestart -r l 명령은 재시작이 필요한 서비스를 목록으로만 보여 주고, 아무것도 재시작하지 않습니다. 출력에 Pending kernel upgrade 문구가 있으면 실행 중인 커널과 설치된 커널이 다른 상태입니다.
needrestart는 커널뿐 아니라 라이브러리 갱신 후 재시작이 필요한 서비스도 찾아 줍니다. 커널은 재부팅을 기다려야 하지만 서비스는 재시작만으로 반영되는 경우를 구분할 수 있습니다. 자동 재시작 정책은 /etc/needrestart/needrestart.conf의 restart 값으로 정하며, 처음에는 목록만 보는 l 설정으로 두고 운영 기준을 정하는 편이 안전합니다.
커널 패치가 빠지는 대표 원인
재부팅 대기 서버가 생기는 원인은 여러 가지입니다. 아래 표는 증상과 확인 방법을 묶어 정리한 것입니다. 점검할 때는 증상 하나만 보고 판단하지 말고 설정, 로그, 커널 버전을 함께 보는 것이 좋습니다.
| 원인 | 나타나는 증상 | 확인 방법 |
|---|---|---|
| 자동 재부팅 꺼짐(기본값) | 설치 로그는 정상, uname -r은 이전 버전 | 50unattended-upgrades의 Automatic-Reboot 값 |
| 보안 저장소 제외 | 일반 패키지만 설치되고 보안 패키지 기록이 없음 | Allowed-Origins의 -security 항목 |
| 패키지 보류(hold) | 특정 커널이나 라이브러리만 계속 제외됨 | apt-mark showhold 결과 |
| 부트 기본 항목이 이전 커널 | 재부팅해도 이전 커널로 부팅됨 | grub 기본 항목과 /boot의 커널 목록 비교 |
| 컨테이너 호스트 | 이미지 패키지는 최신인데 커널 버전은 동일 | 커널은 호스트 기준이므로 호스트에서 확인 |
| 업데이트 중단 실패 | dpkg 잠금이나 의존성 오류로 설치가 멈춤 | unattended-upgrades.log의 오류 문구 |
바로 해 볼 순서
- 서버마다 uname -r 결과와 /boot 아래 최신 커널 버전을 비교해 차이가 있는 서버를 표시합니다.
- 20auto-upgrades와 50unattended-upgrades에서 자동 업그레이드 값, Allowed-Origins, Automatic-Reboot 값을 확인합니다.
- unattended-upgrades.log와 압축된 로그를 zgrep으로 검색해 최근 설치 기록과 실패 문구를 정리합니다.
- /var/run/reboot-required 존재 여부와 needrestart -r l 출력을 함께 모아 재부팅 대기 서버 목록을 만듭니다.
- 서비스 영향도를 기준으로 재부팅 창을 잡고, 재부팅 후 같은 방법으로 다시 확인한 결과를 점검 기록에 남깁니다.
자주 묻는 질문
질문: 재부팅 없이 커널 패치를 적용할 수 있나요?
일반 커널 업데이트는 재부팅 없이 실행 중인 커널에 반영되지 않습니다. 재부팅을 줄이기 위해 공급사의 라이브 패치 기능을 검토할 수는 있지만, 지원 범위와 구독 조건은 공급사 문서에서 직접 확인해야 합니다. 라이브 패치가 모든 커널 취약점을 대체한다고 가정하지 않는 것이 좋습니다.
질문: 자동 재부팅을 켜면 서비스 장애가 나지 않나요?
재부팅하는 동안 해당 서버의 서비스는 중단됩니다. 이중화된 서비스라도 세션 유지 방식, 배치 작업과의 충돌, DB 연결 재시도 설정을 먼저 확인해야 합니다. 자동 재부팅은 점검 시간대와 복구 절차를 문서로 정한 뒤에 운영 서버에 적용하는 것이 바람직합니다.
질문: 컨테이너 이미지를 최신으로 빌드했는데 왜 커널 점검에서 걸리나요?
컨테이너는 호스트의 커널을 공유합니다. 이미지 안의 패키지를 아무리 올려도 커널 버전은 호스트 커널로 결정됩니다. 따라서 호스트 노드의 재부팅 상태와 커널 버전을 따로 점검하고, 점검 보고서에도 호스트와 컨테이너를 구분해 기록해야 합니다.
정리
- 자동 업데이트는 패키지 설치까지만 담당하며, 기본 설정에서는 재부팅하지 않습니다.
- 설치 로그, /var/run/reboot-required 파일, needrestart 출력을 함께 봐야 재부팅 대기 서버를 정확히 찾을 수 있습니다.
- 커널 버전은 uname -r과 설치된 커널을 비교해 확인하고, 그 결과를 점검 기록으로 남겨야 합니다.
오늘 할 일: 운영 서버 한 대를 골라 uname -r 결과와 /boot의 최신 커널 버전을 비교하고, 차이가 있으면 재부팅 계획을 세우세요.
댓글