대상 OS: Amazon Linux 2023

업데이트(특히 보안 업데이트) 이후 장애/회귀(regression)가 나면, ‘업데이트를 했다’는 사실 자체보다 무엇이 바뀌었는지를 빠르게 파악하는 게 훨씬 중요합니다. 이 글은 Amazon Linux 2023에서 업데이트 직후 5~10분 안에 변경 범위를 정리하는 최소 루틴을 정리합니다.

업데이트 직후 “변경 범위”를 10분 안에 잡는 체크리스트

  1. 1) 변경된 패키지 목록(최근 설치/업데이트) 상위부터 확인

    가장 먼저 “무슨 패키지가 바뀌었는지”를 봐야 합니다. 장애가 나면 보통 glibc, openssl, systemd, kernel, nginx/httpd, php, mysql/mariadb, python 같은 핵심이 원인 후보가 됩니다.

    # 최근 변경된 RPM 목록(최신순)
rpm -qa --last | head -n 50

# 특정 시간대만 보고 싶으면(예: 오늘 날짜 포함 검색)
rpm -qa --last | grep -E "$(date +%b)\s+$(date +%d)" -n


  2. 2) 커널/부팅 관련 변경 확인(장애 영향도 큼)

    커널 업데이트는 재부팅 시점에만 반영되지만, “재부팅 후 부팅 실패/드라이버 문제/네트워크 문제”로 이어질 수 있어 최우선으로 확인합니다.

    # 현재 실행 중 커널
uname -r

# 설치된 커널 패키지 목록
rpm -q kernel kernel-core kernel-modules --last

# 최근 부팅 로그(이번 부팅에서 무엇이 있었는지)
journalctl -b -0 -p warning..alert --no-pager | head -n 200


  3. 3) 서비스 재기동/실패 여부를 ‘목록’으로 확인

    업데이트 후 서비스가 자동 재시작되거나(혹은 재시작이 필요하지만 안 된 상태)로 남아 “겉보기엔 정상인데 일부 기능이 죽은” 형태가 자주 나옵니다.

    # 실패한 유닛이 있는지 확인
systemctl --failed --no-pager

# 최근 1시간 동안 에러 레벨 로그(서비스 이름을 같이 보려면 -o short-iso)
journalctl --since "1 hour ago" -p err..alert -o short-iso --no-pager | head -n 200

# 중요한 데몬 상태 빠른 확인(환경에 맞게 조정)
systemctl status sshd --no-pager
systemctl status crond --no-pager


  4. 4) 보안 관점: SSH/인증/암호화 라이브러리 변경 여부 확인

    OpenSSH/OpenSSL/ca-certificates 등은 보안적으로는 좋은 변화지만, 레거시 클라이언트/낡은 암호 스위트/자체 서명 인증서 운영에서 갑자기 접속이 깨질 수 있습니다.

    # 주요 보안 관련 패키지 버전 확인
rpm -q openssh openssh-server openssl ca-certificates

# SSH 데몬 설정 문법 검사(설정 변경이 있었다면 특히)
sshd -t

# 서버 측 키/알고리즘 관련 디버그(접속 문제 재현 시)
# (클라이언트에서)
# ssh -vvv user@server


  5. 5) 변경 패키지의 “무엇이 바뀌었는지”(changelog)까지 바로 보기

    패키지 changelog는 “왜 바뀌었는지/무슨 동작이 달라졌는지”의 힌트를 줍니다. 장애 대응에서는 원인 추정 시간을 크게 줄여줍니다.

    # 예: openssl 변경 내역
rpm -q --changelog openssl | head -n 60

# 예: nginx/httpd 같은 서비스 패키지
# rpm -q --changelog nginx | head -n 80
# rpm -q --changelog httpd | head -n 80


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

  • 업데이트 후 재부팅했더니 NIC 이름/드라이버가 바뀌어 네트워크가 끊김: 커널/드라이버/udev 변화로 인터페이스 명칭이나 모듈 로딩이 달라져 발생.
  • SSH 접속이 갑자기 일부 구간에서만 실패: OpenSSH/OpenSSL 업데이트 후 구형 클라이언트(혹은 중간 장비)와의 알고리즘 협상이 깨짐.
  • 서비스는 running인데 기능이 부분적으로 고장: 라이브러리 업데이트(예: glibc/openssl) 이후 재기동이 필요한데 누락되거나, 설정 호환성이 깨져 일부 요청만 실패.
  • “보안 업데이트만 했는데” 애플리케이션이 죽음: 실제로는 의존성 패키지(파이썬/노드/자바 런타임)가 함께 올라가면서 동작이 달라짐.

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

  • 증상: 업데이트 후 SSH 접속이 특정 클라이언트에서만 실패

    원인: 암호 알고리즘/키 교환 방식 협상 실패(구형 클라이언트, 구형 장비, 제한된 정책)

    해결: 서버/클라이언트에서 ssh -vvv로 실패 지점 확인 → 필요 시 임시로 호환 알고리즘 허용(정책 검토 후 최소 범위) → 장기적으로는 클라이언트/중간장비 업데이트

  • 증상: 서비스가 재시작 후 바로 실패하고 계속 재시도

    원인: 업데이트로 설정 옵션이 deprecated/변경, 혹은 라이브러리 ABI 변화

    해결: systemctl status, journalctl -u 서비스명로 에러 확인 → 설정 파일 diff/문서 확인 → 롤백이 가능하면 롤백 후 원인 정리

  • 증상: 재부팅 후 네트워크가 올라오지 않음

    원인: 커널/드라이버 변경, NetworkManager/설정 파일 참조 인터페이스명이 달라짐

    해결: 콘솔 접근 확보 → ip a/nmcli로 인터페이스 확인 → 설정에서 대상 인터페이스 재지정 → 다음부터는 커널 업데이트 전후 인터페이스/모듈 체크 절차 추가

업데이트 자체를 두려워할 필요는 없습니다. 다만 업데이트 직후 “변경 목록(패키지/커널/서비스 실패)”만 습관적으로 확인해도, 장애 대응 속도가 체감될 정도로 빨라집니다.

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