평화롭게 잘 돌아가던 웹 서비스나 데이터베이스가 갑자기 다운되어 접속이 불가능해진 경험이 있으신가요? 에러 로그를 확인하려고 해도 터미널 창에 **”No space left on device”**라는 절망적인 문구만 출력된다면, 이는 리눅스 서버의 하드디스크(스토리지) 용량이 100% 꽉 찼음을 의미합니다.
디스크 용량이 부족해지면 새로운 데이터를 쓸 수 없는 것은 물론이고, 기존의 데이터베이스(MySQL, MariaDB 등)가 멈춰버리며 서버의 핵심 프로세스들이 연쇄적으로 다운되는 치명적인 장애가 발생합니다. 이번 포스팅에서는 구글 애드센스 승인을 위한 전문 기술 지식으로서, 리눅스 서버 용량이 100%가 되었을 때 원인을 파악하고 안전하게 로그 파일을 삭제하여 여유 공간을 확보하는 트러블슈팅(Troubleshooting) 과정을 단계별로 완벽하게 정리해 보겠습니다.
1. 골든 타임 확보! 현재 디스크 사용량 확인하기 (df 명령어)
서버가 멈췄다면 가장 먼저 전체 디스크의 어디가 얼마나 꽉 찼는지 큰 그림을 확인해야 합니다. 이때 사용하는 명령어가 바로 df입니다.
[적용 방법]
Bash
df -h
- 명령어 해석:
df(Disk Free)는 디스크의 남은 용량을 확인하는 명령어이며,-h(human-readable) 옵션을 주면 우리가 읽기 편한 메가바이트(MB)나 기가바이트(GB) 단위로 환산해서 보여줍니다. - 확인 포인트: 출력된 결과물 중에서
Use%항목이 100%를 가리키는 마운트 포인트(보통/또는/var)를 찾습니다. 이곳이 바로 범인들이 서식하는 공간입니다.
2. 범인 찾기: 용량을 가장 많이 차지하는 디렉토리 추적 (du 명령어)
어느 파티션이 가득 찼는지 알았다면, 이제 그 파티션 내부로 들어가 어떤 파일이나 폴더가 비정상적으로 뚱뚱해졌는지 찾아내야 합니다.
[적용 방법] 가장 용량을 많이 차지하는 파일들은 보통 /var/log (시스템 로그)나, /home (사용자 데이터), 또는 웹 서버의 폴더 안에 숨어 있습니다. 범인 추적을 위해 최상위 경로(/)나 /var 경로로 이동한 뒤 아래 명령어를 입력합니다.
Bash
cd /var
du -sh *
- 명령어 해석:
du(Disk Usage)는 특정 디렉토리의 사용량을 보여줍니다.-s(요약)와-h(읽기 쉬운 단위) 옵션을 줘서 현재 폴더 안의 항목별 용량을 파악합니다.
[고급 팁: 용량 큰 순서대로 정렬하기] 수많은 폴더 중에서 용량이 큰 순서대로 한눈에 보고 싶다면 아래 명령어를 사용하세요.
Bash
du -ah -d 1 | sort -hr
이 명령어를 통해 비정상적으로 기가바이트(GB) 단위의 용량을 차지하고 있는 .log 파일이나 더미 파일을 찾아낼 수 있습니다.
3. 초보자 주의! 안전하게 로그 파일 비우기 (무조건 rm을 쓰면 안 되는 이유)
디스크 용량을 차지하는 주범을 찾았다고 해서, 무턱대고 rm -rf error.log 명령어로 파일을 삭제해 버리면 아주 위험합니다.
웹 서버(Nginx, Apache)나 DB 등 **현재 실행 중인 프로세스가 해당 로그 파일을 쥐고(Open file) 글을 쓰고 있는 상태에서 파일을 강제 삭제하면, 파일 이름만 사라질 뿐 디스크 공간은 환원되지 않는 일명 ‘고스트(Ghost) 현상’**이 발생합니다. 결국 용량은 100% 그대로인데 파일만 사라져버리는 최악의 상황이 됩니다.
[올바른 로그 파일 삭제(비우기) 방법] 파일 자체를 지우는 것이 아니라, 파일은 그대로 둔 채 안의 ‘내용물’만 0바이트로 텅 비워버려야 프로세스 충돌 없이 디스크 공간을 즉각 확보할 수 있습니다.
Bash
cat /dev/null > /var/log/nginx/error.log
# 또는 더 짧게
> /var/log/nginx/error.log
위 명령어를 입력하면 error.log 파일의 크기가 즉시 0 바이트(Empty)로 변하면서, 꽉 찼던 디스크 공간이 마법처럼 쑥 내려가는 것을 확인할 수 있습니다.
[오래된 로그 파일 한 번에 정리하기] 현재 쓰고 있는 로그가 아니라, 며칠 전에 생성되어 이미 압축된 .gz 형태의 로그나 30일이 지난 과거의 로그 파일들은 rm 명령어로 삭제해도 무방합니다.
Bash
find /var/log -type f -name "*.log" -mtime +30 -exec rm -f {} \;
이 명령어는 /var/log 디렉토리 내에서 이름이 .log로 끝나고, 생성된 지 30일(+30)이 지난 파일만 찾아 강제로 삭제(rm -f)해 주는 강력한 명령어입니다.
4. 근본적인 해결책: 로그 로테이트(Logrotate) 설정하기
매번 용량이 꽉 찰 때마다 수동으로 로그를 지우는 것은 매우 비효율적입니다. 실무 서버 관리에서는 **’로그 로테이트(Logrotate)’**라는 리눅스 기본 데몬을 활용하여 이 과정을 완전히 자동화합니다.
Logrotate는 특정 주기가 되거나 로그 파일이 특정 용량에 도달하면, 기존 로그 파일을 압축해서 백업 파일로 분리하고 새로운 빈 로그 파일을 만들어줍니다. 또한 오래된 백업 파일은 자동으로 삭제하여 디스크 용량이 무한정 늘어나는 것을 막아줍니다.
/etc/logrotate.conf파일이나/etc/logrotate.d/디렉토리 내의 설정 파일을 열어, Nginx나 Tomcat 등의 로그가 하루 단위(daily)로 잘리는지, 보관 기간(rotate)은 적절한지(예: 7~14일) 반드시 체크하고 설정해 주어야 합니다.
결론: 안정적인 서버 운영의 첫걸음, 디스크 모니터링
“No space left on device” 에러는 겪어보면 아찔하지만, 대처법만 정확히 알고 있다면 5분 만에 해결할 수 있는 장애이기도 합니다.
오늘 배운 df -h로 전체 용량을 파악하고, du -sh *로 범인을 찾은 뒤, > 파일명으로 안전하게 로그를 비워내는 3단계 공식을 꼭 기억해 두시기 바랍니다. 나아가 Zabbix나 AWS CloudWatch 같은 모니터링 툴을 이용해 디스크 용량이 80%를 넘을 때 슬랙(Slack)이나 이메일로 알람이 오도록 세팅해 둔다면, 당신은 이미 초보를 벗어난 훌륭한 서버 관리자입니다.
