[Rejected] PEP 8014 - The Commons Governance Model

September 27, 2025

원문 링크: PEP 8014 - The Commons Governance Model

상태: Rejected 유형: Informational 작성일: 16-Sep-2018

PEP 8014 – 커먼즈 거버넌스 모델

요약 (Abstract)

이 PEP는 절차, 정의된 용어, 비율을 가능한 한 적게 사용하는 거버넌스 모델을 제안합니다. 이 모델은 ‘무정부주의 거버넌스 모델(The Anarchist Governance Model)’이라고도 불릴 수 있지만, 일부 사람들에게 ‘무정부주의’라는 용어가 부정적인 의미로 받아들여질 수 있어 현재는 ‘커먼즈(Commons)’라는 용어를 사용합니다.

기본 아이디어는 모든 결정이 원칙적으로 전체 커뮤니티의 투표를 거치지만, 실제로는 커뮤니티의 일부만이 투표에 참여한다는 것입니다. 전체 커뮤니티가 투표할 권리가 있더라도, 실제로는 항상 특정 결정에 대해 소수의 일부만이 투표할 것이기 때문입니다. 투표는 편견 없는 위원회(impartial council)에 의해 감독되며, 이 위원회는 결정 통과 여부를 판단합니다. 이 위원회는 찬성 및 반대 투표의 비율뿐만 아니라 총 투표 수, 제안의 중요성, 그리고 개별 투표자와 그들의 투표 방식 등을 고려하여 결정을 내립니다. 이를 통해 위원회는 각 개별 결정이 충분한 다수에 의해 지지되는지 확인할 책임이 있습니다.

PEP 반려 (PEP Rejection)

PEP 8014는 2018년 12월 17일 월요일에 PEP 8001에 설명된 핵심 개발자 투표를 통해 반려되었습니다. 대신 PEP 8016과 그 모델이 채택되었습니다.

서론 (Introduction)

커먼즈 거버넌스 모델은 모든 결정이 Python 커뮤니티의 충분한 다수에 의해 승인되거나 적어도 수용될 수 있도록 하는 것을 목표로 합니다.

하지만 “충분한 다수(sufficient majority)”와 “Python 커뮤니티(Python community)”라는 두 용어는 일반적인 경우에 정량화하기 매우 어렵습니다. 이는 두 용어 모두 실제로 결정되는 특정 상황에 따라 달라지기 때문입니다. 예를 들어, 기존 API에 대한 하위 호환 가능한 변경을 제안하는 PEP의 경우, 처음부터 PEP 투표에 관심이 있었던 핵심 개발자(core developers)들의 단순 다수로도 충분할 수 있습니다. 그러나 Python 3에서 Python 4로의 전환과 같이 더 광범위한 결과를 초래하는 변경의 경우, 진정한 다수가 필요할 수 있으며, 사용자층 내에서 충분한 지지가 있음을 보여주어야 합니다. 또한, 포괄적이지 않은 언어를 폐지하는 결정과 같이 Python 언어 자체를 넘어선 변경의 경우, 이 정의는 더욱 모호해집니다.

커먼즈 거버넌스 모델은 “충분한 다수”와 “Python 커뮤니티”가 일반적인 경우에 무엇을 의미하는지 정의하지 않고, 특정 경우에 이를 결정할 기관을 제안함으로써 이 문제를 회피하고자 합니다.

이 모델은 의사 결정 과정을 감독하고, 특정 제안이 사례별로 충분한 지지를 받는지 결정하는 “원로회(Council of Elders)”를 구성할 것을 제안합니다. 모든 개별 PEP에 대해 투표가 진행되며, 원로회는 해당 투표 결과가 이 특정 사례에서 결정을 진행하기에 충분한지 선언합니다. 이 모델은 BDFL (평생 자비로운 독재자)이 전통적으로 의사 결정 과정에서 맡았던 역할에만 초점을 맞추며, 다른 역할은 다루지 않습니다.

모델 이름의 “커먼즈(Commons)”는 공유 자원으로서 모두가 사용하고 모두가 돌보는 역사적 용어에서 느슨하게 파생되었습니다. 이 모델로 생각해야 할 그림은 따뜻한 여름 저녁, 마을 광장에서 미래 계획을 논의하는 상당수의 농민 집단이 투표를 한 후, 마을 원로들이 결과를 발표하고 연회가 시작되는 모습입니다.

커먼즈 거버넌스 모델은 전체 커뮤니티에 최고의 권한을 명시적으로 부여한다는 점에서 다른 대부분의 거버넌스 제안(8012를 제외하고)과 다릅니다.

제안 배경 (Rationale)

