Linux 서버 유지보수 체크리스트: 주간 및 월간 점검 가이드

Linux 서버 유지보수의 실체

Linux 서버 유지보수는 정해진 주기에 따라 수행하는 짧은 점검 목록이며, 끝이 있는 프로젝트가 아닙니다. 매주 업데이트 설치 여부, 디스크 여유 공간, 서비스 가동 상태, 백업 작업 완료 여부를 확인합니다. 매달 복구 테스트, 인증서 만료 확인, 계정 및 키 감사, 오래된 커널과 로그 정리를 수행합니다. 배포판의 메인 릴리스가 나올 때마다 버전 업그레이드를 계획하고 미뤄왔던 재부팅을 진행합니다.

서버 구축은 별개의 작업이며, 새로운 VPS에서 수행하는 첫 10분에서 해당 내용을 다룹니다. 이 페이지는 그 이후의 1년을 위한 것입니다. 아래의 모든 항목은 예방하고자 하는 장애를 명시합니다. 결과가 따르지 않는 체크리스트는 결국 아무도 실행하지 않게 되기 때문입니다.

여기에 나열된 명령어는 예시이며 실행하기 전에 내용을 읽어봐야 합니다. 여유 공간이나 프로세스 개수의 적정치는 서버의 역할에 따라 다르므로, 자신의 서버 출력 결과와 비교하십시오. 배포판마다 점검 방식이 다른 경우 본문에 명시했습니다. 예시는 Debian 및 Ubuntu와 apt를 기준으로 합니다. RHEL 계열에서는 도구로 dnf을 사용하며 일부 경로는 다를 수 있습니다.

지속 가능한 Linux 서버 유지보수 주기 설정 방법

주간 점검은 패키지, 디스크 사용량, 서비스 상태, 예약 작업 등 사용자가 개입하지 않아도 스스로 변하는 항목을 다룹니다. 이러한 항목은 시간이 지나면 계속 변하므로, 일주일 이상 확인하지 않고 방치하는 것은 위험합니다.

월간 점검은 서서히 발생하는 문제를 다룹니다. 만료가 임박한 인증서, 삭제되지 않은 계정, /boot에 쌓이는 커널, 로테이션 규칙이 어긋나 비대해진 로그 파일 등이 여기에 해당합니다. 이런 문제들은 당장 내일 서버를 멈추게 하지는 않지만, 결국에는 반드시 장애를 유발합니다.

릴리스 점검은 일정에 따라 수행합니다. 배포판 릴리스는 외부 기한이 정해진 유일한 유지보수 항목입니다. 사용자의 준비 여부와 관계없이 현재 버전의 지원이 종료되기 때문입니다.

유지보수 작업을 고정된 시간에 배치하십시오. 주간 점검은 월요일 아침, 월간 점검은 매월 1일로 정하는 식입니다. "시간 날 때" 하는 점검은 점검이 아닙니다. 관리하는 서버가 몇 대를 넘어가면 수동으로 작업하지 말고 한곳에서 통합 관리하십시오. 이에 관한 내용은 한곳에서 여러 Linux 서버 관리하기에서 다룹니다.

매주 확인: 업데이트가 실제로 설치되었는가?

unattended-upgrades를 활성화하는 것과 실제로 실행되었는지 확인하는 것은 별개의 문제입니다. 서비스가 masked 상태일 수 있고, 설정이 사용하지 않는 오리진으로 제한될 수 있으며, 보류(held)된 패키지 하나가 이후의 모든 실행을 중단시킬 수 있습니다. 설치 방법은 Ubuntu의 자동 보안 업데이트에서 다룹니다. 매주 수행하는 작업의 목적은 설치한 도구가 실제로 작업을 수행했는지 증명하는 것입니다.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable은 의도가 아닌 현재 상태를 보고하므로 가장 확실한 측정 지표입니다. 해당 목록에 보안 업데이트가 남아 있다면 자동화가 제대로 작동하지 않는다는 의미이므로, 시스템이 패치되었다고 가정하기 전에 로그를 확인해야 합니다. apt-mark hold로 고정(pinned)된 패키지는 영구적으로 건너뛰며 아무것도 보고하지 않으므로, apt-mark showhold을 동일한 과정에서 함께 확인해야 하는 이유가 여기에 있습니다.

