Anthropic Cowork 기능이 macOS에서 경고 없이 10GB VM 번들을 생성
(github.com/anthropics)- macOS용 Claude Desktop의 Cowork 기능이 활성화되면, 시스템에 약 10GB 크기의 가상머신(VM) 번들이 자동 생성되어 성능이 급격히 저하됨
- 이 파일은
~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img경로에 저장되며, 삭제 후에도 다음날 다시 생성됨 - 사용자는 CPU 사용률 상승(24~55%), 스왑 증가, UI 지연 등 지속적인 성능 저하를 보고함
- 임시 해결책으로 VM 번들과 캐시 폴더를 삭제하면 약 75% 성능 개선이 있으나, 시간이 지나면 다시 느려짐
- 여러 사용자가 투명성 부족과 저장공간 낭비를 지적하며, VM 생성 여부를 선택할 수 있는 설정과 사전 고지를 요구함
문제 개요
- Cowork 기능 사용 후 Claude Desktop이 매우 느려지고, 시작 지연·UI 렉·응답 지연이 발생
- 성능 저하는 세션 중에도 점차 심화되며, VM 번들 파일이 10GB까지 커지고 자동 재생성됨
- 해당 문제는 macOS 환경(8GB RAM) 에서 재현됨
조사 결과
- Cowork 기능이 생성하는 VM 번들은
~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img위치에 존재 - 이 파일은 삭제해도 하루 내 다시 생성되며, 자동 정리(cleanup) 가 이루어지지 않음
- VM 번들과 캐시를 삭제하면 저장공간이 11GB → 639MB로 줄고, 작업 속도 약 75% 향상
- 그러나 재시작 후 몇 분 내에 CPU 사용률이 24% → 55% 로 상승하고, swapins 20K → 24K+ 로 증가
- 이는 메모리 누수 또는 누적 작업 부하로 인한 성능 저하 가능성을 시사
관찰된 동작
- 유휴 상태에서도 CPU 사용률 24~55%
- 스왑 활동 지속 증가, 수 분 내 성능 저하
- Cowork 세션마다 10GB VM 번들 재생성
- 정리 후 일시적 개선(75%), 그러나 시간이 지나면 다시 저하
임시 해결책
- Claude Desktop 종료 후 다음 명령으로 VM 및 캐시 삭제
rm -rf ~/Library/Application\ Support/Claude/vm_bundles rm -rf ~/Library/Application\ Support/Claude/Cache rm -rf ~/Library/Application\ Support/Claude/Code\ Cache - 이 조치로 일시적 성능 개선 가능하나, 주기적 재시작 필요
- 일부 사용자는 VM 폴더 권한을
chmod 000으로 변경해 재생성 방지
사용자 피드백
- Cowork 비활성 상태에서도 VM이 실행되어 메모리 점유
- 일부 사용자는 21GB 이상으로 커진 VM 번들을 보고
- VM이 앱 실행 시 자동 재프로비저닝되며, 압축 파일(
rootfs.img.zst)까지 남아 중복 저장공간 낭비 - Cowork를 한 번도 사용하지 않은 사용자도 10GB 번들 발견, 메모리 누수로 인식
- 저장공간이 제한된 Mac 사용자들은 비활성화 옵션 필요성을 강조
투명성 및 신뢰 문제 제기
- 사용자들은 사전 고지 없이 12~20GB 디스크와 2GB RAM을 점유하는 점을 문제로 지적
- 설치 시 또는 첫 실행 시 고지, VM 사전 다운로드 여부 선택, Cowork 비활성화 토글 제공 등을 제안
- 일부는 VM 샌드박싱 설계의 의도는 이해하지만, 설명 부족이 사용자 신뢰를 해친다고 언급
- “앱이 사용자 모르게 시스템 자원을 사용하는 것은 신뢰를 떨어뜨린다”는 의견 다수
관련 이슈 및 후속 논의
- 관련 버그 리포트 다수 존재:
- VM 메모리 부족으로 인한 SIGKILL 반복 발생 (#22715)
- 시스템 전체 메모리 고갈 및 Electron 앱 충돌 (#23334)
- Cowork 세션 중 프리징 및 강제 종료 (#25012)
- Windows 환경에서도 12GB VM 번들 생성 (#26258)
- 해당 이슈는 high-priority, performance, oncall 라벨로 분류됨
- 담당자는 felixrieseberg로 지정됨
요약
- Cowork 기능이 macOS에서 10GB 이상 VM 번들을 자동 생성하며, 성능 저하와 저장공간 낭비를 유발
- 삭제 후 재생성, 비활성 상태에서도 실행, 투명성 부족이 주요 불만
- 커뮤니티는 명시적 고지, 선택적 설치, 비활성화 옵션을 요구
- 문제는 고우선순위(performance-critical) 버그로 등록되어 있음
Hacker News 의견들
-
안녕하세요, Anthropic의 Felix임. 나는 Claude Cowork와 Claude Code를 담당하고 있음
Cowork는 Linux VM 안에서 동작하는 Claude Code 에이전트 하니스 위에 구축되어 있고, Apple의 Virtualization Framework나 Microsoft의 Host Compute System을 통해 실행됨
이렇게 하는 이유는 세 가지임
(1) Claude가 사용자 대신 자유롭게 코드를 작성할 수 있는 독립된 컴퓨터 환경을 제공하기 위함
(2) 다른 샌드박싱 솔루션보다 보안 경계 보장이 확실함
(3) 기술 비전문 사용자에게 더 안전한 사용 경험을 제공함
다만 트레이드오프가 존재함을 알고 있고, Cowork를 사용하지 않거나 VM 없이 쓰고 싶은 사람들을 위한 개선 아이디어를 검토 중임- 피드백을 주자면, Cowork가 10GB의 저장공간을 쓴다면 사전에 사용자에게 알리고 원클릭으로 삭제할 수 있게 해야 함
“승인 피로(approval fatigue)”를 줄이는 건 단기적으로 Anthropic에 유리할 뿐, 사용자에게는 장기적으로 이득이 아님
이런 패턴이 굳어지기 전에 멈추는 게 좋을 것 같음 - 공식 혹은 반공식 Claude 샌드박스용 컨테이너 이미지를 제공해줬으면 함. Cowork VM을 외부에서도 쓸 수 있게 하면 좋겠음
- 설명은 훌륭하지만, 실제로는 Cowork가 성능 저하와 전력 소모 문제를 일으킨다는 불만이 있음
- Cowork가 VM 위에서 돌아간다는 걸 몰랐음. 마케팅에서 이걸 명확히 알렸다면 훨씬 일찍 써봤을 것 같음
- Claude Desktop에서 Mac VM(UTM 내)으로 실행하려다 Apple Virtualization Framework 관련 오류가 발생했음
이미 VM 안에서 실행 중이라 중첩 가상화 오류가 난 듯함. 오류 메시지를 개선하거나, 이미 VM 안이라면 Cowork가 자체 VM을 생략하도록 하면 좋겠음
- 피드백을 주자면, Cowork가 10GB의 저장공간을 쓴다면 사전에 사용자에게 알리고 원클릭으로 삭제할 수 있게 해야 함
-
요즘 앱들이 디스크 접근을 남용하는 게 놀라움
예를 들어 Apple Podcasts 앱이 이유 없이 120GB의 팟캐스트 파일을 다운로드하고 삭제하지 않음. “System Data”로 표시되어 외장 드라이브를 찾아야 했음- macOS의 “System Data” 문제는 정말 끔찍함. Docker, 음악 라이브러리, 캐시 등으로 인해 1~2년에 한 번은 클린 설치를 해야 함
-
~/Library/Messages폴더를 보면 iMessage 동기화 때문에 100GB가 넘게 차지함. 이런 건 클라우드로 오프로드해야 함 - 5G 시대인데도 여전히 오디오 파일을 기본으로 다운로드하는 건 이해가 안 됨. 스트리밍으로 충분함
- 나도 Time Machine 백업 문제로 512GB 중 300GB가 “System Data”로 표시되어 하루치 작업을 날렸음
- 이런 문제를 해결하기 위해 Mole 같은 도구를 사용함. 또한 warp/gemini CLI로 불필요한 캐시를 찾아 삭제함
-
“vibe coding”이 주는 축복과 저주를 동시에 느끼는 중임. 그야말로 분위기 코딩의 양면성임
-
VM 샌드박스는 Cowork의 핵심임. 코드 생성 기능을 안전하게 제공하려면 격리 환경이 필수임
사용자에게 특정 폴더만 접근 권한을 주게 하고, 쓰기 권한이 필요한 경우 경고를 띄우는 UI를 제안함 -
사실 LLM이 없어도 개발은 VM 안에서 하는 게 좋음
Vagrant 같은 도구가 여전히 유용함
Cowork의 주요 대상은 비개발자이며, 코드를 짜는 비서형 AI로 접근하는 게 맞음
전문가들은 별도 Mac Mini에서 작업하지만 일반 사용자는 그럴 수 없으니 VM이 현실적인 해법임- 요즘은 VPS 제공업체들이 많아 exe.dev, sprites.dev, shellbox.dev 같은 곳에서 쉽게 환경을 만들 수 있음
- 나는 복잡한 프로젝트에는 devcontainer를 선호함. Docker와 NixOS를 활용하면 더 가볍고 유연한 개발 환경을 만들 수 있음
- macOS에서는 Lima가 최고의 선택이었음. Claude Code를 이미지로 두고 필요한 디렉터리만 마운트함. Vagrant보다 훨씬 매끄럽게 작동함
- “그럼 프로그래밍할 때도 콘돔을 쓰냐?”는 농담이 나올 정도로 보안 집착이 과하다는 반응도 있었음
-
Anthropic 직원들이 Claude Code로 Claude Code를 개발하고 있다고 들음
AI가 제품 완성도를 높이지만 품질 저하가 문제임. 결국 숙련된 개발자가 다시 필요해질 것임
초기 사용자들은 실험용 쥐처럼 제품을 테스트해야 하는 책임이 있음- 이런 1st party 제품들이 오픈소스와 경쟁할 수 있을지 의문임. 무료이면서 더 나은 대안이 있는데 굳이 쓸 이유가 없음
- Anthropic 내부의 품질 문제를 보면, 직원 대부분이 주니어 이하 수준으로 보임. Bun 팀 정도만 예외로 보임
-
최근 30분 동안 DaisyDisk로 노트북 정리를 하다가 Cowork의 10GB VM을 발견했음
앱들이 불필요하게 저장공간을 차지하는 경우가 많고, 정리 기능이 거의 없음
Xcode도 오랫동안 실행하지 않았는데 여러 OS용 SDK와 시뮬레이터를 계속 보관함- 이런 문제를 해결하려면 DevCleaner를 쓰면 됨
- macOS에
crond나find가 있는데 왜 이런 정리 작업을 자동화하지 않는지 의문임
-
Cowork가 Apple Virtualization Framework를 사용하기 때문에 중첩 VM 오류가 발생함
기능 제한, 공간 낭비, 지연이 생김. OpenAI가 사용하는 Seatbelt 샌드박스가 더 나은 대안일 수 있음
관련 링크- 하지만 Seatbelt는 거의 쓸모가 없다고 생각함. 왜 Cowork를 VM 안에서 실행하려는지 궁금함. 자체 VM을 쓰면 충분하지 않음?
- 게다가 Seatbelt는 문서화가 거의 안 되어 있음
-
불편하긴 하지만, 이런 샌드박스 방식이야말로 에이전트형 도구의 본질임
내장 샌드박스 없이 실행되는 도구는 언젠가 데이터 손실을 초래하게 됨 -
아마 Anthropic 내부에서 “앱 성능 개선” 프롬프트를 던졌더니 이런 결과가 나온 것 같음