Hacker News 의견

• 몇 달 전까지만 해도 uv를 절대 쓰지 않겠다고 생각했는데, 이미 venv와 pip에 익숙했기 때문이었음, 다른 도구가 굳이 필요하다고 생각하지 않았음, 하지만 최근 공유 서버에서 root 권한이 없는 상황에서 각종 패키지나 드라이버가 다 깨져 있었고 pytorch가 필요했던 경험 덕분에 완전히 uv로 바꾼 상황, pip은 오랜 시간이 걸리고 캐시가 공간을 엄청 차지하며 위치 변경도 잘 안 되는 불편함이 있었음, uv로 바꾸자 모든 게 너무 잘 동작해서 만족함, 아직 망설이고 있다면 5분만이라도 꼭 써보라는 추천

  • uv의 최고의 장점은 기존에 쓰던 venv 기반 워크플로우와 완전히 호환된다는 점, 그냥 uv venv 실행으로 해결 가능
  • uv는 설명하거나 특히 초보자에게 사용법을 안내할 때 훨씬 쉽게 느껴짐, pip + 설정 파일 + venv 조합은 올바른 venv를 만들고 설치하는 과정이나, 스크립트 실행/테스트마다 어색한 shebang이나 venv 활성화를 기억해야 해서 헷갈리고 에러 메시지도 온전히 도움을 못 주는 불편함이 있었음, 초보자에게 가르칠 때 도구들이 참 번거롭게 느껴졌고, 이제는 "uv run", "uv add", "uv sync"만 기억하면 되니까 팀원들도 훨씬 덜 부담스럽게 받아들이는 분위기
  • 나의 경우 asdf를 사용하다가 mise로 넘어갔는데, uv와 같은 범용 도구들과 비교하면 어떨지 궁금증
  • pip 캐시가 많은 공간을 차지하고 위치도 제대로 바꿀 수 없었다고 했는데, uv가 저장소 공간 활용 면에서 더 나은지 궁금, 만약 낫다면 그 이유가 공유를 잘하는 방식 때문인지도 궁금함
  • 최근 실험용 저장소에서 "uv a b c"로 시작하는 간단한 가이드 보고 실행해본 경험, 내부적으로 많은 중복이 있는 듯하지만, 실사용에서는 GNU-Debian-Ubuntu 기본 호스트에서 딱히 문제 없고 모든 게 순조롭게 돌아가서 만족

• 처음 uv를 썼을 때, pip과 비교해 워낙 빨리 끝나서 뭔가 실수했거나 제대로 동작하지 않은 줄 알았던 기억

  • 가끔 패키지 설치에 200ms 정도 걸려서 엔터 입력과 프롬프트 표시 사이에 아주 약간의 딜레이가 느껴짐, 하지만 Poetry에서는 커피 한 잔 마시고 오면 끝나는 수준이라 속도 차이가 확연함
  • 나 역시 같은 느낌, 워낙 매끄러워서 Python이 아닐 것 같은 경험
  • 비슷한 경험을 최근에 했고, 덕분에 완전히 uv로 전향한 입장
  • 나도 의심이 들 정도였지만, 시도해보고 나선 원래로 돌아갈 수 없을 정도로 만족

• uv와 ruff는 "절대 바퀴를 다시 만들지 말라"는 말에 대한 멋진 반례라고 생각, 목적이 뚜렷하다면 기존보다 월등히 나은 결과물이 나오는 경우도 발생

  • 대부분 그런 말이 나오는 맥락은 기존을 잘 모르는 초보자에게 해당하는 조언이라고 봄, 즉 시스템의 한계와 개선점을 모르는 사람이 섣불리 재발명을 시도할 때에만 들어맞음, 진짜 전문가에겐 해당 안 되는 말
  • 이들이 바퀴를 다시 만든 게 아니라, 기존의 목재 바퀴를 더 견고한 재질로 교체해서 10배 속도로 회전 가능하게 만들었다는 비유
  • Python 패키지 관리의 역사만 봐도 모두가 기존보다 더 잘 만들겠다는 생각으로 뛰어든다는 인상
  • 사실 "바퀴를 다시 만들지 않는다"는 속담 자체가 말이 안 됨, 우리는 실제 바퀴도 계속 발전시켜 왔는데 소프트웨어 역시 더 좋은 바퀴를 만들지 않을 이유가 없음
  • 약간 새는 이야기지만, "order of magnitude better" 대신 왜 짧은 "10x" 표현을 안 쓰고 굳이 긴 표현을 선호하는지 궁금증

