윈도우 업데이트 배달 최적화(Delivery Optimization) 피어 캐시 충돌 해결 방법

날짜:

WSL2 메모리 과다 점유 해결: .wslconfig로 RAM 제한하고 VmmemWSL 줄이는 방법

날짜:

이 글의 목적은 WSL2가 호스트 메모리를 과다 점유하는 상황에서, Windows 사용자 프로필의 .wslconfig 설정으로 WSL2 VM의 최대 RAM·스왑을 제한하고, 필요 시 메모리 반환(리클레임)까지 안정적으로 적용하는 절차를 정리하는 것이다.

1. WSL2 메모리 과다 점유가 발생하는 대표 상황

WSL2는 Linux 커널이 Hyper-V 기반의 경량 VM 안에서 동작하며, Linux의 페이지 캐시(파일 캐시) 특성 때문에 “사용 중인 것처럼” 보이는 메모리가 크게 늘어날 수 있다. 특히 Docker 컨테이너, 대용량 빌드, 패키지 설치, 데이터 전처리, 모델 학습 등 디스크 I/O가 많은 작업을 수행하면 캐시가 빠르게 커지며 Windows 작업 관리자에서는 VmmemWSL(또는 vmmem)이 지속적으로 RAM을 점유하는 형태로 관찰되곤 하다.

문제는 “작업이 끝난 뒤에도” 메모리가 즉시 줄지 않아, 다른 Windows 애플리케이션이 메모리 부족을 겪거나 페이징이 급증하는 경우이다. 이때 가장 확실하고 재현성 있는 1차 대응은 .wslconfig로 WSL2가 사용할 수 있는 메모리 상한을 명확히 지정하는 것이다.

주의 : .wslconfig는 “WSL2 VM이 시작될 때”만 읽히는 전역 설정 파일이다. 파일만 수정하고 WSL을 종료하지 않으면 적용되지 않는다.

2. .wslconfig와 wsl.conf의 차이

.wslconfig는 Windows 쪽에 위치하며 WSL2 VM 자원(RAM/CPU/스왑 등)에 영향을 주는 전역 설정이다. 반면 wsl.conf는 Linux 배포판 내부(/etc/wsl.conf)에 존재하며 배포판별 마운트/네트워크/interop 등 동작 설정에 초점이 있다. “메모리 제한” 목적이라면 .wslconfig를 사용해야 한다.

3. .wslconfig 파일 위치와 작성 규칙

3.1 파일 위치

Windows 사용자 프로필 루트에 생성해야 한다. 경로 예시는 다음과 같다.

C:\Users\<사용자이름>\.wslconfig

3.2 인코딩과 형식

일반 텍스트(ANSI/UTF-8)로 작성해도 무방하나, 줄바꿈과 섹션 표기([wsl2], [experimental])를 정확히 지켜야 한다. 확장자는 없으며 파일명은 반드시 “.wslconfig” 그대로여야 한다.

4. 메모리 제한의 핵심: [wsl2] memory, swap, processors

가장 많이 사용하는 설정은 memory(최대 RAM), swap(스왑 크기), processors(가상 CPU 코어 수)이다. 메모리 과다 점유를 억제하려면 memory를 먼저 고정하고, 스왑은 사용 목적에 따라 최소화하거나 정책적으로 끄는 방식으로 접근하는 것이 일반적이다.

키 섹션 의미 권장 사용 예 주의사항
memory [wsl2] WSL2 VM이 사용할 최대 RAM 상한 memory=6GB, memory=50% 너무 낮으면 빌드/컨테이너가 OOM으로 실패할 수 있다.
processors [wsl2] WSL2 VM에 할당할 최대 vCPU 코어 수 processors=4 너무 낮으면 병렬 작업 성능이 급감할 수 있다.
swap [wsl2] WSL2 스왑 파일 크기 swap=0, swap=1GB swap=0은 메모리 부족 시 바로 OOM을 유발할 수 있다.
swapFile [wsl2] 스왑 파일의 위치(경로) swapFile=C:\\wsl\\wsl.swap 디스크 여유 공간과 권한 문제가 없도록 경로를 관리해야 한다.
localhostForwarding [wsl2] WSL2에서 Windows 로컬호스트 포트 포워딩 사용 localhostForwarding=true 대부분 기본값으로 충분하나 환경에 따라 접근성이 달라질 수 있다.

5. 실전 권장 .wslconfig 예시

5.1 안정형(대부분의 개발 PC에 권장)

호스트 RAM이 16GB~32GB인 일반 개발 환경에서 WSL2 메모리를 과다 점유하지 않도록 상한을 두고, 스왑을 최소 수준으로 제공하는 구성이다.

[wsl2] memory=8GB processors=4 swap=1GB localhostForwarding=true

5.2 강력 제한형(Windows 앱 우선, WSL은 보조)

Windows 쪽 애플리케이션(브라우저, 오피스, CAD 등)을 최우선으로 두고 WSL2는 가볍게만 쓰는 환경에서 사용한다.

[wsl2] memory=4GB processors=2 swap=0 localhostForwarding=true
주의 : swap=0은 메모리 부족 상황에서 컨테이너나 빌드가 즉시 실패할 수 있다. “느려져도 일단 버티는 것”이 필요한 작업이라면 swap을 512MB~2GB 정도로 남기는 편이 안전하다.

5.3 Docker/대용량 빌드용(WSL 작업이 주력)

WSL2에서 Docker 엔진을 많이 돌리거나 대규모 컴파일이 잦다면, 상한을 넉넉히 두되 “무제한”은 피하는 방식이 운영 안정성이 좋다.

[wsl2] memory=16GB processors=8 swap=2GB localhostForwarding=true

6. 메모리 “반환”까지 고려한다면: [experimental] autoMemoryReclaim

메모리 과다 점유 문제는 상한 설정만으로도 상당 부분 개선되지만, 작업 후 캐시가 커진 상태에서 Windows로 메모리가 빨리 돌아오길 원한다면 자동 메모리 반환 기능을 추가로 고려할 수 있다. 이 기능은 .wslconfig의 [experimental] 섹션에 설정한다.

[wsl2] memory=8GB processors=4 swap=1GB [experimental] autoMemoryReclaim=gradual
주의 : autoMemoryReclaim를 [wsl2] 섹션에 넣으면 “Unknown key” 경고가 발생할 수 있다. 반드시 [experimental] 섹션에 작성해야 하며, 사용 중인 WSL 버전이 해당 설정을 지원해야 한다.

7. 적용 절차: 설정 반영을 확실히 하는 종료·재시작

.wslconfig 변경 후에는 WSL2 VM을 완전히 종료해야 한다. 가장 단순하고 확실한 절차는 다음과 같다.

1) .wslconfig 저장 2) PowerShell(또는 CMD)에서 실행 wsl --shutdown 3) WSL 재실행(예: Ubuntu 실행 또는 wsl 실행) 4) 적용 확인

환경에 따라 서비스 재시작이 필요할 때도 있다. 관리자 PowerShell에서 다음을 추가로 사용할 수 있다.

Restart-Service LxssManager

8. 적용 확인 방법

8.1 Windows에서 확인

작업 관리자에서 VmmemWSL의 메모리 상한이 “대략적으로” 제한되는지 확인한다. 단, 순간적으로는 캐시/버퍼 영향으로 보이는 값이 출렁일 수 있으므로, 장시간 작업 후에도 상한을 넘어 지속 점유하는지 관찰하는 것이 중요하다.

8.2 Linux 내부에서 확인

WSL 배포판에서 다음 명령으로 메모리 총량이 제한된 값으로 보이는지 확인한다.

free -h

9. 자주 겪는 문제와 해결

9.1 .wslconfig를 만들었는데 변화가 없다

