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

[GN⁺]

Lobste.rs 의견들

• 아주 험악해 보이진 않지만 약간 어색하긴 함. JIT가 아직 실험적 기능이라면 병합이 계속되는 것 자체는 문제 없어 보임
  Shannon 같은 사람들이 “PEP를 가져오겠지만 어색한 충돌은 피하게 해달라”고 말한다면, 더 진행하지 못하게 강한 잠금을 걸지 않아도 될 만큼 신뢰할 수 있다고 느낌. 이 공개 발표가 비공개 대화 뒤에 나온 것일 수도 있지만, 불필요한 상처 없이 잘 진행됐으면 함

• 서로 다른 JIT 구현을 허용하는 인터페이스 제안은 고성능 JIT에 무엇이 필요한지 크게 오해한 것처럼 보임. JIT 작업자들에게 여러 문제가 있었겠지만, 큰 문제 중 하나는 핵심 런타임 자료구조를 크게 바꾸지 못했거나 바꾸려 하지 않았던 점으로 보임
  물론 Python은 사실상 구현 전체를 API처럼 노출해버린 문제도 있음. 그래도 누군가 나쁜 짓을 하면 타입을 다시 작성하게 만들 수는 있지만, 그러려면 성능을 정말 중요하게 여기는 커뮤니티가 필요함. Python은 역사적으로 성능이 필요한 라이브러리는 Python으로 쓰지 않는 방식으로 버텨왔고, 그게 우선순위에 영향을 줬음. 예전에 언어 성능 비교에서 기본 알고리즘 구현과, 실제로는 C 라이브러리의 잘 다듬어진 고성능 구현을 감싼 Python 구현을 비교하던 기억이 남

  • JIT 인터페이스 제안은 Ruby에서 영감을 받은 것 같고, Ruby에서는 꽤 잘 작동한 인상임. 그래서 Ruby에 초고성능 JIT가 없을 수도 있지만, 그 정도면 괜찮을 수도 있음. Python JIT가 Ruby JIT만큼만 동작해도 많은 사람이 만족할 것 같음

  • “서로 다른 JIT 구현을 허용하는 인터페이스 제안은 고성능 JIT에 필요한 것을 크게 오해한 것”이라는 말이 왜 그런지 잘 모르겠음
    말한 대로 Python이 구현을 API처럼 노출한 상황은 있지만, 같은 이유로 JIT도 그 API들을 호출하고 있음. 실제로 일부 함수는 JIT가 필요로 해서 링커에 공개 심벌로 노출되기도 했음. 개인적으로는 추적 JIT가 아니라 메서드 JIT를 작업하고 있고, 플러그형 JIT 아이디어를 공개적으로 지지해 왔음

• 왜 이걸 핵심 JIT 개발자들에게 비공개 요청으로 보내지 않고 공개 발표로 올렸는지 궁금함

  • Python은 커뮤니티 주도 오픈소스 프로젝트이기 때문임. 독점 프로젝트에서도 비슷한 발표가 유출된 적이 있음

• 어딘가의 인류학자가 오픈소스 소프트웨어 프로젝트의 관료제에 관한 책을 써야 할 것 같고, Python과 Debian은 핵심 연구 대상이 되어야 함
  비난은 아님. 이런 관료제는 결국 분산된 의사결정과 합의 형성 과정이고, 이 정도 규모에서 잘 작동하게 만드는 건 어렵다

  • Gabriella Coleman은 Debian을 현지조사한 인류학자임. 그 결과로 나온 책이 “Coding Freedom”이고 강력 추천함

• 솔직히 Python 3로 이어졌던 증후군과 같지만 반대 효과가 난 것처럼 보임. CPython은 주로 구현자들의 즐거움을 위해 존재하고, 이 변화는 지금 방식으로 해킹하는 데 익숙한 사람들에게 꽤 큰 불편을 줄 것 같음
  아마 올바른 방향은 JIT 버전을 별도 구현으로 후원하고, 변경을 허용하면서 원래 CPython과의 호환성은 최선 노력으로 추구하게 하는 것일 듯함

  • “Python 3로 이어졌던 증후군과 같지만 반대 효과”라는 말이 정확히 무슨 뜻인지 잘 모르겠음
    “CPython은 주로 구현자들의 즐거움을 위해 존재한다”는 부분도, SC와 핵심 개발자들과의 제한적인 상호작용에서 받은 인상은 오히려 반대였음. 대체로 기존 커뮤니티를 계속 지원하면서도 앞으로 나아가는 균형을 합리적으로 잡는 데 꽤 깊이 헌신하는 것처럼 보였음