Python Steering Council의 JIT 프로젝트 발표 — CPython의 다음 6개월을 어떻게 바꿀까

Python Steering Council의 JIT 프로젝트 발표 — CPython의 다음 6개월을 어떻게 바꿀까

2026년 6월, Python Steering Council이 CPython의 실험적 JIT 컴파일러에 관한 공식 발표를 공개했습니다. 수년간 main 브랜치에서 개발되어 온 JIT는 최근 실제 성능 개선을 보여주고 있지만, 영구 기능으로 정식 채택되기 전까지는 새 기능·최적화·성능 작업의 main 반영이 중단됩니다. 이번 발표는 JIT 작업 자체에 대한 비판이 아니라, 이 정도 규모와 복잡성을 가진 변경에는 더 엄격한 절차가 필요하다는 판단에서 출발합니다.

이 글에서는 발표의 핵심 내용과 개발자·사용자가 알아야 할 포인트를 정리합니다.

왜 지금 발표가 나왔나

CPython의 실험적 Just-In-Time 컴파일러는 여러 core developer와 기여자가 main 브랜치에서 수년간 함께 만들어 온 결과물입니다. 최근 들어 의미 있는 성능 개선이 측정되면서 "이제 슬슬 정식 기능으로 격상해야 하지 않나"는 목소리가 커져 왔습니다.

하지만 기존 관련 PEP인 PEP 744는 Informational PEP 수준에 머물러 있었습니다. 초기 설계와 영구 기능 전환 기준을 개략적으로 다루기는 했지만, 다음과 같은 미해결 질문들이 그대로 남아 있었습니다.

• 장기 유지보수자시수가 되는가

• 보안 검토는 어떻게 진행되는가

• 디버거·프로파일러 같은 외부 프로세스 도구는 어떻게 호환되는가

• 런타임 보장은 어디까지인가

• 재배포자·다운스트림 패키저의 의무는 무엇인가

Steering Council은 이런 질문들은 커뮤니티가 PEP 절차를 통해 따져보고 합의해야 할 사항이라고 판단했습니다.

발표의 핵심 요구사항

Steering Council은 JIT를 CPython의 지원되는 비실험 기능으로 만들기 위해 다음을 공식 요청했습니다.

1. Standards Track PEP 작성 요청 — 보장, 유지보수 약속, 재배포자 영향까지 다루는 정식 PEP 필요

2. main 브랜치 반영 중단 — PEP 수락 전까지 새 기능·최적화·성능 작업의 main 반영 중단

3. 버그 수정·보안 수정은 계속 허용 — 중단 범위는 "추가 JIT 기능 반영"으로 한정

여기서 중요한 점은 버그 수정은 계속 가능하다는 것입니다. 즉 JIT 자체가 제거되는 것이 아니라, 새 기능 추가만 멈추는 것입니다.

새 PEP가 다뤄야 할 쟁점

Steering Council이 새 PEP에 반드시 포함되어야 한다고 명시한 항목은 다음과 같습니다.

1. 단일 구현이 아닌 JIT 인프라

단일 JIT 구현 하나를 제안하기보다, 여러 구현 전략을 지원할 수 있는 JIT 인프라를 설명하는 PEP가 더 적절할 수 있습니다. 여러 tracing JIT 접근법이 계속 제안되고 있기 때문에, 인프라는 단일 전략에 강하게 결합되기보다 CPython 안에서 다양한 접근법을 쉽게 실험하고 평가할 수 있어야 합니다.

2. 장기 유지보수 계획

이 규모와 복잡성을 가진 하위 시스템을 장기적으로 어떻게 지속·유지할지, JIT에 직접 기여하지 않는 유지보수자와 기여자에게는 어떤 영향을 줄지에 대한 명확한 계획이 필요합니다.

3. 기존 기능과의 호환성

free-threading, profiler, debugger 같은 기존 CPython 기능과 JIT의 상호작용 및 보장을 넓고 세밀하게 다뤄야 합니다. Python은 사실상 구현 전체를 API처럼 노출해 버린 특성이 있어, JIT가 어떤 심벌을 노출하고 어떤 호출 규약을 따르는지가 매우 중요합니다.

4. 측정 가능한 성공 지표와 일정

성능 목표, 플랫폼 지원 범위, 메모리 오버헤드 같은 목표와 시점을 명확하고 측정 가능한 형태로 제시해야 합니다. "빨라진다" 같은 모호한 표현이 아니라, 구체적인 수치와 일정이 필요하다는 뜻입니다.

