실행 중인 Ubuntu 업데이트하기: 사전 준비·연결 복구·재부팅 후 확인

실행 중인 Ubuntu 서버를 업데이트할 때는 패키지를 새 버전으로 바꾸는 작업뿐 아니라, 서비스를 중지하고 재부팅 후 운영 상태로 복귀시키는 절차도 필요합니다. SSH 연결이 끊기거나, 인증 설정이 새로운 사양과 맞지 않거나, 백업을 복원하지 못하는 등의 문제는 업데이트 명령이 끝난 뒤에도 발생할 수 있습니다.

이 글에서는 Ubuntu 24.04에서 26.04로의 LTS 업그레이드와 업그레이드 후 일반 업데이트에서 얻은 교훈을 다른 서버에도 적용할 수 있는 절차로 정리합니다. 전제는 관리자 권한이 있고 서비스 중지가 필요한 유지보수 시간을 확보할 수 있다는 것입니다. 먼저 공통 준비와 실행 절차를 소개하고, 후반부에서는 연결·인증·부팅 문제를 진단합니다.

24.04에서 26.04로 이전할지 일반 업데이트할지 선택하기

새 OS 세대의 기능이 필요한지 현재 세대의 수정만으로 충분한지 먼저 결정합니다. 릴리스 업그레이드에는 외부 인증, VPN, DB 호환성 검증을 추가하고 일반 업데이트는 예정된 패키지 변경과 재시작 영향을 중심으로 확인합니다. 복구 콘솔이나 실제 복원 검증이 불가능하면 시작하지 않는 기준을 마련하세요.

Ubuntu Server：LTS 이전 조건과 준비

1. 업데이트 종류와 작업 범위를 정한다

먼저 OS 버전을 올리는지, 같은 버전 내에서 패키지만 업데이트하는지 결정합니다. 두 작업은 필요한 변경 범위와 확인 항목이 다릅니다.

작업	예	사용하는 도구	사전에 확인할 사항
일반 업데이트	Ubuntu 26.04 내의 수정 사항 및 커널 업데이트	APT	업데이트·추가·삭제 예정 항목, 서비스 재시작의 영향
릴리스 업그레이드	Ubuntu 24.04에서 26.04로 업그레이드	do-release-upgrade	공식 업그레이드 조건, 호환성, 폐지·분리된 패키지

apt-get dist-upgrade는 설정된 패키지 저장소를 대상으로 의존성을 조정하는 명령입니다. 이름에 ‘dist’가 들어가도 Ubuntu의 다음 LTS로 업그레이드하는 전용 명령은 아닙니다. 릴리스 업그레이드는 Ubuntu 공식 절차에 따라 진행합니다. 운영 환경에서는 개발 버전용 -d 옵션을 사용하거나 APT 저장소만 수동으로 바꾸는 방법을 택하지 않습니다. Debian에서 Ubuntu로 바꾸는 작업도 이 절차로 수행할 수 있는 업그레이드에 해당하지 않습니다.

대상은 호스트 이름에 그치지 않고 해당 서버가 의존하는 DNS, 인증, 데이터베이스, 접속용 VPN까지 확인합니다. 여러 대를 업데이트한다면 의존 대상이 안정적으로 동작하는지 확인하면서 1대씩 진행합니다. 다른 유지보수 작업이나 백업 작업과 겹친다면 먼저 순서를 정하세요.

아울러 ‘복원에 실패함’, ‘필요한 패키지를 가져올 수 없음’, ‘정상적으로 중지할 수 없음’, ‘복구 콘솔에 접속할 수 없음’과 같은 중단 조건을 정합니다. 유지보수 시간이 끝날 때까지 업데이트를 계속하는 것보다 복구에 쓸 시간을 미리 남겨 두는 편이 판단하기 쉽습니다.

2. SSH 연결이 끊겨도 조작할 수 있는 경로를 확보한다

