코딩 에이전트 보안을 위한 일회용 VM 활용법

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

코딩 에이전트에게 일회용 VM을 제공하면, 최악의 경우에도 10분이면 복구할 수 있는 머신이 파괴될 뿐입니다. 에이전트는 여전히 root 권한을 얻고, 패키지를 설치하며, 매 단계마다 허락을 구하지 않고 테스트 스위트를 실행합니다. 차이점은 피해가 발생하는 위치입니다. 노트북에서 에이전트는 SSH 키, 브라우저 프로필, .env 파일, 그리고 지금까지 클론한 모든 저장소와 홈 디렉터리를 공유합니다. 반면 일회용 서버에서는 셸과 체크아웃된 코드 외에는 탈취할 가치가 있는 것이 아무것도 없습니다.

이것이 논점의 전부이며, 이는 확률의 문제가 아니라 비대칭성에 관한 논의입니다. 신중한 에이전트가 신중하게 관리되는 노트북에서 작업한다면 거의 매번 괜찮을 것입니다. 하지만 그렇지 않은 단 한 번의 경우, 그 대가는 단순한 잘못된 커밋이 아닙니다. 백업이 있다면 백업으로부터 복구해야 하는 상황이 발생합니다.

논쟁하기 전에 영향 범위를 먼저 정의하십시오

영향 범위(blast radius)란 특정 프로세스가 접근할 수 있는 모든 대상을 의미합니다. 일반 사용자의 권한으로 일반적인 머신에서 실행되는 에이전트의 경우, 그 범위는 대부분의 사람이 생각하는 것보다 훨씬 넓습니다.

여기에는 보통 암호 구문을 입력하는 것이 번거로워 암호화하지 않은 ~/.ssh/id_ed25519이 포함됩니다. 설계상 평문으로 되어 있는 ~/.aws/credentials와 ~/.config/gh/hosts.yml도 포함됩니다. ~/code 하위에 있는 모든 형제 리포지토리도 포함되며, 여기에는 로컬 env 파일에 프로덕션 연결 문자열이 포함된 리포지토리도 들어갑니다. 한때 붙여넣었던 토큰이 남아 있는 셸 히스토리도 포함됩니다. 또한 노트북이 연결된 네트워크도 포함되는데, 이는 종종 인증되지 않은 서비스가 존재하는 가정용 또는 사무용 네트워크인 경우가 많습니다.

이 모든 일에 악의적인 에이전트가 필요한 것은 아닙니다. 그저 자신 있게 잘못된 명령어를 한 번 실행하는 것으로 충분합니다. 변수가 설정되지 않아 /으로 확장되는 rm -rf, 잘못된 디렉터리에서 실행한 git clean -xfd, 로컬 데이터베이스를 함께 삭제하는 docker system prune -af --volumes, 홈 디렉터리에 실행한 유용한 chmod -R 777 등이 그 예입니다. 에이전트는 다른 모든 사람에게 그러한 명령어를 가르친 것과 동일한 인터넷 데이터를 학습합니다.

당신을 구하는 메커니즘은 에이전트의 판단력이 아닙니다. 피해가 발생해도 감수할 수 있는 머신에서 작업을 수행한다는 사실 그 자체입니다.

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

소형 VPS는 한 달에 몇 달러면 충분합니다. 개발자용 노트북을 복구하는 데는 최소 하루가 소요되며, 이는 즉시 문제를 인지하고 백업이 있는 경우의 가장 좋은 시나리오일 뿐입니다.

본인의 수치를 대입해 계산해 보십시오. 본인의 시간당 단가를 기준으로 운영체제 재설치, 홈 디렉터리 복구, SSH 키 교체, 개인 액세스 토큰 교체, 그리고 20개의 저장소를 다시 클론하는 데 걸리는 시간을 곱해 보십시오. 이 비용을 서비스 제공업체에서 판매하는 가장 저렴한 서버의 12개월 이용료와 비교해 보십시오. 손익분기점은 수년에 한 번 발생하는 사고만으로도 충분히 달성되며, 그 사고가 반드시 치명적일 필요도 없습니다. 로컬 환경이 손상되어 오후 시간을 허비하는 것만으로도 이미 1년 치 서버 비용은 상쇄됩니다.

계산의 나머지 절반은 스냅샷입니다. 위험한 작업을 수행하기 전의 스냅샷은 나쁜 결과를 "내 삶을 복구하는 일"에서 "롤백 후 다른 프롬프트 시도"로 바꿔줍니다. 현재 이 글을 작성 중인 노트북에서는 이러한 선택지가 존재하지 않습니다. 책상처럼 사용 중인 기기를 스냅샷으로 찍을 수는 없기 때문입니다.

2026년 7월 기준 현황

