pip install torch 한 줄로 끝낸다 — Python 패키징의 오랜 숙제, 드디어 풀리나

NVIDIA·Astral·Quansight 연합이 내놓은 Wheel Next: CPU·GPU를 가리지 않는 차세대 패키징 표준

출처: Talk Python To Me, Episode #544 |

배경: 2009년에 멈춰버린 바퀴

pip install numpy를 실행하면 어떤 바이너리가 설치될까? 당신의 CPU가 최신 AMD Zen 4든, Apple M4든 상관없다. 설치되는 휠(wheel)은 2009년 수준의 x86-64 명령어만 사용하도록 빌드된 것이다.

SSE4, AVX2 같은 최신 SIMD 명령어를 쓰고 싶어도 인스톨러가 해당 기능의 지원 여부를 알 방법이 없다. 결과는 PyTorch 같은 패키지의 경우 900MB에 육박하는 거대한 바이너리 파일, 그리고 "퍼즐 책"처럼 복잡한 설치 가이드 페이지로 이어진다.

NVIDIA, Astral, Quansight 연합은 이 문제를 해결하기 위해 Wheel Next 이니셔티브를 추진 중이다. 패키지가 필요한 하드웨어를 선언하고, uv 같은 인스톨러가 자동으로 올바른 빌드를 선택할 수 있게 하는 일련의 PEP들이 그 핵심이다.

게스트 소개

이번 에피소드에는 세 명의 핵심 인물이 참여했다.

Jonathan Dekhtiar (NVIDIA) — CUDA 기술에 매료되어 PhD까지 마치고 NVIDIA에 입사한 엔지니어. 지난 2년여간 CUDA와 Python의 접점을 개선하는 일을 해왔으며, Wheel Next 이니셔티브의 핵심 추진자다.

Ralf Gommers (Quansight) — 물리학 박사 출신으로 2004년부터 Python을 써온 개발자. NumPy와 SciPy의 릴리즈 매니저이며, 현재는 공익 법인 Quansight의 공동 CEO다. 네이티브 Python 패키징 문제를 체계적으로 정리한 PyPackaging Native 가이드의 저자이기도 하다.

Charlie Marsh (Astral) — uv, ruff, ty를 만든 Astral의 창업자 겸 CEO. 2022년 10월 창업 이후 Python 생태계의 속도와 사용자 경험 개선에 집중해왔다.

핵심 문제: "최소 공통분모의 함정"

x86-64용 휠을 빌드하면, 2009년 이전 CPU 기능만 사용할 수 있다. SSE4, AVX2 등 그 이후에 등장한 명령어는 인스톨러가 해당 기능의 탑재 여부를 알 수 없기 때문에 아예 사용하지 못한다.

2009년 기준 하드웨어 기능과 2019~2023년 기준 기능의 성능 차이는 경우에 따라 10~20배에 달한다.

ARM의 상황도 마찬가지다. 현재 ARM용 기본 빌드 타깃은 사실상 라즈베리 파이 수준이다. M4 Max 칩이 들어간 MacBook Pro에서도 라즈베리 파이용으로 빌드된 바이너리가 실행되는 셈이다.

JetBrains의 Python 개발자 설문조사 기준으로 Python 개발자의 약 40~50% 가 데이터 사이언스나 과학 계산 분야에 종사하고 있다. 이 거대한 커뮤니티가 체계적으로 엄청난 성능을 낭비하고 있는 것이다.

NumPy는 어떻게 버텨왔나

NumPy는 이 문제를 자체적으로 해결했다. 같은 소스 코드를 Haswell, Skylake 등 여러 CPU 아키텍처를 타깃으로 여러 번 컴파일한 뒤, 하나의 Python 확장 모듈로 합치는 방식이다. 런타임에서 CPU를 감지해 최적의 코드 경로로 디스패치한다.

Intel은 수년간 엔지니어를 파견해 x86 코드 경로를 최적화했고, ARM도 전담 NumPy 메인테이너를 두고 있다. 덕분에 성능은 뛰어나지만, 이 방식은 소수의 대형 프로젝트만 감당할 수 있는 규모다.

SciPy, scikit-learn, Pandas, Pillow는 코드 자체에는 SIMD 최적화가 구현되어 있지만, 이를 휠에 담아 배포할 방법이 없어 실제로는 배포하지 못하고 있다.

PyTorch의 경우: 900MB짜리 "퍼즐 책"

PyPI에 올라와 있는 PyTorch 휠은 약 900MB에 달한다. 5~6개의 GPU 아키텍처를 위한 CUDA 라이브러리가 하나의 바이너리에 묶여 있기 때문이다. PyTorch 팀은 1GB를 넘지 않기 위해 엄청난 노력을 기울이고 있다.

특정 CUDA 버전이 필요한 사용자는 별도의 인덱스 URL을 직접 설정해야 하며, vLLM 같은 패키지의 설치 페이지는 "퍼즐 책"처럼 복잡하다.

Wheel Next가 완성되면 어떻게 될까?

