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

운영 위원회는 2단계 동안 해결해야 할 요구 사항 목록(전체 목록은 아님)과 함께 PEP 779를 수락합니다. 자세한 내용은 수락 공지를 참조하십시오.

초록

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

Note

눈썰미 좋은 독자라면 이 PEP의 저자와 PEP 703 수락 당시의 운영 위원회 구성원이 겹친다는 것을 눈치챘을 것입니다. 그 이후 운영 위원회의 구성은 바뀌었지만, 명확히 해 두자면, 제안된 이 PEP는 운영 위원회가 제시한 기준에 바탕을 두고 있으나 운영 위원회 자체에서 나온 것이 아닙니다.

동기

PEP 703을 계속 진행할지(그리고 궁극적으로 이를 기본값으로 만들지)는 비용이 이점보다 큰지의 문제입니다. 자유 스레드 Python을 공식 지원 빌드로 만드는 것은 이제 설계가 확정되었고, API를 사용할 수 있으며 안정적이고, 성능 및 복잡성 비용이 감당하지 못할 수준이 아니라고 확신하는 단계에 이르렀음을 알리는 데 중요합니다.

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

근거

PEP 703이 수용 가능하려면 바람직하고, 안정적이며, 유지 관리가 가능하고, (CPU와 메모리 측면에서) 성능이 좋아야 하며, 이상적으로는 자유 스레드 빌드와 GIL 포함 빌드에서 같은 휠을 사용할 수 있도록 안정 ABI를 갖추어야 합니다.

바람직성: 여러 실험을 통해 자유 스레드 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 뒤에 감춰져 있습니다. 예를 들어 QSBR에 의존하는 락 없는 리스트 및 딕셔너리 API와 교착 상태를 회피하는 임계 구역의 구현 세부 사항은 복잡하고 올바르게 만들기 어려울 수 있지만, 함정이 많지 않고 사용하기 쉬운 API를 제공합니다. CPython의 더 많은 부분을 자유 스레딩에 안전하게 만드는 것은 비교적 간단한 과정이지만, 새로운 API가 제공하는 기본 보장에 대한 문서는 아마도 더 필요할 것입니다(https://github.com/python/cpython/issues/128642).
성능: pyperformance 벤치마크로 측정한(예를 들어 Microsoft’s Faster CPython team이나 Meta’s Python Runtime team이 실행한 것처럼) 자유 스레드 빌드와 GIL 포함 빌드 간의 선형 성능 저하는 현재 약 10%입니다(macOS는 예외로, 3%에 가깝습니다). 진행 중인 PR이 몇 개 더 있으며, 이들이 반영되면 Linux와 Windows에서 10%보다 넉넉히 낮아질 것입니다.
메모리 사용량. gc 모듈의 구현이 다르므로 정확한 수치는 달라지지만, 현재 자유 스레드 Python의 메모리 사용량은 약 15-20% 더 높습니다(pyperformance로 측정한 기하 평균 기준). 아직 이를 낮추는 데 많은 시간을 들이지 않았으므로, 앞으로 더 낮출 수 있을지도 모릅니다. 하지만 현실적으로 보면, 더 높은 메모리 사용량은 효율적이고 안전한 자유 스레딩을 위해 치러야 하는 비용이며, 상당한 성능 손실 없이 GIL 사용 빌드의 메모리 사용량에 아주 가깝게 줄이기는 어려울 것입니다.
안정 ABI. 운영 위원회는 안정 ABI 지원을 2단계의 잠재적 요구 사항으로 언급했습니다. 안정 ABI를 지원하면 서드파티 패키지 배포가 훨씬 쉬워지겠지만, 닭이 먼저냐 달걀이 먼저냐 하는 문제가 다소 있습니다. 안정 ABI를 사용해 자유 스레드 Python을 지원하는 패키지가 없으면 안정 ABI가 충분히 좋은지 알 수 없고, 안정 ABI의 요소에서 문제를 발견하더라도 이를 안정 ABI에서 제거할 수 없습니다. 2단계는 커뮤니티가 자유 스레드 Python을 도입하고 API와 ABI에 대한 피드백을 제공할 시간을 주기 위한 것이므로, 2단계에서 안정 ABI를 얼마나 엄격한 요구 사항으로 삼아야 할지는 확신하기 어렵습니다.

명세

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

수용 가능한 성능. 운영 위원회는 자유 스레드 Python이 약 10-15% 느릴 것으로 예상한다고 언급했지만, 이는 엄격한 목표는 아니었습니다. 현재는 약 10% 수준이며 더 느려질 것으로 예상하지 않지만, 2단계(기본값 전환이 아님)에 대해서는 15%를 엄격한 성능 목표로 제안합니다.
수용 가능한 메모리 사용량. 이는 운영 위원회가 언급하지 않았으며 많이 논의되지도 않았습니다. 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에서 다룰 내용으로 남겨 둡니다.)

미해결 문제

안정 ABI를 자유 스레드 빌드의 “지원” 상태를 위한 엄격한 요구 사항으로 삼아야 합니까?

각주

Copyright

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