Rye와 uv: 8월은 Python 패키징 수확 시즌

• Rye의 관리권이 2024년 2월 Astral로 넘어간 뒤, 기반 resolver·installer인 uv가 빠르게 개선되며 Python 패키징 도구 통합 후보로 부상함
• 최신 uv는 pyproject.toml 조작, workspace 지원, 로컬 패키지 참조, 스크립트 설치, Python 설치 관리까지 포함하며 Rye가 맡던 영역을 흡수하고 있음
• AI·ML 투자로 Python 신규 사용자가 늘었지만, 패키징 도구 선택지가 많고 호환성이 엇갈려 개발자 경험은 여전히 일관되지 않음
• 패키징 생태계는 모두가 쓰는 지배적 도구가 있어야 투자와 문서가 한 스택으로 모이고, Rye는 uv 중심 전환을 위한 마이그레이션 경로가 될 가능성이 큼
• Astral의 VC 투자는 PSF와 Python 코어 프로젝트가 고려해야 할 리스크지만, uv는 최악의 경우에도 포크와 유지보수가 가능한 코드로 평가됨

---

Rye에서 uv로 기능이 모이는 흐름

• 2024년 2월 Rye의 관리권이 Astral로 넘어갔고, 이후 몇 달 동안 Astral은 Python 패키징 도구를 빠르게 개선함
• Rye 사용자는 기반 resolver·installer인 uv가 더 좋아지고 빨라진 것을 체감할 수 있었음
• 최신 uv는 예전에는 Rye가 필요했던 기능을 직접 제공하기 시작함
  • pyproject.toml 파일 조작
  • workspace 지원
  • 로컬 패키지 참조
  • 스크립트 설치
  • Python 설치 관리
• 현재 Rye를 쓰는 사용자는 uv를 살펴보고 Astral에 피드백을 줄 필요가 있음

Python 패키징 도구가 하나로 모여야 하는 이유

• EuroPython Prague 발표는 Python 패키징의 현재 상황과 Rye를 만들며 얻은 교훈을 중심으로 함
• 패키징 도구의 목표는 해당 영역을 지배하는 도구가 되는 것임
  • 모두가 쓰는 도구가 가장 좋은 도구여야 함
  • Python을 처음 접하는 사람이 프로그래밍 여정을 시작할 때 마주치는 도구이기 때문임
• 최근 2년간 Python은 AI와 ML에 대한 투자와 관심에 힘입어 신규 개발자에게 매우 뜨겁고 인기 있는 플랫폼이 됨
• 신규 사용자가 Python을 낡고 도구가 나쁜 언어가 아니라, 뛰어난 개발자 경험을 가진 언어로 기억하는 것이 중요함
• 하지만 현재 Python 패키징은 선택지가 너무 많고, 도구 간 호환성이 완전하지 않으며, 곳곳의 불일치가 경험을 흔듦
  • 어떤 사용자는 한 도구를 따라가다가 벽에 부딪혀 전체 스택을 conda로 옮겼다가 다시 돌아오는 상황을 겪음

uv가 지배적 도구가 될 가능성

• 도구가 지배적 위치를 갖는다는 것은 대부분의 투자가 하나의 스택으로 모인다는 뜻임
• Rye와 그 주변의 여러 도구는 지배적 도구가 확립되면 더 이상 독립적으로 존재하지 않아도 되는 방향이 바람직함
• 현재 uv는 그 역할을 맡을 가능성이 가장 큰 도구로 평가됨
  • 아직 모든 사용 사례를 충족하는 것은 아님
  • 다만 빠르게 그 지점에 도달할 것으로 보임
• 커뮤니티가 지금 uv를 중심으로 모이기 시작해야 할 시점임
• 이 도구가 영원히 유일한 도구가 된다는 뜻은 아님
  • 도구는 생기고 사라질 수 있음
  • 미래에는 다른 도구가 나올 수도 있음

Rye의 은퇴와 Python 프로젝트 안내의 변화

