에이전트에 Python 실행기를 넣기 전: MicroPython·WASM의 권한과 자원 경계

에이전트가 만든 짧은 Python 코드로 금액을 합산하거나 문자열을 정리하고 싶다면, 먼저 결정할 것은 실행 권한이다. 기존 애플리케이션 안에서 그대로 실행할지, 지정한 입력만 읽는 별도 실행기에 넘길지에 따라 파일과 외부 시스템에 닿는 범위가 달라진다. 계산 결과 하나가 필요하다고 해서 애플리케이션의 모든 권한까지 함께 줄 필요는 없다.

이 글의 결론은 다음과 같다. 작은 순수 계산은 일회성 실행부터 검토하고, 외부 시스템을 바꾸는 작업은 실행기 밖의 승인된 호스트 계층에 남겨둔다. 그 과정에서 필요한 Python 기능이 MicroPython에 없거나, 적대적 코드를 여러 사용자가 함께 실행한다면 호환성과 운영체제 수준의 격리를 별도로 검토한다. WASM이라는 이름만으로 이 두 문제가 해결되지는 않는다.

아래 판단표와 권한·자원·상태 도식은 원문을 바탕으로 작성한 편집 분석이다. 이 글은 고정된 원문과 README를 읽어 만든 설계 분석이며, 패키지 실행·탈출 실험·독립 보안 감사를 수행한 결과가 아니다.

먼저 고를 것: 계산기인가, 애플리케이션 대리인인가

Simon Willison은 2026년 6월 6일 글에서 기존 Python 플러그인이 애플리케이션의 전체 권한으로 실행되는 문제를 설명했다. 승인하지 않은 파일 읽기와 네트워크 연결을 제한하면서, 필요한 호스트 함수만 선택해서 제공하고 싶었다는 것이다. 이를 위해 MicroPython을 WASI WebAssembly 모듈로 묶고 Python에서 Wasmtime으로 실행하는 실험적 패키지를 만들었다.

예를 들어 호스트가 승인된 입력을 준비하고 실행기에 변환 코드만 보내는 구조를 생각해 보자. 실행기는 변환 결과를 반환하고, 실제 데이터베이스 반영은 호스트가 검증한 뒤 수행한다. 이 예시는 이 글의 설계 제안이지 패키지의 자동 승인 기능이 아니다. 핵심은 계산과 외부 변경을 나누는 것이다. 결과 검증 없이 반환값을 곧바로 중요한 시스템에 적용하면, 실행 권한을 줄였더라도 잘못된 결과의 피해는 남는다.

독자의 요구	먼저 검토할 선택	별도로 확인할 경계
작은 산술·문자열 변환, 호출 사이 상태 불필요	run() 일회성 실행	필요한 문법·모듈과 출력 처리
호출 사이 변수·함수를 실제로 유지	MicroPythonSession	세션 수명, 사용자별 분리, trap 이후 폐기
성공한 코드를 재실행해 상태 재구성	MicroPythonReplaySession	과거 코드와 콜백의 반복 실행
특정 입력 파일만 읽기	전용 입력 디렉터리와 readonly_dir	읽기 허용 데이터의 최소화
임의 PyPI 패키지나 CPython 동작이 필수	다른 실행 환경도 비교	호환성 확인과 별도 격리 설계
고위험 다중 사용자 코드 실행	별도 프로세스와 OS 제한을 함께 검토	실행기 단독으로 보안 경계를 완성했다고 보지 않기

상태 요구에 맞춰 실행 API를 고르는 편집 판단표다. CPython 호환성과 replay의 부수효과는 별도로 검토한다. 출처: raw.githubusercontent.com/simonw/micropython-wasm/5e79a4f2443a257d2ae38da957d1f99f54650efd/README.md.

이 표는 우열 순위가 아니다. 상태가 필요 없는 요청에 상주 세션을 넣으면 관리할 상태가 늘고, 상태가 필요한 요청을 일회성 실행으로 처리하면 이전 변수를 기대한 코드가 성립하지 않는다. 기능을 많이 켜는 것이 아니라 실제 요구에 맞는 가장 좁은 실행 방식을 고르는 데 사용하자.

파일과 네트워크: 기본 제한보다 중요한 추가 권한

고정 README의 Filesystem Access에 따르면 게스트에는 기본으로 열린 호스트 디렉터리가 없다. readonly_dir를 지정하면 해당 디렉터리를 게스트의 /input으로 읽기 전용 노출한다. 이는 어떤 파일도 읽어도 된다는 뜻이 아니다. 읽기 전용은 쓰기를 막는 권한이고, 민감한 내용을 읽지 못하게 하는 데이터 선별과는 다르다.

