CPython JIT, 공식화 절차 밟는다
CPython JIT 컴파일러 프로젝트의 향후 방향성에 대한 스티어링 카운슬의 공식 발표임
PEP 744의 정보 제공 역할 한계를 지적하며, 표준 트랙 PEP(Standards Track PEP) 작성을 공식 요청함
6개월 내 PEP 미수용 시 JIT 코드 제거를 명시하며, 개발 중단 및 외부 저장소 이전 요구
보안, 유지보수, 호환성 등 미해결 과제에 대한 커뮤니티 논의 및 합의 강조
JIT 컴파일러의 비공식적 지위와 PEP 절차 요구
스티어링 카운슬은 CPython의 JIT 컴파일러가 실험적 단계에 머물러 있으며, PEP 744가 정보 제공(Informational) 수준에 그쳤음을 지적함. 이에 따라 표준 트랙 PEP(Standards Track PEP)를 통해 JIT의 지원 여부, 보증 범위, 유지보수 계획 등을 공식적으로 논의하고 합의할 것을 요구함. 이는 복잡성과 영향력을 고려할 때 프로세스 준수가 필수적이라는 판단에 따른 것으로 보임.
개발 중단 및 코드 제거 가능성
향후 6개월 내에 JIT에 대한 표준 트랙 PEP가 수용되지 않을 경우, 메인 브랜치에서 JIT 코드가 제거될 수 있음을 명확히 함. 이는 JIT 프로젝트에 대한 개발 중단을 의미하며, 지속적인 개발은 CPython 저장소 외부에서 이루어져야 함을 시사함. 커뮤니티의 합의 없이는 핵심 런타임 변경이 지속될 수 없다는 강력한 메시지를 전달함.
다양한 JIT 구현 전략 지원 가능성
제안된 PEP는 특정 JIT 구현에 국한되지 않고, 다양한 JIT 구현 전략을 지원하는 인프라 구축에 초점을 맞출 것을 권고함. 이는 Numba, PyTorch 등 외부 JIT 컴파일러와의 호환성 및 다수의 실험적 접근 방식을 CPython 내에서 평가할 수 있는 유연성을 확보하기 위함으로 분석됨. 단일 전략 고수보다는 개방형 아키텍처(Open Architecture)를 지향하는 것으로 보임.
유지보수, 호환성, 성능 지표의 중요성
PEP에서 다루어야 할 핵심 사항으로 장기적인 유지보수 계획, 기존 CPython 기능 및 디버거, 프로파일러와의 호환성 보장, 그리고 명확하고 측정 가능한 성능 목표(Performance Targets) 설정이 강조됨. 특히 프리쓰레딩(Free-threading)과 같은 기존 기능과의 상호작용 및 메모리 오버헤드(Memory Overhead)에 대한 구체적인 논의가 필요함을 시사함.