새벽에 모니터링 알림이 울립니다. “/ 파티션 사용량 91%“. 서버에 접속해서 df -h를 쳐보면 정말로 빨간불이 들어와 있고, 그런데 정작 “뭐가 이렇게 찼지?”부터 막히죠. 저도 이런 상황을 여러 번 겪으면서 나름의 순서를 만들어 뒀는데요, 오늘은 Ubuntu 24.04 LTS나 Rocky/Debian 계열 서버 기준으로 du와 ncdu를 써서 원인 파일을 5분 안에 찾아내고 안전하게 정리하는 흐름을 정리해 볼게요. 당황해서 아무 파일이나 지우다 서비스 죽이는 일만은 피해야 하니까요.
1단계: 어디가 찼는지 “파티션 단위”부터 좁히기
제일 먼저 할 일은 무작정 du를 돌리는 게 아니라, 어느 마운트 지점이 문제인지 확인하는 거예요. 루트가 찬 건지, /var가 별도 파티션인데 거기가 찬 건지에 따라 뒤지는 경로가 완전히 달라집니다.
- df -hT — 파일시스템 타입까지 함께 보여줍니다. tmpfs, overlay 같은 건 대체로 무시해도 돼요.
- df -h / — 특정 경로가 속한 파티션만 콕 집어 확인.
- df -i — 용량은 여유 있는데 “No space left on device”가 뜬다면 inode 고갈입니다. 작은 파일 수백만 개가 쌓인 세션 디렉터리, 메일 큐, 캐시 폴더를 의심하세요.
여기서 IUse%가 100%에 가깝다면 이건 용량 문제가 아니라 파일 “개수” 문제예요. 이 경우엔 아래에서 소개할 ncdu를 -c 옵션(파일 개수 표시)으로 돌리는 게 훨씬 빠릅니다.
2단계: du로 위에서 아래로 파고들기
du는 어디에나 기본으로 깔려 있다는 게 최대 장점이에요. 패키지 설치조차 안 되는 꽉 찬 서버에서도 쓸 수 있죠. 핵심은 한 번에 다 뒤지지 말고 한 층씩 내려가는 것입니다.
- du -xh –max-depth=1 / | sort -rh | head -20 — 루트 바로 아래 1단계 디렉터리 용량을 큰 순서로 20개. 여기서 -x가 정말 중요한데, 다른 파일시스템(NFS 마운트, /proc, 도커 오버레이 등)으로 넘어가지 않게 막아줍니다. 이거 없으면 네트워크 마운트를 타고 들어가서 몇 십 분씩 멈춰 있어요.
- du -xh –max-depth=1 /var | sort -rh | head — 보통 범인은 /var에 있습니다. 그다음은 /home, /opt, /tmp 순서로 내려가면 돼요.
- du -sh /var/log/* — 특정 디렉터리 안 항목별 합계만 간단히.
- du -ah /var/log | sort -rh | head -30 — 디렉터리가 아니라 개별 파일까지 포함해 크기순 정렬.
표준 에러가 지저분하게 쏟아진다면 뒤에 2>/dev/null을 붙이세요. 권한 없는 경로는 어차피 못 읽으니까요. 다만 정확한 총량이 필요하면 sudo로 돌리는 게 맞습니다.
큰 파일만 콕 집어 찾고 싶을 때는 find가 더 직관적이에요.
- find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null — 500MB 넘는 파일만.
- find /var/log -type f -mtime +30 -size +50M — 30일 이상 손 안 댄 오래된 큰 로그.
3단계: ncdu로 눈으로 보면서 정리하기
du 결과를 눈으로 읽는 게 슬슬 답답해지면 ncdu가 답입니다. 터미널에서 방향키로 디렉터리를 드나들며 용량 막대그래프를 보고, 그 자리에서 삭제까지 할 수 있는 도구예요. 요즘 배포판에 들어 있는 건 Zig로 다시 쓰인 ncdu 2.x 버전이라 속도도 훨씬 빠르고 컬러 UI도 깔끔합니다.
- 설치: sudo apt install ncdu (Debian/Ubuntu) 또는 sudo dnf install ncdu (RHEL 계열, EPEL 필요할 수 있어요).
- ncdu -x / — 루트만 스캔. -x는 여기서도 필수라고 생각하세요.
- ncdu -x –exclude /proc –exclude /sys / — 굳이 제외하고 싶은 경로 지정.
- ncdu -o scan.json -x / 로 결과를 파일로 저장해 두고, 나중에 ncdu -f scan.json 으로 부하 없이 다시 열어볼 수 있어요. 운영 시간대에 재스캔 돌리기 부담될 때 정말 유용합니다.
실행 후 화면에서 자주 쓰는 키는 이 정도예요.
- 방향키 / Enter: 디렉터리 진입, 좌측 화살표로 상위 이동
- n / s / C: 이름순 / 크기순 / 파일 개수순 정렬 (inode 문제일 때 C가 구세주)
- d: 선택 항목 삭제 (확인 프롬프트가 뜨니 침착하게 읽고 누르세요)
- g: 퍼센트·그래프 표시 토글, a: 실제 디스크 점유량과 논리 크기 전환
- i: 항목 상세 정보, q: 종료
참고로 SSH 세션이 끊기면 스캔이 날아가니, 파일이 아주 많은 서버라면 tmux 안에서 돌리는 걸 추천해요.
4단계: 자주 나오는 범인 TOP 5와 안전한 처리법
경험상 90% 알림의 원인은 거의 이 다섯 가지 안에서 나옵니다.
- systemd 저널 로그: /var/log/journal이 수 GB씩 먹고 있으면 journalctl –disk-usage로 확인 후 sudo journalctl –vacuum-size=500M 또는 –vacuum-time=7d로 줄입니다. 근본 해결은 /etc/systemd/journald.conf의 SystemMaxUse 설정이에요.
- 애플리케이션 로그: nginx access.log, 앱 로그가 로테이션 없이 커진 경우. 절대 rm으로 지우지 마세요. 프로세스가 파일 핸들을 잡고 있어서 용량이 안 돌아옵니다. truncate -s 0 /var/log/앱.log로 비운 뒤 logrotate 설정을 잡아주는 게 정석입니다.
- 도커: docker system df로 이미지·볼륨·빌드 캐시 용량을 보고, docker system prune -a로 정리합니다. 볼륨까지 지우는 –volumes는 데이터 날아갈 수 있으니 꼭 내용 확인하고 쓰세요.
- 패키지 캐시: sudo apt clean / sudo dnf clean all, 그리고 sudo apt autoremove –purge로 안 쓰는 커널 정리. 오래된 커널 여러 개가 /boot를 채우는 것도 흔한 케이스죠.
- 지워졌지만 열려 있는 파일: du 총합과 df 수치가 안 맞으면 이걸 의심하세요. sudo lsof +L1 또는 sudo lsof | grep deleted로 확인하고, 해당 프로세스를 재시작하면 용량이 한꺼번에 반환됩니다.
다시 안 겪으려면
불 끄고 나면 예방이 남습니다. logrotate 설정 점검, journald의 SystemMaxUse 지정, 도커 데몬의 로그 드라이버에 max-size·max-file 옵션 추가, 그리고 디스크 사용량 80% 임계값 알림을 걸어두는 것. 여기에 ncdu -o로 주기적인 스냅샷을 남겨두면, 다음에 용량이 튀었을 때 “언제부터, 어느 디렉터리가” 늘었는지 비교가 됩니다.
정리하면 df로 파티션 좁히기 → du로 층별 하강 → ncdu로 시각 확인 → 원인별 안전 정리 순서예요. 이 흐름만 몸에 익혀두면 새벽 알림도 그렇게 무섭지 않답니다.