프리 스레드 파이썬의 첫 번째 해

11 hours ago 1

프리 스레드 파이썬은 멀티코어 하드웨어를 효율적으로 활용할 수 있도록 설계됨
CPython 3.14에서는 핵심 모듈의 스레드 안전성과 성능이 대폭 개선됨
아직 프리 스레드 빌드를 지원하지 않는 많은 주요 패키지들이 남아있음
누구든 실사용 환경에서의 보고와 커뮤니티 기여를 통해 발전에 함께할 수 있음

개요

지난주 CPython 3.14.0b1이 공개되었고, 이번 주에는 PyCon 2025가 피츠버그에서 시작됨
이 두 가지 이벤트는 프리 스레드 파이썬의 배포와 안정화 측면에서 중요한 이정표임
이 글은 지난 1년간의 과정을 돌아보고, Quansight 팀이 복잡한 의존성을 가진 실제 프로덕션 워크플로우에 프리 스레드 빌드를 실험적으로 적용하는 데 어떻게 핵심 역할을 했는지 설명함

프리 스레드 파이썬의 의미와 필요성

프리 스레드 파이썬 지원은 멀티코어 CPU와 GPU가 보편화된 현대 하드웨어의 전체 연산 자원 활용을 가능하게 함
기존 GIL(글로벌 인터프리터 락) 방식에서는 병렬 알고리듬을 완전히 활용하려면 우회 방법과 별도의 튜닝이 필요했음
보통 threading 모듈보다는 multiprocessing을 사용했으나, 이것은 프로세스 생성 비용이 크고, 데이터 복사도 비효율적임
파이썬 패키지 중 네이티브 코드를 포함하는 경우, 프리 스레드 빌드가 바로 호환되지 않으므로 스레드 안전성 보장을 위해 코드 감사를 반드시 수행해야 함
GIL 해제는 CPython 인터프리터에 깊은 구조적 변화를 필요로 했고, 기존 패키지의 구조적 문제까지 드러내는 계기가 되었음

주요 성과

Meta의 Python 런타임 팀과 함께, 아래와 같은 다양한 패키지와 프로젝트에 프리 스레드 Python 지원을 기여함
- meson, meson-python, setup-python GitHub Actions, packaging, pip, setuptools 등 패키징 및 워크플로우 도구
- Cython, pybind11, f2py, PyO3 등 바인딩 생성기
- NumPy, SciPy, PyArrow, Matplotlib, pandas, scikit-learn, scikit-image 등 PyData 생태계의 핵심 패키지
- Pillow, PyYAML, yarl, multidict, frozenlist 등 PyPI 다운로드 상위 주요 의존성
아직 지원하지 않는 인기 패키지들(CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, grpcio 등)과 머신러닝 라이브러리(safetensors, tokenizers 등)도 점진적으로 작업 중임
Quansight 팀의 CPython 핵심 개발자들은 3.14 버전에 다음과 같은 개선 사항을 반영함
- warnings 모듈이 프리 스레드 빌드에서 기본적으로 스레드 안전하게 동작함
- asyncio의 심각한 스레드 안전성 문제 개선 및 병렬 확장성 증가
- ctypes 모듈에서 스레드 안전성 전면 개선
- 프리 스레드 가비지 컬렉터 성능 향상
- deferred reference counting 스킴 및 적응형 특수화 인터프리터 최적화
- 수많은 버그 수정과 스레드 안전성 보완 진행
프리 스레드 Python 지원을 위한 종합적 가이드1도 작성하여, 앞으로 더 많은 패키지에 실질적으로 참고될 수 있는 문서화를 제공함

프리 스레드 파이썬 생태계 현황

1년 전(3.13.0b1 출시 당시에) 프리 스레드 빌드에서 대부분의 파이썬 패키지 설치가 전면적으로 깨지는 상황이었음
빌드 실패 원인은 근본적인 문제라기보다, 지원되지 않는 기본 옵션이나 작은 가정이 깨졌기 때문임
지난 1년간 커뮤니티와 협력하여 많은 문제를 해결했고, 특히 Cython 3.1.0이 공식 지원되면서 큰 전환점이 됨
아직도 컴파일된 코드를 포함하지만 프리 스레드 휠을 제공하지 않는 패키지들이 남아 있음
이들의 진행 상황은 수동 및 자동 추적 테이블2에서 확인 가능함

당면 과제

현재 프리 스레드 파이썬 빌드는 실제 워크플로우에서의 실험과 피드백이 필요한 단계임
멀티프로세싱 사용 비용이 큰 워크플로우 등에서 특히 성능 개선 가능성이 있지만, 각 패키지에 대한 세밀한 스레드 안정성 감사가 필수적임
많은 라이브러리들이 뮤터블 자료구조를 제공하면서 스레드 안전성 문서화나 실제 안전 보장이 미흡함
패키지 규모가 크고 레거시가 많은 경우, 코드를 완전하게 파악할 수 있는 사람이 부족해 지원이 늦어지는 현상 발생
커뮤니티 차원에서 핵심 패키지 유지관리의 지속 가능성을 위한 노력이 필요함