• 기대되는 Rye의 최종 릴리스는 Rye 고유 기능을 은퇴시키고 사용자를 uv로 마이그레이션하며, 대부분 uv의 별칭처럼 동작하는 형태임
• Rye 하나를 은퇴시키는 것만으로는 충분하지 않음
  • 현재 Python에는 여러 패키지 관리 해법이 쓰이고 있음
  • 커뮤니티는 더 적은 수의 도구를 안내해야 함
• Rye와 uv는 그 아래 생태계의 오랜 발전 위에 만들어짐
  • setup.py에서 eggs, 그리고 wheels로 이동한 흐름
  • 메타데이터 표준의 부재에서 표준 보유 상태로 이동한 흐름
  • 결합된 빌드 시스템에서 분리된 빌드 시스템으로 이동한 흐름
  • 재배포·다운로드 가능한 Python 바이너리를 가능하게 만든 작업
  • 관련 Rust crates와 Python 라이브러리 생태계
• 커뮤니티는 언젠가 일부 도구를 더 이상 추천하지 않는다고 말할 준비가 필요함
  • 예전에는 신규 개발자 안내 문서에서 ez_setup.py와 easy_install을 권장했음
  • 이후 안내 문서에서 ez_setup.py를 제거하고 pip로 대체함
  • 일부 프로젝트는 pip-tools, poetry, PDM을 안내했음
  • 현재 많은 프로젝트는 다양한 도구 때문에 5가지 설치 안내를 동시에 보여주기도 함
• 중요한 Python 프로젝트 유지보수자는 uv를 직접 써보고, 사용자에게 uv를 안내할 수 있을지 판단해볼 필요가 있음
• Astral의 Charlie가 쓴 uv가 현재 할 수 있는 일에 대한 글은 uv의 현재 성과를 보여줌

Astral의 VC 투자와 커뮤니티 리스크

• uv를 만드는 Astral이 VC 투자를 받은 회사라는 점은 피할 수 없는 쟁점임
• 커뮤니티 입장에서는 누군가 많은 돈을 투입하는 일이 새로운 과제를 만들 수 있음
• PSF와 Python 코어 프로젝트는 이 점을 고려해야 함
• uv의 코드와 동작을 보면, 최악의 미래에도 포크 가능하고 유지보수 가능한 대상으로 보임
• Astral이 문을 닫거나 라이선스 측면에서 매우 의심스러운 일을 하더라도, 커뮤니티는 uv가 존재하기 전보다 더 나은 위치에 있을 수 있음

[GN⁺]

Hacker News 의견들

• uv의 최신 릴리스는 어제도 논의됐음: https://news.ycombinator.com/item?id=41302475
  링크된 글은 Rye 작성자가 그 릴리스를 보고 쓴 견해임

• uv에 관심 있는 사람에게는, pip 대신 uv를 쓰면서 Home Assistant 릴리스 과정이 크게 빨라졌음
  릴리스에 걸리는 시간이 약 2.5시간에서 약 20분으로 줄었고, 자세한 내용은 https://developers.home-assistant.io/blog/2024/04/03/build-i...에 있음. 참고로 나는 그냥 HA 사용자임

  • 컴파일러 언어도 아닌데 pip가 이미지를 만드는 데 1시간 넘게 걸렸다는 게 이해가 안 됨
    Python을 가볍게 쓰는 입장이긴 하지만, 대체 뭘 하길래 그렇게 오래 걸렸는지 모르겠고 말도 안 되게 느껴짐

