[Withdrawn] PEP 413 - Faster evolution of the Python Standard Library

September 26, 2025

원문 링크: PEP 413 - Faster evolution of the Python Standard Library

상태: Withdrawn 유형: Process 작성일: 24-Feb-2012

PEP 413 – Python 표준 라이브러리의 더 빠른 발전 (철회됨)

작성자: Alyssa Coghlan 상태: 철회됨 (Withdrawn) 유형: Process 생성일: 2012년 2월 24일

PEP 철회 (PEP Withdrawal)

PEP 413은 제안되었으나, 결국 철회되었습니다. 철회된 주된 이유는 다음과 같습니다.

PEP 453의 수용: pip이 대부분의 새로운 Python 사용자에게 기본적으로 제공되면서, 충분히 성숙하기 전에 새로운 모듈을 표준 라이브러리에 추가해야 한다는 압박이 줄었습니다.
패키지 인덱스 모델의 성장: 표준 라이브러리 패키지가 오래된 Python 버전도 지원하는 Python Package Index (PyPI)에서 동등한 버전을 제공하는 모델의 사용이 증가했습니다.

이러한 변화들과 Python 3.4 릴리스 주기 동안의 커뮤니티 참여도를 고려할 때, PEP 작성자는 표준 라이브러리 개발 프로세스에 이처럼 근본적인 변화를 주는 것이 더 이상 적절하지 않다고 판단했습니다.

개요 (Abstract)

이 PEP는 표준 라이브러리(standard library)에 대해 별도의 버전 관리 체계를 채택할 것을 제안합니다. 이 체계는 기존 언어 버전 관리 체계와는 다르지만 연결되어 있으며, Python 표준 라이브러리의 릴리스 속도를 가속화하는 동시에 핵심 언어 정의의 변경 속도는 유지하거나 심지어 늦출 수 있도록 합니다.

PEP 407과 마찬가지로, 이 제안은 광범위한 커뮤니티가 적응할 시간을 주는 신중한 변화와, 현재의 릴리스 주기보다 빠르게 발전하는 외부 영향(특히 웹 기술과 관련된 표준 라이브러리 요소)에 보조를 맞출 수 있는 능력 사이의 균형을 조정하는 것을 목표로 합니다. 그러나 PEP 407보다 목표가 더 보수적이며, 개발 속도 증가를 builtin 및 표준 라이브러리 인터페이스로 제한하고, 언어 문법, 버전 번호, CPython 바이너리 API 및 바이트코드 형식과 같은 다른 요소의 변경 속도에는 영향을 미치지 않으려 했습니다.

제안 배경 (Rationale)

PEP 407의 추상(abstract)을 인용하자면, 오픈 소스 프로젝트의 릴리스 주기를 찾는 것은 개발 인력, 릴리스 관리 자원 봉사자의 가용성, 사용자 및 서드 파티 패키지 관리자의 유지보수 용이성, 새로운 기능 및 행동 변경의 빠른 가용성, 새로운 기능이나 행동 변경 없이 버그 수정의 가용성 등 서로 모순되는 제약 조건을 관리하는 섬세한 작업입니다.

현재의 릴리스 주기는 보수적인 경향이 있으며, 반응성보다는 안정성을 중요하게 생각하는 사람들에게 적합합니다. 이 PEP는 Python의 상징이 된 안정성을 유지하면서, Long-Term Support (LTS) 버전의 개념을 도입하여 더 유연한 기능 릴리스를 제공하려는 시도였습니다.

작성자는 PEP 407 작성자들과 마찬가지로 표준 라이브러리의 현재 릴리스 주기가 웹 프로토콜 및 관련 기술(데이터베이스, 템플릿, 직렬화 형식 포함)과 같은 일부 주요 프로그래밍 분야의 변화 속도에 효과적으로 대처하기에는 너무 느리다는 데 동의했습니다.

