Mac에서 Docker 디스크 사용량: 실제로 공간을 차지하는 것

Mac에서 Docker는 거의 한 번에 커지지 않습니다. 레이어 단위로 커집니다.

처음에는 하나의 이미지, 하나의 프로젝트, 하나의 데이터베이스 볼륨, 하나의 정지된 컨테이너, 나중에 정리하려던 하나의 빌드 캐시입니다. 그러다 머신이 여유로워지고, Docker Desktop이 의심스러워 보이기 시작하며, 흔한 결론은 모호하지만 감정적으로 만족스럽습니다: “Docker가 내 디스크를 잡아먹고 있어.”

그 결론은 방향은 맞지만, 유용하기에는 너무 부정확합니다. 실제 문제는 보통 “일반적인 Docker”가 아닙니다. 이미지, 레이어, 빌드 캐시, 정지된 컨테이너, 볼륨, 누구도 하나의 시스템으로 검토하지 않은 런타임 데이터에 걸친 축적입니다.

빠른 답변

Docker가 Mac에서 조용히 커지는 이유

Docker는 명시적으로 지시하지 않는 한 유용한 상태를 유지하도록 설계되었습니다. Docker 자체 문서에서는 정리를 보수적으로 설명합니다: 사용하지 않는 이미지, 컨테이너, 볼륨, 네트워크는 일반적으로 Docker에 요청하지 않는 한 제거되지 않습니다.

이는 개발자 워크플로에 편리하지만, 디스크 사용량이 조용히 증가하는 정확한 이유이기도 합니다.

Mac에서는 Docker Desktop이 Linux 컨테이너와 이미지를 단일 큰 디스크 이미지 파일에 저장하기 때문에 상황이 더 불투명하게 느껴집니다. 즉, 호스트는 하나의 큰 Docker 공간을 보여주지만 실제 원인은 여러 레이어의 런타임 데이터 안에 묻혀 있습니다.

증가 패턴은 보통 다음의 조합입니다:

• 여러 프로젝트에서 풀하고 재구축한 이미지;
• 태그와 버전에 걸쳐 재사용되는 공유 레이어;
• 여전히 쓰기 가능한 레이어를 유지하는 정지된 컨테이너;
• 데이터베이스, 업로드된 파일 또는 로컬 서비스 상태를 보유하는 볼륨;
• 비용이 되기 전까지 빌드를 빠르게 유지하는 빌드 캐시;
• 재구축과 재태깅 후 남겨진 dangling 객체.

결과는 각 개별 추가가 정상적으로 느껴지기 때문에 조용히 확장되는 공간입니다.

Mac에서 Docker 디스크 공간을 실제로 차지하는 것

유용한 정리 계획을 원한다면 Docker 공간을 하나의 거대한 블랙박스로 취급하는 대신 카테고리별로 분리하세요.

이것이 “가장 큰 폴더” 워크플로가 Docker에 약한 이유입니다. 동일한 총 크기도 공간이 주로 빌드 캐시인지 실제 볼륨 데이터인지에 따라 매우 다른 정리 결정을 의미할 수 있습니다.

Docker 이미지와 공유 레이어

이미지는 개발자가 가장 먼저 생각하는 것이지만, 더 깊은 이야기는 레이어에 있습니다. 여러 언어 런타임, CI와 유사한 로컬 빌드, 여러 마이크로서비스가 있는 머신은 많은 공유 및 고유 레이어를 빠르게 축적할 수 있습니다.

그래서 디스크 사용량이 기억하는 이미지 목록과 깔끔하게 매핑되지 않는 경우가 많습니다.

Docker 빌드 캐시

빌드 캐시는 활성 개발 머신에서 가장 흔한 숨겨진 원인 중 하나입니다. 향후 빌드를 빠르게 만들기 위해 존재하므로, 정리할 때까지 남아 있습니다. 이는 삭제가 보통 무료 이익이 아닌 성능 트레이드오프임을 의미합니다.

정지된 Docker 컨테이너

개발자들은 이것을 지속적으로 과소평가합니다. 실행되지 않는 컨테이너도 여전히 스토리지 객체입니다. 존재한다면 여전히 디스크 공간을 차지할 수 있습니다.

Docker 볼륨

볼륨은 위험이 높아지는 지점입니다. 실제로 중요한 데이터를 보유할 수 있습니다: 데이터베이스, 패키지 미러, 업로드, 검색 인덱스, 로컬 레지스트리 콘텐츠, 서비스 상태 등.

이것이 Docker 정리와 일반 캐시 정리의 차이입니다. 일부 Docker 스토리지는 재구축 가능합니다. 일부는 사용자의 환경 그 자체입니다.

Dangling Docker 이미지와 객체

Dangling 객체는 종종 가장 안전한 정리 대상입니다. Docker의 prune 문서는 dangling 이미지를 태그가 없고 어떤 컨테이너도 참조하지 않는 이미지로 정의합니다. 이는 정상적인 반복을 통해 성장하는 축적의 정확한 종류입니다.

Mac에서 Docker 디스크 사용량 확인 방법

