[Rejected] PEP 8010 - The Technical Leader Governance Model

원문 링크: PEP 8010 - The Technical Leader Governance Model

상태: Rejected 유형: Informational 작성일: 24-Aug-2018

파이썬 개선 제안 (PEP) 8010: 기술 리더 거버넌스 모델

개요

이 문서는 Python Enhancement Proposal (PEP) 8010, 즉 “기술 리더 거버넌스 모델”에 대한 한국어 번역 및 요약입니다. 이 PEP는 단일 기술 프로젝트 리더 모델의 지속을 제안하며, 기존의 BDFL (Benevolent Dictator For Life) 모델을 ‘Gracious Umpire Influencing Decisions Officer (GUIDO)’라는 새로운 명칭으로 대체할 것을 제시했습니다. 이 명칭 변경은 GUIDO가 더 넓은 개발 커뮤니티와의 협의를 통해 Python 언어 의사결정 과정의 최종 중재자로서 확장된 역할을 반영하며, “종신”이라는 개념이 언어나 GUIDO 자신에게 항상 최선은 아닐 수 있다는 인식을 담고 있습니다.

참고: PEP 8010은 2018년 12월 17일에 핵심 개발자 투표를 통해 거부되었습니다. 대신 PEP 8016과 그 거버넌스 모델이 채택되었습니다.

주요 제안 내용 (거부되었음)

이 PEP는 다음과 같은 내용을 기술합니다.

  • 단일 기술 리더 모델 유지의 근거: 단일 기술 리더 모델을 유지하는 이유를 설명합니다.
  • GUIDO 선출 및 유지 과정: GUIDO가 어떻게 선택, 선출, 유지, 소환되고 계승될지에 대한 절차를 명시합니다.
  • GUIDO의 역할: Python 언어 발전 과정에서 GUIDO의 역할을 정의합니다.
  • 임기: GUIDO의 임기 길이를 제안합니다.
  • Council of Pythonistas (CoP)와의 관계: 기술적 문제에 대해 GUIDO에게 자문하는 CoP와의 관계를 설명합니다.
  • CoP의 규모, 선출, 역할: CoP의 구성원 수, 선출 방식 및 역할을 정의합니다.
  • 의사결정 위임 절차: 의사결정 위임 과정을 설명합니다.
  • PEP 프로세스 변경: 새로운 거버넌스 모델에 맞춰 PEP 프로세스에 필요한 변경 사항을 제안합니다.

이 PEP는 새로운 BDFL을 지명하지 않습니다. 이 모델이 채택될 경우, PEP 13에 이 문서에 설명된 모든 직책 보유자의 이름과 함께 명시될 예정이었습니다.

PEP 거부

PEP 8010은 2018년 12월 17일 월요일에 PEP 8001에 설명된 핵심 개발자 투표를 통해 거부되었습니다. 대신 PEP 8016 및 해당 거버넌스 모델이 채택되었습니다.

논의 지점

거버넌스 논의 과정에서 CoP의 정확한 규모, 임기, 투표 절차 등 이 PEP의 매개변수에 대한 다양한 조정이 허용됩니다. 이들은 PEP가 투표에 부쳐질 준비가 될 때까지 성문화될 예정이었습니다.

이 PEP에 설명된 투표 절차 및 이벤트는 PEP 8001에 명시된 투표 방식을 기본으로 하지만, 이 PEP가 작성될 당시 PEP 8001도 논의 중이었으므로 변경될 수 있었습니다.

이 모델을 통해 경험이 쌓이면서, 향후 GUIDO가 지명될 때 더 원활한 거버넌스 프로세스를 제공하기 위해 이러한 매개변수가 조정될 수 있을 것으로 예상되었습니다.

왜 단일 기술 리더인가?

다른 모델이 아닌 이 모델을 제안한 이유는 “비전(vision)”에 있습니다. 위원회식 설계는 많은 단점을 가지고 있으며, 이는 당시 기여자들의 다양한 관심사에 기반하여 새로운 기능이 축적되는 언어로 이어질 수 있습니다. 유명한 경구는 “낙타는 위원회가 설계한 말이다(a camel is a horse designed by committee)”라는 것입니다. 위원회가 설계한 언어가 “일관성 있게 유지될(hang together)” 수 있을까요? 규칙이 합리적이고 쉽게 기억되는 일관되고 자기 모순 없는 언어처럼 느껴질까요?

