▲

NanoClaw를 Docker 샌드박스에서 실행하기

 (nanoclaw.dev)
22P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • NanoClaw와 Docker의 협력으로, 한 줄 명령으로 각 AI 에이전트를 격리된 Docker 샌드박스에서 실행할 수 있게 됨
  • 각 에이전트는 마이크로 VM 내부의 독립 컨테이너에서 동작하며, 호스트 시스템 접근 없이 완전한 격리 환경을 가짐
  • 이중 보안 경계 구조를 통해 컨테이너 탈출 시에도 VM 단에서 차단되어, 호스트 파일·자격 증명·애플리케이션이 보호됨
  • NanoClaw의 보안 모델은 ‘불신을 전제로 한 설계’ 로, 에이전트를 잠재적 악성 행위자로 간주하고 피해를 최소화하는 구조를 채택
  • 향후 컨텍스트 공유 제어, 지속형 에이전트, 세분화된 권한 정책, 인간 승인 절차 등 대규모 에이전트 팀 운영을 위한 기능 확장을 목표로 함

Docker 샌드박스 통합 개요

  • NanoClaw는 Docker와의 협력을 통해 한 줄 명령으로 샌드박스 실행을 지원
    • macOS(Apple Silicon)과 Windows(WSL)에서 지원되며, Linux는 곧 추가 예정
    • 설치 스크립트가 클론, 설정, 샌드박스 구성을 자동 처리
  • 각 에이전트는 마이크로 VM 내부의 독립 컨테이너에서 실행
    • 별도 하드웨어나 복잡한 설정이 필요하지 않음
    • 각 컨테이너는 자체 커널과 Docker 데몬을 가지며, 호스트 접근이 차단됨

작동 방식

  • Docker 샌드박스는 하이퍼바이저 수준의 격리를 제공하며, 밀리초 단위의 빠른 시작 속도를 가짐
  • NanoClaw는 이 구조에 자연스럽게 매핑됨
    • 각 에이전트는 독립된 파일시스템·컨텍스트·도구·세션을 보유
    • 예: 영업용 에이전트는 개인 메시지에 접근할 수 없고, 지원용 에이전트는 CRM 데이터에 접근 불가
  • 마이크로 VM 계층이 두 번째 보안 경계를 형성
    • 컨테이너 탈출 시에도 VM 벽에 막혀 호스트 시스템 보호

보안 모델: 불신 기반 설계

  • NanoClaw는 AI 에이전트를 신뢰하지 않는 구조를 전제로 설계
    • 프롬프트 인젝션, 모델 오작동 등 예측 불가한 위험을 고려
    • 에이전트 환경에 비밀정보나 자격 증명을 넣지 않도록 설계
  • 보안은 에이전트 외부에서 강제되는 구조로, 올바른 동작에 의존하지 않음
  • OpenClaw와 달리 NanoClaw는 에이전트 간 완전한 격리를 제공
    • OpenClaw는 동일 환경을 공유해 개인·업무 데이터가 혼재될 수 있음
  • 에이전트를 협업 대상이자 잠재적 공격자로 간주하는 보안 엔지니어링 원칙을 강조

향후 발전 방향

  • 대규모 에이전트 팀 운영을 위한 새 인프라와 런타임 계층 구축 필요성 제시
  • NanoClaw는 이미 여러 Slack 채널과 연결해 업무별 독립 에이전트 운영 가능
  • 다음 단계로 제시된 네 가지 핵심 기능
    • 통제된 컨텍스트 공유: 팀 내 자유로운 정보 공유와 팀 간 선택적 공유를 병행
    • 지속형 에이전트 생성: 일회성 하위 에이전트가 아닌, 영속적 ID·환경·데이터를 가진 팀 구성원 형태
    • 세분화된 권한 정책: 이메일 읽기만 허용, 특정 저장소 접근 제한, 지출 한도 설정 등 세밀한 제어
    • 인간 승인 절차: 되돌릴 수 없는 작업은 인간 검토 후 실행
  • NanoClaw는 보안 중심의 런타임 및 오케스트레이션 계층, Docker 샌드박스는 엔터프라이즈급 인프라 기반으로 제시됨
  • 목표는 기본 격리, 통제된 협업, 조직 수준의 가시성과 거버넌스를 동시에 제공하는 에이전트 실행 스택 구축

