monty 딥다이브
— AI가 쓴 Python에 권한의 울타리를 세우는 법

1프로젝트 한줄 요약

monty는 AI가 쓴 Python 코드를 제한된 환경에서 실행하는 임베디드 샌드박스입니다. 기존 CPython에 금지 목록을 덧붙이는 대신, Python 문법의 일부를 자체 실행기로 처리합니다. Ruff로 문법을 읽고, 자체 바이트코드로 바꾼 뒤, Rust로 작성한 VM에서 실행합니다.

샌드박스가 바깥세상에서 할 수 있는 일은 호스트가 연결해 준 기능으로 결정됩니다. 파일 읽기와 도구 호출은 VM이 운영체제에 직접 요청하는 일이 아닙니다. 실행을 멈추고 요청 내용을 호스트에 전달한 뒤, 호스트가 보낸 결과로 이어 갑니다. 기본 시계와 난수 정책에는 예외가 있으므로 보안 경계는 4절과 11절에서 구체적으로 다룹니다.

1-1. 가장 작은 사용 흐름

다음은 Python 호스트 API 예제입니다. Monty는 워커 풀, checkout()은 상태가 유지되는 세션, feed_run()은 코드 조각 실행을 뜻합니다. 마지막 표현식의 값이 결과가 됩니다. API 근거는 docs/quickstart/python.md입니다.

from pydantic_monty import Monty

# 이 함수는 샌드박스 밖의 Python 호스트에서 실행된다.
def price(sku: str) -> int:
    return {'A1': 3500, 'B2': 12000}[sku]

with Monty() as pool:
    with pool.checkout() as session:
        result = session.feed_run(
            "price('A1') * quantity",
            inputs={'quantity': 3},
            external_lookup={'price': price},
        )
        print(result)  # 예상 출력: 10500

quantity는 미리 전달한 값입니다. price는 필요할 때 external_lookup에서 찾는 호스트 함수입니다. 샌드박스가 호스트의 전체 전역 변수나 모듈 목록을 받아 가는 구조가 아닙니다.

2왜 주목받는가

2-1. 에이전트의 여러 도구 호출을 코드 한 조각으로 묶는다

주문 목록을 읽고, 가격을 조회하고, 합계를 계산하는 에이전트를 생각해 봅시다. 모델이 작은 도구 호출마다 판단을 반복하는 대신, 반복문과 조건문을 가진 코드를 작성할 수 있습니다. README는 monty가 Pydantic AI의 Code Mode를 실행한다고 설명합니다. 계산과 제어 흐름은 샌드박스에 두고, 실제 업무 도구는 호스트가 제공하는 구성이 자연스럽습니다.

이런 수요와 Python의 익숙한 문법, Rust 실행기의 조합은 관심을 설명할 만한 요인입니다. 다만 트렌딩 순위를 만든 원인을 통계로 입증한 것은 아닙니다. GitHub Trending Rust Monthly #18은 2026-10-23의 선정 지표이고, 스타 8,761개는 그날의 누적 관심도입니다. 스타만으로 보안성이나 실제 도입 규모를 판단할 수는 없습니다.

2-2. 낮은 세션 시작 비용이라는 설계 목표

README는 이미 실행 중인 OSS 풀에서 새 샌드박스를 얻는 시간이 1ms 미만이라고 소개합니다. docs/alternatives.md의 상세 조건은 유휴 워커에서 세션을 빌려 1 + 1의 결과를 받는 20회 왕복의 중앙값 약 0.77ms이며, 2026-09-24의 1.0.0b3 측정입니다. 풀을 새로 만드는 비용과 Python 코드 전체의 처리 시간은 서로 다른 지표입니다.

빠른 시작 수치는 준비된 워커에서 새 세션을 만들고 짧은 계산 결과를 받는 비용과, 풀을 처음 만드는 비용을 구분해야 이해할 수 있습니다. 이 수치는 v1.3.0의 모든 환경을 보장하지 않습니다. 비교 문서도 macOS의 OSS 측정과 Linux 컨테이너의 Full Monty 측정을 직접 비교하기 어렵다고 밝힙니다.

2-3. 비슷한 문제를 푸는 선택지와 비교

다음 표는 docs/alternatives.md의 구분을 중심으로 정리한 것입니다. 속도 순위보다 필요한 Python 범위와 격리 경계를 비교하는 표로 읽으세요.

2-4. 소스가 보여 주는 강점과 README 표현의 범위

crates/monty-pool/src/pool.rs는 최소 워커를 미리 만들고, 상한까지 필요할 때 늘리는 구조를 실제로 구현합니다. crates/monty/src/run_progress.rs는 외부 요청을 상태로 돌려주며, crates/monty/src/dump_format.rs는 중단 상태를 저장합니다. 빠른 시작·제어권 반환·상태 저장은 홍보 문구만 있는 기능이 아닙니다.