업데이트 전에 VPS나 클라우드 관리 화면에서 복구 콘솔에 접속할 수 있는지 확인합니다. 화면을 열 수 있는 것만으로는 충분하지 않습니다. 실제로 OS를 조작할 수 있는 로그인 방법이 필요합니다. SSH와 같은 VPN이나 인증 서버에 의존하는 경로만 있다면, 해당 의존 대상이 중단됐을 때 복구할 수 없습니다.

재부팅 버튼으로 해결되는 것은 일시적인 멈춤이나 장애입니다. 설정 오류나 부팅 순서 문제는 재부팅해도 반복됩니다. 업데이트 도중인지 알 수 없는 상태에서 재부팅을 반복하기 전에, 콘솔에서 현재 상태를 확인할 수 있도록 준비합니다.

프로바이더의 디스크 이미지를 사용하는 경우에는 이미지를 만드는 동안 부팅이나 조작이 제한되는지, 완료까지 얼마나 걸리는지, 저장 용량과 과금 단위는 무엇인지 확인합니다. 애플리케이션 백업을 사용하는 경우에는 OS를 재구축하고 설정을 복원하는 절차도 필요합니다. 어느 쪽을 선택하든 복구할 수 있는 범위와 부족한 범위를 작업 전에 정리하세요.

3. 백업을 다른 위치에 실제로 복원한다

백업 작업이 성공했더라도 필요한 데이터가 포함되어 있거나 읽어올 수 있다는 보장은 없습니다. 업데이트 전에 대상 호스트·저장 시각·저장 내용을 확인한 백업 세대를 비어 있는 검증용 디렉터리에 복원합니다.

예를 들어 restic 백업 도구를 사용하는 경우, 기존 연결 설정을 사용할 수 있는 관리자 셸에서 다음과 같이 확인할 수 있습니다. snapshot_id는 확인한 백업 세대의 ID로 바꿉니다. latest에 맡기지 않고 ID를 고정하면 검증 중 새 백업 작업이 실행되어도 대상이 바뀌지 않습니다.

# 既存のリポジトリ接続設定を使う。秘密値をコマンドに直書きしない。
snapshot_id='確認したスナップショットID'
umask 077
restore_dir=$(mktemp -d /var/tmp/restore-check.XXXXXX) || exit 1
restic restore "$snapshot_id" --target "$restore_dir" --verify

운영 데이터 디렉터리를 복원 대상으로 지정하지 않습니다. restic은 기존 파일을 덮어쓸 수 있으므로 공식 복원 사양을 확인하고, 격리된 빈 위치에서 검증합니다. R2 등의 오브젝트 스토리지를 사용하는 구성 예시는 백업의 실제 복원을 절차에 포함하는 방법에서도 소개합니다.

복원 후에는 데이터 형식에 따라 다음을 확인합니다.

데이터	확인할 사항	이것만으로 확인할 수 없는 사항
ZIP 등의 아카이브	압축 해제·무결성 검사, 필요한 파일의 존재 여부	애플리케이션이 시작되어 내용을 사용할 수 있는지
SQL 덤프	격리된 DB로 가져오기, 스키마와 주요 데이터	첨부 파일이나 외부 스토리지와의 일관성
SQLite	복원 파일의 존재·크기, DB 무결성 검사	서비스 전체의 복구
설정·인증서·키	대상 파일, 소유자, 권한, 참조 대상	외부 서비스 측 설정이나 유효성

실행 중인 DB 파일을 그대로 복사하면 저장 중인 상태가 섞일 수 있습니다. DB나 애플리케이션이 제공하는 일관성 보장 백업 방식을 사용하고 데이터와 관련 파일의 시점도 맞춥니다. 검사 명령이 빈 DB를 새로 만들 수도 있으므로, ‘무결성 검사가 성공했다’고 판단하기 전에 복원된 파일이 실제로 존재하는지 확인합니다.

인증 기반 시스템 등을 실행해 검증하는 경우에는 같은 식별 정보를 가진 복제본이 운영 환경에 통신하지 않도록 네트워크도 격리합니다. 컨테이너나 네임스페이스를 사용한다면 분리 상태를 확인한 뒤 마운트나 실행을 진행합니다. 검증용 /run을 준비하는 작업이 운영 호스트의 /run을 가리지 않는지도 확인해야 합니다.