가장 좋은 첫 번째 단계는 Finder가 아닙니다. 데몬이 공간을 소비하고 있다고 생각하는 것에 대한 Docker 수준의 뷰입니다.

Mac에서 Docker 자체의 권장 사항은 docker system df -v로 시작하는 것이며, 이미지, 컨테이너, 로컬 볼륨, 회수 가능한 공간에 대한 사용량을 보여줍니다. 이것이 추측을 멈추는 가장 빠른 방법입니다.

다음 검토 순서를 사용하세요:

1. docker system df -v로 시작

이것이 가장 좋은 첫 번째 요약입니다. 다음을 보여주기 때문입니다:

• 총 이미지 사용량과 회수 가능한 사용량;
• 컨테이너 사용량;
• 로컬 볼륨 사용량;
• verbose 플래그를 사용할 때 더 자세한 분석.

회수 가능한 공간이 적다면, 광범위한 정리는 도움이 되지 않을 것입니다.

2. 정리 전에 정지된 컨테이너 검토

더 이상 아무도 필요로 하지 않는 종료된 컨테이너가 많은지 확인하세요. 이들은 볼륨이나 활성 런타임 상태에 비해 상대적으로 안전한 정리 대상입니다.

3. 빌드 캐시와 별도로 이미지 검토

이미지와 빌드 캐시는 다른 문제를 해결합니다. 캐시가 주요 문제라면, Docker가 소유한 모든 것을 광범위하게 재설정하는 것보다 캐시 중심 정리가 보통 더 낫습니다.

4. --volumes를 사용하기 전에 볼륨 검토

이것이 사람들이 건너뛰고 후회하는 부분입니다. 볼륨이 현재 실행 중인 컨테이너에서 분리된 것처럼 보이지만, 내일 다시 시작할 프로젝트의 실제 로컬 데이터를 나타낼 수 있습니다.

5. Docker Desktop의 Mac 측 디스크 이미지 검토

Docker의 Mac FAQ에서는 Docker Desktop이 Linux 컨테이너와 이미지를 단일 디스크 이미지 파일에 저장하며, 일부 도구는 실제 소비 크기가 아닌 최대 파일 크기를 보여줄 수 있다고 언급합니다. 이것이 중요한 이유는 무서운 호스트 측 숫자가 항상 즉시 회수 가능한 낭비와 같은 것은 아니기 때문입니다.

정리 전 확인 사항

빠른 Docker 검토 명령어

제거하기 전에 유용한 검사 명령어입니다:

docker system df -v
docker ps -a --size
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'
docker volume ls

이를 사용하여 prune 범위를 선택하기 전에 실제로 회수 가능한 것을 확인하세요.

Docker 폴더를 직접 삭제하는 것이 위험한 이유

직접 삭제는 결정적으로 보이기 때문에 매력적입니다. 하지만 Docker 정리를 런타임 정리 룰렛으로 만드는 방법이기도 합니다.

두 가지 이유가 있습니다.

첫째, Docker는 런타임 상태와 메타데이터를 추적합니다. Docker 자체 워크플로 외부에서 Docker 관리 파일을 제거하면 런타임이 존재한다고 믿는 것과 실제로 디스크에 있는 것 사이의 관계가 깨질 위험이 있습니다.

둘째, Mac에서 Docker 공간은 Docker Desktop의 관리 디스크 이미지와 런타임 스토리지에 연결되어 있습니다. Docker 자체 Mac 문서에서는 Finder에서 디스크 이미지를 직접 이동하지 말라고 명시적으로 경고합니다. Docker Desktop이 이를 잃어버릴 수 있기 때문입니다. 같은 일반적인 교훈이 Docker 관리 스토리지 내부의 무차별 삭제에도 적용됩니다: Docker 인식 작업이 파일 시스템 추측보다 안전합니다.

이는 또한 실행 중인 컨테이너 내부에서 파일을 삭제하는 것이 호스트 디스크 공간을 회수하는 것과 같지 않은 이유이기도 합니다. Docker의 Mac 문서에 따르면 호스트 공간은 파일이 실행 중인 컨테이너 내부에서 사라질 때 자동으로가 아니라 이미지가 삭제될 때 회수됩니다.

prune이 도움이 될 때

prune은 이미 공간을 이해하고 Docker가 사용하지 않는 객체를 제거하게 하려고 할 때 유용합니다.

도움이 되는 주요 경우는 간단합니다:

• 정지된 컨테이너, 사용하지 않는 네트워크, dangling 이미지, 사용하지 않는 빌드 캐시가 쌓였을 때 docker system prune;
• 빌드 캐시가 실제 문제일 때 docker builder prune;
• 사용하지 않는 볼륨이 진정으로 일회성인지 확인한 후 docker volume prune;
• 모든 것을 쓸어버리는 대신 범위를 좁히고 싶을 때 시간 또는 라벨 필터링된 정리.

이것이 Docker 인식 정리가 원시 파일 삭제보다 명확히 나은 지점입니다. 런타임은 객체 유형을 이해합니다. Finder는 그렇지 않습니다.

docker system prune이 위험할 때

