파이썬 실험적 JIT, CPython에서 제거될 전망

AI 요약

CPython 3.13에 포함된 실험적 JIT(Just-in-Time) 컴파일러가 주 저장소에서 빠질 전망입니다. Python 운영위원회(Steering Council)는 JIT를 실험 기능으로 계속 유지할지 판단하려고 표준 트랙 PEP를 요청했지만, 이를 작성한 개발자들은 제안서를 철회했습니다. 기능의 개발이 다른 곳에서 이어질지는 아직 정해지지 않았습니다.

PEP 836을 요구한 배경

JIT는 Brandt Bucher가 주도해 CPython 3.13에 추가했습니다. 큰 기능은 일반적으로 운영위원회가 승인한 표준 트랙 PEP를 거치지만, JIT 개발은 정보 제공 목적의 PEP 744를 바탕으로 진행됐습니다. 운영위원회는 2026년 6월 유지보수와 호환성, 성공 기준, 완료 일정을 다루는 새 PEP를 요구했습니다. 여섯 달 안에 제안서를 제출하고 승인받지 못하면 CPython 주 저장소에서 JIT 코드를 제거하겠다고 했습니다.

Bucher와 Savannah Ostrowski, Ken Jin은 7월 3일 PEP 836을 공개했습니다. 제안서에는 지원 목표뿐 아니라 구현 계획도 담겼습니다. 일부 개발자는 목표와 구현 세부 사항을 별도 PEP로 나누자고 했고, Ostrowski는 계획 없이 목표만 제시하면 충분하지 않다고 답했습니다.

운영위원회가 요청한 보완 사항

9월 운영위원회는 PEP가 요청한 질문에 답했지만 일부 답변은 설득력이 부족하다고 밝혔습니다. 운영위가 판단하려는 것은 JIT가 정식 지원 기능이 될 자격이 있는지가 아니라, CPython 주 저장소에서 실험을 계속해야 하는지였습니다. 통일된 설계가 없는 상태로 실험이 이어지면 핵심 개발자와 패키지 유지관리자, 사용자가 변경되는 동작과 API를 예측하기 어렵다는 우려를 제시했습니다.

운영위는 지원 계획과 성능 기준을 구체화하고, 메모리 사용량과 보안 등 열 가지 항목을 더 논의하거나 제안서에서 제외할 이유를 설명해 달라고 했습니다. 플랫폼별 지식에 크게 기대지 않고 새 플랫폼에 적용할 수 있는 설계인지도 질문했습니다. JIT가 켜졌을 때 나타날 사용자 차이를 지나치게 낙관적으로 다뤘다고 지적하면서, 인터프리터의 동작 차이를 버그로 볼지, 불가피한 차이는 어떻게 처리할지 설명을 요구했습니다. 보안 대응팀과 논의하고 보안 검토를 정식 지원 조건에 넣는 방안도 제안했습니다.

PEP 836은 Python 3.17 첫 릴리스 후보가 나올 무렵인 2028년 8월쯤 주요 PyPI 패키지의 테스트를 돌려 호환성을 검토하겠다고 했습니다. 운영위는 이 시점이 너무 늦다며 가능한 한 빨리 지속적으로 검토해야 한다고 했습니다. 또한 CPython을 책임지는 더 넓은 개발자 집단의 검토 없이 설계 결정이 내려지는 점도 우려했습니다.

제안 철회와 이후

10월 19일 Ostrowski는 제안서 철회를 알렸습니다. 운영위원회가 이 정도 규모의 제안에 높은 기준을 두는 것은 타당하지만, 현재 제안서를 계속 추진할 개인적 여력이 부족하다고 설명했습니다. 작성자들은 자유 스레드 실행 지원과 메서드 기반 프런트엔드를 포함한 기술 방향에 대한 지지는 유지하며, 참조 구현을 공개해 다른 개발자가 이어서 실험할 수 있도록 하겠다고 했습니다.

Brett Cannon은 JIT 작업이 주 저장소에서는 중단되겠지만, 다른 곳에서 이어갈지는 커뮤니티에 달렸다고 설명했습니다. 기존 작업을 이끌던 사람들이 대부분 PEP 작성자이거나 기여자였기 때문에 운영위원회 마감 전 대체 PEP를 내기는 어려울 것이라고도 했습니다. 따라서 코드 제거는 Python 3.16 개발 초기에 제거 과정의 문제를 고칠 시간을 확보하도록 가까운 시일 안에 진행될 가능성이 있습니다. 기존 주도자들이 다른 저장소에서 개발을 이어갈지는 분명하지 않습니다.

원문: LWN.net / 번역·요약: Trawling