Clawk가 코딩 에이전트에게 일회용 리눅스 VM을 통째로 던집니다

핵심 요약 (TL;DR)

Clawk는 Claude Code·Codex·shell 에이전트를 일회용 리눅스 VM 안에서 돌리는 CLI 도구입니다. cd 후 clawk 한 번이면 Docker나 devcontainer 없이 하이퍼바이저 경계로 격리된 환경이 뜨죠. 2026년 7월 13일 Show HN 제출 후 165점·139댓글로 창 내 두 번째 상위 진입, GitHub 270 stars. Go 99.1%, Apache 2.0 라이선스, 정식 ARCHITECTURE.md와 CI/CD 워크플로 포함. --dangerously-skip-permissions으로 시스템을 걸거나 매번 승인 지옥을 겪거나 사이에 낀 바이브코더에게 하이퍼바이저가 제3의 답이 될 수 있는지 보여주는 사례예요.

왜 프로세스 샌드박스로는 부족했을까요

바이브코더라면 익숙한 딜레마가 있죠. Claude Code에 --dangerously-skip-permissions을 붙이면 자동으로 빠르지만 rm -rf ~/ 같은 실수 한 방이 무섭습니다. 그래서 매 명령마다 y를 눌러야 하는 승인 모드로 돌리면, 반나절이 승인 확인에 사라져요.

지금까지 답으로 나온 것들은 대개 프로세스 샌드박스였습니다. seccomp, AppArmor, macOS의 sandbox-exec. 문제는 이 필터 정책을 완벽하게 짜기가 거의 불가능하다는 거예요. 필터 하나 빠뜨리면 뚫리고, 너무 좁게 잡으면 npm install이 안 됩니다. 정책을 관리하는 데 드는 시간이 승인 지옥보다 많을 수도 있어요.

Clawk 개발자 celrenheit가 택한 답은 다릅니다. 정책을 짜지 말고, 그냥 하이퍼바이저를 사자. 리눅스 VM 하나를 통째로 띄워서 에이전트를 그 안에 밀어 넣고, 호스트와의 경계는 하이퍼바이저에게 맡기는 거예요. macOS라면 Virtualization.framework, 리눅스라면 KVM.

Clawk가 실제로 하는 일

로컬에서 어떻게 도는지 보면 이해가 빠릅니다.

cd my-repo
clawk claude "이 리팩터를 자동으로 진행해줘"

이 한 줄로 벌어지는 일:

1. 현재 디렉토리를 VM 안에 마운트합니다.
2. VM 안에서 Claude Code가 뜨고, 유저 프롬프트를 그대로 받습니다.
3. VM 안의 파일 수정·명령 실행은 전부 하이퍼바이저 경계 안에서만 벌어져요.
4. Outbound 네트워크는 DNS-aware 화이트리스트로 걸립니다. npm install은 허용하되 이상한 도메인으로의 exfil은 막는 방식이죠.
5. git push나 SSH는 ssh-agent 포워딩으로 처리해서 시크릿은 호스트에만 남기고 결과만 밖으로 나갑니다.

Docker나 devcontainer로 비슷한 걸 만들려면 이미지 관리·마운트 설정·네트워크 정책 등을 직접 짜야 했죠. Clawk는 그걸 다 자동화한 게 핵심입니다.

멀티 리포 워크트리 지원이 왜 중요할까요

의외로 실전에서 자주 걸리는 지점이에요. 한 에이전트에게 리포 3개를 동시에 손보라고 시키는 경우가 있죠. Clawk는 하나의 샌드박스가 여러 리포 각각의 워크트리를 마운트하는 걸 지원합니다. 리포마다 VM을 새로 띄우지 않아도 되니 오버헤드가 크게 줄죠.

GitHub 리포를 보면 정식 오픈소스 프로젝트 구조가 그대로 있어요. ARCHITECTURE.md, DESIGN.md, CI/CD 워크플로. Go로 짜여 있고 라이선스는 Apache 2.0입니다. 개인 취미 프로젝트가 아니라 진지하게 유지할 물건이라는 뜻이죠.

FAQ

Q. Docker보다 정말 나은가요?
A. Docker는 리눅스 커널을 호스트와 공유합니다. Clawk의 VM은 자기 커널을 갖죠. 커널 익스플로잇이 있다면 Docker는 뚫리지만 VM은 하이퍼바이저 경계가 한 층 더 있어서 훨씬 어렵습니다. 다만 시작 시간이 Docker보다 약간 길고, 리소스도 조금 더 씁니다.

Q. macOS와 리눅스 둘 다 되나요?
A. macOS는 Virtualization.framework, 리눅스는 KVM 기반이에요. 두 플랫폼 모두 첫 clawk 명령이 무설정으로 도는 걸 목표로 하지만, 실제 프로덕션 시나리오에서의 안정성은 팩트체커도 실측 확인이 필요하다고 판단한 지점입니다. 직접 써보고 판단하는 게 좋습니다.

Q. npm install 같은 것도 정말 될까요?
A. Outbound가 DNS-aware 화이트리스트라서 npm registry나 pypi 같은 표준 경로는 자동으로 허용됩니다. 이상한 도메인만 거르는 방식이죠. 다만 사설 레지스트리를 쓴다면 별도 설정이 필요해요.

마무리

Clawk의 진짜 메시지는 도구 그 자체보다 접근법의 전환에 있어요. 지금까지 바이브코딩 안전 논의는 "어떻게 하면 정책을 잘 짤 것인가"였습니다. Clawk는 그 질문을 통째로 옆으로 밀어버립니다. "정책을 짜지 말고 아키텍처로 해결하자." 하이퍼바이저 경계 하나가 프로세스 필터 100개보다 튼튼하니까요. 어제 다룬 FetchSandbox가 API 시뮬레이션 층이었다면, Clawk는 로컬 시스템 격리 층이에요. 바이브코딩 툴체인의 위·아래를 이틀에 걸쳐 채운 셈이죠. --dangerously-skip-permissions 습관을 이제 그만 두고 싶은 분은 GitHub 리포에서 바로 받아볼 만합니다.