PEP 779 – 프리 스레드 Python의 지원 상태 기준

Author:: Thomas Wouters <thomas at python.org>, Matt Page <mpage at python.org>, Sam Gross <colesbury at gmail.com>
Discussions-To:: Discourse thread
Status:: Final
Type:: Standards Track
Created:: 13-Mar-2025
Python-Version:: 3.14
Post-History:: 13-Mar-2025
Resolution:: 16-Jun-2025

Table of Contents

초록
동기
근거
명세입니다.
미해결 문제입니다.
각주입니다.
Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

Note

Steering Council은 2단계에서 다루어야 할 요구 사항을 망라하지 않은 목록과 함께 PEP 779를 승인합니다. 자세한 내용은 acceptance를 참조하십시오.

초록

Steering Council이 발표한PEP 703(PEP 703의 전역 인터프리터 잠금을 CPython에서 선택 사항으로 만들기) 승인은 전역 인터프리터 잠금을 제거하는 작업의 세 가지 개발 단계를 설명합니다. 1단계는 Python 3.13 개발 초기에 시작되었으며, 프리 스레드(GIL이 없는) Python 빌드를 사용할 수 있게 하되 명시적으로 실험적으로 지정하는 작업을 포함합니다. 2단계에서는 프리 스레드 빌드를 공식적으로 지원하지만 여전히 선택 사항으로 만들고, 3단계에서는 프리 스레드 빌드를 기본값으로 만듭니다. 당시에는 알려지지 않은 사항이 많았기 때문에 다음 단계로 이동하기 위한 기준은 의도적으로 모호하게 남겨 두었습니다. 이 PEP는 프리 스레드 Python 빌드를 공식적으로 지원하도록 하여 2단계로 이동하기 위한 명확한 기대 사항과 요구 사항을 수립합니다.

Note

주의 깊은 독자라면 PEP 703 승인 당시 이 PEP의 저자와 Steering Council 구성원 사이에 일부 중복이 있었다는 점을 알아차렸을 수 있습니다. 이후 SC의 구성은 변경되었지만, 명확히 하자면 SC가 제시한 기준에 기반한 이 제안 PEP는 Steering Council 자체에서 나온 것이 아닙니다.

동기

관련 PEP 703을 추진할지 여부(궁극적으로 이를 기본값으로 지정하는 것 포함)는 비용이 이점보다 큰지에 관한 문제입니다. 프리 스레드 Python을 공식적으로 지원되는 빌드로 만드는 것은 설계가 최종 확정되고 API가 사용 가능하며 안정적이고, 성능 및 복잡성 비용이 감당할 수 없을 정도로 크지 않다고 판단하는 단계에 도달했음을 알리는 데 중요합니다.

“공식적으로 지원되는” 단계로 이동하는 것은 프리 스레드 Python을 기본 빌드로 만들고 궁극적으로 유일한 빌드로 만드는 데 중요한 단계입니다. 이를 기본값으로 만들 준비가 되었다고 결정하기 전에 비용과 이점에 대해 훨씬 더 정확히 파악해야 하며, 더 많은 Python 생태계가 프리 스레드 Python을 지원하기 시작해야만 그 단계에 도달할 수 있습니다. 현재 PEP 703를 지원하는 패키지와 도구는 충분하여 우리가 올바른 방향으로 가고 있음은 분명하지만, 최종 결정을 내리기에는 충분하지 않습니다. Python 커뮤니티가 프리 스레드 Python을 지원하는 데 필요한 변경을 수행할 시간을 제공하는 것과 더불어, 2단계를 통해 실제 애플리케이션에서 명확한 이점을 보여 주고 성능, 지원 부담 및 생태계 복잡성 측면의 비용을 명확히 정의할 수 있을 것으로 기대합니다.

근거

PEP 703이 받아들여지려면 바람직하고 안정적이며 유지 관리 가능하고 성능이 우수해야 하며(CPU 및 메모리 측면에서), 이상적으로는 안정적인 ABI를 갖추어 프리 스레드 빌드와 GIL 사용 빌드에서 동일한 휠을 사용할 수 있어야 합니다.

