PEP 607 – CPython 기능 제공 지연 시간 줄이기

Author:: Łukasz Langa <lukasz at python.org>, Steve Dower <steve.dower at python.org>, Alyssa Coghlan <ncoghlan at gmail.com>
Discussions-To:: Discourse thread
Status:: Final
Type:: Informational
Created:: 11-Oct-2019
Python-Version:: 3.9
Post-History:: 20-Oct-2019

Table of Contents

초록
변경의 근거
완화해야 할 위험
Copyright

번역·라이선스 안내

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

초록

PEP 602와 PEP 605는 더 작은 기능 묶음을 더 자주 Python 사용자에게 제공하기 위한 두 가지 대안적 접근 방식을 설명합니다(18~24개월마다 새 기능 릴리스를 제공하고 최종 릴리스보다 6~8개월 앞서 첫 바이너리 알파 릴리스를 내놓는 현재 방식과 비교됩니다).

두 PEP는 또한 매년 같은 시기에 정식 릴리스가 나오는 릴리스 주기로 전환하자고 제안합니다(PEP 602는 매년, PEP 605는 격년).

경쟁하는 두 제안의 저자들이 함께 작성한 이 PEP는 릴리스 주기 변경이 왜 바람직하다고 여겨지는지에 대한 공통 배경과 함께, 두 PEP가 완화하려는 위험 요소를 설명합니다.

변경의 근거

기능 제공 묶음의 크기 줄이기

여러 대규모 변경이 함께 제공되면 새로 발생하는 문제의 근본 원인을 파악하기 위해 복잡한 조사가 필요할 수 있습니다. 또한 묶음이 크면 상대적으로 덜 검증된 코드가 더 많이 포함되므로 실제로 문제가 발생할 가능성도 커집니다.

이러한 조사를 단순화하고 사용자가 문제를 겪을 가능성을 줄이는 가장 쉬운 방법은 배포하는 묶음의 크기를 줄이는 것입니다.

PEP 602는 18개월 이상의 변경을 쌓아 두는 대신 매번 12개월 분량의 변경을 배포하여 CPython의 일반적인 묶음 크기를 50% 줄이는 단순한 접근 방식으로 이 문제를 해결하자고 제안합니다.

PEP 605는 베타 릴리스의 롤링 스트림을 실행하기로 선택한 Python 사용자층의 일부에게 2개월 분량의 변경 사항을 정기적으로 제공하여 이 문제를 해결할 것을 제안합니다(Windows 정식 릴리스 대신 Windows Insider 빌드를 실행하거나, Debian stable 대신 Debian testing을 실행하는 것과 비슷합니다).

기능 제공 지연 시간 줄이기

안정 릴리스만 사용자에게 널리 채택되고 안정 릴리스 사이의 기간이 길면, 개발자들은 변경 사항이 일반적인 사용에 충분히 준비되기 전에 안정 릴리스에 밀어 넣고 싶은 매우 강한 유혹을 받게 됩니다.

PEP 602는 안정 릴리스 사이의 기간을 18개월에서 12개월로 줄여 이 문제를 해결하자고 제안합니다.

PEP 605는 CPython 베타 릴리스를 정기적으로 설치하고 사용하는 Python 사용자 커뮤니티를 적극적으로 만들어 이 문제를 해결하자고 제안합니다. 이렇게 하면 코어 개발자들에게는 기능이 안정 릴리스에서 고정되기 전에 피드백을 얻기 위해 사전 릴리스 주기의 더 이른 시점에 변경을 배포하기 시작할 동기가 생깁니다.

현재 릴리스 주기는 명목상 18~24개월이지만, 실제로는 꾸준히 그 범위 중 18개월 쪽에 가까웠습니다. 이는 사전 릴리스와 최종 릴리스의 목표 날짜가 릴리스마다 달라진다는 뜻이며, 이를 기억하려면 릴리스 PEP를 확인하거나 해당 날짜를 달력에 추가하는 수밖에 없습니다. 이는 개인 자원봉사자와 기업 기여자 모두에게 번거로운 일이며, PyCon US(보통 4월/5월)나 이제 매년 열리는 코어 개발 스프린트(보통 9월) 같은 행사와 일정을 맞추는 일도 복잡하게 만듭니다.

PEP 602는 매년 10월에 새 릴리스를 발표하고 이를 기준으로 해마다 사전 릴리스 일정을 정하여 이 문제를 해결하자고 제안합니다.

PEP 605는 릴리스 연도(8월에 새 안정 릴리스가 발표되는 해)와 비릴리스 연도(유지보수 릴리스와 새 롤링 베타 릴리스만 발표되는 해)를 번갈아 운영하여 이 문제를 해결하자고 제안합니다.

사전 릴리스 설계 피드백 주기 개선하기

코어 인터프리터와 표준 라이브러리 API의 변경을 설계할 때 겪는 어려움 중 하나는 나이틀리 빌드와 현재 사전 릴리스에 대해 피드백을 줄 수 있는 사용자층이 상대적으로 제한적이라는 점입니다. 이 때문에 많은 사용자 피드백은 API 설계가 이미 정식 X.Y.0 릴리스로 배포된 후에야 들어옵니다.

해당 API가 일반 API라면 폐지(deprecation) 주기 때문에 그 시점에 발견된 설계 실수를 바로잡는 데 말 그대로 몇 년이 걸릴 수 있습니다. API를 잠정적(provisional)으로 표시하면 명목상 그 제약을 피할 수 있지만, 실제로 그 자유를 활용하면 다른 문제가 생깁니다.

