AI 에이전트와 플러그인 시스템이 늘수록 한 가지 질문이 더 중요해집니다.
사용자가 준 코드를 내 애플리케이션 안에서 실행해도 안전한가?
micropython-wasm 0.1a2는 이 질문에 대한 초기 실험입니다. MicroPython을 WebAssembly 샌드박스 안에서 실행하는 알파 패키지이며, Python 애플리케이션 안에서 임의 코드를 더 안전하게 실행하는 것을 목표로 합니다.1
핵심은 '완전한 Python 실행'이 아니라 '통제된 실행'입니다
기존 Python 플러그인 방식의 가장 큰 문제는 권한입니다. 플러그인 코드가 애플리케이션 내부에서 전체 권한으로 실행될 수 있기 때문입니다.1 버그가 있거나 악의적인 코드라면 파일을 읽고, 네트워크에 접근하고, 데이터를 유출할 수 있습니다.
micropython-wasm은 CPython 전체를 그대로 격리 실행하는 방식이 아닙니다. WebAssembly 엔진은 Python 소스가 아니라 WebAssembly 바이너리를 실행합니다.2 따라서 MicroPython 인터프리터를 WASM 환경에 올리고, 그 안에서 제한된 Python 코드를 실행하는 구조로 이해하는 편이 정확합니다.
이 접근은 범용 Python 실행 환경을 대체하기보다, 작은 데이터 변환, 제한된 플러그인 로직, AI 에이전트가 생성한 짧은 코드 실행처럼 권한을 좁게 묶어야 하는 상황에 더 잘 맞습니다.
좋은 샌드박스는 무엇을 막고 무엇을 허용할지 정해야 합니다
샌드박스는 단순히 “격리된다”는 말만으로 충분하지 않습니다. 실제로 유용하려면 다음과 같은 제어가 필요합니다.
메모리 제한
CPU 제한
파일 접근 제어
네트워크 접근 제어1
하지만 모든 것을 막기만 하면 실행 환경은 쓸모가 없어집니다. 그래서 또 하나의 핵심은 호스트 애플리케이션이 선택한 기능만 샌드박스 안의 코드에 노출할 수 있어야 한다는 점입니다.1
즉, 샌드박스 설계의 본질은 “코드를 실행할 것인가 말 것인가”가 아니라 “어떤 권한만 주고 실행할 것인가”에 가깝습니다.
왜 WebAssembly인가
WebAssembly가 이 맥락에서 주목받는 이유는 실행 격리 기술로 오래 검증되어 왔기 때문입니다. 브라우저 환경에서 거의 10년 동안 신뢰할 수 없는 코드를 다루는 데 사용되어 왔고, Python에서는 wasmtime 라이브러리를 통해 WebAssembly를 실행할 수 있습니다.1
wasmtime이 Python용 바이너리 휠을 제공한다는 점도 중요합니다.1 Python 애플리케이션 입장에서는 별도의 복잡한 런타임을 직접 구축하기보다, WASM 실행 엔진을 가져와 샌드박스 실행 기반으로 활용할 수 있기 때문입니다.
0.1a2가 보여주는 방향
micropython-wasm 0.1a2는 안정화된 최종 해법이라기보다 알파 단계의 패키지입니다. 하지만 방향은 분명합니다. Python 애플리케이션 안에서 임의 코드를 실행해야 하는 상황이 늘어날수록, 실행 능력보다 권한 제어가 더 중요해집니다.
이 패키지는 Datasette Agent의 코드 실행 샌드박스 플러그인인 datasette-agent-micropython에도 사용됩니다.1 이는 단순한 데모를 넘어, 에이전트형 도구에서 생성된 코드를 어디까지 믿고 실행할 수 있는지 실험하는 기반으로 볼 수 있습니다.
결국 micropython-wasm 0.1a2가 던지는 메시지는 간단합니다.
앞으로 중요한 것은 코드를 더 많이 실행하는 능력이 아니라, 더 작은 권한으로 안전하게 실행하는 설계입니다.
참고
1Running Python code in a sandbox with MicroPython and WASM
2Running Python Code in a Sandbox with MicroPython and WebAssembly
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.