PEP 729 – 타이핑 거버넌스 절차

Author:: Jelle Zijlstra <jelle.zijlstra at gmail.com>, Shantanu Jain <hauntsaninja at gmail.com>
Discussions-To:: Discourse thread
Status:: Active
Type:: Process
Topic:: Governance, Typing
Created:: 19-Sep-2023
Post-History:: 04-Oct-2023, 20-Sep-2023
Resolution:: 20-Nov-2023

Table of Contents

번역·라이선스 안내

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

초록

이 PEP는 Python 타입 시스템을 운영하는 새로운 방식, 즉 Python 타입 시스템의 유지와 발전을 책임지는 위원회를 제안합니다. 위원회는 명세와 적합성 테스트 스위트를 유지 관리하며, 처음에는 파이썬 운영 위원회(Python Steering Council)가 위원을 임명합니다.

Python 타입 시스템은 거의 10년 전에 PEP 484에 의해 만들어졌습니다. 현재 타입 시스템은 널리 사용되고 있으며, 타이핑은 유지보수하기 쉬운 좋은 Python 코드를 작성하기 위한 중요한 도구가 되었습니다. 더 많은 사용 사례를 다루고 사용성을 개선하기 위해 타입 시스템에 많은 변경이 이루어졌습니다. 여러 타입 검사기가 만들어졌으며, 각각 고유한 강점을 가지고 있습니다. 타입 어노테이션 문법은 널리 쓰이는 dataclasses 모듈, Pydantic 같은 패키지에 의한 런타임 타입 검사와 검증, mypyc 같은 도구에 의한 정적 컴파일 등 Python 생태계에서 여러 주요 혁신을 이끌어 왔습니다.

그러나 타입 시스템이 성장하면서, 현재의 타입 시스템 관리 방식에 서로 연관된 여러 문제가 있다는 사실이 드러났습니다.

PEP가 유일한 명세입니다

Python 타입 시스템은 처음에 PEP(PEP 484)로 만들어졌으며, 타입 시스템에 대한 변경도 여전히 PEP를 통해 이루어집니다. Python 타입 시스템의 명세라고 할 만한 것이 있다면, 그것은 이 일련의 PEP로 구성되어 있습니다. 하지만 표준 트랙(Standards Track) PEP는 계속 갱신되는 문서나 명세로 의도된 것이 아니라 변경 제안입니다.

예를 하나 들어 여기서의 문제를 설명해 보겠습니다. PEP 484가 typing 모듈을 도입한 것과 거의 같은 시기에, PEP 3156은 Python 3의 성공에 크게 기여한 또 하나의 주요 신기능인 asyncio 모듈을 도입했습니다. 두 모듈 모두 처음 만들어진 이후 크게 발전했으며, 핵심 언어의 변경에도 영향을 주었습니다.

그러나 asyncio와 typing은 본질적인 측면에서 다릅니다. asyncio를 사용하는 사용자는 표준 라이브러리 자체와만 상호 작용하지만, typing 사용자는 외부 도구인 타입 검사기까지 고려해야 합니다. Python 언어 레퍼런스는 typing 모듈의 심볼들을 다루지만, 타입 검사기가 전체 타입 시스템을 어떻게 해석해야 하는지에 대해서는 자세히 다루지 않으며 (다루어서도 안 됩니다). 그러한 내용은 현재 PEP에만 존재합니다.

패키징 생태계도 같은 문제를 겪고 있으며, 별도의 PyPA 명세를 유지 관리하는 방식으로 이를 해결하려 하고 있습니다.

명세를 발전시키기 어렵습니다

우리가 가진 명세는 PEP뿐이므로, 명세의 변경으로 볼 수 있는 모든 것에는 이론상 새로운 PEP가 필요합니다. 하지만 작은 변경에는 그것이 지나치게 무거운 절차인 경우가 많습니다. 그 대신 기존 PEP를 직접 수정하는 경우도 있지만, 이는 수락되고 구현된 PEP는 더 이상 변경해서는 안 되는 역사적 문서가 된다는 원칙에 어긋납니다.

구체적인 예는 다음과 같습니다.