단일 기술 리더는 위원회가 할 수 있는 것보다 더 많은 비전을 추진할 수 있습니다. 각 참여자는 “Python”이 무엇인지에 대한 자신만의 비전을 가질 것이며, 이러한 개별 비전이 충돌할 때 우유부단함이나 비논리적인 선택으로 이어질 수 있습니다. 예를 들어, CPython을 3배 더 빠르게 만들어야 할까요, 아니면 C API를 보존해야 할까요? 이는 어느 쪽도 옳고 그르지 않기 때문에 합의를 얻기 매우 어려운 질문입니다. 그러나 잘못된 결정을 내리는 것보다 더 나쁜 것은 합의를 찾을 수 없기 때문에 현 상태를 수용하는 것일 수 있습니다.

유연성

GUIDO와 CoP 모두에게 명세 부족(underspecification)을 통해 일정 수준의 유연성이 부여됩니다. 이 PEP는 갈등이 어떻게 해결될지 설명하지만, 핵심 개발자, 커뮤니티 구성원, 직책 보유자를 포함한 모든 참여자가 항상 Python과 그 사용자들의 최선의 이익을 염두에 둘 것으로 기대합니다. 이 PEP는 상호 존중과 선의가 항상 합의로 이어질 것이며, 행동 강령(Code of Conduct)이 모든 상호작용과 논의를 관리한다고 가정합니다.

GUIDO의 역할

GUIDO의 가장 중요한 역할 중 하나는 여러 릴리스에 걸쳐 Python 언어 발전에 대한 포괄적이고 넓고 일관된 비전을 제공하는 것입니다. 이는 의사결정이 장기적인 영향을 미치고 상충하는 이점을 가질 때 특히 중요합니다. 예를 들어, C API에 대한 하위 호환성 없는 변경이 Python 성능을 2배 향상시킨다면, 다른 커뮤니티 구성원들은 논쟁의 양측에서 설득력 있게 주장할 것이며, 명확한 합의가 도출되지 않을 수 있습니다. 어느 선택이든 똑같이 유효합니다. CoP와의 협의를 통해 궁극적인 결정을 이끌어내는 것은 GUIDO의 비전이 될 것입니다.

GUIDO는 PEP 및 기타 문제에 대한 최종 결정권자이며, 특정 변경 사항이 PEP 가치가 있는지 여부를 포함합니다. 오늘날과 마찬가지로, 많은 —사실 대부분의— 결정은 이슈 트래커, 병합 요청, 토론 포럼에서 논의와 해결을 통해 이루어지며, 일반적으로 해당 분야 전문가의 의견이나 주도에 따라 진행됩니다. 이러한 운영 절차가 완벽하게 작동하는 곳에서는 변경 없이 계속될 수 있습니다. 이는 또한 CoP와 GUIDO의 업무 부담을 줄여 가장 중요한 결정과 넓은 시야를 중앙 권한에만 남겨둡니다.

마찬가지로, 특정 변경 사항이 PEP를 요구한다고 간주되지만, GUIDO가 CoP와의 협의를 통해 최종 결정을 내릴 완전한 신뢰를 가진 전문가를 식별하는 경우, GUIDO는 해당 PEP에 대한 위임자(Delegate)를 지명할 수 있습니다. GUIDO가 최종 권한을 유지하지만, GUIDO는 위임자의 권한을 훼손하지 않고 실제로 PEP의 최종 중재자로서 지지할 것으로 예상됩니다.

GUIDO는 제안이 Python의 장기적인 비전에 반한다는 것이 분명할 때, 비생산적인 논의, 아이디어, 제안을 중단할 수 있는 완전한 권한을 가집니다. 이는 변경을 주장하는 사람들에게는 공감하지만, 모든 커뮤니티 구성원의 건강과 복지를 염두에 두고 이루어집니다. 막다른 골목 제안에 대한 독성이 있는 논의는 누구에게도 도움이 되지 않으며, 명령에 의해 종료될 수 있습니다.

요약하자면: GUIDO는 거버넌스 PEP 자체를 변경하는 것을 제외하고, 기술적 또는 비기술적 주제에 대한 최종 선언을 할 권한을 가집니다.

권한은 커뮤니티로부터 나온다