• Python 패키징에 문제가 있다는 건 알지만, 개인적으로는 지금까지 plain pip만으로도 꽤 멀리 왔음
  가장 큰 변화는 원래 virtualenv에서 내장 venv 모듈로 갈아탄 것이었음. 정말 진지하게 의존성 관리를 하려면 FAANG식으로 모노레포를 만들고 패키지 관리자와 관련된 번거로움을 피할 것 같음

  • 모노레포를 직접 해보길 정말 권하고 싶음
    운영 환경에서 Python 모노레포를 관리하고 있는데 의존성 관리가 지옥임. Poetry의 새 기능 몇 가지를 적용해보려 하지만, 큰 모노레포를 둘러싼 생태계 상태는 끔찍함
  • 이 문제는 더 깊게 생각해볼 필요가 있음
    “나한테는 충분하다”가 목표가 아니고, Python 개발자 2명짜리 조직부터 수백·수천 명 규모까지 확장되는 패키지와 가상 환경 표준 도구가 필요함. 그렇지 않으면 생태계가 쪼개지고, 버그와 어려운 문서화가 늘어나 언어가 효과적으로 계속 발전하기 어려워짐
  • Python 버전에 신경 쓰지 않는다면 나도 pip + venv로 충분하다고 봄
    하지만 프로젝트가 어떤 Python 버전을 기준으로 만들어졌는지 정의할 방법이 없음. 패키지를 만든다면 여러 버전에 대해 테스트해야 할 가능성이 높고, 설치 가능한 배포 패키지가 아니라 몇몇 개발자가 공유하는 코드 묶음이라면 머신러닝 모델 실행, 클라우드 함수 배포, 보고서 생성 같은 작업에는 보통 Python 버전 하나만 정확히 목표로 삼고 싶을 것임
    모노레포 접근이라는 게 numpy와 pandas를 저장소에 복사해 넣자는 뜻인지도 의문임
  • 내 경험도 완전히 같음: pip는 나에게 충분함

• 처음에는 새 도구가 Python의 “패키징” 문제를 해결해줄 것 같아 기대했지만, 더 읽어보니 내가 만든 Python 애플리케이션을 포장하는 문제라기보다 패키지 관리에 관한 내용이었음
  개인적으로 Python 패키지 관리에는 큰 문제가 없었고, 생태계에 부족한 점은 있지만 네임스페이스가 없다는 점 같은 것을 제외하면 pip는 대체로 잘 동작함
  정말 짜증나는 건 Python 애플리케이션을 쉽게 실행 파일로 감싸서 어딘가에 배포할 수 없다는 점임. 운영 환경에서 git clone과 virtualenv 생성을 하는 모습을 자주 보는데, 대상 서버에 필요 이상의 연결성이 요구되고 개발 의존성이 운영체제에 남기도 함. 보안 관점에서는 아주 나쁜 생각이라서, 이 문제가 해결되기 전까지는 최종 사용자나 운영 배포가 필요한 작업에는 다른 언어를 선호할 것임

  • 그 말이 틀린 건 아니지만, 풀어보면 핵심은 다른 사람이 애플리케이션을 쉽게 실행하게 만들 필요가 있다는 뜻임
    그러려면 애플리케이션이 사용자에게 전달되고, 거기서 Python을 찾으며, 그 과정이 사용자에게 투명해야 함. Rye를 만들 때, 그리고 uv도 마찬가지로, 시스템을 망가뜨리지 않는 방식으로 Python 설치를 지원하려 한 이유 중 하나가 이것임
    더 발전한 형태는 uv까지 포함해 전 과정을 자동화하는 것임. 지금도 원한다면 curl to bash 설치 프로그램으로 uv/Rye와 앱을 앱 전용 임시 위치에 설치하고, 사용자 시스템을 절대 깨지 않게 만들 수 있음
    언젠가는 이 과정이 완전히 투명해지고 네트워크 접근도 필요 없으며 Windows용 .msi 같은 것도 제공되면 좋겠음. 다만 그 전제는 uv 같은 도구가 미리 컴파일된 Python과 필요한 모든 의존성을 사용자 플랫폼에 맞는 위치에 임의로 배치할 수 있어야 한다는 것임
    uv가 언젠가 제공할 수 있는 최종 보너스는 완전히 포장된 결과물이고, 그렇게 되면 매우 좋을 것임. 그 전 단계만으로도 Python으로 만든 명령줄 도구를 사용자에게 제공하는 경험은 더 이상 끔찍하지 않게 될 수 있음. uvx를 쓰거나, 원하면 uv 자체를 완전히 숨길 수도 있음
  • 어디에 무엇을 설치하려는지에 따라 다르지만, 합리적인 배포 대상이라면 보통 그 대상용 설치 가능한 바이너리를 만드는 도구가 있음
    예를 들어 운영체제별 설치 프로그램을 만들어주는 도구가 있고, Android나 iOS, 브라우저처럼 특이한 곳에 배포하는 도구도 생겼음. 당연히 특정 패키지가 특정 대상에서 동작하지 않을 수는 있지만, 표준 인터페이스가 있으므로 코드가 어딘가에서 실행 가능하다면 그 대상용 도구가 동작하는 결과물을 만들어줄 수 있어야 함