반면 README의 “파일시스템·환경 변수·네트워크가 샌드박스에 없다”는 문장은 호스트 연결 없는 상태의 권한을 설명합니다. 소스에는 os·pathlib 모듈과 마운트 구현이 존재합니다. 모듈 이름의 존재와 실제 파일 접근 권한의 존재를 구분하면 모순이 풀립니다.

3기술 스택 전체 지도

monty는 일반적인 웹 백엔드와 프론트엔드를 제공하는 제품이 아닙니다. 핵심은 라이브러리와 워커 실행 파일입니다. 아래 버전은 커밋 93227e8의 의존성 선언값이며, 범위 표현은 그대로 보존했습니다. 잠금 파일이 선택한 정확한 버전이나 독자의 설치 버전과 같다는 뜻은 아닙니다.

3-1. 실행기와 백엔드에 해당하는 계층

workspace에는 19개 멤버가 있고 기본 빌드 대상은 crates/monty-runtime입니다. 내부 주요 crate는 1.3.0 버전을 함께 사용합니다. 모든 작업을 한 crate에 넣는 대신 monty-types가 경계의 공통 타입을 제공하고, 실행기는 monty, 호스트는 monty-pool과 monty-fs로 나눕니다.

3-2. Python·Node.js 연결 계층

crates/monty-js/Cargo.toml만 에디션이 2021입니다. 설정 주석은 napi-derive 생성 코드의 호환성 때문이라고 설명합니다. “이 저장소는 Rust 2024”라는 설명에도 이런 예외가 있습니다. 바인딩 crate가 자체 Python 인터프리터를 호스트 안에 넣는 것으로 이해하면 안 됩니다.

3-3. 프론트엔드·브라우저 계층

핵심 패키지에 React나 Vue 화면은 없습니다. 대신 브라우저에서 같은 실행 모델을 쓰기 위한 WebAssembly 워커 경로가 있습니다. crates/monty-wasm-runtime/Cargo.toml은 cdylib과 wit-bindgen = "0.46"을 선언합니다. JS 빌드 명령은 wasm32-wasip1로 컴파일한 뒤 컴포넌트로 변환합니다.

패키지의 exports는 Node 경로와 브라우저 경로를 나눕니다. crates/monty-js/ts/worker/pool.ts의 WorkerPool.create(), checkout()은 브라우저 워커나 Node worker thread를 빌려 줍니다. 네이티브의 자식 프로세스와 브라우저의 Web Worker는 같은 격리 장치가 아니므로 배포 환경별 차이를 읽어야 합니다.

3-4. 인프라·빌드·품질 검사

릴리스 프로필은 lto = "fat", codegen-units = 1, strip = true입니다. 최종 최적화와 배포 크기를 중시하는 설정이지만, 빌드 시간과 디버깅 편의에는 비용이 있습니다. Python client의 Maturin 선언은 >=1.9.4,<2.0, runtime은 >=1.14.1,<2.0이고, 루트 개발 도구는 >=1.15.0,<2.0으로 따로 적혀 있습니다.

• Makefile: Python·JS 빌드, Rust lint, 프로토콜 생성물 검사, 문서 예제 검사를 분리합니다.
• .github/workflows/ci.yml: Ubuntu 검사에 더해 macOS·Windows Rust 테스트를 수행합니다. Node 검사 설정에는 24가 사용됩니다.
• Python CI 행렬에는 3.10부터 3.15, 자유 스레딩 빌드인 3.14t·3.15t도 있습니다. 최소 요구사항과 CI의 폭은 다른 정보입니다.
• make check-proto는 스키마와 체크인된 생성 코드의 일치를 확인합니다. Miri·fuzz 검사도 별도 작업입니다.
• mkdocs-material>=9.7.7, mkdocstrings[python]>=0.30은 루트 pyproject.toml의 문서 의존성입니다.

기능을 어느 패키지에 넣는지는 빌드 속도뿐 아니라 신뢰해야 할 코드의 범위도 결정합니다. 이 커밋에는 Dockerfile이나 Docker Compose 설정이 없습니다. README가 언급하는 Full Monty 컨테이너를 이 OSS 저장소의 배포 파일로 혼동하지 마세요.

4아키텍처 심화 분석

4-1. 시스템 구조도: 계산은 워커, 권한은 호스트

위 그림에서 워커가 호스트 파일을 직접 여는 화살표가 없는 점을 보세요. crates/monty/Cargo.toml은 monty-fs에 의존하지 않습니다. 반대로 Python·Node 호스트 바인딩은 monty-types와 풀에 의존하고, 실행기 monty를 직접 연결하지 않습니다. 이 의존성 방향이 설계 의도를 코드 구조로 고정합니다.

4-2. 패턴 ① 단계별 변환 파이프라인

crates/monty/src/run.rs의 MontyRun::new()는 Executor::new()로 이어집니다. 여기서 입력 이름을 검사하고 소스 중첩을 점검한 뒤, compile_module_source()를 호출합니다. 이 함수의 핵심 순서는 다음과 같습니다.