PEP 484는 typing.NoReturn을 인자 어노테이션에 사용할 수 없다고 명시하고 있습니다. 그럼에도 불구하고 타입 검사기들은 오랫동안 그러한 사용을 허용해 왔습니다.
2023년의 한 논의에서는 PEP 561의 부분 스텁(partial stub)에 대한 설명이 불분명하며, 주요 타입 검사기들이 이를 명세된 그대로 구현하지 않았다는 점이 지적되었습니다.
널리 사용되는 서드 파티 typing_extensions 패키지는 새로운 타입 시스템 기능의 백포트를 제공합니다. 타입 검사기는 이 모듈의 심볼을 typing의 심볼과 동일하게 취급할 것으로 기대되지만, 이는 어느 PEP에도 명시적으로 규정되어 있지 않습니다.

타입 시스템의 명세가 불충분합니다

PEP가 명세를 제공하기는 하지만, 충분히 정밀하지 않은 경우가 많습니다(때로는 의도적으로 그렇게 두기도 합니다). 타입 시스템의 조합적 복잡도가 커지면서 이런 현상이 더욱 두드러집니다.

결국 명세가 불충분한 영역을 어떻게 다룰지는 개별 타입 검사기가 결정하게 됩니다. 타입 검사기들이 비공식적으로 조율하는 경우에는 어디에도 명확히 기록되지 않은 사실상의 표준이 생겨나며, 이 때문에 새로 입문하는 사람들이 타입 시스템에 접근하기가 더 어려워집니다. 예를 들면 다음과 같습니다:

@overload 매칭이 동작하는 방식
ParamSpec이 메서드와 함께 동작해야 하는 방식
재귀적 별칭이라는 개념
변수 초기화의 의미론
__exit__에 붙은 어노테이션의 도달 가능성 의미론
심볼 가시성
완전성 검사를 위한 NoReturn 사용

운영 위원회는 위 문제를 해결하기에 적합하지 않습니다

운영 위원회(SC)는 언어 전체를 관할하므로 순수하게 타입 시스템에 관한 결정을 내리기에는 적합하지 않습니다. 다른 이유를 제쳐 두더라도, 운영 위원회는 다른 책무를 수행하면서 타입 시스템의 난해한 세부 사항까지 다룰 시간이 없기 때문입니다. 이는 운영 위원회가 때때로 PEP 위임을 활용하는 이유와 취지가 비슷합니다.

지지 의견

이 PEP는 Rebecca Chen (pytype), Eric Traut (Pyright)를 비롯한 모든 주요 타입 검사기의 유지 관리자들에게 지지를 받았으며, mypy와 Pyre의 유지 관리자들에게서도 비공개적으로 지지를 받았습니다.

명세

우리는 타이핑 위원회(Typing Council)라는 새로운 그룹을 신설할 것을 제안합니다. 이 그룹은 Python 타입 시스템을 개발하고 유지 관리하며, 위 문제들을 해결하는 책임을 맡습니다.

“운영 및 절차” 절에서는 이 그룹이 어떻게 운영되고 관리될지를 설명합니다.

더 흥미로운 “프로젝트” 절에서는 타이핑 위원회가 이끌어 갈 수 있는, 위 문제들에 대한 해결책을 설명합니다.

임무

타이핑 위원회의 임무는 Python 타입 시스템이 다음과 같도록 보장하는 것입니다:

유용성: 타입 시스템은 일반적인 사용 사례에 도움이 되어야 합니다. PEP 484에서 밝힌 바와 같이 주된 사용 사례는 정적 분석이지만, 런타임 타입 검사, 정적 컴파일, IDE 지원, 문서화 등 다른 사용 사례도 있습니다. 타이핑 위원회는 결정을 내릴 때 이러한 사용 사례를 모두 고려해야 하며, 새로운 사용 사례가 생겨나면 이를 지원하는 데에도 열려 있어야 합니다.
사용성: 타입 시스템은 Python 개발자가 쉽게 사용할 수 있어야 합니다. 타입 검사기가 받아들이는, 타입이 올바르게 지정된 Python 코드를 편리하게 작성할 수 있어야 합니다. 타입 시스템에 대한 좋은 문서가 갖춰져 있어야 합니다.
안정성: 타입 시스템이 성숙해 감에 따라 사용자는 타입이 지정된 코드가 계속 동작할 것이라고 믿을 수 있어야 하며, 타입 시스템에 대한 자신의 멘탈 모델을 신뢰할 수 있어야 합니다. 변경은 신중하게, 그리고 혼란을 최소화하는 방식으로 이루어져야 합니다. 그럼에도 타입 시스템은 발전할 수 있어야 하며, 타입 검사기의 동작에 Python 자체와 동일한 호환성 지침을 적용하는 것은 타당하지 않습니다. 물론 typing 모듈에 있는 객체의 존재 여부와 런타임 동작은 PEP 387에 명시된 Python의 표준 호환성 정책을 따릅니다.

