WSL2 메모리 사용량 줄이는 법: .wslconfig 제한 설정과 자동 회수 옵션 비교

WSL2 메모리 사용량 줄이는 법은 메모리 상한과 캐시 자동 회수를 구분하는 데서 시작한다. Windows가 버벅인다면 memory로 사용 상한을 조정하고, 빌드가 끝난 뒤에도 메모리가 높게 남는다면 autoMemoryReclaim과 실제 실행 프로세스를 함께 확인하면 된다.

이 글은 설정 방법을 찾는 탐색형 검색 의도에 맞춰 사용량 확인 → 옵션 비교 → 설정 변경 → 재시작 → 적용 확인 순서로 구성했다. 2026년 Microsoft 공식 문서의 기본값을 기준으로 설명하며, 설정 예시의 용량은 모든 PC에 통하는 권장값이 아니라 조정 방법을 보여 주는 값이다.

1. WSL2 버전과 메모리 사용량부터 확인하기

작업 관리자에서 WSL 관련 메모리가 크게 보인다는 이유만으로 메모리 누수라고 판단하기는 어렵다. Linux는 파일 읽기와 빌드 과정에서 캐시를 활용하므로, 작업이 끝난 시점의 프로세스 사용량과 캐시를 나눠 살펴보는 편이 정확하다.

PowerShell에서 WSL 버전과 배포판 방식 확인

wsl --version
wsl --list --verbose
winver

wsl --version은 설치된 WSL 구성 요소의 버전을 보여 준다. 반면 wsl --list --verbose의 VERSION 열은 Ubuntu 등 각 배포판이 WSL1인지 WSL2인지를 나타낸다. 두 숫자는 의미가 다르므로 함께 기록해야 한다.

.wslconfig의 전역 설정은 Windows 빌드 19041 이상에서 WSL2 배포판을 대상으로 한다. memory와 swap은 [wsl2], 자동 회수는 [experimental]에 작성한다. 현재 공식 옵션 표에는 autoMemoryReclaim에 별도의 Windows 11 전용 표시가 없지만, 오래된 WSL에 최신 문서의 기능과 기본값이 그대로 적용된다고 가정해서는 안 된다.

wsl --version이 인식되지 않으면 구형 Windows 기본 제공 WSL일 가능성이 있다. 이때는 지원되는 환경에서 wsl --update로 업데이트한 뒤 버전을 다시 확인한다. 업데이트가 조직 정책으로 관리된다면 해당 정책을 먼저 따른다.

작업 관리자와 Linux 수치를 함께 읽는 방법

Windows 작업 관리자에서는 환경에 따라 VmmemWSL 또는 Vmmem으로 표시되는 항목과 시스템 전체 메모리 사용 상태를 확인한다. WSL 터미널에서는 다음 명령으로 내부 상태를 확인한다.

free -h
ps -eo pid,comm,rss --sort=-rss | head -n 11

free -h의 available은 새 작업에 사용할 수 있는 메모리를 판단하는 데 유용하고, buff/cache는 버퍼와 캐시 상태를 보여 준다. 프로세스 목록의 rss는 일반적으로 KiB 단위이므로, 사람이 읽기 좋은 단위로 표시되는 free -h와 숫자만 그대로 비교하지 않는다.

작업 관리자는 호스트에서 본 가상 머신의 메모리를, Linux 명령은 게스트 내부의 상태를 보여 준다. 집계 범위와 갱신 시점이 달라 두 값이 정확히 일치할 필요는 없다. 같은 빌드를 실행하기 전, 실행 중, 종료 후의 흐름을 비교하면 캐시가 남은 것인지 실행 중인 서비스가 계속 메모리를 쓰는지 구분하기 쉽다.

1. WSL2 버전과 메모리 사용량부터 확인하기

2. .wslconfig 메모리 제한과 자동 회수 옵션 비교

메모리 상한은 사용할 수 있는 최대 용량을 정하고, 자동 회수는 캐시를 반환하는 방식을 정한다. 서로 대체하는 옵션이 아니므로 함께 설정할 수 있다. 제목의 비교 대상은 아래 5개 항목으로 나눠 보면 차이가 분명해진다.

