Mar 24, 2026

마지막 업데이트 Mar 30, 2026

Docker no space left on device: 먼저 확인할 것들

Docker에서 no space left on device가 뜰 때, 겉으로는 build나 pull, write, container start 한 번이 실패한 것처럼 보여도 실제 원인은 이미지, cache, log, volume 중 하나가 오래 누적되면서 host 저장 공간이 바닥난 경우가 많습니다.

짧게 말하면, 무조건 prune부터 하지 말고 어떤 저장 영역이 자라고 있는지 먼저 구분해야 합니다. 잘못된 데이터를 먼저 지우면 새로운 장애를 만들거나 필요한 상태를 날릴 수 있습니다.

먼저 host 디스크 압박과 container 내부 파일시스템 문제를 구분하세요

실무에서는 아래 둘이 자주 섞입니다.

Docker host 전체가 image, cache, log, volume 때문에 디스크 부족 상태인 경우
특정 container 안에서 writable layer나 mount path가 꽉 찬 경우

첫 번째는 host 수준의 Docker 정리가 필요하고, 두 번째는 application 쓰기 패턴이나 mount 경로를 다시 봐야 합니다. 이 둘을 구분하지 않으면 cleanup이 전부 추측이 됩니다.

공간을 잡아먹는 흔한 원인

1. 오래된 image와 dangling layer가 쌓임

반복 빌드와 pull이 이어지면 오래된 tag와 사용하지 않는 layer가 조용히 누적됩니다.

2. build cache가 계속 커짐

BuildKit cache는 개발 머신과 CI host에서 생각보다 빠르게 커질 수 있습니다.

특히 자주 build하고 거의 정리하지 않는 환경에서 두드러집니다.

3. container log가 rotation 없이 계속 커짐

로그가 많은 애플리케이션은 host의 JSON log 파일을 예상보다 빠르게 채울 수 있습니다.

앱 자체는 정상이라 더 늦게 발견되는 경우가 많습니다.

4. volume이 오래된 데이터를 계속 보관함

named volume에는 database, upload, temporary artifact, 옛 상태 데이터가 컨테이너가 사라진 뒤에도 남아 있을 수 있습니다.

5. image 자체가 과하게 큼

runtime layer가 지나치게 크면 새 host나 새 배포마다 디스크 부담이 반복됩니다.

직접적인 원인이 아닐 때도 있지만 전체 상황을 더 악화시키는 요인입니다.

실전 점검 순서

1. Docker 저장 공간 요약부터 보세요

기본적으로 아래 명령으로 시작합니다.

docker system df
docker ps -a
docker volume ls

여기서 image, container, local volume, build cache 중 무엇이 크게 차지하는지 대략적인 감을 잡는 것이 첫 단계입니다.

2. stopped container와 오래된 image가 많은지 확인하세요

사용하지 않는 container나 오래된 image tag가 많으면 비교적 빠르게 정리 효과를 볼 수 있습니다. 다만 정말 버려도 되는 것인지 먼저 확인해야 합니다.

공유 host, CI runner, 오래 켜둔 개발 머신일수록 중요합니다.

3. 큰 log와 write-heavy container를 보세요

image가 핵심이 아니라면 log가 원인인 경우가 많습니다. noisy service 하나가 거대한 로컬 파일을 만들고 있어도 팀은 다른 곳만 보고 있을 수 있습니다.

4. volume은 지우기 전에 역할을 확인하세요

여기서부터는 데이터 유실 위험이 커집니다. database, upload store, stateful workload가 named volume을 쓰고 있다면 그 안의 데이터가 무엇인지, 복구 가능한지부터 알아야 합니다.

5. 책임 있는 저장 영역만 정리하세요

images, build cache, logs, volumes 중 어느 쪽이 진짜 원인인지 알게 됐다면, 그 범위만 의도적으로 정리하세요.

image 자체가 너무 큰 편이라면 Docker image가 너무 클 때도 같이 보는 것이 좋습니다.

패턴을 찾은 뒤 어떻게 바꿀지

오래된 image와 layer가 핵심인 경우

CI runner와 shared build host에서는 오래된 tag와 dangling layer를 주기적으로 정리하는 운영 습관이 필요합니다.

build cache가 핵심인 경우

cache 유지 정책과 build 빈도를 함께 봐야 합니다. 자주 build하는 host에서는 cache 증가가 자연스러운 만큼, 관리도 의도적으로 해야 합니다.

log가 디스크를 채우는 경우

불필요한 로그 양을 줄이고, 로컬 log rotation이나 driver 설정이 워크로드에 맞는지 확인하세요.

volume이 핵심인 경우

어떤 서비스가 그 데이터를 아직 쓰는지 파악하고, 큰 상태 데이터는 더 관리 쉬운 저장소로 옮기고, 오래된 named volume을 계속 방치하지 않도록 해야 합니다.

application이 writable path를 빠르게 채우는 경우

temp file 생성, export job, local upload, background task가 container filesystem이나 mounted directory에 계속 쓰고 있지 않은지 봐야 합니다.

안전한 체크리스트

Docker에서 no space left on device가 뜨면 아래 순서가 가장 안전합니다.

host가 찼는지, container 내부 파일시스템이 찼는지 구분한다
docker system df를 실행한다
오래된 image, stopped container, cache 증가를 본다
container log와 named volume을 확인한다
이해한 범위만 prune 하거나 정리한다
반복해서 커지는 원인을 수정한다

FAQ

Q. `docker system prune -a`가 항상 정답인가요?

아닙니다. 유용한 cache나 artifact를 같이 지울 수 있고, 환경에 따라 너무 과격할 수 있습니다.

Q. 가장 빠른 첫 단계는 무엇인가요?

정리 전에 docker system df를 실행해서 어느 저장 영역이 실제 원인인지 보는 것입니다.

Q. CI host에서 왜 자꾸 반복되나요?

빌드와 pull이 많고 cache가 계속 누적되기 때문입니다. 계획된 정리가 없으면 반복됩니다.

Q. 디스크를 비워서 container가 다시 떴다면 끝난 건가요?

아닙니다. 무엇이 계속 커졌는지 찾지 않으면 같은 장애가 다시 옵니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.