WSL2 디스크 공간 부족 Docker 포함 용량 폭증 원인과 재발 방지

WSL2 용량 폭증의 원인 → 진단 → 즉시 감량(확실한 절차) → C 용량 부족 상황에서의 해법(핵심) → Optimize-VHD 미존재 원인/설치 → 운영/보안 관점 가이드 → 자동화 예시 정리입니다.

배경과 문제 정의

1. 현상

• WSL2 사용 중 C 드라이브 용량이 급격히 줄어들고
• WSL의 디스크 사용량이 수십~수백 GB까지 커짐
• WSL 내부에서 파일/이미지/캐시를 삭제해도 Windows(C:) 용량은 크게 줄지 않음

2. 결론

• WSL2는 리눅스 파일시스템을 단일 가상 디스크 파일(ext4.vhdx)로 보관합니다.
• 이 파일은 커질 때는 즉시 커지지만, 내부에서 파일을 지워도 자동으로 줄지 않는 구조라서
• “정상적인 사용 패턴 + 구조적 특성”만으로도 용량 폭증이 매우 흔합니다.
• 실제 Windows 디스크 공간을 돌려받으려면
  • (A) VHDX 압축(Compact/Optimize) 또는
  • (B) export→unregister→import로 D:에 재생성이 필요합니다.

왜 WSL 용량이 계속 증가하는가?

1. 핵심 원인: ext4.vhdx 구조(동적 확장 + 비자동 축소)

WSL2는 내부 리눅스 루트(/)를 Windows 파일 하나에 저장합니다. 대표 위치 예시(배포판에 따라 폴더명 다름)

C:\Users\사용자이름\AppData\Local\Packages\
CanonicalGroupLimited...\LocalState\ext4.vhdx

이 구조의 “문제 포인트”

• ✅ 파일이 늘어나면: VHDX는 즉시 확장
• ❌ 파일을 지우면: VHDX는 자동 축소되지 않음
• 즉, WSL 내부에서 삭제해도 Windows 쪽 VHDX 크기(점유)는 유지되는 경우가 흔함

2. WSL에서 많이 쌓이는 데이터 “대표 범인”

스레드에서 언급된 대표적 원인들

(1) 패키지/업데이트

• apt install, apt upgrade 반복
• /var/cache/apt/archives 캐시
• 오래된 패키지/커널/헤더 잔존

(2) Docker(폭증의 90%를 차지하는 경우도 흔함)

• 이미지 레이어, 컨테이너, 볼륨, 빌드 캐시
• 실무에서 “WSL 용량 폭증” 원인 1순위로 자주 등장

(3) 개발 캐시/산출물

• node_modules
• npm/yarn/pnpm 캐시
• pip 캐시
• 빌드 산출물(dist/build/target 등)
• 로그 파일

지금 당장 용량 줄이는 방법(표준 절차)

핵심은 “내부 정리 → WSL 종료 → VHDX 압축” 3단계입니다.
내부 정리만 하면 “리눅스 안에서는” 줄어든 것처럼 보여도, Windows 용량은 그대로일 수 있습니다.

1단계: WSL 내부 정리(삭제/정리)

apt 정리(기본)

sudo apt autoremove -y
sudo apt clean
sudo apt autoclean

Docker 사용 중이면(가장 효과 큼)

docker system prune -a

볼륨까지 포함(주의: 데이터 삭제)

docker system prune -a --volumes

npm 캐시

npm cache clean --force

pip 캐시

pip cache purge

2단계: WSL 완전 종료(필수)

PowerShell(관리자 권한 권장)

wsl --shutdown

3단계: VHDX 압축(Windows 실제 용량 회수의 핵심)

diskpart compact(가장 보편적, Home에서도 가능)

 

PowerShell에서

diskpart

diskpart 콘솔에서

select vdisk file="C:\Users\사용자이름\AppData\Local\Packages\CanonicalGroupLimited...\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

이 중 compact vdisk가 실제로 수백 GB → 수십 GB로 줄여줄 수 있는 핵심 단계입니다.

C 드라이브가 부족하면 “압축도 공간이 필요하냐?”

1. 답: 네, 부족하면 실패할 수 있습니다

• “C 드라이브가 용량 부족한데, 옵티마이즈 하려고 해도 용량이 있어야 하나?”
• “C의 vhdx를 옵티마이즈하면 D에 다시 생성되는가?”

✅ 정리

• Optimize-VHD / diskpart compact는 기본적으로 in-place 작업이라
• 작업 중 메타데이터/블록 이동 등으로 약간의 여유 공간이 필요할 수 있습니다.
• 그리고 D 드라이브에 새 VHDX를 생성해서 교체해 주지 않습니다.
  • (중요) Optimize/compact는 “같은 파일을 줄이는” 방식이지 “새 파일 생성”이 아님

C가 꽉 찬 상태에서의 현실적 해결책(가장 추천)

최강 해법: export → unregister → import (D에 새 VHDX 생성)

이건 스레드에서 강조된 “C 부족 시 사실상 정답” 루트입니다.

1) 배포판 확인

wsl -l -v

예

