리눅스 배포판 젠투(Gentoo)의 한 개발자가 순수 파이썬(Python) 패키지를 빌드할 때 러스트(Rust) 기반의 'uv-build'를 백엔드로 사용하지 말아 달라고 공식적으로 요청했습니다. 이 요청은 최근 젠투의 핵심 의존성 중 하나가 uv-build로 전환되면서, 십여 개 패키지에서 특정 아키텍처(예: 32비트, SPARC)에 대한 지원이 중단되는 문제가 발생한 데 따른 것입니다. 젠투는 소스 코드에서 직접 패키지를 빌드하는 방식을 선호하는데, uv-build가 가진 러스트 기반의 특성 때문에 이러한 문제가 불거진 것으로 보입니다.
uv-build는 파이썬 생태계에서 빠른 속도를 강점으로 내세우는 빌드 도구 'uv'의 일부이지만, 러스트로 작성되어 있어 순수 파이썬 백엔드(예: flit-core)에 비해 의존성이 크고 빌드 파일 크기도 훨씬 큽니다. 또한, uv-build는 잦은 릴리스 주기를 가지고 있어, 소스에서 모든 것을 빌드하는 젠투 사용자들에게는 반복적인 컴파일 부담으로 작용합니다. 더 큰 문제는 이식성(portability)입니다. 러스트 컴파일러가 있는 환경에서도 uv-build가 의존하는 다른 러스트 패키지들의 플랫폼 지원 제약이나 32비트 주소 공간 문제로 인해 빌드 또는 실행이 불가능한 경우가 발생할 수 있습니다. 이는 파이썬이 C 컴파일러만 있으면 대부분의 환경에서 높은 이식성을 보장하는 것과 대조적입니다.
이번 요청은 uv 자체나 다른 애스트럴(Astral) 도구에 대한 비판이 아니라, 순수 파이썬 패키지 빌드에 굳이 러스트 기반의 uv-build를 선택할 필요가 없다는 점을 강조합니다. 파이썬 패키징 표준인 PEP 517은 빌드 프런트엔드(예: uv)와 백엔드를 분리하도록 설계되어 있어, uv를 사용하더라도 flit-core나 hatchling과 같은 경량의 순수 파이썬 빌드 백엔드를 선택할 수 있습니다. 개발자는 패키지 빌드에서 얻는 미미한 속도 이점(약 100ms)보다, 러스트 기반 백엔드를 컴파일하고 여러 플랫폼에서 유지 관리하는 비용이 훨씬 크다고 지적하며, 특히 소스 배포본 사용자들에게 이러한 부담이 전가된다고 설명했습니다.
이번 논의는 오픈소스 생태계에서 핵심 의존성이 특정 기업의 이해관계에 좌우되는 것에 대한 우려와 함께, 새로운 기술 도입 시 이식성과 유지보수 비용을 신중하게 고려해야 함을 시사합니다. 특히 젠투와 같이 소스 기반 배포판의 경우, 작은 의존성 변화도 전체 생태계에 큰 파급 효과를 미칠 수 있음을 보여줍니다. 파이썬 코어 개발팀이 파이썬 3.16부터 러스트 사용을 계획하고 있는 상황에서, 이러한 이식성 및 유지보수 문제는 앞으로도 계속 논의될 중요한 과제가 될 것입니다.