이 과정을 통해 방지할 수 있는 장애는 다음과 같습니다. 업데이트가 자동으로 이루어지고 있다고 믿으면서 실제로는 알려진 취약점이 있는 패키지를 수개월 동안 실행하는 상황입니다.

주간 점검: 디스크 및 inode 여유 공간

루트 파일 시스템이 가득 차면 디스크와 무관해 보이는 문제들이 발생합니다. 데이터베이스는 쓰기를 거부하고, 로그 기록이 중단되며, 패키지 업그레이드는 설정 도중 실패합니다. 일부 환경에서는 세션 파일을 기록할 수 없어 새로운 세션을 열 수 없게 됩니다.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i는 많은 사람이 간과하는 절반의 영역입니다. Inode는 파일 메타데이터를 담는 고정 개수의 구조체이며, df -h에서 여전히 기가바이트 단위의 여유 공간이 표시되더라도 inode가 고갈될 수 있습니다. 이 경우 여유 공간이 있음에도 쓰기 작업이 No space left on device 오류와 함께 실패하며, 처음 겪을 때는 원인을 파악하는 데 많은 시간이 소요됩니다. 보통 처리되지 않은 메일 큐나 정리되지 않은 세션 디렉터리에 수백만 개의 작은 파일이 쌓여 발생하는 문제입니다.

du -xh는 단일 파일 시스템 내에서만 동작하며, 이는 바인드 마운트나 외부 스토리지가 연결된 서버에서 의도한 동작 방식입니다. Docker 호스트의 경우, 보통 이미지 레이어나 사용하지 않는 볼륨이 원인이며, VPS에서 Docker 디스크 사용량 정리하기에 설명된 대로 이를 정리해야 합니다.

여유 공간은 용량에 대한 정보를 제공합니다. 하부 스토리지 자체의 고장은 별도의 주기로 발생하며, 이는 VPS에서 디스크 상태 모니터링하기에서 다루는 별도의 점검 항목입니다.

매주 점검: 알림 없이 중단된 서비스 확인

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

충돌 후 재시작 제한 횟수를 초과한 유닛은 failed 상태로 진입하며, 그 상태로 조용히 머무릅니다. 이와 관련하여 별도의 이메일 알림은 발송되지 않습니다. list-timers은 이 문제를 파악하는 데 더 유용한 도구입니다. 각 타이머가 마지막으로 실행된 시점과 다음 실행 예정 시간을 보여주기 때문입니다. 따라서 LAST 값이 타이머의 설정된 주기보다 오래되었다면, 해당 작업이 전혀 수행되지 않았음을 의미합니다.

유닛을 재시작하기 전에 journalctl -u <unit> -n 100 --no-pager를 사용하여 해당 유닛의 저널 로그를 먼저 확인하십시오. 재시작을 수행하면 증상이 사라져 버리며, 더 곤란한 상황이 발생할 때까지 원인을 조사할 기회를 잃게 됩니다.

이 점검을 통해 3주 전 메모리 급증 이후 죽어버린 모니터링 에이전트, 큐 워커 또는 백업 서비스가 방치되는 상황을 방지할 수 있습니다.

매주 확인: 백업 작업이 실제로 완료되었는가?

예약된 백업과 완료된 백업은 서로 다른 사실이며, 오직 완료된 백업만이 복구를 보장합니다. 완료 여부를 확인하십시오.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