Ubuntu    Running    2

2) WSL 종료

wsl --shutdown

3) export (tar 파일로 내보내기)

wsl --export Ubuntu D:\wsl_backup\ubuntu.tar

포인트

• export는 “실제로 사용 중인 데이터” 중심으로 나가므로 VHDX의 빈 공간이 같이 따라가지 않습니다.
• 즉, 결과적으로 슬림한 형태로 재구성되는 효과가 있습니다.

4) 기존 배포판 제거(= C의 vhdx 제거 효과)

wsl --unregister Ubuntu

5) D에 import (새 VHDX 생성)

wsl --import Ubuntu D:\WSL\Ubuntu D:\wsl_backup\ubuntu.tar --version 2

결과

• D:\WSL\Ubuntu\ext4.vhdx 형태로 새로 생성
• C 드라이브 압박 해소
• “최적화된 상태”로 재출발

Optimize-VHD가 없다고 나올 때: 무엇을 설치해야 하나?

• “Optimize-VHD 없다고 나오는데 뭘 설치해야 하나?”

1. 왜 없는가?

Optimize-VHD는 기본 PowerShell 명령이 아니라 Hyper-V PowerShell 모듈에 포함된 cmdlet입니다.

즉,

• Hyper-V 기능이 설치/활성화되지 않았거나
• Windows 에디션이 Home이거나
• Hyper-V PowerShell 모듈이 없는 경우 Optimize-VHD는 “없음”이 정상입니다.

2. 설치/활성화(Windows Pro/Enterprise/Education인 경우)

방법(관리자 PowerShell)

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

설치 확인

Get-Module -ListAvailable Hyper-V
Get-Command Optimize-VHD

3. Home이면?

• Windows Home은 일반적으로 Hyper-V 전체를 제공하지 않아 Optimize-VHD가 없을 수 있고, 그 경우 diskpart compact나 export/import가 표준 대안입니다.

앞으로 폭증하지 않게 운영하는 법(재발 방지)

1. Docker 사용 시 “주기적 정리”는 필수

권장 루틴 예시

• 자주 빌드하면 주 1회 또는 더 자주

  docker system prune -a
  docker builder prune -a

• 월 1회
  • wsl --shutdown
  • compact vdisk 또는 export/import

2. 근본 대책: WSL을 C가 아닌 D에 두기

• C 드라이브를 OS/업무 핵심으로 남기고
• WSL/Docker 데이터는 D로 분리하는 게 장기적으로 가장 안정적입니다.

보안/운영 관점 체크 포인트

1. “용량 폭증”은 단순 캐시 외에도 이상 징후일 수 있음

• 로그 폭증(/var/log)
• 덤프/코어 파일 누적
• 스크립트/빌드 파이프라인 오류로 산출물 무한 생성
• 컨테이너 로그 폭증(서비스 오류/비정상 트래픽 가능)

300x250

점검 예시(WSL)

 

상위 디렉터리 용량

sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 50

큰 파일 Top

sudo find / -type f -size +500M -printf '%s %p\n' 2>/dev/null | sort -n | tail -n 30

Docker 점유

docker system df

2. 사용자 가이드(권장 문장 예시)

• WSL은 기본적으로 ext4.vhdx 단일 파일 구조이므로 삭제만으로 Windows 공간이 회수되지 않을 수 있음
• Docker 사용 시 이미지/볼륨/빌드캐시가 급격히 증가하므로 주기적 prune 필요
• C 드라이브 보호를 위해 WSL 저장 위치를 D로 분리(export/import) 권장
• 월 1회 compact(또는 export/import) 수행 권장

자동화 예시(정리 루틴 스크립트)

1. WSL 내부 정리 스크립트 예시

sudo apt autoremove -y
sudo apt clean
sudo apt autoclean

docker system prune -a -f 2>/dev/null || true
npm cache clean --force 2>/dev/null || true
pip cache purge 2>/dev/null || true

2. Windows 측 compact(diskpart) 자동화 개념

1. wsl --shutdown 후
2. diskpart 스크립트 파일로 실행

예: compact_wsl.txt

select vdisk file="C:\...\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

실행

wsl --shutdown
diskpart /s .\compact_wsl.txt

최종 결론

1. WSL2 용량 폭증은 구조적으로 흔합니다(ext4.vhdx 비자동 축소)
2. 내부 정리는 “준비 단계”이고, 실제 Windows 용량 회수는
   • diskpart compact vdisk 또는
   • Optimize-VHD(가능한 환경에서)가 핵심입니다.
3. C 드라이브가 이미 부족하면 optimize/compact가 실패할 수 있으므로,
   export → unregister → import로 D에 새 VHDX를 생성하는 방식이 가장 안전하고 근본적입니다.
4. Optimize-VHD가 없다면 Hyper-V(및 모듈) 미설치/에디션 제약일 수 있으며,
   없어도 diskpart/export-import로 충분히 해결 가능합니다.

Optimize-VHD 없음에서 “가장 추천 루트”

export → unregister → import로 D로 이전
이게 “C 여유가 거의 없어도” 성공률이 높고, 결과가 깔끔합니다.