WSL 내부 파일 삭제해도 해당 디스크 공간은 줄어들지 않습니다.

(dev.to)

Dev.to DevOps2026년 9월 3일개발자 도구

WSL2에서 파일을 삭제해도 Windows의 .vhdx 파일 크기가 줄어들지 않는 현상은 가상 디스크의 특성 때문이며, 이를 해결하려면 fstrim, shutdown, compaction이라는 세 단계의 정교한 프로세스를 반드시 순서대로 수행해야 합니다.

이 글의 핵심 포인트

1WSL2의 .vhdx 파일은 내부 파일 삭제 후에도 자동으로 크기가 줄어들지 않음
2용량 회수를 위해서는 fstrnetic, wsl --shutdown, Optimize-VHD/diskpart의 3단계 순서가 필수적임
3실제 사례에서 845.8GB였던 컨테이너 크기를 173.4GB로 약 672GB 감소시킴
4디스크 압축(Compaction)은 영구적이지 않으며, 새로운 데이터 쓰기에 따라 다시 용량이 증가함
5최적화 스크립트 자동화 시 권한 관리 및 프로세스 간섭(side effect)에 주의해야 함

이 글에 대한 공공지능 분석

왜 중요한가?

개발 환경의 디스크 점유 문제는 개발 생산성과 직결되며, 특히 대규모 빌드 아티팩트를 다루는 개발자에게는 시스템 리소스 관리의 핵심적인 기술적 지식입니다.

어떤 배경과 맥락이 있나?

WSL2는 Thin-provisioning 방식의 가상 디스크를 사용하여 필요할 때만 용량을 확장하지만, 삭제된 블록을 호스트 OS에 즉시 알리지 않는 구조적 한계를 가집니다.

업계에 어떤 영향을 주나?

클라우드나 로컬 개발 환경을 관리하는 엔지니어링 팀에서 불필요한 스토리지 비용을 절មាន하고, 개발자 머신의 디스크 부족 문제를 예방하는 데 기여합니다.

한국 시장에 어떤 시사점이 있나?

고성능 개발 환경을 구축하는 한국의 IT 스타트업과 테크 기업들은 CI/CD 파이프라인이나 로컬 개발 환경 자동화 스크립트 설계 시 이러한 리소스 관리 메커니즘을 반드시 고려해야 합니다.

이 글에 대한 큐레이터 의견

WSL2의 디스크 용량 문제는 단순한 버그가 아니라 가상화 기술의 구조적 특성에서 기인한 문제입니다. 개발자들은 이를 단순한 '용량 부족'으로 치부하기보다, 인프라 관리 측면에서 '자원 할당과 회수'의 메커니즘을 이해하고 자동화된 관리 프로세스를 구축할 필요가 있습니다.

물론, 이러한 최적화 과정을 자동화하는 것은 효율적이지만 리스크도 존재합니다. 본문에서 언급된 것처럼 권한 문제나 프로세스 재시작과 같은 부작용이 발생할 수 있으며, 잦은 컴팩션 작업은 디스크 I/O 부하를 초래할 수 있습니다. 따라서 무조건적인 자동화보다는 빌드 아티팩트가 대량으로 발생하는 특정 시점에만 실행되도록 정교하게 설계된 운영 전략이 필요합니다.

원문 보기 →