두 가지를 확인해야 합니다. 마지막 실행의 종료 코드가 0인지, 그리고 가장 최근 생성된 아카이브가 최신 상태이며 예상한 크기와 비슷한지 확인하십시오. 갑자기 평소 크기의 10분의 1로 줄어든 백업 파일은 덤프는 실패했지만 파일은 생성된 경우입니다. 이는 모든 후속 작업이 정상으로 보이기 때문에 가장 위험한 형태의 백업 실패입니다.

스크립트에서 덤프를 압축기로 파이프 연결한다면, 스크립트 상단에 set -o pipefail을 추가하십시오. 이 설정이 없으면 파이프라인의 종료 상태는 압축기의 상태를 따르게 되며, 압축기는 오류 메시지를 정상적으로 압축했으므로 성공으로 간주됩니다. 결과적으로 작업은 매일 밤 아무것도 없는 작은 아카이브를 생성하면서도 성공을 보고하게 됩니다.

매월: 다른 곳에 백업 복원하기

이 항목은 대부분의 사람이 건너뛰지만, 나머지 목록이 의미가 있는지 결정짓는 가장 중요한 단계입니다.

라이브 데이터에 덮어쓰지 말고, 다른 머신이나 새로운 컨테이너에 복원하십시오. 그 후 복원된 내용을 열어 실제 데이터인지 확인하십시오. 테이블의 행 수를 세어보고, 문서를 열어보고, 복원된 애플리케이션에 로그인해 보십시오. 추출 작업이 완료되었다는 사실은 아카이브를 읽을 수 있다는 것만 증명할 뿐입니다.

저장소 도구에는 자체적인 검증 기능이 있습니다. restic check --read-data-subset=5% 및 borg check --verify-data은 인덱스가 아닌 저장된 데이터를 직접 읽습니다. 이 도구들을 실행하되, 이를 대체 수단이 아닌 스모크 테스트로 간주하십시오. 검증은 바이트가 손상되지 않았는지 확인하는 과정입니다. 복원은 그 바이트가 애플리케이션에 필요한 데이터인지 확인하는 과정입니다.

사람들이 고생하며 배우는 두 가지 세부 사항이 있습니다. 복호화 암호는 에이전트에 키가 저장되어 있지 않은 머신에서 테스트하십시오. 복호화할 수 없는 백업은 백업이 아니기 때문입니다. 또한 복원 시간을 측정하십시오. 그 소요 시간이 실제 복구 시간이며, 이를 확인하는 일반적인 시점은 장애가 발생했을 때이기 때문입니다.

매월: 곧 만료되는 인증서는 무엇입니까?

갱신 자동화는 조용히 실패할 수 있습니다. certbot 타이머는 디스크의 파일을 갱신할 수 있지만, 웹 서버는 서비스를 다시 로드하는 deploy hook이 실행되지 않아 메모리에 있는 이전 인증서를 계속 제공할 수 있습니다. 따라서 외부에서 실행 중인 서버가 어떤 인증서를 제공하고 있는지 확인해야 합니다.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

-servername 플래그는 SNI(Server Name Indication)를 설정하며, 이는 한 주소에서 여러 사이트를 호스팅할 때 필수적입니다. 그렇지 않으면 본인의 인증서가 아닌 기본 인증서가 전달됩니다. certbot을 snap으로 설치했다면 타이머 이름이 다를 수 있으므로, 임의로 가정한 유닛 이름 대신 해당 단어로 검색하십시오.

자동화가 전혀 적용되지 않은 인증서를 기억하십시오. 메일 서버, VPN, 내부 인증 기관(CA) 등이 이에 해당합니다. 이러한 인증서는 주말에 만료되기 쉬우며, 브라우저와 클라이언트는 경고를 표시하는 대신 즉시 연결을 거부합니다.