"에이전트를 어디에서 실행해야 하는가"라는 질문에는 세 가지 정직한 답변이 있으며, 이들은 경계의 강력함과 설정의 번거로움이라는 두 가지 요소를 서로 맞바꿉니다.

로컬 마이크로 VM. 이 범주의 도구는 사용자 하드웨어에서 실제 가상 머신을 부팅하고, 저장소를 마운트한 뒤 에이전트에게 루트 권한을 부여합니다. clawk이 현재의 예시이며, 이 도구의 핵심은 바로 이 글의 주제와 같습니다. 즉, 코딩 에이전트에게 노트북이 아닌 일회용 Linux VM을 제공하라는 것입니다. 2026년 7월 기준으로 Apple silicon 기반의 macOS 14 이상을 대상으로 하며, Firecracker를 통한 실험적인 Linux 지원을 제공하고 brew install clawkwork/tap/clawk로 설치합니다. 저장소 내부에서 clawk를 실행하여 샌드박스를 부팅하고 에이전트를 연결하며, clawk down으로 중지하고 clawk destroy로 제거합니다. 경계는 하이퍼바이저이므로 강력합니다. 한계점은 VM이 사용자가 휴대하는 기기에서 실행되므로 메모리 자원을 점유하며, 노트북 덮개를 닫으면 동작이 멈춘다는 것입니다.

컨테이너. Docker는 이미 대부분의 사용자가 설치해 둔 도구이며, 실제로 유용합니다.

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

--rm는 종료 시 컨테이너를 폐기하며, --network none은 네트워크를 완전히 차단합니다. 이는 빌드나 테스트 실행 시 좋은 기본 설정입니다. 이 방식이 수행하지 않는 작업을 명확히 이해해야 합니다. 컨테이너는 호스트 커널을 공유하므로 커널 버그가 발생하면 탈출 경로가 생깁니다. 또한 --privileged를 추가하거나 /var/run/docker.sock를 마운트하여 에이전트가 "Docker를 사용"하게 만드는 순간 경계는 사라집니다. Docker 소켓을 컨테이너에 마운트하는 것은 해당 컨테이너에 호스트 루트 권한을 부여하는 것과 같습니다.

재구축 가능한 일반 VPS. 새로운 도구가 필요 없고, 실제 커널 경계를 사용하며, 제공업체의 스냅샷 기능을 활용할 수 있고, 노트북을 종료해도 계속 실행됩니다. 이 가이드의 나머지 부분에서 설명하는 방식이 바로 이 패턴입니다. 이 방식은 긴 에이전트 실행 시간에도 안정적입니다. 4시간이 걸리는 작업이라도 사용자가 퇴근하는 것과는 무관하기 때문입니다.

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

보안이 강화된 서버에서 시작하십시오. 새 VPS 설정의 첫 10분 가이드에서는 에이전트와 무관한 기본 보안 사항인 업데이트, 비루트(non-root) 계정 로그인, 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 키를 사용하여 해당 계정에 접근할 수 있습니다. agent은 의도적으로 sudo 그룹에 포함되지 않아야 함을 유의하십시오. sudo 권한을 가진 에이전트는 root 권한을 갖게 되며, root는 다른 모든 사용자의 파일을 읽을 수 있으므로 방금 구축한 격리 체계는 무용지물이 됩니다. 에이전트가 패키지를 설치해야 한다면, 이는 공유 서버에서 sudo 권한을 부여할 이유가 아니라 해당 에이전트 전용 서버를 따로 운영해야 할 근거가 됩니다. 일반적인 규칙은 VPS에서 리눅스 사용자를 위한 최소 권한 원칙을 참조하십시오.

신뢰하기 전에 경계가 제대로 작동하는지 확인하십시오. agent 사용자로 전환한 뒤, 본인 계정의 파일을 읽을 수 있는지 시도해 보십시오.

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

cat: /home/you/.ssh/id_ed25519: Permission denied 메시지가 출력되어야 합니다. 만약 키 정보가 출력된다면 홈 디렉터리의 권한이 755로 설정되어 격리가 제대로 이루어지지 않은 상태입니다. sudo chmod 700 /home/you 명령으로 이를 수정하십시오.

자격 증명을 서버에 절대 저장하지 마십시오

일회용 서버를 사용하는 목적은 프로덕션 환경의 비밀 정보를 서버에 복사하는 순간 무의미해집니다. 규칙은 간단합니다. 오늘 오후 당장 교체해도 문제가 없을 자격 증명 외에는 그 어떤 것도 서버에 두어서는 안 됩니다.

Git의 경우, 개인 키를 복사하는 대신 SSH 에이전트를 포워딩하십시오. 개인 키는 사용자의 노트북에 그대로 유지되며, 연결을 통해 서명 요청만 전달됩니다.

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을 실행하여 개인 키가 존재하지 않음을 확인하십시오.

