Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

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

Author:
Jack Jansen
Status:
Rejected
Type:
Informational
Topic:
Governance
Created:
16-Sep-2018
Table of Contents

번역·라이선스 안내

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

초록

이 PEP는 절차, 정의된 용어, 비율을 가능한 한 적게 두는 거버넌스 모델을 제안합니다. 이 모델은 무정부주의 거버넌스 모델이라고 부를 수도 있습니다. 하지만 일부 독자에게는 무정부주의라는 용어가 부정적으로 받아들여질 수 있어서 당분간은 커먼스라는 이름을 사용합니다.

기본 개념은 이렇습니다. 원칙적으로는 모든 결정을 커뮤니티 전체가 투표로 정하지만, 실제로는 커뮤니티의 일부만 투표합니다. 일부라고 하는 이유는 커뮤니티 전체에 투표권이 있더라도 실제로 특정 결정에 투표하는 사람은 언제나 소수에 불과하기 때문입니다. 투표는 공정한 위원회가 감독하며, 이 위원회가 결정의 통과 여부를 판단합니다. 이 위원회는 찬성표와 반대표의 비율만 보지 않고 전체 투표 수와 투표 대상 제안의 중대성도 판단 근거로 삼습니다. 경우에 따라서는 개별 투표자가 누구이며 어떻게 투표했는지도 함께 고려하도록 하려는 것입니다. 이를 통해 이 위원회는 각각의 결정이 충분한 다수의 지지를 받아 통과되도록 보장할 책임을 지게 됩니다.

PEP 거부

PEP 8014는 2018년 12월 17일 월요일에 PEP 8001에 기술된 핵심 개발자 투표로 거부되었습니다.

대신 PEP 8016과 그 PEP가 기술하는 거버넌스 모델이 채택되었습니다.

소개

Commons 거버넌스 모델은 모든 결정이 Python 커뮤니티의 충분한 다수에게 지지받거나, 적어도 받아들여질 수 있도록 하려고 합니다.

안타깝게도 앞 문단에는 일반적인 경우에 정량화하기가 매우 어려운 용어가 두 개 있는데, 바로 충분한 다수와 Python 커뮤니티입니다. 두 용어 모두 실제로는 결정 대상이 되는 구체적인 사안에 따라 달라지기 때문입니다. 이 어려움의 예를 들자면, 어떤 API에 하위 호환되는 변경을 제안하는 PEP라면 애초에 그 PEP에 대한 투표에 관심이 있었던 코어 개발자의 단순 과반수로 아마 충분할 것입니다. 그러나 Python3에서 Python4로의 전환처럼 더 광범위한 영향을 미치는 변경이라면 실질적인 과반수가 필요할 수 있습니다. 또한 적어도 사용자층에서도 충분한 지지가 있어 보인다는 점을 입증해야 할 수도 있습니다. 그리고 비포용적 언어를 폐지하는 결정처럼 언어로서의 Python을 넘어서는 변경이라면 매우 모호해집니다.

Commons 거버넌스 모델은 충분한 다수와 Python 커뮤니티라는 용어가 일반적인 경우에 무엇을 의미하는지 정의하지 않고, 대신 구체적인 경우마다 이를 결정할 기구를 제안함으로써 이 문제를 비켜 가려 합니다.

이 모델은 원로 위원회를 두자고 제안합니다. 원로 위원회는 결정 과정을 감독하고 특정 제안이 충분한 지지를 받았는지를 사안별로 판단합니다. 모든 개별 PEP에 대해 투표가 이루어지며, 원로 위원회는 투표 결과가 이 구체적인 경우에 결정을 통과시키기에 충분한지를 선언합니다.

이 모델은 결정 과정에서 전통적으로 BDFL이 맡아 온 역할만 다루며, 그 밖의 역할은 다루지 않습니다.

모델 이름의 Commons라는 용어는 이 단어의 역사적 용법에서 느슨하게 따온 것입니다. 역사적으로 이 단어는 모두가 사용하고 모두가 돌보는 공유 자원을 뜻했습니다. 이 모델을 떠올릴 때 머릿속에 그려야 할 장면은 이렇습니다. 따뜻한 여름 저녁, 마을 공터에서 꽤 많은 농민이 미래의 어떤 계획을 논의합니다. 그런 다음 투표를 하고, 마을 원로들이 결과를 발표합니다. 그런 다음 연회가 시작됩니다.

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

근거

