AI 코딩 에이전트를 로컬에서 돌리면 비용은 절약되지만, 에이전트가 파일 시스템을 뒤지거나 API 키가 환경변수에 그대로 노출되는 건 여전히 찜찜한 문제입니다. Docker가 최근 이 두 가지를 한 번에 해결하는 조합을 공개했습니다.

Docker 엔지니어 Oleg Selajev가 2026년 2월 23일 Docker 블로그에 공개한 가이드로, AI 코딩 에이전트 OpenClaw를 Docker Sandboxes와 Docker Model Runner 조합으로 실행하는 방법을 다룹니다. 클라우드 API 없이, 완전히 로컬 모델로, 그러면서도 에이전트가 호스트 시스템에 손댈 수 없는 격리 환경을 구성하는 게 핵심입니다.

출처: Run OpenClaw Securely in Docker Sandboxes – Docker Blog

Docker Sandboxes가 뭔데 이게 중요한가

Docker Sandboxes는 AI 에이전트를 microVM 위에서 실행하는 Docker의 새 기능입니다. 일반 컨테이너와 달리 호스트와 커널을 공유하지 않기 때문에, 에이전트가 지정된 작업 폴더 밖의 파일을 읽거나 쓸 수 없습니다. 여기에 네트워크 프록시가 붙는데, 이 프록시가 에이전트가 연결할 수 있는 외부 호스트를 화이트리스트 방식으로 제한합니다.

API 키 문제는 여기서 깔끔하게 풀립니다. 호스트의 ANTHROPIC_API_KEY나 OPENAI_API_KEY는 샌드박스 내부에 전달되지 않습니다. 대신 프록시가 네트워크 요청에 자동으로 키를 주입하는 방식이라, 에이전트는 키 값 자체를 알 수 없고 따라서 외부로 유출할 수도 없습니다.

로컬 모델 연동에서 한 가지 까다로운 점

Docker Model Runner는 호스트의 localhost:12434에 바인딩됩니다. 그런데 샌드박스 안에서 localhost는 샌드박스 자신을 가리키기 때문에 에이전트가 Model Runner를 직접 찾을 수 없죠. 게다가 OpenClaw는 Node.js 기반인데, Node.js는 HTTP_PROXY 환경변수를 자동으로 따르지 않아 프록시를 통한 우회도 그냥은 안 됩니다.

이 문제를 해결한 방식이 흥미롭습니다. 샌드박스 안에 약 20줄짜리 경량 브리지 스크립트를 하나 심어두고, OpenClaw가 이 브리지에 요청을 보내면 브리지가 샌드박스 HTTP 프록시를 통해 호스트의 Model Runner로 포워딩하는 구조입니다.

OpenClaw → 브리지(localhost:54321) → 프록시(host.docker.internal:3128) → Model Runner(host localhost:12434)

클라우드 모델을 쓸 때는 이 브리지가 필요 없고, 프록시가 API 키를 자동 주입하는 역할만 합니다.

로컬 + 보안, 동시에 가능하다는 의미

AI 코딩 에이전트를 실무에서 쓰기 꺼리는 이유 중 하나가 “에이전트가 뭘 할지 모른다”는 불안감입니다. 특히 코드베이스 전체에 접근하거나, 환경변수에 담긴 키를 가져갈 수 있다는 점이 걸립니다. Docker Sandboxes는 이 불안의 두 축인 파일 접근과 키 유출을 구조적으로 차단합니다.

로컬 모델 실행이 가능하다는 점도 주목할 만합니다. API 비용이나 외부 전송 없이 사내 코드를 에이전트에게 맡길 수 있는 환경이 Docker Desktop 수준에서 갖춰지기 시작했다는 신호이기도 합니다. Docker는 이 샌드박스 위에서 Claude Code, Gemini, Codex 등 다른 에이전트들도 실행할 수 있다고 밝히고 있어, OpenClaw에 국한된 이야기는 아닙니다.

구체적인 설정 방법과 커스텀 이미지 빌드 과정은 원문에 상세히 나와 있습니다.