• 작은/저사양 시스템(AWS T2.micro에서 Windows 같이)에선 uv가 너무 많은 동시 다운로드를 시도해 타임아웃이 남, 환경 변수 UV_CONCURRENT_DOWNLOADS로 동시 다운로드 수를 1~2 정도로 제한하면 해결, uv 기본 설정이 너무 공격적이라 느끼며, 서버별 스레드 자동 조정에 다운로드 속도를 활용하는 식으로 개선되면 좋겠음

  • 전혀 이상한 사례가 아니며, 많은 유저가 저렴한 VPS에서 사이드 프로젝트를 진행함, (본인도 자주 그러는 편, AWS는 아니지만), 공유해줘서 고맙고 자동 감지 기능이 개선되길 바람

• 최근 노트북에 uv를 개인용으로 써보고 있는데, pip에 익숙했던 입장에선 체감 속도가 도무지 믿기 힘들 정도로 빨라서 몇 번은 제대로 실행됐는지 헷갈린 경험

• uv add <mydependencies> --script mycoolscript.py 명령을 좋아함, 그리고 맨 위에 #!/usr/bin/env -S uv run을 붙이면 Python 스크립트를 즉시 실행 가능해서 매우 유용한 툴로 활용 중

  • 이 방식을 Claude Project에 특화된 프롬프트로 가르쳐서, 단일 입력만으로 의존성 포함 전체 스크립트 자동 생성도 가능, Claude 4의 컷오프는 2025년 3월임, Claude Sonnet 4에선 추가 프롬프트 없이도 이 기능이 동작, 예시로 URL을 입력하면 httpx와 beautifulsoup으로 크롤링해서 링크 목록을 CSV로 반환하는 코드를 바로 생성 관련 자료 Claude 스크립트 결과
  • Marimo.io 노트북의 app-mode와 함께 이 트릭을 사용, uv만 설치돼 있으면 즉석에서 반응형, 재현 가능한 앱을 최소한의 준비만으로 타인에게 손쉽게 전달 가능, 정말 최고 조합
  • 지금은 작은 스크립트도 즉흥적으로 바로 실행하는 습관이 생겼음, 환경이나 의존성 관리를 신경 쓸 필요가 없어져서 훨씬 쾌적, the little scripter 관련 글, 관련 유튜브 영상, ez-mcp 깃허브
  • 예시를 잘못 읽었다는 정정과, 프로젝트 컨텍스트에서 'uv add --script'와 단순 'uv add'는 다르단 설명 및, 공식 문서에서 run --with이나 PEP723 지원 등 더 유용한 기능이 많으니 확인 권장 공식 가이드
  • "mydependencies"가 구체적으로 뭐냐는 질문, 설정 파일의 의미인지 궁금

• uv를 예전에 시도했는데, 압도적으로 빠르고 사용도 쉬워서 놀람, 이제 거의 pip을 쓸 이유가 없고 Python만 쓴다면 conda도 필요가 없어짐

  • pyenv와 poetry 역시 이제는 사용하지 않게 됨

• UV를 정말 좋아함, Astral 팀의 Ruff도 좋아해서 기존 pylint + Black에서 Ruff로 린팅/포매팅을 모두 옮김, 린트 시간이 90초에서 1.5초 미만으로 단축된 경험, 깜짝 놀람

  • 다만 ruff는 pylint의 일부 체크만 수행하고 지나치게 명확한 에러들도 검출 못하고 그냥 넘어간다는 점을 나중에 알게 돼서 아쉬움, (실행 불가한 코드 등도 걸러지지 않음)

• 최근에는 아래 패턴으로 작은 실행형 스크립트를 돌리는 게 새롭게 마음에 들어서 즐겨 사용 중

  #!/usr/bin/env -S uv --quiet run --script
  # /// script
  # requires-python = ">=3.13"
  # dependencies = [
  #   "python-dateutil",
  # ]
  # ///
  #
  # [python script that needs dateutil]  
  

  • 해시뱅 줄이 너무 외우기 어려워서 그냥 #!/usr/bin/env uvx 정도의 더 단순한 형태가 있으면 좋겠음, 쓸 때마다 검색해야 하는 번거로움이 있음

• 완전히 만족해서 pip/twine/requirements.txt로 다시 돌아가고 싶지 않음, 여러 프로젝트가 내부 GitLab에 공용 휠을 두고 있었는데 기존 YAML 10줄을 "uv build"와 "uv publish" 두 줄로 대체 가능, 의존성 가져오기 편하고 주요 의존성도 한 번에 확인 가능, requirements.txt에 모든 걸 뒤섞어 두는 번거로움이 사라짐