[Withdrawn] PEP 481 - Migrate CPython to Git, Github, and Phabricator

September 26, 2025

원문 링크: PEP 481 - Migrate CPython to Git, Github, and Phabricator

상태: Withdrawn 유형: Process 작성일: 29-Nov-2014

PEP 481: CPython을 Git, GitHub, Phabricator로 이전하기

작성자: Donald Stufft
상태: 철회됨 (Withdrawn)
유형: 프로세스 (Process)
생성일: 2014년 11월 29일

요약 (Abstract)

참고: 이 PEP는 철회되었으며, GitHub로의 이전 과정을 문서화한 PEP는 PEP 512를 참조해야 합니다.

이 PEP는 CPython 및 관련 저장소의 호스팅을 Git 및 GitHub로 이전하고, 변경 사항 검토를 위해 GitHub Pull Request 외에 Phabricator를 대안으로 추가할 것을 제안합니다. 이 PEP는 Mercurial을 지원하고 완전히 오픈 소스(Open Source)인 도구만을 사용하는 PEP 474 및 PEP 462의 대안으로 제시되었습니다.

배경 (Rationale)

CPython은 자원봉사자들의 시간에 의존하는 오픈 소스 프로젝트입니다. 프로젝트의 건강한 인력 유지를 위해 새로운 자원봉사자를 유치하고 기존 자원봉사자를 유지하는 것이 중요합니다. 또한, 현재 가용한 인력을 효과적으로 활용해야 합니다.

현재 CPython 프로젝트의 툴체인(toolchain)은 독자적인(custom) 도구 조합과 워크플로우(workflow)를 사용하는데, 이는 오래된 프로젝트에서 흔히 볼 수 있는 방식이지만 시간이 지남에 따라 점점 인기가 줄어들고 있습니다. 이러한 독자적인 툴체인과 워크플로우는 새로운 기여자가 CPython에 기여하기 전에 도구와 워크플로우를 학습하는 데 시간을 투자해야 하는 장벽으로 작용합니다. 또한, 학습한 지식을 다른 프로젝트에 적용하기 어렵기 때문에 잠재적인 새로운 기여자를 단념시킬 수 있습니다.

현재 CPython이 사용하는 도구는 유지보수가 부족하고(under-maintained), 노후되었으며(antiquated), 변경 사항을 검토하고 승인하는 데 필요한 중요한 기능이 부족합니다. 예를 들어, 커밋(commit) 사전 테스트 기능이나 자동 병합(merge) 도구의 부재는 커미터(committer)들이 간단한 변경 사항을 커밋하기 위해서도 불필요한 작업을 해야 함을 의미합니다.

버전 관리 시스템 (Version Control System)

주요 서버 측 저장소의 VCS(Version Control System)를 결정하는 것이 첫 번째 단계입니다. 현재 CPython 및 일부 지원 저장소는 Mercurial을 사용합니다. VCS를 평가할 때는 VCS 자체의 기능뿐만 아니라 커뮤니티의 네트워크 효과(network effect)와 인지도(mindshare)를 고려해야 합니다.

Mercurial과 Git, 두 가지 주요 옵션이 있으며, 기술적 기능은 대체로 비슷합니다. 따라서 이 PEP는 기술적 논쟁보다는 사회적 측면에 중점을 둡니다.

인기: The Open Hub(이전 Ohloh) 통계에 따르면 Git은 Mercurial보다 약 18배 더 인기가 많습니다. PyPI 상위 100개 프로젝트에서는 Git이 Mercurial보다 약 3배 더 많이 사용됩니다.
새로운 기여자: Git은 더 널리 사용되므로 새로운 기여자가 이미 Git에 익숙할 가능성이 높으며, 학습한 지식을 다른 프로젝트에 적용하기 용이합니다. 또한, 더 큰 커뮤니티는 Git 관련 자료와 지원이 풍부함을 의미합니다.
도구 생태계: 더 큰 커뮤니티는 GUI 클라이언트, 헬퍼 스크립트, 저장소 호스팅 등 Git 주변에 더 많은 도구가 개발됨을 의미합니다.

이러한 이유로 Git이 오픈 소스 프로젝트를 위한 분산 버전 관리 시스템(DVCS)으로 훨씬 더 인기가 많으며, 인기 있는 VCS를 선택하는 것이 여러 가지 긍정적인 이점을 가져다줍니다.

저장소 호스팅 (Repository Hosting)