이 모델의 근거는 모든 것을 확정적으로 못 박아 두는 모델이 의도하지 않은 부정적인 부작용을 낳는다는 것입니다. 예를 들어 Python 커미터에게 투표권을 부여하는 거버넌스 모델에서는, 새 후보가 일하는 회사 출신 커미터가 이미 많다는 이유로 그 사람이 커미터로 받아들여지지 않는 일이 생길 수 있습니다.

또 다른 예로, PEP 승인에 고정된 비율을 설정하면 투표자들 사이에 파벌이 형성될 수 있습니다. 그러면 개별 PEP가 그 자체의 장점이 아니라 파벌에 따라 평가될 수 있습니다(내 PEP를 지지해 주면 당신의 PEP도 지지하겠다는 식으로).

또한 Python과 같은 대상에는 1인 1표 방식이 최선의 모델이 아니라는 문제도 있습니다. 다시 예를 들자면, 투표 결과가 갈리는 경우(또는 갈리는 것에 충분히 가까운 경우) 코어 개발자 Guido van Rossum의 의견은 아마도 코어 개발자 Jack Jansen의 의견보다 더 무게를 가져야 할 것입니다. 이를 투표 모델로 형식화하려고 하면 매우 복잡한 모델이 만들어질 것이고, 그 모델은 어차피 경계 사례에서 틀리게 될 것입니다. 여기서 제시하는 모델은 이러한 문제에 대한 결정을 (바라건대 분별 있는) 원로 평의회에 맡깁니다.

결정 절차

모든 중요한 결정은 PEP 절차를 거칩니다. 각 PEP에는 이를 책임지는 사람이 있으며, 여기서는 이를 저자라고 부르지만, 반드시 한 사람일 필요는 없고 실제로 본문을 쓴 사람일 필요도 없습니다. 따라서 저자를 옹호자나 인도자 또는 그와 비슷한 의미로 읽어도 됩니다.

PEP 작성자는 PEP에 대한 투표를 조직할 책임이 있습니다. 이 투표는 공개적입니다. 즉, 투표자가 누구인지 밝혀지며 결과는 모두에게 알려집니다. 투표는 단순한 +1/0/-1 방식일 수도 있지만, 투표자가 해당 사안에 대해 왜 매우 강한 의견을 갖는지 아주 간결하게 설명하는 +2/-2로 확장될 수도 있습니다. 이러한 어노테이션은 장로 위원회(Council of Elders)에 대한 설명 역할을 합니다. 투표자에게는 커뮤니티에서의 지위(코어 개발자 등)가 주석으로 표시됩니다.

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

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

  • PEP의 중대성과 그 영향,
  • 측정 가능한 투표 결과(몇 명이 투표했는지, 어떤 사람들이 투표했는지, 무엇에 투표했는지).

평의회는 투표가 통과되었는지에 대한 잠정 결정을 선언하며, 이 결정은 공표됩니다.

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

결과가 충분한 지지를 실제로 보여 준다는 잠정 결정이 내려지면, 상당히 짧은 대기 기간(몇 주 정도)이 시작됩니다. 이 기간 동안 누구나 원로 평의회에 이의를 제기할 수 있지만, 투표가 커뮤니티의 충분한 다수를 반영하지 않는다는 근거로만 가능합니다. 대기 기간이 지나면 평의회는 최종 결정을 선언합니다. PEP는 수락되거나, 평의회가 이의 제기에 설득되면 더 많은 지지를 입증해야 하는 상태로 되돌아갑니다.

원로 평의회

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

원로 평의회는 BDFL을 BDFL과 같은 권한을 가진 사람들의 집단으로 대체하는 것이 아닙니다. 평의회는 Python의 방향에 대한 지침을 제공하지 않으며, 투표 결과가 커뮤니티의 의지를 대변하도록 보장하려 할 뿐입니다.

원로 평의회는 실제 결정 권한을 가진 미국 연방 대법원과 같지 않습니다. 평의회는 투표에 커뮤니티가 대변되도록 투표 절차를 감독할 뿐입니다. 그리고 원로 평의회는 결코 스페인 종교 재판소와 같지 않습니다. 공포, 기습, 무자비한 효율성은 우리에게 필요 없는 것들이기 때문입니다(다만 귀여운 진홍색 예복을 입는 데에는 어느 정도 장점이 있습니다).

평의회는 과정과 준수된 절차를 판단하고 사건을 새로운 판단을 위해 돌려보낼 수만 있다는 점에서 네덜란드의 Hoge Raad(안타깝게도 영어로는 흔히 Supreme Court로 번역됩니다)와 다소 비슷합니다.

