실제로 일을 하는 AI 에이전트를 만들고 배포하면서, 파일시스템 격리·WASM·MCP에 대해 가졌던 초기 가정들이 왜 과했고 무엇이 더 단순하고 실용적인 해법인지 돌아본다.
URL: https://tuananh.net/2026/01/22/i-was-wrong-about-ai-agent-sandboxing/
처음으로 실제로 무언가를 할 수 있는 AI 에이전트(코드 수정, 테스트 실행, 인프라 관리)를 만들고 배포하기 시작했을 때, 내 첫 본능은 모든 것을 꽁꽁 잠그는 것이었다. 아마도 내가 오랫동안 컨테이너/마이크로VM 영역에 몸담아 왔기 때문일 것이다. 나는 에이전트가 환각을 일으킨 채로 rm -rf / 같은 재앙으로 치닫는 일을 막기 위해 복잡하고 다층적인 격리가 필요하다고 확신했다.
돌이켜보면, 몇몇 핵심 아키텍처 결정들에 대해 내가 틀렸다는 걸 깨달았다. 아직 오지 않은 미래를 대비해 과하게 설계하고 있었고, 그 과정에서 눈앞에 있는 더 단순하고 우아한 해결책들을 놓치고 있었다.
초기에는 파일시스템 격리에 집착했다. 각 에이전트에게 깨끗하고 일회용(disposable) 환경을 제공하는 방법을 두고 많은 시간을 고민했다. 나는 Docker 레이어를 가능하게 하는 것과 같은 기술인 OverlayFS 쪽으로 기울었다. 읽기 전용 베이스 레이어와, 에이전트가 작업을 마치면 폐기할 쓰기 가능한 “상단(upper)” 레이어를 두는 구상이었다.
하지만 핵심은 이렇다. 이건 규모의 문제가 아니다. 그저 추가적이고 불필요한 복잡성일 뿐이다. 대부분의 개발자는 에이전트를 안전하게 실행하기 위해서 스택에 또 하나의 특수 도구나 복잡한 커널 레벨 의존성을 추가하고 싶어 하지 않는다.
오늘날 AI 에이전트 사용 사례의 대다수가 코딩에 집중되어 있다는 점을 고려하면, 사실 대부분의 사람들에게 필요한 건 git worktree 정도면 충분하다. 우리는 이미 갖고 있고 신뢰하는 도구들을 쓰고 싶다.
Git worktree는 동일한 .git 히스토리를 공유하면서도 서로 다른 디렉터리에 여러 브랜치를 동시에 체크아웃할 수 있게 해준다. AI 에이전트에겐 이게 완벽하다. 에이전트에게 전용 worktree를 하나 주면, 에이전트는 변경을 만들고 테스트를 실행하고 심지어 로컬 환경을 “망가뜨리더라도” 메인 작업 디렉터리나 다른 에이전트에 영향을 주지 않는다. 성공하면 커밋하면 되고, 실패하면 디렉터리를 그냥 삭제하면 된다. 내장 기능이고 가볍고, 우리가 이미 쓰는 도구를 그대로 활용한다.
나는 WASM이 에이전트 보안의 은탄환이 될 거라고 정말 믿었다. 그래서 hyper-mcp도 썼다.
WASM의 약속은 놀랍다. 플랫폼에 구애받지 않고, capability 기반 보안 모델로 기본값이 네트워크와 파일시스템 접근을 샌드박싱한다. 나는 모든 에이전트 도구가 WASM 모듈이 되고, 할 수 있는 일이 엄격히 제한되는 세상을 상상했다.
문제는? 아무도 모든 것을 다시 쓰고 싶어 하지 않는다.
모든 도구, 스크립트, CLI 유틸리티를 WASM 런타임으로 몰아넣으면 마찰이 엄청나게 커진다. 에이전트가 특정 파이썬 라이브러리나 특정 버전의 CLI 도구를 필요로 하는 순간, WASM은 촉진제가 아니라 병목이 된다.
규모 있게 신뢰할 수 없는 코드를 실행해야 하는 제공자라면, 온디맨드 microVM 같은 해법이 필요할지도 모른다. 하지만 대다수에게는 완전히 과하다.
실제로는 가벼운 bubblewrap(bwrap) 샌드박스만으로도 충분하다. 이는 전체 생태계를 WASI로 컴파일하라고 요구하지 않으면서도 Linux 네임스페이스 격리를 제공한다. 혹은 많은 경우 tmux와 분리된 git worktree 인스턴스의 조합만으로도 오버헤드 없이 일을 해낼 만큼의 논리적 격리를 제공한다. Gastown과 multiclaude 같은 프로젝트가 등장하기 시작한 것도 정확히 이런 이유다. 샌드박스를 재발명하려 하기보다, 기존에 익숙한 프리미티브에 기대기 때문이다.
Model Context Protocol(MCP)은 LLM이 외부 도구와 상호작용하는 방식을 표준화하려는 훌륭한 시도다. 나도 오랫동안 이를 다뤄왔지만, 기대치를 조정해야 했다.
LLM은 기존 인류 지식의 방대한 총합으로 학습되며, 그 안에는 수십 년에 걸친 CLI 사용 경험이 포함되어 있다. LLM은 학습 데이터에서 수백만 개의 예시를 봤기 때문에 bash, grep, awk, find, curl을 어떻게 사용하는지 “알고” 있다.
우리가 MCP 같은 새로운 추상화로 이런 도구들을 감싸면, LLM의 주된 세계관에는 존재하지 않던 “번역 계층”을 종종 추가하게 된다. 에이전트가 처음 보는 MCP 인터페이스를 억지로 거치도록 만들면, 그냥 bash 스크립트를 작성하게 두는 것에 비해 성능(속도와 추론 품질 모두)이 더 낮아지는 경우가 많다.
이 때문에 Claude Skills 같은 것이 큰 인기를 얻고 있다. 단순하기 때문이다. 에이전트가 무엇을 할 수 있는지 설명하는 단 하나의 Markdown 파일일 뿐이다. 새로운 프로토콜을 배우거나 복잡한 서버를 설정할 필요 없이 누구나 자기 것을 만들 수 있다.
CLI는 기술적 AI 에이전트의 모국어다. MCP처럼 _전송(transport)_을 표준화하는 건 훌륭하지만, 셸의 힘과 익숙함을 추상화로 감춰버리려 해서는 안 된다.
내가 얻은 가장 큰 교훈은 AI 에이전트의 세계에서 복잡성은 적이라는 점이다. 추상화 계층을 하나씩 더할 때마다 깨질 수 있는 지점이 하나씩 늘고, LLM이 효과적으로 작동하기 위해 “이해”해야 할 것들도 더 늘어난다.
때로 가장 좋은 샌드박스는 하이테크 컨테이너나 WASM 런타임이 아니다. 때로는 그냥 깨끗한 git worktree와 적당한 실용주의가 전부일 수 있다.