이 PEP는 GitHub Pull Request 제출을 허용할 것을 제안하지만, GitHub는 자체 호스팅되지 않은 저장소에 대해 Pull Request를 제출할 방법을 제공하지 않습니다. 이 PEP는 GitHub Pull Request와 더불어 Phabricator의 Differential 앱을 사용하여 변경 사항을 제출할 수도 있다고 제안합니다. Phabricator는 자체 호스팅되지 않은 저장소에 대한 변경 사항 제출을 허용합니다.

따라서 이 PEP는 GitHub를 저장소의 공식적인(canonical) 위치로 사용하고, Phabricator에는 읽기 전용 미러(read-only mirror)를 두는 것을 제안합니다. 만약 미래에 GitHub 사용이 더 이상 바람직하지 않게 되면, 저장소 호스팅은 쉽게 Phabricator로 완전히 옮겨질 수 있으며, GitHub Pull Request 수락 기능은 중단될 수 있습니다. 또한, 모든 저장소의 읽기 전용 복사본은 PSF(Python Software Foundation) 인프라에도 미러링됩니다.

코드 리뷰 (Code Review)

현재 CPython은 Rietveld의 커스텀 포크(custom fork)를 사용하고 있으며, 이는 현대적인 코드 리뷰(code review) 도구에 있는 많은 기능이 부족합니다.

이 PEP는 GitHub Pull Request와 Phabricator 변경 사항 모두를 통해 변경 사항을 제안하고 코드를 리뷰할 수 있도록 허용할 것을 제안합니다. 이는 기여자가 가장 편한 도구를 선택하여 변경 사항을 제출하고, 리뷰어가 가장 선호하는 도구에서 변경 사항을 검토할 수 있도록 하기 위함입니다.

GitHub Pull Requests

GitHub는 매우 인기 있는 코드 호스팅 사이트이며, 프로젝트에 기여하려는 사람들이 가장 먼저 찾는 곳이 되고 있습니다. GitHub를 통해 기여할 수 있도록 하는 것은 기여자들이 이미 익숙한 도구를 사용하거나, 학습하더라도 다른 프로젝트에 적용할 수 있는 도구를 사용하여 기여할 수 있도록 돕습니다.

GitHub Pull Request는 “버그 트래커(bug tracker)에 패치(patch) 제출”이라는 구식 모델에 비해 상당한 이점을 가집니다. 개발자는 표준 VCS 도구를 사용하여 VCS 내에서 완전히 작업할 수 있으므로, 패치 파일을 생성하고 업로드 위치를 파악할 필요가 없습니다. 이는 변경 사항을 리뷰에 보내는 장벽을 낮춥니다.

리뷰 측면에서 GitHub Pull Request는 통일 또는 나란히(side-by-side) 보기에서 작동하는 구문 강조(syntax highlighted) diff를 제공하여 훨씬 쉽게 리뷰할 수 있습니다. 또한, diff의 컨텍스트(context)를 전체 파일까지 확장할 수 있으며, 인라인(inline) 및 Pull Request 전체에 댓글을 달 수 있고, 더 이상 유효하지 않은 댓글은 숨길 수 있습니다. GitHub는 또한 렌더링된 마크업(rst 등)의 diff를 쉽게 볼 수 있는 “렌더링된 diff” 보기를 제공합니다.

Pull Request 워크플로우는 변경 사항을 실제로 병합하기 전에 사전 테스트(pre-test)할 수 있는 기능을 쉽게 제공합니다. 각 Pull Request에는 여러 유형의 “커밋 상태(commit statuses)”가 적용되어 커밋(및 Pull Request)이 대기 중, 성공, 오류 또는 실패 상태임을 표시할 수 있습니다. 이를 통해 Pull Request가 모든 테스트를 통과하는지, 기여자가 CLA(Contributor License Agreement)에 서명했는지 등을 인라인으로 쉽게 확인할 수 있습니다.

GitHub Pull Request 병합은 간단하며, 핵심 리뷰어(core reviewer)는 모든 검사 상태가 성공적으로 초록색이 되면 “Merge” 버튼을 누르면 됩니다.

GitHub는 웹 인터페이스를 통해서도 Pull Request를 제출하는 좋은 워크플로우를 제공합니다. 이는 Python 문서의 모든 페이지에 “Edit on GitHub” 버튼을 제공하여, 오타, 부정확성 또는 개선 사항을 발견한 사람들이 버튼을 눌러 브라우저 내 에디터에서 변경 사항을 만들고 Pull Request를 제출할 수 있게 합니다.

Phabricator

