GN⁺: UV 기술의 장단점 및 마이그레이션 필요성 검토
(bitecode.dev)uv 사용 1년: 장단점 및 마이그레이션 여부
요약
-
uv
는 Astral에서 개발한 새로운 Python 프로젝트 관리 도구로, 다양한 상황에서 사용해 본 결과, 사용을 권장할 만한 가치가 있음. -
uv
는 설치 및 전환 비용이 낮고, 제공하는 가치가 높음. - Python 부트스트래핑 문제를 독립적으로 해결하며, 다양한 플랫폼에서 일관된 방식으로 Python을 설치하고 실행할 수 있음.
-
pip
및venv
와의 호환성을 제공하여 기존 프로젝트와의 통합이 용이함. - 강력한 의존성 해결 기능을 제공하며, 간단한 작업을 쉽게, 복잡한 작업을 가능하게 함.
uv가 해결하려는 문제
- Python 설치 및 부트스트래핑의 복잡성으로 인한 문제 해결.
- 다양한 설치 방법과 운영 체제에 따라 달라지는 설정 문제.
- Python의 다양한 사용 맥락으로 인해 통일된 튜토리얼 제공의 어려움.
- 잘못된 정보와 선택의 역설로 인한 혼란.
부트스트래핑의 올바른 접근
-
uv
는 Python 자체와 독립적으로 작동하여 부트스트래핑 문제를 해결함. -
pip
및venv
인터페이스를 제공하여 기존 커뮤니티와의 호환성을 유지함. - Python 설치를 통합된 방식으로 제공하며, 관리자 권한 없이 설치 가능.
프로젝트 관리 기능
-
uv init
은 기본적으로.venv
,pyproject.toml
, git 저장소 등을 생성함. - 의존성 관리 및 프로젝트 빌드 기능 제공.
- 플랫폼 간 호환 가능한 잠금 파일 제공.
uv의 한계
- 패키징 문제는 해결할 수 없으며, 이는 PyPI의 데이터 품질에 의존함.
- 오래된 프로젝트에서는 의존성 해결이 어려울 수 있음.
- 특정 Python 버전을 제공하지 않을 수 있으며, 이는 외부 설치 Python과의 호환성 문제로 이어질 수 있음.
-
uv
의 캐시가 많은 공간을 차지할 수 있음.
uv 사용 시기와 사용하지 말아야 할 시기
- 레거시 프로젝트에서 의존성 해결이 어려운 경우.
- 기업 환경에서 사용이 제한되는 경우.
- 특정 Python 버전을 필요로 하는 경우.
- CLI 사용이 팀에 큰 장애물이 되는 경우.
결론
-
uv
는 대부분의 경우에 유리한 선택이며, 사용해보고 문제가 발생하면 다른 도구로 전환하는 것이 좋음. -
uv
는 Python 프로젝트 관리에 있어 많은 이점을 제공하며, 사용을 권장함.
Hacker News 의견
-
매우 잘 작성된 글임. Python 패키징의 어려움에 대한 저자의 분석을 존경함
- uv의 출현으로 Python 패키징이 해결된 느낌을 받음
- 단일 파일 Python 스크립트에서 인라인 종속성을 갖고 자연스럽게 실행할 수 있는 것이 아름다움
- JavaScript의
import ObjectName from 'module-name';
와 유사한 인라인 종속성 전용 구문이 있으면 좋겠다고 생각함 - 작은 Python 스크립트에서 종속성을 피하거나 복잡한 해결책을 사용해야 했던 과거를 회상함
- 개인적으로는 로컬 스크립트를 위한 거대한 가상 환경을 관리했었음
- 종속성을 추가하는 것에 대한 두려움이 있었고, 같은 방식으로 해결했음
- 이러한 변화가 작업 방식을 완전히 바꾼다고 느끼며, 테스트 환경을 자주 파괴하고, 테스트를 피하거나 도구 사용을 꺼렸던 과거를 회상함
-
conda에 대한 언급이 많은 기사들처럼, 이 글도 conda가 오랫동안 가지고 있던 "새로운" 기능들에 대해 열광함
- Python 부트스트래핑에서 독립적이라는 점에서 conda와 유사함
- 모든 상황과 플랫폼에서 Python을 통합적으로 설치하고 실행할 수 있음
- 강력한 종속성 해결 기능을 가짐
- uv가 가지고 있는 "프로젝트 관리" 기능이 conda에는 없지만, 사람들은 그것을 원함
- uv와 같은 도구의 장점은 pip와 잘 상호작용할 수 있다는 점임
- 단점은 비-Python 종속성을 별도로 배포할 수 없는 등의 제한을 상속받는다는 점임
-
uv의 팬이지만, 86GB의 Python 종속성 다운로드 캐시가 주요 SSD에 있는 것은 pip의 문제를 해결하지 못한다는 증거임
- 25년 동안 프로그래밍하면서 언어/빌드 시스템에 대해 이렇게 화가 난 적이 없었음
- Scala의 SBT를 다뤘던 과거를 회상함
-
"uv를 사용하지 말아야 할" 시나리오로, 많은 nvidia 라이브러리가 torch처럼 더 나은 패키지로 포장되지 않은 경우를 언급함
- nemo2riva를 설치하기 전에 pip를 깨뜨려 nvidia의 패키지 레지스트리를 사용하도록 하는 다른 패키지를 설치해야 함
- uv는 이러한 상황을 처리하지 않음
-
Astral이 어떻게 수익을 창출할 것인지에 대한 질문이 남아있음
- 기업 패키지 인덱스를 보안 기능과 함께 제공하면 많은 조직에 쉽게 판매할 수 있을 것 같음
-
uv가 비 Python 개발자에게 Python을 더 접근 가능하게 만든다는 점에서 큰 칭찬을 받을 수 있음
- 외부인에게는 생태계가 매우 혼란스러울 수 있음
- uv를 사용하면 가상 환경을 신경 쓸 필요가 없음
-
uv의 비프로젝트 기반 워크플로우/구성을 설명해줄 수 있는지 궁금함
- conda를 사용하여 동일한 ML 환경을 여러 폴더나 임시 노트북에서 사용함
- 새로운 환경을 각 관련 "프로젝트"에 대해 만드는 것이 이해되지 않음
-
uv에 대한 반대 의견을 제시함
- conda는 환경 관리, pip는 패키지 관리에 사용하여 두 도구의 장점을 활용함
- uv가 모든 것을 해결하려는 또 다른 시도일 뿐이라고 생각함
- uv의 디자인에서 혁신적이거나 직관적인 점을 찾지 못함
-
uv의 정적 타입 체커 출시를 기대하고 있음
- Python 세계에서 흥미로운 새로운 기회를 제공할 수 있을 것임
-
프로젝트 이름을 uv로 정한 것은 libuv의 보편적인 성격 때문에 불행한 선택이라고 생각함