이 모델의 제안 배경은 모든 것을 명확하게 고정하는 모델이 의도하지 않은 부정적인 부작용을 가질 수 있다는 것입니다. 예를 들어, Python 커미터(committers)에게 투표권을 부여하는 거버넌스 모델은 새로운 후보자가 일하는 회사에 이미 많은 커미터가 있다는 이유로 개인의 커미터 승인을 거부하게 만들 수 있습니다.

또 다른 예로, PEP 승인을 위한 고정된 비율을 설정하는 것은 투표자들 사이에 파벌 형성을 유발하고, 개별 PEP가 개별적인 장점에 따라 판단되지 않고 파벌에 따라 판단될 수 있습니다 (만약 당신이 내 PEP를 지지한다면 나도 당신의 PEP를 지지할 것이다).

또한, 일인 일표(one-person-one-vote)가 Python과 같은 것에 가장 좋은 모델이 아니라는 문제도 있습니다. 다시 예를 들자면, 분열된 투표(또는 분열에 가까운 투표)의 경우 핵심 개발자 Guido van Rossum의 의견이 핵심 개발자 Jack Jansen의 의견보다 우선되어야 할 수도 있습니다. 이를 투표 모델에서 공식화하려고 하면 매우 복잡한 모델이 될 것이며, 경계 사례에서는 어쨌든 틀릴 것입니다. 여기에 제시된 모델은 그러한 문제들을 (바라건대 현명한) 원로회에 맡깁니다.

의사 결정 과정 (Decision Process)

모든 중요한 결정은 PEP 과정을 거칩니다. 각 PEP에는 책임자가 있으며, 여기서는 “작성자(author)”라고 불리지만, 단일 인물일 필요는 없으며 실제로 텍스트를 작성한 사람일 필요도 없습니다. 따라서 “작성자”는 “옹호자(champion)” 또는 “관리자(shepherd)” 등으로 읽을 수도 있습니다.

PEP 작성자는 PEP에 대한 투표를 조직할 책임이 있습니다. 이 투표는 공개적이며, 즉 투표자는 식별되고 결과는 모든 사람에게 알려집니다. 투표는 단순한 +1/0/-1 방식일 수도 있지만, 투표자가 해당 문제에 대해 매우 강한 감정을 느끼는 이유에 대한 간결한 설명과 함께 +2/-2로 확장될 수도 있습니다. 이러한 주석은 원로회에 대한 설명으로 사용될 것입니다. 투표자에게는 커뮤니티 상태(핵심 개발자 등)가 주석으로 추가됩니다.

투표는 명확하게 정의된 Discourse 카테고리 또는 태그, 특별 메일링 리스트 또는 유사한 기술적 방법(예: vote.python.org와 같은 웹사이트에서 사람들이 로그인하여 커뮤니티 상태가 자동으로 추가되고 신원이 어느 정도 확인될 수 있도록 하는 방식)을 사용하여 토론과 명확하게 분리됩니다.

PEP 작성자는 PEP와 투표 결과를 원로회에 제출합니다. 원로회는 두 가지를 고려합니다:

PEP의 중요도(gravity)와 그 영향
측정 가능한 투표 결과 (몇 명이 투표했는지, 어떤 개인이 투표했는지, 어떻게 투표했는지)

원로회는 투표 통과 여부에 대한 잠정적인 결정을 발표하며, 이 결정은 공개됩니다.

투표 결과가 해당 결정에 대한 커뮤니티의 충분한 지지를 보여주지 못한다고 결정되면, 작성자는 더 많은 지지를 모으고 나중에 투표를 재제출해야 할 책임이 있습니다. 또는 작성자는 제안을 철회할 수 있습니다. 더 많은 지지를 모으는 기간은 한 달이 적절해 보이며, 그 기간 이후에도 투표가 재제출되지 않으면 제안은 반려됩니다.

잠정적인 결정이 결과가 충분한 지지를 보여준다고 판단되면, 비교적 짧은 대기 기간(수 주 정도)이 시작됩니다. 이 기간 동안 누구든지 원로회에 항소(appeal)할 수 있지만, 투표가 커뮤니티의 충분한 다수를 반영하지 않는다는 근거로만 가능합니다. 대기 기간이 지나면 원로회는 최종 결정을 발표합니다. PEP는 수락되거나, 원로회가 항소에 영향을 받으면 더 많은 지지를 보여주어야 하는 상태로 돌아갑니다.

원로회 (Council of Elders)

원로회의 의도는 그들이 함께 특정 투표에서 Python 커뮤니티의 의지가 지켜지는지 판단할 수 있도록 하는 것입니다.