이 한 줄이면 된다. 인스톨러가 자동으로 GPU를 감지하고, 맞는 CUDA 버전을 파악해 해당 하드웨어에 최적화된 약 200~250MB짜리 슬림 휠을 다운로드한다. Astral은 이미 uv의 변형 지원(variant-enabled) 브랜치에서 작동하는 프로토타입을 구축해놓은 상태다.

Wheel Next의 설계 철학: 고정 목록이 아닌 확장 가능한 시스템

현재 방식은 플랫폼 태그를 파일명에 하드코딩한다. 새로운 요구사항이 생길 때마다 태그를 추가해야 하는데, 이를 반복하면 결국 끝없는 유지보수 부담이 된다.

Wheel Next는 다르다. 패키지가 임의의 변형(variant) 메타데이터를 선언할 수 있고, 플러그인 인터페이스를 통해 인스톨러가 동적으로 플랫폼 속성을 감지해 최적의 휠을 선택한다. CUDA 버전 하나하나에 태그를 붙이는 대신, 범용적이고 확장 가능한 시스템을 만든 것이다.

설계에는 슈퍼컴퓨터용 패키지 매니저 Spack의 archspec, Conda-forge, Nix에서 영감을 받았다.

PEP 현황

이번 이니셔티브와 관련된 주요 PEP들:

PEP 817은 역대 가장 긴 PEP라는 기록을 세웠다. PEP 에디터들의 검토만 한 달 이상 걸릴 정도였다. 이후 관리 가능한 단위로 쪼개, 인스톨러·빌드 백엔드·인덱스 서버 각각에 대한 논의가 별도로 진행되고 있다.

Python Build Standalone: 조용한 레버

Charlie Marsh가 언급한 흥미로운 사실 하나. Astral은 Python Build Standalone 프로젝트를 유지 관리하고 있다. uv로 Python을 설치할 때 실제로 다운로드되는 것이 바로 이 프로젝트의 빌드다.

Astral의 목표는 CPython 소스 코드를 변경하지 않고 빌드 최적화만으로 가장 빠른 Python 배포판을 출시하는 것이다. Charlie는 현재 가장 빠른 Python을 갖고 있다고 생각하지만, 엄격한 벤치마크 방법론을 아직 공개하지 않았다며 공식적으로 주장하지는 않겠다고 했다.

수많은 개발자가 이미 uv로 Python을 부트스트랩하고 있다는 점에서, Astral의 빌드 선택은 Python 성능에 엄청난 영향을 미칠 수 있는 레버가 된다.

전례 없는 산업 간 협업

2025년 3월, 약 20개 기업의 대표들이 한자리에 모이는 오프라인 서밋이 열렸다. Meta의 PyTorch 팀, Google의 JAX 팀이 각자의 고민을 발표했다.

현재 Wheel Next 이니셔티브에 기여하는 기업 및 오픈소스 프로젝트는 다음과 같다:

기업: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks 등 14개 이상

오픈소스 프로젝트: NumPy, SciPy, PyTorch, scikit-learn, JAX 등

프로토타이핑 과정에서 pip, warehouse(PyPI), setuptools, scikit-build-core, packaging 라이브러리 등 Python 패키징 생태계의 거의 모든 구성 요소를 포크해서 작업했다. 물론 최종 목표는 그것들을 다시 합치는 것이다.

앞으로의 일정

Ralf의 예상으로는 2026년 내내 PEP 검토와 프로토타입 업데이트가 진행되고, 이후 PyPI, Twine, 메타데이터 소비 도구들이 업데이트될 예정이다. 생태계 전반이 준비되는 것은 2026년 이후로 보인다.

하지만 Jonathan은 낙관적이다. 표준이 사용 가능해지는 순간, ML·과학 계산 생태계의 채택 속도는 빠를 것으로 예상된다. 핵심 패키지들이 이미 Wheel Next 워킹 그룹에 참여해 있기 때문이다.

핵심 용어 정리

마치며

"이상적으로는 일반 사용자가 이 모든 것을 신경 쓰지 않아도 됩니다. 그냥 uv나 pip를 통해 자동으로 얻을 수 있게 되는 거죠." — Charlie Marsh

Python 패키징 시스템은 더 단순했던 시대에 설계됐다. 그러나 데이터 사이언스·AI 워크로드가 폭발적으로 증가한 지금, 그 설계는 성능·대역폭·사용자 경험 모두에서 병목이 되고 있다.

Wheel Next는 경쟁사들(NVIDIA, AMD, Intel, Google, Meta)이 같은 테이블에 앉아 PEP를 함께 쓰고 공유 인프라에 투자하는 드문 사례다. uv의 프로토타입은 기술적 타당성을 이미 증명했다. 생태계 전반이 따라오는 데는 시간이 걸리겠지만, 그 미래는 충분히 기다릴 만하다.

관련 링크

• wheelnext.dev — Wheel Next 프로젝트 공식 사이트
• PEP 817 — Wheel Variants Beyond Platform Tags
• PEP 825 — Wheel Variants Package Format
• pypackaging-native.github.io — 네이티브 Python 패키징 문제 가이드
• astral.sh/pyx — Astral의 패키지 레지스트리 pyx

이 기사는 Talk Python To Me Episode #544의 내용을 번역·편집한 것입니다.