▲

Monty - AI 생성 코드를 안전하게 실행하는 경량 Python 인터프리터

(github.com/pydantic)
5P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • AI가 생성한 코드를 안전하게 실행하기 위해 설계된 Rust 기반의 경량 Python 인터프리터로, 컨테이너 샌드박스의 복잡성과 지연을 제거
  • 파일시스템·환경변수·네트워크 접근을 완전히 차단하고, 개발자가 지정한 외부 함수만 호출 가능
  • 1 마이크로초 미만의 시작 시간과 CPython과 유사한 실행 성능을 제공하며, Rust·Python·JavaScript에서 모두 호출 가능
  • 실행 상태를 바이트 단위로 스냅샷 저장 및 복원할 수 있어, 프로세스 간 중단·재개가 가능
  • Pydantic AI의 Code Mode 기능을 구동할 예정으로, LLM이 작성한 Python 코드를 안전하게 실행하는 핵심 구성요소로 사용

Monty 개요

  • Monty는 Rust로 작성된 실험적 Python 인터프리터로, AI가 생성한 코드를 안전하게 실행하기 위한 도구
    • 컨테이너 기반 샌드박스의 비용·지연·복잡성을 피하고, LLM이 작성한 Python 코드를 직접 실행 가능
    • 시작 시간은 수 마이크로초 단위, 일반적인 컨테이너의 수백 밀리초보다 훨씬 빠름
  • 가능한 기능
    • Python 코드의 일부 문법 실행 지원, 타입 힌트 기반 정적 타입체크 포함
    • 호스트 접근 완전 차단, 외부 함수 호출은 개발자가 명시적으로 허용한 함수만 가능
    • Rust·Python·JavaScript에서 호출 가능하며, 리소스 사용량 추적 및 제한 기능 내장
    • stdout/stderr 수집, 비동기 코드 실행, 스냅샷 저장 및 복원 기능 지원
  • 제한 사항
    • 표준 라이브러리는 sys, typing, asyncio, dataclasses(예정), json(예정)만 사용 가능
    • 클래스 정의 및 match 문은 아직 미지원
    • 서드파티 라이브러리는 지원 대상 아님
  • 설계 목적은 단 하나, 에이전트가 작성한 코드를 안전하게 실행하는 것

Pydantic AI 통합

  • Monty는 Pydantic AI의 Code Mode를 구동
    • LLM이 도구 호출 대신 Python 코드를 작성하고, Monty가 이를 안전하게 실행
    • 예시에서는 get_weather, get_population 같은 함수형 도구를 정의하고, LLM이 이를 호출하는 코드 작성

대안 기술 비교

  • Monty는 언어 완전성은 제한적이지만, 보안·속도·단순성에서 우수
    • 시작 지연 0.06ms, 무료, 설치 간단, 스냅샷 기능 지원
  • 다른 기술과의 비교 요약:
    • Docker: 완전한 CPython 환경, 보안 양호하나 시작 지연 195ms
    • Pyodide: WASM 기반, 보안 약하고 시작 지연 2800ms
    • starlark-rust: 매우 제한된 언어, 빠르지만 Python과 다름
    • sandboxing 서비스: 보안 강력하나 비용·지연·설정 복잡
    • YOLO Python(exec/subprocess) : 빠르지만 보안 전무
  • Monty는 파일 접근 제어, 리소스 제한, 스냅샷 기반 중단·재개 기능을 통해
    AI 코드 실행용 안전한 Python 환경을 제공
▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • WebAssembly로 빌드한 버전을 실행해봤음. 직접 테스트할 수 있는 웹 플레이그라운드를 만들어둠
    아직 클래스 지원은 없지만, LLM이 클래스를 쓰려 하면 에러를 보고 스스로 클래스를 안 쓰는 코드로 다시 작성함
    빌드 과정을 정리한 글은 여기에 있음

    • 말은 맞지만, 이런 하위 추상화 수준의 작은 불편함들이 쌓이면 상위 레벨의 성능이 떨어짐. LLM이 본래 문제 해결 대신 파이썬 인터프리터의 허점을 우회하는 데 리소스를 쓰게 됨
    • 멋진 프로젝트지만, 구체적인 사용 사례가 잘 안 떠오름. MCP 호출을 Monty 함수로 대체하는 코드모드용인가, 아니면 질의 전후처리나 CaMeL 구현용인가?
      터미널 에이전트의 강점이 네트워크·파일시스템 접근인데, 그렇다면 샌드박스 컨테이너가 자연스러운 확장처럼 느껴짐
    • 솔직히 왜 필요한지 모르겠음. 내 모델들은 이미 여러 언어로 코드를 잘 짜는데, 굳이 제한된 파이썬만 써야 할 이유가 있을까?
      Typescript, C#, Python 다 문제없이 쓰고 있음
    • “클래스를 안 쓰는 코드로 다시 작성한다”는 말은, 결국 훈련 데이터에 그런 코드가 충분히 있을 때만 가능함. 다행히 Stack Overflow 코드가 많으니 괜찮을지도 모름

  • 예전에 Git으로 옮기기 전 Mercurial을 썼던 때가 떠오름. 그땐 Git이 유행이라 다들 쓰는 것 같았지만, Mercurial의 UX가 훨씬 좋다고 생각했음
    지금은 다들 Python으로 agent exec을 짜는데, 나는 TypeScript/JS가 더 적합하다고 느낌. 빠르고 안전하며, 타입 덕분에 정보 밀도도 높음. 하지만 이번에도 내가 질 것 같음

    • Python이 JS보다 낫다고 생각하는 이유 세 가지가 있음
      1. 풍부한 표준 라이브러리 (CSV, sqlite3, json 등)
      2. LLM이 작성한 코드가 대부분 바로 동작함. JS는 Node/Deno 분리, import 문법 혼란, top-level await 같은 불안정 요소가 많음
      3. 데이터 처리 생태계가 훨씬 강력함 (csv/pandas 등)
    • 10년 넘게 Python과 JS를 써왔는데, 매번 이상한 예외 처리나 null/undefined 체크 문제로 고생했음. 그래서 매일 Python을 선택할 것 같음
    • 역사적으로 Python은 과학·AI 생태계가 강함. numpy, scipy, PyTorch 같은 라이브러리 덕분임
      개인적으로는 TypeScript의 정적 타입 시스템이 더 마음에 들지만, 속도나 보안 면에서는 두 언어 다 비슷한 수준임
    • 에이전트가 코드를 실행할 수 있으면 데이터를 직접 처리할 수 있어서 컨텍스트를 줄일 수 있음.
      Python은 이런 데이터 처리 생태계가 잘 되어 있고, Pyodide나 ty 같은 도구로 보안 문제도 완화 가능함
    • AI 덕분에 CPython도 드디어 JIT 내장 압박을 받고 있음. GPU 쪽도 Python DSL 기반 JIT이 많아서 실제 성능 차이는 크지 않음.
      이제는 NVIDIA도 Python으로 커널을 짜는 걸 공식 지원함

  • 이 프로젝트는 샌드박싱 문제에 대한 흥미로운 접근임. 예전에 jsrun이라는 실험에서 Python 안에 V8을 넣어 JS를 안전하게 실행한 적이 있음
    Monty도 비슷한 목표를 가진 듯함. 최소한의 인터프리터로 시작하는 건 AI 워크로드에 적합하지만, Python의 긴 꼬리 문법을 다루는 건 쉽지 않음
    보안성과 예측 가능성을 위해 표면적을 줄이면서도, LLM이 생성하는 복잡한 코드까지 처리할 수 있을 만큼의 기능을 제공해야 하는 균형점이 중요함

    • 목표는 코드모드나 외부 함수 호출을 단순화하는 것임. 단기적으로는 class, dataclass, datetime, json 정도만 지원해도 충분할 듯함
    • 하지만 보안이 중요한 환경에서는 결국 VM 기반 격리가 필수라고 생각함. Monty 같은 접근은 현실적 제약이 많음 (E2B 근무자 의견)

  • 약간 다른 이야기지만, Monty Roberts의 『The Man Who Listens to Horses』라는 책이 떠올랐음.
    동물의 언어를 배우는 내용인데, 책 링크와 영상이 있음

  • “LLM이 작성한 Python 코드를 초고속으로 안전하게 실행한다”는 설명이 흥미로웠음.
    다만 uv 같은 Rust 기반 런타임도 최소 10ms 정도 걸리는데, 마이크로초 단위는 어려워 보임
    그래도 표준 라이브러리 없는 미니 인터프리터라는 아이디어는 좋음. AI 샌드박싱 관점에서도 새롭고, Pydantic에서 이런 게 나올 줄은 몰랐음

    • Pydantic과 FastAPI는 요즘 가장 흥미로운 Python 팀임. 항상 새로운 프로젝트를 내놓음
    • 참고로 uv는 Rust로 작성된 런타임임

  • 나는 기존 언어를 재활용하기보다 AI 전용의 엄격한 언어를 만드는 게 낫다고 생각함
    AI는 명세를 잘 이해하므로, 인간처럼 느슨한 문법이 필요 없음.
    오히려 정확한 구조와 일관된 포맷을 강제하는 언어가 더 적합함.
    나도 이런 언어를 실험 중인데, AI 코드 생성에는 인간보다 더 높은 규율을 요구할 수 있다고 봄

    • 하지만 문제는 학습량임. 모델이 새 언어를 배우려면 엄청난 데이터가 필요함.
      이미 Python을 잘 아는 모델에게 “이 함수만 써라” 식으로 제한하는 게 훨씬 현실적임

  • jstanley가 말한 “작은 불편함(papercut)” 논점은 맞지만, 반대로 AI가 생성한 코드를 대규모로 실행할 때는 보안 리스크가 더 큼
    파일 I/O, 네트워크, subprocess 같은 기능을 완전한 CPython에 열어주는 건 위험함
    다만 클래스 제한은 이상함. 보안과는 상관없고, 단지 코드가 지저분해질 뿐임.
    아마 “최소 기능부터 시작해 점진적으로 확장”하는 접근일 듯함

    • 맞음, 클래스 제한은 보안 목적이 아니라 단순히 아직 구현이 안 된 상태임

  • CPython 전체 기능을 흉내내기보다, AI 코드에 필요한 최소한의 인터프리터를 만드는 접근이 흥미로움
    완전한 런타임은 공격 표면이 너무 넓지만, 제한된 서브셋은 안전함
    에러 피드백을 통해 LLM이 스스로 제한된 문법에 적응하도록 유도하는 전략도 현실적임.
    대부분의 툴 사용 시나리오에서는 메타클래스나 동적 import가 필요하지 않음

  • 단순한 질문이지만, seccomp로 시스템 콜을 제한하면 안 되는가?
    파일 접근을 막고 싶다면 관련 syscall을 차단하면 될 텐데, 굳이 별도 인터프리터가 필요한 이유가 궁금함

    • bvisor 같은 프로젝트가 그 방향으로 가고 있음
    • 맞는 접근이지만, 기본 런타임이 너무 강력하면 우회 가능성이 많음.
      처음부터 극도로 단순한 런타임으로 시작하면 공격 표면이 작아 훨씬 안전함

  • 프로젝트 자체는 합리적이지만, “AI용 초고속 도구”라는 말에는 웃음이 남
    AI의 사고 속도가 워낙 느려서, 코드 실행이 아무리 빨라도 전체 체감 속도에는 큰 차이가 없음
    마치 옆에서 빙하가 움직이는 속도로 일하는 동료와 함께 배달하는 느낌임

답변달기