• npm의 벤처 투자 기반 러그풀과 Microsoft 인수, 그리고 OpenAI가 법적 비영리 지위도 벤처 투자 경로에 얽힌 리더들에게는 힘없는 마케팅이라는 걸 보여준 뒤로, 핵심 경로에 있는 언어 인프라를 이런 조직에 넘기기는 꺼려짐
  여기에 기여하는 개인들은 각자 훌륭하고 종종 뛰어나지만, 조직 차원의 금전적 이해관계는 시작부터 오염돼 있음. 1~4년이 지나면 중요한 건 조직임. “영웅으로 죽거나, 오래 살아남아 악당이 된다”는 식임
  그래서 빠른 린터, 타입 검사, 코드 스캔, PR 보조 도구는 괜찮고 언제든 바꿀 수 있음. 하지만 설치 흐름과 패키지 저장소는 안 됨
  pip와 conda의 상태를 생각하면 안타깝지만, 현실이 이렇다 봄

  • Python에서는 그 싸움이 이미 졌음
    Microsoft가 Python을 소유하고 있지만 공개적으로 드러내지 않을 뿐이라고 봄
    몇 년 전 kubectl용 Python 바인딩을 만들고 싶었는데, 크로스 플랫폼으로 동작하려면 CGo가 모든 플랫폼에서 Python과 같은 컴파일러를 써야 한다는 걸 알게 됨. 그런데 Windows에서는 CGO가 MINGW를 쓰고 Python은 MSVC를 씀. 당시 존재하던 Python 개발 메일링 리스트에 “오픈소스” 프로젝트가 왜 독점 컴파일러를 쓰는지 물었고, 돌아온 답은 MSVC가 역사적 선택이며 지금은 바꿀 수 없다는 것이었음. Microsoft가 Python Foundation에 CI와 빌드를 돌릴 무료 인프라를 제공하고, Python 인터프리터 작업을 하는 개발자도 제공하기 때문이라는 설명이었음. 즉 Microsoft 직원들이 Microsoft 돈을 받고 Python 인터프리터를 작업하고, 도구 체인에서 Microsoft 도구를 빼지 말라는 지시를 받는다는 뜻이었음
    해마다 상황은 더 나빠졌음. 비슷한 프로젝트들처럼 성공이 별다른 실력 없는 사람들이 권력을 잡을 토양을 만들었고, Python Foundation과 PyPA 같은 주변 프로젝트는 유용한 코드를 기여해서가 아니라 행동 강령 페이지를 쓰면서 자리에 오른 사람들로 채워지기 시작했음. 이 행동 강령과 자리 통제를 둘러싼 끝없는 다툼은 결국 오래된 기여자들이 떠나거나 쫓겨나는 결과로 이어졌고, 최근에는 Tim sort를 만든 Tim이 금지된 일도 있었음
    Microsoft는 손댄 프로젝트마다 하는 일반적인 의제를 계속 밀고 있음. 광고를 위해 쓸모없는 기능을 잔뜩 추가하고, 프로젝트가 온갖 방향으로 흔들리게 하며, 특히 유행을 최대한 따라가게 만드는 것임. 그래서 Python은 완전히 다른 타입 시스템을 가진 언어인데도 머신러닝식 타입을 최대한 추가하고, 네이티브 라이브러리를 동적으로 붙이는 데 절반쯤 쓰이는 언어인데도 사전 컴파일과 JIT에 매달리고 있음. 본질적으로 중괄호 없는 C#으로 만드는 셈임
    Microsoft는 Python 소유를 공개적으로 발표하면 많은 사람이 기술에서 멀어질 걸 알 만큼 영리해서 크게 광고하지 않음. 하지만 개발자들이 자사 도구에 의존하도록 계속 만들고 있고, 언젠가는 그 투자금을 회수하러 올 것임
  • npm은 원래부터 회사 아니었나? 러그풀이 뭐였는지 모르겠고, 실제로 동작을 멈춘 게 있나?
  • PSF와 PyPA가 정신 차리고 Python 패키징에 대해 좋은 이야기를 내놓는 건 얼마든지 환영임
    하지만 지금까지 내놓은 건 본질적으로 “우리가 만든 시스템이 우리를 도움이 되지 못하게 제한하고 있으며, 어쨌든 그건 우리 잘못이 아니다”라는 식의 기여자 블로그 글 수십억 개뿐이었음
    내부 시스템과 내부 정치에 너무 빠져서 자신들이 왜 거기 있는지도 더 이상 모르는 것처럼 보임
    그래서 누군가가 실제로 잘 해내고 Astral처럼 시장을 장악한다면, 그게 바로 커뮤니티인 우리가 받아 마땅한 결과임
    [1]: 여기서 말하는 건 내부 정치임. 이상한 극우식 “DEI 채용!” 난동이 아님