따라서 홈 디렉터리나 프로젝트 전체를 넘기지 말고, 그 요청에 필요한 자료만 담은 전용 입력 디렉터리를 준비하는 설계를 검토할 수 있다. README도 프로젝트 루트, 홈, 루트 파일시스템, 공유 임시 디렉터리를 열지 말라고 경고한다. 입력 파일의 비밀정보 검토는 호스트의 책임으로 남는다.

Network Access에는 네트워크 import나 호스트 소켓 함수를 노출하지 않으며 해당 WASI 빌드의 socket·SSL 지원도 꺼져 있다고 적혀 있다. 하지만 호스트 함수를 추가하면 이야기가 달라진다. 게스트가 네트워크를 직접 쓰지 못하더라도, 네트워크에 연결하는 호스트 콜백을 호출하도록 허용하면 그 경로로 외부에 영향을 줄 수 있다.

기본 게스트에는 호스트 폴더와 네트워크가 노출되지 않는다. 입력 디렉터리와 콜백을 추가하면 그 권한·데이터 범위를 다시 확인해야 한다. 출처: raw.githubusercontent.com/simonw/micropython-wasm/5e79a4f2443a257d2ae38da957d1f99f54650efd/README.md.

호스트 함수는 권한의 통로로 검토해야 한다. 이름이 평범한 함수라도 내부에서 파일을 읽거나 메시지를 보내면 그 동작이 실행 경계 밖에서 일어난다. README의 제안처럼 네트워크 기능이 필요하다면 허용 목록, 시간 제한, 리다이렉트 제한, 응답 크기 제한을 가진 좁은 API를 검토한다. 모든 파일 경로나 임의 URL을 받는 만능 함수는 그 취지와 맞지 않는다. 인자와 반환값이 JSON으로 오간다는 사실은 전달 형식의 제약이지, 함수의 권한을 검증해 주는 장치가 아니다.

자원 제한: 메모리 하나로 전체 비용을 설명하지 말자

고정 README의 API 예시는 서로 다른 네 가지 값을 지정한다. 아래 코드는 문서에 실린 설정 예시이며, 이 글에서 실행하거나 권장 예산을 측정한 결과가 아니다.

from micropython_wasm import run

result = run(
    "print(sum(range(10)))",
    memory_bytes=16 * 1024 * 1024,
    fuel=20_000_000,
    wall_timeout_seconds=1.0,
    host_result_bytes=256 * 1024,
)

memory_bytes는 게스트의 WebAssembly 선형 메모리 제한이다. 호스트 Python 프로세스, Wasmtime 런타임, 컴파일된 코드, 호스트 콜백의 메모리까지 합친 전체 사용량 제한으로 읽으면 안 된다. 문서가 고위험 다중 사용자 작업에 별도 프로세스와 운영체제 메모리·CPU·시간 제한을 함께 고려하라고 하는 이유다.

fuel은 Wasmtime의 실행 진행 예산이며 초 단위 시간이 아니다. 20_000_000이라는 숫자를 실행 시간이나 처리 건수로 환산할 근거는 이 자료에 없다. 저자도 6월 글에서 이 값의 적절성에 확신이 없다고 했다. wall_timeout_seconds는 별도의 경과 시간 제어이고, host_result_bytes는 직렬화된 호스트 콜백 응답 크기 제한이다. 마지막 값 역시 일반 출력이나 전체 프로세스 사용량 제한으로 바꾸어 설명하면 안 된다.

설정값의 보호 범위를 나눈 문서 기반 비교다. 예시 값은 권장값이나 측정값이 아니며 전체 호스트 메모리와 일반 출력 제한을 대신하지 않는다. 출처: raw.githubusercontent.com/simonw/micropython-wasm/5e79a4f2443a257d2ae38da957d1f99f54650efd/README.md.

실무 검토에서는 무엇을 제한하는 값인지부터 구분하자. 무한 반복에 대한 대응, 큰 입력으로 생기는 메모리 부담, 오래 걸리는 요청, 큰 콜백 반환값은 같은 문제가 아니다. 호스트에서 출력 수집 크기도 따로 다루어야 한다는 Security Notes의 주의까지 포함해야 전체 처리 경로를 볼 수 있다. 이 글은 제한값 설정 뒤의 실제 정지 시간, 최대 처리량, 비용 절감률을 측정하지 않았다.

상태 유지: 같은 변수처럼 보여도 실행 방식은 다르다

run()은 호출마다 새 엔진·스토어·WASI 설정·모듈 인스턴스·MicroPython 프로세스를 만든다고 README에 설명되어 있다. 이전 호출의 전역 변수와 import가 남지 않는 일회성 모델이다. 서로 독립적인 변환 요청에는 이 특성이 판단의 출발점이 된다. 다만 같은 호스트 콜백을 공유한다면 그 외부 상태까지 자동 초기화된다고 추론해서는 안 된다.