매월 점검: 사용자, sudo 권한 및 SSH 키

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T은 모든 Include이 병합된 후의 최종 설정을 출력하며, 데몬이 실제로 사용하는 설정이 바로 이것입니다. 최근 Ubuntu 이미지에는 /etc/ssh/sshd_config.d/에 드롭인 파일이 포함되어 있으며, 이 파일들이 메인 파일을 덮어쓸 수 있으므로 sshd_config만 읽어서는 잘못된 정보를 얻을 수 있습니다. RHEL 계열에서는 관리자 그룹이 sudo가 아닌 wheel이므로 getent 라인을 그에 맞게 조정하십시오.

그다음 authorized_keys 파일 자체를 확인하십시오. 접근 권한은 계정이 아닌 키 단위로 부여됩니다. 따라서 6개월 전 퇴사한 계약자가 남겨둔 키는 사용자 목록에는 나타나지 않지만 여전히 유효한 로그인 수단입니다. 키에는 주석 필드가 있습니다. 이 필드를 활용하고, 누구의 것인지 확인할 수 없는 키는 모두 삭제하십시오.

로그인 기록을 확인할 때 journalctl -t sshd --since "30 days ago" | grep -i accepted은 유닛 이름이 아닌 syslog 식별자를 기준으로 매칭합니다. 이는 중요한 차이입니다. Ubuntu 24.04는 소켓을 통해 SSH를 활성화하므로 각 연결이 생성된 개별 연결 유닛 아래에 기록되기 때문입니다. 따라서 단순히 journalctl -u ssh만 사용하면 이러한 기록을 놓칠 수 있습니다.

매월 정기 작업: 오래된 커널과 꽉 찬 /boot 파티션

/boot은 일반적인 VPS 이미지에서 수백 MB 정도의 별도 파티션으로 구성되는 경우가 많습니다. 커널 업데이트가 진행될 때마다 해당 파티션에 커널 이미지와 initramfs가 추가됩니다. 파티션 용량이 가득 차면 다음 업그레이드가 중간에 실패하며 패키지가 설정되지 않은 상태로 남게 되는데, 이는 금요일에 마주하기에는 매우 곤란한 상황입니다.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r을 가장 먼저 확인하십시오. 현재 실행 중인 커널의 이름을 알려주며, 어떤 커널을 삭제하더라도 이 커널은 반드시 유지되어야 합니다. apt autoremove는 Debian과 Ubuntu에서 일반적인 상황을 처리합니다. 커널은 자동으로 설치된 것으로 표시되며 현재 사용 중인 커널은 보호되기 때문입니다. 수동으로 설치한 커널이나 이미 /boot이 가득 차서 apt 명령 자체가 실행되지 않는 예외적인 상황은 Ubuntu에서 오래된 커널 정리하기에서 다룹니다.

월간 점검: 로그 증가와 systemd 저널

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug는 드라이 런(dry run)으로 아무것도 기록하지 않으므로 운영 중인 서버에서 실행해도 안전합니다. 로그 로테이션 규칙은 경로를 기준으로 일치 여부를 판단하므로 이 명령을 실행해 볼 가치가 있습니다. 업그레이드 과정에서 애플리케이션의 로그 위치가 변경되면 기존 규칙이 더 이상 적용되지 않으며, 해당 파일은 디스크가 가득 찰 때까지 무제한으로 커질 수 있습니다.

systemd 저널은 크기가 제한되어 있지만, 사용자가 지정한 절대 수치가 아닌 파일 시스템의 일정 비율을 기준으로 동작합니다. 특정 용량 제한을 설정하려면 /etc/systemd/journald.conf 파일에서 SystemMaxUse= 항목을 설정한 뒤 systemd-journald을 재시작하십시오. sudo journalctl --vacuum-time=14d은 즉시 공간을 확보하지만, 이는 정책이 아닌 일회성 작업이므로 설정 변경과 함께 수행해야 합니다.

릴리스별 관리: 계속 미루고 있는 재부팅

