12P by GN⁺ 5일전 | ★ favorite | 댓글 1개
  • microsandbox는 신뢰할 수 없는 사용자 및 AI 코드 실행을 안전하게 가상 머신 수준의 격리로 제공함
  • 초고속 부팅(200ms 이하), OCI 컨테이너 호환성, 자체 호스팅 등 기존 VM·컨테이너의 단점을 극복함
  • 다양한 프로그래밍 언어용 SDK와 CLI 도구로 개발자 및 AI 툴 통합 효율성 극대화함
  • 코드 실행, 개발 환경, 데이터 분석, 웹 자동화, 앱 호스팅 등 폭넓은 AI·개발 활용 사례에 적합함
  • 모든 작업은 프로젝트 기반으로 관리 가능하며, 시스템 전역 설치 및 세션 유지/격리 실행 환경 지원함

  • microsandbox는 신뢰할 수 없는 사용자 코드나 AI 코드 (예: AI 에이전트, 사용자 제출 코드, 실험성 코드)의 안전한 실행을 위해 설계된 오픈소스 자체 호스팅 플랫폼
  • 기존의 로컬 실행은 보안 취약성, 컨테이너는 커널 공유로 인한 불완전한 격리, 전통 VM은 느린 부팅, 클라우드는 유연성 부족이라는 단점이 있음
  • microsandbox는 microVM(초경량 가상 머신) 기반의 진정한 프로세스 격리를 지원하면서도, 컨테이너와 동일하게 빠른 시작 속도와 개발자 친화적 경험을 제공
  • 초기 환경 세팅 후 200ms 이내 부팅, 컨테이너 이미지(OCI) 호환성, MCP 기반 AI 통합, 자체 인프라 사용 제어 등으로 차별화

주요 특징 요약

  • Bulletproof Security: microVM 기반으로, 컨테이너의 취약점(커널 탈출)을 원천적으로 차단하는 가상 머신 수준 보안 제공
  • Instant Startup: 초기 부팅 시간이 200ms 미만으로, VM 대비 극단적으로 짧은 코드 실행 시작 속도 구현
  • Self-Hosting & Full Control: 클라우드 종속 없이 로컬·자체 서버에 직접 구축·운영 가능
  • OCI 호환: 표준 컨테이너 이미지로 그대로 실행 가능함으로써, 기존 도커·컨테이너 워크플로와 호환
  • AI-Ready (MCP 지원) : Claude, Agno 등 MCP 기반 AI와 자연스럽게 통합 및 확장 가능

빠른 개발 및 실행 워크플로

1. 서버 시작

  • 간단한 명령어만으로 microsandbox 서버 시작 및 개발 환경 구성 가능
  • 서버는 MCP 서버 역할도 겸하여, Claude 등 AI 툴에서 직접 호출 활용 가능

2. SDK 설치

  • Python, JavaScript, Rust 등 주요 언어별 microsandbox SDK 제공
  • 다양한 추가 언어 지원(SDK 확장성 제공)으로 폭넓은 개발자·AI 통합 가능성 확보

3. 코드 안전 실행

  • Python, JavaScript, Rust 등 여러 언어 샌드박스 환경을 별도로 선택하여 실행 가능
  • 각 샌드박스는 독립 실행 환경으로, 외부 코드 실행 시에도 시스템 안전성 보장
  • SDK 예제를 통해 비동기·자동화된 안전 코드 실행 프로세스 구현 용이

프로젝트 기반 환경 관리

  • 프로젝트 단위로 Sandboxfile(설정 파일)을 생성·관리하며, 개발자 친화적 패키지 매니저적 워크플로와 유사
  • 다수 샌드박스 환경(예: 서로 다른 언어, 설정)을 프로젝트에 추가해 버전/환경별로 관리 가능
  • 프로젝트 샌드박스 실행 시, 파일 및 설치 변경 내용이 로컬 디렉터리(./menv)에 자동 보존
  • 임시 샌드박스 활성화 옵션(세션 종료 시 모든 기록, 상태 완전 삭제 및 격리)