운영 및 절차

위원회는 Python 코어 개발자와 주요 타입 검사기의 유지 관리자 등 저명한 커뮤니티 구성원으로 이루어진 3~5명의 위원으로 구성됩니다. 위원에는 타입 검사와 관련된 다양한 프로젝트에 소속된 사람들이 포함되어야 하며, 이러한 프로젝트에는 타입 검사기, CPython, typeshed 또는 기타 프로젝트가 포함될 수 있습니다.

위원회의 초대 위원은 다음과 같습니다.

Eric Traut (Pyright; PEP 647, PEP 681, PEP 695 저자)
Guido van Rossum (코어 개발자; PEP 484, PEP 526 저자)
Jelle Zijlstra (코어 개발자; typeshed; pyanalyze; PEP 688, PEP 702 저자)
Rebecca Chen (pytype)
Shantanu Jain (코어 개발자; typeshed; mypy)

현재 위원회의 구성원은 python/typing-council 저장소에 기록되어 있습니다.

위원의 임기 제한은 없습니다. 위원은 언제든지 사임할 수 있습니다. 각 위원은 연속으로 최대 5년까지 재임한 후 사임할 것으로 기대됩니다.

공석이 생겼을 때 남은 위원이 3명 이상이면, 새 위원을 임명할지는 위원회가 결정합니다. 후임자를 정하기 위해 타이핑 커뮤니티로부터 추천을 받습니다. 자기 추천도 허용됩니다. 그런 다음 기존 타이핑 위원회가 후보자 가운데서 후임 위원을 결정합니다. 이는 위원회의 재량에 따른 결정으로 이루어질 것으로 예상되지만, 타이핑 위원회는 투표를 포함하여 적절하다고 판단하는 어떤 방법으로든 후임자를 선정할 수 있습니다.

타이핑 위원회는 여전히 운영 위원회(Steering Council)에 대해 책임을 집니다. 운영 위원회는 언제든지, 어떤 이유로든 (공개적으로 또는 비공개로) 타이핑 위원회의 구성에 대해 구체적인 변경을 가하거나, 구체적이지 않은 변경을 요청할 수 있습니다.

저희는 이것이 그다지 민주적인 구조가 아니며 타이핑 위원회에 많은 신뢰를 맡기는 구조라는 점을 인정합니다. 하지만 Python 커뮤니티는 그다지 민주적이지 않은 구조로 오랫동안 성공을 거둬 온 역사가 있습니다! 저희는 자체 거버넌스, 구성원 교체, 그리고 운영 위원회에 대한 책임이 Typing Council이 커뮤니티의 요구를 충족하도록 보장하기에 충분할 것이라고 믿습니다.

위원회는 주로 GitHub PR 리뷰를 통해 운영됩니다. 정기 회의는 아마 필요하지 않겠지만, 위원회는 화상 통화, 비공개 채팅, 또는 내부적으로 정하는 그 밖의 어떤 수단이든 마련할 수 있습니다.

위원회는 투명성을 지향해야 하며, 모든 결정을 가능하면 그 근거와 함께 discuss.python.org에 공개적으로 게시해야 합니다. 결정을 내리기 전에 위원회는 관심 있는 모든 커뮤니티 구성원에게 의견을 제시할 기회를 주어야 합니다. 논의가 시작된 시점과 위원회가 결정을 내리는 시점 사이에는 최소 일주일의 기간이 있어야 합니다.

위원회 위원은 PEP를 후원할 자격을 갖게 됩니다. 이 PEP가 수락되면 이 사실을 명시하도록 PEP 1을 개정해야 합니다.

운영 위원회와의 관계

지금과 마찬가지로 Python 운영 위원회는 Python 언어의 전반적인 방향에 대한 책임을 계속 지며, 타이핑 관련 PEP에 대한 결정도 계속 내리게 됩니다. 타이핑 위원회는 타이핑 관련 PEP에 대해 운영 위원회에 서면 의견과 권고를 제공하게 됩니다.

