WSL2 메모리 반환 안 됨 — 4일 만에 PC 전체가 느려진 이유

WSL2 메모리 반환이 꺼져 있으면 왜 PC가 느려지나?

WSL2 메모리 반환은 가상 머신이 다 쓴 메모리를 Windows에 되돌려 주는 동작입니다. .wslconfig 설정 파일에 autoMemoryReclaim이라는 줄이 없으면 이 동작은 기본으로 꺼져 있고, WSL은 한 번 손댄 메모리 페이지를 Windows에 잘 돌려주지 않습니다. 작업 관리자에 보이는 vmmem(WSL 가상 머신이 차지한 메모리) 값이 줄지 않고 오래 머무는 까닭이 여기 있습니다.

우리는 이 줄 하나가 빠진 PC를 4일 5시간 동안 켜 두었고, 마지막에는 Windows 전체가 심하게 느려졌습니다. 처음에는 다른 범인을 의심했고, 원인을 찾은 뒤에도 그 원인을 너무 세게 단정했다가 같은 날 스스로 정정했습니다. 이 글은 그 과정을 틀린 판단까지 포함해 순서대로 적은 기록입니다.

같은 PC에서 프로세스 하나가 수십 GB로 부풀어 가상 머신이 통째로 멈춘 다른 사고는 WSL 메모리 부족 멈춤 편에 따로 적었습니다. 그 글이 한 번에 터지는 사고라면, 이번 글은 며칠에 걸쳐 조금씩 조여 오는 사고입니다.

증상 — 4일 5시간 켜 둔 PC가 통째로 느려졌다

PC는 2026년 8월 17일 10:46에 켰고, 8월 21일 07:51에 결국 재부팅했습니다. 그 사이 4일 5시간 동안 한 번도 끄지 않았습니다. 마지막 날에는 특정 프로그램 하나가 아니라 PC 전체가 느렸습니다. 브라우저 탭을 넘기는 일도, 터미널에 글자를 치는 일도 한 박자씩 늦게 반응했습니다.

이런 랙은 원인을 짚기 어렵습니다. 에러 메시지도 없고, 멈춘 프로그램도 없습니다. 모든 것이 조금씩 느릴 뿐입니다. 그리고 재부팅하면 한동안 멀쩡해 보이기 때문에, 원인을 찾기 전에 증상부터 사라져 버립니다.

처음 의심한 것 — 여러 PC를 잇는 동기화 작업

가장 먼저 의심한 대상은 동기화 작업이었습니다. 우리는 회사 PC와 집 PC 사이에 설정과 작업 파일을 주기적으로 맞추는 예약 작업을 돌리고 있었고, 마침 그 무렵 이 동기화 쪽을 손보던 중이었습니다. 주기적으로 파일을 훑고 쓰는 작업이니 디스크와 CPU를 괴롭힐 만했습니다.

최근에 바꾼 것이 동기화다. 그러니 느려진 것도 동기화 때문이다.

그래서 동기화를 껐습니다. 원인 행위를 멈추면 증상도 멈춰야 합니다. 이 가설은 확인 방법이 간단하다는 점에서 좋은 가설이었습니다.

알리바이 — 동기화를 꺼도 랙은 그대로였다

동기화를 끈 뒤에도 PC는 계속 버벅였습니다. 원인을 멈췄는데 증상이 남는다면, 적어도 그것 하나로는 설명이 안 됩니다. 동기화 가설은 여기서 기각했습니다.

돌아보면 이 관찰 자체가 진짜 원인을 가리키는 단서였습니다. 「원인을 멈춰도 증상이 안 풀린다」는 모양은, 무언가가 이미 쌓여 있고 그것을 내보낼 길이 없다는 뜻일 수 있습니다. 당시에는 이 연결을 바로 떠올리지 못했습니다.

무엇으로 확인했나 — 안에서 본 메모리와 밖에서 본 메모리

다음으로 메모리를 의심했습니다. 확인 수단은 두 가지였습니다. WSL 안에서 리눅스 free 명령으로 본 메모리 사용량, 그리고 Windows 작업 관리자에서 본 vmmem 값입니다. 같은 가상 머신을 안과 밖에서 재는 셈이니, 두 값이 크게 다를 이유는 없다고 생각했습니다.

재부팅 직후 세션 8개를 띄우기만 한 상태에서 12분 동안 두 값을 나란히 봤습니다. Windows 쪽 vmmem은 16.4GB에서 20.9GB로, 12분 만에 4.5GB가 늘었습니다. 같은 12분 동안 WSL 안의 free는 「6.1GB used / 13GB free」를 보여 줬습니다. 안에서 보면 메모리가 넉넉했고, 밖에서 보면 빠르게 차오르고 있었습니다.

이 차이가 핵심이었습니다. free가 말하는 「여유」는 리눅스 입장에서 지금 쓰지 않는 메모리이고, vmmem은 Windows가 가상 머신에 내준 뒤 **아직 돌려받지 못한** 메모리입니다. 리눅스가 다 쓰고 비워 둔 페이지도, Windows에 반환하지 않으면 Windows 입장에서는 여전히 사용 중입니다. WSL 안의 free만 보고 판단하면 이 문제는 항상 「메모리 문제 아님」으로 오진하게 됩니다.

