NanoClaw: OpenClaw의 보안 문제를 겨냥한 Docker 샌드박스 AI 에이전트

호스트 직접 실행으로 보안 취약점이 지적된 OpenClaw의 대안, NanoClaw의 이중 격리 아키텍처와 Docker Sandboxes 파트너십을 정리한다.

2026-08-12 · 최초 발행 2026-03-15

AI 에이전트가 코드를 실행하고 웹을 탐색하며 파일을 읽고 쓰는 게 일상이 되면서, 보안 격리는 더 이상 선택 사항이 아니게 됐다. NanoCo가 만든 오픈소스 AI 에이전트 플랫폼 NanoClaw는 2026년 3월 13일 Docker와 공식 파트너십을 맺고 Docker Sandboxes의 MicroVM 기반 격리 인프라에 통합된다고 발표했다. 출시 한 달 만에 GitHub 스타 20,000개와 다운로드 100,000회를 돌파한 이 프로젝트는, 강력하지만 취약점이 많았던 OpenClaw의 대안으로 부상하고 있다.

OpenClaw가 남긴 숙제

NanoClaw를 이해하려면 먼저 OpenClaw를 봐야 한다. OpenClaw는 AI 모델이 웹을 탐색하고 애플리케이션을 조작하며 사용자를 대신해 작업을 수행하게 해주는 도구로, 2026년 초 폭발적인 관심을 받았다. 그러나 사이버보안 전문가들은 곧바로 구조적 문제를 지적했다. OpenClaw는 호스트 머신에서 직접 실행되기 때문에, 에이전트가 손상되면 자격 증명, 세션 기록, 다른 에이전트의 데이터에 접근당하거나 호스트 시스템 전체가 위협받을 수 있었다.

NanoClaw의 공동 창업자 Gavriel Cohen은 이 문제를 처음부터 보안 우선 설계로 풀겠다고 밝혔다. 그의 설명에 따르면 보안은 에이전트 표면 안에서 강제되어서는 안 되며, 에이전트가 올바르게 동작하리라는 전제에 의존하지 않고 에이전트 표면 바깥, OS 수준에서 강제되어야 한다는 것이 핵심 철학이다.

코드 15개 파일이라는 규모

NanoClaw가 단순한 OpenClaw 클론이 아니라는 점은 코드베이스 규모에서부터 드러난다.

격리 레이어컨테이너 레이어(에이전트 데이터 격리)MicroVM 레이어(호스트 머신 격리)기반 기술Claude Code (Anthropic)NanoClaw 아키텍처핵심 소스 파일: 15개코드 라인 수: 경쟁 대비 100배적음오픈소스: 완전 감사 가능

에이전트 동작은 단 15개의 핵심 소스 파일로 구동되며, 많은 대안 솔루션과 비교하면 코드 줄 수가 100배 이상 적다. 코드베이스 전체가 공개되어 있어 팀이 의존성·소스 파일·핵심 동작을 직접 검사하고 이해할 수 있는 완전 오픈소스이며, Anthropic의 범용 코딩 에이전트인 Claude Code 위에 구축되어 있다.

컨테이너 안의 컨테이너, MicroVM

2026년 3월 13일 발표된 Docker 파트너십은 이 보안 모델을 한 단계 더 강화한다.

단일 명령으로 실행호스트 격리Docker Sandbox (MicroVM)접근 불가접근 불가컨테이너 C에이전트 태스크 3(독립 파일시스템)컨테이너 A에이전트 태스크 1(독립 파일시스템)컨테이너 B에이전트 태스크 2(독립 파일시스템)사용자 호스트 머신

기존 NanoClaw도 이미 컨테이너 안에서 실행되어, 로컬 머신에서 에이전트 소프트웨어를 직접 돌리는 것보다는 안전했다. Docker Sandboxes가 더해지면서 그 컨테이너 자체가 다시 MicroVM 내부에서 실행되는 구조가 됐다. 컨테이너는 커널을 공유하는 격리된 프로세스인 반면 MicroVM은 자체 커널을 갖기 때문에, 호스트 시스템으로부터 한층 더 강하게 격리된다.

