Hacker News 의견

• 예전엔 Python의 툴링이 충분하다고 들었지만, 이제 Python 개발자들이 npm이나 cargo, bundler 같은 lockfile 기반 생태계를 경험하고 나서 그 장점을 깨닫는 걸 보니 속이 시원해짐
  npm에도 문제는 있지만, 일관된 설치와 잠금 파일은 정말 훌륭한 개념임

  • 다른 사람의 Python 프로젝트를 실행해야 할 때만큼 두려운 일은 없음
    이렇게 오랫동안 환경 관리가 불편했다는 게 놀라움
  • 왜 이렇게 오래 걸렸는지 궁금함
    수많은 시도가 실패한 이유가 단순히 패키지 관리의 난이도 때문인지, 아니면 VC 자금이 필요했기 때문인지 의문임
  • 예전부터 pip freeze > requirements.txt와 pip install -r requirements.txt를 써왔음
    버전 범위를 쓰지 않으면 사실상 requirements.txt가 lockfile 역할을 함
    그래서 요즘의 ‘공식 lockfile’ 열풍이 조금 과장된 것 같음
  • npm도 한동안 lockfile이 없었음
    yarn이 등장하면서 npm이 개선된 게 크다고 봄
  • 1998년부터 웹 개발을 해왔는데, npm보다 PNPM이 훨씬 낫다고 생각함
    더 빠르고 효율적이며 결정적임
    자세한 내용은 pnpm.io/motivation 참고

• UV 스크립트를 이용해 MCP 클라이언트/서버를 단일 파일로 배포할 수 있었음
  관련 글: MCP server in a file

• 대부분의 스크립트가 단일 파일이라, 맨 위에 아래 코드를 추가하면 삶이 훨씬 단순해짐
  #!/usr/bin/env -S uv run --script
  이렇게 하면 스크립트가 독립 실행 파일처럼 동작하고, uv가 필요한 모듈을 자동으로 설치해줌

  • 보안 관점에서 보면 이런 방식은 조금 위험 요소가 있음
    스크립트 작성자가 악성 의존성을 숨길 수도 있기 때문임
    화이트리스트 기능이 있으면 좋겠음
  • 현재 날짜 기준으로 최대 릴리스 날짜 플래그를 쓰면 lockfile 없이 버전을 고정할 수 있음
    다만 일부 패키지는 릴리스 날짜를 감지하지 못함 (예: yaml)
  • 실행하려면 uv가 설치되어 있어야 하므로 완전한 standalone은 아님
  • /usr/bin/env -S를 지원해야 하고, 의존성 이름은 uv pip install 명령에서 쓰는 배포 패키지명을 써야 함
    이는 PEP 723 표준이며 pipx도 지원함
  • 인터넷 연결이 필요하고, 저장소 상태에 따라 다른 버전이 설치될 수도 있음

• uv를 쓰기 전엔 Rust에 관심이 없었는데, uv 덕분에 성능 민감한 코드는 Rust로 옮기게 됨
  conda는 완전히 사라졌으면 좋겠음. ML 클러스터에서 conda 환경이 너무 커지고 재현성도 떨어짐

  • conda 대안으로 Rust 기반의 pixi를 추천받음. uv의 PyPI 솔버를 재사용함
  • conda는 의존성을 고정하면 재현성은 있지만, 빌드가 느림
  • ML 클러스터라면 컨테이너화가 되어 있어 conda가 필요 없다고 생각함
  • uv로 CUDA 의존성 관리를 어떻게 하는지 궁금함
  • 대규모 ML 의존성 관리에 대한 오픈소스 접근법은 Metaflow docs와 Fast Bakery 블로그 참고

• 예전엔 pyenv + venv + pip + pipx 조합으로 충분히 만족했지만, uv는

  • 의존성 해석 속도가 매우 빠르고
  • uv run, uv add 등으로 사용성이 훨씬 좋아졌음
  • 여러 툴을 하나로 통합했고
  • Python 설치도 간편해짐