이 PEP는 GitHub Pull Request 외에도 Phabricator 인스턴스를 설정하고 GitHub 호스팅 저장소를 가리키게 할 것을 제안합니다. 이는 Phabricator의 Differential 및 Audit 리뷰 애플리케이션을 활용할 수 있게 합니다. Differential은 GitHub Pull Request와 유사하게 작동하지만, 패치를 Phabricator에 업로드하려면 arc 명령줄 도구를 설치해야 합니다. Phabricator 활성화 여부는 저장소별로 사례별로 선택할 수 있지만, CPython 저장소에는 활성화되어야 한다고 제안하며, PEP 저장소와 같은 작은 저장소에는 노력이 불필요할 수 있습니다.

비판 (Criticism)

X는 Python으로 작성되지 않았다 (X is not written in Python)

현재 도구(Mercurial, Rietveld)의 한 가지 특징은 모든 구성 요소의 주요 언어가 Python으로 작성되었다는 점입니다. 이 PEP는 Python으로 작성된 도구 중 최고보다는 작업에 가장 적합한 도구에 초점을 맞춰야 한다고 주장합니다. 자원봉사자의 시간은 오픈 소스 프로젝트의 소중한 자원이므로, 도구 자체의 장단점에 초점을 맞추는 것이 도구가 어떤 언어로 작성되었는지에 초점을 맞추는 것보다 더 중요하다고 봅니다.

도구를 수정하여 우리에게 맞게 작동시킬 수 있는 능력에 대한 우려도 있지만, 이 PEP의 목표 중 하나는 소프트웨어를 수정하는 대신 더 표준적인 워크플로우에 우리 자신을 맞추는 것입니다. 이러한 표준화는 도구를 즉시 재사용할 수 있게 하여 개발자 시간을 절약하고 프로젝트 간 지식 공유를 가능하게 합니다.

Git 자체는 CPython과 마찬가지로 C로 작성되었으며, Python을 포함한 모든 언어로 명령을 작성할 수 있습니다. Phabricator는 웹 세계에서 흔하고 배우기 쉬운 PHP로 작성되었습니다. GitHub 자체는 Ruby로 작성되었지만 오픈 소스가 아니므로 수정할 수 없어 구현 언어는 무의미합니다.

GitHub는 Free/Open Source가 아니다 (GitHub is not Free/Open Source)

GitHub는 이 제안의 큰 부분이며, 실용성보다는 이념에 더 치우친 사람들은 이 PEP에 반대할 수 있습니다. 이 PEP는 완전히 Free/Open Source 소프트웨어를 사용하는 것이 매력적인 아이디어이자 고귀한 목표이지만, 기여자들에게 잘 유지보수되고 이미 알고 있거나 다른 프로젝트에 적용할 수 있는 좋은 도구를 제공하여 그들의 시간을 소중히 여기는 것이 Free/Open Source 여부를 엄격한 요구 사항으로 여기는 것보다 더 중요하다고 주장합니다.

그러나 역사는 때때로 자비로운 사유 기업이 자비롭지 않게 변할 수 있음을 보여주었습니다. 이에 대한 대비책은 다음과 같습니다:

GitHub 이슈 트래커(Issue Tracker)는 사용하지 않습니다. 이는 CPython에 충분히 강력하지 않고, 만약 GitHub를 떠나야 할 경우 이슈를 다른 곳으로 옮길 수 있는 능력이 GitHub API(Application Programming Interface) 액세스에 의존하기 때문입니다.
GitHub Pull Request 워크플로우를 사용하지만, 모든 변경 사항은 Git 내에 존재합니다. 따라서 GitHub 저장소의 미러는 모든 Pull Request를 쉽게 포함할 수 있습니다. GitHub가 갑자기 “악”하게 변하면 댓글은 손실될 수 있지만, 변경 사항 자체는 여전히 존재합니다.
GitHub 저장소 호스팅 기능을 사용하지만, 이는 Git이므로 저장소를 다른 위치로 푸시(push)하는 것만으로 GitHub에서 벗어나는 것이 간단합니다. 저장소 자체의 데이터 이식성(portability)은 매우 높습니다.
GitHub를 사용하고 싶지 않은 사람들을 위한 대안으로 Phabricator도 활용합니다. 이는 GitHub 사용을 중단해야 할 경우 이미 마련된 대체 옵션(fallback option) 역할을 합니다.

GitHub에 의존하는 것은 플랫폼 자체의 이점 외에도 여러 이점을 제공합니다. 상업적으로 지원되는 기업이므로 서비스를 유지보수하는 전담 직원이 있습니다. 여기에는 서비스 유지, 다양한 보안 취약점에 대한 패치 적용, 시간이 지남에 따라 소프트웨어 및 인프라 개선이 포함됩니다.