4. 설정뿐 아니라 ‘원래의 운영 상태’도 저장한다

설정 파일의 복사본 외에도 다음 상태를 기록합니다. 보관 위치는 관리자만 읽을 수 있도록 설정하고, 기존 기록을 덮어쓰지 않게 작업별로 분리합니다.

저장 대상	나중에 대조할 내용
OS·패키지	릴리스, 실행 중인 커널, 설치된 패키지, APT 저장소와 hold
네트워크·SSH	Netplan, SSH 설정, VPN 설정, 방화벽 관리 방식
서비스	unit 및 drop-in, 부팅 시 활성화 여부, 현재 실행 상태
예약 작업	timer, cron, 백업의 활성화 여부와 다음 실행 시각
애플리케이션	설정, 데이터 위치, 컨테이너 구성, 외부 의존 대상

Netplan과 systemd를 사용하는 Ubuntu에서의 보관 예시입니다. 대상 디렉터리가 있는지 확인하고 sudo -i로 root 셸에 들어간 뒤 실행합니다. mktemp로 만드는 디렉터리는 root만 접근할 수 있는 새 위치이므로 이전 기록을 덮어쓰지 않습니다.

umask 077
record_dir=$(mktemp -d /root/ubuntu-upgrade.XXXXXX) || exit 1
cp -a /etc/netplan /etc/ssh /etc/systemd/system "$record_dir/" || exit 1
apt-mark showhold > "$record_dir/apt-hold.txt"
systemctl list-unit-files > "$record_dir/unit-files.txt"
systemctl list-units --type=service --all > "$record_dir/services.txt"
systemctl list-timers --all > "$record_dir/timers.txt"
cat /proc/sys/kernel/random/boot_id > "$record_dir/boot-id.txt"

이 예시에는 애플리케이션별 설정이나 외부 스토리지의 데이터가 포함되지 않습니다. 위 표에 따라 대상을 추가하고 보관 위치를 작업 기록에 남깁니다.

확인 명령의 예시입니다. 호스트 이름, 접속 대상, 설정 내용이 포함된 출력은 공개하지 말고 작업 기록으로 보관합니다.

cat /etc/os-release
uname -r
cat /proc/sys/kernel/random/boot_id
apt-mark showhold
systemctl list-timers --all
systemctl --failed
sudo sshd -t

sshd -t는 SSH 설정의 구문을 확인하는 명령입니다. 성공해도 외부에서 접속할 수 있는지까지는 알 수 없습니다. Netplan도 구문·생성 결과와 실제 통신을 각각 확인합니다.

업데이트를 위해 timer를 중지하거나 일시적으로 hold를 변경하는 경우에는 원래 상태와 이유를 기록합니다. 작업 후 일괄적으로 ‘모두 활성화’하면 의도적으로 중지해 둔 작업까지 실행됩니다. 설정을 복원할 때도 /etc 전체를 이전 상태로 되돌리는 대신 이번에 변경한 부분을 diff로 대조합니다.

5. 사용자가 없는 순간을 안전하게 중지할 수 있는 상태로 연결한다

사용자가 없을 때만 서비스를 중지하려면 사용자 수나 연결 수가 0인지뿐 아니라 관측 범위와 시각도 확인합니다. 입구의 프록시만 봐서는 그 뒤편의 서버나 실행 중인 작업까지 사용자가 없는지 알 수 없습니다.

판정 대상을 먼저 목록으로 만들고 각 대상에서 최신 값을 가져옵니다. 가져오기 실패, 값 누락, 오래된 값, 모니터링 대상에서 빠진 서버가 하나라도 있으면 중지를 허용하지 않습니다. ‘값 없음’을 0으로 바꾸면 모니터링 장애 시 중지될 수 있습니다.

예를 들어 평소 몇 초 간격으로 갱신되는 모니터링이라면 ‘관측 시각과 원본 데이터의 갱신 시각이 모두 15초 이내’라는 조건을 설정할 수 있습니다. 여기서 15초는 설계 예시입니다. 실제 갱신 간격에 맞춰 정하고 시각 오차도 확인하세요. 사용자 수만으로 판단할 수 있다면 사용자 이름을 수집하거나 정기적으로 콘솔에 목록 명령을 보낼 필요는 없습니다.