또한 선거를 감독한다는 점에서, 많은 나라에 (이름은 다르지만) 존재하는 선거관리위원회와도 다소 비슷합니다.

평의회 운영

위원회 위원은 자원봉사자이며, Python 커뮤니티 안에서 다른 역할도 맡고 있을 가능성이 높습니다(Python 바깥의 삶은 말할 것도 없습니다). 따라서 구성원의 업무 부담을 최소한으로 유지해야 합니다. 또한 개별 평의회 구성원이 언제 평의회 구성원으로서 발언하고 언제 개인으로서 발언하는지가 명확해야 한다는 뜻이기도 합니다. 그리고 정서적 부담도 신경 써야 합니다. 위원회 위원이 Python 메일링 리스트에서 아무렇게나 비난을 퍼붓는 사람들에게 결정에 대한 책임을 추궁당해서는 안 됩니다.

이 제안은 두 가지 방법으로 업무 부담을 최소화하고자 합니다:

  • 실제 작업의 대부분은 PEP 작성자와 커뮤니티가 수행하며, 원로 평의회는 투표를 조직하거나 결과를 집계하지 않습니다.
  • 첫 번째 잠정 결정의 바탕에 있는 생각은 원로 평의회의 실수(대개는 PEP의 파급 범위를 잘못 판단하는 것)가 치명적이지 않다는 것입니다. 커뮤니티가 이러한 실수를 지적할 기회가 있기 때문입니다.

    실질적으로 이는 바로잡는 일을 커뮤니티에 맡기고, 평의회의 일부 구성원만으로도 잠정 결정을 내릴 수 있다는 뜻입니다. 바쁘게 일하는 전문가 일곱 명을 2주마다 한자리에 모으는 것은 이메일로 하더라도 다소 무리한 요구일 수 있습니다.

개별 원로가 언제 평의회를 대표하여 발언하는지를 명확히 하려면, 특별한 이메일 주소나 원로만 글을 올릴 수 있는 Discourse 토픽을 사용하는 것이 아마 가장 좋은 방법일 것입니다. 이는 교황이 Ex Cathedra로 말하는 경우와 단지 개인으로서 말하는 경우(이때 교황은 무류하지 않습니다)에 비유할 수 있습니다. 원로들은 커뮤니티에서 존경받는 구성원일 가능성이 높으므로, 평의회에 속해 있다는 이유로 PEP에 대한 개인적인 의견을 말할 수 없다고 느낀다면 좋지 않을 것입니다.

커뮤니티 구성원과 원로 평의회 간의 논의, 즉 결정에 이의를 제기하는 경우의 논의는 별도의 포럼(Discourse 토픽, 메일링 리스트)에서 이루어져야 합니다.

원로 평의회의 결정은 개별 구성원의 결정이 아니라 평의회 전체의 결정으로 간주되어야 합니다. 최초 구현에서는 원로들이 자신의 이름으로 글을 올려야 합니다(평의회 구성원으로서 발언한다는 사실은 글을 올리는 토픽이나, 경우에 따라서는 특별한 배지로 나타냅니다). 원로들이 개별적으로 인신공격의 표적이 되는 것으로 드러난다면, 이 방식을 재검토하고 익명성을 보장할 방법을 마련해야 합니다.

자유의 제한

특정 투표에서 코어 팀 구성원의 실질적 과반수(찬성이든 반대든)(전체 코어 팀 구성원의 50% + 1 초과)가 나오면 그 결과가 통과됩니다. 특정 투표에서 PSF 투표권 회원의 실제 과반수(50% + 1 초과)가 찬성 또는 반대하면 그 결과가 통과됩니다. 그리고 완전성을 위해 덧붙이자면, 앞의 두 진술이 모두 참이지만 결과가 서로 반대라면 코어 팀 구성원 쪽이 우선합니다.

이러한 제한을 두는 주된 이유는 어느 시점에 제대로 기능하는 원로 평의회가 없더라도 (노력이 들기는 하지만) 결정을 내릴 수 있게 해 주기 때문입니다.

평의회 구성

평의회는 너무 크지도 너무 작지도 않아야 하며, 아마 5명에서 10명 사이가 적당할 것입니다. 이 숫자를 고정할 이유는 없습니다. 위원은 Python과 Python 커뮤니티에 대해 잘 알고 있어야 하며, 위원회의 일원으로 활동하는 동안에는 기꺼이 공정한 태도를 유지해야 합니다. 위원회 위원은 코어 개발자일 수 있지만, 이것이 필수 요건은 아닙니다.

