No space left on device가 나오는데 df -h에 여유가 있다면 실패한 경로의 파일시스템을 기준으로 df -i도 확인하세요. 데이터 블록과 inode 여유는 다른 정보입니다. 홈 디렉터리의 여유 공간을 보고 다른 마운트나 컨테이너의 저장 경로도 괜찮다고 판단하면 원인을 놓칠 수 있습니다.
원인: 용량 수치 하나가 모든 자원을 뜻하지 않는다
파일시스템은 파일 내용뿐 아니라 파일을 관리하는 정보도 필요합니다. 작은 파일이 많이 쌓이면 총 바이트만으로는 상태를 설명하기 어려울 수 있습니다. 또한 /tmp, 데이터 볼륨, 컨테이너 저장 경로가 서로 다른 파일시스템일 수 있습니다. 오류가 난 정확한 경로와 실행 환경을 먼저 적어야 합니다.
| 관찰 | 다음 확인 | 주의 |
| 블록 여유 있음 | 같은 경로 df -i | 다른 마운트 혼동 |
| inode 여유 없음 | 생성 서비스·보존 | 무차별 삭제 금지 |
| 둘 다 여유 있음 | 경로·할당량·오류 | inode로 단정 금지 |
| 정리 후 수치 개선 | 실제 쓰기 성공 | 수치와 업무 분리 |
1. 실패 경로의 기존 상위 디렉터리를 지정한다
아래 /path/to/existing-dir는 오류가 발생한 파일의 실제 존재하는 상위 디렉터리로 바꿉니다. 파일 생성이 실패해 대상 파일이 없다면 파일명 자체보다 존재하는 디렉터리를 사용하세요. 두 명령은 같은 경로를 조사해야 비교가 됩니다.
df -h /path/to/existing-dir
df -i /path/to/existing-dir
첫 결과에서는 대상 파일시스템과 사용 가능 블록을, 두 번째에서는 inode 사용량과 남은 수를 확인합니다. 표시가 제한되거나 해당 파일시스템에서 해석이 다른 경우에는 해당 파일시스템의 공식 도구와 문서를 함께 확인합니다. 이 글은 모든 파일시스템의 inode 할당 방식이 같다고 가정하지 않습니다.
2. 숫자와 실제 쓰기 환경을 연결한다
호스트에서 본 여유 공간이 컨테이너 안의 경로와 같은 저장소인지 확인하세요. 마운트 연결과 애플리케이션의 실제 설정 경로가 일치해야 합니다. 로그에는 /data라고 나오는데 운영자가 다른 디렉터리를 조사하면 정상 수치만 반복해서 보게 됩니다.
inode가 충분한데도 실패한다면 inode 부족으로 확정하지 않습니다. 블록 여유, 할당량, 파일시스템 자체 오류와 해당 도구의 구체적인 오류 문구를 다음 단계로 확인합니다. 같은 경고라는 이유로 디스크를 확장하거나 파일을 지우는 조치를 먼저 선택하지 않습니다.
3. 작은 파일을 만드는 작업부터 찾는다
문제가 있는 저장소가 확인되면 캐시, 임시 파일, 작업 큐, 로그 조각을 만드는 애플리케이션과 보존 정책을 조사합니다. GNU du의 inode 집계 기능은 디렉터리별 사용을 살펴볼 때 참고할 수 있지만 파일이 많은 경로의 전수 조회 자체도 I/O 부담을 줄 수 있습니다. 범위를 좁히고 운영 부하를 고려하세요.
작은 파일을 없애기 전에 소유 서비스, 사용 중인지 여부, 보존 요구와 복구 가능성을 확인합니다. 데이터베이스·큐·컨테이너 내부 저장 파일을 경로만 보고 직접 삭제하지 마세요. 해당 서비스가 제공하는 정리 기능과 승인된 보존 정책을 우선합니다. 이 글에는 일괄 삭제 명령을 넣지 않았습니다.
확인 방법: 같은 경로에서 재발 여부까지 본다
승인된 정리가 끝나면 같은 경로로 두 df 결과를 다시 저장합니다. 이후 서비스가 원래 수행하던 쓰기 작업이 성공하는지 확인합니다. 수치가 좋아진 것과 실제 업무가 복구된 것은 별도 결과입니다. 시험 파일 생성도 운영 데이터를 덮지 않는 승인된 위치에서만 수행합니다.
짧은 시간 뒤 같은 문제가 반복된다면 정리 횟수를 늘리기보다 파일을 만드는 속도와 보존·삭제 작업이 정상인지 확인합니다. 감시 기준에는 블록뿐 아니라 필요하면 inode 사용량도 포함하세요. 실제 수치를 측정하지 않은 상태에서 원인이나 개선률을 단정하지 않습니다.
FAQ
큰 파일 하나만 지우면 되나요? inode 문제라면 큰 파일 크기만으로 효과를 판단할 수 없습니다. 원인과 보존 범위를 먼저 확인합니다.
df -h만 보면 충분한가요? 파일 생성 실패에서는 실제 경로와 inode 정보를 함께 볼 필요가 있습니다.
이 절차가 삭제를 자동으로 수행하나요? 아닙니다. 읽기 전용 진단과 승인된 정리·복구 검증을 분리한 안내입니다.
공식 출처와 관련 글
자료 확인일: 2026년 10월 18일. 공식 문서 기반 설명이며 실제 서비스·명령 실행 시험은 수행하지 않았습니다. 설치 버전과 리전·지원 범위는 적용 전에 확인하세요.
관련 글: Docker 빌드 오류는 단계와 경로부터 확인
적용 전 원본 설정을 보존하고 승인된 시험 범위에서 결과를 확인하세요.

'소프트웨어개발' 카테고리의 다른 글
| Git detached HEAD 해결: 브랜치 이동 전에 커밋을 보존하는 순서 (0) | 2026.10.19 |
|---|---|
| Aurora Serverless v2와 프로비저닝 비교: 최소 ACU·유휴 시간·지연 조건 (0) | 2026.10.19 |
| API Gateway HTTP API와 REST API 선택: WAF·사용량 계획·비공개 엔드포인트 확인 (0) | 2026.10.19 |