중지 직전에는 다음 순서를 따릅니다.

1. 모든 대상의 사용자·작업 수가 0이고, 충돌할 유지보수 작업이 없는지 확인합니다.
2. 애플리케이션이나 로드 밸런서에서 신규 접수를 차단합니다. 기존 작업은 정상적으로 완료될 때까지 기다릴 수 있는 방식을 사용합니다.
3. 접수를 차단한 뒤 생성된 새 값으로 모든 대상이 0인지 다시 확인합니다.
4. 정상 종료를 요청하고 프로세스 종료와 데이터 저장 완료를 확인합니다.
5. 업데이트·재부팅 후 동작 확인을 마친 다음 접수를 다시 허용합니다.

접수를 차단한 뒤 사용자가 발견되면 중지를 진행하지 말고, 미리 정한 대기·접수 복원 절차를 사용합니다. 앞서 확인한 0 값을 재사용하지 않습니다.

방화벽으로 제어한다면 신규 연결과 기존 연결을 어떻게 처리하는지, IPv4·IPv6, TCP·UDP를 확인합니다. UDP는 연결 처리 방식이 애플리케이션마다 다르므로 애플리케이션 측 유지보수 모드도 고려합니다. 관리용 SSH나 VPN, 내부 통신은 유지하고 재부팅 중에도 접수 차단이 지속되는지 확인합니다. 전용 임시 규칙을 사용해 복구할 때 해당 규칙만 제거할 수 있게 합니다.

정상 종료 요청과 정상 종료 완료를 구분한다

systemctl stop을 사용하는 경우 대상 unit의 ExecStop, 중지 유예 시간, 강제 종료 설정을 먼저 확인합니다. ExecStop이 종료 요청만 보내고 반환하면 남은 프로세스가 systemd에 의해 종료될 수 있습니다. systemd 사양에 따라 정상 종료를 기다리는 처리까지 포함합니다.

콘솔 입력으로 종료하는 서비스라면 올바른 명령이 개행 문자와 함께 대상 프로세스에 전달되어야 합니다. unit 내부 명령 줄에서 셸의 $()나 파이프를 자동으로 사용할 수 있다고 가정할 수는 없습니다. 필요한 처리는 작은 스크립트로 묶고, 대상 프로세스를 잘못 식별하지 않도록 확인한 뒤 종료될 때까지 기다립니다. 시간 초과가 발생하면 강제 종료하고 업데이트를 계속하는 대신 정상 중지에 실패한 원인을 조사합니다.

6. 일반 업데이트는 색인 가져오기·예정 확인·적용을 나눠 진행한다

복원 확인과 중지 준비가 끝나면 먼저 패키지 색인을 가져옵니다. 일부 저장소에서 가져오기에 실패한 상태로 오래된 색인을 사용해 다음 단계로 넘어가지 않도록 합니다.

# この段階ではパッケージを更新しない
sudo apt-get update -o APT::Update::Error-Mode=any &&
  sudo apt-get -s --no-remove dist-upgrade

시뮬레이션의 종료 코드와 업데이트·추가·삭제 예정 항목을 확인합니다. --no-remove는 삭제가 필요한 경우 중단하기 위한 조건입니다. 커널 등은 새 패키지 추가가 필요할 수 있으므로 일반 업데이트에 ‘추가 항목 0’을 공통 조건으로 삼지 않습니다. APT 사양에 따르면 시뮬레이션 중 상태는 고정되지 않습니다. 실행 직전에도 다른 APT 작업이 실행 중이 아닌지, 예정 항목이 바뀌지 않았는지 확인합니다.

예정에 문제가 없고 대상 서비스가 중지된 것을 확인했다면 적용을 진행합니다. needrestart를 사용하는 환경에서 추가 재시작 제안을 목록으로 표시하는 예시는 다음과 같습니다.