시스템 전역 샌드박스 설치

  • 자주 사용하는 환경 또는 앱을 별도 실행파일로 설치 및 등록 가능
  • 터미널에서 프로젝트 경로 없이도 한 줄 명령어로 바로 샌드박스 실행 환경 진입
  • 샌드박스별 이름 부여 및 각각 다른 설정 복수 운영, 세션 상태도 계속 유지됨

주요 활용 사례

AI 코드 실행 및 개발 환경

  • AI가 실질적인 소스코드 빌드·실행·디버깅까지 자동화할 때, 격리·반복 가능한 개발 환경 신속 제공
  • 웹앱 생성·버그 수정·프로토타입 등 코드 자동화에 적합함

데이터 분석

  • NumPy, Pandas, TensorFlow 등 주요 데이터 과학 라이브러리를 샌드박스 내에서 안전하게 활용
  • 개인정보, 민감 데이터 등 보호가 필요한 분석 워크플로에 이상적

웹 브라우징 에이전트

  • 웹사이트 탐색, 폼 제출, 로그인, 데이터 크롤링 등 자동화 업무를 AI가 안전하게 수행
  • 컨텐츠 수집, 가격 비교, 자동화 테스트 등 활용에 유용

인스턴트 앱 호스팅

  • 사용자가 만든 도구, 데모, 계산기, 시각화 등을 즉시 서비스로 공유 가능
  • 각 앱은 별도 격리 공간에서 동작, 임시 환경의 빠른 생성·종료 지원

시스템 구조

  • 사용자는 자신의 비즈니스 로직에서 microsandbox SDK 호출
  • 서버 프로세스(microsandbox server)로 신뢰할 수 없는 코드 전달·실행을 요청
  • 서버 내에서는 각각의 실행 요청이 별도의 microVM에서 수행되어 서로 격리
  • 각 microVM은 독립적 Python/Node 환경 구성 가능

오픈소스 정책

  • Apache License 2.0 하에 오픈소스 배포