NanoClaw 개요

  • NanoClaw는 오픈소스 보안 런타임 및 오케스트레이션 레이어로, 팀 단위 AI 에이전트 운영을 지원
  • GitHub에서 프로젝트를 확인하고 별표(star)로 참여 가능
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 작은 디테일 같지만 몇 가지 새로운 설계 결정이 업계 전반에 퍼지면 혁신적 변화를 가져올 것 같음
    Karpathy가 언급했듯, Slack·Discord 같은 통합을 직접 구현하는 대신 “통합을 작성하는 방법”에 대한 스킬(spec) 을 제공하는 접근이 핵심임
    “Claude native development”라 부를 수 있는데, 기존의 “batteries-included” 프레임워크 대신 “fork and customize” 방식으로 생태계가 이동할 것 같음
    다만 테스트·검증·보안 같은 스펙을 어떻게 배포할지 등 해결할 과제도 많음
    OS 수준에서도 이런 변화가 일어날 수 있을지 궁금함. 각 인스턴스가 강한 면역체계를 가진다면 공격에 더 강한 이질적 생태계가 될 수 있을 것 같음

    • 각 사용자가 같은 작업을 반복해야 하므로 효율성이 떨어질 것 같음. 한 번 구현해 모두가 공유하는 편이 낫다고 생각함
    • 오픈소스의 강점은 협업과 검증 과정임. LLM이 처음엔 버그를 많이 내듯, 사람도 마찬가지임. 나는 검증된 기반 위에서 커스터마이징하는 게 더 낫다고 봄
    • 코드 대신 Markdown 스펙 파일을 주고받으며 기능을 구현하는 세상이 될 수도 있겠다는 생각을 해봄

  • 보안 도구나 샌드박싱을 논할 때는 반드시 위협 모델(threat model) 을 명시해야 함
    AI 에이전트가 비밀 데이터가 있는 호스트에서 임의 코드를 실행할 수 있다는 점이 위험함
    예를 들어, 메일함 삭제, 캘린더 유출, 잘못된 송금 등은 샌드박스만으로 막을 수 없음
    따라서 샌드박싱 외에도 작업별·도구별 세분화된 권한 제어가 필요함. 예: “이 요청은 Gmail 읽기만 가능하고, 쓰기·삭제는 불가해야 함”

    • 완전히 동의함. 여기에 더해 도구 간 데이터 흐름 추적(IFC) 과 권한 감쇠(ocap) 기능이 필요함. 예를 들어 “원래 메일 스레드 외부로 데이터 전송 금지” 같은 정책을 표현할 수 있어야 함
    • “Don’t Trust AI Agents” 글에서 말했듯, AI 에이전트는 불신을 전제로 설계해야 함. 오작동이나 프롬프트 인젝션을 가정하고 피해를 최소화하는 구조가 필요함
    • 나는 정책 제어 중심의 에이전트 프레임워크 smith-core와 게이트웨이 smith-gateway를 만들었음. 하지만 이런 보안 설계 논의는 커뮤니티에서 거의 주목받지 못함
    • 흥미로운 글을 봤는데, OpenClaw Sandbox에서 언급하듯 권한은 이진적이지만 LLM의 행동은 확률적이라 두 개념이 본질적으로 충돌함
    • 사실 IAM, WIF, Macaroons, Service Accounts 같은 기존 권한 시스템이 이미 존재함. 보안팀에 물어보면 회사 내에서도 활용 가능한 솔루션이 있을 것임

  • NanoClaw가 마음에 듦. OpenClaw는 너무 복잡했는데 NanoClaw는 훨씬 간결함
    Claude Code를 설정 인터페이스로 쓰는 첫 프로젝트인데, 기능 추가도 재미있고 잘 작동함

    • 내 OpenClaw 인스턴스는 최근 깨졌음. 업데이트가 OpenRouter 통합을 망가뜨렸고, 코드가 지나치게 복잡함
      보안 모델도 내 루트리스 Kubernetes 환경과 맞지 않아 매번 문제가 생김
      그래서 Nullclaw로 옮겼음. Zig 언어를 배우며 디버깅할 수 있어서 학습 측면에서도 흥미로움
    • Nanoclaw에서 Claude로는 쉽게 만들 수 없는 워크플로우가 어떤 게 있는지 궁금함

  • Docker 샌드박스는 Apple의 container 프레임워크와 유사함
    macOS에서는 Docker보다 훨씬 가벼운 네이티브 런타임으로 적합함
    하지만 Linux에서는 하이퍼바이저를 쓰고 싶지 않음. Linux namespace만으로도 충분히 격리 가능함
    왜 OpenClaw나 NanoClaw는 제대로 구성된 공식 Docker 이미지를 제공하지 않는지 궁금함

    • 나는 macOS에서는 Apple Container, 다른 OS에서는 Podman을 씀
      Container의 네트워크 버그가 좀 있지만 가치가 큼. DNS 설정만 수정하면 됨
      Claude Code나 Node.js를 호스트에 설치하지 않아도 돼서 만족스러움

  • 컨테이너 여부보다 중요한 건 무엇을 하려는가임
    유용한 작업에 토큰을 쓰는 방법을 찾기 전까지 런타임은 부차적임
    보안 측면에서 LLM을 컨테이너에 넣는 것만으로는 부족함. 중요한 건 접근 가능한 정보의 범위임
    에이전트가 모든 데이터에 접근할 수 있다면 그게 진짜 위험임

    • Docker 샌드박스는 MicroVM을 추가 격리층으로 사용함. 단순한 컨테이너가 아님

  • 세밀한 권한과 정책 제어가 핵심임
    단순히 어떤 도구를 쓸 수 있는지가 아니라, 무엇을 할 수 있는지까지 정의해야 함
    예: 이메일 읽기만 가능, 특정 저장소만 접근, 지출 한도 설정 등
    Docker 샌드박싱만으로는 메시징 계정 같은 민감한 자산을 LLM에게 맡기기엔 불안함

  • Docker 샌드박스는 각 에이전트마다 전용 MicroVM과 Docker 데몬을 띄우고, 유연한 egress 프록시를 함께 구성함
    리버스 엔지니어링해봤는데 꽤 흥미로운 구현임

  • NanoClaw는 바로 쓸 수 있는 완제품이 아님
    코딩 에이전트를 통해 iMessage 같은 기능을 직접 추가해야 함
    즉, Claude가 컴파일러 역할을 하는 셈임

    • 예전엔 컴파일러가 생성한 어셈블리를 직접 확인하던 시절이 있었음
      코딩 에이전트도 아직 그 수준임. 최근 “코딩 에이전트가 훨씬 좋아졌다”는 말은 과장임
      여전히 Claude에게 “그건 해결이 안 됐어, 다시 해줘”라고 반복 지시해야 함

  • 나는 “claws”와 비슷한 아이디어를 작업 중임
    메시징 앱 통합 대신 종단간 암호화된 TUI를 제공하는 방식임
    wingthing.ai / GitHub 저장소 참고
    Docker 지원 방식을 고민 중이라 이 프로젝트도 살펴볼 예정임

  • Nano/Open-Claw의 명확한 사용 사례가 궁금함. 내 디지털 생활을 대신 운영하는 건가?

    • 사실 단순함. LLM 크론잡이거나, 텔레그램·이메일 같은 채팅 커넥터임. 전자는 일반 크론으로, 후자는 수동 코드나 Gemini Gems로도 가능함
    • 이메일 요약, 일정 알림, 브리핑 문서 등 반복적 지식 작업을 자동화하는 데 유용함
    • 할 일 앱과 연결해 봇에게 메시지로 관리시키는 식임. 생산성 향상에 도움됨
    • 나는 NanoClaw를 식단·운동 코치로 씀. 목표 관리, 식단 계획, 장보기 리스트, 운동 기록까지 담당함
      Apple Container로 옮기고, LanceDB 기반 장기 기억 기능도 추가했음. 이제 같은 말을 반복할 필요가 없음
답변달기