// crates/monty/src/run.rs의 호출 순서만 요약
parse_with_interner(...)
    -> prepare_with_existing_names(...)
    -> Compiler::compile_module(...)
    -> interns.commit()

crates/monty/src/bytecode/op.rs의 Opcode는 #[repr(u8)]이며 명령 코드는 1바이트입니다. 인수는 뒤의 바이트에서 별도로 읽습니다. LoadSmallInt는 작은 정수를, LoadConst는 상수 테이블의 값을 가져옵니다. 다음 예시는 실제 덤프 출력이 아니라 스택 동작을 이해하기 위한 개념도입니다. 실제 컴파일러는 특수 명령과 최적화를 사용할 수 있습니다.

# 개념적인 x + 1의 실행 흐름
값 x를 스택에 넣기       스택: [41]
작은 정수 1 넣기         스택: [41, 1]
BinaryAdd               스택: [42]
결과 반환                결과: 42

여기서 배울 점은 “파서를 만들지 않고도 실행기를 만들 수 있다”입니다. Ruff가 Python 문법 해석을 맡아도, 지원할 문법의 범위·값의 표현·실행 규칙·권한은 monty가 정합니다. 외부 파서 도입이 전체 Python 호환성을 자동으로 주지는 않습니다.

4-3. 패턴 ② 바깥 작업을 실행 결과의 한 종류로 표현한다

crates/monty/src/run_progress.rs의 RunProgress를 보세요. 실행 결과가 성공과 실패 두 가지뿐이지 않습니다. FunctionCall, OsCall, ResolveFutures, NameLookup, Complete를 구분합니다. 외부 기능이 필요하다는 상황을 명시적인 상태로 반환합니다.

// crates/monty/src/run_progress.rs에서 변형 목록을 발췌
pub enum RunProgress {
    FunctionCall(FunctionCall),
    OsCall(OsCall),
    ResolveFutures(ResolveFutures),
    NameLookup(NameLookup),
    Complete(MontyObject),
}

FunctionCall에는 함수 이름, 인수, call_id, 호출 위치, 내부 실행 스냅샷이 담깁니다. 호스트는 요청을 검사하고 결과나 예외를 전달합니다. 기다리는 작업을 미래 값으로 표현할 수도 있습니다. 언어 내부의 호출 스택과 호스트의 비동기 작업을 분리할 수 있는 지점입니다.

외부 작업을 직접 실행하지 않고 요청 상태로 돌려주면, 호스트가 실행·거절·기록·재개 정책을 선택할 수 있습니다. 흔히 효과를 바깥에서 처리하는 설계와 연결해 이해할 수 있습니다. 다만 이 저장소가 특정 효과 처리 라이브러리를 사용한다는 뜻은 아닙니다.

Python에서는 feed_start()와 FunctionSnapshot으로 이 흐름을 관찰할 수 있습니다. 아래의 resume()은 실제 호스트 함수를 호출하지 않고, 우리가 결정한 반환값을 넣습니다. 근거는 docs/snapshots.md입니다.

from pydantic_monty import FunctionSnapshot, Monty, MontyComplete

with Monty() as pool:
    with pool.checkout() as session:
        paused = session.feed_start('greet(name) + "!"', inputs={'name': 'Ada'})
        assert isinstance(paused, FunctionSnapshot)
        print(paused.function_name, paused.args)
        # 예상 출력: greet ('Ada',)
        done = paused.resume({'return_value': '안녕하세요, Ada'})
        assert isinstance(done, MontyComplete)
        print(done.output)  # 예상 출력: 안녕하세요, Ada!

한 세션에는 활성 중단 지점이 하나만 있습니다. 스냅샷 객체는 실행 상태의 독립 복사본이 아닙니다. 여러 갈래로 실험하려면 dump()로 저장한 뒤 서로 다른 새 세션에 load_snapshot()해야 합니다. feed 사이의 유휴 세션은 load_session()으로 복원합니다.

저장 형식은 crates/monty/src/dump_format.rs에 있습니다. MONTY\0 매직 바이트, 리틀엔디언 버전, CBOR 본문을 사용하며 DUMP_VERSION = 13입니다. 현재 최소 지원 버전도 13입니다. 구조체의 필드 이름과 enum 변형 이름이 저장 계약이므로, 바이트코드 의미를 바꾸는 수정과 단순 필드 추가는 호환성 영향이 다릅니다.

4-4. 패턴 ③ 실행기 프로세스와 호스트를 분리한다

crates/monty-pool/src/pool.rs의 Pool::new()는 최소 워커를 미리 준비합니다. checkout_with()는 세션에 워커 하나를 전용으로 배정합니다. 유휴 워커가 없으면 상한까지 새로 만들고, 상한에 도달하면 반납을 기다립니다. PoolConfig::subprocess()의 기본값은 최소 1개, 최대는 사용 가능한 병렬성 수이며 조회 실패 시 4개입니다.

