--- title: "클로드 데스크톱, 채팅만 켜도 1.8GB Hyper-V VM을 띄운다는 버그 리포트" published: 2026-06-10T17:11:56.000Z canonical: https://jeff.news/article/3994 --- # 클로드 데스크톱, 채팅만 켜도 1.8GB Hyper-V VM을 띄운다는 버그 리포트 Windows용 Claude Desktop이 채팅만 쓰는 상황에서도 Hyper-V 기반 VM을 매번 띄워 약 1.8GB 메모리를 먹는다는 버그 리포트가 올라왔다. Cowork나 agent mode를 한 번 쓴 뒤 남은 세션 파일과 VM 초기화 흐름이 얽혀, 16GB 노트북에서는 유휴 상태 메모리 사용률이 50%에서 62%까지 튄다는 내용이다. - 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` 하나였음 > [!IMPORTANT] > 이 이슈의 핵심은 “Claude가 VM을 쓴다”가 아니라 “채팅만 하는데도 VM을 무조건 띄운다”는 점임. agent 기능의 인프라 비용이 기본 실행 비용으로 전가된 셈임. - 이벤트 로그에는 Hyper-V Compute Admin 오류가 반복적으로 남았음 - 오류 메시지는 `The virtual machine or container JSON document is invalid` 계열이었고, 코드로는 `0xC037010D`가 찍힘 - 제보자는 이 오류가 최소 2026년 2월 19일부터 부팅과 앱 실행 때마다 발생했다고 적음 - `vmcompute` 서비스는 수동 시작으로 설정돼 있었지만, RPC interface event에 의해 부팅 시점에 트리거됐다고 분석함 ```mermaid 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을 준비해야 사용자가 납득할 수 있는 비용이 돼요. ## 핵심 포인트 - Claude Desktop이 채팅 전용 실행에서도 Vmmem 약 1.8GB를 생성 - Windows 11 Pro 25H2, VirtualMachinePlatform 활성화 환경에서 재현 - 이전 Cowork 세션 파일 2,689개가 남아 있었지만 삭제해도 VM 재생성은 계속됨 - 현재 우회법은 VirtualMachinePlatform 비활성화 또는 vmwp, vmcompute 프로세스 수동 종료 - 요청 사항은 VM 인프라를 Cowork나 agent mode 사용 시점에만 지연 초기화하는 것 ## 인사이트 AI 데스크톱 앱이 로컬 agent 기능을 붙이면서 ‘그냥 채팅 앱’이 아니라 가상화 런타임까지 품은 실행 환경이 되고 있다는 신호다. 문제는 그 무거운 인프라가 필요할 때만 켜지지 않으면, 사용자는 기능을 쓰기도 전에 비용을 메모리로 먼저 내게 된다는 점이다.