• 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 런타임에 대한 큰 변경에 필요한 명확성과 커뮤니티의 명시적 약속을 부여하기 위한 절차임