대상 OS: Amazon Linux 2023

업데이트는 “적용” 자체보다 무엇이 바뀌었는지(변경 추적), 그리고 재부팅이 필요한지(리스크 판단)를 빠르게 확인하는 게 핵심입니다. 특히 커널/openssl/glibc/systemd 같은 핵심 구성요소가 바뀌면 “재시작만으로 충분한지, 재부팅이 필요한지”를 구분해야 운영 리스크를 줄일 수 있습니다.

0) 업데이트 전에: 현재 상태 스냅샷(권장)

나중에 “업데이트 후 뭔가 이상해졌다”가 나오면, 업데이트 전 상태가 있어야 원인/범위를 줄일 수 있습니다.

# 기본 정보(운영 문서/변경관리 기록용)
cat /etc/os-release
uname -r
rpm -q kernel systemd glibc openssl | sed 's/^/PKG: /'

# 현재 부팅된 커널이 어떤 패키지에서 왔는지 확인(참고)
rpm -qf /boot/vmlinuz-$(uname -r) 2>/dev/null || true


1) 업데이트 후보(특히 보안 업데이트) 먼저 확인

가능하면 “보안 업데이트”만 따로 보고, 변경 폭을 가늠합니다(환경에 따라 updateinfo 메타가 없을 수도 있습니다).

# 업데이트 후보 확인
dnf check-update

# (가능한 경우) 보안 권고 기준으로 확인
dnf -q updateinfo list security || true
dnf -q updateinfo summary || true


2) 업데이트 적용(dnf update) + 로그 남기기

서버 운영에서는 “업데이트를 했다”가 아니라 언제/무엇을/왜가 남아야 합니다. dnf 자체 히스토리도 유용합니다.

# 적용
sudo dnf -y update

# dnf 히스토리 확인(무슨 트랜잭션이 적용됐는지)
dnf history | head
sudo dnf history info last


3) 최근 변경 패키지/커널 빠르게 확인

가장 현실적인 방법은 “최근 설치/업데이트된 패키지 목록”과 “현재 커널”을 같이 보는 것입니다.

# 최근 변경 패키지 상위 30개
rpm -qa --last | head -n 30

# 현재 커널
uname -r

# 설치된 커널 패키지(복수 커널이 있으면 재부팅 후 버전이 바뀔 수 있음)
rpm -q kernel --last


4) 재부팅 필요 여부를 ‘빠르게’ 판단하는 3단계

(A) 커널이 업데이트 됐는지가 1순위입니다. 커널이 바뀌었다면 일반적으로 재부팅이 필요합니다(커널 라이브 패치 체계가 별도로 없는 일반 운영 기준).

# 커널 패키지 최근 변경 확인
rpm -q kernel --last

# 현재 커널과 설치된 최신 커널을 비교(대략적인 감)
uname -r
rpm -q --qf '%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel | sort -V | tail -n 1

(B) needs-restarting 사용: 프로세스 재시작/재부팅 필요성을 빠르게 체크할 때 도움이 됩니다(패키지 제공 여부에 따라 설치가 필요할 수 있음).

# needs-restarting 도구가 없으면 설치(환경에 따라 패키지명이 다를 수 있음)
sudo dnf -y install dnf-utils || true

# 재부팅이 필요한지(반환 코드/메시지로 판단)
sudo needs-restarting -r || true

# 어떤 프로세스가 오래된 라이브러리를 잡고 있는지(재시작 후보)
sudo needs-restarting || true

(C) 핵심 데몬(systemd/sshd 등) 재시작으로 끝나는지: 커널이 아니고, “라이브러리 갱신” 중심이면 재시작으로 리스크를 줄일 수 있습니다. 단, 원격 접속(SSH) 의존 서버는 재시작 순서가 중요합니다.

# 예: sshd 재시작 전에는 반드시 세션 2개 유지(운영 절차)
# 실제 재시작 후보는 needs-restarting 출력 기반으로 결정
sudo systemctl try-restart sshd || true
sudo systemctl try-restart chronyd || true
sudo systemctl try-restart rsyslog || true


5) 재부팅을 한다면: 안전한 확인 루틴(최소)

재부팅은 “했더니 올라오더라”가 아니라, 부팅 후 검증까지가 한 세트입니다.

# 재부팅 전: 현재 세션에서 기본 서비스 상태 확인(대략)
systemctl --failed || true
ss -lntup | head

# 재부팅
sudo reboot
# 재부팅 후: 커널/서비스 상태 확인
uname -r
uptime
systemctl --failed || true
journalctl -p 3 -xb --no-pager | head -n 80


사례(현장에서 자주 겪는 상황)

  • 커널 업데이트가 포함됐는데 재부팅을 미룸 → 다음 장애/보안 이슈 때 “커널 버전이 실제로는 옛날”이라 조사 시간이 길어짐.
  • openssl/glibc 업데이트 후 서비스 재시작을 안 함 → 프로세스가 구버전 라이브러리를 계속 물고 있어, 취약점 완화가 ‘적용된 것처럼 보이지만 실제론 미적용’ 상태가 됨.
  • dnf update만 하고 기록이 없음 → 변경관리/장애 분석 때 “무슨 패키지”가 원인인지 역추적이 어려움(dnf history를 몰라서 더 오래 걸림).

트러블슈팅(증상→원인→해결)

  • 증상: 업데이트 후에도 취약점 스캐너가 동일 취약점을 계속 표시
    원인: 라이브러리만 업데이트 되고 해당 서비스를 재시작하지 않아 구버전 라이브러리를 프로세스가 계속 사용
    해결: needs-restarting로 재시작 대상 확인 후, 영향 서비스부터 순차 재시작(가능하면 점검창에서) 또는 재부팅
  • 증상: 커널 패키지는 최신인데 uname -r가 예전 버전
    원인: 재부팅을 하지 않아 실행 커널이 바뀌지 않음
    해결: 점검창 확보 후 재부팅, 부팅 후 uname -r 및 rpm -q kernel --last로 일치 확인
  • 증상: 업데이트 후 서비스 일부가 실패 상태로 부팅됨
    원인: 설정 파일/의존성 변경으로 유닛이 깨짐(특히 systemd, 라이브러리, 설정 경로 변경 등)
    해결: systemctl --failed, journalctl -u 서비스명 -xe로 원인 확인 후 롤백(dnf history undo) 또는 설정 수정

운영 메모(권장): 업데이트 적용 시점, 적용된 트랜잭션 ID(dnf history), 재부팅 여부/시각, 재부팅 후 커널 버전, 장애 유무를 한 줄로 남겨두면 다음 대응이 빨라집니다.

- 이 글은 ai가 random적으로 만들어 올리는 글입니다. -