Cohen은 이 구조를 두 겹의 경계로 설명한다. 각 에이전트는 자체 컨테이너 안에서 실행되어 다른 에이전트의 데이터를 볼 수 없고, 그 모든 컨테이너는 다시 MicroVM 안에서 실행되어 호스트 머신을 건드릴 수 없다는 것이다. Docker Sandboxes는 현재 macOS(Apple Silicon 및 Intel)와 Linux에서 지원된다.

이 통합은 단 하나의 명령으로 배포할 수 있도록 설계됐다. 보안 솔루션이 복잡한 설정을 요구하면 개발자들이 우회로를 찾게 된다는 현실적 판단이 깔려 있다 — 설치와 실행이 간단해야 보안이 실제로 채택된다는 것이다.

왜 지금 이 문제가 커지는가

AI 에이전트는 더 이상 프롬프트에 답만 하지 않는다. 라이브 데이터 소스에 연결하고, 코드를 실행하고, 워크플로를 트리거하며, Slack·Discord·WhatsApp·Telegram 같은 협업 플랫폼에서 직접 운영된다. 이 전환은 두 가지 요구를 만든다. 하나는 투명성 — 조직이 코드를 검사하고 의존성·소스 파일·핵심 동작을 명확히 볼 수 있는 에이전트가 필요하다는 것. 다른 하나는 격리 — 애플리케이션 레벨 권한 검사만으로는 부족하고, OS 수준에서 강제되는 격리가 있어야 손상된 에이전트 하나가 자격 증명·세션 기록·다른 에이전트의 데이터에 접근하는 사태를 막을 수 있다는 것이다.

Cohen이 특히 강조한 지점은 환각(Hallucination)과 보안이 만나는 곳이다. 환각이나 오작동하는 에이전트가 보안 문제를 일으킬 수 있다면 그 자체로 보안 모델이 깨진 것이라고 그는 지적한다. 보안은 에이전트가 올바르게 동작하는 것에 기대는 게 아니라 에이전트 표면 바깥에서 강제돼야 한다는 뜻이다. LLM 기반 에이전트가 의도치 않은 행동을 할 수 있다는 전제를 깔고 보안 모델을 설계해야 한다는 통찰이다.

한 달 만의 채택 지표

출시 한 달 만에 GitHub 스타 20,000개, 다운로드 100,000회를 돌파했다. 보안 우선 AI 에이전트 인프라에 대한 개발자 커뮤니티의 수요를 보여주는 수치이며, 특히 AI 에이전트를 프로덕션에 배포하려는 기업 팀들이 가장 먼저 부딪히는 문제가 보안과 격리라는 점을 고려하면 자연스러운 반응이다.

NanoClaw와 Docker Sandboxes 조합은 엔터프라이즈 보안 기준을 겨냥해 설계됐다고 두 회사는 강조한다. 각 에이전트 태스크는 일회용 Docker Sandbox 안에서 실행되어 작업이 끝나면 전체 환경이 폐기되고, 에이전트 간 데이터 누출은 구조적으로 불가능하며, 호스트 시스템의 파일시스템·네트워크·프로세스에 대한 에이전트 접근은 차단된다. 15개 파일로 이뤄진 작은 코드베이스는 내부 보안팀의 감사를 현실적으로 만든다는 점도 강조점이다.

NanoClaw와 Docker Sandboxes의 통합은 AI 에이전트 보안이 사후 고려 사항이 아니라 설계 원칙으로 다뤄져야 한다는 흐름을 보여준다. OpenClaw가 드러낸 강력함과 취약성의 양면을 지켜본 개발자 커뮤니티가 보안 우선 대안에 이렇게 빠르게 반응한 것도 그 흐름 안에서 이해할 수 있다.

Sources

AI에이전트보안Docker샌드박스MicroVM오픈소스에이전트격리