PEP 602는 이전 안정 릴리스 직후에 바로 알파 기간을 시작하여 이 문제를 해결하자고 제안합니다.

PEP 605는 (라이브러리와 애플리케이션 호환성 테스트뿐 아니라) 프로덕션 워크로드 실행에도 CPython 사전 릴리스를 채택하도록 적극적으로 장려하고, 그것이 합리적인 선택이 되도록 필요에 따라 사전 릴리스 관리 절차를 조정하여 이 문제를 해결하자고 제안합니다.

(참고: 일부 표준 라이브러리 API는 처음에는 PyPI를 통해 별도로 버전 관리되는 패키지의 일부로 배포되었다가 나중에야 표준 라이브러리에 통합되는 방식이 적합합니다. 이 절은 초기 설계 피드백을 얻는 그러한 방식이 적용되지 않는 저수준 API와 라이브러리가 아닌 기능에 관한 내용에 더 가깝습니다)

완화해야 할 위험

현 상황에도 일부 측면에서 개선의 여지가 있지만, Python의 인기는 폭넓은 Python 생태계의 많은 사용자와 기타 참여자가 현재의 릴리스 관리 프로세스에 대체로 만족하고 있음을 보여 줍니다.

Python의 사용자 기반은 너무 크고 너무 다양하기 때문에 릴리스 주기 변경에 따른 잠재적 단점을 여기서 모두 다룰 수는 없습니다. 따라서 이 절에서는 PEP 설계 시 특별히 고려한 몇 가지 사항만 다룹니다.

이미 일부 릴리스를 건너뛰는 사용자와 재배포자에 대한 영향

이미 모든 사용자와 재배포자가 게시된 CPython 릴리스 시리즈마다 업데이트하는 것은 아닙니다(예를 들어, Debian stable과 Ubuntu LTS는 자신들의 24개월 릴리스 주기와 CPython의 통상적인 18개월 주기가 맞지 않아 때때로 릴리스를 건너뜁니다).

PEP 602의 더 빠른 12개월 정식 릴리스 주기에서는 이 범주의 사용자가 이전이라면 릴리스 하나만 건너뛰었을 상황에서 두 개를 건너뛰게 될 수 있습니다. 하지만 폐지 예고 기간이 연장되므로, 릴리스 하나를 건너뛰더라도 더 이상 폐지 경고를 놓치는 일은 없을 것입니다.

PEP 605의 더 느린 24개월 정식 릴리스 주기는 지금까지 이 범주에 속했던 사용자 일부를 “모든 안정 릴리스로 업데이트” 범주로 옮겨 가게 할 수 있습니다.

모든 릴리스로 업데이트하는 사용자와 재배포자에 대한 영향

많은 Python 사용자는 사전 릴리스를 전혀 설치하지 않지만, 모든 안정 릴리스 시리즈가 게시된 후 어느 시점에는 해당 시리즈로 업데이트합니다.

PEP 602는 릴리스 간 최소 간격을 12개월로 유지하고 각 릴리스의 18개월 완전 지원 기간을 유지함으로써 이 그룹 구성원에게 미칠 수 있는 부정적 영향을 완화하고자 합니다.

각 릴리스 브랜치의 18개월 완전 지원 기간을 유지하면, 브랜치가 완전 지원 모드와 보안 수정 전용 모드에 머무는 기간은 현재와 거의 같습니다(각각 약 18개월과 약 42개월).

PEP 605는 사전 릴리스 기간 동안의 사용을 늘려 출시 시점에 더 폭넓은 생태계 지원을 갖춘 더 안정적인 최종 릴리스를 달성함으로써 이 그룹 구성원에게 미칠 수 있는 부정적 영향을 완화하고자 합니다.

24개월 릴리스 주기에서는 각 릴리스 브랜치가 상대적으로 완전 지원 모드에 더 오래, 보안 수정 전용 모드에 더 짧게 머물게 됩니다(각각 약 24개월과 약 36개월).

이 그룹에 대한 영향의 전체 논의는 개별 PEP에 맡깁니다.

CPython 나이틀리 빌드의 사용자와 재배포자에 대한 영향

어려움이 있음에도 불구하고, 이미 CPython master 브랜치를 직접 사용하거나 배포하는 일에 도전하는 사용자와 재배포자가 일부 있습니다.

PEP 602와 PEP 605 모두 이 그룹에 직접적인 영향을 주지는 않을 것이지만, PEP 605의 롤링 릴리스 스트림 제안은 master 브랜치를 직접 사용할 필요 없이 테스트를 거친 롤링 베타 스트림을 채택할 수 있게 함으로써 더 많은 사용자가 이러한 사용 방식을 채택하는 데 따르는 장벽을 낮추고자 합니다.

서드파티 라이브러리 유지 관리자에 대한 영향

서드파티 라이브러리 유지 관리자에게 지원 복잡성의 핵심 원인은 널리 사용되는 서로 다른 Python 버전의 개수입니다.

PEP 602는 정식 릴리스 간 최소 간격을 12개월로 유지함으로써 이 그룹 구성원에게 미칠 수 있는 부정적 영향을 완화하고자 합니다.

PEP 605는 정식 릴리스 간 간격을 24개월로 늘리고, 각 릴리스 브랜치를 후속 릴리스가 출시된 후 머지않아 보안 수정 전용 모드로 전환하는 현재 정책을 유지하며, 새 롤링 릴리스 스트림에 “베타” 명명 체계를 유지함으로써(적어도 Python 3.9 릴리스 주기 동안은) 이 그룹 구성원에게 미칠 수 있는 부정적 영향을 완화하고자 합니다.