crates/monty-runtime/src/subprocess.rs의 serve()는 요청 프레임을 읽고 Child::handle()로 넘깁니다. 상태 전이의 본체는 crates/monty-proto/src/worker.rs에 있습니다. 한 요청 뒤에는 0개 이상의 출력 이벤트와 정확히 하나의 턴 종료 이벤트가 옵니다. stdout은 이 프로토콜 전용이며 진단은 stderr로 나갑니다.

crates/monty-proto/src/frame.rs는 4바이트 리틀엔디언 길이 + protobuf 본문을 사용합니다. 프레임 상한은 256 MiB, 누적 디코딩 할당의 기본 예산은 그 4배인 1 GiB입니다. 이는 정상 작업의 권장 크기가 아니라 비정상 프레임을 위한 상한입니다. 현재 프로토콜 버전은 6이고 5~6을 지원합니다.

값은 메시지마다 하나의 평평한 그래프로 전달됩니다. crates/monty/src/object_bridge.rs의 GraphExporter는 같은 객체를 다시 만나면 기존 노드를 재사용합니다. 한 객체를 여러 경로에서 가리킬 때 중복 복사가 커지는 일을 줄입니다. 순환 참조는 별도 표현을 쓰므로 호스트 변환의 모든 객체 동일성이 그대로 유지된다고 일반화해서는 안 됩니다.

이 설계가 막으려는 장애에는 스택 오버플로와 메모리 할당 실패도 있습니다. 자식이 죽어도 호스트를 유지하는 장애 격리입니다. 워커는 기본적으로 애플리케이션의 OS 권한으로 실행되므로, 자식 프로세스라는 이유만으로 컨테이너와 같은 권한 격리를 얻지는 않습니다.

4-5. 패턴 ④ 경로 문자열보다 디렉터리 권한을 붙잡는다

crates/monty-fs/src/mount_table.rs의 MountRoot::open()은 마운트할 때 cap_std::fs::Dir을 열어 보관합니다. 이후 파일 작업은 이 디렉터리를 기준으로 수행됩니다. “정규화한 경로가 허용 경로로 시작하는가”만 확인한 뒤 일반 경로로 여는 방식과 차이가 있습니다.

MountTable::handle_os_call()은 요청을 해당 마운트로 보냅니다. crates/monty-fs/src/dispatch.rs는 이를 FsRequest로 바꾸고, 읽기 전용·읽기 쓰기·메모리 오버레이 정책에 따라 처리합니다. crates/monty-fs/src/path_security.rs의 resolve_virtual_path()는 가상 경로 정책을 담당하며, 호스트 파일 경계의 본체는 열린 Dir라고 파일 설명에 명시돼 있습니다.

경로 상한도 구체적입니다. 전체 길이 4096바이트, 구성요소 255바이트, 깊이 64개입니다. 절대 심볼릭 링크는 마운트 안쪽을 가리켜도 따라가지 않는 제약이 있습니다. 가상 경로는 Windows에서도 POSIX 형태이며, 마운트의 읽기 전용 정책을 우회할 중복 호스트 경로도 검사합니다.

5디렉토리 구조 해부

5-1. 처음 읽을 파일은 다섯 묶음이면 충분하다

crates/monty/src/repl.rs의 MontyRepl은 힙과 전역 변수, 이름 테이블, 소스, 난수 상태를 유지합니다. 다음 코드를 실행할 때 과거 코드를 다시 실행하지 않습니다. 소스도 보관하는 이유는 이전 feed에서 정의한 함수의 오류 위치를 나중에 표시해야 하기 때문입니다. 세션 상태에는 결과값 이상의 정보가 필요합니다.

5-2. 코드 규모를 읽는 법

아래는 커밋 93227e8에서 확장자별 파일을 대상으로 센 물리적 줄 수입니다. 빈 줄·주석·테스트를 포함하고, .git과 심볼릭 링크는 제외했습니다. 따라서 limitations 링크를 중복 집계하지 않습니다. 생산 코드의 논리적 줄 수나 품질 지표는 아닙니다.

vendor·generated·oracle·component라는 경로 구성요소를 제외하면 Rust는 413개·219,885줄, TypeScript는 87개·16,773줄, .pyi는 19개·3,017줄입니다. 이 규칙도 모든 생성 코드를 완벽히 분류하는 기준은 아닙니다. 집계 범위를 공개해야 숫자를 비교할 수 있습니다.

Rust는 crates/monty에 143,724줄, monty-proto에 15,691줄, monty-pool에 14,834줄이 있습니다. 모두 해당 crate의 테스트 등을 포함한 값입니다. crates/monty/test_cases의 Python 사례 파일은 703개입니다. 이것을 자동으로 703개의 독립 테스트나 100% 호환성 증명으로 읽어서는 안 됩니다.

