JIT는 포함되었지만, 승인은 받지 못했습니다
Python의 실험적 JIT 컴파일러는 2023년 말과 2024년 초에 시작된 작업을 바탕으로 CPython 3.13에 선택적으로 활성화하는 기능으로 도입되었습니다. 코어 개발자 Brandt Bucher가 런타임 성능을 높일 목적으로 copy-and-patch JIT를 처음 병합했습니다.
그러나 JIT는 공식적이고 장기적인 승인을 받지 못했습니다. JIT는 기능의 자리와 지속적인 유지 관리 약속을 확고히 해 주었을 Standards Track PEP가 아니라, 기능을 설명하기만 하는 Informational PEP인 PEP 744에 따라 배포되었습니다. 이러한 절차상의 공백 때문에 JIT의 미래는 처음부터 불확실했습니다.
이는 버그 때문에 이루어진 번복이 아니었으며, 코드 자체는 작동했습니다. 대신 Python 프로젝트는 영구적인 약속 없이 실험적 기능을 배포하도록 허용하며, 이는 핵심 팀에 무기한 지원 부담을 자동으로 지우지 않는 혁신의 공간을 만듭니다. JIT가 제거되는 것은 기술적 결함이 아니라 이러한 공식적 합의의 부재 때문입니다.
Python Steering Council은 결국 최후통첩을 내렸습니다. Standards Track PEP를 확보하지 못하면 JIT를 제거하겠다는 것이었습니다. 이 조치는 실험적 코드를 배포하는 것과, 커뮤니티와 유지 관리자가 자원을 무기한 투입하도록 설득하는 것은 별개이며 후자가 오픈 소스 개발에서 훨씬 더 큰 과제임을 보여 주었습니다.
council이 요구한 것은 약속이 아니라 증거였습니다
JIT의 비공식적인 도입을 탐탁지 않게 여긴 Python steering council는 2026년 6월에 최후통첩을 내렸습니다. 6개월 이내에 Standards Track 제안을 제출해 통과시키지 못하면 실험적 JIT 코드를 main 브랜치에서 제거하겠다는 것이었습니다. 이는 권고가 아니라, 표준 거버넌스를 거치지 않았던 기능에 대한 엄격한 기한이었습니다.
이에 대응해 Savannah Savannah Ostrowski, Ken Jin, Brandt Bucher는 2026년 7월 “JIT Go Brrr: The Path to a Supported JIT Compiler for CPython”이라는 적절한 제목의 PEP 836을 제출했습니다. council의 10개 항목 비판은 신속하고 가차 없었습니다. council은 이 PEP가 보안에 충분한 관심을 기울이지 않았다며 “충분히 다뤄지지 않은 영역”이라고 평가했고, 성능 및 사용자 영향 전망은 “지나치게 낙관적”이라며 일축했습니다.
아마도 가장 혹독한 거부는 2028년 8월 Python 3.17 릴리스 후보 시점으로 예정된 호환성 검토 제안에 관한 것이었을 것입니다. council은 이 일정이 “너무나도 늦다”고 판단하며 즉각적이고 확고한 보장을 요구했습니다. 설득력 있는 로드맵이 없는 상황에서, 초기의 가능성에도 불구하고 JIT의 미래는 점점 더 암울해 보였습니다.
유망했던 제안에 사람이 부족했습니다
Python Steering Council의 최후통첩이 무겁게 자리하는 가운데, 유망한 제안은 자리를 잡지 못했습니다. 2026년 10월 19일, Python 3.16과 3.17의 릴리스 매니저인 Savannah Savannah Ostrowski는 JIT를 Standards Track 지위로 끌어올리려던 “JIT Go Brrr” 제안인 PEP 836을 공식적으로 철회했습니다. 철회 사유는 “현재 버전을 계속 추진할 개인적인 여력”이 크게 부족하다는 것이었습니다.
이는 JIT가 무가치하다는 선언이 아니었으며, 오히려 그 반대입니다. Savannah Ostrowski와 팀은 Python 성능을 높일 수 있는 이 기술의 잠재력을 여전히 확신했습니다. 철회는 보안 우려를 해소하고, 좁은 범위의 벤치마크에서 관찰된 기하평균 4–12%의 완만한 속도 향상보다 더 견고한 성능 향상을 입증하는 등 council의 엄격한 요구를 충족하는 데 필요한 엔지니어링 및 정치적 노력의 규모를 반영한 것이었습니다.
council의 피드백은 직설적이었습니다. 보안을 “충분히 다뤄지지 않은 영역”이라고 부르고, Python 3.17에 대해 제안된 2028년 8월 호환성 검토를 “너무나도 늦다”고 평가했습니다. 이러한 사항을 포괄적으로 해결할 전담 자원이 없었기 때문에 PEP 836은 진행될 수 없었습니다. JIT가 처음 덜 공식적으로 도입된 배경은 PEP 744 – JIT Compilation을 참조하십시오.
그 결과는 이제 거의 확실합니다. 실험적 JIT 코드는 Python 3.16 개발 주기 초반에 CPython의 main 브랜치에서 제거될 것입니다. 트리 내 JIT를 둘러싼 Python의 짧은 시도는 끝난 것으로 보이며, 코드를 배포하는 일이 가장 쉬운 부분인 경우가 많은 오픈 소스의 현실이 낳은 결과입니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
진짜 병목은 장기적인 소유권입니다
코드를 병합하는 것은 오픈 소스 개발의 끝이 아니라 시작입니다. CPython의 main 브랜치에서 JIT가 곧 제거된다는 사실은 중요한 교훈을 보여 줍니다. 소유권은 최초 커밋 이후에도 이어진다는 것입니다. 유지 관리자는 보안 검토, 호환성 위험, 메모리 비용, 장기 지원에 대한 책임을 계속 져야 하며, JIT 팀은 이 기술을 믿었음에도 그 부담을 감당할 수 없었습니다.
이 결과를 Python 성능 개선 노력의 중단으로 오해해서는 안 됩니다. JIT는 선택적으로 활성화하는 실험적 기능이었습니다. Python 3.11과 3.12의 상당한 개선을 포함해 CPython의 최근 속도 향상 대부분은 별개이며 계속 진행 중인 최적화 전략인 specializing adaptive interpreter에서 비롯되었습니다.
또한 이번 결정이 Python JIT 개발 전반의 종말을 의미하지는 않습니다. PyPy, Numba, PyTorch Inductor 같은 대안 프로젝트는 계속해서 JIT 컴파일을 활용하고 있습니다. 이러한 솔루션은 서로 다른 워크로드와 실행 환경을 대상으로 하며 CPython의 핵심 개발 트랙 밖에서 운영되고, 특정 고성능 Python 애플리케이션에서는 JIT 개념이 여전히 중요하다는 점을 보여 줍니다.
자주 묻는 질문
CPython은 왜 실험적 JIT를 제거하나요?
JIT는 승인된 Standards Track PEP가 없었고, 해결되지 않은 보안 및 호환성 우려가 있었으며, 유지 관리자들이 제안을 계속 추진하는 데 필요한 여력을 확보할 수 없었습니다.
JIT에 버그가 있어서 제거된 것인가요?
아니요. 이번 결정은 거버넌스, 장기 유지 관리, 보안 검토, 그리고 기대되는 이점이 비용을 정당화하는지 여부를 중심으로 이루어졌습니다.
PEP 744와 PEP 836의 차이는 무엇인가요?
PEP 744는 실험적 JIT를 문서화한 정보성(Informational) PEP였습니다. PEP 836은 지원되는 JIT에 대한 공식 승인을 요청했지만, 주 저자가 철회했습니다.
그렇다면 Python에는 앞으로 JIT가 생기지 않는다는 뜻인가요?
아니요. 이번 결정은 CPython의 main 브랜치에 있는 JIT에 관한 것이며, 독립 프로젝트와 향후 제안은 여전히 JIT 컴파일을 추진할 수 있습니다.