WSL2 ext4.vhdx 용량 관리, 자동 확장과 실제 디스크 부족을 구분하는 법
AI를 활용하여 생성한 이미지입니다.
WSL2에서 Docker 이미지, 패키지 캐시, 빌드 산출물을 지우고도 Windows 저장 공간이 바로 늘지 않으면 ext4.vhdx가 고장 났다고 생각하기 쉽습니다. 실제로는 서로 다른 세 숫자를 보고 있을 가능성이 큽니다. Linux 파일 시스템의 여유 공간, WSL 가상 디스크가 차지하는 크기, Windows SSD의 남은 공간을 분리해야 안전하게 조치할 수 있어요.[1]
먼저 세 층을 따로 확인하세요
WSL2는 Linux 배포판의 파일을 ext4 파일 시스템으로 저장하고, Windows에서는 그 저장소가 가상 하드 디스크인 ext4.vhdx로 보입니다. Microsoft 문서에 따르면 WSL2의 VHD는 사용량에 맞춰 커지며, Windows의 실제 디스크 여유 공간과 Linux에서 보이는 최대 용량은 같은 값이 아닐 수 있습니다.[1]
| 확인 대상 | 명령·위치 | 이 결과가 알려 주는 것 |
|---|---|---|
| 배포판과 버전 | wsl -l -v, wsl --version |
문제가 WSL2 대상인지, 명령 지원 범위가 어떤지 확인합니다.[2] |
| Linux 내부 | 배포판에서 df -h / |
ext4 파일 시스템이 실제로 가득 찼는지 봅니다. |
| 큰 디렉터리 | du -xh --max-depth=1 ~ |
홈·캐시·프로젝트 중 어디가 공간을 쓰는지 찾습니다. |
| Windows 호스트 | 설정 → 시스템 → 저장소 | SSD 자체의 여유 공간과 VHD가 차지하는 공간을 봅니다. |
예를 들어 Linux df에 여유가 있어도 Windows SSD가 부족할 수 있고, Linux 내부가 꽉 찼는데 Windows 설정만 보고 정상이라고 판단할 수도 있습니다. 진단 결과에 날짜와 배포판 이름을 함께 적어 두면 정리 전후를 비교하기 쉬워요.
정리할 때 지키는 순서
- 다시 만들 수 있는 것부터 찾습니다. 패키지 캐시, 오래된 로그, 사용하지 않는 컨테이너 이미지처럼 재생성 가능한 데이터와 원본 소스·데이터베이스를 구분하세요.
- 사용 중인 프로세스를 확인합니다. 개발 서버나 컨테이너가 파일을 잡고 있으면 삭제 후에도 상태가 예상과 다를 수 있습니다.
- Windows 저장 위치를 직접 지우지 않습니다.
%LOCALAPPDATA%\Packages아래의 배포판 파일이나ext4.vhdx를 탐색기에서 삭제하면 정리가 아니라 배포판 손실로 이어질 수 있습니다. - 정리 후 양쪽을 다시 측정합니다. Linux에서
df -h /, Windows에서 저장소 화면을 다시 확인해 어느 층에서 변화가 있었는지 봅니다.
배포판을 옮기거나 보관해야 한다면 먼저 wsl --export 같은 공식 백업 경로를 검토하세요. 중요한 프로젝트를 한 곳에만 두고 VHD를 줄이는 작업부터 시도하면 복구 지점이 사라질 수 있습니다.
VHD 공간이 정말 부족할 때
Linux 내부에서 새 파일을 만들 수 없고, 정리할 데이터도 없다면 VHD의 허용 크기를 확인합니다. Microsoft 문서에는 WSL2 가상 디스크를 확장하는 방법으로 wsl --manage와 수동 절차가 안내되어 있습니다.[1] 현재 설치가 해당 명령을 지원하는지 먼저 확인한 뒤, 다음처럼 모든 WSL 인스턴스를 종료하고 배포판 이름과 목표 크기를 환경에 맞게 바꿉니다.
wsl --version
wsl -l -v
wsl --shutdown
wsl --manage Ubuntu --resize 256GB
Ubuntu는 예시일 뿐입니다. 실제 이름은 wsl -l -v 결과의 NAME 열을 사용하세요. 확장 뒤에는 배포판을 다시 열어 df -h /로 파일 시스템이 늘었는지 확인합니다. 명령이 인식되지 않거나 오류가 나면 수동 명령을 무작정 이어 가지 말고 WSL 버전과 공식 문서의 현재 절차를 대조하세요.
축소는 확장과 다릅니다. VHD 파일 크기를 줄이는 과정은 데이터 배치, 백업, 파일 시스템 상태에 따라 실패 위험이 커집니다. DiskPart나 VHD 파일을 직접 조작하기 전에 배포판을 내보내 복구 가능한 사본을 만들고, 현재 지원되는 절차인지 확인하세요. Windows SSD의 실제 여유 공간이 급한 상황이라도 백업 없는 축소가 더 큰 손실을 만들 수 있습니다.
.wslconfig와 wsl.conf를 섞지 않기
.wslconfig는 WSL2 가상 머신 전체의 메모리·CPU·커널·VHD 관련 설정을 다루고, /etc/wsl.conf는 특정 배포판의 자동 마운트·systemd 같은 설정을 다룹니다.[3] 저장 공간 문제를 해결하려고 배포판 설정 파일에 VM 전역 옵션을 넣는 식으로 접근하면 원하는 변화가 생기지 않습니다.
설정 파일을 바꾼 뒤에는 실행 중인 배포판이 완전히 종료되어야 새 설정이 반영됩니다. Microsoft는 wsl --shutdown이 모든 배포판과 WSL2 경량 VM을 종료한다고 설명하므로, 저장하지 않은 작업이 없는지 먼저 확인하세요.[3][2] 다시 시작한 뒤 wsl --list --running으로 상태를 점검합니다.
증상별로 다음 행동 고르기
| 증상 | 먼저 볼 곳 | 다음 행동 |
|---|---|---|
| Linux 명령이 “No space left”로 실패 | df -h /와 큰 디렉터리 |
캐시·로그·컨테이너 데이터를 분류한 뒤 정리합니다. |
| Linux는 여유가 있지만 Windows 경고가 뜸 | Windows 저장소와 VHD 위치 | 호스트 SSD의 다른 대용량 파일까지 함께 확인합니다. |
| 확장 명령이 인식되지 않음 | wsl --version |
WSL 업데이트와 공식 문서의 지원 범위를 확인합니다. |
| 설정 변경이 반영되지 않음 | wsl --list --running |
저장하지 않은 작업을 닫고 필요한 범위에서 종료·재시작합니다. |
컨테이너를 쓴다면 Linux 홈 디렉터리만 보아서는 부족할 수 있습니다. Docker 데이터가 별도 위치나 다른 배포판에 저장되는지 확인하고, 사용하지 않는 이미지와 볼륨을 삭제하기 전 재생성 비용과 보존 필요성을 판단하세요. 삭제 명령은 환경마다 다르므로 복사해 실행하기보다 목록을 먼저 출력하고 대상 이름을 확인하는 단계가 안전합니다.
정리·이동·축소의 선택 기준
정리는 다시 만들 수 있는 데이터가 많고 원본을 보존할 수 있을 때 선택합니다. 이동은 Windows SSD가 작거나 배포판을 다른 드라이브에 두려는 경우에 내보내기·가져오기 절차를 검토합니다. 축소는 단순히 파일을 지우는 것과 다르므로, 공간 회수가 꼭 필요하고 백업과 복구 계획이 있는 경우에만 공식 절차를 따라야 합니다.
VHD를 다른 위치로 옮긴 뒤에는 개발 도구, 자동화 스크립트, 백업 프로그램이 예전 경로를 계속 가리키지 않는지 확인하세요. 배포판 이름을 바꾸거나 재등록하는 과정은 프로젝트의 현재 경로와 권한에도 영향을 줄 수 있습니다. 작업 전후에 wsl -l -v, 프로젝트 경로, 중요한 서비스의 시작 방법을 기록해 두면 되돌릴 때 도움이 됩니다.
실행 전 체크리스트
- 문제가 발생한 배포판 이름과 WSL 버전을 기록하기
df와 Windows 저장소에서 서로 다른 공간을 확인하기- 원본 프로젝트와 데이터베이스를 별도 백업하기
- 정리 대상이 재생성 가능한지 확인하기
- 확장·이동·축소 중 어떤 작업인지 구분하기
- 명령 실행 뒤 양쪽 공간과 서비스 상태를 다시 측정하기
자주 묻는 질문
Linux에서 파일을 지우면 ext4.vhdx도 즉시 작아지나요?
그렇게 기대하면 안 됩니다. 파일 시스템 내부의 사용량 감소와 Windows에서 보이는 VHD 파일 크기 회수는 별개의 문제입니다. 먼저 양쪽 수치를 각각 확인하세요.[1]
VHD 최대 크기를 크게 잡으면 SSD 부족이 해결되나요?
아닙니다. 최대 허용량을 늘리는 것은 Linux가 사용할 수 있는 상한을 바꾸는 일이지 Windows SSD에 공간을 만들어 주는 작업이 아닙니다.
배포판 폴더를 직접 삭제해도 되나요?
안 됩니다. 배포판 전체 파일 시스템이 사라질 수 있으므로 공식 제거·내보내기 절차를 사용하세요.
WSL의 NAT·mirrored 네트워크와 VPN·localhost 문제는 WSL2 네트워크 모드 점검법에서 이어서 볼 수 있습니다.
[…] 계획 없이 실행하지 않는 게 안전합니다. 기존 WSL 디스크 관리 절차는 ext4.vhdx 용량 관리 글에서 더 자세히 확인할 수 […]