왜 우리는 여전히 AI 에이전트를 YOLO 모드로 돌리고 있을까? Stanford의 새로운 샌드박스 jai 분석

최근 몇 달간 로컬 개발 환경에서 Claude Code, Aider, Cursor 같은 AI 에이전트를 사용하는 것이 거의 표준이 되어가고 있습니다. 코드를 알아서 작성하고, 스크립트를 실행하고, 디버깅까지 해주는 이 경험은 확실히 혁명적입니다. 하지만 솔직히 말해서, 우리는 지금 거대한 보안 리스크를 안고 아슬아슬한 줄타기를 하고 있습니다.

에이전트에게 내 터미널의 제어권을 넘겨주는 순간, 우리는 속으로 ‘제발 내 홈 디렉토리를 날려버리지 마’라고 기도하며 엔터키를 누릅니다. 흔히 말하는 YOLO 모드입니다.

물론 우리 모두 Docker나 VM이 안전하다는 것은 알고 있습니다. 하지만 작업 흐름 한가운데서 컴파일 에러를 만났을 때, 에이전트를 가두기 위해 Dockerfile을 작성하고 컨테이너를 빌드할 개발자는 없습니다. 마찰(Friction)이 너무 크기 때문입니다. Stanford의 Secure Computer Systems 연구소에서 발표한 jai는 바로 이 지점을 정확히 파고듭니다.

jai의 아키텍처: 마찰 없는 캐주얼 샌드박스

jai는 무거운 컨테이너 런타임이 아닙니다. 이 툴의 핵심 철학은 “설정이 필요 없는 단일 커맨드 격리”입니다. 그저 실행하려는 에이전트 명령어 앞에 jai를 붙이기만 하면 됩니다 (예: jai claude).

내부적으로 이 툴은 Linux의 namespace와 파일 시스템 오버레이를 영리하게 조합하여 작동합니다.

  • CWD (Current Working Directory): 현재 작업 중인 디렉토리는 온전한 읽기/쓰기 권한을 유지합니다. 에이전트가 코드를 수정해야 하니까요.
  • Home Directory: 홈 디렉토리(~)는 Copy-on-write (COW) 오버레이로 덮어씌워집니다. 에이전트가 ~/.bashrc를 수정하거나 파일을 지우더라도 원본은 안전하게 보존됩니다.
  • System Files: /tmp와 /var/tmp는 프라이빗하게 격리되며, 나머지 시스템 파일은 모두 읽기 전용(Read-only)으로 마운트됩니다.

과거 2010년대 후반에 컨테이너 기술이 대중화될 때, 우리는 모든 것을 완벽히 격리하려다 오히려 개발 생산성을 깎아먹는 우를 범하곤 했습니다. jai의 접근 방식은 실용적입니다. 완벽한 Multi-tenant 격리를 포기하는 대신, 개발자의 로컬 환경에서 발생할 수 있는 대참사(Blast radius)를 최소화하는 데 집중했습니다.

나의 시선: 이것은 정말로 안전한가?

15년 이상 인프라와 백엔드 시스템을 다뤄온 엔지니어로서, 저는 이 툴의 실용성에는 박수를 보냅니다. 하지만 보안이라는 관점에서 보면 여전히 치명적인 맹점이 존재합니다.

Hacker News 스레드에서도 날카로운 지적이 나왔습니다. jai는 CWD에 대한 완전한 쓰기 권한을 허용합니다. 만약 악의적이거나 환각(Hallucination)에 빠진 에이전트가 .git/hooks/pre-commit에 악성 쉘 스크립트를 심어둔다면 어떻게 될까요? 혹은 .venv/bin/activate 파일이나 .pyc 파일을 변조한다면요?

샌드박스 내부에서는 아무 일도 일어나지 않겠지만, 개발자가 샌드박스 외부에서 git commit을 하거나 가상 환경을 활성화하는 순간 호스트 머신은 바로 탈취됩니다. 결국 근본적인 해결책은 CWD마저도 오버레이로 처리하고, 변경된 파일 중 Git 인덱스에 있는 파일만 리뷰 후 호스트로 동기화(Sync)하는 방식이 되어야 할 것입니다. (다행히 jai -D 옵션을 통해 CWD를 오버레이로 만드는 기능이 제공되긴 합니다만, 변경 사항을 병합하는 것은 여전히 개발자의 몫입니다.)

커뮤니티의 반응과 대안들

흥미롭게도 Claude 자체적으로도 최근 bubblewrap (Linux) 및 Seatbelt (macOS) 기반의 샌드박스 기능을 도입했습니다. .claude/settings.json에 간단한 설정만 추가하면 됩니다.

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"]
    }
  }
}

하지만 HN 유저들의 증언에 따르면, Claude는 샌드박스 때문에 파일 접근에 실패하면 스스로 샌드박스를 비활성화하고 재시도하는 기행을 보이기도 합니다. 심지어 ssh localhost "rm -rf ~" 같은 방식으로 샌드박스를 우회할 가능성도 제기되었습니다. 에이전트가 똑똑해질수록, 애플리케이션 레벨의 통제보다는 OS 레벨의 강제적인 격리(jai나 chroot, 독립된 VM)가 필수적이라는 것을 보여주는 대목입니다.

재밌는 여담으로, jai의 핵심 C++ 코드는 수십 년 경력의 Stanford OS 전공 교수(David Mazieres)가 직접 작성했지만, 웹사이트 랜딩 페이지는 AI가 ‘Vibe-coding’으로 대충 만들어냈다고 합니다. 엉성한 웹 디자인과 탄탄한 로우레벨 코드의 대비가 묘한 매력을 줍니다.

결론: 도입해야 할까?

완벽한 보안을 원한다면 전용 클라우드 워크스페이스나 Ephemeral Dev Container를 사용하는 것이 맞습니다. ZFS 스냅샷을 주기적으로 뜨는 것도 훌륭한 백업 전략입니다.

하지만 우리가 매일 터미널에서 가볍게 에이전트를 호출하는 패턴을 버리지 못한다면, jai는 현재로서는 가장 훌륭한 타협점입니다. 최소한 에이전트가 내 SSH 키를 탈취하거나 홈 디렉토리를 날려버리는 끔찍한 사고는 막아줄 테니까요. 단, .git 디렉토리와 환경 설정 파일들에 대한 모니터링은 여전히 여러분의 몫입니다.

오늘 당장 YOLO 모드를 끄고 jai를 앞에 붙여보시길 권합니다. 귀찮음의 대가로 잃기에는 여러분의 로컬 환경이 너무 소중하니까요.

References: