코딩 에이전트용 일회용 VM 구성하기

일회용 VM이 노트북보다 나은 이유

코딩 에이전트에 일회용 VM을 제공하면, 에이전트가 할 수 있는 최악의 일은 10분 안에 다시 구축할 수 있는 시스템을 파괴하는 것입니다. 에이전트는 여전히 root 권한을 얻고, 패키지를 설치하며, 모든 단계에서 권한을 요청하지 않고 테스트 스위트를 실행합니다. 차이는 피해가 발생하는 위치에 있습니다. 노트북에서는 에이전트가 SSH 키, 브라우저 프로필, .env 파일 및 지금까지 복제한 모든 저장소가 있는 홈 디렉터리를 공유합니다. 버릴 수 있는 서버에서는 에이전트에 셸과 체크아웃만 있으며, 가져갈 만한 다른 항목은 없습니다.

이것이 핵심 주장입니다. 이 주장은 가능성보다 비대칭에 관한 것입니다. 신중한 노트북에서 신중하게 작동하는 에이전트는 거의 항상 문제가 없습니다. 문제가 발생하는 단 한 번의 경우, 비용은 잘못된 커밋이 아닙니다. 백업이 있다면 백업에서 복원해야 합니다.

논쟁하기 전에 피해 범위를 정하라

피해 범위는 프로세스가 접근할 수 있는 대상의 집합을 의미합니다. 일반적인 시스템에서 일반 사용자로 실행되는 에이전트의 접근 범위는 대부분의 사람이 생각하는 것보다 넓습니다.

여기에는 ~/.ssh/id_ed25519이(가) 포함됩니다. 대개 암호화되지 않은 상태입니다. 암호를 입력하는 일이 번거로워졌기 때문입니다. ~/.aws/credentials 및 ~/.config/gh/hosts.yml도 포함됩니다. 이 파일들은 설계상 평문입니다. ~/code 아래에 있는 모든 형제 repository도 포함됩니다. 여기에는 로컬 env 파일에 production 연결 문자열이 들어 있는 repository도 포함됩니다. 한 번 붙여 넣은 token이 남아 있는 shell history도 포함됩니다. 노트북이 연결된 network도 포함됩니다. 이 network는 흔히 인증되지 않은 service가 실행 중인 home 또는 office network입니다.

이 모든 상황에 악성 agent가 필요한 것은 아닙니다. 확신에 찬 잘못된 명령 하나면 충분합니다. 설정되지 않은 변수가 /으로 확장되는 rm -rf, 잘못된 directory에서 실행되는 git clean -xfd, 로컬 database까지 삭제하는 docker system prune -af --volumes, home directory에서 실행되는 유용한 chmod -R 777이 그 예입니다. Agent는 다른 모든 사람에게 그런 명령을 가르친 것과 동일한 internet을 바탕으로 학습합니다.

당신을 보호하는 것은 agent의 판단력이 아닙니다. 피해가 발생할 machine을 잃어도 괜찮다고 판단했다는 사실입니다.

비용 계산은 지루하지만, 이것이 핵심입니다

소형 VPS는 한 달에 몇 달러면 사용할 수 있습니다. 개발자 노트북을 복구하는 데는 하루가 걸립니다. 즉시 문제를 알아차리고 백업도 있었다는 좋은 경우에도 그렇습니다.

자신의 수치로 계산해 보십시오. 시간당 요금에 운영 체제 재설치, 홈 디렉터리 복원, SSH 키 교체, 개인용 access token 교체, 20개 repository 재복제에 필요한 시간을 곱하십시오. 그 결과를 provider가 판매하는 가장 저렴한 서버를 12개월 동안 사용하는 비용과 비교하십시오. 손익분기점은 몇 년에 한 번도 안 되는 단일 사고보다 낮습니다. 또한 그 사고가 치명적일 필요도 없습니다. 손상된 로컬 환경 때문에 오후 한 번을 잃는 것만으로도 1년 사용료를 이미 충당합니다.