커뮤니티의 모든 사람이 평의회가 자신을 대변한다고 느낄 수 있어야 하므로, 평의회가 다양하게 구성되는 것이 좋습니다:

  • 과학자와 기술자,
  • (Python 언어와 관련하여) 진보주의자와 보수주의자,
  • 다양한 문화적 배경, 성별, 연령의 사람들,
  • 기타

다만 이는 평의회 전체에 대해 성립해야 합니다. 개별 평의회 구성원이 특정 이익 집단을 대표하는 것으로 여겨져서는 안 됩니다.

평의회 구성

평의회의 권한은 순전히 절차적인 것이므로, 구성원이 상당히 오랜 기간 재임하는 것이 아마도 바람직할 것입니다. 그렇지만 평의회를 정기적으로 재신임하는 것 역시 여전히 바람직할 것입니다. 따라서 평의회가 PSF 산하에서 운영되고 매년 신임 투표를 받도록 할 것을 제안합니다. 이 투표는 평의회 전체에 대한 것입니다. 평의회에 반대표를 던지는 사람은 사실상 “Python은 당신들이 있는 것보다 원로 평의회(Council of Elders)가 없는 편이 낫다”고 말하는 것임을 알고 있어야 합니다.

평의회는 보통 새로운 원로를 호선하며, 이는 아마도 평의회에 부족한 Python 커뮤니티(또는 언어)의 특정 분야에 관한 지식을 해당 인물이 갖추고 있다고 여겨지기 때문일 것입니다. 누구나 (자기 자신을 포함하여) 새로운 원로를 평의회에 자유롭게 추천할 수 있지만, 평의회는 그 추천을 자유롭게 무시할 수 있습니다. 평의회 구성원은 언제든지 자유롭게 물러날 수 있어야 합니다. 개별 평의회 구성원은 나머지 평의회 구성원 전원의 만장일치 투표로 물러나게 할 수 있습니다.

제대로 기능하지 않는 평의회를 해산하기 위한 비상 제동 절차가 있습니다. 원로 한 명, 또는 코어 개발자나 PSF 투표권 회원 10명으로 이루어진 집단은 평의회 전체에 대한 즉각적인 재신임 투표를 요청할 수 있습니다(아마도 평의회가 권한을 잃게 하려는 의도일 것입니다). 이 투표를 원로가 요청한 경우, 해당 인물은 투표 결과와 관계없이 즉시 평의회 직위를 잃습니다. 커뮤니티 구성원이 투표를 요청했고 평의회가 재신임된 경우, 이 절차는 1년 동안 다시 발동할 수 없습니다.

기능하는 평의회가 없는 경우(현재의 초기 상황, 또는 불신임 투표로 평의회가 권한을 잃은 이후)에는 초기 평의회를 선출해야 합니다. 일반적인 소통 채널(discourse, 메일링 리스트)을 통해 누구나 (자기 자신을 포함하여) 구성원을 추천할 수 있습니다. 후보자들 사이에서, 그리고 커뮤니티 전체에서 논의를 거친 후, 자신들을 원로 평의회로 임명하기 위한 초기 투표를 요청하는 최소 3명 이상의 집단이 나타나야 합니다. 이 절차의 취지는, 그러한 집단이 나타나 신임 투표를 요청할 즈음에는 이들이 압도적인 지지를 기대할 수 있어야 한다는 것입니다.

논의

이 PEP는 BDFL의 다른 역할은 다루지 않으며, 투표 절차만을 다룹니다. 가장 중요한 점으로, Python의 장기적인 방향은 원로 평의회가 다룰 것으로 예상되지 않습니다. 이는 커뮤니티 전체(또는 아마도 커뮤니티의 개별 구성원)의 몫입니다.

또한 외부 세계에 대해 Python과 Python 커뮤니티를 대표하는 상징적 인물 또는 대변인의 역할도 있습니다. 이 역시 제 의견으로는 원로 평의회가 맡아야 할 역할이 아니며, 다른 어떤 사람이나 기구가 맡아야 합니다.

이 제안은 진보보다 보수를 선호할 가능성이 매우 높다는 점에 유의하십시오. 적어도, 이 제안이 정체로 이어질 위험이 미지의 영역으로 무모하게 돌진하는 결과로 이어질 위험보다 더 큽니다. 그러므로 이 모델이 시행된다면 PEP 572와 같은 PEP는 통과되기 어려울 것임을 인식해야 합니다.