• 이 도구들에는 아직 권위라는 문제가 남아 있음
  PyPA가 승인한 것이 아니라는 점이 cargo와 다름. 동시에 PyPA는 수년 동안 포괄적인 해법을 내놓지 못했고, Python 패키징과 개발 도구는 계속 늘어났음. 불과 3~4년 전만 해도 poetry와 pipenv가 pip+virtualenv로는 해결하지 못한 Python 패키징 문제를 해결하는 것처럼 보였음
  이제 PyPA가 astral.sh 배에 올라타야 한다고 보지만, 일정 수준의 통제권 없이 그렇게 할지는 모르겠음

  • 최근에 알게 됐는데, PyPA의 이름인 Python Packaging Authority에서 Authority는 원래 농담 의도였다고 함: https://discuss.python.org/t/remove-the-authority-from-packa...
  • PyPA가 다른 선택지보다 Pipenv를 승인했을 때부터 PyPA의 추천은 신경 쓰지 않게 됐음
    내가 보기에는 상당 부분 개인적 관계 때문이었고, 당시 Pipenv는 재앙적이었음. 의도는 좋았지만, 회사에서는 널리 쓰이는 의존성이 비교적 적은 저장소에서도 잠금 파일을 갱신하는 데 한 시간을 기다려야 했음. 그냥 동작하지 않았음
    실무적으로 PyPA가 하는 어려운 기술 작업에는 크게 감사함. 하지만 지금 어떤 도구 묶음을 추천하는지는 별로 신경 쓰지 않음. 커뮤니티가 쓰는 걸 쓰고 “공식” 제안은 걱정하지 않는 편이 낫다고 봄
  • 약간 외부 관찰자 입장에서는 PyPA가 실제로 무엇인지 잘 이해되지 않음
    참여자 수가 불분명하고, PyPA가 핵심 Python이나 PSF와 어느 정도 관련이 있는지도 확실하지 않음
    실제로 도움이 될 승인은 핵심 Python 프로젝트 자체에서 나오는 것이라고 봄. 이상적인 세계라면 공식 Python 튜토리얼이 “Python 설치 방법은 이렇다”로 시작하면서 uv 설치부터 안내하고, 공식 Rust 문서가 rustup과 cargo를 가리키는 것과 같아야 함
    PSF가 Astral과 어떤 관계를 구축해서 언젠가 이런 현실이 가능해지길 강하게 바람
  • 솔직히 이 시점에서는 PyPA에 신경 쓰지 않음
    이 맥락에서는 대체로 무관하다는 걸 스스로 증명했다고 봄. 손대는 것마다 썩어가는 것처럼 보여서, 안타깝지만 이 문제에서는 멀리 떨어져 있었으면 함. 이렇게 말하는 게 괴롭고 내 철학에도 어긋나지만, 현재 상태를 반영한 판단일 뿐임. Python으로 10년 동안 풀타임으로 일해왔고, 다른 패키징 생태계들은 사실상 Python을 한 바퀴 이상 앞질렀음
    이제는 “PyPA의 실행 문제인지, 정해진 역할 범위가 잘못된 것인지” 같은 뉘앙스도 신경 쓰지 않음. 그런 논의에 끌려 들어가는 것도 지겨움