계산의 두 번째 부분은 snapshot입니다. 위험한 실행 전에 snapshot을 만들면 문제가 발생했을 때 "내 환경 전체를 복구"하는 대신 "롤백하고 다른 prompt를 시도"할 수 있습니다. 지금 이 글을 입력하는 노트북에서는 이 선택지를 사용할 수 없습니다. 책상으로 사용하는 동안에는 해당 컴퓨터의 snapshot을 만들 수 없기 때문입니다.

2026년 7월 기준 환경

“에이전트를 어디에서 실행해야 하는가?”라는 질문에는 정직한 답이 3가지 있습니다. 각 답은 동일한 2가지 요소 사이에서 절충합니다. 경계의 강도와 감수할 수 있는 설정 작업의 양입니다.

로컬 마이크로 VM. 이 범주의 도구는 자체 하드웨어에서 실제 가상 머신을 부팅하고, 저장소를 가상 머신에 마운트하며, 에이전트가 그 안에서 root 권한을 사용하도록 합니다. clawk은 현재 사용할 수 있는 예이며, 이 게시물의 핵심 주장과 정확히 일치합니다. 코딩 에이전트에는 노트북이 아니라 폐기 가능한 Linux VM을 제공해야 합니다. 2026년 7월 기준으로 이 도구는 Apple silicon에서 macOS 14 이상을 대상으로 하며, Firecracker를 통한 실험적 Linux 지원도 제공합니다. brew install clawkwork/tap/clawk로 설치합니다. 저장소 안에서 clawk를 실행하면 샌드박스를 부팅하고 에이전트를 연결할 수 있습니다. clawk down으로 중지하고, clawk destroy으로 제거합니다. 경계는 강력한 hypervisor입니다. 한계는 VM이 휴대하는 컴퓨터에서 실행된다는 점입니다. 따라서 메모리를 함께 사용하며, 덮개를 닫으면 실행이 중지됩니다.

컨테이너. Docker는 대부분의 사람이 이미 설치한 선택지이며, 실제로 유용합니다.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm는 종료할 때 컨테이너를 폐기하고, --network none는 컨테이너의 네트워크를 완전히 차단합니다. 빌드나 테스트 실행의 기본값으로 적합합니다. 다만 이 방식이 하지 않는 일을 분명히 알아야 합니다. 컨테이너는 호스트 kernel을 공유하므로 kernel 버그가 탈출 경로가 될 수 있습니다. 또한 --privileged를 추가하거나 에이전트가 “Docker를 사용”할 수 있도록 /var/run/docker.sock를 마운트하는 순간 경계가 사라집니다. 컨테이너에 Docker socket을 마운트하는 것은 해당 컨테이너에 호스트의 root 권한을 부여하는 것과 같습니다.

재구축할 수 있는 일반 VPS. 새 도구가 필요하지 않고, 실제 kernel 경계를 사용하며, 노트북을 종료해도 계속 실행됩니다. 이 가이드의 나머지 부분에서는 이 패턴을 설명합니다. 또한 장시간 실행되는 에이전트 작업에도 적합합니다. 4시간이 걸리는 작업은 사용자가 집에 갔는지 신경 쓰지 않기 때문입니다.

VPS 패턴: 에이전트 전용 사용자 생성

보안을 강화한 서버에서 시작합니다. 새 VPS에서 처음 10분 동안 수행할 작업에서는 업데이트, non-root 로그인, key-only SSH, 방화벽 등 에이전트에만 해당하지 않는 항목을 다룹니다.

