pip install torch 한 줄로 끝내는 시대를 향해: Python 패키징의 한계를 바꾸는 Wheel Next

이 글은 Python 패키징 생태계가 오랫동안 안고 있던 성능과 배포 문제, 그리고 이를 해결하기 위해 등장한 Wheel Next 이니셔티브를 정리합니다. 왜 pip install numpy나 pip install torch 한 줄이 실제로는 수많은 타협의 결과였는지, 그 구조적인 한계는 무엇이었는지, 그리고 NVIDIA·Astral·Quansight를 중심으로 한 연합이 어떤 방식으로 이 문제를 풀고자 하는지 살펴봅니다. 특히 CPU·GPU 하드웨어 성능을 제대로 활용하지 못했던 기존 휠(wheel) 구조와, 이를 바꿀 차세대 패키징 표준의 방향성을 중심으로 설명합니다.

반응형

---

Python 휠의 출발점과 멈춰버린 시간

Python의 바이너리 패키징 표준인 휠(.whl)은 2009년을 기준으로 설계되었습니다. 이 때문에 오늘날 pip install numpy를 실행해도, 설치되는 바이너리는 최신 CPU나 GPU의 성능을 전제로 만들어진 것이 아닙니다.
x86-64 환경에서는 여전히 2009년 수준의 최소 명령어 집합만 사용하도록 빌드된 휠이 설치됩니다. SSE4, AVX2 같은 최신 SIMD 명령어를 사용할 수 있음에도, 인스톨러는 해당 CPU가 이를 지원하는지 알 방법이 없기 때문입니다.

그 결과는 명확합니다.

• 최신 CPU와 오래된 CPU가 같은 바이너리를 사용
• 하드웨어 성능 차이가 최대 10~20배까지 벌어짐
• 패키지 개발자는 성능과 호환성 사이에서 극단적인 선택을 강요받음

ARM 환경도 다르지 않습니다. 최신 Apple Silicon이 탑재된 MacBook Pro에서도, 사실상 라즈베리 파이 수준을 기준으로 빌드된 바이너리가 실행되고 있습니다.

---

최소 공통분모의 함정과 그 영향

현재 Python 패키징은 “모두에서 동작해야 한다”는 원칙 아래 최소 공통분모만을 타깃으로 합니다. 이 구조는 단순하지만, 대가가 큽니다.

JetBrains의 Python 개발자 설문조사에 따르면, Python 개발자의 약 40~50%는 데이터 사이언스나 과학 계산 분야에 종사하고 있습니다. 즉, 성능이 중요한 사용자층이 Python 생태계의 절반에 가깝습니다. 그럼에도 불구하고, 이들은 하드웨어 잠재력을 체계적으로 낭비하고 있는 셈입니다.

---

NumPy가 선택한 우회로, 그러나 모두의 해법은 아니다

NumPy는 이 문제를 자체적으로 해결해 왔습니다.
같은 소스 코드를 여러 CPU 아키텍처(Haswell, Skylake 등)를 기준으로 여러 번 컴파일한 뒤, 하나의 확장 모듈로 묶습니다. 실행 시점에 CPU를 감지해 최적의 코드 경로로 분기하는 방식입니다.

이 접근은 성능 면에서는 매우 뛰어납니다. 하지만 현실적인 제약도 분명합니다.

• 수년간의 엔지니어링 투자 필요
• Intel, ARM 등 하드웨어 벤더의 직접적인 지원
• 소수의 대형 프로젝트만 감당 가능한 복잡도

SciPy, scikit-learn, Pandas, Pillow 역시 SIMD 최적화 코드를 보유하고 있지만, 이를 휠로 배포할 수 있는 표준적인 방법이 없어 실제 사용자에게 전달되지 못하고 있습니다.

---

PyTorch의 900MB 휠이 말해주는 현실

PyTorch는 또 다른 방식으로 이 문제를 우회했습니다.
여러 GPU 아키텍처와 CUDA 버전을 하나의 바이너리에 묶는 Fat Binary 전략입니다. 그 결과 PyPI에 올라온 PyTorch 휠의 크기는 약 900MB에 달합니다.

사용자는 특정 CUDA 버전을 쓰기 위해 별도의 인덱스 URL을 설정해야 하고, 설치 가이드는 퍼즐 책처럼 복잡해졌습니다. 성능과 사용성, 어느 쪽도 만족스럽지 않은 상황입니다.

---

Wheel Next란 무엇인가

이 문제를 근본적으로 해결하기 위해 등장한 것이 Wheel Next 이니셔티브입니다.
핵심 아이디어는 단순합니다.