MicroPythonSession은 백그라운드 스레드에서 실제 상주 VM을 유지한다. 같은 VM의 변수, 함수, import와 객체를 다음 호출에서 사용할 수 있다. 문서는 각 요청에 fuel을 다시 제공하고, fuel 고갈 등으로 게스트가 trap되면 세션을 버려야 한다고 설명한다. 사용자가 바뀌는 요청에 같은 세션을 재사용할지, 실패한 세션을 어떻게 폐기할지는 애플리케이션 설계에서 명시해야 한다.

반면 MicroPythonReplaySession은 VM을 상주시켜 보존하는 방식이 아니다. 새 실행 인스턴스에서 이전의 성공한 코드 조각을 다시 실행한 뒤 새 코드를 실행한다. 사용자는 변수가 이어지는 것처럼 볼 수 있지만, 과거 코드가 호스트의 기록 함수를 호출했다면 그 기록도 다시 발생할 수 있다. README는 record('once')가 다음 요청에서 반복 호출되는 예시를 제공한다. 이것을 데이터베이스 변경이나 외부 알림과 연결할 경우의 중복 위험은 이 글의 설계상 해석이다.

README의 기록 콜백 예시를 도식화했다. replay의 상태 재구성은 외부 변경을 되돌리는 기능이 아니며 여기서 직접 실행한 결과도 아니다. 출처: raw.githubusercontent.com/simonw/micropython-wasm/5e79a4f2443a257d2ae38da957d1f99f54650efd/README.md.

재시도를 설계할 때는 반환값만 보지 말고 외부 변경이 어디에서 일어났는지 기록하자. replay로 이전 상태를 복구했다고 해서 외부 시스템도 이전으로 되돌아온 것은 아니다. 순수 계산과 부수효과가 있는 콜백을 나누고, 부수효과가 꼭 필요하면 반복 호출에 대한 검증을 별도로 두는 이유가 여기에 있다.

적용을 미룰 조건도 먼저 적어두자

MicroPython은 CPython이 아니다. 고정 README는 문법, 표준 라이브러리, 객체 동작과 플랫폼 세부사항의 차이를 명시한다. 해당 번들 아티팩트에는 hashlib.sha256과 zlib이 없다는 관찰도 기록되어 있다. 그러므로 Python 코드라는 이유만으로 기존 스크립트나 임의 PyPI 의존성이 그대로 작동한다고 약속하면 안 된다. 필요한 모듈과 언어 기능을 먼저 목록으로 만들고, 호환성이 필수이면 다른 실행 환경도 비교하는 편이 적절하다.

보안 상태도 분리해서 읽어야 한다. 저자의 6월 글은 알파 구현이며 상당한 위험을 감수할 독자 외에는 추천할 준비가 되지 않았다고 설명했다. 모델을 동원한 탈출 시도가 성공하지 않았다는 보고는 독립 감사나 탈출 불가능의 증명이 아니다. 고정 README 역시 이 패키지만으로 고위험 프로덕션의 완전한 보안 경계가 되지 않는다고 적는다. 빌드의 실험적 상태와 적대적·장시간 코드에 대한 스트레스 테스트 필요성도 남아 있다.

따라서 도입 검토의 결과는 ‘안전하다’ 한 문장보다 구체적이어야 한다. 어떤 입력만 제공하는지, 어떤 호스트 함수를 열어두는지, 어떤 자원 제한이 어느 범위에 적용되는지, 호출 사이 어떤 상태가 남는지, 실패 후 무엇을 폐기하는지를 적는다. 필요한 호환성과 별도 프로세스 제한을 충족하지 못했다면 도입을 미루는 결정도 정상적인 결과다. 작은 실행기를 고르는 일은 권한과 상태를 작게 만드는 설계 작업이지, 위험을 이름 하나로 없애는 작업이 아니다.

출처와 검토 범위

• Simon Willison: Running Python code in a sandbox with MicroPython and WASM — 2026년 6월 6일 작성자의 구현 배경과 위험 고지. 이 글은 당시 크기나 탈출 시도 보고를 현재 성능·안전성 증거로 사용하지 않았다.
• micropython-wasm 고정 커밋 README — 커밋 5e79a4f2443a257d2ae38da957d1f99f54650efd의 API, 파일·네트워크, 자원 제한, 세션, 호환성, Security Notes와 구현 주의사항. 이후 릴리스의 동작을 보장하는 설명이 아니다.

검토는 동결된 원문 증거에 한정했다. 외부 서비스 이용료나 패키지 처리 속도에 관한 측정값은 없으며, 그림은 문서 기반의 자체 제작 도식으로 실제 제품 화면이 아니다. 관련 내부 글은 동결 목록에 제목과 ID만 있고 본문 적합성·실제 URL을 이번 단계에서 확인하지 않았으므로 억지로 연결하지 않았다.