그러나 타입 시스템에 대한 소규모 변경은 타이핑 위원회가 직접 할 수 있습니다. 운영 위원회는 일부 PEP에 대한 결정을 타이핑 위원회에 위임할 수도 있습니다(다른 PEP 위임과 정확히 같은 방식입니다).

과거와 최근의 사안이 이 모델에서 어떻게 처리될 수 있었을지 몇 가지 예를 들면 다음과 같습니다.

언어 문법을 변경하는 PEP 695 (타입 매개변수 문법) 같은 PEP는 운영 위원회가 결정해야 하며, 타이핑 위원회는 의견이나 지지를 제공하는 데 그칩니다. 마찬가지로 PEP 702 (폐지 예고) 같은 PEP는 순수한 타이핑을 넘어서는 런타임 동작과 관련되므로 운영 위원회가 결정하게 됩니다. 운영 위원회가 결정해야 하는 다른 예로는 PEP 718 (첨자 사용 가능한 함수)와 PEP 727 (문서화 메타데이터)가 있습니다.
타입 검사기 사용자에게만 영향을 미치고 언어 전반을 변경하지 않는 PEP 698 (@override) 같은 PEP 역시 기본적으로는 운영 위원회가 결정하게 됩니다. 그러나 이러한 PEP는 결정을 위해 타이핑 위원회에 위임될 수 있습니다(다른 PEP 위임과 마찬가지입니다). 위임될 수 있는 PEP의 다른 예로는 PEP 647 (타입 가드), PEP 655 (개별 필수 TypedDict 항목), PEP 673 (Self), PEP 675 (Literal)이 있습니다.
typing.Never를 typing.NoReturn의 별칭으로 추가하는 것과 같은 소규모 기능 추가는 명세와 적합성 테스트 스위트에 대한 PR을 통해 이루어집니다. 그런 다음 타이핑 위원회가 해당 PR의 병합 여부를 결정하게 됩니다. 위원회는 필요하다고 판단하면 해당 기능을 PEP로 명세하고 논의하도록 요청할 수 있습니다.
최근 PEP 561의 부분 스텁에서 있었던 것처럼 명세 일부의 해석에 혼란이 있는 경우, 누군가가 명세를 명확히 하기 위해 타이핑 명세에 PR을 올리고, 그런 다음 타이핑 위원회가 해당 명세 변경을 결정하게 됩니다.

런타임 typing 모듈은 계속해서 CPython 코어 개발자 팀이 유지 관리합니다. 그러나 타입 검사기의 동작에 영향을 미치는 런타임 모듈의 변경은 모두 명세 변경(아래 참조)과 함께 이루어져야 하며 타이핑 위원회의 승인을 받아야 합니다. 예를 들어 Python 3.11에서 코어 개발자들은 새로운 함수 typing.assert_type()을 추가했습니다. 타이핑 위원회가 있었다면 이 변경에는 그에 맞는 명세 변경과 타이핑 위원회의 승인이 필요했을 것입니다. 한편 Python 3.11에서는 typing.get_overloads() 인트로스펙션 도우미도 추가되었습니다. 이 함수는 타입 검사기의 동작에 영향을 미치지 않으므로 타이핑 위원회의 승인이 필요하지 않았을 것입니다. 그러나 런타임 타입 검사기에 대한 지원은 위원회의 소관이므로, 위원회는 이러한 변경을 주시하고 적절한 경우 피드백을 제공해야 합니다.

타입 검사기와의 관계

타이핑 위원회는 타입 검사기에 대한 직접적인 권한이 없으며, 타입 검사기가 특정 기능을 구현하거나 동작을 변경하도록 강제할 수 없습니다. 타입 검사기는 위원회가 정한 명세를 따를 동기가 있습니다. 명세를 따르면 명세에 부합하는 타이핑 정보를 제공하는 라이브러리, typeshed의 스텁 파일, typing 표준 라이브러리 모듈, 표준 타입 시스템을 다루는 사용자 문서 같은 공유 자원을 활용할 수 있기 때문입니다. 타입 검사기는 타입 시스템을 자유롭게 확장하거나 명세에서 벗어날 수 있지만, 그러한 차이점은 명확하게 문서화해야 합니다.