# 通常更新の予定を確認し、必要なサービスを正常停止した後に実行する
sudo env NEEDRESTART_MODE=l apt-get --no-remove dist-upgrade

NEEDRESTART_MODE=l은 needrestart의 목록 표시 모드를 지정합니다. 패키지 자체의 설정 처리에 따른 서비스 재시작까지 모두 금지하는 설정은 아닙니다. SSH나 VPN에 미치는 영향도 고려해 복구 경로를 확보한 유지보수 시간에 실행합니다. 확인 없이 -y를 지정하거나 모든 설정 파일을 일괄 교체하는 옵션은 사용하지 않습니다.

SSH 연결이 끊기는 상황에 대비해 tmux처럼 연결이 끊긴 뒤에도 처리를 계속할 수 있는 관리자 세션을 사용하고 명령의 종료 결과를 기록합니다. 자동 실행하는 경우에는 실행 직전에 대상 호스트, OS 버전, 설정 대조 결과, 백업 검증, 중지 상태를 확인하고 중간 단계도 저장합니다. 연결이 끊겼다고 같은 업데이트를 다시 시작하지 않습니다.

단계적 배포로 남은 업데이트 처리

Ubuntu의 단계적 배포는 일부 사용자에게 일반 업데이트를 순차적으로 제공하고 문제가 발생하면 배포를 억제하는 방식입니다. 일반 업데이트에서 단계적 배포로 인해 보류된 항목이 남으면 그 이유를 기록합니다. 보류 건수를 0으로 만들기 위해 강제 적용으로 전환할 필요는 없습니다. Ubuntu의 단계적 배포 설명

다만 릴리스 업그레이드를 준비하는 일은 별개입니다. Ubuntu 공식 절차는 단계적 배포로 보류된 항목도 포함해 현재 릴리스의 업데이트를 적용하도록 안내합니다. do-release-upgrade의 사전 조건에는 해당 시점의 공식 절차를 따르세요. 릴리스 업그레이드에는 필요한 패키지 교체나 삭제도 있으므로 위의 일반 업데이트용 명령을 그대로 업그레이드 절차로 사용하지 않습니다.

실행 전에 다음 명령으로 제공되는 업그레이드 대상을 확인합니다.

sudo do-release-upgrade -c

의도한 LTS가 대상으로 표시되고 현재 릴리스 업데이트와 재부팅, 복원 검증, 호환성 확인을 마친 뒤 유지보수 시간에 sudo do-release-upgrade를 실행합니다. 확인했는데 업그레이드 대상이 표시되지 않는 경우에는 제공 조건을 조사합니다. 개발 버전을 지정해 진행하지 않습니다. 설정 파일 변경 확인이 표시되면 diff를 살펴 연결·인증 설정에 미치는 영향을 판단합니다.

7. SSH가 돌아오지 않으면 통신과 부팅을 순서대로 조사한다

SSH에 연결할 수 없다면 복구 콘솔에서 다음 항목을 나눠 확인합니다.

확인 단계	확인 예시	다음으로 조사할 사항
OS가 부팅되었는가	콘솔, systemctl --failed	긴급 모드, 실패한 unit, 패키지 설정 중단
IP와 경로가 있는가	ip address, ip route	Netplan 설정의 생성 원본, 인터페이스 이름, 경로 변경
SSH가 대기 중인가	sshd -t, SSH service·socket	설정 오류, 실제 대기 포트
외부에서 접속할 수 있는가	다른 호스트에서 연결	방화벽, VPN, 클라우드 측 통신 제어

journal은 현재 부팅을 대상으로 조사합니다. journalctl -b -u 対象unit으로 부팅 실패나 취소 이유를 확인하고, systemctl show 対象unit -p After -p Before -p Requires -p Wants로 의존 관계를 확인합니다.

접속용 VPN의 시작이 취소되는 경우 네트워크 설정뿐 아니라 부팅 순서도 의심합니다. 오래된 socket unit이 VPN을 기다리고, 해당 VPN이 다시 다른 부팅 단계를 기다려 순환이 생기는 사례가 있습니다. 현재 사용하는 대기 포트와 통신을 확인한 뒤 역할이 끝난 unit만 수정합니다. socket activation에서는 연결을 기다리는 service가 inactive여도 정상일 수 있으므로 상태 표시만으로 불필요하다고 판단하지 않습니다.

