큰 ZimaOS 스왑 파일이 있다고 해서 실제로 스왑 압박이 발생하는 것은 아니며, 스왑 파일을 삭제하는 것도 부팅 디스크 공간을 확보하는 올바른 방법이 아닙니다. 스왑의 실제 사용량, 메모리 압박, Docker 디스크 사용량, 로그 및 AppData 위치를 확인한 후 스왑 설정을 변경하세요.
2026년 원본 스레드에서는 거의 가득 찬 48GB 부팅 디스크의 원인으로 3.8GB .swap 파일을 지목했지만, 계산해 보면 스왑은 부족한 공간 중 일부에 불과했습니다. 이후 시스템에서 약 20GB가 다시 확보되었으므로, 스왑 축소보다는 일시적인 Docker 또는 캐시 정리일 가능성이 높습니다.
예약된 스왑 크기와 실제 스왑 사용량
다음 명령을 실행하세요.
free -h
swapon --show4GB 스왑 파일이 디스크에 존재하더라도 실제로는 아주 적은 양만 사용 중일 수 있습니다. 파일 크기는 예약된 용량일 뿐이며, RAM이 4GB만큼 초과되었다는 뜻은 아닙니다.
시스템 디스크를 채우는 항목 찾기
다음 명령을 실행하세요.
df -h
du -xh /var/lib/docker --max-depth=1 2>/dev/null | sort -h애플리케이션 미디어가 다른 위치에 매핑되어 있더라도 Docker 이미지 레이어, 쓰기 가능한 오버레이, 로그, 캐시 및 임시 데이터가 작은 시스템 디스크를 차지할 수 있습니다.
AppData를 시스템 드라이브 밖에 유지하기
현재 ZimaOS 앱 데이터 가이드에서는 시스템 드라이브를 가득 채우지 않도록 App 데이터 위치를 저장 공간으로 설정할 것을 명확히 권장합니다.
이렇게 해도 모든 Docker 시스템 사용량이 사라지는 것은 아니지만, 애플리케이션 데이터베이스와 미디어 캐시가 기본적으로 부팅 장치를 차지하는 것을 방지할 수 있습니다.
컨테이너 로그 확인
로그를 과도하게 생성하는 컨테이너는 JSON 로그를 빠르게 키울 수 있습니다. 무작위로 파일을 삭제하기 전에 Docker 디스크 사용량과 컨테이너 로그 크기를 확인하세요.
특정 앱이 원인이라면 활성 로그 파일을 수동으로 삭제하기보다 해당 앱의 로깅 동작을 수정하거나 로그를 순환 처리하세요.
스왑 사용량이 높으면 RAM 압박일 수 있음
free -h에서 사용 가능한 메모리가 적고 스왑이 실제로 사용 중이라면 RAM을 많이 사용하는 프로세스를 확인하세요. 대규모 데이터베이스, 사진 인덱싱, AI 작업 및 가상 머신은 메모리가 적은 시스템을 스왑 상태로 몰아갈 수 있습니다.
증상을 숨기기 위해 스왑을 비활성화하지 마세요
스왑은 짧은 메모리 급증이 발생하는 동안 시스템을 계속 실행하는 데 도움이 될 수 있습니다. 메모리가 제한된 서버에서 스왑을 비활성화하면 속도 저하가 메모리 부족으로 인한 프로세스 종료로 바뀔 수 있습니다.
RAM을 추가해야 하는 경우
지속적인 작업으로 실제 메모리가 계속 고갈되고 중요한 서비스가 심하게 페이징될 때 RAM을 추가하세요. 스왑 파일이 존재한다는 이유만으로 RAM을 업그레이드할 필요는 없습니다.
성능 문제 해결 가이드를 참고하면 느린 서버를 항상 RAM 문제로 간주하는 일을 피할 수 있습니다.
시간에 따른 메모리 압박 측정
Linux는 남는 RAM을 캐시로 적극 사용하므로 free -h를 한 번만 확인하면 오해할 수 있습니다. 사용 가능한 메모리와 작업 중 스왑 인·스왑 아웃 활동이 계속되는지를 확인하세요.
시스템에서 사용할 수 있는 도구를 통해 지속적인 스와핑이 확인되고 서버가 느리게 느껴진다면, 스왑 파일 크기에만 집중하지 말고 어떤 앱이나 가상 머신이 메모리를 사용하는지 확인하세요.
Docker 이미지는 여전히 시스템 공간을 사용함
AppData를 /DATA로 옮겨도 모든 Docker 이미지 레이어와 런타임 파일이 함께 이동하는 것은 아닙니다. 따라서 사용자 데이터 볼륨이 모두 다른 위치를 가리키더라도 많은 앱을 설치하고 업데이트하면 시스템 디스크가 커질 수 있습니다.
정리하기 전에 Docker 자체의 디스크 사용량 화면을 사용해 이미지, 컨테이너, 로컬 볼륨 및 빌드 캐시를 구분하세요. 사용하지 않는 것이 확실한 객체만 삭제하세요.
작은 시스템 디스크가 구조적인 문제인지 확인
48GB 부팅 디스크도 사용할 수는 있지만, 여러 앱 이미지와 업데이트, 로그 및 임시 작업을 처리할 여유 공간이 거의 없습니다. 정상적으로 정리한 후에도 시스템 디스크가 반복해서 100%에 가까워진다면 더 큰 시스템 디스크를 사용하거나 영구 작업을 주 저장소로 더 많이 옮기는 것이 지속 가능한 해결책일 수 있습니다.
여유 공간 부족은 2차 장애를 일으킬 수 있음
쓰기 가능한 시스템 영역이 거의 가득 차면 앱 업데이트, 데이터베이스 쓰기, 로그 및 임시 파일이 저장 공간과 직접 관련 없어 보이는 방식으로 실패할 수 있습니다. 다른 어레이에 테라바이트 단위의 여유 공간이 있더라도 여유 공간이 매우 적은 상태를 운영 위험으로 간주하세요.
FAQ
밤새 디스크 여유 공간이 다시 늘어난 이유는 무엇인가요?
임시 Docker 레이어, 캐시, 로그 또는 정리 작업으로 인해 공간이 확보되었을 수 있습니다. 그렇다고 스왑 파일 자체가 줄어든 것은 아닙니다.
.swap 파일을 삭제해야 하나요?
아니요. 먼저 실제 스왑 사용량과 디스크 공간을 차지하는 항목을 확인하세요.
3~4GB 스왑은 정상인가요?
수 GB 크기의 스왑 파일이 존재하는 것은 드문 일이 아닙니다. 중요한 것은 실제로 얼마나 많은 스왑이 사용되고 있는지, 그리고 메모리 압박이 지속되는지입니다.
AppData가 /DATA에 있는데도 부팅 디스크가 사용되는 이유는 무엇인가요?
Docker 엔진 메타데이터, 이미지 레이어, 런타임 오버레이, 로그 및 시스템 파일은 여전히 매핑된 애플리케이션 데이터 외부에 저장됩니다.