진짜 원인은 무엇이었나?

다음에 연 것은 설정 파일이었습니다. Windows 사용자 폴더의 .wslconfig에는 autoMemoryReclaim이라는 줄이 없었습니다. 이 설정이 없으면 기본값은 꺼짐이고, WSL은 한 번 손댄 페이지를 Windows에 돌려주지 않습니다. 그 결과 vmmem은 당시 상한 24GB를 향해 오랜 기간에 걸쳐 불어납니다.

계산은 단순합니다. 이 PC의 물리 메모리는 47.7GB입니다. vmmem이 상한 24GB에 닿으면 절반 가까이가 가상 머신에 묶이고, Windows는 나머지로 브라우저와 다른 프로그램을 돌려야 합니다. 모자라면 Windows가 디스크로 메모리를 밀어내는 스와핑을 시작하고, 그때부터 PC 전체가 느려집니다.

동기화를 꺼도 랙이 안 풀린 이유도 여기서 설명됩니다. 회복 경로는 재부팅이나 wsl --shutdown으로 가상 머신을 끄는 것뿐입니다. 메모리를 쓴 작업을 멈춰도, 이미 잡힌 메모리는 돌아오지 않습니다.

그럼 무엇이 그렇게 메모리를 썼을까요. 재부팅 5분 시점의 부하를 세어 봤습니다. Claude Code 세션 8개, MCP 서버 프로세스 65개, npm 실행기 하나가 1.43GB, 예약 작업 목록 142줄이었습니다. MCP 서버는 세션마다 따로 떴습니다. 구글 계정 연동 7개, 브라우저 조작용 playwright 7개, 문서 검색용 context7 7개처럼, 같은 도구가 세션 수만큼 겹쳐 있었습니다.

다만 우리는 세션 수 자체를 범인으로 보지 않았습니다. 일을 시키는 만큼 메모리를 쓰는 것은 정상입니다. 문제는 그 부하가 만든 메모리가 **돌아오지 않는** 구조였습니다.

그 원인도 처음엔 과장했다 — 같은 날의 정정

처음 적은 기록에는 「vmmem은 천장까지 단조 증가하고, 한번 붙으면 절대 내려오지 않는다」고 썼습니다. 같은 날 08:37에 이 서술을 스스로 고쳤습니다. 재부팅 후 4.5시간을 더 지켜보니, vmmem이 20.9GB에서 17.1GB로, 다시 10.96GB로 크게 떨어졌습니다. 회수 설정은 아직 꺼진 채였는데도 그랬습니다. 20.9GB에서 18.05GB로 내려가는 구간도 따로 관측했습니다.

그래서 모양을 다시 적었습니다. 매 순간 오르는 것이 아니라, 오르내리면서 **바닥이 조금씩 올라가고 내려오는 폭이 줄어드는** 형태에 가깝습니다. 4일이면 천장에 닿을 수 있다는 결론은 남지만, 「절대 안 내려온다」는 틀린 말이었습니다.

더 중요한 정정은 확정도입니다. 4일 만에 랙이 온 것은 사실이지만, 그 경로가 vmmem 누적 하나였는지는 그날 데이터로 가를 수 없었습니다. 디스크 입출력, CPU 포화, Windows 쪽 요인도 후보로 남습니다. 그래서 이 글의 원인은 **유력 가설**이지 확정이 아닙니다. autoMemoryReclaim이 빠져 있던 것은 원인 판정과 상관없이 확정된 결함이라, 이것은 먼저 고치기로 했습니다.

어떻게 고쳤나 — 그리고 고치다가 한 번 더 틀렸다

고치는 과정에서 더 불편한 사실이 나왔습니다. 2026년 6월 16일에 만든 설정 사본(.wslconfig.bak, 820B)에 이미 정답이 들어 있었습니다. 주석에는 「재부팅해도 40% 점유 메커니즘 해소」라고 적혀 있었습니다. 그런데 8월 21일의 실제 파일은 48B였고, [experimental] 블록이 통째로 없었습니다. 두 달 전에 이미 맞는 답을 냈고, 그 답이 사라진 것을 아무도 몰랐습니다.

언제 사라졌는지는 확정하지 못했습니다. 남아 있는 작업 기록 안에서는 이 파일을 쓴 흔적이 0건이었습니다. 다만 7월 말에 swap을 16GB에서 8GB로 줄이는 대안을 검토한 적이 있고, 사라진 파일의 swap=8GB가 정확히 그 값입니다. swap을 줄이면서 파일을 통째로 새로 쓸 때 [experimental] 블록이 함께 날아갔다고 보는 편이 가장 잘 맞습니다. 이것은 추정입니다.

