CPython에 Rust를 도입하는 방안

AI 요약

David Hewitt가 Python Language Summit에서 CPython에 Rust를 도입하는 계획과 단계별 기준을 소개했습니다. Rust for CPython 팀은 핵심 개발자 Kirill Podoprigora와 Emma Smith가 PEP 초안을 작성하고 있으며, Discord에 약 60명의 개발자가 참여합니다. Android와 Linux 커널처럼 기존 코드베이스에 Rust를 통합한 경험을 보유한 개발자와 Rust 프로젝트 관계자도 함께하고 있습니다.

Rust 도입을 검토하는 이유

CPython에서 ‘type-crash’로 분류된 이슈가 꾸준히 늘고 있습니다. 새 파서와 JIT, free-threading 같은 규모가 큰 기술 변경이 크래시 보고 증가의 한 원인일 수 있으며, Rust 도입은 이 문제에 대응하는 방법 가운데 하나로 제시됐습니다. Android에서 Rust를 도입한 뒤 같은 규모의 패치에서 수정 횟수가 줄었다는 경험도 소개했습니다. Python 패키지 생태계에서는 PyO3와 Maturin을 통해 이미 Rust와 Python이 함께 쓰이고 있습니다.

다만 Rust를 사용한다고 버그나 보안 문제가 사라지지는 않습니다. Rust가 흔한 오류 유형을 줄여도 코드의 정확성 문제는 남습니다. 팀은 이식 과정에서 property-based testing과 퍼징(fuzzing), 신중한 엔지니어링 관행을 적용하겠다고 밝혔습니다.

단계별 일정과 첫 대상 zlib

팀은 Python 3.16에서 첫 Rust 코드를 선택 기능으로 제공하고 C 구현을 대체하지 않는 방안을 제안했습니다. 해당 버전은 2027년 10월 출시 예정이며, Rust 지원을 CPython 빌드의 필수 조건으로 삼는 시점은 가장 빨라도 Python 3.18이 되는 2029년입니다.

계획에 따르면 2026년 여름에는 빌드 시스템과 CI, Rust API 개념 검증을 진행하고, 2026년 말에는 성공 기준을 정하는 PEP를 마련합니다. Python 3.16에서는 zlib의 선택형 Rust 백엔드와 비공개 Rust API를 제공하는 방안을 검토합니다. Python 3.17에서는 플랫폼별 문제를 해결하고 io, json, xml, memoryview, parser 등으로 Rust 적용 범위를 넓힙니다. 더 먼 일정에는 Rust 빌드를 필수화하고 공개 Rust API를 제공하는 내용도 포함됐습니다.

첫 모듈로 zlib를 고른 이유는 적용 범위를 작게 유지하면서도 의미 있는 개선을 시험하려는 목적입니다. 구현에는 Firefox, uv, Cargo에서 사용하고 테스트한 zlib-rs를 활용할 계획입니다. 팀은 zlib-rs가 여러 플랫폼에서 zlib와 zlib-ng보다 빠르다고 설명했습니다. 외부 Cargo 패키지를 사용하는 과정도 함께 시험합니다. zlib는 Python 패키징에서 널리 쓰이므로 제안이 받아들여지면 Python 3.16에서 pip 설치가 빨라질 것으로 팀은 내다봤습니다.

Rust API와 성공 기준

제시된 Rust API 예시는 #[pyfunction] 속성으로 함수를 표시하고 Python의 함수 인자 문법을 지정합니다. Python 인터프리터 상태는 Python<'_> 인자로 전달하고 객체는 Py<...> 형태로 다룹니다. 오류 처리는 Rust의 Result 계열을 사용합니다. 예시에서는 버퍼를 함수 범위 안에서 확보하며, 범위를 벗어날 때 정리합니다. C에서 필요한 수동 정리 작업을 줄이는 방식입니다.

Rust 적용 범위를 다음 단계로 넓히려면 활동 중인 핵심 개발자 다수가 Rust API 사용에 열린 태도를 보여야 합니다. 성능 벤치마크에서 의미 있는 저하가 없어야 하며, 모든 등급의 지원 플랫폼을 Rust가 지원해야 합니다. 배포판 관리자가 CPython에 Rust 지원을 추가하는 과정도 감당할 만해야 합니다. 팀은 Rust에 익숙한지를 묻기보다 Rust API 사용에 열린지를 살피겠다며 핵심 개발자 대상 설문을 계획했습니다.

API 설계와 의존성 우려

Thomas Wouters는 C API 사용자에게 익숙하게 맞추려고 Rust API를 타협하지 말고, Rust다운 설계를 처음부터 검토하자고 제안했습니다. Hewitt는 범위 종료 때 자원을 정리하는 방식처럼 Rust의 장점을 살리되, 관용적인 Rust 설계가 모두 CPython에 적합한 것은 아니라고 답했습니다. 핵심 개발자가 C와 Rust API를 함께 살필 상황도 고려해야 한다고 덧붙였습니다.

Larry Hastings는 Rust로 다시 작성하는 대신 성공 사례를 포크로 보여주는 방안을 물었습니다. 팀은 이미 RustPython 기여자와 대화했으며, RustPython의 성능은 CPython보다 낮지만 API 설계 참고 자료로 활용할 수 있다고 답했습니다. Hastings는 CPython 작업을 위해 Rust를 배우는 데 큰 흥미가 없다고도 말했습니다. Hewitt는 Rust를 쓰기 위해 CPython을 Rust로 바꾸려는 게 아니며, 상당 기간 두 언어를 함께 쓰게 될 것이라고 설명했습니다. 다만 Rust가 영원히 선택 사항으로 남는다고 말하는 것도 정확하지 않다고 밝혔습니다.

Pablo Galindo Salgado는 Cargo 의존성 관리가 큰 장애물이 될 수 있다고 지적했습니다. CPython은 의존성을 직접 포함해 관리하며, 의존성에서 취약점이 발견되면 릴리스 관리자가 새 버전을 배포해야 해 부담이 커진다는 우려입니다. Hewitt는 외부 의존성을 최소화하고, zlib-rs 하나만 사용하며 Rust 소스를 별도로 보관하는 방안을 제시했습니다. 이 방식을 쓰면 CPython 빌드에 Cargo가 필요하지 않으며, 개념 검증에서도 Cargo의 의존성 보관 체계를 사용하고 있다고 설명했습니다. Łukasz Langa는 의존성 코드를 CPython 저장소와 분리하는 편이 낫다고 동의했습니다.

Lobsters 반응

• @blin — 제가 아는 한, 2025년 11월에 게시된 https://discuss.python.org/t/pre-pep-rust-for-cpython/104906 이후 Rust for CPython에 관한 첫 공개 소식입니다. 그래서 행사 이름을 제목에 넣는 것이 적절해 보였습니다.

원문: Python Blog / 번역·요약: Trawling