타입 검사기가 타이핑 위원회의 결정을 구현해야 한다는 사실은 위원회에 유용한 제동 장치로 작용하여, 위원회의 결정이 보수적이고 충분히 숙고된 것이 되도록 합니다. 개별 타입 검사기는 적합하다고 판단하는 대로 자유롭게 혁신할 수 있으며, 성공적인 혁신은 표준 타입 시스템에 통합될 수 있습니다.

프로젝트

타이핑 위원회가 맡게 될 몇 가지 작업은 다음과 같습니다.

적합성 테스트 스위트

적합성 테스트 스위트는 타입 검사기가 Python 코드를 어떻게 검사해야 하는지를 기계로 검증할 수 있는 형태로 문서화하고, 주요 타입 검사기 구현들이 이 테스트 스위트에서 얻은 결과도 함께 제공할 것입니다. 이것이 어떤 모습이 될 수 있는지 보여 주는 대략적인 초안을 Shantanu가 작성했습니다.

여기에는 이전 PEP들이 규정한 동작에 근거한 규범적 테스트와, 어떤 표준으로도 규정되지 않은 영역에서 기존 구현들의 동작을 문서화할 수 있게 해 주는 기술적(descriptive) 테스트가 포함될 것입니다. 이러한 기술은 아래의 작업들에 참고 자료가 되고, 표준화 작업에서 집중할 영역을 파악하는 데 유용할 것입니다.

타입 시스템 명세

명세는 처음에는 기존 PEP들의 명세 부분을 이어 붙여 만들고, 이후 혼란스러운 부분을 명확히 하고 더 많은 영역을 다루도록 점진적으로 개선할 것입니다. 이렇게 이어 붙인 명세의 초안을 Jelle가 작성했습니다.

명세의 대상 독자는 다음과 같습니다.

타입 검사기에게는 이상적인 타입 검사기가 어떻게 동작해야 하는지에 대한 설명을 제공합니다. 개별 타입 검사기는 저마다 다른 목표와 기술적 제약을 가지고 있으므로, 명세를 완전히 구현할 여력이 없거나 다른 동작이 사용자에게 더 도움이 된다고 판단하는 경우에는 명세에서 벗어나도 됩니다. 다만 명세에서 벗어난 부분은 문서화해야 합니다.
typeshed와 같은 프로젝트나 여러 타입 검사기와 호환되기를 원하는 라이브러리에게는 타입 검사기가 자신의 코드를 이해할 수 있도록 따를 수 있는 규칙 모음을 제공합니다.
타입 시스템의 변경을 제안하려는 사람들에게는 모든 새로운 제안의 토대를 제공합니다.

특히 명세는 타입 지정을 사용하는 애플리케이션 개발자를 대상으로 하지 않습니다. 이러한 사용자들은 일반적으로 타입 검사기 간의 호환성을 걱정할 필요가 없습니다. 이들에게는 다음 절에서 다루는, 보다 비공식적인 사용자용 참고 문서가 더 적합합니다.

이러한 명세가 얼마나 형식적이어야 하는지에 대해서는 커뮤니티 내에서 다양한 의견이 있습니다. 이 문서는 기존 명세를 바탕으로 하는 점진적인 접근 방식을 권장하지만, 최종 형태를 규정하려는 것은 아닙니다. 타이핑 위원회는 커뮤니티가 원하는 수준의 형식성에 맞추어 명세가 발전할 수 있도록 하는 체계를 마련할 것입니다. 예를 들어, 명세를 더 잘 형식화하기 위한 수단으로 Kevin Millikin의 “Python Static Types”에 관한 문서 일부를 통합할 수 있습니다.

PEP를 포함하여 명세에 대한 변경 제안에는 일반적으로 다음이 함께 제시되어야 합니다.

변경 사항을 자신들의 타입 검사기에서 구현하고 유지할 수 있음을 확인하는 타입 검사기 유지 관리자들의 동의.
기존 기능을 변경하는 경우, 기존 타입 검사기들의 동작에 대한 조사. 기존 타입 검사기들이 대체로 비슷하게 동작한다면, 이는 그 공통된 동작을 명세의 일부로 삼아야 한다는 근거가 됩니다.
명세된 동작을 보여 주는 적합성 테스트 스위트의 변경.

타입 시스템의 사용자용 참고 문서