원로회는 BDFL과 동일한 권한을 가진 그룹으로 BDFL을 대체하는 것이 아닙니다. Python의 방향에 대한 지침을 제공하지 않으며, 단지 투표 결과가 커뮤니티의 의지를 대표하는지 확인하려고 합니다. 원로회는 실제 결정권을 가진 미국 대법원과 같지 않으며, 투표 과정만을 감독하여 커뮤니티가 투표에 대표되는지 확인합니다. 그리고 원로회는 스페인 종교 재판과도 전혀 같지 않습니다. (하지만 귀여운 주홍색 예복을 사용하는 데는 어느 정도 장점이 있습니다).

이 위원회는 네덜란드의 Hoge Raad (불행히도 영어로는 종종 대법원으로 번역됨)와 유사하게, 과정과 절차를 판단하고 사건을 재심을 위해 돌려보낼 수 있습니다. 또한, 많은 국가에 있는 선거 위원회(다른 이름으로)와 유사하게 선거를 감독합니다.

위원회 운영 (Council operation)

위원회 구성원은 자원봉사자이며, Python 커뮤니티 내에서 다른 역할도 수행할 가능성이 높습니다 (Python 밖의 삶은 말할 것도 없습니다). 이는 구성원들의 업무 부담을 최소한으로 유지해야 함을 의미합니다. 또한, 개별 위원회 구성원이 언제 위원회 구성원으로서 말하고 언제 자신으로서 말하는지 명확해야 합니다. 그리고 우리는 감정적인 부담에 대해 신경 써야 합니다. 위원회 구성원들은 Python 메일링 리스트의 무작위 비난자들의 결정에 대해 책임을 지지 않아야 합니다.

이 제안은 두 가지 방법을 통해 업무 부담을 최소화하려고 합니다:

대부분의 실제 작업은 PEP 작성자와 커뮤니티가 수행하며, 원로회는 투표를 조직하고 결과를 집계하지 않습니다.
첫 번째 잠정 결정 이면의 아이디어는 원로회의 실수(주로 PEP의 파급력을 오판하는 것)가 치명적이지 않다는 것입니다. 왜냐하면 커뮤니티가 이러한 실수를 지적할 기회를 가지기 때문입니다.

실질적으로 이는 잠정적인 결정이 위원회의 일부에 의해 내려질 수 있으며, 커뮤니티가 이들을 수정할 것을 기대한다는 것을 의미합니다. 2주마다 7명의 근면한 전문가들을 이메일로라도 한자리에 모으는 것은 다소 무리한 요구일 수 있습니다.

개별 원로가 위원회를 대표하여 말하는 시점을 명확히 하는 가장 좋은 방법은 특별 이메일 주소나 원로들만 게시할 수 있는 Discourse 주제를 사용하는 것입니다. 여기에는 교황이 Ex Cathedra (교황으로서 공식적으로) 말하는 것과 개인으로서 말하는 것 (이 경우 무오하지 않음) 사이의 비유가 있습니다. 원로들은 커뮤니티의 존경받는 구성원일 가능성이 높으며, 그들이 위원회에 속해 있다는 이유로 PEP에 대한 개인적인 의견을 표명할 수 없다고 느끼게 하는 것은 좋지 않습니다.

커뮤니티 구성원과 원로회 간의 토론, 즉 결정에 항소할 때의 토론은 다른 포럼(Discourse 주제, 메일링 리스트)에서 이루어져야 합니다.

원로회의 결정은 개별 구성원의 결정이 아닌, 위원회 전체의 결정으로 간주되어야 합니다. 첫 번째 구현에서는 원로들이 자신의 이름으로 게시해야 합니다 (게시하는 주제 또는 특별 배지를 통해 위원회 구성원으로서 말한다는 사실이 전달됨). 만약 원로들이 인신공격의 개별적인 대상이 되는 것으로 밝혀지면, 우리는 이 문제를 재검토하고 익명성을 위한 방법을 모색해야 합니다.

자유의 제한 (Limitation of freedom)

특정 투표에서 핵심 팀 구성원(전체 핵심 팀 구성원의 50% + 1 이상)의 진정한 다수(찬성 또는 반대)가 있다면 그 결과는 통과됩니다. 특정 투표에서 PSF 투표 회원(50% + 1 이상)의 진정한 다수(찬성 또는 반대)가 있다면 그 결과는 통과됩니다. 그리고 완벽을 기하자면, 앞의 두 진술이 모두 사실이지만 반대 결과가 나온 경우 핵심 팀 구성원들이 승리합니다.

이러한 제한을 두는 주된 이유는 특정 순간에 기능하는 원로회가 없더라도 결정이 (노력을 통해) 내려질 수 있도록 하기 위함입니다.

위원회 구성 (Council composition)

