▲

PYX: 파이썬 패키징의 다음 단계

 (astral.sh)
14P by GN⁺ 1일전 | ★ favorite | 댓글 3개
  • pyx는 uv 개발팀이 만든 Python 네이티브 패키지 레지스트리로, PyPI·PyTorch·사설 소스 설치 속도를 최대 10배 향상함
  • 기존 패키지 레지스트리 범위를 넘어, 속도·보안·GPU 인식 기능을 제공하며, 내부 패키지와 PyPI·PyTorch 같은 공개 소스 모두 지원
  • 패키지 인기, 생성 시기, 취약점 여부 등 기준으로 필터링 가능한 전용 인덱스 URL을 제공해 보안성과 컴플라이언스를 강화
  • Python에 특화된 최신 표준 지원과 uv와의 직접 통합을 통해 설정 없이 인증과 사용이 가능함
  • 팀 내 중복 빌드, PyTorch·CUDA 설치 난이도, 빌드 깨짐, 인증 불편 등 엔터프라이즈 환경의 주요 문제를 서버-클라이언트 통합으로 해결
  • GPU 인식 기능으로 하드웨어에 맞는 PyTorch, vLLM, FlashAttention, DeepSpeed 등의 사전 빌드 버전을 일관된 메타데이터와 최적 구성으로 제공함
  • 최적화된 아티팩트와 uv 네이티브 메타데이터 API를 통해 다른 사설 레지스트리 대비 월등한 성능을 제공

Astral의 비전과 배경

  • Astral은 Python 생태계를 위한 고성능 개발 도구를 만드는 회사로, Ruff(린터·포매터)와 uv(패키지 매니저)로 잘 알려짐
  • 창업 배경은 Python이 세계에서 가장 인기 있는 프로그래밍 언어임에도 불구하고 툴링 측면에서 충분히 지원받지 못하고 있음을 느꼈기 때문임
  • 현재 Astral 도구 체인은 월 1억 건 이상 설치, uv는 하루 5억 건 이상의 요청을 처리하며 폭발적으로 성장 중임
  • 목표는 Python을 가장 생산적인 프로그래밍 생태계로 만드는 것이며, 이를 위해 클라이언트 도구를 넘어 Python 클라우드를 구축하려 함

pyx 소개

  • pyx는 uv의 최적화된 백엔드로 설계된 Python 네이티브 패키지 레지스트리
    • 내부 패키지 호스팅 가능
    • PyPI, PyTorch 인덱스 같은 공개 소스에 대한 가속·설정 가능 프런트엔드 역할
  • 주요 특징
    • 빠른 설치 속도 : 패키지 설치 및 빌드 최적화
      • PyPI, PyTorch, 내부 프라이빗 소스에서 패키지 설치 시 최적화된 아티팩트와 uv 네이티브 메타데이터 API 활용
      • 타 사설 레지스트리 대비 최대 10배 빠른 속도 제공
    • 보안 및 규정 준수 강화 : 의존성·공급망 이해를 통한 위험 최소화
      • 패키지 필터링을 위한 전용 인덱스 URL 생성 가능
      • 인기, 배포 연령, 취약점 상태 등의 기준으로 패키지 접근 제어
      • 서버 측에서 재현 가능한 빌드 보장
    • 최신 표준 지원
      • Python에 특화된 최신 패키징 표준과 워크플로를 지원
      • uv와 직접 통합돼 별도 설정 없이 원활한 인증 및 사용 가능
    • GPU 인식 패키지 배포 : CUDA·PyTorch 관련 빌드 및 배포 단순화
      • PyTorch, vLLM, FlashAttention, DeepSpeed 등 GPU 관련 라이브러리의 맞춤형 사전 빌드 제공
      • 하드웨어 기반 최적 구성과 일관된 메타데이터 유지

해결하려는 문제

  • PyTorch·CUDA·FlashAttention·DeepSpeed 등 GPU 관련 라이브러리 설치의 어려움
  • 팀 내 동일 패키지의 반복 빌드로 인한 리소스 낭비
  • setuptools 업데이트로 인한 빌드 오류
  • 내부 레지스트리 인증 과정의 불편함

서버-클라이언트 통합 전략

  • uv(클라이언트) 와 pyx(서버) 의 수직 통합으로 위 문제들을 직접 해결
  • pyx 없이 uv만, 또는 uv 없이 pyx만 사용 가능하지만 함께 사용할 때 최고의 경험 제공
  • 오픈소스 도구와의 깊은 통합으로 기존에는 불가능했던 개발 경험 구현 가능