6학습 포인트 (기술별)

6-1. Rust: 소유권을 경계의 규칙으로 사용하기

MontyRun::start(self, ...)는 실행기를 소비하고, RunProgress가 다음 상태를 가집니다. 시작 전의 실행기를 그대로 두고 실행 중인 복사본도 함께 만지는 실수를 줄이는 API입니다. FunctionCall::resume() 계열을 읽으며 “누가 지금 실행 상태를 소유하는가”를 표시해 보세요.

힙에서는 Rust의 자동 메모리 관리만으로 Python의 객체 수명을 해결할 수 없습니다. Python 리스트끼리 서로 가리킬 수 있기 때문입니다. crates/monty/src/heap/mod.rs의 참조 수와 collect_cycles()는 언어가 관리하는 객체 그래프를 별도로 다룹니다. 호스트 프로그램의 Rust 값 수명과 샌드박스 객체의 수명을 구분하는 연습이 됩니다.

루트 Cargo.toml은 unsafe_code = "deny"를 선언하지만, crates/monty/src/heap/mod.rs와 crates/monty-alloc/src/lib.rs에는 근거를 명시한 예외가 있습니다. “Rust로 작성했다”와 “unsafe 코드가 전혀 없다”는 같은 말이 아닙니다. 안전한 외부 API가 의존하는 내부 불변식과 이를 검사하는 Miri·테스트까지 함께 읽어야 합니다.

crates/monty/src/heap/stable_heap.rs는 페이지당 256개 슬롯을 둡니다. 페이지 목록이 늘어나도 각 페이지의 실제 저장 위치가 바뀌지 않는 성질을 사용합니다. HeapReader::with()의 범위 제한과 함께, 주소 안정성과 대여 규칙이 어떻게 연결되는지 읽어 보세요. 저수준 힙을 수정하기보다 불변식을 먼저 문장으로 설명하는 과제가 적합합니다.

실습 아이디어: crates/monty/test_cases/refcount__cycle_mutual_reference.py를 읽고 객체와 참조를 화살표로 그리세요. 참조 수만으로 회수할 수 없는 시점을 표시하고, CcColor의 Black·Purple·Gray·White가 각각 어떤 단계인지 한국어로 적어 봅니다.

6-2. 컴파일러: 이름을 문자열에서 슬롯으로 바꾸는 이유

crates/monty/src/prepare.rs와 crates/monty/src/name_map.rs에서 이름 해석을, crates/monty/src/bytecode/compiler.rs의 compile_name()과 compile_store()에서 접근 명령 생성을 읽어 보세요. 매번 변수 이름 전체를 찾는 대신, 이름의 소속과 저장 위치를 준비 단계에서 정하는 흐름을 배울 수 있습니다.

실습 아이디어: 전역 x, 함수 인수 x, 바깥 함수의 x를 읽는 내부 함수를 각각 만들어 “같은 철자의 이름이 왜 다른 저장소를 가리키는가”를 설명합니다. crates/monty/test_cases/closure__param_shadows_outer.py가 읽기 출발점입니다. 문법을 아는 것과 스코프를 구현하는 것은 별도 문제입니다.

6-3. 비동기 시스템: 대기 중인 작업도 자원이다

crates/monty-pool/src/pool.rs는 짧고 await가 없는 구간에 동기 Mutex를 사용하고, 자리가 생기는 알림에는 Tokio Notify를 사용합니다. 비동기 함수 안이라고 모든 잠금을 비동기 Mutex로 바꾸는 방식은 아닙니다. 잠금 안에서 무엇을 하며 얼마나 오래 잡는지를 먼저 봅니다.

대여 대기 제한인 checkout_timeout, 워커 응답 제한인 request_timeout, VM 실행 시간 제한은 서로 다른 시계를 봅니다. Checkout의 feed·resume 경로를 읽으면서 “지금은 CPU 계산 중인가, 자리 대기 중인가, 호스트 작업 대기 중인가”를 구분해 보세요.

실습 아이디어: 워커 수를 하나로 가정하고 두 세션의 요청·대여·반납을 시간축으로 그립니다. 첫 세션이 실행을 끝내도 checkout을 계속 보유하면 두 번째 세션이 왜 기다리는지 설명하세요. 워커 개수와 함수 호출 개수는 일치하지 않습니다.

6-4. 타입 시스템: 실행 가능한 세계를 타입 선언으로 설명하기

타입 검사는 기본적으로 꺼져 있으며 type_check=True로 켭니다. crates/monty-type-checking/src/type_check.rs의 TypeChecker::run_with()는 메모리 기반 검사 환경에 소스와 선언을 배치하고 ty를 사용합니다. monty-typeshed는 monty가 지원하는 API에 맞춘 선언을 제공합니다.

from pydantic_monty import Monty