위원회는 너무 크지도 작지도 않아야 하며, 아마도 5명에서 10명 사이가 적절할 것입니다. 이 숫자를 고정할 이유는 없습니다. 구성원들은 Python과 Python 커뮤니티에 대해 잘 알고 있어야 하며, 위원회의 일원으로서 공정하게 운영하려는 의지가 있어야 합니다. 위원회 구성원은 핵심 개발자일 수 있지만 필수는 아닙니다.

커뮤니티의 모든 사람이 위원회에 의해 대표된다고 느껴야 하므로 위원회가 다양하면 좋을 것입니다:

과학자와 기술자
진보주의자와 보수주의자 (Python 언어에 대한 관점에서)
다양한 문화적 배경, 성별, 연령 등을 가진 사람들

하지만, 이것은 위원회 전체에 해당되어야 합니다. 개별 위원회 구성원은 특정 이익 집단을 대표하는 것으로 간주되어서는 안 됩니다.

위원회 멤버십 (Council membership)

위원회의 권한이 순전히 절차적이기 때문에 구성원들이 비교적 오랫동안 봉사하는 것이 좋을 것입니다. 그러나 위원회가 정기적으로 재설정되는 것이 여전히 좋을 것입니다. 따라서 위원회가 PSF 산하에서 운영되고 매년 신임 투표(vote of confidence)를 받아야 한다고 제안됩니다. 이 투표는 위원회 전체에 대한 것입니다. 위원회에 반대하는 사람들은 기본적으로 “Python은 당신들 같은 원로회 없이 더 낫다”고 말하는 것임을 인지해야 합니다.

위원회는 일반적으로 새로운 원로를 공동 선임(co-opts)합니다. 이는 아마도 특정 개인이 위원회에 부족한 Python 커뮤니티(또는 언어)의 특정 부분에 대한 지식을 가지고 있다고 여겨지기 때문일 것입니다. 누구나 위원회에 새로운 원로를 제안할 수 있지만 (자신을 포함하여), 위원회는 그 제안을 무시할 수 있습니다. 위원회 구성원들은 언제든지 은퇴할 수 있어야 합니다. 개별 위원회 구성원은 나머지 위원회의 만장일치 투표로 은퇴될 수 있습니다.

기능하지 않는 위원회를 해임하기 위한 비상 제동 절차(emergency brake procedure)가 있습니다. 한 명의 원로 또는 10명의 핵심 개발자 또는 PSF 투표 회원 그룹이 위원회 전체의 즉각적인 재신임 투표를 요청할 수 있습니다 (아마도 위원회가 임무를 상실하게 할 의도일 것입니다). 이 투표가 원로에 의해 요청되었다면 해당 개인은 투표 결과와 관계없이 즉시 위원회 직위를 잃습니다. 투표가 커뮤니티 구성원에 의해 요청되었고 위원회가 재신임되면 이 절차는 1년 동안 다시 호출될 수 없습니다.

기능하는 위원회가 없는 경우(현재 초기 상황 또는 불신임 투표 후 위원회가 임무를 상실한 경우) 초기 위원회를 선출해야 합니다. 일반적인 의사소통 채널(Discourse, 메일링 리스트)을 통해 누구든지 (자신을 포함하여) 구성원을 제안할 수 있습니다. 후보자들 사이의 토론과 전체 커뮤니티 내의 토론 후에, 원로회로 자신들을 임명하기 위한 초기 투표를 요청하는 최소 3명의 개인이 나와야 합니다. 이 절차의 의도는 그러한 개인 그룹이 나타나 신임 투표를 요청할 때 압도적인 지지를 기대한다는 것입니다.

논의 (Discussion)

이 PEP는 BDFL의 다른 역할은 다루지 않으며, 오직 투표 과정만을 다룹니다. 가장 중요한 것은 Python의 장기적인 방향이 원로회에 의해 다루어질 것으로 예상되지 않는다는 것입니다. 이는 전체 커뮤니티(또는 커뮤니티의 개별 구성원)의 몫이 될 가능성이 높습니다.

또한, 외부 세계에 Python과 Python 커뮤니티를 대표하는 상징적인 인물 또는 대변인의 역할도 있습니다. 제 생각으로는 이것 역시 원로회가 처리해야 할 역할이 아니라 다른 사람이나 기관이 맡아야 할 역할입니다.

이 제안은 진보보다는 보수주의를 선호할 가능성이 높다는 점에 유의해야 합니다. 또는 적어도 이것이 초래할 수 있는 정체의 위험이 미지의 영역으로 무모하게 나아가는 위험보다 더 큽니다. 따라서 이 모델이 도입된다면 PEP 572와 같은 PEP가 통과될 가능성은 낮다는 것을 인식해야 합니다.

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

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