AI 코딩 에이전트를 여러 개 병렬로 장기 운용하다 보면, WSL2 측에 로그나 캐시가 계속 쌓이게 됩니다. 어느 날 C 드라이브의 여유 공간이 이상하게 적다는 것을 깨닫고 조사해 보니, "WSL 내에서 파일을 삭제해도 C 드라이브의 여유 공간은 늘어나지 않는다"라는, 아는 사람에게는 상식이지만 모르면 막막해지는 동작에 부딪혔습니다. 이 기사는 그 원인과 대처법에 대한 메모입니다.

전제: WSL의 가상 디스크는 "줄어들지 않는다"

WSL2는 Linux 환경을 vhdx 형식의 가상 디스크 파일로서 호스트 OS (Windows) 상에 가지고 있습니다. 까다로운 점은, WSL 내에서 큰 파일을 삭제하더라도 vhdx 파일 자체의 크기는 자동으로 축소되지 않는다는 점입니다. 내용물이 비워져도 외부의 상자는 부풀어 있는 상태 그대로 유지됩니다.

AI 에이전트를 장기 운용하다 보면 이 상자가 서서히 부풀어 오릅니다. 실행 로그, 의존성 패키지의 캐시, 일시적으로 생성한 검증용 데이터 등, 매일의 작업에서 만들고 지우기를 반복하는 파일들이 쌓이면서 C 드라이이브의 여유 공간만 줄어드는 상태가 되었습니다.

실행한 것: TRIM하고, 셧다운하고, 압축하기

대처법은 3단계입니다.

• WSL 내에서
  fstrim -av

를 실행하여 삭제되었으나 사용되지 않게 된 블록을 가상 디스크 측에 통지한다 -
wsl --shutdown

으로 WSL을 완전히 정지한다 (기동 중인 상태에서는 가상 디스크를 조작할 수 없다) -
Windows 측에서
diskpart

를 사용하여 vhdx 파일에 대해
compact vdisk

를 실행하여 물리적 크기를 축소한다

포인트는 이 절차를 Hyper-V의 추가 모듈을 활성화하지 않고도 실행할 수 있다는 점입니다. diskpart는 표준 탑재된 도구이므로, 불필요한 기능을 활성화하지 않고도 압축까지 완결할 수 있었습니다.

효과

C 드라이브의 여유 공간이 명확하게 회복되었습니다. 내용물을 지워도 외부가 부풀어 있는 상태였던 상자가, 이제는 외부도 제대로 줄어드는 상태가 되었다는 뜻입니다. 에이전트를 여러 개 돌리고 있는 환경에서는 이 차이가 체감될 정도로 느껴졌습니다.

주의한 점: "영구 대책"을 곧이곧대로 믿지 않기

조사하는 과정에서, vhdx를 처음부터 가변 크기가 아닌 sparse (희소) 형식으로 변환하면 압축하는 수고 자체가 필요 없어진다는 "영구 대책" 정보도 접하게 되었습니다. 얼핏 좋아 보이지만, 실제로 검토해 보니 변환 후의 동작이나 도구의 대응 상황이 수동 압축만큼 성숙(mature)해 있지 않아, 현재의 운용에 도입하기에는 아직 불확실성이 남아 있다고 판단했습니다.

대신 선택한 것은, "수동으로 고치기"를 "정기적으로 감시하고 필요할 때 고치기"로 바꾸는 것이었습니다. vhdx의 크기를 정기적으로 확인하고, 임계값을 넘으면 알림을 주는 메커니즘을 구축했습니다. 단번에 끝나는 마법 같은 영구 대책을 찾는 것보다, 수수하더라도 지속적으로 지켜보는 것이 현재의 제 운용에는 더 현실적이었습니다.

배움

• WSL2의 가상 디스크는 "안을 지운다고 밖도 줄어드는" 것이 아니다. 이를 모르면 삭제해도 줄어들지 않는 여유 공간 때문에 끊임없이 고민하게 된다.
• 압축 자체는 Hyper-V의 추가 기능 없이도 표준 도구의 조합 (TRIM → 셧다운 → compact vdisk)으로 완결된다.
• "영구적으로 해결하는 설정"보다 "정기적으로 상태를 지켜보며 대처하는 운용"이, 아직 성숙하지 않은 수법에 도박을 거는 것보다 더 확실할 때가 있다.

AI 에이전트를 장시간 돌리는 환경일수록, 이런 수수한 디스크 운용의 차이가 효과를 발휘합니다.

Discussion