그런 다음 에이전트 전용 계정을 생성합니다. 이 계정에서 실수가 발생해도 서버의 다른 부분에는 영향을 줄 수 없습니다.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password을 사용하면 추측할 비밀번호가 없으며, sudo -u agent 또는 SSH key를 사용해 계정에 접속합니다. agent은 의도적으로 sudo 그룹에 속하지 않는다는 점에 유의합니다. sudo 권한이 있는 에이전트는 root 권한을 가지며, root는 다른 모든 사용자의 파일을 읽을 수 있습니다. 그러면 방금 구성한 분리가 형식적인 것에 불과해집니다. 에이전트에 실제로 패키지 설치가 필요하다면, 공유 서버에서 에이전트에 sudo을 부여할 이유가 아니라 에이전트가 소유하는 별도의 서버를 사용해야 할 이유입니다. 일반적인 규칙은 VPS에서 Linux 사용자의 최소 권한에 정리되어 있습니다.

권한 경계를 신뢰하기 전에 확인합니다. agent 사용자로서 자신의 계정에 속한 파일을 읽어 봅니다.

sudo -u agent cat /home/you/.ssh/id_ed25519

cat: /home/you/.ssh/id_ed25519: Permission denied이 표시되어야 합니다. 대신 key material이 표시되면 home directory의 mode가 755이므로 아직 격리가 제대로 이루어지지 않은 것입니다. sudo chmod 700 /home/you로 수정합니다.

자격 증명을 머신에 전혀 저장하지 않기

프로덕션 비밀 정보를 일회용 머신에 복사하면 해당 머신을 일회용으로 사용하는 의미가 사라집니다. 원칙은 간단합니다. 해당 머신에는 오늘 오후에 교체해도 문제가 없을 자격 증명만 있어야 합니다.

git에는 키를 복사하지 말고 SSH agent를 전달합니다. 개인 키는 노트북에 남아 있고 서명 요청만 연결을 통해 전달됩니다.

ssh -A agent@203.0.113.10
ssh -T git@github.com

두 번째 명령은 Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.에 답해야 합니다. 그러면 서버에 키 파일이 없어도 git push이 작동한다는 사실을 확인할 수 있습니다. 이후 해당 머신에서 ls -la ~/.ssh을 실행하고 개인 키가 없는지 확인합니다.

Agent forwarding에는 한 가지 중요한 주의 사항이 있습니다. 연결된 동안 해당 서버에서 root 권한을 가진 사용자는 전달된 소켓을 사용해 사용자의 자격으로 인증할 수 있습니다. 다른 사용자가 사용자 한 명뿐인 서버라면 이는 허용할 수 있는 절충안입니다. 공유 머신에서는 허용해서는 안 됩니다. 이 경우에는 하나의 저장소로 범위를 제한한 deploy key가 더 적절합니다. 선택지는 SSH 키 관리 기본 사항에서 설명합니다.

API 키에는 별도의 지출 한도가 설정된 전용 키를 사용합니다. 이 키는 agent 사용자가 소유하고 mode 600으로 설정된 파일에 저장합니다. 머신을 삭제할 때는 키가 유출되었는지 걱정하지 말고 해당 키를 폐기합니다. 키별 모델 사용 비용을 확인할 수 있어야 VPS에서 AI agent 비용 관리의 수치도 예측 가능한 상태로 유지됩니다.

에이전트가 네트워크에서 접근할 수 있는 범위를 제한합니다

파일 시스템 격리는 경계의 절반입니다. 나머지 절반은 프로세스가 통신할 수 있는 대상인 송신 트래픽입니다. Linux는 프로세스를 생성한 사용자별로 아웃바운드 트래픽을 필터링할 수 있으므로 이 패턴에 정확히 맞습니다.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

규칙은 순서대로 읽히므로 마지막 REJECT가 앞의 규칙에서 허용하지 않은 모든 트래픽을 처리합니다. 에이전트로 실행하여 테스트합니다.

sudo -u agent curl -sS -m 5 http://example.com

연결이 멈춘 상태로 대기하지 않고 거부 규칙이 즉시 응답하므로 curl: (7) Failed to connect to example.com port 80: Connection refused 오류가 발생해야 합니다. 같은 호스트에 대한 HTTPS 요청은 계속 성공해야 합니다.

