[PyCon KR 2025] AI 시대를 위한 Python 패키징

Transcript

1. AI 시대를 위한 Python 패키징 WheelNext 프로젝트와 함께 알아보는 차세대 패키징 규격 김준기 래블업 주식회사
2. Table of Contents 현행 wheel 규격 Wheel 파일 형식과 platform tag에 대하여 Python Package Index (PyPI) 01 WheelNext 워킹그룹 결성 계기 주요 Agenda 소개 variantlib 톺아보기 02 워크샵 활동 WheelNext 워크샵 @ GTC 2025 온라인 Monthly Update Packaging Summit @ PyCon US 2025 03 정리 04
3. 자기소개 󰗞 오픈소스 기반 시스템 프로그래머 & 연구자 & 창업자 ➔ PyCon KR/APAC/US/JP/… 발표 ➔ 래블업 공동창업 (2015년) ➔ 주요 Python 키워드 wheelnext, aiotools, aiomonitor, aiodocker, aiohttp, asyncio, C/C++, Rust, C# ➔ 주요 개발 키워드 NeoVim, Zed, WezTerm, 한글 iPuTTY
4. 현행 wheel 규격 크로스 플랫폼 패키징을 향한 노력 01
5. Python Wheel 규격 간략한 역사 Source : ChatGPT와 함께 PyPA, PEP, 메일링 리스트 등 정리 https://packaging.python.org/en/latest/discussions/ https://www.pypa.io/en/latest/history/ 연도 주요 사건 & 제안 배경·의의 1998 ‒ 2000 distutils 표준 라이브러리 (Greg Ward) → Python 2.0에 포함 (Python 3.12에서 제거) • setup.py sdist로 소스 배포만 가능 • 바이너리 배포·의존성 관리 기능 부족 2004 ‒ 2008 setuptools / easy_install (Phillip Eby) → .egg 형식 도입 • import-time zip-import 덕분에 “설치 없이” 로드 가능 • 이슈 : 플랫폼·ABI 태그 부재, script entry point 처리 문제, namespace 미지원 2008 ‒ 2011 Packaging Summit (PyCon 2008) → Distutils-SIG PEP 345 (메타데이터 1.2), PEP 376 (설치 레코드), PEP 386 (버전 규칙) 등 • “egg의 한계 + 서로 다른 빌드·배포 파편화” 해결 필요성 확인 • Python Packaging Authority (PyPA) 결성, distutils2 실험(결국 폐기) 2012 Wheel 규격 제안 (Daniel Holth) → PEP 425 (호환 태그), PEP 427 (wheel 1.0), PEP 426 (메타데이터 1.3, 이후 Core Metadata로 발전) 채택 주요 개발목표 (1) OS/ABI/파이썬 버전별 호환 태그로 정확한 바이너리 제공 (2) 단순 파일 복사만으로 빠른 설치 (3) zip-safe 포맷이지만 import-time hack 없음 (egg 대비 개선) (4) 설치 기록은 PEP 376 표준으로 통합 2013 wheel 0.9‒1.0 릴리즈 → pip install <pkg>.whl 지원 (pip 1.4), setup.py bdist_wheel 커맨드 보급 • Linux binary 문제를 해결하기 위해 곧이어 manylinux 제안 논의 시작 2014 ‒ 2016 PEP 425 Platform Tags 확대, PEP 513 (manylinux1), PEP 571 (manylinux2010) 등 • 리눅스 배포판 간 glibc 호환 계층 정의 → Wheel이 C-extension 생태계의 기본 배포 형식으로 자리잡음
6. ⬝ zip 형식의 압축 파일로 구성 ⬝ METADATA: 패키지의 이름, 버전, 의존성 등 (PEP 566, email-like format) ⬝ WHEEL: Wheel 포맷 버전, 생성자 정보, 구현체 태그 등 ⬝ RECORD: 모든 파일 목록 + 해시값 + 크기 (서명 가능) ⬝ entry_points.txt: 콘솔 스크립트 등 entry point 정의 ⬝ top_level.txt: top-level import 가능한 패키지 목록 Python Wheel 규격 파일 내부 구조 PEP 427: Python 패키지의 binary distribution format (.whl) Source : https://peps.python.org/pep-0427/ package_name/ __init__.py ... package_name-1.0.0.dist-info/ METADATA WHEEL RECORD top_level.txt (optional) entry_points.txt (optional) ...
7. Python Wheel 규격 Platform Tag 형식 PEP 425: 호환성을 확인하기 위한 플랫폼 태그 형식 ⬝ Python tag: 지원하는 인터프리터 (cp313, py3 등) ⬝ ABI tag: ABI 호환성 (cp313, abi3, none) ⬝ Platform tag: 운영체제 및 아키텍처 ⬝ 순수 Python: any ‒ Linux 예시: manylinux2014_x86_64, musllinux_1_1_x86_64, manylinux_2_28_aarch64 ‒ macOS 예시: macosx_10_9_x86_64, macosx_10_15_universal2 ‒ Windows 예시: win_amd64, win32 Source : https://peps.python.org/pep-0425/ {distribution}-{version}(-{build_tag})?-{python_tag}-{abi_tag}-{platform_tag}.whl
8. Python Package Index wheel을 배포하기 위한 중앙 저장소 Source : https://www.pypa.io/en/latest/ 역사 ⬝ 2002년 “Cheese Shop” — Richard Jones, Juergen Hermann가 CPAN과 유사한 Python 패키지 공유 공간으로 시작 ⬝ 2003 ~ 2005년 PEP 301, PEP 314로 메타데이터 포맷 표준화 → 자동 설치 도구(easy_install) 등장 ⬝ 2016년 warehouse 프로젝트로 전면 재작성 → 2018년 공식 서비스 전환 주요 기능 ⬝ 패키지 업로드·배포 ‒ twine upload, Trusted Publisher (OIDC) 등의 배포자 인증 방식 지원 ‒ Yanked Release, Project Transfer 기능으로 릴리즈 관리 ⬝ 메타데이터·검색 API ‒ Simple API (PEP 503) : 경량 인덱스, 모든 Python 클라이언트 호환 ‒ JSON & XML-RPC : 상세 메타데이터·통계 조회 ‒ PEP-658 : requires_dist 등 의존성 미리 노출해 설치 최적화
9. WheelNext 워킹그룹 “Reinventing the wheel” 02
10. Source : https://wheelnext.dev/ WheelNext 워킹그룹 주요 Agenda 2025년 7월 기준 주요 agenda ⬝ How to reinvent the wheel (PEP 777) ‒ Wheel 2.0 등 호환성 깨지는 포맷 변화를 안전히 도입하기 위한 규칙(Wheel-Version 필드, .whlx 확장자 등) 마련 ⬝ Wheel Variants ‒ GPU 드라이버·CPU ISA 등 하드웨어 특화 속성을 갖는 여러 Variant Wheel을 배포하고, 플러그인이 시스템 특성을 감지해 최적 wheel을 자동 선택 ‒ 해시 기반 식별·Provider Plugin 체계로 태그 폭발 없이 세분화된 호환성 표현을 가능케 해 사용자·배포자 관리 부담 감소 ⬝ Index Prioritization (PEP 766) ‒ 다중 인덱스 사용 시 버전 우선과 인덱스 우선 두 해석 모드를 명확히 정의해 pip와 uv 동작 차이 해소 ‒ “회사 내부 인덱스 → PyPI” 같은 우선순위를 선언 가능하게 만들어 예측 가능한 패키지 의존성 해결 동작과 보안 정책 지원 ⬝ Native Library Loader ‒ 여러 wheel이 공유하는 OpenBLAS 등 native library를 중복 적재하지 않고 공통 로더로 안전하게 로드·버전 협상하도록 표준화 ‒ importlib 유사 고수준 API로 플랫폼별 로딩·RPATH 문제를 통일, 패키지 크기·메모리 사용 감소와 보안 검사 일원화 ⬝ Default Extra (PEP 771) ‒ 사용자가 extras를 명시하지 않을 때 패키지가 권장 extras 집합을 기본으로 자동 설치하도록 하여 사용자 경험 개선 ⬝ Build Isolation Passthrough ‒ 빌드 격리 환경에 호스트의 컴파일러·헤더·라이브러리 등을 선택적으로 패스스루해 CUDA·Rust 등 ABI 의존 패키지의 빌드 실패를 줄이자는 제안
11. Source : https://wheelnext.dev/ WheelNext 워킹그룹 “Reinventing” the wheel format (PEP 777) 문제 인식 ⬝ 현재 wheel 포맷(1.0)은 10년 이상 사용되어 새로운 기능을 수용하면서도 구형 도구를 위한 하위호환 고려 필요 제안하는 해결 방법 ⬝ Wheel-Version 필드 도입: METADATA 파일에 Wheel 버전을 명시하여, 설치 도구가 호환성을 사전에 판단할 수 있도록 함 ⬝ 파일 확장자 변경: 향후 Wheel 2.0 이상은 .whl 대신 .whlx 확장자를 사용하여, 구형 도구가 새로운 포맷을 무시하도록 유도 ⬝ 설치 도구 및 해석기(resolver) 동작: 호환되지 않는 Wheel 버전은 설치 대상에서 제외한 후 사용자에게 경고 ⬝ 기존 pip 및 패키지 설치 도구와의 하위호환성을 유지하기 위한 조건들 ‒ importlib.metadata와의 호환성 유지 ‒ ZIP 포맷 유지 및 .dist-info 디렉토리는 압축 없이 루트에 위치 ‒ 표준 라이브러리에 포함된 압축 포맷만 사용 ⬝ 기대 효과 ‒ Wheel 포맷의 진화를 위한 기반 마련 ‒ 설치 도구의 안정성과 사용자 경험 향상 ‒ 다양한 플랫폼 및 하드웨어 지원을 위한 확장성 확보
12. Source : https://wheelnext.dev/ WheelNext 워킹그룹 Index Prioritization (PEP 766) 문제 인식 ⬝ pip과 uv 등 Python 패키지 설치 도구들이 다중 인덱스를 처리하는 방식이 서로 달라 예기치 않은 결과 발생 ⬝ 두 가지 우선순위 모델 존재 ‒ Version Priority: 모든 인덱스를 병합하여 가장 적합한 버전 선택 ‒ Index Priority: 인덱스 우선순위에 따라 순차적으로 먼저 발견된 패키지를 선택 ⬝ Index Priority의 장점 ‒ 명시적인 index 우선순위를 클라이언트 도구가 일관되게 설정·적용 ‒ 예기치 않은 업데이트를 방지하고 예측 가능한 설치 결과 제공 제안하는 해결 방법 ⬝ pip, uv 업데이트: 명시적인 index priority를 고려하도록 기본 메커니즘 적용 ⬝ 도입 고려사항 ‒ 캐시 및 잠금 파일(lockfile) 시스템의 변경 필요 ‒ 인덱스 그룹 및 우선순위 설정을 위한 사용자 정의 구성 지원 필요 ⬝ 기대 효과 ‒ 보안 강화: 명시적으로 Index Priority는 사용자가 인덱스 간의 신뢰 계층을 명시할 수 있게 하여 의존성 혼동 공격을 제한
13. Source : https://wheelnext.dev/ WheelNext 워킹그룹 Variant support 문제 인식 ⬝ 현행 wheel 포맷은 다양한 하드웨어 및 플랫폼 요구사항을 충족하기에 부족하여, 플랫폼 특화 패키지 배포를 위한 체계적인 메커니즘 도입 필요 제안하는 해결 방법 ⬝ variantlib 개발 + pip 업데이트 ‒ Wheel Variant 시스템: 동일한 패키지 버전에 대해 하드웨어 특화된 여러 Wheel을 구분하여 제공 ‒ Provider Plugin: 설치 시 플랫폼 속성을 동적으로 감지하여 최적의 Wheel Variant를 추천 ‒ 해시 기반 식별자: Wheel 파일명에 해시를 추가하여 명확한 변형 구분 및 호환성 유지 ⬝ 기대 효과 ‒ 설치 도구의 변경 없이도 다양한 하드웨어에 최적화된 패키지 제공 가능 ‒ 패키지 유지보수자의 부담 최소화 및 생태계의 일관성 유지 python -m build ... auditwheel repair ... variantlib make-variant ... python3 -m pip install \ pep-xxx-wheel-variants variant-aware PyPI (or MockHouse) pip install ... twine upload ...
14. Source : https://wheelnext.dev/, 직접 작성한 variantlib 반영 빌드 스크립트 WheelNext 워킹그룹 Variant support variantlib ⬝ 실제로 확장 플랫폼 태그를 포함시켜주는 wheel 파일 빌드 도구 ‒ 이미 빌드된 .whl 파일에 variants.json 파일을 추가하고 variant 속성 목록으로부터 해시값을 계산하여 파일명의 플랫폼 태그 뒤에 붙여줌 ‒ 빌드 과정 자체에 개입하지 않고 결과물의 태그만 업데이트하므로 기존 빌드 파이프라인을 거의 그대로 활용할 수 있음 https://www.youtube.com/watch?v=1Oki8vAWb1Q
15. Source : https://wheelnext.dev/ WheelNext 워킹그룹 Variant support pip 확장 구현 ⬝ 해시 형태로 된 variant tag를 인식하면 pypi에서 variants.json 인덱스 파일을 먼저 다운로드하고, 해시값이 가리키는 property 값들을 가져옴 ‒ Provider plugin들이 제공하는 property 목록과 대조하여 현재 시스템에 가장 최적의 wheel을 선택하여 다운로드하고 설치 https://www.youtube.com/watch?v=1Oki8vAWb1Q
16. 워크샵 활동 커뮤니티가 일하는 과정 03
17. Source : 직접 촬영 WheelNext Summit 2025 2025년 3월 21일 @ Meta 먼로파크 오피스 1부 ‒ Case Sharing & 주요 Agenda 초안 제안자 설명 세션 ⬝ 주요 커뮤니티·기업별 case sharing 세션 ‒ PyTorch: 패키지 크기가 너무 커지는 문제, default extras, symlink ‒ Jax: C++ wheel 관련 표준 필요성, extra 패키지들이 main 패키지 업데이트 시 함께 업데이트되지 않는 문제 ‒ Quansight: SIMD 관련 플랫폼 태깅 필요성, native 모듈 위한 build backend 지원 ‒ RedHat: 보안 상 모든 wheel을 직접 소스 빌드하는데 sdist만으론 부족 (임의로 커스터마이징해둔 빌드 스크립트들과 본인들이 강제하는 빌드 환경과의 충돌 등), Bazel/buck 같은 hermetic sandbox 내에 CUDA를 넣기 어려운 점 ‒ AMD: zip 압축 방식은 GPU나 개발용 라이브러리에서 효율이 나쁨 ‒ Astral: vLLM-PyTorch 버전 강결합 이슈, 가속기 하드웨어 의존성 표기방법 필요 ‒ Anaconda: CPU instruction set (AVX2, SSE4.2 등) 의존성 표기방법 필요, sigstore나 attestation 같은 보안 검증 기능 필요성 ‒ GPU Mode: AOT vs. JIT, PyTorch와 써드파티 C++ 코드 결합 이슈
18. Source : 직접 촬영 WheelNext Summit 2025 2025년 3월 21일 @ Meta 먼로파크 오피스 1부 ‒ Case Sharing & 주요 Agenda 초안 제안자 설명 세션 ⬝ Wheel variants ⬝ Index priority ⬝ Symlink support & reinventing the wheel 2부 ‒ Wheel variants, index priority 두 주제에 대한 소그룹 토의 ⬝ 화이트보드와 함께 자유롭게 질의응답 및 아이디어 제안 토의 진행 ⬝ Wheel Variants ‒ provider 간의 우선순위 이슈 (여러 개의 provider가 동시에 동일한 provider identifier를 지원한다고 주장하면 어떻게 할 것인가?) ‒ requirements.txt나 lock 파일에서 variantlib tag를 어떻게 표현할 것인가? 참고 자료 https://wheelnext.dev/summits/2025_03/slidedecks_and_resources/
19. Source : 직접 촬영 WheelNext Monthly Update 2025년 5월 1일 @ 온라인 미팅 다가오는 PyCon US 발표 및 Packaging Summit 관련 내용 사전 공유 ⬝ variantlib으로 태깅된 whl 파일들 서빙하는 MockHouse 프로젝트 공개 ‒ https://mockhouse.wheelnext.dev/ ⬝ provider 플러그인이 현재 시스템 스캔하여 태그 집합 생성하는 기능 추가 ⬝ 사용자가 variants.toml 파일을 통해 feature 간 우선순위 정의할 수 있도록 확장 래블업 건의사항 ⬝ PBS (python-build-standalone) 프로젝트에서 호환성 때문에 일부러 과거 kernel 버전을 기준으로 빌드하는 바람에 최신 syscall (예: pidfd_open() 등) 못 쓰는 문제를 해결할 수 있도록 weak symbol을 도입할 필요가 있음 ⬝ CUDA 런타임 버전뿐만 아니라 NVIDIA Driver 버전도 매칭할 수 있으면 좋겠음 (NVML API를 직접 사용하는 경우 고려) ⬝ 일관된 방법으로 C/C++ symbol 버전 충돌 문제를 피할 수 있는 native library loader 규격도 정의할 필요가 있음 참고 자료 https://wheelnext.dev/slidedecks_resources/
20. Source : 직접 촬영 Packaging Summit 2025년 5월 18일 @ PyCon US 세션 발표 ⬝ PEP 13에 따른 governance 체계를 PyPA에 도입 ⬝ 3.14부터 모바일 환경 CPython 구현체들을 Tier 2로 상향 / wheel variants 등 자유 발제 ⬝ Vendored package가 있는 경우 라이선스 다중 표기 가능하게 하는 옵션 ⬝ “Partial” dynamic metadata ⬝ SBOM 뽑아내기 위해 빌드 VM 자체를 감싸는 네트워크 프록시 샌드박스 구축 ⬝ PyTorch + vLLM 제발 어떻게 좀 쉽게 배포할 수 있을 것인가... ⬝ pyodied + emscripten 기반 wasm 빌드에 대한 플랫폼 태그 정의를 pip, uv에 반영하기 ⬝ 직접 발제한 내용:
21. 정리 04
22. Source : https://wheelnext.dev/ WheelNext 참여 소감 커뮤니티와 표준화 기대 ⬝ 향후 1~2년 내로 CUDA 및 다양한 가속기 하드웨어에 특화된 wheel 설치 과정이 pip install 하나로 해결되는 날이 올 수 있을까? 워킹그룹 구도 ⬝ Python Packaging Authority 산하 SIG 형식이지만 실질적으로는 Meta와 NVIDIA가 주도 ‒ 본인들도 이 사실을 잘 인지하고 있고, 그래서 더욱 적극적으로 다양한 목소리를 들을 기회를 마련 노력 ⬝ 아무래도 full-time으로 이 일을 본인 업무로 삼아서 진행하는 사람의 존재 유무가 추진력에 큰 차이를 가져옴 느낀 점 ⬝ 실리콘밸리 빅테크들이 어떻게 ‘표준화’라는 주제를 다루는지 경험할 기회 ⬝ 우리나라가 AI 시장에서 할 수 있는 일이 전세계 기준으로 굉장히 큰 편이라, 한국 오픈소스 커뮤니티에서도 이런 논의에 좀더 적극 참여 필요 ‒ 중국·미국하고만 비교하면 아쉬워보이지만 AI 반도체부터 응용 서비스까지 모든 스택을 개발·상용화 가능한 몇 안 되는 나라 ⬝ Right place, right time에 가서 이야기하는 것의 중요성 ‒ 똑같은 아이디어라도, Packaging Summit에 직접 참가하여 대면으로 이야기하기 vs. discuss.python.org에 글로만 적기
23. 김준기 래블업 주식회사 감사합니다 :D
24. 김준기 래블업 주식회사 질문 있으시면 편하게 해주세요 :D