리눅스(Linux) 환경에서 웹 서버나 데이터베이스를 운영하다 보면 어느 날 갑자기 서비스가 먹통이 되거나 데이터 저장 및 로그 기록이 중단되는 치명적인 장애를 마주하게 됩니다. 이때 시스템 로그나 에디터에서 흔히 발견되는 에러 메시지가 바로 ‘No space left on device’입니다. 말 그대로 서버의 하드디스크 디스크 용량이 100% 가득 차서 더 이상 단 1바이트의 데이터도 쓸 수 없는 디스크 풀(Disk Full) 장애 상태에 직면한 것입니다.
디스크가 가득 차면 시스템의 임시 파일 생성이나 백엔드 프로그램의 로그 쓰기가 모두 불가능해지기 때문에 전체 인프라가 마비됩니다. 이 문제를 신속하게 해결하기 위해서는 어떤 디렉터리에서 용량을 많이 잡아먹고 있는지 정확하게 원인을 파악하고 찌꺼기 파일을 정리해야 합니다. 본 가이드에서는 리눅스 디스크 상태를 점검하는 핵심 명령어인 df와 du의 사용법을 익히고, 실무에서 디스크 풀 장애를 해결하는 단계를 상세히 정리합니다.
1. 전체 디스크 상태 파악의 첫걸음: df 명령어
디스크 용량 부족 경고를 확인했다면 가장 먼저 서버 전체의 파티션별 남은 용량을 직관적으로 파악해야 합니다. 이때 사용하는 명령어가 바로 ‘Disk Free’의 줄임말인 df 명령어입니다.
실무 필수 옵션: df -h
단순히 df만 터미널에 입력하면 파일 시스템의 용량이 1KB 블록 단위의 거대한 숫자로 출력되기 때문에 사람이 한눈에 크기를 식별하기 어렵습니다. 따라서 실무에서는 항상 사람이 읽기 쉬운 단위인 메가바이트(M), 기가바이트(G)로 자동 변환하여 보여주는 -h(Human-readable) 옵션을 붙여서 사용합니다.
Bash
df -h
명령어를 실행하면 출력되는 결과 항목들은 다음과 같은 의미를 가집니다.
- Filesystem: 리눅스 시스템에 마운트된 실제 물리 하드디스크 장치나 가상 파티션의 경로를 나타냅니다. (예:
/dev/xvda1,/dev/sda1) - Size: 해당 파티션의 전체 총 용량입니다.
- Used: 현재 시스템에서 사용 중인 용량입니다.
- Avail: 아직 사용 가능한 실제 남은 용량입니다. 디스크 풀 장애가 발생했다면 이 항목이 0에 가깝게 표시됩니다.
- Use%: 전체 용량 대비 사용량의 백분율입니다. 장애 상황에서는 이 부분이
100%로 빨갛게 채워져 있는 것을 볼 수 있습니다. - Mounted on: 해당 파일 시스템이 리눅스 내부의 어떤 디렉터리 경로와 연결되어 있는지 보여줍니다. 대개 루트 경로인
/에 마운트된 영역의 Use%가 100%인 경우가 많습니다.
2. 범인 파일 검거를 위한 디렉터리별 용량 추적: du 명령어
df -h 명령어를 통해 특정 파티션(예: 루트 /)이 가득 찬 것을 확인했다면, 이제 그 파티션 내부의 수많은 폴더 중 ‘실제로 어떤 폴더와 파일이 용량을 무식하게 차지하고 있는지’ 좁혀 들어가야 합니다. 이때 사용하는 파일 및 디렉터리 용량 확인 명령어가 ‘Disk Usage’의 줄임말인 du 명령어입니다.
실무에서 용량 큰 폴더를 찾는 마법의 명령어 조합
단순히 du만 치면 하위 폴더의 모든 파일 경로를 줄줄이 출력하므로 터미널 화면이 마비됩니다. 실무에서는 보통 다음과 같은 옵션 조합을 사용하여 가장 무거운 상위 폴더들을 추려냅니다.
Bash
sudo du -h --max-depth=1 / | sort -hr
이 명령어 한 줄에는 디스크 추적을 위한 엄청난 노하우가 집약되어 있습니다. 각 옵션의 의미를 쪼개어 분석해 보면 다음과 같습니다.
sudo: 리눅스 시스템 내의 시스템 보호 폴더나 타 유저의 폴더 용량까지 에러 없이 완벽하게 계산하기 위해 최고 관리자 권한으로 실행합니다.-h: du 명령어 역시 사람이 보기 편하게 기가(G), 메가(M) 단위로 출력하도록 지정합니다.--max-depth=1: 탐색할 하위 디렉터리의 깊이를 딱 1단계로 제한합니다. 지정한 경로(여기서는 루트/) 바로 밑에 있는 1차 자식 폴더들의 누적 용량 합계만 깔끔하게 끊어서 보여주므로 가독성이 극대화됩니다.sort -hr: du가 계산한 결과를 파이프(|) 라인을 통해 정렬 명령어인sort로 넘깁니다.-h옵션은 용량 단위를 인식하게 만들고,-r(reverse)옵션은 내림차순(큰 것부터 작은 순서로) 정렬을 수행합니다.
위 명령어를 실행하면 /var 또는 /log, /home 등 대용량 데이터를 담고 있는 폴더가 맨 상단에 기가바이트(GB) 단위로 선명하게 찍히게 됩니다. 범인이 된 폴더를 찾았다면 해당 경로 안으로 들어가서 경로를 좁혀가며 동일한 명령어를 반복 실행하면 됩니다. (예: sudo du -h --max-depth=1 /var | sort -hr)
3. 디스크 풀 장애의 주요 원인과 안전한 해결 단계
용량을 대거 점유하고 있는 파일의 최종 경로에 도달했다면 대개 다음 3가지 원인 중 하나에 해당합니다. 원인별로 안전하게 디스크 공간을 확보하는 트래픽 조치법입니다.
원인 1: 끝없이 쌓인 톰캣, Nginx, 가상 머신 로그 파일 (.log)
시스템이나 어플리케이션이 구동되면서 누적된 로그 파일이 수십 기가바이트를 차지하는 경우가 가장 흔합니다.
- 안전한 조치법: 무작정
rm명령어로 로그 파일을 지워버리면, 현재 해당 파일을 붙잡고 쓰기 작업을 하던 프로세스(Nginx 등)가 파일 디스크립터를 놓지 않아 디스크 용량이 반환되지 않는 유령 용량 현상이 발생할 수 있습니다. 따라서 아래와 같이 파일 내부 내용만 깔끔하게 비워버리는 방식을 권장합니다.
Bash
sudo cat /dev/null > /var/log/nginx/access.log
이렇게 하면 파일 형태와 권한은 유지되면서 알맹이 용량만 즉시 0바이트로 초기화됩니다.
원인 2: 도커 유령 컨테이너 및 쓰지 않는 가상 이미지 누적
도커 컨테이너를 자주 껐다 켜거나 빌드를 반복하면 빌드 캐시와 찌꺼기 볼륨 데이터가 /var/lib/docker 아래에 엄청나게 쌓이게 됩니다.
- 안전한 조치법: 도커 시스템이 제공하는 일괄 청소 명령어를 활용하면 현재 구동 중이지 않은 모든 유령 자원을 안전하게 날려 디스크를 확보할 수 있습니다.
Bash
docker system prune -a --volumes
원인 3: 사용하지 않는 구형 패키지 및 임시 파일 백업본
패키지를 업데이트하면서 남은 아카이브 파일이나 임시 폴더(/tmp)의 잔재들입니다.
- 안전한 조치법: 아래 명령어를 통해 우분투 APT 매니저가 임시로 보관하던 캐시 파일들을 깨끗하게 정리합니다.
Bash
sudo apt-get clean
sudo apt-get autoremove
결론: 사후 약방문 방지를 위한 디스크 모니터링 체계 구축
디스크 100% 풀 장애는 예고 없이 찾아와 전체 서비스를 다운시키는 악성 인프라 장애입니다. 오늘 배운 df -h 명령어로 주기적으로 서버 파일 시스템 잔여량을 체크하고, 위급 상황 발생 시 du -h --max-depth=1 | sort -hr 마법의 명령어로 범인 폴더를 추적하는 법을 숙지해 둔다면 장애 복구 시간을 획기적으로 단축할 수 있습니다.
장기적으로는 디스크 사용량이 80% 또는 90%를 돌파했을 때 시스템 관리자의 이메일이나 슬랙(Slack) 메시지로 경고 알림을 보내주는 모니터링 자동화 스크립트나 모니터링 도구(Prometheus, Grafana 등)를 연동하여, 사전에 인프라 용량을 증설하거나 로그를 로테이션(Logrotate)해 주는 선제적인 방어 체계를 구축해 보시기 바랍니다.