클로드 데스크톱, 채팅만 켜도 1.8GB Hyper-V VM을 띄운다는 버그 리포트

• Windows용 Claude Desktop이 실행될 때마다 Hyper-V VM을 띄워 약 1.8GB RAM을 먹는다는 버그 리포트가 올라옴

  • 문제는 Cowork나 agent mode를 쓰는 것도 아닌, 그냥 채팅만 하려는 실행에서도 발생한다는 점임
  • 제보자 환경은 Windows 11 Pro 25H2, i7-10750H, RAM 16GB짜리 Razer Blade 15였음
  • 16GB 시스템에서 1.8GB면 전체 메모리의 11% 이상이라, ‘백그라운드 인프라’라고 넘기기엔 꽤 큼

• 재현 조건은 꽤 구체적임. Claude Desktop에서 Cowork/agent mode를 한 번이라도 쓴 뒤 앱을 다시 열면 Vmmem이 살아남

  • 작업 관리자에서 Vmmem이 약 1,796~1,846MB를 차지하는 걸 확인했다고 함
  • CPU는 0%에 가까운데 메모리만 잡아먹는 상태라 더 짜증나는 유형의 문제임
  • 앱을 닫았다 열거나, 아예 재부팅한 뒤에도 같은 현상이 반복됨

• 조사 결과, 흔히 의심할 만한 WSL이나 Docker 문제는 아니었음

  • WSL은 설치돼 있지 않았고, wsl --shutdown도 설치 안 됐다고 응답함
  • Hyper-V 관리 도구도 없어서 Get-VM이 실패했고, Docker 프로세스도 없었음
  • Windows Sandbox와 Core Isolation / Memory Integrity도 꺼져 있었음
  • 켜져 있던 가상화 관련 기능은 VirtualMachinePlatform 하나였음

• 이벤트 로그에는 Hyper-V Compute Admin 오류가 반복적으로 남았음
  • 오류 메시지는 The virtual machine or container JSON document is invalid 계열이었고, 코드로는 0xC037010D가 찍힘
  • 제보자는 이 오류가 최소 2026년 2월 19일부터 부팅과 앱 실행 때마다 발생했다고 적음
  • vmcompute 서비스는 수동 시작으로 설정돼 있었지만, RPC interface event에 의해 부팅 시점에 트리거됐다고 분석함

sequenceDiagram
    participant 사용자 as 사용자
    participant 클로드 as Claude Desktop
    participant 컴퓨트 as vmcompute 서비스
    participant 가상머신 as Hyper-V VM
    participant 작업관리자 as 작업 관리자
    사용자->>클로드: 채팅하려고 앱 실행
    클로드->>컴퓨트: RPC 이벤트로 가상화 서비스 트리거
    컴퓨트->>가상머신: vmwp.exe 기반 VM 생성
    가상머신->>작업관리자: Vmmem 약 1.8GB 표시
    사용자->>작업관리자: 메모리 급증 확인

• 더 찝찝한 디테일은 오래된 Cowork 세션 파일이 2,689개나 쌓여 있었다는 점임

  • 경로는 %APPDATA%\\Claude\\local-agent-mode-sessions\\였음
  • 세션 이름은 nifty-dreamy-volta, tender-vigilant-goodall 같은 Docker 스타일 이름이었다고 함
  • 다만 이 파일들을 전부 지우고 vmcompute와 vmwp를 죽여도, Claude Desktop을 다시 열면 VM이 다시 생성됐음
  • 즉 세션 파일 누적은 별도 청소 문제일 수 있지만, VM 무조건 실행의 직접 원인은 그보다 앱 초기화 흐름 쪽에 더 가까워 보임

• 실제 체감 영향도 꽤 큼. 유휴 상태 메모리 사용률이 약 50%에서 62%까지 튀었다고 함

  • 일반 앱들을 같이 켜면 전체 메모리 사용률이 70~75%까지 올라가 시스템이 느려졌다고 함
  • 사용자는 매번 실행 후 VM 프로세스를 수동으로 죽이는 식으로 버텨야 했음
  • 채팅 기능은 VM 프로세스를 죽여도 정상 동작했다고 함. 이게 오히려 “그럼 왜 처음부터 띄움?”이라는 의문을 더 키움

• 현재 우회법은 둘 중 하나임. 둘 다 깔끔하진 않음

  • Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -NoRestart로 VirtualMachinePlatform을 꺼버리면 VM 실행은 막을 수 있음
  • 대신 Cowork 기능도 같이 못 쓰게 됨
  • 아니면 매번 Stop-Process -Name vmwp -Force, Stop-Process -Name vmcompute -Force로 프로세스를 직접 죽여야 함

• 제보자가 요구한 수정 방향은 명확함. VM/container 인프라는 Cowork나 agent mode를 실제로 시작할 때만 켜야 한다는 것

  • 이전 Cowork 세션 데이터는 세션 종료 후 자동 정리돼야 함
  • VM 인프라가 없거나 초기화에 실패해도 채팅 성능은 떨어지지 않아야 함
  • 데스크톱 AI 앱이 로컬 agent 기능을 품는 건 이해되지만, 기본 채팅 UX까지 무거워지는 건 별개의 문제임

기술 맥락

• 여기서 중요한 선택지는 Claude Desktop이 VM 인프라를 앱 시작 시점에 올릴지, Cowork나 agent mode를 실제로 누른 시점에 올릴지예요. 후자가 보통 더 자연스러운 이유는 채팅 기능과 agent 실행 환경의 비용 구조가 완전히 다르기 때문이에요.

• Hyper-V 기반 VM은 그냥 라이브러리 하나 로드하는 수준이 아니에요. Windows에서는 vmcompute, vmwp.exe, Vmmem 같은 계층이 같이 움직이고, 이 글에서는 그 결과가 약 1.8GB 메모리 점유로 나타났거든요. 16GB 노트북에서는 이 정도면 개발 환경 하나 더 띄운 것과 비슷한 부담이에요.

• 제보자가 WSL, Docker, Windows Sandbox를 하나씩 배제한 게 의미 있는 이유는 원인을 “사용자 PC에 원래 있던 가상화 환경” 탓으로 돌리기 어렵게 만들기 때문이에요. 남은 단서는 Claude Desktop 실행과 VirtualMachinePlatform, 그리고 Cowork 세션 흔적이에요.

• 설계 관점에서는 채팅 경로와 agent 경로를 분리하는 게 핵심이에요. 채팅만 할 때는 네트워크 클라이언트와 UI만 살아도 충분하고, 로컬 작업 실행이나 격리가 필요한 순간에만 VM을 준비해야 사용자가 납득할 수 있는 비용이 돼요.