가장 흔한 원인은 경로/파일명이 틀리거나, WSL을 종료하지 않은 경우이다. 파일명은 반드시 .wslconfig여야 하며, 위치는 C:\Users\<사용자>\ 루트여야 한다. 저장 후 wsl --shutdown을 수행해야 한다.

9.2 “Unknown key” 경고가 뜬다

섹션 위치가 잘못되었거나, 현재 설치된 WSL이 해당 키를 지원하지 않는 경우이다. 특히 autoMemoryReclaim는 [experimental]에 있어야 하며, 오래된 WSL 구성에서는 인식되지 않을 수 있다.

9.3 Docker가 불안정해진다

자동 메모리 반환 기능이 특정 구성에서 Docker 데몬 동작에 영향을 주는 사례가 보고된 바 있다. 이 경우 autoMemoryReclaim를 제거하고, memory 상한 설정만으로 운용 안정성을 확보한 뒤 증상을 재평가하는 방식이 안전하다.

10. 운영 팁: 메모리 점유를 “관리 가능한 수준”으로 유지하는 습관

10.1 상한은 반드시 둔다

메모리 무제한은 단기 성능은 좋을 수 있으나, 장기 운영에서는 Windows 전체 성능을 흔드는 원인이 된다. 호스트 RAM의 40~60% 범위 안에서 memory를 잡고, 작업 성격에 따라 조정하는 것이 실무적으로 가장 안정적이다.

10.2 스왑은 0 또는 소형으로 관리한다

스왑이 크면 “죽지 않고 버티는” 대신 디스크를 과도하게 사용하여 체감 성능이 급락할 수 있다. 반대로 swap=0은 즉시 실패를 유발할 수 있으므로, 실패가 곧바로 큰 손실로 이어지는 작업이라면 512MB~2GB 정도의 작은 스왑이 균형점이 되곤 하다.

10.3 작업 종료 후 즉시 회수가 필요하면 종료가 가장 확실하다

급하게 Windows 메모리를 확보해야 한다면, 가장 확실한 방법은 WSL을 종료하는 것이다.

wsl --shutdown
주의 : wsl --shutdown은 실행 중인 배포판과 작업을 모두 종료한다. 백그라운드 서비스나 실행 중인 컨테이너가 있다면 중단 영향을 반드시 고려해야 한다.

FAQ

memory=50%처럼 퍼센트로도 설정할 수 있나?

가능한 환경에서는 퍼센트 표기가 지원되며, 호스트 메모리 기준 비율로 상한을 둘 수 있다. 다만 조직 표준 운영에서는 “예상 가능한 고정 값(예: 8GB, 16GB)”이 장애 재현과 성능 기준 관리에 유리하다.

메모리 제한을 걸면 WSL이 더 느려지나?

상한이 충분하면 체감 성능 영향은 제한적이다. 다만 컨테이너를 많이 띄우거나 대규모 빌드를 수행할 때 상한이 빡빡하면 캐시 효율이 떨어지고 OOM이 발생할 수 있다. 작업 패턴에 맞춰 상한과 processors를 함께 조정하는 것이 실무적으로 중요하다.

.wslconfig를 바꿨는데 일부 배포판만 다르게 동작하나?

.wslconfig는 WSL2 VM 전역에 적용되므로 기본적으로 모든 WSL2 배포판에 동일하게 반영된다. 배포판별 동작 차이는 wsl.conf 설정이나 배포판 내부 서비스 구성 차이에서 오는 경우가 많다.

autoMemoryReclaim를 켜면 항상 좋은가?

메모리 반환에 도움이 될 수 있으나, 환경에 따라 호환성 이슈가 보고된 바 있다. 운영 안정성이 최우선이라면 memory 상한 설정을 1차로 적용하고, 그 다음에 autoMemoryReclaim를 단계적으로 도입하는 방식이 안전하다.

:
추천·관련글