GUIDO의 권한은 궁극적으로 커뮤니티에 있습니다. 대다수 커뮤니티의 신뢰를 잃은 무책임한 GUIDO는 소환될 수 있으며, 새로운 투표가 실시될 수 있습니다. 이는 극히 드물고 일어날 가능성이 낮은 사건입니다. 이는 최악의 시나리오에 대한 충분한 임시방편이므로 가볍게 다루어져서는 안 됩니다. GUIDO는 한 가지 결정 때문에 해임되는 것을 두려워해서는 안 됩니다. 비록 그 결정이 대다수의 Python 개발자들이 선호하지 않는 결정이라 할지라도 말입니다. 소환은 Python 언어 또는 커뮤니티에 심각하게 해로운 행동에 대해서만 유보되어야 합니다.

Council of Pythonistas (아래 참조)는 불신임 투표를 시작할 책임이 있습니다.

임기 및 연임 제한

GUIDO는 세 번의 Python 릴리스 동안, 현재 릴리스 주기를 고려할 때 약 4.5년 동안 봉사합니다. Python의 릴리스 주기가 변경되면, GUIDO의 임기는 전체 릴리스로 반올림하여 4.5년으로 변경되어야 합니다. 반올림 방식은 잠재적인 릴리스 주기 PEP에 맡겨집니다. 이 기간이 지나면, 아래에 명시된 절차에 따라 새로운 선거가 실시됩니다. 연임 제한은 없으므로, GUIDO는 원하는 한 재선에 출마할 수 있습니다.

GUIDO는 임기를 모두 채울 것으로 예상되지만, 물론 “인생은 예측 불가능합니다(Life Happens)”. GUIDO가 임기 전에 사임해야 하는 경우, 새로운 GUIDO 선출 절차에 따라 공석이 채워집니다. 그러나 새로운 GUIDO는 원래 GUIDO의 남은 임기 동안만 봉사하며, 이 시점에 새로운 선거가 실시됩니다. 사임하는 GUIDO는 후임자가 선출될 때까지 계속 봉사할 수 있습니다.

과도기 동안, CoP (아래 참조)는 GUIDO의 의무를 수행할 수 있지만, 실질적인 결정(예: 기술 PEP 승인)은 새로 선출될 GUIDO에게 맡기는 것을 선호할 수도 있습니다.

GUIDO 선출

선출 과정은 새로운 GUIDO의 공석이 발생하거나, 정상적인 과정에서 GUIDO가 재선에 출마할 때 시작됩니다. GUIDO가 사임하거나 GUIDO의 정규 임기가 끝나기 두 달 전에 선출 과정이 시작되면, 새로운 선거 절차가 시작됩니다.

투표 전 3주 동안 후보 지명이 가능합니다. 후보자는 현재 Python 핵심 개발자 목록에서 선택되어야 합니다. 비핵심 개발자는 GUIDO로 봉사할 자격이 없습니다. 후보자는 자신을 지명할 수 있지만, 모든 지명은 재청(seconded)되어야 합니다. 지명과 재청은 비공개 저장소에 대한 병합 요청(merge request)으로 진행됩니다.

지명을 수락하면, 후보자들은 동일한 비공개 저장소를 사용하여 짧은 입장 성명(position statement)을 게시할 수 있으며, 커미터 토론 포럼에도 게시할 수 있습니다. 토론도 있을 수 있습니다! 이 선거 단계는 2주 동안 진행됩니다.

핵심 개발자들은 PEP 8001에 설명된 절차를 사용하여 3주 동안 투표합니다.

Council of Pythonistas (CoP)

GUIDO를 돕는 것은 소수의 선출된 Python 전문가 팀입니다. 이들은 기술 위원회 구성원 팀으로 봉사합니다. 이들은 GUIDO 앞에 놓인 선택 사항에 대한 통찰력과 논의를 제공합니다. 협의는 양측에서 시작될 수 있습니다. 예를 들어, GUIDO가 특정 선택에 대해 여전히 결정을 내리지 못한 경우, CoP와의 논의는 남은 문제를 명확히 하고, 올바른 질문을 식별하고, GUIDO가 잘 알지 못할 수 있는 다른 Python 사용자들에게 미치는 영향에 대한 통찰력을 제공하는 데 도움이 될 수 있습니다. CoP는 GUIDO의 신뢰할 수 있는 조언자이며, 긴밀한 협력 관계가 예상됩니다.