• 환경을 활성화하는 대신 명령 앞에 uv를 붙이는 게 훨씬 편함
  Python 버전 관리도 쉬워지고, 프로젝트별로 batteries-included 느낌이 있음
  아직 장기적으로 안정성은 모르지만 새 프로젝트엔 기본으로 쓰고 있음

  • 환경 활성화는 단순히 PATH와 프롬프트를 조정하는 것뿐임
    uv가 자동으로 환경을 감지하는 걸 싫어하는 사람도 있음
    Python 버전 관리의 가치를 잘 모르겠지만, uv로 환경 재생성은 훨씬 빨라짐
  • uv를 붙이면 stateless하게 명령을 실행할 수 있어 협업 시 편함
  • mise와 함께 써서 자동 활성화를 하되, uv 접두사는 여전히 유용함
  • uv의 철학은 venv는 일회용이라는 것임. 문제 생기면 .venv를 지우면 됨
  • 사실 이런 환경 설정은 그냥 “그냥 작동해야 하는” 문제임

• 이 블로그 글이 내 경험과 거의 일치함
  마찰이 줄고 단순해졌음
  Python 커뮤니티가 uv를 기본 도구로 채택했으면 함

• Rust 기반 툴들이 피드백 속도를 완전히 바꿔놓았음
  다만 Astral이 수익을 어떻게 내는지 궁금함. 투자도 받았는데 유료 제품이 없음

  • Astral의 수익 모델은 오픈소스 도구와 통합된 엔터프라이즈 소프트웨어 판매임
    예: 사내용 패키지 레지스트리
    관련 인터뷰: Charlie Marsh 인터뷰
  • 유료 서비스로 발전할 가능성이 있는 제품은 Pyx
  • Conda도 “보안 강화 패키지” 접근권만으로 돈을 벌고 있음
    Python 개발자가 1천만 명이라면 uv도 충분히 수익화 가능하다고 봄

• 개인적으로는 타입 어노테이션과 GIL 제거가 uv보다 더 중요하다고 생각함
  uv는 아직 초기 단계라 불편함도 있음. 결국 또 하나의 패키지 관리자일 뿐임

  • 사람들이 uv를 칭찬하는 이유 중 일부는 사실 pip과 venv가 이제 표준화된 PEP들 덕분에 개선된 결과임
    pip의 새 resolver와 wheel 배포 증가가 큰 역할을 했음
    관련 글: Wheels are faster for pure Python
  • 언어 차원에서는 GIL 제거가 더 큰 변화겠지만, 실제로 효용 있는 사례는 아직 많지 않음
  • 타입 힌트는 이미 2015년에 도입된 오래된 기능임
  • uv는 단순한 패키지 관리자가 아니라 배포 단순화에 큰 가치를 줌
    Rust로 작성된 것도 흥미로움. LLVM처럼 다른 언어를 지원하는 구조임
    end-user 입장에선 uv가 훨씬 낫고, 유지보수자에게 불편하다면 피드백을 주면 됨
  • 타입 어노테이션은 문서화엔 좋지만 실용성은 낮음
    엄격 모드가 생기면 성능 향상도 가능하겠지만 언어 철학과 충돌함
    그래도 conda가 사라진다면 uv로 옮길 의향은 있음

• 나는 uv가 마음에 들지 않음

  • 너무 많은 걸 하려 함: pip, pyenv, virtualenv, ruff까지 한 번에 대체하려 함
  • uv pip을 써야 해서 완전한 대체도 아님
  • Docker와의 호환성도 떨어짐
  • 새로운 환경 변수들이 많아 복잡도 증가가 있음
  • pyenv, virtualenv, pip이 따로 있는 게 이상하지 않다고 생각함
    하지만 pip과 venv도 자주 깨지고 디버깅이 더 어려움
  • 사실 pip, pyenv, virtualenv는 항상 함께 쓰이므로 통합 도구가 합리적임
    uv는 ruff를 대체하지 않음
    환경 변수는 건드릴 필요도 없음
  • uv pip은 pip을 호출하는 게 아니라 호환 인터페이스를 제공함
    실제로는 uv가 pip을 대체함
    Docker 호환성 문제는 구체적으로 어떤 건지 궁금함
  • uv add, uv sync, uv run으로 관리하면 훨씬 인체공학적이고 빠름
    자세한 문서는 uv dependencies 개념 참고
  • 내 경험상 uv는 여러 역할을 잘 수행함. 구체적으로 어떤 문제를 겪었는지 궁금함