with Monty() as pool:
    with pool.checkout(
        type_check=True,
        type_check_stubs='def double(x: int) -> int: ...',
    ) as session:
        print(session.feed_run(
            'double(21)',
            external_lookup={'double': lambda x: x * 2},
        ))  # 예상 출력: 42

이 예제에서 선언은 검사기에 “이 함수가 있다”고 알려 주고, external_lookup는 실제 구현을 제공합니다. 선언만 넣으면 함수가 생기는 것이 아닙니다. 실습 아이디어: 인수를 문자열로 바꾸었을 때의 타입 진단과, 구현을 뺐을 때의 이름 해석 실패를 비교해 보세요.

타입 검사는 보안 정책이나 실행 성공의 증명이 아닙니다. docs/type-checking.md는 일부 upstream 선언이 실제 지원 범위보다 넓을 수 있다고 밝힙니다. 호스트 함수의 선언이 실제 동작과 일치하는지도 호스트 작성자의 책임입니다.

6-5. 프로토콜: 신뢰할 수 없는 자식의 응답도 검사한다

언어 경계가 안전하다는 목표와 통신 상대를 신뢰한다는 가정은 별개입니다. crates/monty-proto/src/frame.rs와 crates/monty-proto/src/decode_budget.rs는 프레임 크기와 디코딩 중 할당을 제한합니다. crates/monty-proto/tests/differential.rs는 수작업 wire 구현과 prost 생성 oracle의 바이트 호환성을 비교합니다.

실습 아이디어: 빈 프레임, 상한을 넘는 길이, 본문 도중 EOF, 정상 protobuf지만 잘못된 값이라는 네 경우를 표로 나눕니다. 각각 프레이밍 오류인지 값 변환 오류인지, 스트림을 계속 사용할 수 있는지 소스에서 찾아 적습니다. 임의 데이터를 실제 서비스에 보내는 실험은 필요하지 않습니다.

6-6. 테스트 설계: 결과뿐 아니라 의미를 비교한다

crates/monty-datatest/src/main.rs는 Python 사례를 Monty와 CPython에서 실행해 결과 차이를 찾는 도구입니다. fixture 헤더로 기대 실패·비동기 모드·마운트 같은 차이를 표현합니다. 의도적인 CPython 차이는 docs/limitations에 기록합니다. 지원 범위와 호환성 검증을 함께 유지하는 방식입니다.

호환성을 배우려면 성공한 예제보다 두 구현의 결과가 갈라지는 경계 조건을 읽는 편이 효과적입니다. 예를 들어 존재하지 않는 파일의 자기 자신으로 이름 바꾸기는 “아무 변화 없음”과 “파일 없음 오류” 중 어느 쪽이어야 할까요? 최신 커밋이 그 질문을 좋은 학습 사례로 제공합니다.

6-7. 자원 계측: 결과가 커지기 전에 예산을 확인하기

crates/monty/src/bytecode/vm/mod.rs의 VM::run()은 CHECK_INTERVAL = u8::MAX인 카운트다운으로 주기적인 dispatch_checkpoint()를 호출합니다. 명령마다 시계를 읽는 비용을 줄이면서 메모리·시간과 출력·GC 점검을 배치하는 선택입니다. 긴 네이티브 연산은 내부에서도 예산을 점검해야 하므로 VM 루프 한 곳만 검사해서 끝낼 수는 없습니다.

crates/monty-types/src/resource.rs의 check_large_result()는 예상 결과가 100,000바이트를 넘는 연산에서 사전 예산 점검에 쓰입니다. check_growth()는 컨테이너 버퍼가 커지는 시점을 다룹니다. 이미 크게 할당한 뒤 확인하는 방법과, 입력에서 증폭 크기를 예측해 거절하는 방법의 차이를 배울 수 있습니다.

협력적인 점검을 놓쳤을 때의 마지막 방어는 별도 계층입니다. LimitedAllocator는 강제 할당 상한을 넘으면 네이티브 워커를 종료하고, 부모는 종료 코드 65를 메모리 오류로 분류할 수 있습니다. Rust에서 실행기를 직접 연결한다면 max_memory 설정뿐 아니라 이 전역 할당기의 설치와 활성화 조건도 확인해야 합니다.

실습 아이디어: 문자열 반복, 리스트의 점진적 증가, 호스트 호출 대기를 각각 사전 크기 점검·주기 점검·호스트 정책 중 어디에서 제어해야 할지 분류합니다. 제한에 도달한 뒤 해당 세션을 버리는 정리 절차까지 그림에 넣으세요.

7하드웨어 / 시스템 요구사항

7-1. 무엇을 준비해야 하는가

crates/monty-js/package.json의 네이티브 대상은 Windows x86_64, macOS x86_64·aarch64, Linux GNU x86_64·aarch64입니다. 이 목록을 Linux musl이나 Windows arm64까지 넓혀 읽으면 안 됩니다. 브라우저의 WASM 경로에서는 호스트 디렉터리 마운트가 지원되지 않습니다.