cloud-init이 네트워크 설정을 다시 생성하는 경우

cloud-init은 클라우드 초기 설정 등을 수행하는 도구입니다. 관리자가 기존 Netplan 설정을 유지하는 설계라면 업데이트 후 다시 생성되는 설정이 바뀌지 않는지 확인합니다. 네트워크 설정 생성을 비활성화하려면 /etc/cloud/cloud.cfg.d/ 아래의 관리용 파일에 다음과 같이 작성합니다.

network:
  config: disabled

이는 cloud-init의 네트워크 설정 생성만 비활성화하는 설정입니다. 클라우드 메타데이터에서 네트워크 설정을 받는 환경에 일괄 적용하지 않습니다. 설정 관리 주체를 확인하고 기존 Netplan 보관본·해시 대조, 생성 결과 확인, 일반 재부팅 후 통신까지 검증합니다.

8. 해당 구성을 사용하는 경우에만 인증·부팅 호환성 문제를 확인한다

다음은 해당 소프트웨어를 사용하는 환경을 위한 확인 사항입니다. 설치하지 않은 서버에 추가할 필요는 없습니다.

Samba로 Windows 도메인 인증을 제공하는 경우

Samba AD/DC는 Windows 도메인의 인증과 디렉터리를 제공하는 구성입니다. Ubuntu 26.04로 업그레이드할 때는 공식 업그레이드 주의 사항에 따라 이전 OS에서 samba-ad-dc 설치 상태를 확인합니다.

dpkg-query -W -f='${Status}\n' samba-ad-dc
apt-cache policy samba-ad-dc

install ok installed인지 확인하고, 설치되지 않았다면 공식 저장소와 추가 설치 예정 항목을 확인한 뒤 이전 OS에서 설치합니다. 필요한 패키지를 보충하는 작업과 도메인 재생성이나 기능 수준 변경을 함께 진행하지 않습니다.

백업에는 DB 파일을 단순 복사하는 대신 samba-tool domain backup의 적절한 방식을 사용합니다. 복원 검증에서는 DB뿐 아니라 격리된 환경에서 디렉터리 응답도 확인합니다. Samba 4.23을 사용한 검증에서는 DB·PID 저장 위치를 바꿔도 내부 소켓용 /run/samba/nmbd가 없어 시작할 수 없는 사례가 있었습니다. 영구 데이터와 런타임 디렉터리를 나눠 점검하면 백업 손상과 검증 환경의 누락을 구분할 수 있습니다.

SSSD로 외부 인증 시스템과 연동하는 경우

SSSD는 Linux를 AD나 LDAP 등의 사용자 정보·인증 시스템에 연결하는 도구입니다. SSSD 2.10에서는 config_file_version이 폐지되었습니다. 오래된 설정이 남아 있다면 원본 파일의 소유자와 권한을 보존한 뒤 수정하고 sudo sssctl config-check로 확인합니다.

시작 방식에도 주의합니다. SSSD 본체의 monitor에서 시작하는 responder와 systemd socket에서 시작하는 동일한 responder가 충돌할 수 있습니다. responder는 사용자 정보 조회나 인증 등을 담당하는 프로세스입니다. 설치된 버전의 설정 사양과 로그를 대조하고 충돌하는 대상만 조정합니다.

수정 후에는 사용자 정보 조회, 필요한 인증 처리, 도메인의 온라인 상태를 확인합니다. AD 연동이라면 기존 machine key를 사용한 adcli testjoin도 확인 항목입니다. 키를 다시 발급하거나 도메인에 재가입하기 전에 설정과 시작 방식의 문제부터 구분합니다.

업데이트가 중단되어 패키지나 부팅 파일이 불완전한 경우