공식 기본값을 단순 계산하면 Windows RAM이 16GB인 PC의 메모리 상한은 8GB, 스왑 크기는 4GB다. 이는 기본 설정을 설명하는 계산 예시이며, WSL이 시작하자마자 RAM 8GB를 모두 사용한다는 뜻은 아니다. memory=4GB 역시 4GB를 항상 점유시키는 설정이 아니라 사용 상한을 제한한다.

실무적으로는 작업 후 남는 캐시와 작업 중 필요한 메모리를 따로 다루는 편이 유리하다. 캐시 반환이 문제인데 상한만 크게 낮추면, 빌드가 진행되는 동안 사용할 공간까지 줄어든다. 반대로 실행 중인 데이터베이스나 개발 서버가 메모리를 점유한다면 캐시 회수 옵션만으로 해결하기 어렵다.

2026년 기준으로 주목할 변화는 자동 회수를 무조건 새로 켜야 하는 기능으로 설명할 수 없다는 점이다. 현재 Microsoft 문서는 dropCache를 기본값으로 안내한다. 따라서 같은 값을 추가하는 작업보다 기존 파일의 disabled 설정, WSL 버전, 실제 캐시 상태를 확인하는 과정이 먼저다.

출처: Microsoft Learn 「Advanced settings configuration in WSL」의 Main WSL settings 및 Experimental settings. 2026년 10월 확인 기준.

2. .wslconfig 메모리 제한과 자동 회수 옵션 비교 바로가기

3. .wslconfig 파일 위치와 메모리 제한 설정 방법

Microsoft는 현재 시작 메뉴의 WSL Settings에서 설정을 변경하는 방법을 권장한다. 해당 앱이 제공되는 환경에서는 설정 화면을 먼저 확인하고, 파일로 값을 관리해야 할 때 아래 절차를 사용하면 된다. 같은 항목을 화면과 파일에서 번갈아 수정했다면 최종 저장값을 다시 확인한다.

1. Windows 파일 탐색기 주소창에 %UserProfile%을 입력한다.
2. 기존 .wslconfig가 있으면 복사본을 만들어 보관한다.
3. 파일이 없으면 해당 폴더에 .wslconfig를 만든다.
4. 파일 확장명을 표시해 .wslconfig.txt로 저장되지 않았는지 확인한다.
5. 기존 섹션이 있다면 해당 섹션 안의 값을 수정하고, 같은 키를 중복해서 추가하지 않는다.

다음은 메모리 상한을 4GB로 제한하면서 캐시를 점진적으로 회수하는 구성 예시다. 스왑은 원인 구분을 쉽게 하기 위해 이 예시에서 변경하지 않는다. 기존 파일에 별도의 swap 값이 있다면 그 값은 그대로 유지된다.

[wsl2]
memory=4GB

[experimental]
autoMemoryReclaim=gradual

현재 기본 회수 방식을 명시적으로 유지하고 싶다면 마지막 줄만 autoMemoryReclaim=dropCache로 바꾼다. 처음에는 회수 방식과 메모리 상한을 한 번에 모두 바꾸기보다 하나씩 변경해야 결과를 해석하기 쉽다. 특히 기존 기본 상한이 4GB 이하인 환경에서는 memory=4GB가 사용량을 줄이는 설정이 아닐 수 있다.

3. .wslconfig 파일 위치와 메모리 제한 설정 신청하기

4. wsl --shutdown으로 재시작하고 설정 적용 확인하기

파일을 저장해도 실행 중인 WSL 가상 머신의 설정이 즉시 바뀌지는 않는다. 공식 문서는 모든 셸을 닫은 뒤 완전히 종료되기까지 통상 약 8초가 필요하다고 설명한다. 백그라운드 작업이 남을 수 있으므로, 작업을 저장하고 관련 서비스를 정리한 다음 PowerShell에서 명시적으로 종료하는 방법이 확실하다.

wsl --shutdown
wsl --list --running