비즈니스 모델

  • uv, Ruff, ty 등 Astral 도구는 영원히 무료·오픈소스·퍼미시브 라이선스 유지
  • 대신 pyx와 같은 유료 호스팅 서비스를 제공해 “다음 단계” 인프라 수요 충족

현재 상태와 향후 계획

  • 현재 Ramp, Intercom, fal과 같은 초기 파트너와 운영 중
  • GA(일반 공개) 전까지 오픈 빌드를 통해 빠른 피드백 루프 유지
  • 관심 있는 팀과 팬들에게 연락 요청
▲
ndrgrd 21시간전  [-]

All python packaging challenges are solved 라니 웃기는 이야기네요
해결된 게 아니라 그냥 돌아만 가게 치워둔 것 아닌가요 ㅋㅋ

파이썬은 전세계에서 사용하는 주류 언어인데 환경이 너무나도 지저분한 게 사실이죠.
해커뉴스 댓글에서는 '기업' 이 나선다고 걱정하지만 기업이 나설 때까지 아무도 신경쓰지 않았기 때문에 상황이 이렇게 됐다는 것은 생각하지 못하네요.

답변달기
▲
aqqnucs 20시간전  [-]

FYI: 해커뉴스 댓글에 누가 한 말을 인용함

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 아마 더 유용한 블로그 글을 공유함 https://astral.sh/blog/introducing-pyx

    • 이 링크가 좀 더 명확한 설명임에도 불구하고, 그들이 해결하려는 문제와 그 해결책의 구체적인 방식이 아직 이해가 잘 되지 않음

  • 모든 파이썬 패키징 문제는 이미 해결되어 있음이라고 생각함. 여기서 배운 교훈은, 모든 문제에 딱 맞는 하나의 솔루션은 없다는 점임. VC 자금이 지원되는 회사들과의 연계를 늘리거나 그들의 인프라에 의존하는 것은 FOSS 커뮤니티에는 항상 큰 리스크임

    • 나는 pip을 사용하라고 들어서 시작했음. 그런데 속도도 느리고 자주 문제가 있었음. 그래서 virtualenv로 갈아탔지만, 이건 문제의 일부만 해결해줌. 그 뒤로 conda를 썼는데, 이건 때때로 잘 돌아갔지만 내 shell 프로필이 엉망이 되었고, 종종 패키지 버전이 꼬이는 일이 많았음. 그 다음엔 pipenv를 추천받았는데, 초기에 좋았지만 개발이 방치되면서 사람이 바뀌고 나서 최신 버전에서 자주 망가짐. 또다시 poetry를 추천받았으나, 너무 느려서 쓸 수가 없었음. 그래서 다시 pip과 내장 venv로 돌아왔지만, 이전에 겪던 문제를 다시 만났고, 기능도 더 부족했음. 그래서 uv로 넘어갔는데, 이건 그나마 제대로 동작했음. 그런데 내가 필요한 의존성은 운영체제별, GPU별로 빌드와 패키징 방식이 달라서, 내 동료들은 이 프로젝트를 자기 랩탑에 설치조차 못함. 파이썬 패키징 문제가 다 "해결"되었다니 정말 다행임

    • "모든 파이썬 패키징 문제는 이미 해결되어 있다"는 주장은 솔직히 모르고 하는 얘기거나 무지함의 소산임. 파이썬은 여전히 다양한 플랫폼에서 네이티브 의존성을 안정적으로 처리할 방법이 없음. pip과 setuptools가 이 생태계의 끝판왕이 되어서는 안 됨

    • 걱정하는 부분에 동의하지만 uv를 쓴 뒤로 엄청난 시간을 세이브했기 때문에, VC 자본의 폐단이 완전히 망가뜨릴 때까지는 계속 쓸 것임. 그쯤 되면 커뮤니티가 한 방향으로 모일 수 있기를 바람

    • 지난 3시간 동안 python과 debian을 맞붙여 처리하다가 파이썬 생태계에 분노가 치솟음. 전혀 해결된 게 아님. Debian에선 venv 사용만 권장하는데, venv에 설치된 패키지는 cmake류 도구가 찾지 못하기 쉬움. apt-get 패키지도 있고, 어떤 도구는 그것만 찾고 다른 것은 또 못 찾기도 함. 패키지 이름도 일관성이 없음. 내 콘솔은 pipx를 추천했는데, 사용 경험은 비슷함. 또 옛날 python 2 vs 3 잔재가 아직도 남아서 버전 번호의 포함 여부 때문에 패키지 탐색 실패가 자주 발생함. c++headerparser가 뭔지 몰라도, 결국에는 파이썬을 빌드 트리에서 빼내고 그냥 역사 속에 묻어두는 것이 맞는 짓이라고 확신하게 됨

    • 혹시 처음 오신 건가요? 여기 이 Kool Aid 한 번 드셔보길 추천함. 유리잔에 박혀 있는 "MongoDB" 로고는 신경 쓰지 않아도 됨. 그건 옛날 것임

  • 오픈 소스 제품을 여러번 믿었다가 상처 받은 경험이 많음. 이런 약속들은 수없이 들어봤음. 언젠간 인수되고, 수년간 쌓인 문서와 이슈, PR이 거의 예고 없이 정리됨. 그리고 새로운 회사가 뭔가 상용 제품을 내놓지만, 내가 쓰던 핵심 기능이 빠져 있기도 함

    • 이런 우려를 이해함에도, pyx는 Astral의 기존 툴과는 다르게 전략적으로 분리시킨 제품임을 강조하고 싶음. 공식 발표에도, "pyx는 Astral의 전략의 실현이자, Astral의 툴들은 앞으로도 무료, 오픈소스, 매우 관대한 라이선스로 영원히 남긴다"고 되어 있음. 우리가 목표로 하는 것은, 오픈소스 툴을 현금화하는 대신, 별도의 상업적으로 지속가능한 상품을 만들어 걱정을 줄이는 것임

    • 완전히 이해되는 걱정임. 그렇지만 Astral의 평판과 실적은 정말 대단하다고 생각함. HN에 이렇게 신중한 반응이 보인 것에 놀랐음. 10년 넘게 파이썬 개발을 해왔는데, Astral이 뭔가 하면 늘 기대하게 됨

    • 진짜 가치있는 기능이라면 pip에 합쳐졌을 거라 생각함

  • PyTorch, CUDA 또는 FlashAttention, DeepSpeed 같은 것 설치가 힘들다는 지적, 매우 공감함. 윈도우(그리고 WSL)에서는, 일부 패키지가 아주 옛날 Visual Studio 버전의 컴파일러를 요구해 번거롭게 직접 다운로드 경로를 찾아야 하는 문제도 있음. 더 좋은 개발 경험을 기다리고 있음

    • 사실 WSL은 거의 리눅스와 비슷하기 때문에, Visual Studio 컴파일러 버전은 별로 중요하지 않다고 생각함. WSL 바이너리는 전부 리눅스 툴체인으로 빌드됨. 윈도우에서도 libc는 Win10 이후로 아주 안정적임. VC++ 2015 이상으로 빌드한 이진파일끼리는 C-ABI 호환성이 유지됨. 예외적으로 특정 언어나 기능을 이전 컴파일러가 지원 안하거나, C++ 객체를 직접 ABI 사이에서 전달하려고 할 때만 오래된 컴파일러가 필요함. 이런 케이스는 드묾

    • 이런 에피소드 때문에 레일즈 덕분에 Ruby에서 완전히 손 뗀 경험이 있음. Ruby 영상 보면 다들 즐겁게 개발하는데 부럽기는 했지만, 내 환경에서는 개발 환경 세팅하려면 DigitalOcean droplet을 써야만 했고, 종종 Rails용 컴파일에서 오류로 망하곤 했음. 2012년쯤 Rails 붐에 동참하고 싶었으나, 설정/설치 과정이 항상 악몽 같았음. 그래서 파이썬으로 넘어갔는데, 초기엔 잘 됐지만 요즘엔 AI나 CUDA 관련이면, 오히려 설치 지옥 때문에 그냥 남의 셸 스크립트를 따라 쓰는 게 낫다고 느끼는 수준임

    • GPU 중심 워크플로우에서는 파이썬 패키징이 이런 방향으로 가야 한다고 생각함. 특히 기대되는 두 가지가 있음. 첫째, 가속기별(예: CUDA/ROCm/CPU 각각) 호환성 검증된 인덱스가 제공되어 torch/cu* 매트릭스 논쟁이 사라지는 것. 둘째, 메타데이터를 클라이언트가 쿼리하여 설치를 병렬화할 수 있게 만드는 것. pyx가 ML 환경에서 하는 ‘pip 시행착오 루프’를 줄이고 하드웨어 타겟 빌드 및 예측 가능한 해시 제공까지 하면, 환경 구성에 들어가는 시간이 엄청 절약될 것임. 또한 도구 자체는 오픈소스로 두고, 호스팅 서비스로 수익을 내는 모델은 신뢰 구축에 긍정적임. pyx가 의존성 그래프, 역의존성(what breaks if X→Y?), SBOM/서명 증명 같은 서플라이체인 체크도 지원할지 궁금함

    • 한때 운영체제라 함은 컴파일러를 내장하는 것이 당연했음

    • 예전에 anaconda를 쓴 결정적 이유가 바로 이런 환경 때문이었음

  • "곧 경쟁하는 Python 패키징 표준이 14개나 생길 것"이라는 유머를 던짐. 사실 14개는 농담이고, 이미 그 이상 생긴 지 오래임

    • 파이썬 패키징에는 표준이 정말 많은데, 지난 10여 년간 생긴 것 중 대다수는 서로 경쟁하지는 않는다는 생각임. 오히려 “쓸만하다 여겨지는 기능이 점진적으로 누적된 결과물”임. 이는 파이썬의 패키징 표준화가 권위주의적이기보다는 합의 기반으로 이뤄진 건강한 프로세스이기 때문임. 만약 권위주의적이었다면 지금같은 파이썬의 성공을 누리진 못했을 거라고 생각함 (참고로 최소 5개 PEP 제안 경험 있음)

  • Python 패키징은 Python에서 가장 Zen(간결함과 심플함 등 파이썬 철학)에 어긋난 부분이라고 생각함

  • 작년 9월, Charlie가 마스토돈에서 이 비즈니스 모델을 구상 중이라고 밝혔음 https://hachyderm.io/@charliermarsh/113103564055291456

  • GPU-aware한 레지스트리가 구체적으로 어떤 의미인지 궁금함. uv가 내 GPU 사양을 확인하고, 거기에 맞는 패키지 세트를 Pyx에서 알아서 뽑아다줄 수 있다는 건지? 이게 기업 고객을 위한 프라이빗, 유료 레지스트리라면, 그런 레지스트리를 회사가 공개 인스턴스 형태로 외부에 제공할 수도 있는지? 즉, 내가 벤더라면 내 패키지들을 위한 Pyx 레지스트리를 유료로 운영하고, 그걸 내 고객에게 엔트리포인트로 쓸 수 있는지 궁금함

    • uv가 이미 이 아이디어의 기본형을 지원하고 있음. 예를 들어 "uv pip install --torch-backend=auto torch" 하면, PyTorch 인덱스에서 내 GPU에 맞는 버전의 PyTorch를 자동으로 설치해줌. pyx는 이를 더 확장한 모델임. PyTorch뿐만 아니라, 각 하드웨어 가속기별로 엄선한 인덱스를 갖고 있고, 이 인덱스엔 다양한 패키지·버전·파이썬 버전·PyTorch 버전 등 빌드된 산출물이 일관된 메타데이터와 함께 준비됨. 즉, pyx를 쓰면 호환성/속도 문제가 잘 맞는 빌드를 쉽게 받을 수 있고, uv 클라이언트도 적합한 pyx 인덱스를 자동으로 찾아줄 수 있음 (이 부분은 pyx를 쓰든 않든 기본적으로 구현됨, 다만 pyx일 땐 훨씬 강력함). 아울러 벤더가 직접 pyx형 레지스트리를 자기 패키지에 맞게 운영하고, 그걸 고객의 엔트리로 제공하는 기능은 아직 정식으론 지원하지 않지만, 구체적으로 관심 있다면 연락하면 논의 가능함

  • 몇 주 전에도 말했지만, 언젠가 Astral은 현금화 전략을 쓸 것임. 핵심은 Uv가 아니라, 보호된 프라이빗 PyPI 같은 형태가 될 것이라고 예상함 https://news.ycombinator.com/item?id=44712558

    • 이 얘기의 요점을 잘 모르겠음. 사실 Charlie Marsh가 작년 9월에 직접 이렇게 설명한 바 있음 - 엔터프라이즈용 프라이빗 패키지 레지스트리 같은 형태가 전략적 예시가 될 수 있다(꼭 이렇게 하진 않더라도 전략 구상을 구체적으로 보여주는 데 쓸 수 있다고 했음). Astral은 비즈니스 모델에 대해 아주 투명함 https://hachyderm.io/@charliermarsh/113103605702842937

    • “현금화”라고 하면 부정적으로 들릴 수 있지만, 이들은 정말 뛰어난 도구를 만들어왔기 때문에, 훨씬 더 많은 문제를 해결해주길 바라는 기업 입장에서는 기꺼이 비용을 지불할 것임

    • uv는 아직 도입하지 않았고, 앞으로 어떤 행보를 보일지 보고 있음. 최근에는 Anaconda 도구 쓰임새도 라이선스 변화 때문에 재검토해야 했고, Qt도 마찬가지였음. 또다른 라이선스 문제를 맞닥뜨릴 생각을 하니 부담스러움

답변달기