디스크에 업데이트된 커널 패키지가 있다고 해서 현재 실행 중인 커널이 바뀌지는 않습니다. 재부팅하기 전까지 서버는 여전히 이전 커널로 동작하며, 라이브 패치(live patching)를 사용할 수 있는 경우에도 수정 사항의 일부만 적용됩니다.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

해당 플래그 파일은 Debian 및 Ubuntu에서 패키지 스크립트가 생성하는 관례입니다. RHEL 계열 시스템은 이 파일을 생성하지 않으며, 동일한 질문에 대해서는 dnf-utils에서 제공하는 needs-restarting -r를 사용합니다. 최근 Ubuntu 서버 이미지에 기본으로 설치되는 needrestart은 커널보다 하위 수준의 문제를 해결합니다. 이 도구는 디스크에서 교체되었음에도 여전히 메모리에 매핑된 라이브러리를 사용하는 프로세스 목록을 보여줍니다. 패치된 OpenSSL이 적용되려면 해당 라이브러리를 사용하는 서비스를 재시작해야 하는 이유가 바로 여기에 있습니다.

재부팅을 피하지 말고 일정을 잡으십시오. /etc/apt/apt.conf.d/50unattended-upgrades를 사용하면 Unattended-Upgrade::Automatic-Reboot "true"; 및 Unattended-Upgrade::Automatic-Reboot-Time "03:00";를 통해 원하는 시간에 재부팅을 수행할 수 있습니다. 계획된 재부팅은 서버가 정상적으로 다시 시작되는지 확인할 수 있는 유일한 방법이기도 합니다. 잘못 설정된 fstab 항목이나 활성화하지 않은 서비스는 오직 부팅 시점에만 그 문제가 드러나기 때문입니다.

릴리스별 관리: 배포판 업그레이드 계획

Ubuntu LTS 릴리스는 5년의 표준 지원을 제공하며, 중간 릴리스는 9개월을 지원하므로 선택에 따라 향후 몇 년간의 업그레이드 작업량이 결정됩니다. 이러한 절충안에 대한 내용은 서버에서의 LTS와 중간 릴리스 비교를 참조하십시오.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade은 해당 파일을 읽고, Prompt=lts은 이를 LTS에서 LTS로의 이동으로 제한합니다. LTS에서 LTS로의 업그레이드 경로는 일반적으로 릴리스 당일이 아닌 새 버전의 첫 번째 포인트 릴리스가 나올 때 열립니다. 따라서 특정 날짜를 가정하여 계획을 세우기보다 시스템에서 실제로 어떤 버전을 제공하는지 확인해야 합니다. 업그레이드 절차에 대한 상세 내용은 Ubuntu 24.04에서 26.04로 업그레이드를 참조하십시오.

3개월의 여유 기간을 두고 계획하십시오. 복구 테스트를 마친 스냅샷을 생성하고, 타사 apt 저장소 목록을 기록해 두십시오(업그레이드 시 저장소가 비활성화되며, 각 저장소는 새 릴리스에 맞는 새로운 대상 경로가 필요합니다). 작업을 시작하기 전에 롤백 계획을 수립하십시오. 2026년 8월 기준으로 Ubuntu 24.04 LTS는 2029년 4월까지 표준 지원을 제공하므로, 이는 긴급 상황이 아닌 일정 관리의 문제입니다.

자동화할 작업과 수동으로 유지할 작업

보안 업데이트, 로그 로테이션, 인증서 갱신, 백업 작업 등 이미 결정을 내린 항목은 자동화하십시오. 알림 또한 자동화해야 합니다. 기억에 의존하는 점검은 새벽 2시에 실행되지 않기 때문입니다. Uptime Kuma를 이용한 자체 호스팅 상태 모니터링과 같은 외부 모니터링 도구는 서버 내부 스크립트가 보고할 수 없는 유일한 상황, 즉 서버 자체에 접근할 수 없는 상태를 감지합니다.

