지난 회차에서 우리는 시스템 자원을 비정상적으로 좀먹는 폭주 프로세스와 메모리 테이블을 오염시키는 좀비 프로세스를 커널 시그널을 이용해 안전하고 확실하게 격리하는 kill, killall, pkill 기술에 대해 알아보았습니다. 이제 프로세스를 통제하는 법을 완벽히 익혔으니, 연재의 전반부를 마무리하며 이 모든 프로그램이 발을 딛고 있는 물리적 기반인 '시스템 자원 및 스토리지 점검 기술'을 마스터할 차례입니다.
리눅스 서버 운영 중 발생하는 장애의 상당수는 알고 보면 매우 단순한 원인에서 비롯됩니다. 하드디스크 공간이 100% 가득 차서 로그를 더 이상 쓰지 못해 웹 서버가 다운되거나, 램(RAM) 용량이 한계에 도달해 커널이 중요한 프로세스를 강제로 죽여버리는(OOM Killer 작동) 현상이 대표적입니다.
인프라의 한계점을 미리 파악하고 장애를 예방하기 위해서는 디스크와 메모리의 상태를 정확한 단위로 측정할 수 있어야 합니다. 이번 10회차에서는 스토리지와 자원 점검의 3대 필수 명령어인 df, du, free의 메커니션을 실무 트러블슈팅 예제와 함께 상세히 살펴보겠습니다.
df(Disk Free) 명령어는 파일 시스템 전체의 총용량, 사용 중인 공간, 남은 공간, 사용 비율 및 마운트 지점(Mount Point) 정보를 일목요연하게 보여주는 마스터 스캐너입니다. 서버에 장애 징후가 보일 때 가장 먼저 디스크의 거시적인 상태를 진단하는 도구입니다.
-h와 -i-h (Human-readable): 기가바이트(G), 메가바이트(M) 등 사람이 직관적으로 이해할 수 있는 단위로 변환하여 출력합니다. 이 옵션이 없으면 블록 단위의 긴 숫자가 출력되어 가독성이 떨어집니다.
-i (Inodes): 순수 용량이 아닌 파일 시스템의 아이노드(Inode) 사용량을 출력합니다. 리눅스 보안과 안정성 측면에서 매우 중요한 옵션입니다.
df -h)Bash
df -h
위 명령어를 실행하면 다음과 같이 마운트된 모든 파티션의 용량 정보가 덤프됩니다.
Plaintext
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/nvme0n1p1 50G 44G 6.0G 88% /
/dev/nvme0n1p2 2.0G 200M 1.8G 10% /boot
해석: 루트 파티션(/)의 사용률(Use%)이 현재 88%에 도달하여 임계치 경고 수준에 진입했음을 직관적으로 파악할 수 있습니다. 95%를 넘기 전에 대용량 불필요 파일을 찾아 정리해야 합니다.
df -i)리눅스 파일 시스템은 파일 하나당 하나의 '고유 인덱스 번호(Inode)'를 할당합니다. 디스크의 물리적 용량이 몇 백 기가바이트씩 넉넉하게 남아있더라도, 수바이트짜리 미세한 임시 파일이나 세션 파일이 수천만 개 생성되어 파일 시스템에 할당된 Inode 숫자가 100% 가득 차면, 시스템은 "디스크 공간 부족(No space left on device)" 에러를 뿜으며 일체의 쓰기 작업을 중단합니다.
Bash
df -i
# 출력 결과 예시:
# Filesystem Inodes IUsed IFree IUse% Mounted on
# /dev/nvme0n1p1 3276800 3276800 0 100% /
만약 위와 같이 IUse%가 100%라면 용량 여부와 상관없이 심각한 장애 상태입니다. 이 경우 세션 디렉토리나 임시 메일 큐를 뒤져 쓸모없는 파일 수백만 개를 지워주어야 정상화됩니다.
df 명령어를 통해 어떤 파티션이 가득 찼는지 확인했다면, 그다지 넓지 않은 디스크 공간을 실제로 차지하고 있는 '용량 먹는 하마 디렉토리'가 어디인지 구체적으로 찾아내야 합니다. 이때 사용하는 파일 핀포인트 추적 도구가 du(Disk Usage)입니다.
-sh와 정렬 연계-s (Summarize): 지정한 디렉토리 내부의 무수한 하위 파일 용량을 일일이 나열하지 않고, 해당 디렉토리 전체의 합산 요약 용량 딱 한 줄만 인쇄합니다.
-h (Human-readable): 단위를 보기 좋게 포맷팅합니다.
루트 파티션이 가득 차서 상위 디렉토리부터 하위로 내려가며 용량을 대량 소비하는 폴더를 단계별로 색출해 나가는 실무 엔지니어의 표준 탐색 절차입니다.
Bash
# 1. 루트(/) 하위의 1단계 디렉토리들의 총용량을 한눈에 요약 비교
sudo du -sh /* 2>/dev/null
# 출력 예시 중 /var 디렉토리가 35G를 차지하여 압도적인 원인으로 지목됨
# 2. 범인으로 지목된 /var 디렉토리 내부로 진입하여 범위를 좁힘
sudo du -sh /var/* 2>/dev/null
# 출력 예시 중 /var/log 폴더가 30G를 차지함이 확인됨
# 3. /var/log 내부에서 용량이 가장 큰 상위 5개 파일/폴더를 크기순으로 정렬하여 식별
sudo du -ah /var/log 2>/dev/null | sort -rh | head -n 5
# 출력 결과:
# 28G /var/log/nginx/access.log
# 1.5G /var/log/messages
이 정밀 추적 과정을 통해 순식간에 디스크를 마비시킨 원인이 백업 정책이 누락된 nginx/access.log 파일임을 완벽히 밝혀낼 수 있습니다.
디스크 스토리지가 파일의 영구 저장소라면, 메모리는 프로세스들이 활발히 연산을 수행하는 런타임 운동장입니다. free 명령어는 시스템의 총 물리 메모리(RAM) 용량과 사용량, 그리고 물리 메모리가 고갈되었을 때 하드디스크의 일부를 메모리처럼 끌어다 쓰는 스왑(Swap) 공간의 상태를 실시간으로 출력합니다.
-m, -g와 -h용량 단위를 메가바이트(-m), 기가바이트(-g)로 고정하거나 가독성 모드(-h)로 지정해 모니터링합니다.
free -h)Bash
free -h
위 명령어를 실행하면 다음과 같은 정형화된 메모리 매트릭스 테이블이 인쇄됩니다.
Plaintext
total used free shared buff/cache available
Mem: 7.7Gi 4.2Gi 300Mi 120Mi 3.2Gi 3.1Gi
Swap: 2.0Gi 500Mi 1.5Gi
많은 초보 관리자들이 하단의 free 열에 표기된 숫자(300Mi)만 보고 "우리 서버 램이 300메가밖에 안 남아서 곧 다운되겠다!"며 패닉에 빠지곤 합니다. 이는 리눅스 커널의 고도화된 메모리 관리 아키텍처를 이해하지 못해 발생하는 오해입니다.
used (4.2Gi): 현재 애플리케이션과 커널이 순수하게 점유하여 사용 중인 활성 메모리입니다.
buff/cache (3.2Gi): 리눅스 성능 최적화의 핵심입니다. 커널은 디스크 I/O 속도를 높이기 위해, 남는 메모리를 그대로 놀려두지 않고 최근에 읽었던 파일 데이터와 버퍼를 이 공간에 임시로 캐싱해 둡니다. 이 공간은 시스템에 메모리가 부족해지면 커널이 즉각 가차 없이 비워내어 애플리케이션에 할당해 주므로, 사실상 남은 것이나 다름없는 안전지대입니다.
available (3.1Gi): 가장 중요하게 보아야 하는 지표입니다. free 수치와 상관없이, 시스템 내부적으로 새로운 프로세스가 구동될 때 커널이 buff/cache를 회수하는 등 모든 수단을 동원해 최종적으로 즉시 쥐어줄 수 있는 순수 여유 메모리의 실질적 총량을 뜻합니다. 따라서 가용성 판단 시에는 오직 available 필드만 보면 됩니다. 이 수치가 수십 메가바이트 이하로 떨어지면 램 증설이나 프로세스 격리가 시급한 상황입니다.
디스크 알림 자동화(Crontab 연계):
매번 수동으로 df -h를 칠 수 없으므로, 뒤에서 배울 스케줄러를 활용해 df 사용률이 90%를 초과하면 관리자 이메일이나 메신저로 경고 봇 알림을 보내도록 모니터링 파이프라인을 구축해야 합니다.
로그 로테이트(Logrotate) 강제:
du 명령어로 대용량 로그 폭주 범인을 매번 수동으로 지우는 것은 임시방편입니다. /etc/logrotate.conf 설정을 통해 날짜별로 로그를 압축 분할하고, 30일이 지난 로그는 자동으로 소멸하도록 시스템 정책을 강제 적용해야 디스크 100% 장애를 근본적으로 막을 수 있습니다.
리눅스 서버 인프라의 연속성을 보장하고 급작스러운 서비스 다운 타임을 방지하기 위해서는 하드웨어 자원의 상태를 명확히 측정하고 분석할 줄 알아야 합니다.
시스템 전체 파티션 용량과 파일 생성 인덱스 한계를 거시적으로 스캔할 때는 df -h와 df -i를 실행하고,
특정 경로 내부에서 비정상적으로 디스크 공간을 독점 중인 대용량 폴더를 좁혀가며 색출할 때는 du -sh와 정렬 명령을 조합하며,
시스템의 심장인 메모리 자원의 건전성을 진단할 때는 단순 free 수치에 속지 말고 실질적 유효 여유량인 available 필드를 핵심 지표로 삼아 모니터링해야 합니다.
이 자원 점검 명령어 3총사를 완벽히 숙지하고 자원 소비의 병목 메커니즘을 꿰뚫어 볼 때, 인프라의 안정성을 극한으로 끌어올리는 노련한 시스템 아키텍트이자 엔지니어로 자리매김할 수 있습니다.
이것으로 리눅스 시스템 제어와 자원 관리의 기본기를 다룬 전반부 10회 연재를 마칩니다. 다음 11회차부터는 연재의 후반부 단계로 진입하여, 시스템 파일의 무결성을 검증하고 네트워크와 보안 채널을 통제하며 업무를 자동화하는 고난도 실무 엔지니어링 기술의 세계를 하나씩 파헤쳐 보겠습니다. 첫 시작은 파일 시스템 깊숙이 숨겨진 대상을 정교한 조건으로 추적하는 '파일 시스템 검색과 무결성 검증(find, locate)' 기술입니다.