Hacker News 의견
  • 정식 컨테이너 보안 등급을 보고 싶음
    1. 모든 알려진 컨테이너 취약점 목록을 큐레이션
    2. 각 취약점을 퍼미션 기반, jail, Docker, 에뮬레이터 등 여러 보안 환경에서 실행
    3. 전체 익스플로잇 중 몇 퍼센트를 막았는지를 점수로 매기면 좋겠다는 아이디어
      이런 방식이면 단순한 permission이나 jail 기반 컨테이너는 0%에 가깝고, Docker는 50% 이상, Microsandbox는 100% 가까이 나올 수 있지 않을까 기대
      “왜 그냥 jail 안 쓰냐” 같은 질문에 대한 본능적인 궁금증을 해소해 줄 수 있을 듯
      또, 오픈 웹에 honeypot 컨테이너를 띄우고 해킹에 성공하면 현금이나 코인으로 보상하는 식으로 100% 달성 컨테이너가 뭔지 ‘증명’하는 것도 재미있을 듯
      최근 Rowhammer나 Spectre같은 취약점 때문에 컨벤셔널, 클라우드 컴퓨팅 보안 자체를 재정의할 필요도 있음
      결국 완벽한 에뮬레이션 없는 100% 보안 컨테이너 개발과 OS의 기본 서비스 보안화에 대한 인사이트를 얻고 싶은 동기
  • 멀티테넌트 환경에서는 “컨테이너 취약점”이 문제가 아니라, 커널을 공유한다는 근본 구조 때문
    커널 LPE(Local Privilege Escalation) 취약점이란 게 있으면 컨테이너 탈출로 바로 이어지기 때문
    보통 컨테이너 탈출로 표시되지 않지만, 업계에선 커널 LPE가 있다고 하면 당연히 컨테이너 보안은 깨지는 걸로 인식
  • 악의적인 컨테이너에 대해선 리눅스 커널 기반의 컨테이너 런타임으로는 완전히 안전한 환경 구축이 불가능
    가시적인 대안은 샌드박스 내부에서 시스템콜(API) 사용을 대거 제한하는 방법인데, 이 경우 컨테이너가 더 이상 범용 플랫폼이 아니고, 매번 케이스별로 새로 튜닝해야 하는 불편함 존재
    그래서 가상화(virtualization)가 필요하다고 보는 입장
    메모리 세이프하고 단단한 OS가 나오지 않는 한 이 방법밖에 없고, 그런 OS가 나와도 MicroVM을 호스트 리눅스에서 돌리는 것보다 빠를지는 아직 미지수
  • 머신의 설정값도 같이 보여줬으면 좋겠는 바람
    Docker나 systemd에서 각종 설정에 따라 보안 수준이 엄청 달라짐
    어떤 설정이 어떤 위험/보안 수준으로 이어지는지 큰 실험 데이터셋이 필요하다고 생각
  • 사실 컨테이너는 이미 현금/코인 바운티가 걸린 honeypot으로 운영되고 있음
    현실적으로 진짜 운영환경 자체가 수많은 해커의 공격 대상
    이런 식의 인센티브 모델은 재미있을 수 있지만, 실제 해킹 타깃 경쟁력이나 금전적 인센티브는 현실 환경보다 훨씬 작을 듯
  • 전통적인 VM이 왜 부팅(start)이 오래 걸리는지 궁금
    예를 들어 윈도우즈에서 VM 실행할 때 아무 것도 돌기 시작하기까지 몇 초 이상 기다림
    여기서 말하는 “아무 것도 실행 안 한다”는 건 유저 프로그램 실행 전, 펌웨어 첫 명령조차 시작하기 전 상태
    심지어 가상 디스크 파일을 비우는 작업 전, 또는 VM 창이 뜨기도 전에 길게 기다리는 구간이 있음
    왜 그런지 궁금
    • 리눅스 커널을 1초 이내로 부팅하는 건 최적화로 충분히 가능
      하지만 표준 커널 기반일 땐 timeout이나 polling 등 시간이 꽤 걸리는 동작이 많음
      UEFI/CSM 시스템에서 가상 하드웨어 준비, 시스템 환경 초기화 등도 꽤 시간 소요
      WSL2는 불필요 오버헤드 제거용 특수 커널 사용 추정
      각종 OS 서비스 기동, 파일시스템 준비, 캐시 준비, 네트워크 구성 등도 영향
      전통 방식은 부트로더 → initramfs → 메인 OS 각각 따로 로드
      부트 타임을 극단적으로 줄이려면 Amazon Firecracker처럼 미리 초기화한 VM 이미지를 바로 메모리에 올리는 방식 사용
      Firecracker MicroVM 소개
      윈도우에선 HyperV 등 어떤 하이퍼바이저를 사용하느냐에 따라 부팅 속도 다름
      HyperV UEFI는 꽤 느리고, 많은 리눅스 배포판은 최적화된 미니멀 커널 제공하지 않음
    • 어떤 VM 소프트웨어를 쓰는지 더 정보 필요
      VirtualBox의 경우, 질문한 현상이 뚜렷하게 보이고, 예전 버전은 이런 딜레이 없었음
      “전통적인 VM”의 본질적 한계라기보단 그 소프트웨어만의 문제 가능성
    • 반드시 그런 건 아님
      일반적으로 VM은 불필요한 요소까지 에뮬레이션해서 느린 것
      만약 부팅 속도 위주로 하이퍼바이저를 만들고 레거시 호환성 무시할 수 있다면, Firecracker처럼 125ms만에 부팅하는 것이 가능
    • 리눅스에서 VM 메모리 할당이 느린 주 원인은 4KB 페이지로 몇 GB씩 할당할 때
      1GB 단위로 할당하면 극적으로 빨라질 수 있음
      윈도우도 이와 비슷한 방식이 아마 있음
    • VirtualBox 문제일 가능성
      본인은 Hyper-V에서 Ubuntu 22 GUI에 XRDP로 10초, Ubuntu 22 서버에 SSH로 3초 이내 접속 경험
  • 신뢰할 수 없는 코드를 실행해야 하는 상황에서 “원격 설치 스크립트를 바로 Bash에 파이프”하는 설치 안내 문구의 아이러니를 지적
    그럼에도 불구하고 기본 아이디어 자체는 대단히 흥미로움
    • 처음엔 무슨 말인지 못 알아들었지만, 설치 스크립트를 별도로 다운로드 후 직접 검증하는 것도 가능
      조만간 공식적인 배포 방법 마련 예정
  • 프로젝트를 공유해줘서 고맙다는 인사 및, 본인이 microsandbox의 제작자임을 밝힘
    Docker 컨테이너처럼 마이크로VM을 쉽게 만들 수 있도록 한 것이 목적
    궁금한 점 있으면 언제든 질문 환영
    • 당장 Python 라이브러리로 잘 써보고 있는데, sandbox를 여러 분할 호출에서 계속 유지시키고 싶음
      “Sandbox is not started. Call start() first” 같은 에러가 종종 발생
      공식 문서의 패턴은 “async with”인데, 본인 사용 방식은 클래스별로 한번 instantiate 후 여러 메서드에서 계속 활용하고 싶음
      이에 대한 추천 방법이나 베스트 프랙티스가 궁금
    • 분산/탈중앙화 소프트웨어 테스트 네트워크(Valet Network) 구축 중인데, microsandbox가 굉장히 유용할 듯
      네트워킹이 어떻게 동작하는지 궁금
      예를 들어 microvm이 오직 public IP만 접근 가능하도록 제한할 수 있나?
      즉, microvm이 local network IP는 접근하지 못하게 할 수 있는지
    • 정말 멋진 프로젝트, appcypher에게 감탄
      내장 MicroVM 기능이 OCI 런타임 인터페이스를 제공하는지 궁금
      runc/crun 대신 Docker/Podman에서도 쓸 수 있는지 알고 싶음
    • readme를 빠르게 스캔했는데, 추가 설명이 궁금한 질문들 있음
      어떻게 그렇게 빠를 수 있는지?
      전통적 VM 대비 어떤 트레이드오프가 있는지?
      VM 격리성이 손상될 수도 있는 여지가 있는지?
      GUI를 띄울 수 있는지?
      새로운 Vagrant로 생각하는지?
      데이터 입출력은 어떻게?
    • 굉장히 깔끔해 보임
      만약 제대로 이해했다면, 이걸로 실시간으로 백엔드도 서버처럼 띄울 수 있나?
      지원 언어 목록이 인상적 microsandbox 지원 언어 리스트
      기여 가이드가 더 상세했으면 좋겠음 contributor guide
  • 최근 몇 년간 초경량, 거의 일회용에 가까운 VM 옵션이 많아진 점에 놀람
    과거에는 VM이 느리고 무거워 고생스러웠던 경험 있음
    macOS의 Orbstack, 특히 “Linux machines” 기능과 비교해보고 싶음
    Orb에서는 VM을 하나만 재사용할지도 궁금
  • 축하 인사
    밀리초 단위로 VM 부팅하는 건 굉장히 중요한 향상
    하지만 CloudHypervisor, Firecracker로도 비슷하게 구현 가능
    컨테이너가 VM보다 이기는 건 런타임 퍼포먼스
    VM이 느려지는 요인은 IO 디바이스 에뮬레이션 때문
    특히 AI 에이전트형 워크로드에선 애플리케이션 단에서 오버헤드가 체감될 듯
    성능 이슈는 어떻게 해결할 계획인지 궁금
    • 맞는 지적임
      Microsandbox는 libkrun을 사용하고, libkrun은 성능 오버헤드를 줄이기 위해 block, vsock, virtio-fs에 virtio-mmio를 씀
      Firecracker도 본질적으로 비슷하며, E2B 프로젝트는 agentic AI 워크로드 처리에 Firecracker 사용
      당장 파일시스템 이슈 외에 큰 성능 향상 계획은 없음
  • 본인 취향상 컨테이너 기술이 OS를 너무 과하게 확장시키는 느낌
    mount 명령 하나만 쳐봐도 무슨 말인지 알 수 있음
    원래 감춰야 할 정보가 다 드러나서, 기존 간단한 명령어 활용성 저하
    더 심각한 문제는 유저가 내부 데이터 구조를 직접 만질 수 있다는 점
    마치 사용자에게 peek, poke 권한을 모두 주는 것 같음
    컨테이너 아이디어 자체는 좋지만, 커널이 재설계되지 않는 한 현재 방식은 임시방편
    • 글 내용이 잘 이해가 안 감
      컨테이너 안에서 mount 치면 어떤 점이 그렇게 치명적인지 설명 부탁
      Host mount가 실제 컨테이너에 노출되는 건가?
      보통은 명시적으로 volume 등을 컨테이너에 연결할 때만 가능하다고 생각
  • 매우 흥미로워 보여서 바로 써보고 싶어짐
    본인도 CodeSandbox SDK, E2B 등으로 재미를 많이 봤는데, 둘과의 차이점이나 향후 방향 궁금
    Firecracker도 내부적으로 쓰는지 알고 싶음
    • Microsandbox는 클라우드 솔루션을 제공하지 않음
      자신이 직접 호스팅하는 구조
      E2B처럼 microVM 기반 샌드박스를 로컬 환경(Linux, macOS, Windows(예정))에서 실행하기 쉽게 하고, 프로덕션 환경 전환도 간단
      Firecracker 대신 libkrun 사용
    • Firecracker 사용 여부가 가장 궁금했는데, 그게 주 관심
      microVM 솔루션의 유지보수 이슈, 보안 감사가 꾸준히 이뤄질지 궁금
      Firecracker와 OCI 이미지 세팅이 어려워서 대안의 등장 자체를 환영
      Kata container도 다루기 힘듦
  • 이런 종류의 프로젝트가 나오면 항상 관심이 감
    컨테이너의 가장 큰 장점은 디스크 크기, CPU 코어 등 구체적 리소스 지정 없이 빠르게 돌릴 수 있다는 점
    그 상태를 image와 diff해서, 프로그램이 실행 중 시스템에 어떤 변화를 줬는지도 확인 가능
    이런 간편성을 갖춘 초소형 VM을 통해서 보안성 강화된 샌드박싱이 가능하면 좋겠음
    가끔은 bwrap도 쓰지만, 커맨드라인에 적합한 툴은 아님
    • 리소스(디스크 용량, CPU 등)는 YAML 파일로 한 번 선언해놓으면 됨
      템플릿이나 원격/자동 생성도 가능
  • 주제가 약간 빗나가지만, 본인은 신뢰할 수 없는 JavaScript 코드를 꼭 돌려야 하는 프로젝트 진행 중
    microsandbox 덕분에 이런 코드를 안전하게 분리해서 돌릴 수 있겠다는 희망
    200ms 부팅 딜레이도 라이브 샌드박스 풀로 해결 가능
    OCI 호환성이 있으니, 전체 샌드박스 환경까지 제공 가능
    이게 정말 좋은 활용처 맞는지, 더 좋은 대안 없는지도 궁금
    • runsc/gVisor도 고려해볼 만함
      runsc 엔진은 Docker/Docker Desktop 안에서도 실행 가능
      단, gVisor는 네트워크 병렬 처리 등 성능이 docker 대비 1/3 수준임
    • 바로 이런 케이스가 microsandbox의 이상적인 적용처
      더 좋은 대안을 못 찾아서 직접 microsandbox를 만듦