그러나 PEP 407이 CPython의 잠재적으로 바이너리 비호환적인 릴리스를 6개월마다 제공하는 접근 방식이 광범위한 Python 생태계에 너무 큰 부담을 준다고 보아, 이 PEP는 경쟁 제안으로 작성되었습니다. 예를 들어, CPython의 릴리스 속도가 3배 이상 빨라진다면, 핵심 바이너리 확장 프로그램 배포자들은 더 빠른 릴리스 주기를 채택하거나, 오래된 Python 버전을 더 빨리 중단하거나, 사용자들에게 CPython LTS 릴리스를 고수하라고 권장해야 하는 딜레마에 직면하게 됩니다.

이 PEP는 변경 속도 증가의 주된 이유(즉, 웹 프로토콜 및 관련 기술에 대한 더 시의적절한 지원)가 표준 라이브러리 변경만 요구한다는 점에 주목합니다. 이는 새로운 릴리스 주기에 의해 영향을 받는 CPython의 부분을 명시적으로 제한하고 다른 부분은 현재의 느린 속도로 발전하도록 허용함으로써 광범위한 커뮤니티에 미치는 부정적인 영향을 피할 수 있음을 의미합니다.

제안 내용 (Proposal)

이 PEP는 새로운 종류의 CPython 릴리스, 즉 “표준 라이브러리 릴리스(standard library releases)”의 도입을 제안했습니다. PEP 407과 마찬가지로, CPython은 세 가지 종류의 릴리스를 가지게 됩니다.

Language release (언어 릴리스): “x.y.0”
Maintenance release (유지보수 릴리스): “x.y.z” (z > 0)
Standard library release (표준 라이브러리 릴리스): “x.y (xy.z)” (z > 0)

이 체계에서 “3.3”과 같은 비한정(unqualified) 버전 참조는 항상 가장 최신에 해당하는 언어 또는 유지보수 릴리스를 지칭합니다. 표준 라이브러리 릴리스를 지칭하기 위해 비한정적으로 사용되지는 않습니다.

릴리스 주기 (Release Cycle)

유지보수 릴리스가 생성될 때, 실제로 python.org에 두 가지 새로운 Python 버전이 게시될 것입니다 (예: Python 3.3의 첫 유지보수 릴리스).

3.3.1 (유지보수 릴리스)
3.3 (33.1) (표준 라이브러리 릴리스)

표준 라이브러리 릴리스는 이전 언어 릴리스와 바이너리 호환성을 유지하며, Python 수준에서 추가 기능을 제공합니다.

프로그래밍 방식의 버전 식별 (Programmatic Version Identification)

새로운 버전 세부 정보를 프로그래밍 방식으로 노출하기 위해, 이 PEP는 기본 인터프리터 버전 외에 새로운 표준 라이브러리 버전을 기록하는 새로운 sys.stdlib_info 속성을 추가할 것을 제안했습니다.

예를 들어, 초기 Python 3.3 릴리스의 경우:

sys.stdlib_info(python=33, version=0, releaselevel='final', serial=0)

이 정보는 sys.version 문자열에도 포함될 것입니다.

Python 3.3.0 (33.0, default, Feb 17 2012, 23:03:41) [GCC 4.6.1]

사용자 시나리오 (User Scenarios)

이 제안된 버전 관리 체계가 채택될 경우 발생할 수 있는 여러 사용자 시나리오를 현재 상태, 이 PEP의 체계, 그리고 PEP 407의 체계를 비교하여 설명합니다.

주요 결론은 거의 모든 시나리오에서 중요한 번호는 언어 버전이지 표준 라이브러리 버전이 아니라는 것입니다. 대부분의 사용자는 표준 라이브러리 버전 번호가 존재한다는 사실조차 알 필요가 없을 것입니다.