에이전트 포워딩에는 한 가지 중요한 주의 사항이 있습니다. 명확히 말씀드리면, 연결이 유지되는 동안 해당 서버의 root 권한을 가진 사람은 누구든 포워딩된 소켓을 사용하여 사용자 본인으로 인증할 수 있습니다. 사용자가 유일한 사용자라면 이는 감수할 만한 절충안입니다. 하지만 공유 서버라면 적절하지 않으며, 특정 저장소로 범위가 제한된 deploy key를 사용하는 것이 더 나은 해결책입니다. 선택 사항에 대한 자세한 내용은 SSH 키 관리 기초에서 다룹니다.

API 키의 경우, 에이전트 전용 키를 생성하여 사용 한도를 설정하고, agent 사용자가 소유하며 권한이 600으로 설정된 파일에 저장하십시오. 서버가 삭제되면 키가 유출되었는지 고민할 필요 없이 해당 키를 즉시 폐기하십시오. 키별로 모델 사용 비용을 가시화하는 것이 VPS에서의 AI 에이전트 비용 제어에 나오는 수치를 예측 가능하게 유지하는 방법이기도 합니다.

에이전트의 네트워크 접근 범위 제한

파일 시스템 격리는 경계 설정의 절반에 불과합니다. 나머지 절반은 이그레스(egress), 즉 프로세스가 통신할 수 있는 대상을 제어하는 것입니다. 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 같은 곳에 접근하기에도 충분합니다. 진정한 도메인 허용 목록을 구현하려면 요청된 호스트 이름을 읽을 수 있는 프록시를 거쳐야 하는데, 이는 1인 개발 환경에서 구축하기에는 다소 복잡한 구조입니다. 현재 보유한 수준을 명확히 인지하십시오. 이는 포트 단위의 이그레스 제어이며, 언제든 유실되어도 무방한 장비에서 수행해야 합니다.

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

작업마다 깨끗한 상태를 유지하는 것은 저평가된 이점입니다. 이전 티켓을 처리하는 데 3시간을 보낸 에이전트는 설치된 패키지, 절반만 적용된 마이그레이션, 오래된 node_modules, 그리고 아무도 검토하지 않은 변경 사항이 포함된 git 작업 트리를 남깁니다. 다음 작업은 이 모든 것을 상속받게 되며, 여러분은 어떤 엉망진창이 어떤 실행 과정에서 발생했는지 파악하느라 검토 예산을 낭비하게 됩니다. 범위가 좁은 에이전트는 애초에 남기는 것이 적으므로, 일회용 머신과 작동하는 가장 작은 변경 사항을 에이전트가 수행하도록 유도하는 기술을 결합하면 diff와 잔여 상태를 모두 검토 가능한 수준으로 작게 유지할 수 있습니다.

가장 저렴한 방법은 작업마다 새로 체크아웃하는 것입니다.

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

더 강력한 방법은 머신 설정 직후, 에이전트가 건드리기 전에 공급자 스냅샷을 한 번 찍어두는 것입니다. 해당 스냅샷을 복원하면 패키지를 포함한 시스템 전체가 알려진 상태로 돌아갑니다. 대부분의 공급자는 이를 머신 내부의 명령어가 아닌 제어판이나 API를 통해 제공하므로, 정확한 단계는 사용 중인 공급자에 따라 다릅니다. 머신이 여전히 평범한 상태일 때 스냅샷을 찍는 습관을 들이십시오.

중요한 데이터는 일회용 머신에 두지 마십시오. 즉, 브랜치를 로컬에 쌓아두지 말고 푸시해야 합니다. 만약 머신에 잃어버리면 안 되는 데이터가 남았다면 VPS의 restic 백업을 통해 적절히 백업하십시오. 파괴 가능한 머신은 파괴하는 과정이 진정으로 아무 일도 아닌 것처럼 느껴질 때만 유용합니다.

여러 대의 서버 비용을 지불하지 않고 여러 개의 격리된 환경을 원한다면, 더 큰 VPS 하나에서 게스트 VM을 직접 호스팅할 수 있습니다. VPS에서의 중첩 가상화는 이 방식의 작동 원리와 공급자가 이를 허용하는지 확인하는 방법을 다룹니다. 여기서 격리는 양날의 검과 같아서, 만약 같은 머신에 있는 두 에이전트가 서로 격리된 채로 있는 것보다 협력하기를 원한다면, 모든 인수인계를 여러분을 거쳐서 처리하는 대신 하나의 Claude Code 세션이 다른 세션으로 텍스트를 직접 전송할 수 있습니다.

신중하게 관리하는 노트북이 충분히 안전한 경우

과도한 격리를 강조하면 사람들이 경청을 멈추게 되므로, 이 부분은 솔직해질 필요가 있습니다.