바람직성: 다양한 실험을 통해 프리 스레드 Python이 엄청난 잠재적 이점을 가진다는 점은 매우 분명합니다. 이는 단순한 드롭인 솔루션이 아니므로 새로운 기능을 최대한 활용하고 성능상의 함정을 피하려면 일부 코드를 재설계해야 하지만, 이를 적극적으로 활용하면 더 높은 성능과 현저히 낮은 지연 시간, 새로운 스레드 기반 기능을 구현할 수 있습니다.
안정성: 새로운 API 설계의 대부분은 3.13에 포함되어 있으며, 여러 서드파티 패키지에서 자유 스레드 Python을 지원하는 데 성공적으로 사용되고 있습니다(예를 들어 https://py-free-threading.github.io/tracking/ 참조). 3.14에서는 더 많은 편의 함수를 추가하고 이전에 스레드 안전성을 위해 GIL에 의존했던 API를 대체하는 개발이 추가로 진행되었지만, 프리 스레드 Python을 위해 3.13 API를 변경해야 했던 적은 없습니다.
유지 관리 가능성: PEP 703의 설계 대부분은 비교적 단순하며, 복잡성의 대부분은 CPython의 기존 C API 뒤에 숨겨져 있습니다. 예를 들어 잠금 없는 리스트 및 딕셔너리 API( which rely on QSBR 및 deadlock-avoiding critical sections),의 구현 세부 사항은 복잡하고 올바르게 구현하기 어려울 수 있지만, 지나치게 많은 함정 없이 사용하기 쉬운 API를 제공합니다. CPython의 더 많은 부분을 프리 스레딩에 안전하게 만드는 과정은 비교적 간단하지만, 새로운 API가 제공하는 기본적인 보장에 관한 문서(https://github.com/python/cpython/issues/128642)가 더 필요할 가능성이 큽니다.
성능: pyperformance 벤치마크로 측정한 프리 스레드 빌드와 GIL 사용 빌드 간 선형 성능의 성능 저하는 현재 약 10%입니다(예를 들어 Microsoft’s Faster CPython team에서 실행하거나 Meta’s Python Runtime team에서 실행한 결과 기준이며, macOS에서는 약 3%에 가깝습니다). Linux와 Windows에서 10%를 충분히 밑돌 수 있도록 하는 PR이 몇 개 더 진행 중입니다.
메모리 사용량입니다. gc 모듈 구현이 서로 다르므로 정확한 수치는 달라지지만, 현재 자유 스레드 Python은 약 15~20% 더 높은 메모리 사용량을 보입니다 (pyperformance로 측정한 기하 평균입니다). 아직 이를 낮추기 위해 많은 시간을 들이지 않았으므로, 이를 더 낮출 수 있을지도 모릅니다. 하지만 현실적으로 더 높은 메모리 사용량은 효율적이고 안전한 자유 스레딩을 구현하는 대가이며, 상당한 성능 비용 없이는 이를 GIL 사용 빌드의 메모리 사용량에 매우 가깝게 낮추기는 어려울 것입니다.
Stable ABI입니다. Steering Council은 Stable ABI 지원을 2단계의 잠재적인 요구 사항으로 언급했습니다. Stable ABI를 지원하면 서드파티 패키지 배포가 훨씬 쉬워지겠지만, 닭과 달걀 문제도 약간 있습니다. Stable ABI를 사용하여 자유 스레드 Python을 지원하는 패키지가 없다면 Stable ABI가 충분히 좋은지 알 수 없으며, 문제가 발견되더라도 Stable ABI에서 관련 항목을 제거할 수 없습니다. 2단계는 커뮤니티가 자유 스레드 Python을 도입하고 API와 ABI에 대한 피드백을 제공할 시간을 주기 위한 것이므로, 2단계에서 Stable ABI가 얼마나 강한 요구 사항이어야 하는지는 확신하지 못합니다.

명세입니다.

저희가 제안하는, 자유 스레드 Python을 공식적으로 지원하기 위한 구체적인 기준(2단계)은 다음과 같습니다.

허용 가능한 성능입니다. Steering Council은 자유 스레드 Python이 약 10~15% 더 느릴 것으로 예상한다고 언급했지만, 이는 엄격한 목표는 아니었습니다. 현재 약 10% 수준이며 더 느려질 것으로 예상하지 않지만, 기본값 전환이 아닌 2단계에서는 15%를 엄격한 성능 목표로 제안합니다.
허용 가능한 메모리 사용량입니다. 이는 Steering Council이 언급하지 않았으며, 많은 논의도 이루어지지 않았습니다. 2단계의 목표로 20%(pyperformance로 측정한 기하 평균)를 제안합니다. 3단계에서는 메모리와 CPU 성능 간의 절충점이 어디에 도달해야 하는지에 대해 커뮤니티의 의견이 필요합니다.
입증된 안정적인 API입니다. 이는 측정하기 어려운 요소이지만, 기존 API를 사용하는 자유 스레드 Python이 상당히 도입되었으며, 이를 수용하기 위해 기존 API를 근본적으로 변경할 필요는 없었습니다. 앞으로 특정 사용 사례를 위한 편의 API를 더 추가하게 될 가능성이 높지만, 현재 API의 실현 가능성과 안정성은 입증되었다고 생각합니다. 새로운 API에서 호환성을 깨뜨리는 변경이 필요했던 적은 없으며, 앞으로의 모든 변경 사항도 PEP 387의 변경 정책을 따를 것으로 예상합니다.
내부 문서입니다. 여러 핵심 개발자가 자유 스레드 Python을 작업하고 있으며, 여기에는 최근 특정 모듈의 스레드 안전성 문제를 해결하기 시작한 개발자도 여러 명 포함되어 있습니다. 하지만 자유 스레드 Python 내부에 대한 입문 문서는 보강할 필요가 있을 것입니다. 3.14에서 이를 달성하는 것은 문제가 되지 않을 것입니다.

이러한 기준을 충족한다면 Python 3.14가 PEP 703의 2단계에 적절한 시기라고 생각합니다.

(이는 오직 2단계에 진입하기 위한 요구 사항이라는 점에 유의하십시오. 자유 스레드 Python을 기본값으로 만드는 결정(3단계)은 매우 다르며, 커뮤니티의 지원과 의지, 그리고 명확한 이점의 입증을 중심으로 이루어질 것으로 예상합니다. 이는 향후 PEP에서 다룰 내용으로 남겨 둡니다.)

미해결 문제입니다.

Stable ABI가 자유 스레드 빌드의 “지원됨” 상태를 위한 강력한 요구 사항이어야 합니까?

각주입니다.

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.