• 패키지가 필요한 하드웨어 속성을 선언한다
• 인스톨러가 실제 시스템 환경(CPU, GPU, 드라이버 등) 을 감지한다
• 가장 적합한 빌드(variant)를 자동으로 선택해 설치한다

이를 가능하게 하는 것이 PEP 817과 PEP 825에서 제안된 Wheel Variants 개념입니다.

---

pip install torch, 정말 한 줄이면 되는 미래

Wheel Next가 완성되면 사용자 경험은 이렇게 바뀝니다.

uv pip install torch

이 한 줄이면,

• 인스톨러가 GPU 유무와 CUDA 버전을 자동 감지
• 해당 환경에 최적화된 약 200~250MB 크기의 슬림 휠 다운로드
• 별도의 인덱스 URL 설정이나 복잡한 가이드 불필요

Astral은 이미 uv의 변형 지원 브랜치에서 이 개념이 동작하는 프로토타입을 구현한 상태입니다.

---

고정 태그가 아닌, 확장 가능한 설계

기존 휠은 플랫폼 태그를 파일명에 하드코딩합니다. 새로운 요구사항이 생길 때마다 태그를 추가해야 하고, 이는 끝없는 유지보수 부담으로 이어집니다.

Wheel Next는 이 접근을 버립니다.

• 패키지가 임의의 변형 메타데이터를 선언
• 인스톨러는 플러그인 인터페이스를 통해 동적으로 플랫폼 속성 감지
• CUDA 버전, CPU 기능 등을 고정 목록이 아닌 확장 가능한 방식으로 처리

이 설계는 Spack, Conda-forge, Nix 등에서 영감을 받았습니다.

---

표준화 진행 상황과 생태계 협업

현재 관련 PEP들은 모두 Draft 단계에 있습니다. 특히 PEP 817은 역대 가장 긴 PEP로 기록될 정도로 논의가 깊었습니다. 이후 인스톨러, 빌드 백엔드, 인덱스 서버 단위로 쪼개어 검토가 진행 중입니다.

이 과정에는 NVIDIA, Astral, Quansight를 비롯해 Meta, Google, AMD, Intel 등 14개 이상의 기업과 NumPy, SciPy, PyTorch 같은 핵심 오픈소스 프로젝트가 참여하고 있습니다. 경쟁 관계에 있는 기업들이 하나의 패키징 표준을 위해 협업하는, 매우 이례적인 장면입니다.

---

Python Build Standalone이라는 또 하나의 레버

Astral이 유지 관리하는 Python Build Standalone 프로젝트도 주목할 만합니다. uv로 Python을 설치할 때 실제로 내려받는 빌드가 바로 이 프로젝트의 결과물입니다.

목표는 단순합니다.
CPython 소스 코드를 바꾸지 않고, 빌드 최적화만으로 가장 빠른 Python 배포판을 만드는 것.
이미 많은 개발자가 uv를 통해 Python을 설치하고 있다는 점에서, 이 선택은 Python 성능 전반에 큰 영향을 미칠 수 있습니다.

---

앞으로의 일정과 현실적인 전망

2026년 내내 PEP 검토와 프로토타입 개선이 이어질 것으로 예상됩니다. PyPI, Twine, 메타데이터 소비 도구까지 포함한 생태계 전반의 준비는 그 이후가 될 가능성이 큽니다.

다만 ML·과학 계산 분야에서는 표준이 사용 가능해지는 즉시 빠른 채택이 이뤄질 가능성이 높습니다. 이미 핵심 패키지들이 Wheel Next 워킹 그룹에 참여하고 있기 때문입니다.

---

728x90

패키징은 더 이상 부수적인 문제가 아니다

Python 패키징 시스템은 단순했던 시대에 만들어졌습니다. 그러나 지금은 데이터 사이언스와 AI 워크로드가 폭발적으로 증가한 시대입니다.
성능, 네트워크 대역폭, 사용자 경험 모두에서 기존 구조는 병목이 되고 있습니다.

Wheel Next는 이 문제를 정면으로 다룹니다. 사용자는 아무것도 신경 쓰지 않고, 단지 pip이나 uv를 실행하면 됩니다. 그 이면에서는 하드웨어에 최적화된 선택이 자동으로 이뤄집니다.

아직은 시간이 필요합니다. 하지만 방향은 분명합니다.
Python 패키징은 다시 한 번, 현대 하드웨어를 전제로 한 진화를 시작하고 있습니다.

300x250

https://talkpython.fm/episodes/show/544/wheel-next-packaging-peps

Wheel Next + Packaging PEPs