공식적인 최소 CPU 코어 수나 RAM 용량은 이 커밋의 설정에서 확인되지 않습니다. “메모리 2GB면 충분하다” 같은 하한을 임의로 정할 수 없습니다. 소스 읽기는 일반 개발 환경에서 시작하고, 실행 서버 용량은 동시 세션 수·세션별 데이터·타입 검사·호스트 콜백을 기준으로 잡아야 합니다.

7-2. 메모리 제한과 실제 프로세스 메모리는 다르다

max_memory는 워커의 전역 할당기를 통해 요청한 바이트를 기준으로 합니다. 프로세스 RSS 전체의 상한은 아닙니다. 스레드 스택, 바이너리 매핑, 할당기 부가 비용 등을 따로 고려해야 합니다. subprocess 워커의 스택 예약 크기는 crates/monty-runtime/src/subprocess.rs의 16 MiB이며, 예약했다고 전부 실제 메모리에 상주하는 것도 아닙니다.

crates/monty-types/src/resource.rs의 memory_limit_with_headroom()은 VM 제한에 일반 실행 4 MiB, 타입 검사 사용 시 32 MiB의 여유를 더해 강제 할당 상한을 계산합니다. 여기에 워커 baseline도 더해집니다. 마운트의 메모리 예산은 별도이며 기본값은 마운트당 50,000,000바이트입니다.

7-3. 기본값부터 확인할 자원 설정

메모리와 실행 시간 제한은 직접 설정해야 합니다. 중단 횟수와 재귀 깊이는 미설정이어도 기본 상한이 있습니다. max_suspensions는 인터프리터가 혼자 강제하는 제한이 아니라 호스트에서 집행합니다. Rust로 직접 VM을 연결한다면 풀과 같은 책임을 누가 맡을지 정해야 합니다.

VM의 실행 시간 제한은 호스트 함수의 대기 시간과 서비스 요청 전체의 기한을 대신하지 않습니다. 호스트 호출을 기다리는 동안 실행 시계는 멈춥니다. 최초 feed의 컴파일도 그 실행 시간 예산에 포함되지 않습니다. 로컬 풀의 request_timeout 기본값 역시 기한 없음이므로 애플리케이션에 맞게 정해야 합니다.

8직접 해볼 수 있는 실습 과제

아래 코드는 독립된 연습 환경에서 사용할 예제입니다. Python 예제는 pydantic-monty==1.3.0 기준입니다. 각 과제는 “성공했다”보다 상태와 경계가 예상대로 유지되는가를 완료 기준으로 삼습니다.

from pydantic_monty import Monty

with Monty() as pool:
    with pool.checkout() as session:
        session.feed_run('counter = 40')
        session.feed_run('counter += 1')
        print(session.feed_run('counter + 1'))  # 42
    with pool.checkout() as fresh:
        print(fresh.feed_run('2 + 3'))  # 5

from pydantic_monty import Monty, MontyRuntimeError

with Monty() as pool:
    with pool.checkout(limits={
        'max_memory': 10_000_000,
        'max_feed_duration_secs': 0.5,
        'max_recursion_depth': 100,
    }) as session:
        try:
            session.feed_run('x = [0] * 100_000_000')
        except MontyRuntimeError as exc:
            print(exc.display(format='type-msg'))
    # 해당 세션을 정리한 뒤 별도 세션에서 다음 실험을 한다.

# path_rename()의 핵심 분기만 발췌
src_entry = self._get_entry(path)
if src_entry is None:
    raise FileNotFoundError(...)
if PurePosixPath(path) == PurePosixPath(target):
    return

9관련 기술 심화 학습 로드맵

선수 지식은 Python 함수·예외·자료구조, 프로세스와 스레드의 기본 구분입니다. Rust가 처음이라면 1~2주차에 소유권·대여·enum·Result를 함께 익히세요. 각 주차의 결과물을 작게 남기면 큰 소스를 읽은 뒤에도 구조를 다시 떠올릴 수 있습니다.

9-1. 읽는 깊이를 조절하는 기준

• 서비스 개발이 목적: 호스트 함수·세션·기한·마운트 경계를 먼저 익히고, VM 명령별 구현은 필요한 만큼 읽습니다.
• 언어 구현이 목적: compile_binary_op()에서 Opcode::BinaryAdd, VM의 binary_add()까지 같은 연산을 연결합니다.
• Rust 학습이 목적: 안전한 공개 API가 내부의 까다로운 힙 구현을 어떻게 감싸는지 살펴봅니다. 처음부터 unsafe 코드를 모방하지 않습니다.
• 브라우저 실행이 목적: crates/monty-js/ts/worker/host.ts의 wasiImports(), crates/monty-js/ts/worker/pool.ts의 풀 수명, monty-wasm-runtime의 진입점을 연결합니다.

