JIT 프로젝트에 관한 Steering Council의 발표

• CPython의 실험적 JIT 컴파일러는 main 브랜치에서 수년간 개발되어 최근 실제 성능 개선을 보였지만, 지원 기능으로 남기려면 공식 PEP 검토가 필요한 상태임
• PEP 744는 초기 설계와 영구 기능 전환 기준을 다뤘지만, 장기 유지보수자, 보안 검토, 디버깅 및 외부 프로세스 도구 지원, 런타임 보장, 재배포자·다운스트림 패키저 의무가 아직 합의되지 않은 상태임
• Python Steering Council은 JIT를 CPython의 지원되는 비실험 기능으로 만들기 위한 Standards Track PEP 작성을 공식 요청했고, PEP 수락 전까지 새 기능·최적화·성능 작업의 main 반영 중단을 요청함
• 새 PEP는 장기 유지보수, 기존 CPython 기능·도구와의 호환성, 측정 가능한 성공 지표와 일정, CinderX·Numba·PyTorch 같은 서드파티 JIT와의 관계, 현재 아키텍처 안정성을 다뤄야 함
• 6개월 안에 PEP가 제출·해결되지 않거나 수락되지 않으면 JIT 코드를 main 브랜치에서 제거하고 main Python 저장소 밖에서 개발을 계속해야 함

배경과 공식 요청

• CPython의 실험적 Just-In-Time 컴파일러는 지난 몇 년 동안 여러 core developer와 기여자가 main 브랜치에서 개발해 온 작업이며, 최근 성능 개선은 실제적이고 고무적인 결과임
• 이 조치는 JIT 작업이나 참여자에 대한 비판이 아니며, 프로젝트가 오래 진행되고 여러 차례 재설계를 거쳤기 때문에 CPython 프로젝트 안에서 JIT의 비공식적 지위를 다시 평가할 시점이라는 판단임
• JIT는 처음 main에 병합될 때 실험으로 들어왔고, 관련 PEP인 PEP 744는 Informational PEP임
• PEP 744는 초기 설계를 다루고 JIT가 영구 기능이 될 수 있는 기준을 개략적으로 다뤘지만, 장기 유지보수자, 보안 검토, 디버깅과 외부 프로세스 도구 지원, 런타임 보장, 재배포자와 다운스트림 패키저의 의무 같은 질문을 열어둔 상태임
• Python Steering Council은 이 정도 복잡성과 범위를 가진 변경에는 더 엄격한 절차가 필요했으며, 해당 미해결 질문들은 커뮤니티가 PEP 절차를 통해 따져보고 합의해야 할 약속이라고 판단함
• JIT를 CPython의 지원되는 비실험 기능으로 만들려면 보장, 유지보수 약속, 재배포자 영향까지 다루는 Standards Track PEP가 필요하며, 커뮤니티 논의 후 Steering Council의 공식 수락 또는 거절 절차가 필요함
• 해당 PEP가 수락될 때까지 main 브랜치에는 새 JIT 개발을 반영하지 말아야 하며, 새 기능, 최적화, 성능 작업이 중단 대상임
• 버그 수정과 보안 수정은 계속 가능하며, 중단 요청의 범위는 PEP 수락 전 추가 JIT 기능 반영으로 한정됨

PEP가 다뤄야 할 쟁점과 6개월 일정

• 경쟁 제안을 요구하려는 의도는 아니지만, 지금은 대안 제안도 논의할 좋은 시점이며, CPython main 브랜치에서 PEP 없이 실험을 진행하지 않아야 한다는 기존 관점과도 일치함
• 단일 JIT 구현 하나를 제안하기보다 여러 구현 전략을 지원할 수 있는 JIT 인프라를 설명하는 PEP가 더 적절할 수 있음
• 여러 유망한 JIT tracing 접근법이 계속 제안되고 있기 때문에, 인프라는 단일 전략에 강하게 결합되기보다 CPython 안에서 그런 접근법을 쉽게 실험하고 평가할 수 있어야 함
• PEP는 이 규모와 복잡성을 가진 하위 시스템을 장기적으로 어떻게 지속·유지할지, JIT에 직접 기여하지 않는 유지보수자와 기여자에게 어떤 영향을 줄지에 대한 명확한 계획을 세워야 함
• PEP는 기존 CPython 기능과 도구와의 호환성을 다뤄야 하며, free-threading, profiler, debugger 같은 기능과 JIT의 상호작용 및 보장을 넓고 세밀하게 다뤄야 함
• PEP는 명확하고 측정 가능한 성공 지표와 일정을 포함해야 하며, 성능 목표, 플랫폼 지원 범위, 메모리 오버헤드 같은 목표와 시점을 다뤄야 함
• PEP는 다른 JIT 컴파일러와의 관계를 다뤄야 하며, 다른 노력이 기반으로 삼을 수 있는 일반 인프라를 제공하는 설계인지, CinderX, Numba, PyTorch 등 서드파티 JIT와 호환 또는 비호환을 예상하는지 밝혀야 함
• PEP는 현재 JIT 아키텍처가 안정적이라고 보는지, 아니면 더 변경될 가능성이 큰지 다뤄야 함
• 이 목록은 완전한 목록이 아니며, 커뮤니티 논의가 진행되면서 추가 쟁점이 더해질 수 있음
• PEP 제출과 해결에는 6개월의 기간이 설정되며, 이 기간 안에 해당 PEP가 수락되지 않으면 JIT 코드는 main 브랜치에서 제거되고 main Python 저장소 밖에서 개발을 계속해야 함
• 이 요구는 프로젝트 종료가 아니라 CPython 런타임에 대한 큰 변경에 필요한 명확성과 커뮤니티의 명시적 약속을 부여하기 위한 절차임