먼저 sudo dpkg --audit와 sudo apt-get check로 설정이 끝나지 않은 패키지와 의존 관계를 확인합니다. 다른 APT·dpkg 작업이 진행 중이라면 겹쳐 실행하지 않습니다. 잠금 파일을 삭제하고 강행하는 방법도 사용하지 않습니다.

작업이 끝났고 설정되지 않은 패키지의 설정을 계속할 상황임을 확인한 경우 sudo dpkg --configure -a로 설정을 재개합니다. 종료 결과를 확인한 뒤 다음 단계로 진행하고, 저장소나 의존 관계 문제가 남아 있다면 먼저 해결합니다.

새 커널이 설치되어 있어도 부팅에 필요한 initrd가 없으면 정상적으로 부팅할 수 없습니다. /boot의 용량, 설치된 커널, 해당 커널에 맞는 부팅 파일을 확인합니다. initrd를 새로 만드는 update-initramfs -c -k 対象バージョン과 기존 initrd를 업데이트하는 -u는 용도가 다릅니다. update-initramfs 사양

복구할 커널은 설치된 커널 목록에서 선택합니다. uname -r은 현재 실행 중인 커널을 표시하므로 업데이트 전의 이전 버전을 가리킬 수 있습니다.

정상 부팅이 되지 않아 임시 root 복구 셸을 사용하는 경우, 인증을 우회하는 작업이므로 관리자의 승인과 절차를 확인합니다. 처음에는 읽기 전용으로 점검하고 필요한 변경만 수행합니다. 임시 부팅 옵션이나 서비스 시작 억제를 되돌리고 마지막으로 일반 systemd 부팅에서 검증합니다. 복구 셸에서 서비스를 시작할 수 있었다는 것만으로 자동 시작이 확인되지는 않습니다.

9. 재부팅 후 완료 조건을 대조한다

업데이트가 끝나면 패키지 설정 처리가 완료된 것을 확인한 뒤 일반 재부팅합니다. 재부팅 후에는 업데이트 전 기록과 다음 항목을 대조합니다.

완료 조건	확인할 증거
일반 부팅이 완료됨	boot ID가 바뀌었고 복구 셸이나 긴급 모드에 남아 있지 않음
예정한 OS·커널로 실행 중	/etc/os-release와 uname -r. 설치된 목록만으로 판단하지 않음
패키지 일관성 확인	dpkg --audit, apt-get check 결과
필요한 서비스가 자동 복귀함	service·socket·컨테이너와 실패한 unit, 외부 응답
연결과 인증을 사용할 수 있음	다른 호스트에서 SSH·VPN·필요한 인증 경로 확인
임시 변경이 정리됨	접수, 방화벽, timer, hold, unit 및 설정 diff
업데이트 후 상태를 복원할 수 있음	새 백업 세대를 실제 복원한 결과와 검증 내용

동작 확인은 업데이트한 호스트 내부에서만 하지 말고 실제 이용 경로와 가까운 다른 호스트에서도 수행합니다. API라면 정상 요청이 성공하는 것뿐 아니라, 인증이 필요한 경로에서는 인증되지 않은 요청이 사양에 따라 거부되는지도 확인합니다. HTTP 200만으로는 인증 경계나 애플리케이션의 주요 기능을 확인할 수 없습니다.

접수를 다시 허용한 뒤에는 유지보수용 임시 unit이나 규칙이 남아 있지 않은지 확인합니다. 백업이 활성화된 대상은 완성된 상태를 다시 저장하고 그 새 백업 세대를 복원해 검증합니다. 업데이트 전에 복원이 성공했다는 사실을 업데이트 후 백업의 증거로 사용하지 않습니다. 의도적으로 중지해 둔 백업은 원래의 중지 상태를 유지합니다.

마지막 작업 기록에는 변경 사항, 명령의 종료 결과, 복구 과정에서 추가로 수행한 작업, 확인한 범위, 남은 보류 항목을 적습니다. 실제 사용자의 로그인이나 주요 작업을 시험하지 않았다면 해당 항목은 미확인으로 남깁니다. 백업 일부를 꺼낼 수 있었다는 것과 다른 환경에서 서비스 전체를 복구할 수 있었다는 것도 구분해 기록하세요.