# Monty - AI 생성 코드를 안전하게 실행하는 경량 Python 인터프리터 > Clean Markdown view of GeekNews topic #26492. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26492](https://news.hada.io/topic?id=26492) - GeekNews Markdown: [https://news.hada.io/topic/26492.md](https://news.hada.io/topic/26492.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-08T07:33:03+09:00 - Updated: 2026-02-08T07:33:03+09:00 - Original source: [github.com/pydantic](https://github.com/pydantic/monty) - Points: 8 - Comments: 1 ## Summary AI가 생성한 코드를 안전하게 실행하기 위한 **Rust 기반 경량 Python 인터프리터**인 Monty는 컨테이너 샌드박스의 복잡성과 지연을 제거하며, 파일시스템·환경변수·네트워크 접근을 완전히 차단합니다. 시작 시간이 1마이크로초 미만으로, CPython 수준의 성능을 유지하면서도 **스냅샷 저장·복원 기능**을 통해 실행 상태를 손쉽게 중단·재개할 수 있습니다. Pydantic AI의 **Code Mode**를 구동하는 핵심 구성요소로, LLM이 작성한 Python 코드를 안전하게 실행하는 기반을 제공합니다. ## Topic Body - 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 환경**을 제공 ## Comments ### Comment 50806 - Author: neo - Created: 2026-02-08T07:33:03+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46918254) - WebAssembly로 빌드한 버전을 실행해봤음. 직접 테스트할 수 있는 [웹 플레이그라운드](https://simonw.github.io/research/monty-wasm-pyodide/demo.html)를 만들어둠 아직 **클래스 지원**은 없지만, LLM이 클래스를 쓰려 하면 에러를 보고 스스로 클래스를 안 쓰는 코드로 다시 작성함 빌드 과정을 정리한 글은 [여기](https://simonwillison.net/2026/Feb/6/pydantic-monty/)에 있음 - 말은 맞지만, 이런 **하위 추상화 수준의 작은 불편함**들이 쌓이면 상위 레벨의 성능이 떨어짐. 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](https://pyodide.org/en/stable/)나 [ty](https://github.com/astral-sh/ty) 같은 도구로 보안 문제도 완화 가능함 - AI 덕분에 CPython도 드디어 **JIT 내장** 압박을 받고 있음. GPU 쪽도 Python DSL 기반 JIT이 많아서 실제 성능 차이는 크지 않음. 이제는 **NVIDIA**도 Python으로 커널을 짜는 걸 공식 지원함 - 이 프로젝트는 **샌드박싱 문제**에 대한 흥미로운 접근임. 예전에 [jsrun](https://github.com/imfing/jsrun)이라는 실험에서 Python 안에 V8을 넣어 JS를 안전하게 실행한 적이 있음 Monty도 비슷한 목표를 가진 듯함. 최소한의 인터프리터로 시작하는 건 AI 워크로드에 적합하지만, Python의 **긴 꼬리 문법**을 다루는 건 쉽지 않음 보안성과 예측 가능성을 위해 표면적을 줄이면서도, LLM이 생성하는 복잡한 코드까지 처리할 수 있을 만큼의 기능을 제공해야 하는 **균형점**이 중요함 - 목표는 코드모드나 **외부 함수 호출**을 단순화하는 것임. 단기적으로는 class, dataclass, datetime, json 정도만 지원해도 충분할 듯함 - 하지만 보안이 중요한 환경에서는 결국 **VM 기반 격리**가 필수라고 생각함. Monty 같은 접근은 현실적 제약이 많음 (E2B 근무자 의견) - 약간 다른 이야기지만, **Monty Roberts**의 『The Man Who Listens to Horses』라는 책이 떠올랐음. 동물의 언어를 배우는 내용인데, [책 링크](https://www.biblio.com/search.php?stage=1&title=The+Man+Who+Listens+to+Horses)와 [영상](https://www.youtube.com/watch?v=vYtTz9GtAT4)이 있음 - “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](https://github.com/butter-dot-dev/bvisor) 같은 프로젝트가 그 방향으로 가고 있음 - 맞는 접근이지만, **기본 런타임이 너무 강력**하면 우회 가능성이 많음. 처음부터 **극도로 단순한 런타임**으로 시작하면 공격 표면이 작아 훨씬 안전함 - 프로젝트 자체는 합리적이지만, “AI용 초고속 도구”라는 말에는 웃음이 남 **AI의 사고 속도**가 워낙 느려서, 코드 실행이 아무리 빨라도 전체 체감 속도에는 큰 차이가 없음 마치 옆에서 **빙하가 움직이는 속도**로 일하는 동료와 함께 배달하는 느낌임