브라우저 경로의 wasiImports()는 파일 preopen·환경 변수·인수를 빈 값으로 구성하면서 시계와 난수 인터페이스를 연결합니다. “WASM이므로 아무 외부 기능도 없다”라는 문장보다, 어떤 import를 주었는가를 확인하는 습관이 유용합니다. 네이티브 경로와 같은 질문을 다른 실행 환경에 적용하는 셈입니다.

9-2. 매주 스스로 답해 볼 세 질문

1. 지금 읽은 함수가 사용하는 상태의 소유자는 누구이며, 오류가 나면 누가 정리하는가?
2. 신뢰할 수 없는 값이 들어오는 지점과, 크기·형식·권한을 검사하는 지점은 어디인가?
3. 이 동작이 지원된다는 근거는 구현·테스트·문서 중 어디에 있으며, 예외 조건도 같은가?

한 기능을 구현·테스트·한계 문서의 세 방향에서 읽으면, 코드를 외우는 대신 설계의 계약을 이해할 수 있습니다. 최신 커밋의 작은 회귀 테스트도 같은 방식으로 읽을 수 있습니다. 복잡한 기능을 추가하기 전에 바뀌면 안 되는 상태부터 나열하는 습관을 가져가세요.

10핵심 키워드 사전

단어가 익숙해지면 “monty는 Rust로 만든 Python 실행기”라는 소개가 여러 계약으로 나뉘어 보입니다. 문법 계약, 값 전달 계약, 호스트 권한 계약, 저장 호환성 계약, 자원 정책이 각각 따로 존재합니다. 한 계약이 잘 설계됐다고 다른 계약까지 자동으로 충족되는 것은 아닙니다.

11참고 링크

11-1. 공식 저장소와 개념 문서

• pydantic/monty 공식 저장소 — README, 릴리스, 이슈의 시작점.
• v1.3.0 릴리스 — 2026-10-21의 최신 릴리스.
• Monty 공식 문서 — 개념과 언어별 사용법. 사이트 문서는 이후 바뀔 수 있습니다.
• Python 빠른 시작의 소스 — 풀·세션·입력·호스트 함수 API.
• 보안 모델의 소스 — 시계·난수·콜백·덤프의 신뢰 경계.
• 자원 제한 문서 — 실행 시간과 벽시계 시간의 차이.
• 스냅샷 문서 — 중단, 저장, 새 세션 복원.
• Python 부분집합과 한계 — 지원 문법·모듈·CPython과 다른 동작.
• 대안 비교와 측정 조건 — README 성능 수치를 읽을 때 함께 확인할 문서.
• 파일시스템 접근 문서 — 마운트, 작업 디렉터리, I/O 기한의 범위.

11-2. 핵심 구현으로 바로 가기

• Rust workspace와 의존성 · JS 패키지와 빌드 설정 · Python 메타패키지
• 실행 진입점과 컴파일 파이프라인 · 바이트코드 VM
• 중단·재개 상태 · 덤프 형식과 버전
• 워커 풀 · 자식 프로세스 진입점 · 통신 프레임
• 디렉터리 권한 기반 마운트 · 자원 제한의 상수와 기본값
• OSAccess.path_rename() · 자기 경로 변경의 회귀 테스트
• CI 구성 · CPython 비교 실행 도구

11-3. 연결해서 공부할 공식 기술 자료

• Rust 공식 책 — 소유권·대여·enum·오류 처리부터.
• Ruff 공식 문서 · ty 공식 문서 — 파싱 도구 생태계와 타입 검사.
• Tokio 공식 튜토리얼 — 비동기 작업·채널·공유 상태.
• PyO3 공식 가이드 · napi-rs 공식 문서 — 호스트 언어와 Rust 연결.
• Serde 공식 문서 · Protocol Buffers 공식 문서 — 저장과 통신 형식.
• cap-std 4.0 문서 — 디렉터리 핸들로 제한하는 파일 접근.
• WebAssembly 컴포넌트 모델 가이드 — WASI·WIT가 연결되는 구조.
• Pydantic AI — 샌드박스 바깥에서 에이전트와 도구를 연결하는 계층.

현재 상태 (2026-10-23 확인)

스타·포크·생성일·릴리스·push는 해당 날짜의 GitHub 지표입니다. 코드 규모와 설정값은 커밋 93227e8 기준입니다. 저장소 생성일만으로 현재 구현의 개발 기간을 계산하거나, 한 커밋의 코드 규모로 개발 속도를 추정하지 않습니다.

monty에서 가져갈 가장 큰 배움은 코드를 실행하는 기능과 그 코드에 권한을 부여하는 결정을 분리하는 방법입니다. 작은 호스트 함수 하나에서도 이 원칙을 연습할 수 있습니다. 계산은 샌드박스에, 자원과 권한 정책은 호스트의 명시적 계약에 두는 구조를 자신의 프로젝트에 적용해 보세요.