이 글의 목적은 WSL2 사용 중 Windows에서 vmmem 또는 vmmemWSL 프로세스가 메모리를 과다 점유하는 문제를 .wslconfig 설정으로 안정적으로 제한하고, 적용·검증·트러블슈팅까지 한 번에 정리하여 현장에서 바로 재현 가능하도록 돕는 것이다.
1. WSL2 메모리 과다 점유 증상과 핵심 원인
1-1. 대표 증상
WSL2를 켠 뒤 시간이 지나면 작업 관리자에서 vmmem 또는 vmmemWSL이 물리 메모리를 크게 점유하여 Windows 전체가 느려지는 현상이 발생하다.
특히 Docker Desktop을 WSL2 기반으로 사용하거나, VS Code Remote - WSL로 개발 환경을 띄우는 경우에 메모리 점유가 장시간 유지되는 현상이 자주 관찰되다.
1-2. 왜 WSL2는 메모리를 크게 잡는가
WSL2는 가상 머신 기반으로 동작하며, Linux 커널과 사용자 공간이 별도의 VM 메모리를 사용하다.
Linux는 파일 캐시(page cache)와 버퍼를 적극적으로 활용해 체감 성능을 올리는 설계를 가지며, 이는 “사용 가능한 메모리가 남으면 캐시로 쓰는” 동작을 의미하다.
문제는 캐시로 사용된 메모리가 Windows로 즉시 반환되지 않는 경우가 있으며, 그 결과 Windows 입장에서는 vmmem이 메모리를 계속 점유하는 것으로 보이다.
2. 해결 전략 개요: .wslconfig로 WSL2 VM 자원 상한을 고정하다
가장 재현성과 효과가 큰 방법은 Windows 사용자 프로필 경로에 .wslconfig 파일을 생성하고, WSL2 VM에 할당 가능한 RAM·CPU·스왑 상한을 명시적으로 제한하는 방법이다.
.wslconfig는 WSL2로 실행되는 모든 배포판에 전역 적용되며, 특정 배포판 하나만이 아니라 WSL2 전체 동작 특성을 제어하다.
2-1. .wslconfig로 제어 가능한 자원 항목
| 항목 | 키 | 효과 | 권장 사용 상황 |
|---|---|---|---|
| 메모리 상한 | memory | WSL2 VM이 사용할 수 있는 RAM 최대치를 제한하다. | vmmem 메모리 폭주를 근본적으로 막아야 할 때 사용하다. |
| CPU 코어 상한 | processors | WSL2 VM이 사용할 논리 프로세서 수를 제한하다. | 빌드/테스트가 CPU를 독점해 Windows가 멈추는 상황에 사용하다. |
| 스왑 크기 | swap | WSL2 VM에 제공할 디스크 기반 스왑 크기를 설정하다. | 메모리를 낮추되 OOM을 줄이고 싶을 때 사용하다. |
| 스왑 파일 위치 | swapFile | 스왑 가상 디스크 파일 경로를 지정하다. | 시스템 드라이브 압박을 피하고 다른 드라이브로 분리할 때 사용하다. |
| 유휴 종료 시간 | vmIdleTimeout | VM이 유휴 상태일 때 종료되기까지의 시간을 설정하다. | WSL을 자주 켰다 껐다 하며 메모리 반환을 빠르게 유도하고 싶을 때 사용하다. |
3. 적용 전 준비: 현재 상태를 먼저 확인하다
3-1. Windows에서 실행 중인 배포판을 확인하다
PowerShell을 열고 현재 실행 중인 배포판이 있는지 확인하다.
wsl --list --running실행 중인 배포판이 없다면 “실행 중인 배포가 없습니다.”와 유사한 메시지가 보이다.
3-2. WSL 내부에서 메모리 관찰 기준을 잡다
WSL 터미널에서 다음 명령으로 메모리 상태를 확인하다.
free -h여기서 buff/cache가 큰 것은 Linux 설계상 자연스러운 경우가 많으며, Windows가 느려지는 수준인지 함께 판단해야 하다.
4. .wslconfig 생성과 메모리 제한 설정 절차
4-1. 파일 생성 위치가 핵심이다
.wslconfig는 다음 경로에 있어야 하다.
C:\Users\<사용자이름>\.wslconfig즉, %UserProfile% 경로 바로 아래에 위치해야 하다.
4-2. 가장 많이 쓰는 기본 템플릿이다
아래 예시는 RAM과 CPU, 스왑을 동시에 제한하는 가장 보편적인 설정이다.
[wsl2] memory=4GB processors=2 swap=2GB localhostForwarding=true4-3. 메모리만 강하게 잡고 싶을 때의 최소 설정이다
CPU는 제한하지 않고 메모리만 상한을 두고 싶다면 다음처럼 구성하다.
[wsl2] memory=6GB4-4. 스왑을 완전히 끄는 설정이다
디스크 스왑을 사용하지 않게 하려면 swap을 0으로 설정하다.
[wsl2] memory=4GB swap=04-5. 스왑 파일을 다른 드라이브로 옮기는 설정이다
시스템 드라이브 여유 공간이 부족하다면 스왑 파일 경로를 별도 드라이브로 지정하다.
[wsl2] memory=6GB processors=4 swap=4GB swapFile=D:\\wsl-swap\\swap.vhdx이때 D:\wsl-swap 폴더는 미리 생성해 두는 것이 안전하다.
5. 설정 적용 방법: 반드시 WSL2 VM을 완전히 재시작하다
5-1. 가장 확실한 적용 명령이다
.wslconfig 저장 후 PowerShell에서 다음을 실행해 WSL2 VM을 종료하다.
wsl --shutdown그 다음 WSL 배포판을 다시 실행하면 설정이 반영되다.
5-2. 특정 배포판만 즉시 끄고 싶을 때의 방법이다
여러 배포판을 동시에 운영 중이라면 특정 배포판만 종료할 수 있따.
wsl --terminate <배포판이름>5-3. “닫았는데도 적용이 안 되는” 대표 원인을 제거하다
WSL은 모든 셸 창을 닫아도 백그라운드에서 완전히 종료되기까지 시간이 걸릴 수 있따.
따라서 설정 변경 직후에는 wsl --list --running으로 완전 종료 여부를 확인하고, 필요하면 wsl --shutdown으로 강제 종료하는 방식이 가장 재현성이 높다.
6. 적용 확인 방법: Windows와 WSL 내부에서 각각 검증하다
6-1. WSL 내부에서 CPU 코어 제한이 반영되었는지 확인하다
nproc출력 값이 processors에 지정한 값과 일치하면 정상 반영이다.
6-2. WSL 내부에서 메모리 상한이 반영되었는지 확인하다
free -hTotal 항목이 memory 설정에 근접한 값으로 표시되면 정상 반영이다.
6-3. Windows 작업 관리자에서 체감 확인을 병행하다
작업 관리자에서 vmmem 또는 vmmemWSL의 메모리 상한이 이전보다 낮아지고, Windows가 메모리 압박 상태에서 회복되는지 확인하다.
7. 권장 설정 가이드: PC 메모리 용량별 현실적인 조합이다
아래 권장치는 “Windows 안정성 우선” 기준이며, WSL2에서 대규모 빌드를 자주 한다면 더 크게 잡아야 하다.
| PC RAM | 권장 memory | 권장 processors | 권장 swap | 설명 |
|---|---|---|---|---|
| 8GB | 2GB ~ 3GB | 1 ~ 2 | 1GB ~ 2GB | Windows가 쉽게 메모리 부족에 빠지므로 강한 제한이 필요하다. |
| 16GB | 4GB ~ 6GB | 2 ~ 4 | 2GB ~ 4GB | 개발·도커를 병행한다면 6GB까지는 실무적으로 무난하다. |
| 32GB | 8GB ~ 12GB | 4 ~ 8 | 4GB ~ 8GB | 대형 빌드와 컨테이너 다중 실행에 대응 가능하나 상한은 두는 편이 안정적이다. |
| 64GB 이상 | 16GB ~ 24GB | 8 이상 | 8GB 이상 | 자원이 충분해도 상한을 두면 폭주 상황에서 Windows 안정성이 유지되다. |
8. 실무 트러블슈팅: “설정했는데도 그대로”인 경우 점검하다
8-1. .wslconfig가 실제로 적용되지 않는 경우다
- 파일 위치가 C:\Users\<사용자이름>\.wslconfig 가 아닌 경우가 흔하다.
- 확장자가 숨겨져 .wslconfig.txt 로 저장된 경우가 흔하다.
- [wsl2] 섹션 헤더 오타가 있는 경우가 흔하다.
- 키 이름에 공백이나 잘못된 문자가 들어간 경우가 흔하다.
8-2. 설정 파일에는 설명 주석을 넣지 않는 편이 안전하다
환경에 따라 설정 파일 내 주석 문자가 파싱 문제를 만드는 경우가 보고되다.
따라서 설정 파일에는 값만 두고, 설명은 별도 문서에 관리하는 방식이 운영 안정성 측면에서 유리하다.
8-3. 스왑 파일이 계속 커지거나 공간을 잡아먹는 경우다
swap을 0으로 변경했다면, wsl --shutdown 이후 기존 스왑 가상 디스크 파일이 남아 있을 수 있따.
이 경우 WSL이 완전히 종료된 상태에서 swapFile 경로에 존재하는 swap.vhdx를 삭제하면 공간을 회수할 수 있따.
8-4. Docker Desktop 사용 시 자주 놓치는 포인트다
Docker Desktop이 WSL2 백엔드를 사용한다면, 컨테이너와 빌드가 모두 WSL2 VM 자원 상한의 영향을 받다.
즉, memory를 4GB로 제한하면 도커 빌드와 컨테이너 메모리 합도 그 안에서 경쟁하게 되다.
대형 이미지 빌드나 여러 컨테이너를 동시에 띄우는 환경이라면 memory와 swap을 더 크게 잡는 것이 장애를 줄이는 길이다.
9. 운영 팁: 제한 설정과 함께 쓰면 효과가 커지는 관리 루틴이다
9-1. “작업 끝나면 vmmem이 계속 남는” 상황을 빠르게 정리하다
WSL 작업을 마친 뒤 Windows 메모리 회수가 필요하면 다음 명령이 가장 확실하다.
wsl --shutdown이는 실행 중인 모든 배포판을 종료하므로, 중요한 작업이 없는 시점에 수행해야 하다.
9-2. VM 유휴 종료 시간을 단축해 자동 종료를 유도하다
WSL을 자주 켰다 끄는 사용 패턴이라면 vmIdleTimeout을 줄여 VM이 더 빨리 종료되도록 구성할 수 있따.
[wsl2] memory=6GB swap=2GB vmIdleTimeout=30000이 설정은 유휴 상태 판단과 실제 종료 동작이 환경에 따라 체감이 다를 수 있으므로, 적용 후 운영 패턴에 맞게 조정하는 것이 현실적이다.
FAQ
WSL2 메모리 제한을 걸면 Linux가 느려지지 않나?
제한값이 작업 부하에 비해 낮으면 성능 저하와 OOM이 발생하다. 반대로 Windows가 메모리 부족으로 느려지는 상황에서는 적절한 제한이 전체 체감 성능을 개선하다. 따라서 “Windows 안정성 확보 후 필요한 만큼 상향”하는 방식이 운영 친화적이다.
메모리 제한을 걸었는데도 vmmem이 바로 줄지 않는데 정상인가?
설정은 “상한”을 정하는 것이며, 이미 할당된 메모리가 즉시 반환되지 않을 수 있따. 가장 확실한 회수 방법은 wsl --shutdown으로 WSL2 VM을 종료하는 방식이다.
.wslconfig와 wsl.conf의 차이는 무엇인가?
.wslconfig는 WSL2 VM 자체에 적용되는 전역 설정이며, wsl.conf는 배포판 내부 /etc/wsl.conf에 두고 배포판별 동작을 조정하는 설정이다. 메모리 상한 같은 VM 자원 제한은 .wslconfig로 관리하는 것이 정석이다.
Docker Desktop을 쓰는데 memory를 어느 정도로 잡아야 하나?
컨테이너 수와 이미지 빌드 규모에 따라 달라지며, 16GB PC 기준으로는 memory 6GB~10GB, swap 2GB~6GB가 실무에서 자주 선택되다. 빌드가 자주 실패하거나 컨테이너가 OOM으로 죽는다면 memory 또는 swap을 단계적으로 올리는 방식이 가장 빠른 해결이다.
설정 파일을 바꿨는데도 적용이 안 되는 가장 흔한 원인은 무엇인가?
파일명이 .wslconfig.txt로 저장되거나, 경로가 %UserProfile% 바로 아래가 아닌 경우가 가장 흔한 원인이다. 탐색기에서 파일 확장명을 표시한 뒤 실제 파일명을 확인하고, wsl --shutdown으로 재시작하는 절차를 반드시 수행해야 하다.