초보 사용자, Python 다운로드: 현재와 PEP 407 모두 LTS (Long Term Support) 릴리스의 의미를 설명하는 것만큼 이 PEP의 표준 라이브러리 릴리스 버전 번호의 의미를 설명하는 것이 복잡하므로 무승부입니다.
초보 사용자, 서드 파티 문서의 최신성 판단: 언어 변경 및 Deprecation (더 이상 사용되지 않음) 경고가 서드 파티 문서의 정확성에 더 큰 영향을 미칠 수 있으므로, 이 PEP의 체계가 더 유리합니다.
초보 사용자, 확장 모듈 바이너리 릴리스 검색: 이 PEP의 체계는 현재 상황과 아무것도 바뀌지 않으므로 확실한 승리입니다. 표준 라이브러리 버전은 이 경우 무관합니다.
확장 모듈 작성자, 바이너리 릴리스 여부 결정: 이 PEP의 체계는 현재 상황과 동일하여 또 다른 확실한 승리입니다.
Python 개발자, Deprecation Warning 제거 우선순위 결정: 이 PEP의 체계가 다시 한 번 확실한 승리입니다. 표준 라이브러리 버전은 이 시나리오에서 무관합니다.
대체 인터프리터 구현자, 새 기능으로 업데이트: 이 PEP는 표준 라이브러리 업데이트가 언어 정의의 이전 버전과 명확하게 호환되는 형태로 더 자주 제공되어 통합하기 쉽습니다.
Python 개발자, 최소 버전 종속성 결정: 이 PEP의 체계는 서드 파티 라이브러리가 표준 라이브러리 기능 채택 속도에 대해 더 명시적으로 설명할 수 있게 하지만, PEP 407이 현재 상태를 유지한다는 장점이 있어 PEP 407의 근소한 우위입니다.
Python 개발자, 트래커 이슈 재현 시도: PEP 407이 약간 더 유리합니다. 새로운 표준 라이브러리 버전은 사용자가 개발자에게 전달해야 할 추가 정보가 될 수 있습니다.
CPython 릴리스 관리자, 보안 수정 처리: PEP 407이 이 시나리오를 다루도록 업데이트될 때까지는 이 PEP가 확실한 승리입니다.

영향 (Effects)

개발 주기 (Development Cycle)

PEP 407과 유사하게, 이 PEP는 새로운 기능의 제공을 더 개별적인 청크(discrete chunks)로 나눌 것입니다. 모든 변경 사항이 언어 릴리스에서 한 번에 적용되는 대신, 각 언어 릴리스는 6개월치의 표준 라이브러리 변경 사항과 새로운 문법과 관련된 변경 사항으로 제한됩니다.

워크플로우 (Workflow)

이 PEP는 일반적인 워크플로우에 하나의 추가 브랜치를 생성할 것을 제안합니다. 예를 들어, 3.3 릴리스 이후에는 2.7 (유지보수), 3.3 (유지보수), 3.3-compat (새로운 하위 호환 변경), default (언어 변경 및 그에 의존하는 표준 라이브러리 업데이트) 브랜치가 사용될 것입니다. 개발자는 새로운 기능이 표준 라이브러리 릴리스에 적합한 변경인지 결정해야 합니다.

버그 수정 주기 (Bugfix Cycle)

버그 수정 워크플로우에 미치는 영향은 새로운 기능 워크플로우와 본질적으로 동일합니다. 즉, 변경 사항이 default 브랜치에 도달하기 전에 하나의 추가 브랜치를 거쳐야 합니다. 유지보수 릴리스에서 중요한 버그가 발견되면, 문제 해결을 위해 새로운 유지보수 및 표준 라이브러리 릴리스가 생성될 것입니다.

커뮤니티 (Community)