두 가지 제한을 분명히 알아야 합니다. 첫째, 규칙을 저장하지 않으면 다음 재부팅 때 사라집니다. sudo apt install -y iptables-persistent을 사용한 다음 sudo netfilter-persistent save를 사용하여 저장해야 합니다. 둘째, 이 설정은 이름이 아니라 포트와 주소를 필터링합니다. 포트 443을 허용하는 규칙은 인터넷의 모든 HTTPS 호스트를 허용합니다. 따라서 모델 API에 접근할 수 있지만 pastebin에도 접근할 수 있습니다. 실제 도메인 허용 목록을 사용하려면 요청된 호스트 이름을 읽는 프록시를 통해 트래픽을 전달해야 합니다. 이는 대부분의 단일 개발자 환경에서 원하는 것보다 복잡한 구성입니다. 실제로 적용한 범위만 주장해야 합니다. 손실을 감수할 수 있는 시스템에서 포트 수준의 송신 트래픽 제어만 적용한 것입니다.

작업 간 깨끗한 상태로 초기화

작업마다 깨끗한 상태를 유지하는 것은 과소평가되는 이점입니다. 이전 티켓을 3시간 동안 처리한 에이전트가 설치된 패키지, 절반만 적용된 마이그레이션, 오래된 node_modules, 그리고 아무도 검토하지 않은 변경 사항이 있는 git 작업 트리를 남겼다고 가정하겠습니다. 다음 작업은 이 모든 상태를 그대로 물려받습니다. 그러면 어떤 문제가 어떤 실행에서 발생했는지 확인하는 데 검토 시간을 사용하게 됩니다.

가장 간단한 방법은 작업마다 새로 checkout하는 것입니다.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

더 확실한 방법은 시스템을 설정한 직후, 에이전트가 시스템에 접근하기 전에 provider snapshot을 한 번 생성하는 것입니다. 이 snapshot을 복원하면 패키지를 포함한 전체 시스템이 알려진 상태로 돌아갑니다. 대부분의 provider는 이를 시스템에서 실행하는 명령이 아니라 control panel 또는 API를 통해 제공합니다. 따라서 정확한 절차는 provider에 따라 다릅니다. 중요한 원칙은 시스템이 아직 변경되지 않은 상태일 때 snapshot을 생성하는 것입니다.

중요한 데이터는 폐기할 시스템 외부에 보관합니다. 대부분의 경우 브랜치를 로컬에 쌓아 두지 말고 push해야 한다는 의미입니다. 그래도 시스템에 잃으면 곤란한 데이터가 남았다면 VPS에서 restic으로 백업을 사용해 제대로 백업합니다. 파기할 수 있는 시스템은 파기해도 실제로 문제가 발생하지 않을 때만 유용합니다.

여러 서버를 비용을 들여 운영하지 않고 여러 격리된 환경을 사용하려면, 더 큰 VPS 1대에서 guest VM을 직접 호스팅할 수 있습니다. VPS에서 중첩 가상화에서는 이를 구성하는 방법과 provider가 이를 허용하는지 확인하는 방법을 설명합니다.

노트북으로도 실제로 충분한 경우

이 점은 솔직하게 설명해야 합니다. 격리를 과장하면 사람들이 더 이상 설명을 듣지 않게 됩니다.

모든 명령이 실행되기 전에 검토한다면 노트북으로도 충분합니다. 권한 확인 프롬프트는 실제 제어 수단이며, 서버에서 Claude Code를 안전하게 실행하기에서는 각 권한 수준이 실제로 무엇을 차단하는지 설명합니다. 작업 대상이 단일 repository이고 시스템 어디에도 production 자격 증명이 없다면, 이미 피해 범위가 작습니다. agent 세션을 짧게 유지하고 감독한다면 노출 시간도 짧습니다.