위험은 prune이 나쁘다는 것이 아닙니다. 위험은 Docker에서 “사용하지 않는”이 여전히 “내 워크플로에 중요한”을 의미할 수 있다는 것입니다.

다음과 같은 경우 주의하세요:

• 정지된 컨테이너가 다시 시작할 로컬 환경의 일부일 때;
• 다음 빌드가 지우려는 캐시를 필요로 할 때;
• 로컬 볼륨이 여전히 중요한 데이터베이스나 서비스 데이터를 보유할 때;
• docker system prune -a가 지금 실행 중이지 않지만 여전히 활성 작업의 일부인 이미지를 제거할 때;
• 볼륨이 무엇을 나타내는지 먼저 확인하지 않고 볼륨 정리를 추가하려고 할 때.

Docker 문서는 데이터가 파괴될 수 있기 때문에 볼륨이 자동으로 제거되지 않는다고 명시합니다. 이것이 볼륨 정리에 대한 올바른 멘탈 모델입니다: 볼륨은 이미지나 dangling 캐시보다 더 많은 의심을 받아야 합니다.

정리 전 결과를 이해하는 방법

무엇이든 정리하기 전에 결과 질문에 평이한 언어로 답하세요:

정리 후 무엇을 재구축, 재풀, 복원, 재생성해야 하나요?

이 질문은 “얼마나 삭제할 수 있는가?”보다 유용합니다.

Docker의 경우 실제 검토는 보통 다음과 같습니다:

1. 주요 공간이 이미지, 빌드 캐시, 정지된 컨테이너, 볼륨 중 무엇인가요?
2. 실행 중인 컨테이너가 계획의 일분인가요, 아니면 정리를 위해 먼저 중지해야 하나요?
3. 캐시를 정리한다면, 이후 느린 빌드나 재풀에 편안한가요?
4. 볼륨을 정리한다면, 어떤 서비스 상태나 데이터가 함께 사라지나요?
5. Docker 정리를 실제 회수 가능한 공간 문제를 해결하는 데 사용하는 것인가요, 아니면 하나의 큰 불투명한 디스크 이미지에 반응하는 것인가요?

이것이 통제된 개발자 정리와 무작위 스토리지 공포의 차이입니다.

개발자 정리가 일반 파일 정리와 다른 이유

일반 파일 정리는 “어떤 폴더가 큰가?”라고 묻습니다.

Docker 정리는 다른 질문이 필요합니다:

• 이것이 재구축 가능한 캐시인가요, 영구적인 서비스 데이터인가요;
• 런타임이 회수 가능하다고 보고하나요;
• 정리가 파일 시스템 삭제가 아닌 Docker 명령을 통해 이루어져야 하나요;
• 실행 중인 컨테이너, 정지된 컨테이너, 볼륨이 결과 모델의 일부인가요;
• 위험한 정리 경로를 적용하기 전에 안내된 검토가 필요한가요?

이것이 Docker가 일반 캐시 폴더를 비우거나 다운로드를 삭제하는 것과 같은 버킷이 아닌 컨테이너 인식 워크플로에 속해야 하는 이유입니다.

StorageRadar의 역할

이것이 중요한 이유는 Docker가 단순히 “하나의 큰 폴더”가 아니기 때문입니다. 다른 정리 결과를 가진 객체 유형의 생태계입니다.

빌드 캐시가 문제라면, 볼륨이 많은 머신과 다른 조치가 필요합니다. 실행 중인 컨테이너를 먼저 중지해야 한다면, 그것은 정리 전에 보여야 합니다. 프로필이 위험하다면 워크플로는 의도적으로 속도를 늦춰야 합니다.

하지 말아야 할 것

이런 일반적인 실수를 피하세요:

• 모든 큰 Docker 공간을 하나의 명령으로 해결할 수 있는 하나의 문제로 취급하지 마세요;
• 경로가 크게 보인다고 Docker 관리 디렉토리 내에서 직접 rm -rf를 실행하지 마세요;
• 큰 Docker Desktop 디스크 이미지가 그 공간 전체가 지금 안전하게 회수 가능하다는 의미라고 가정하지 마세요;
• 볼륨이 무엇을 보유하고 있는지 확인하지 않고 대충 볼륨 정리를 추가하지 마세요;
• 감당할 수 없는 데모, 릴리즈, 로컬 환경 재구축 직전에 광범위한 prune을 사용하지 마세요.

Docker가 더 큰 개발자 머신 문제의 일부에 불과하다면, Xcode DerivedData가 Mac에서 너무 많은 공간을 차지할 때에 대한 가이드가 유용한 다음 읽을 거리입니다.

결론

Mac에서 Docker 디스크 사용량은 올바른 카테고리로 나누면 보통 신비롭지 않습니다. 가장 큰 요인은 일반적으로 이미지, 레이어, 빌드 캐시, 정지된 컨테이너, 볼륨, dangling 객체, Docker Desktop 런타임 스토리지입니다.

안전한 접근 방식은 먼저 공간을 검사하고, 재구축 가능한 아티팩트를 영구적인 데이터와 분리한 후, 결과를 이해한 후에만 Docker 인식 정리를 사용하는 것입니다.