이 PEP는 변경 속도 증가를 표준 라이브러리로 격리하고 별도의 버전 번호로 명확하게 구분함으로써 커뮤니티가 “갑자기 개발 속도를 3배로 늘려야 하는 것은 아니다”라고 안심시키는 데 큰 도움이 될 것이라고 믿었습니다. 대신, 이전 Python 버전과 하위 호환되는 변경 사항이라도 다음 언어 정의 업데이트까지 지연시키지 않고, 다음 언어 릴리스를 위한 표준 라이브러리 업데이트를 6개월 단위로 제공할 것이라는 입장입니다.

버전 결합 감소의 다른 이점 (Other benefits of reduced version coupling)

언어 릴리스 주기 늦추기 (Slowing down the language release cycle)

현재의 릴리스 주기는 핵심 언어 정의 및 C 확장 ABI의 안정성에 대한 요구와 새로운 기능(특히 표준 라이브러리 업데이트)을 사용자에게 더 빨리 제공하려는 요구 사이의 절충안입니다. 표준 라이브러리 릴리스 주기가 핵심 언어 정의의 주기와 (어느 정도) 분리되면서, 언어 정의의 변경 속도를 실제로 늦출 기회가 제공됩니다.

표준 라이브러리 개발 속도 추가 증가 (Further increasing the pace of standard library development)

이 PEP에서 제안하는 체계의 한 가지 이점은 언어 릴리스 주기를 표준 라이브러리 릴리스 주기와 크게 분리한다는 것입니다. 표준 라이브러리는 3개월마다, 심지어 한 달에 한 번 업데이트될 수 있으며, 언어 버전 번호나 핵심 언어의 인지된 안정성에 아무런 영향을 미치지 않습니다.

기타 질문 (Other Questions)

주요 버전 번호를 사용하지 않는 이유: Python 2에서 Python 3으로의 전환으로 인한 지속적인 어려움으로 인해 major.minor.micro 버전을 언어, 표준 라이브러리, 유지보수 릴리스에 각각 매핑하는 간단한 옵션은 역사적인 이유로 실행 가능하지 않습니다.
4부분 버전 번호를 사용하지 않는 이유: 기존 버전 관리 체계에 “표준 라이브러리” 버전을 추가하는 것은 sys.version_info 구조에 대한 하위 호환성 제약으로 인해 실행 가능하지 않습니다.
날짜 기반 버전 관리 체계를 사용하지 않는 이유: 이전 버전의 이 PEP에서는 날짜 기반 버전을 제안했지만, 보안 문제나 중요한 버그를 수정하기 위한 “주기 외” 릴리스(out-of-cycle releases)를 처리하기가 매우 어렵게 만들었습니다.
PEP 384만으로는 충분하지 않은 이유: PEP 384는 CPython에 “Stable ABI” 개념을 도입했지만, 기존 모듈의 Stable ABI로의 마이그레이션은 많은 작업이 필요하며, 이 PEP는 바이너리 호환성 외에도 다른 이점(위에서 설명)을 제공합니다.
표준 라이브러리 릴리스에서 C ABI에 바이너리 호환 가능한 추가를 허용하지 않는 이유: PEP는 현재 인터프리터 버전을 언어 버전과 연결하고, 따라서 주요 인터프리터 변경(C ABI 추가 포함)을 언어 릴리스로 제한합니다. 이 접근 방식이 더 간단하고 설명하기 쉽다고 판단했습니다.
표준 라이브러리를 완전히 분리하지 않는 이유: 표준 라이브러리를 CPython 참조 구현과 완전히 독립적으로 만드는 아이디어는 많은 작업과 거의 이점이 없다고 판단했습니다. 많은 “표준 라이브러리 모듈”은 실제로는 해당 인터프리터의 내부 세부 사항과 밀접하게 연결되어 있습니다. 대신, 이전 언어 릴리스와 호환되는 별도의 CPython 개발 브랜치를 만들고, 그 브랜치에서 별도의 표준 라이브러리 버전 번호로 식별되는 릴리스를 만드는 것이 독립적인 표준 라이브러리 저장소의 대부분의 이점을 제공하면서 고통은 적을 것이라고 보았습니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.