프롬프트를 건너뛰는 순간부터 판단이 달라집니다. 무인 실행, 야간 작업, 계획을 승인한 뒤 자리를 비우는 모든 workflow는 격리를 담당하던 사람의 확인 절차를 없앱니다. 그러면 시스템이 대신 격리를 수행해야 합니다. 여러 repository에서 동시에 VPS에서 coding agent 실행하기와 같이 agent의 접근 범위를 넓히는 작업에도 같은 원칙이 적용됩니다.

결정은 model을 얼마나 신뢰하는지에 관한 것이 아닙니다. model이 잘못 판단했을 때 model 옆에 무엇이 놓여 있는지에 관한 것입니다.

FAQ

컨테이너만으로 코딩 에이전트를 충분히 격리할 수 있습니까?

대부분의 작업에서는 가능합니다. 단, 2가지 조건이 있습니다. 컨테이너는 --privileged로 실행하면 안 됩니다. 또한 /var/run/docker.sock를 컨테이너에 마운트하면 안 됩니다. 둘 중 하나라도 있으면 프로세스가 호스트의 root에 접근할 수 있는 경로가 생깁니다. 컨테이너는 호스트 커널을 공유하므로 가상 머신보다 격리 경계가 약합니다. 에이전트가 인터넷에서 가져온 신뢰할 수 없는 코드를 실행한다면 실제 VM이나 별도 서버를 사용합니다.

에이전트에 서버의 sudo 권한이 필요합니까?

아니요. sudo 권한을 부여하면 구축한 격리가 무력화됩니다. root는 해당 시스템의 다른 모든 계정을 읽을 수 있기 때문입니다. sudo 권한 없이 에이전트 사용자를 생성하고, 자체 작업 디렉터리에만 쓰기 권한을 부여합니다. 작업에 패키지 설치가 반드시 필요하다면, 다른 사용자와 공유하는 시스템에서 root 권한을 주는 대신 에이전트가 소유한 전체 시스템을 제공합니다.

서버에 내 SSH 키를 두지 않고 에이전트가 git에 push하도록 하려면 어떻게 합니까?

연결할 때 ssh -A로 SSH agent를 전달합니다. 서명 요청은 연결을 통해 전송되고 개인 키는 노트북에 남습니다. 따라서 ssh -T git@github.com가 인증하고 git push가 서버에 개인 키 없이 작동합니다. 단, 연결된 동안 해당 서버의 root는 전달된 소켓을 사용할 수 있습니다. 따라서 다른 사람과 공유하는 시스템에서는 저장소 범위로 제한된 deploy key를 사용합니다.

에이전트에 필요한 VPS 크기는 어느 정도입니까?

에이전트 작업은 대부분 파일 편집, 빌드 실행, 테스트 실행이므로 모델이 아니라 빌드에 맞춰 시스템 크기를 정합니다. 호스팅된 모델은 제공업체의 하드웨어에서 실행되므로 네트워크 트래픽은 발생하지만 로컬 부하는 거의 추가되지 않습니다. 스크립트 작업은 2 GB RAM으로 시작하고, 저장소에서 컨테이너를 빌드하거나 상당한 규모의 코드를 컴파일한다면 8 GB로 늘립니다.

시스템을 얼마나 자주 삭제하고 다시 빌드해야 합니까?

상태를 더 이상 설명할 수 없을 때 다시 빌드합니다. 최소한 시스템의 자격 증명이 노출되었을 가능성이 있을 때마다 다시 빌드합니다. 작업 사이에 새로 checkout하면 일상적인 상태 변화를 처리할 수 있습니다. 첫 에이전트 실행 전에 스냅샷을 생성하면 돌아갈 수 있는 깨끗한 시스템 이미지를 확보할 수 있습니다. 다시 빌드하는 비용이 크게 느껴진다면, 이는 일회용이라고 부른 시스템에 중요한 무언가가 저장되어 있다는 신호입니다.