복구 테스트와 계정 감사는 수동으로 유지하십시오. 두 작업 모두 결과가 올바른지 판단할 사람이 필요합니다. 터미널보다 브라우저에서 시스템 상태를 확인하는 것을 선호한다면, 서버 관리를 위한 Cockpit과 Webmin 비교를 통해 두 가지 주요 웹 콘솔을 비교해 보십시오.

자동화 작업 자체에 대한 점검도 필요합니다. 이 목록의 첫 번째 주간 항목이 업데이트 도구 확인인 이유가 바로 이것입니다. 조용히 실패하는 자동화는 아예 없는 것보다 나쁩니다. 실패 사실을 인지할 기회와 점검하는 습관을 동시에 없애기 때문입니다.

한눈에 보는 전체 체크리스트

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

리눅스 서버 유지보수는 얼마나 자주 수행해야 합니까?

업데이트 상태, 디스크 및 inode 여유 공간, 실패한 유닛, 백업 작업 완료 여부 등 스스로 변하는 항목은 매주 확인합니다. 복구 테스트, 인증서 만료, 계정 및 SSH 키 감사, 오래된 커널, 로그 증가와 같이 서서히 진행되는 문제는 매달 점검합니다. 배포판 릴리스마다 버전 업그레이드를 수행하고 최신 커널로 재부팅합니다. 정상적인 서버라면 매주 점검하는 데 몇 분밖에 걸리지 않으며, 문제가 발생한 뒤가 아니라 매주 점검하는 목적이 바로 여기에 있습니다.

백업 작업이 성공했다고 보고하는데도 왜 복구 테스트를 해야 합니까?

백업 작업은 자신의 종료 상태만을 보고하기 때문입니다. 아카이브가 쓸모없는 상태여도 종료 상태는 성공(true)일 수 있습니다. set -o pipefail 없이 압축기로 파이프된 덤프는 압축기의 상태를 반환합니다. 따라서 오류 메시지만 생성하고 실패한 덤프도 종료 코드는 0을 반환하며 작은 파일을 생성합니다. 다른 머신에 복구하여 데이터를 열고 내용을 확인해야 합니다. 복구 테스트는 시간도 측정하며, 그 소요 시간이 실제 복구 시간(RTO)이 됩니다.

커널 업데이트를 할 때마다 재부팅해야 합니까?

새 커널이 실행 중인 커널이 되려면 재부팅해야 합니다. Debian과 Ubuntu에서는 /var/run/reboot-required 파일의 존재 여부로 패키지가 재부팅을 요청했는지 알 수 있으며, /var/run/reboot-required.pkgs 명령으로 해당 패키지를 확인할 수 있습니다. RHEL 계열에는 해당 파일이 없으며, dnf-utils 패키지의 needs-restarting -r 명령으로 같은 정보를 확인할 수 있습니다. 재부팅을 무기한 미루지 말고 /etc/apt/apt.conf.d/50unattended-upgrades에 자동 재부팅 시간을 설정하십시오. 1년 동안 재부팅하지 않은 머신은 커널이 오래되었을 뿐만 아니라 부팅 경로조차 검증되지 않은 상태이기 때문입니다.

이 점검 항목 중 무엇을 자동화해도 안전합니까?

보안 업데이트, 로그 로테이션, 인증서 갱신, 예약된 백업과 같이 이미 결정된 작업은 자동화하십시오. 실패한 유닛이나 디스크 용량 부족을 사람이 명령어를 입력하지 않아도 알 수 있도록 알림도 자동화합니다. 복구 테스트와 키 감사는 사람이 직접 결과가 올바른지 판단해야 하므로 수동으로 유지하십시오. 마지막으로 자동화 자체에 대한 점검을 추가하십시오. 업데이트 실패는 아무런 알림 없이 조용히 발생할 수 있으며, 이는 정상 작동하는 것처럼 보이기 때문입니다.