Mercurial이 Git보다 낫다 (Mercurial is better than Git)

Mercurial과 Git 중 어느 것이 기술적으로 더 나은지에 대한 질문은 주관적인 의견입니다. 이 PEP는 Git 또는 Mercurial의 메커니즘이 더 낫다고 말하지 않고, 대신 각 옵션에 사용 가능한 네트워크 효과에 중점을 둡니다. 이 PEP는 Git으로의 전환을 제안하므로 Mercurial을 선호하는 사람들은 제외되지만, Mercurial의 hg-git 확장 기능을 사용하여 서버 측에서 Git인 저장소와 함께 작업함으로써 Mercurial을 계속 사용할 수 있습니다.

CPython 워크플로우가 너무 복잡하다 (CPython Workflow is too Complicated)

이전 논의에서 나온 의견 중 하나는 CPython의 다중 브랜치(multi branch) 모델이 GitHub Pull Request에는 너무 복잡하다는 것이었습니다. 이 PEP는 이 주장이 정확하지 않다고 믿습니다.

현재 특정 변경 사항은 2.7 및 3.x 버전에 대해 수동으로 패치를 생성해야 하며, 이는 이 점에서 전혀 변하지 않습니다.

누군가가 현재 안정(stable) 브랜치(현재 3.4)에 대한 수정 사항을 제출하면, GitHub Pull Request 워크플로우를 사용하여 현재 안정 브랜치를 마스터(master) 브랜치로 병합(merge)하는 Pull Request를 브라우저에서 생성할 수 있습니다 (병합 충돌이 없다고 가정). 병합 충돌이 발생하면 로컬에서 처리해야 합니다. 이는 병합이 항상 로컬에서 발생해야 하는 현재 상황에 대한 개선을 제공합니다.

마지막으로, 누군가가 현재 개발(development) 브랜치에 대한 수정 사항을 제출하면, 안정 브랜치에 포함시키려면 수동으로 적용해야 합니다. 이는 새로운 워크플로우에서도 로컬에서 발생해야 하지만, 사소한 변경 사항의 경우 GitHub 웹 에디터에서 쉽게 수행될 수 있습니다.

여러 장기 실행 브랜치를 유지 관리하는 데 관련된 복잡성을 어떤 시스템도 숨길 수 없다고 이 PEP는 생각합니다. 도구가 할 수 있는 유일한 일은 변경 사항을 가능한 한 쉽게 제출하도록 하는 것입니다.

예시: Scientific Python

Git과 GitHub로의 이전의 핵심 아이디어 중 하나는 DVCS의 특징, 저장소 호스팅, 그리고 사용되는 워크플로우가 해당 도구를 사용하는 커뮤니티의 소셜 네트워크와 규모라는 점입니다. Scientific Python 커뮤니티의 예를 통해 이를 확인할 수 있습니다. 이들은 이미 SciPy 스택의 주요 구성 요소를 Pull Request 기반 워크플로우를 사용하여 GitHub로 대부분 이전했습니다. 이 과정은 IPython부터 시작되었으며, 더 많은 프로젝트가 이전함에 따라 커뮤니티의 새로운 프로젝트에 대한 자연스러운 기본값이 되었습니다.

그들은 이 이전으로 인해 상당한 이점을 얻었다고 주장합니다. 이는 일반 기여자들이 각 프로젝트에 대한 특별하고 독자적인 워크플로우와 다른 툴체인을 배울 필요 없이 하위 커뮤니티 내의 다른 프로젝트들 사이를 쉽게 이동할 수 있게 합니다. 사람들이 다른 도구와 워크플로우를 배우는 대신 실제 기여에 제한된 시간을 사용할 수 있을 때, 그들은 한 프로젝트에 더 많이 기여할 뿐만 아니라 다른 프로젝트로 확장하여 기여한다는 것을 발견했습니다. 이러한 이전은 또한 해당 커뮤니티 구성원들이 연구 및 교육 자료를 GitHub에 게시하는 경향이 증가한 이유로도 언급됩니다.

이 예시는 매우 인기 있는 툴체인과 워크플로우로 이전하는 것의 진정한 힘을 보여줍니다. 왜냐하면 각 편차는 새롭고 일반적인 기여자들이 극복해야 할 또 다른 장애물을 도입하고, 해당 워크플로우를 배우는 데 소요되는 시간을 다른 프로젝트에서 재사용하기 어렵게 만들기 때문입니다.

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