문서화는 Python 타입 시스템의 성공에 중요하므로, 타이핑 위원회는 타입 시스템에 대한 좋은 문서가 갖추어지도록 해야 합니다.

앞서 언급했듯이, PEP는 여러 독자를 대상으로 하는 특정 시점의 변경 제안이며 나중에 명확히 다듬기가 어렵습니다. 이 때문에 PEP는 사용자 문서로 적합하지 않습니다. 앞 절에서 논의한 명세는 계속 갱신되는 문서가 되겠지만, 일반적인 사용을 위한 문서로 쓰기에는 지나치게 기술적일 가능성이 높습니다.

따라서 타입 시스템에 대한 사용자 대상의 별도 레퍼런스가 있으면 유용할 것입니다. 이러한 작업을 통해 typing.python.org의 문서를 확장하고, 개별 타입 검사기의 문서 섹션과 CPython 문서의 자료를 재사용할 수 있습니다.

개정

이 PEP는 Typing Council의 헌장 역할을 합니다. Typing Council의 운영에 대한 변경은 새 PEP를 통해서나 이 PEP를 변경하는 방식으로 이루어질 수 있습니다. 어느 경우든, 변경 사항은 커뮤니티에서 논의를 거친 후 운영 위원회가 결정합니다.

기각된 아이디어

명세를 처음부터 작성하기

이 PEP는 기존 PEP에서 출발하여 필요에 따라 명세를 명확히 하고 개선하는 방식으로 타이핑 명세를 만들 것을 제안합니다. 커뮤니티의 일부 구성원은 처음부터 시작하여 타입 시스템 전체를 다루는 새롭고 더 형식적인 명세를 작성하는 방식을 선호합니다. 이렇게 하면 명세에 더 견고한 기반을 마련할 수 있을 것입니다.

하지만 이는 훨씬 더 큰 작업이 될 것입니다. Kevin Millikin이 진행 중인 기존의 형식화 작업은 좋은 출발점이지만, 지금까지는 PEP 484의 일부만 다루고 있습니다. typing.Protocol, typing.Literal, typing.TypedDict와 같은 주요 타입 시스템 기능이 PEP 484 이후에야 도입되었다는 점을 고려하면, 타입 시스템의 나머지 부분을 다루려면 아마도 몇 배 더 많은 노력이 필요할 것입니다. 커뮤니티에 이처럼 거대한 작업을 감당할 여력이 있는지조차 분명하지 않습니다. 누군가 나서서 명세를 작성하는 모든 작업을 맡는다 하더라도, 명세가 현재 동작을 정확하게 반영하는지, 그렇지 않다면 명세와 타입 검사기 중 어느 쪽을 바꿔야 하는지 검토하기 위해 커뮤니티 구성원과 타입 검사기 유지 관리자들이 많은 노력을 들여야 합니다.

기존 PEP에서 시작하면 품질이 더 낮은 명세가 만들어지지만, 그 대신 Typing Council이 명세를 개선하고 명확히 함으로써 타입 시스템의 어느 부분에서든 즉시 변화를 만들어 내기 시작할 수 있습니다. 형식화 작업은 명세의 섹션을 점진적으로 대체하는 방식으로 여전히 진행될 수 있습니다.

대안적 거버넌스 메커니즘

이 PEP의 초기 초안에서는 운영 위원회가 매년 Typing Council의 위원을 임명하도록 제안했습니다. 현재 운영 위원회는 Typing Council이 스스로 조직을 꾸려 운영 위원회가 Typing Council을 지속적으로 감독할 필요가 없도록 하는 편이 더 낫다고 제안했습니다.

더 민주적인 방식을 포함하여 대안적인 거버넌스 메커니즘도 가능하지만, 이러한 방식은 대개 여러 까다로운 문제를 제기하고, 훨씬 더 많은 절차를 요구하며, 잠재적으로 더 큰 분열을 초래할 수 있습니다. 예를 들어 PEP 8000 시리즈나, 다른 Python 하위 커뮤니티에서 최근 이루어진 대안적 거버넌스에 관한 논의를 참고하십시오. 결국 Typing Council은 운영 위원회의 권한 아래에 존재하므로, 거버넌스를 처음 세우는 일과 책임을 묻는 장치의 역할을 운영 위원회에 맡길 수 있습니다.

Python 개선 제안 한국어 번역