PEP 8010 – 기술 리더 거버넌스 모델
- Author:
- Barry Warsaw <barry at python.org>
- Status:
- Rejected
- Type:
- Informational
- Topic:
- Governance
- Created:
- 24-Aug-2018
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 단일 기술 프로젝트 리더 모델, 즉 Python 거버넌스의 Benevolent Dictator For Life (BDFL) 모델이라고 완곡하게 불리는 모델을 이어 갈 것을 제안하며, 이 모델을 이 PEP에서는 앞으로 Gracious Umpire Influencing Decisions Officer(GUIDO)라고 부릅니다. 이 명칭 변경에는 GUIDO가 더 넓은 개발 커뮤니티와 협의하여 Python 언어 의사 결정 과정의 최종 중재자 역할을 한다는 확장된 관점이 반영되어 있습니다. 또한 “종신”이라는 것이 이상적일 수는 있어도 언어나 GUIDO 자신의 안녕에 반드시 최선은 아니라는 인식도 함께 반영되어 있습니다.
이 PEP는 다음 내용을 설명합니다.
- 단일 기술 리더 모델을 유지하는 근거
- GUIDO를 선정, 선출, 유임, 소환, 승계하는 절차
- Python 언어 발전 과정에서 GUIDO가 맡는 역할;
- 임기
- 기술적 사안에 관해 GUIDO에게 조언하는 파이써니스타 협의회(Council of Pythonistas, CoP)와 GUIDO의 관계
- CoP의 규모, 선출 및 역할
- 의사 결정 위임 절차
- 새 거버넌스 모델에 맞추기 위한 PEP 절차의 모든 변경 사항
이 PEP는 새 BDFL을 지명하지 않습니다. 이 모델이 채택되면 이 PEP에 설명된 모든 직책 보유자의 이름과 함께 PEP 13에 명문화됩니다.
PEP 거부
PEP 8010은 2018년 12월 17일 월요일에 PEP 8001에 설명된 핵심 개발자 투표로 기각되었습니다.
대신 PEP 8016과 그 PEP가 설명하는 거버넌스 모델이 선택되었습니다.
열린 논의 사항
거버넌스 논의 과정에서는 CoP의 정확한 규모, 임기, 투표 절차 등 이 PEP의 여러 매개변수를 다양하게 조정할 수 있습니다. 이러한 사항은 이 PEP를 투표에 부칠 준비가 될 무렵에는 명문화될 것입니다.
이 PEP에 설명된 투표 절차와 행사는 기본적으로 PEP 8001에 명시된 투표 방식을 따르지만, 이 글을 쓰는 시점에 그 PEP는 아직 논의 중이므로 변경될 수 있습니다.
이 모델로 경험이 쌓이면 더 원활한 거버넌스 과정을 위해 향후 GUIDO가 지명될 때 이러한 매개변수를 조정할 수 있으며, 어쩌면 그렇게 되리라 예상하기도 합니다.
왜 단일 기술 리더입니까?
왜 다른 모델이 아니라 이 모델입니까? 결국 “비전”의 문제입니다. Design by committee에는 잘 알려진 단점이 많으며, 그 결과 당시 기여자들의 다양한 관심사에 따라 새 기능이 계속 덧붙는 언어가 만들어집니다. 유명한 격언으로 “낙타는 위원회가 설계한 말이다”라는 말이 있습니다. 위원회가 설계한 언어가 “하나로 잘 어우러질” 수 있겠습니까? 규칙이 이치에 맞고 기억하기 쉬운, 일관되고 자기모순이 없는 언어라고 느껴지겠습니까?
단일 기술 리더는 위원회보다 그 비전을 더 잘 추진할 수 있습니다. 이는 위원회가 소규모(예: 3명 또는 5명)이든 Python 커뮤니티 전체에 걸쳐 있든 마찬가지입니다. 모든 참여자는 “Python”이 무엇인지에 대해 저마다의 비전을 가지고 있으며, 이러한 개인의 비전들이 충돌하면 결정을 내리지 못하거나 비논리적인 선택으로 이어질 수 있습니다. CPython을 3배 더 빠르게 만들어야 합니까, 아니면 C API를 보존해야 합니까? 어느 선택도 옳거나 그르지 않기 때문에, 이는 합의를 이끌어 내기가 매우 어려운 질문입니다. 하지만 잘못된 결정을 내리는 것보다 더 나쁜 것은 합의를 찾지 못했다는 이유로 현상 유지를 받아들이는 것일 수 있습니다.
유연성
세부 사항을 일부러 모두 규정하지 않음으로써 GUIDO와 CoP 모두에게 어느 정도의 유연성이 주어집니다. 이 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가 임기를 끝까지 채우기를 기대하지만, 물론 살다 보면 무슨 일이든 생길 수 있습니다. GUIDO가 임기가 끝나기 전에 물러나야 한다면, 새 GUIDO 선출에 관해 아래에 설명하는 절차에 따라 공석을 채웁니다. 다만 새 GUIDO는 원래 GUIDO의 남은 임기 동안만 재임하며, 그 임기가 끝나면 새 선거를 치릅니다. 물러나는 GUIDO는 후임자가 선출될 때까지 계속 직무를 수행할 수 있습니다.
이행 기간에는 CoP(아래 참조)가 GUIDO의 직무를 수행할 수 있지만, 실질적인 결정(기술 PEP 승인 등)은 새로 취임하는 GUIDO에게 맡기는 편을 택할 수도 있습니다.
GUIDO 선출
선출 절차는 새 GUIDO가 필요한 공석이 생길 때마다, 또는 통상적인 경우처럼 GUIDO의 재선 시기가 되었을 때 시작됩니다. GUIDO가 물러나거나 GUIDO의 정규 임기 종료 두 달 전이 되어 선출 절차가 시작되면, 새 선거 절차가 개시됩니다.
투표 전 3주 동안 후보 추천을 받습니다. 후보자는 현재의 Python 코어 개발자 목록에서 선정해야 합니다. 코어 개발자가 아닌 사람은 GUIDO가 될 자격이 없습니다. 후보는 스스로를 추천할 수 있지만, 모든 추천에는 재청이 있어야 합니다. 추천과 재청은 비공개 저장소의 머지 요청으로 진행합니다.
추천을 수락한 후보는 같은 비공개 저장소를 사용해 짧은 입장문을 게시할 수 있으며, 커미터 토론 포럼에도 게시할 수 있습니다. 어쩌면 토론회도 열릴지 모릅니다! 선거의 이 단계는 2주 동안 진행됩니다.
그다음 코어 개발자들은 PEP 8001에 설명된 절차에 따라 3주 동안 투표합니다.
파이썬 전문가 평의회(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는 작성자가 누구인지와 관계없이 동일하게 처리됩니다.
다만 GUIDO가 PEP를 작성한 경우에는 공정한 PEP 위임자를 선정하여 해당 PEP를 수락하거나 거부할 권한을 부여해야 합니다. GUIDO는 의사 결정 과정에서 스스로 물러나야 합니다. 명확한 합의에 이르지 못하는 논쟁적인 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가 물러나는 경우 어떻게 되는지 설명합니다.
- 소환 투표가 가결되려면 핵심 개발자의 초다수 찬성이 필요합니다.
Copyright
This document has been placed in the public domain.