명령어를 실행하기 전에 매번 검토한다면 노트북 환경으로도 충분합니다. 권한 프롬프트는 실질적인 통제 수단이며, 서버에서 Claude Code를 안전하게 실행하기 문서에서는 각 단계가 실제로 무엇을 차단하는지 설명합니다. 작업 환경이 단일 저장소이고 기기 내에 운영용 자격 증명이 없다면, 사고 발생 시의 영향 범위는 이미 작습니다. 에이전트 세션이 짧고 감독하에 이루어진다면 노출 시간 또한 짧습니다.

프롬프트를 건너뛰는 순간 상황은 달라집니다. 2026년 8월 14일부터 Claude Code의 기본 설정이 자동 모드로 변경되어 새로 설치 시 파일 수정이나 명령어 실행 전에 확인을 거치지 않게 된다는 점을 고려해야 합니다. 무인 실행, 야간 작업, 계획을 승인하고 자리를 비우는 모든 워크플로우는 격리 역할을 하던 인간의 검토 과정을 제거합니다. 바로 그때 기계가 그 역할을 대신해야 합니다. VPS에서 코딩 에이전트를 실행하여 여러 저장소를 동시에 다루는 등 에이전트의 접근 범위를 넓히는 모든 경우에도 동일하게 적용됩니다.

이 결정은 모델을 얼마나 신뢰하느냐의 문제가 아닙니다. 모델이 잘못된 판단을 내렸을 때 그 옆에 무엇이 있느냐의 문제입니다.

FAQ

컨테이너 격리만으로 코딩 에이전트를 운영하기에 충분합니까?

대부분의 작업에서는 충분하지만, 두 가지 조건이 필요합니다. 컨테이너를 --privileged 권한으로 실행해서는 안 되며, /var/run/docker.sock를 컨테이너 내부에 마운트해서도 안 됩니다. 두 경우 모두 프로세스가 호스트의 root 권한을 획득할 경로를 제공하기 때문입니다. 컨테이너는 호스트 커널을 공유하므로 가상 머신보다 격리 경계가 약합니다. 에이전트가 인터넷에서 가져온 신뢰할 수 없는 코드를 실행한다면 가상 머신이나 별도의 서버를 사용하는 편이 좋습니다.

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

아니요. sudo 권한을 부여하면 구축한 격리 환경이 무의미해집니다. root 사용자는 서버 내의 모든 계정을 읽을 수 있기 때문입니다. sudo 권한이 없는 에이전트 전용 사용자를 생성하고, 해당 사용자의 작업 디렉터리에만 쓰기 권한을 부여하십시오. 작업 수행을 위해 패키지 설치가 반드시 필요하다면, 공유 서버의 root 권한을 주는 대신 에이전트가 단독으로 사용하는 머신을 할당하십시오.

서버에 SSH 키를 저장하지 않고 에이전트가 git에 푸시하게 하려면 어떻게 합니까?

서버에 접속할 때 ssh -A 옵션을 사용하여 SSH 에이전트를 포워딩하십시오. 서명 요청은 연결을 통해 전달되고 개인 키는 사용자의 노트북에 그대로 남습니다. 따라서 ssh -T git@github.com을 통해 인증이 이루어지며 서버에 개인 키를 두지 않고도 git push을 사용할 수 있습니다. 주의할 점은 사용자가 접속해 있는 동안 서버의 root 사용자가 포워딩된 소켓을 사용할 수 있다는 것입니다. 다른 사람과 공유하는 머신이라면 저장소 범위로 제한된 deploy key를 사용하십시오.

에이전트에게 필요한 VPS 사양은 어느 정도입니까?

에이전트 작업은 주로 파일 편집, 빌드 실행, 테스트 수행으로 이루어지므로 모델 사양이 아닌 빌드 환경에 맞춰 머신 크기를 결정하십시오. 호스트형 모델은 제공자의 하드웨어에서 실행되므로 네트워크 트래픽만 발생할 뿐 로컬 부하는 거의 없습니다. 스크립트 작업은 2 GB RAM으로 시작하고, 저장소에서 컨테이너를 빌드하거나 대규모 컴파일을 수행한다면 8 GB로 증설하십시오.

머신을 얼마나 자주 삭제하고 다시 구축해야 합니까?

상태를 설명할 수 없게 되었을 때 다시 구축하십시오. 최소한 머신 내의 자격 증명이 노출되었을 가능성이 있다면 즉시 다시 구축해야 합니다. 작업 사이에 코드를 새로 체크아웃하면 일상적인 설정 변화를 관리할 수 있으며, 첫 번째 에이전트 실행 전에 스냅샷을 찍어두면 깨끗한 시스템 이미지로 되돌릴 수 있습니다. 다시 구축하는 과정이 번거롭게 느껴진다면, 일회용이라고 생각했던 머신에 중요한 무언가가 남아 있다는 신호입니다.