wsl --shutdown은 실행 중인 모든 배포판과 WSL2 가상 머신을 종료한다. WSL에서 실행하던 개발 서버, 데이터베이스, Docker 관련 작업도 영향을 받을 수 있으므로 저장되지 않은 작업부터 정리한다. 이후 사용하는 배포판을 다시 실행한다.

Linux 터미널에서 아래 명령을 실행해 메모리와 스왑 상태를 확인한다. 메모리 총량은 커널 예약 등의 영향으로 설정한 숫자보다 조금 작게 표시될 수 있으므로, 정확히 같은 문자열이 나오는지를 기준으로 판단하지 않는다.

free -h
grep -E 'MemTotal|MemAvailable|Cached|SwapTotal|SwapFree' /proc/meminfo
swapon --show

free -h만으로 자동 회수 모드가 적용됐다고 확정할 수는 없다. 동일한 빌드를 실행한 뒤 작업을 멈추고, 일정한 관찰 간격으로 캐시와 Windows 작업 관리자 수치를 기록한다. 공식 문서의 ‘즉시 회수’는 회수 방식에 대한 설명이며, 설정 저장 직후 작업 관리자 값이 곧바로 특정 수치까지 내려간다는 보장은 아니다.

• 메모리 총량이 예상 범위인가: 파일 위치, 확장명, [wsl2] 구문을 점검한다.
• 작업 종료 후 캐시와 호스트 사용량이 줄어드는가: 실제로 남아 있는 서비스와 함께 확인한다.
• 같은 빌드의 완료 시간과 성공 여부가 유지되는가: 메모리 절감과 작업 성능을 함께 평가한다.
• 스왑 사용이 늘고 디스크 작업이 많아졌는가: 상한이 지나치게 낮은지 검토한다.

5. WSL2 빌드 실패·성능 저하를 막는 조정과 복구

메모리 제한을 낮춘 뒤 컴파일러가 종료되거나 빌드 중 Killed 메시지가 나타난다면 메모리 부족을 의심할 수 있다. 다만 해당 메시지만으로 원인을 확정하지 말고, 가능한 환경에서 커널 로그를 함께 확인한다.

sudo dmesg | grep -Ei 'out of memory|oom|killed process'

메모리 부족이 확인되면 먼저 memory 상한을 높이거나 빌드 도구의 병렬 작업 수를 줄인다. 스왑을 과도하게 사용하며 느려지는 경우에도 메모리 상한과 동시 실행 작업을 먼저 점검한다. swap=0은 스왑 파일을 끄는 설정이므로, RAM이 부족한 상태에서 적용하면 작업을 버틸 여유가 더 줄 수 있다.

반복 빌드가 느려졌다면 캐시 회수 방식도 비교할 대상이다. dropCache에서 gradual로 바꾼 뒤 같은 조건으로 재실행해 완료 시간과 Windows의 메모리 여유를 기록한다. 캐시 재사용 효과는 작업마다 다르므로, 특정 옵션이 항상 빠르거나 메모리를 일정 비율 줄인다고 단정할 근거는 없다.

설정 이전 상태로 복구하는 순서

1. 보관한 .wslconfig 복사본을 원래 위치에 복원한다.
2. 복사본이 없다면 이번에 추가한 memory, swap, autoMemoryReclaim 항목만 제거한다.
3. 작업을 저장하고 PowerShell에서 wsl --shutdown을 실행한다.
4. 배포판을 다시 열어 메모리 총량과 기존 작업의 정상 동작을 확인한다.

설정 파일 전체를 비활성화하면 다른 네트워크·프로세서 설정도 영향을 받을 수 있다. 기존 설정이 많은 환경에서는 변경한 항목만 되돌리는 편이 복구 범위를 명확하게 유지한다. 또한 자동 회수 항목을 지우는 것은 자동 회수를 끄는 것과 다르며, 설치된 WSL 버전의 기본 동작으로 돌아가는 의미다.

5. WSL2 빌드 실패·성능 저하를 막는 조정과 복구 조회하기