그리고 같은 날 한 번 더 틀렸습니다. 설정을 다시 넣으면서 두 줄을 [wsl2] 섹션 아래에 적었습니다. Microsoft 공식 문서(2026년 6월 2일 갱신본)를 보면 autoMemoryReclaim과 sparseVhd는 [experimental] 섹션에서만 듣는 설정이고, [wsl2]에 적으면 오류 없이 조용히 무시합니다. 파일을 열면 글자는 보이는데, 설정은 듣지 않는 상태였습니다. 6월 16일 판이 맞았고, 다시 넣은 판이 틀렸습니다.

최종적으로는 두 줄을 6월 16일 사본처럼 [experimental] 섹션 아래로 옮겼습니다. 회귀를 고치던 동작이 새 회귀를 만들 뻔했다는 점이 이 단계의 교훈입니다.

같은 실수를 막는 장치는 무엇인가?

설정이 두 번 사라진 이유를 따져 보니, 세 가지가 동시에 없었습니다. 첫째, 사본이 없었습니다. .wslconfig는 설정 백업 대상이 아니어서 지워져도 비교할 대상이 없었습니다. 둘째, 계측이 없었습니다. vmmem 추이를 아무도 재지 않아 설정이 듣는지 알 방법이 없었습니다. 셋째, 감시가 없었습니다. 기존 메모리 감시는 프로세스를 강제 종료한 횟수만 봐서, 이런 느린 누적에는 침묵했습니다.

그래서 세 층을 붙였습니다.

• ① 사본 — 설정 백업 스크립트가 .wslconfig를 참고용 사본으로 함께 보관합니다. 자동 복원은 하지 않습니다. PC마다 메모리 크기가 달라 같은 값을 덮어쓰면 안 되기 때문입니다.
• ② 계측 — 30분마다 도는 예약 작업이 vmmem 크기, 가동 시간, 회수 설정이 실제로 켜져 있는지를 시계열로 기록합니다.
• ③ 감시 — 매일 보는 운영 현황판이 그 기록을 읽어 설정 실효성·가동 일수·점유율 3가지 축으로 경고를 띄웁니다.

설정 실효성 검사는 키 이름만 찾지 않고 **그 키가 어느 섹션 아래 있는지**까지 봅니다. 「글자는 있는데 안 듣는」 상태를 잡으려면 이 검사가 필요합니다. 일부러 틀린 설정 6가지를 넣어 검사가 전부 잡아내는지 확인하는 반증 시험도 통과시켰습니다. 원인 판정은 이 계측이 며칠 쌓인 뒤 vmmem·swap·부하·디스크 대기 상태·설정 실효성 5가지 축을 함께 보고 다시 할 계획입니다.

평소에 WSL 가상 머신의 캐시를 주기적으로 덜어 내는 다른 방법은 vmmem 메모리 자동 회수 편에 적었습니다. 사내 PC에서 AI 도구와 자동화 작업을 함께 돌리다 비슷하게 점점 느려지는 문제를 겪고 있다면 상담으로 상황을 알려 주셔도 됩니다.

WSL2가 점점 느려질 때 무엇부터 확인하나?

같은 증상을 겪는 분을 위해 점검 순서를 정리합니다.

• WSL 안의 free만 보고 「메모리 여유 있음」이라 결론 내지 않습니다. Windows 작업 관리자의 vmmem 값을 같은 시각에 함께 봅니다.
• 사용자 폴더의 .wslconfig를 열어 autoMemoryReclaim이 있는지 봅니다. 없으면 기본값은 꺼짐입니다.
• 있다면 그 줄이 [experimental] 섹션 아래 있는지 확인합니다. [wsl2] 아래 있으면 오류 없이 무시당합니다.
• 설정 파일을 손으로 고칠 때는 파일 전체를 새로 쓰지 말고, 바꿀 줄만 고칩니다. 다른 블록이 함께 사라지기 쉽습니다.
• 원인 작업을 멈췄는데도 느리다면, 쌓인 메모리가 안 돌아오는 상황을 의심합니다. 이때 회복 방법은 wsl --shutdown 또는 재부팅입니다.

남는 한계는 무엇인가?

첫째, 랙의 원인은 아직 유력 가설입니다. 회수 설정이 꺼진 상태에서도 vmmem이 10.96GB까지 내려간 관측이 있었고, 디스크 입출력이나 Windows 쪽 요인을 배제할 데이터는 아직 없습니다. 계측이 쌓인 뒤 판정이 바뀔 수 있습니다.

둘째, 설정이 언제 사라졌는지는 추정입니다. swap 값이 일치한다는 정황은 강하지만, 파일을 쓴 기록 자체는 남아 있지 않습니다.

셋째, 이번 일에서 얻은 가장 큰 교훈은 메모리가 아니라 설정 관리에 있습니다. 설정을 「넣었다」로 끝내면, 그 설정이 살아 있는지 재는 장치가 없는 한 언젠가 조용히 사라집니다. 그리고 몇 달 뒤 같은 사고로, 처음 보는 문제처럼 돌아옵니다. 다시 찾는 데 드는 비용은 처음 진단한 비용과 같습니다.