5. 다른 JIT와의 관계

CinderX, Numba, PyTorch 같은 서드파티 JIT와 호환 또는 비호환을 예상하는지, 다른 노력이 기반으로 삼을 수 있는 일반 인프라를 제공하는 설계인지 밝혀야 합니다.

6. 현재 아키텍처 안정성 평가

현재 JIT 아키텍처가 안정적이라고 보는지, 아니면 앞으로 더 큰 변경이 예상되는지 다뤄야 합니다. 이 부분이 합의되지 않으면 PEP 자체가 의미 없어질 수 있습니다.

6개월 시한의 의미

PEP 제출과 해결에는 6개월의 기간이 설정되어 있습니다. 이 기간 안에 PEP가 제출·해결되지 않거나 수락되지 않으면, JIT 코드는 main 브랜치에서 제거되고 main Python 저장소 밖에서 개발을 계속해야 합니다.

이것은 프로젝트 종료가 아닙니다. CPython 런타임에 대한 큰 변경에 필요한 명확성과 커뮤니티의 명시적 약속을 부여하기 위한 절차입니다. 커뮤니티가 합의하지 못한 채로 main에 머무르는 것보다, 합의된 형태로 들어오거나 main 밖에서 개발을 이어가는 것이 더 건강하다는 판단입니다.

개발자·사용자가 알아야 할 점

일반 Python 사용자에게

• Python 3.15의 JIT는 여전히 실험적이며, 일반 사용자가 활성화해서 쓰는 것은 권장되지 않습니다.

• PEP가 수락되거나 거부되는 시점에 따라 향후 CPython 릴리스의 성능 특성이 크게 달라질 수 있습니다.

• 6개월 시한 안에 합의를 보지 못하면 JIT는 별도 구현체로 남게 되고, 메인 CPython과의 통합은 최선 노력으로 추구됩니다.

라이브러리·프레임워크 개발자에게

• JIT 활성화 환경에서의 디버깅·프로파일링 호환성 보장은 아직 확정되지 않았습니다.

• Numba, PyTorch 등 이미 JIT 기반 라이브러리를 사용하는 경우, CPython JIT와 어떤 관계가 될지관주가 필요합니다.

CPython 기여자에게

• 새 JIT 기능·최적화·성능 작업의 main 반영은 6개월 동안 중단됩니다.

• 버그 수정·보안 패치는 계속 가능합니다.

• PEP 작성에 직접 참여하거나 discuss.python.org에서 의견을 낼 수 있습니다.

커뮤니티 반응

Hacker News와 Lobsters에서는 발표 자체의 톤에 대해 대체로 긍정적인 반응이 많았습니다. "험악해 보이진 않지만 약간 어색하긴 하다"는 의견이 많았고, 핵심 JIT 개발자들이 이 발표를 잘 받아들여 PEP 작업을 시작할 것으로 기대하는 분위기입니다.

특히 "JIT 인터페이스 제안은 Ruby에서 영감을 받은 것 같고, Ruby에서는 꽤 잘 작동한 인상"이라는 반응이 인상적입니다. Python JIT가 Ruby JIT만큼만 동작해도 많은 사용자가 만족할 것이라는 현실적인 기대도 함께 등장했습니다.

전망과 요약

이번 발표는 CPython의 성능 향상을 향한 움직임이 한 단계 격상된 시점입니다. 단순히 코드를 더 빠르게 만드는 것을 넘어, "어떤 보장과 약속을 가지고 main에 머무를 것인가"라는 절차적 합의에 집중하고 있습니다.

핵심 포인트를 정리하면 다음과 같습니다.

• JIT 기능의 main 반영은 6개월간 중단되며, 버그·보안 수정은 계속 가능합니다

• 6개월 안에 Standards Track PEP가 제출·수락되지 않으면 JIT는 main에서 제거됩니다

• 새 PEP는 유지보수, 호환성, 성공 지표, 다른 JIT와의 관계를 모두 다뤄야 합니다

• 단일 구현이 아닌 JIT 인프라 설계가 권장됩니다

Python의 성능이 정말로 C 수준에 근접할 날이 올지는 이 6개월 동안의 PEP 작업과 커뮤니티 합의에 달려 있습니다. 개발자라면 discuss.python.org의 후속 PEP 토론을관주하고, 자신의 워크로드에 미칠 영향을 미리 가늠해 두는 것이 좋겠습니다.

---

📚 출처

• https://news.hada.io/topic?id=30238