CoP는 핵심 개발자 중에서 선출된 3명의 구성원으로 구성됩니다. 그들의 임기는 3년이며, 구성원은 원하는 만큼 여러 번 재선에 출마할 수 있습니다. 연속성을 보장하기 위해 CoP 구성원은 순환 방식으로 선출됩니다. 매년 한 명의 CoP 구성원이 재선에 출마합니다.

초기 선거를 위한 시차를 부트스트랩하기 위해, 가장 많은 득표를 얻은 CoP 구성원은 3년 동안, 두 번째로 인기 있는 득표자는 2년 동안, 가장 적은 득표를 얻은 CoP 구성원은 초기 1년 동안 봉사합니다.

투표의 모든 동점은 PEP 8001에서 결정될 절차에 따라 해결될 예정이었습니다.

지명 및 투표 절차는 GUIDO와 유사합니다. 3주간의 지명 기간이 있으며, 자천이 허용되고 재청되어야 합니다. 그 다음 입장 성명을 게시하는 기간이 있고, 이어서 투표가 진행됩니다.

CoP는 만장일치 결정으로 GUIDO에 대한 불신임 투표를 시작할 수 있으며, 해당 섹션의 절차를 시작합니다.

불신임 투표

위에서 언급했듯이, CoP는 만장일치 결정으로 GUIDO에 대한 불신임 투표를 시작할 수 있습니다. 이 과정은 가볍게 다루어져서는 안 되지만, 일단 시작되면 최대 두 번의 투표가 시작됩니다. 두 경우 모두 투표는 PEP 8001과 동일한 절차로 이루어지며, 모든 핵심 개발자가 불신임 투표에 참여할 수 있습니다.

첫 번째 투표는 현재 GUIDO를 소환할지 여부입니다. Python 개발자들의 압도적 다수가 “불신임”에 투표하면, GUIDO는 소환됩니다. 그 다음, 이 직책 보유자의 초기 선출 절차에 따라 새로운 GUIDO를 선출하기 위한 두 번째 투표가 실시됩니다. GUIDO가 없는 기간 동안, 주요 결정은 보류되지만, 정상적인 Python 운영은 물론 계속될 수 있습니다.

일상적인 운영

GUIDO는 모든 또는 대부분의 결정에 필요하지 않습니다. Python 개발자들은 이미 위임, 책임, 자기 주도성을 위한 충분한 기회를 가지고 있습니다. 이슈 트래커와 풀 리퀘스트는 이 거버넌스 모델이 선택되기 전과 동일한 기능을 수행합니다. 버그 수정 및 사소한 개선에 대한 대부분의 논의는 항상 그래왔듯이 이러한 포럼에서 이루어질 수 있습니다.

PEP 고려 사항

GUIDO, CoP 구성원, 그리고 Python 커뮤니티의 다른 누구라도 PEP를 제안할 수 있습니다. 잠재적인 PEP의 처리는 PEP 작성자에 관계없이 동일하게 처리됩니다.

그러나 GUIDO가 PEP를 작성하는 경우, 공정한 PEP 위임자(Delegate)가 선정되어 PEP를 수락하거나 거부할 권한이 부여되어야 합니다. GUIDO는 의사결정 과정에서 스스로를 제외(recuse)해야 합니다. 명확한 합의가 이루어지지 않는 논란이 많은 PEP의 경우, GUIDO가 작성한 PEP에 대한 최종 권한은 CoP에 있습니다.

PEP 제안은 핵심 개발자가 항상 PEP Shepherd로 선택되어야 한다는 점에서 더욱 강화됩니다. 이 사람은 적절한 절차가 유지되도록 보장합니다. Shepherd는 핵심 개발자 중에서 선택되어야 합니다. 이는 누구든지 PEP를 작성할 수 있지만, 모든 PEP는 최소한 한 명의 핵심 개발자로부터 일정 수준의 후원을 받아야 함을 의미합니다.

버전 기록

버전 2

  • “기술 리더 거버넌스 모델(The Technical Leader Governance Model)”로 이름 변경
  • “단일 리더(singular leader)” -> “단일 기술 리더(singular technical leader)”
  • PEP 8001 투표 절차 채택은 해당 PEP가 승인될 때까지 잠정적임
  • GUIDO가 사임할 경우 발생하는 상황 설명
  • 소환 투표는 핵심 개발자의 압도적 다수가 찬성해야 성공함

저작권

이 문서는 퍼블릭 도메인에 공개되었습니다.

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

Comments