• Armin은 uv가 이 영역을 지배하길 옹호하지만, 벤처 투자 기반이라 러그풀될 수 있다는 점도 인정함
  그 잠재적 문제에 대한 해법으로 “포크하기 매우 쉽다”고 말하는데, 포크는 본질적으로 더 큰 파편화를 낳지 않나? 그가 해결하고 싶어 하는 바로 그 문제 말임
  Python 패키징 지형을 지배하려는 도구라면 커뮤니티가 주도하고 커뮤니티가 통제해야 한다고 봄

  • 포크가 본질적으로 더 큰 파편화를 낳는 건 아님
    러그풀된 도구로 일단 통합된 뒤의 파편화 수준이, 통합 전보다 훨씬 낮을 수도 있음
    그리고 이 상상 속 커뮤니티는 훌륭한 지배적 도구를 만들기 위해 앞으로 몇십 년이 더 필요한가?
  • 라이선스 선택이 MIT나 Apache라서 쉽게 포크할 수는 있겠지만, Rust 선택은 실제로 기여할 수 있는 사람 수를 제한함
  • npm도 벤처 투자 기반 아닌가?

• 오늘 아침 회사에서 Poetry의 느림 때문에 우리 소프트웨어를 Poetry에서 uv로 이전하는 걸 살펴봤음
  지금까지는 문서를 많이 읽고 있지만 실제로 진척되는 건 많지 않음. 이전에 Poetry로 옮기는 작업도 내가 했는데, 그때가 훨씬 단순했음. 지금까지 보기엔 Poetry는 다른 패키지 관리자처럼 동작하는 단순한 패키지 관리자를 만들려 했고, uv는 Python 패키지의 광기를 꽤 많이 그대로 유지하는 것 같음

  • 적어도 uv는 Poetry가 virtualenv와 충돌하며 완전한 난장판을 만들지는 않음
    Poetry의 사소한 변경으로 package.toml 형식이 깨지거나, 전이 의존성에는 동작하지 않는 멍청한 “sources” 때문에 여러 인덱스에서 해결 시간이 더 길어지는 일도 없음
  • uv에서 무엇이 어려웠는지 구체적으로 공유할 수 있나?
  • 최근에 pip-tools에서 uv로 옮겼는데 꽤 매끄러웠음
    uv는 사실상 표준 Python 도구 흐름에 그대로 꽂히는 느낌임
  • 지금은 uv가 너무 저수준이라, 아마 Rye를 원한 것 아닌가?
  • 어떤 광기를 말하는 건가?

• 사람들이 이번 차례는 건너뛰고, 2026년판 “Python 패키지 관리자: 이번에는 진짜 해결했습니다!”를 기다리더라도 탓하지 않겠음
  그래도 나는 여전히 만족스러운 Nix 사용자임

• 이 프레이밍이 정말 마음에 듦
  많은 사람이 오랜 시간 점진적으로 쌓아온 작업 덕분에, 이제 한 회사의 몇 명 정도가 중간 정도의 노력으로 상황을 급격히 개선할 수 있는 지점까지 온 것임