Windows에서 WSL, Docker Desktop 또는 Hyper-V를 설치했다면, 드라이브에 있는 단일 파일 하나가 30GB, 40GB, 심지어 50GB까지 차지하고 있을 가능성이 큽니다. 이 파일은 다운로드 폴더나 휴지통 같은 일반적인 정리 위치에서는 보이지 않으며, 저장 공간 센서(Storage Sense)조차 이를 감지하지 못합니다. 그저 대부분의 사용자가 절대 열어보지 않는 폴더 깊숙한 곳에 묻혀 조용히 크기만 키우고 있을 뿐입니다.
이 파일은 VHDX로, 이러한 도구들이 Linux 배포판, 컨테이너, VM 내부의 모든 데이터를 저장하기 위해 사용하는 가상 디스크 이미지입니다. 문제는 VHDX 파일이 사용할수록 커지기는 하지만, 내부 데이터를 삭제하더라도 스스로 줄어들지는 않는다는 점입니다. 컨테이너를 몇 개 실행하거나 이미지를 가져온 뒤 일주일 후에 삭제하더라도, 파일 크기는 최고치에 머물러 있습니다. 이러한 도구를 한동안 사용해 왔다면, 이 폴더들을 확인하여 상당한 양의 저장 공간을 확보할 가치가 있습니다.
비대해진 파일이 숨어 있는 곳
PC에서 확인해야 할 정확한 폴더
처음 이 파일들을 찾으러 다닐 때는 어디서부터 시작해야 할지 막막했습니다. 위치는 실행 중인 도구에 따라 다르지만, 각 도구는 예측 가능한 위치에 VHDX 파일을 생성합니다. WSL의 경우, 파일 탐색기를 열고 주소 표시줄에 %LOCALAPPDATA%\Packages를 붙여넣으세요. CanonicalGroupLimited(Ubuntu의 경우) 또는 배포판 게시자 이름으로 시작하는 폴더를 찾으세요. 그 안의 LocalState 하위 폴더에 ext4.vhdx 파일이 있습니다. 이 단일 파일이 Linux 파일 시스템 전체를 담고 있습니다.
Docker Desktop은 %LOCALAPPDATA%\Docker\wsl 위치에 docker_desktop.vhdx 또는 disk\docker_data.vhdx라는 이름으로 디스크를 보관합니다(버전에 따라 다름). Hyper-V VM은 사용자가 구성한 위치에 저장되지만, 기본값은 C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks입니다.
파일 크기에서 다소 이상한 점이 발견됩니다. 필자의 경우 ‘앱 및 기능’에서는 WSL이 583GB를 차지한다고 표시되는데, Ubuntu 내부에서 df -h를 실행하면 93GB만 사용 중이라고 나옵니다. 아무런 이유 없이 490GB의 차이가 발생하는 것입니다. 처음에는 Windows가 기본적으로 WSL 내부에 C: 드라이브를 마운트하기 때문에 /mnt/c가 계산에 포함된 것이라 생각할 수 있지만, 그렇지 않습니다. VHDX 자체가 공간을 반환하지 않고 있는 것입니다.
본인의 파일을 확인하려면 파일 탐색기에서 ext4.vhdx 또는 docker_data.vhdx를 마우스 오른쪽 버튼으로 클릭하고 ‘디스크 할당 크기(Size on disk)’ 값을 확인하세요. 이 값이 중요한 수치이며, 보통 사람들을 놀라게 하는 지점입니다. 만약 이 값이 실제 배포판이나 컨테이너 내부의 데이터보다 크다면, 이 글의 나머지 부분이 도움이 될 것입니다.
VHDX 파일이 스스로 줄어들지 않는 이유
버그가 아닌 의도적인 설계 선택
출처: Tashreef Shareef / All Things N 이것은 Microsoft의 실수처럼 보이지만, 사실 의도적인 선택입니다. WSL은 동적으로 확장되는 VHDX를 사용하므로, 드라이브의 거대한 공간을 미리 할당할 필요가 없습니다. 필요에 따라 디스크가 커지는 것은 공간을 다시 확보하고 싶어지기 전까지는 매우 유용한 기능입니다.
자동으로 줄어들지 않는 이유 또한 흥미롭습니다. 예를 들어 32GB 프로젝트처럼 작업 부하가 1~2GB 정도만 변동하며 안정적인 크기를 유지하는 경우, 자동 축소 기능이 있다면 디스크가 계속해서 줄어들고 다시 커지는 과정을 반복하게 될 것입니다. 이러한 빈번한 작업은 성능에 좋지 않으며 SSD 마모를 가속화합니다. 하루 종일 생성되고 삭제되는 Docker 컨테이너에도 동일한 논리가 적용됩니다.
따라서 Microsoft는 파일이 커지면 그대로 유지하도록 하고, 수동 정리는 사용자에게 맡기기로 결정했습니다. 대부분의 작업 부하에는 적절한 결정이지만, 사용자는 이 트릭의 존재를 알고 있어야 합니다. 그렇지 않으면 WSL 내부에서 파일을 삭제하거나 Docker 이미지를 정리해도 왜 C: 드라이브가 여전히 꽉 차 있는지 의아해하게 될 것입니다. Linux 측에서는 공간이 비어 있다고 보고하지만, Windows 측에서는 계속 공간을 점유하고 있으며, 두 도구 모두 이러한 불일치에 대해 알려주지 않기 때문입니다.
공간을 확보하는 방법
압축(Compaction) 과정과 주의 사항
정리 작업은 2단계로 진행되며, 대부분의 가이드가 첫 단계를 건너뛰어 잘못된 결과를 낳습니다. 희소(sparse) VHDX는 0으로 채워진 긴 구간만 축소할 수 있기 때문에, 압축하기 전에 WSL 내부의 여유 공간을 0으로 채워야 합니다. 이 단계를 건너뛰면 Optimize-VHD가 정상적으로 실행되는 것처럼 보여도 파일 크기는 거의 변하지 않습니다. 단계를 따랐는데 변화가 없으면 이 트릭이 작동하지 않는다고 생각하게 됩니다.
WSL 배포판 내부에서 dd if=/dev/zero of=/zerofile bs=1M; rm /zerofile을 실행하세요. 이 명령은 디스크가 꽉 찰 때까지 0을 기록한 다음 파일을 삭제하여, 깨끗하고 압축 가능한 공간을 만듭니다. 명령은 결국 ‘장치에 남은 공간이 없음(no space left on device)’ 오류와 함께 종료되는데, 이것이 정확히 의도한 결과입니다. WSL2를 통해 Docker를 실행 중이라면, 압축 후 컨테이너가 손상되었다는 보고가 있으므로 먼저 Docker Desktop을 중지하고 중요한 데이터를 백업하세요.
그다음, PowerShell에서 wsl --shutdown을 실행하고, VHDX가 있는 폴더로 이동한 뒤 Optimize-VHD -Path .\ext4.vhdx -Mode full을 실행하세요. 이 작업은 Hyper-V 기능이 설치되어 있어야 하며, 즉 Windows Pro 또는 Enterprise 버전이 필요합니다. Home 에디션에서는 오류가 발생합니다. 이 경우 대체 방법으로 diskpart를 사용합니다. 관리자 권한으로 실행한 후 select vdisk file="C:\path\to\ext4.vhdx", attach vdisk readonly, compact vdisk, detach vdisk를 순서대로 실행하세요. 다소 번거롭지만 Hyper-V 없이도 작동합니다.
##### Docker Desktop
Docker Desktop은 컨테이너화된 애플리케이션을 쉽게 빌드, 실행 및 관리할 수 있도록 Windows, macOS, Linux용으로 제공되는 원클릭 애플리케이션입니다.
일상적인 유지 관리 작업으로 만들지 마세요
압축 작업은 효과적이며, 비대해진 WSL 설치 환경에서는 100GB 이상의 공간을 쉽게 확보할 수 있습니다. 하지만 Microsoft가 왜 이런 방식으로 설계했는지 기억할 필요가 있습니다. 매주 Optimize-VHD를 실행하는 것은 설계 의도에 반하는 것이며, 미미한 이득을 위해 SSD에 불필요한 쓰기 사이클을 추가하는 행위입니다.
필자는 드라이브 공간이 부족하다고 느껴지거나, 오래된 Docker 이미지 삭제 또는 프로젝트 폴더 정리와 같이 WSL 내부에서 대규모 정리를 마친 후에만 이 작업을 수행합니다. 그 외의 시간에는 그대로 둡니다. 전반적으로 디스크 공간이 부족하다면, 이 작업은 수행할 수 있는 가장 가치 있는 정리 작업 중 하나입니다. 단, 정기적인 일정으로 설정하지는 마세요.