uv가 이렇게 빨라진 이유

1 month ago 10

Python 패키지 관리자 uv는 pip보다 10배 이상 빠른 설치 속도를 보이며, 이는 단순히 Rust로 작성되었기 때문이 아니라 설계상의 선택에서 비롯됨
속도를 가능하게 한 핵심은 정적 메타데이터 표준(PEP 518, 517, 621, 658) 으로, 코드 실행 없이 의존성을 파악할 수 있게 함
uv는 pip이 유지하는 레거시 기능(.egg, pip.conf, 시스템 Python 설치 등) 을 과감히 제거해 불필요한 코드 경로를 없앰
Rust가 기여한 부분은 제로-카피 역직렬화, 락 없는 동시성, 단일 바이너리 구조 등으로, 전체 속도 향상 중 일부만 차지함
전체적으로 uv의 사례는 표준화된 메타데이터와 불필요한 호환성 제거가 성능 혁신의 핵심임을 보여줌

uv의 속도를 가능하게 한 표준

pip의 느림은 구현 문제가 아니라, 과거 setup.py 기반 구조로 인해 의존성을 알기 위해 코드를 실행해야 했던 구조 때문임
- setup.py 실행에는 빌드 의존성 설치가 필요했고, 이는 “닭과 달걀 문제” 를 초래
- 설치 과정에서 임의 코드 실행과 반복 실패가 발생, 설치 속도를 저하시킴
PEP 518(2016) 은 pyproject.toml을 도입해 코드 실행 없이 빌드 의존성을 선언 가능하게 함
PEP 517(2017) 은 빌드 프런트엔드와 백엔드를 분리, pip이 setuptools 내부를 이해할 필요를 제거
PEP 621(2020) 은 [project] 테이블을 표준화해 TOML 파싱만으로 의존성 확인 가능
PEP 658(2022) 은 패키지 메타데이터를 Simple Repository API에 직접 포함시켜, 휠 다운로드 없이 의존성 정보를 가져올 수 있게 함
PyPI는 2023년 5월 PEP 658을 적용했고, uv는 2024년 2월 출시되어 새 표준 인프라를 완전히 활용한 첫 도구로 등장
Rust의 Cargo나 npm처럼, Python 생태계도 이제 정적 메타데이터 기반 패키징으로 전환됨

Rust는 특정 저수준 최적화에서 중요한 역할을 함
- rkyv 기반 제로-카피 역직렬화로 캐시 데이터를 복사 없이 직접 사용
- 락 없는 동시성 구조체로 안전한 병렬 접근 구현
- 인터프리터 초기화 없음: uv는 단일 정적 바이너리로, pip의 Python 프로세스 생성 비용 제거
- 버전 정보를 u64 정수로 압축 표현, 비교 및 해시 연산을 빠르게 수행
이러한 요소들은 성능을 높이지만, 전체 속도 향상의 주된 원인은 아님

uv의 속도는 Rust 때문이 아니라, 하지 않는 것들 덕분임
PEP 518·517·621·658의 표준화가 빠른 패키지 관리의 기반을 마련했고, uv는 레거시 제거와 현대적 가정으로 이를 실현
pip도 병렬 다운로드, 글로벌 캐시, 메타데이터 기반 해석을 구현할 수 있지만, 15년간의 하위 호환성 유지가 장애 요인
결과적으로 pip은 항상 느릴 수밖에 없고, 새로운 전제에서 출발한 도구만이 근본적 속도 향상 가능
다른 패키지 관리자에게 주는 교훈은, 정적 메타데이터·코드 실행 없는 의존성 탐색·사전 해석 가능 구조가 필수라는 점임
Cargo와 npm은 이미 이 방식을 채택하고 있으며, 의존성 확인을 위해 코드를 실행해야 하는 생태계는 근본적으로 느림