요약
Python의 실험적 JIT 컴파일러가 정식 기능 승인을 받지 못해 메인 브랜치에서 빠집니다.
LWN의 조 브록마이어가 정리한 소식입니다. 2024년 CPython 3.13에 들어간 JIT(실행 중에 코드를 기계어로 바꿔 빠르게 돌리는 컴파일러)를 정식 기능으로 만들자는 PEP 836(Python 개선 제안서)이 운영위원회 검토 끝에 철회됐습니다.
왜 중요한가
- CPython에 내장될 것으로 기대되던 JIT가 사라지고, 작업을 이어 갈지는 커뮤니티의 몫으로 남았습니다.
- 제안서 없이 먼저 들어간 큰 기능도 유지 계획과 성공 기준을 증명하지 못하면 빠진다는 선례가 됐습니다.
핵심 내용
- 운영위원회는 2026년 6월 메인 브랜치의 JIT 작업을 멈추게 했습니다.
- 6개월 안에 정식 제안서가 승인되지 않으면 JIT 코드를 제거하는 것이 기본 결론이었습니다.
- 위원회는 9월 플랫폼 간 차이, 메모리 사용량, 보안 등 열 가지 우려를 내놓았습니다.
- 3.17 출시 후보 무렵(2028년 8월)으로 잡은 호환성 검토 일정은 너무 늦다는 평가를 받았습니다.
- 공동 저자 서배너 오스트로스키는 10월 19일 개인 여력이 없다며 제안서를 철회했고, JIT는 3.16 개발 초반에 제거될 전망입니다.
HN 반응
- 성능 최적화에까지 제안서를 요구하면 실험이 불가능하다는 의견과, 위원회는 범위·성공 기준·지원 계획만 요구했을 뿐이라는 반론이 맞섰습니다.
- 정교한 최적화를 여럿 넣었는데도 실제 프로그램 기준의 속도 향상은 JIT치고 크지 않았다는 평가도 나왔습니다.
안타깝습니다. 이 작업을 가끔씩 지켜보고 있었습니다.
한편으로는 운영위원회(SC)가 새 PEP를 요구하기 전까지 JIT 작업이 한창 속도를 내고 있었다는 점이 아쉽습니다. JIT에는 프리스레딩(free threading)으로 인한 성능 저하를 상쇄해 주리라는 기대도 일부 걸려 있었던 것 같거든요.
다른 한편으로는, (제가 보기에) 화려하고 분명 멋진 최적화를 많이 얻었는데도(참조 횟수 연산 자동 제거, 새로운 타입 기반 특수화, 제자리 수학 연산) 매크로 벤치마크에서 나온 이득은 JIT치고 그렇게 인상적이지는 않았습니다. 정수 언박싱 같은 더 화려한 최적화를 넣으면 더 나아질 가능성은 분명 있지만, 복잡도가 계속 올라가기만 합니다.
기술적으로 JIT는 인터프리터 루프와 같은 소스에서 생성되므로 처음에는 차이가 생길 가능성이 극히 낮았습니다. 하지만 JIT 전용 경로와 최적화가 새로 들어오면서 그 위험이 계속 커졌으리라 짐작합니다.
그리고 정치적으로 보면, SC의 논리는 "이 사이드 프로젝트가 거의 우연히 main 브랜치에 들어온 뒤 감독도 없이 계속 뭉근히 끓고 있고, 안정화될 기미도 안 보인다"였던 것 같습니다. 게다가 최신 PEP도 "이 솥에 넣을 재료를 더 추가하겠다"는 식의 모호한 내용이 많았을 테니, SC가 만족하지 못했다는 점은 이해할 수 있습니다.
성능 최적화에 PEP를 요구하는 것이 큰 문제라고 생각합니다.
JIT는 본질적으로 많은 일을 해야 하는 크고 지저분한 물건입니다. 결국 "새 파이썬 인터프리터와 컴파일러에 대한 PEP를 내놓으라"고 말하는 셈입니다.
JIT가 하는 일은 본질적으로 흐릿합니다. 최적화가 모든 상황에서 이로운 경우는 아주 드물기 때문입니다. 측정하고, 퇴행(regression)을 찾고, 가진 샘플 애플리케이션 기준으로 가장 큰 문제를 다음에 해결하는 게임입니다. 게다가 과적합 위험도 늘 따라붙습니다(django는 빨라졌는데 flask는 느려졌을 수도 있죠).
제 생각에 이런 일은 PEP 절차를 거칠 사안이 아닙니다. 런타임의 구현 세부 사항이니까요.
예를 들어 JVM이 JIT를 개선할 때마다 JEP가 줄줄이 필요하다고 상상해 보세요. 아무것도 끝나지 않을 겁니다. 자바스크립트 엔진이 새 JIT 최적화를 넣으려면 ECMA의 승인이 필요하다는 경우도 마찬가지고요.
실제로 필요합니다.
https://openjdk.org/jeps/197
https://openjdk.org/jeps/515
모든 최적화에 JEP가 필요한 건 아니지만, "JIT를 추가하거나 제거한다" 정도로 큰 일이라면 100% JEP가 필요할 겁니다.
참고로, 내부 최적화를 다룬 PEP와 JEP는 둘 다 얼마든지 찾을 수 있습니다. 무작위로 고른 예시입니다.
https://peps.python.org/pep-0509/
https://openjdk.org/jeps/147
그런 JEP를 찾을 수는 있겠지만, 솔직히 말해 둘 중 한 가지 이유로 존재하는 것입니다.
OpenJDK 정규 개발팀 바깥의 사람이 최적화를 제안하는 경우.
영향이 클 수 있는 멋진 새 성능 개선을 홍보하는 경우.
JEP 설명이 PEP 설명과 매우 다르다는 점도 눈에 띌 겁니다.
아마 JVM에서 가장 큰 JEP일 Valhalla를 보세요.
https://openjdk.org/jeps/401
파이썬 JIT에 요구되는 것과 같은 수준의 요건을 요구하지 않습니다. 게다가 이 JEP는 승인되어 병합되기 전까지 꽤 오랫동안 프리뷰 상태로 "main에 올라가 있을" 것이라는 점도 널리 알려져 있습니다.
JEP가 대신 하는 일은 기능과 잠재적 위험을 설명하는 것뿐입니다.
JVM 최적화의 압도적 다수에는 JEP가 붙지 않습니다.
맞는 말씀입니다. 자바의 절차에 대해서는 잘 몰라서 반박하지는 않겠습니다. 다만 한 가지만 짚겠습니다.
파이썬도 마찬가지입니다. 그래도 JIT는 정말 덩치가 큰 일입니다. 더 나은 방법이 있을지 모르겠습니다. 1. 브랜치 밖에서 개발하다가 다 끝나면 거대한 PR을 올리는 방식은 그래도 거절당할 위험이 있고, 2. Rust처럼 main에서 더 많은 실험을 허용하면 반쯤 방치된 nightly 전용 기능이 수백 개 쌓여서 서로 충돌할 수도 있고, 결국엔 그걸 걷어내려고 관료적인 절차를 거치게 됩니다.
자바의 경우라면(최초의 JIT) 아마 JEP가 있었을 거라는 점은 인정합니다. 다만 JIT를 바꿀 때마다 새 JEP가 나오는 건 아닙니다. 자바의 JIT인 핫스팟은 JEP 절차가 시작되기 직전에 통합됐습니다. JIT에 대한 JEP는 아마 "이건 JIT이고, 이런 일을 하며, 일부 애플리케이션에서 이 정도 속도 향상을 확인했다" 정도로 꽤 밋밋했을 겁니다. AOT JEP(https://openjdk.org/jeps/514)처럼요.
자바의 거버넌스는 후속 작업이 이어지는 훨씬 개방적인 프로젝트를 허용합니다. 무모하다는 뜻이 아닙니다. Valhalla가 그 증거죠. 어느 정도 쓸 만해지면 프리뷰 기능으로 일단 내놓고, 안정 기능이 될 자격을 갖출 때까지 다듬는 데 꽤 열려 있다는 뜻입니다.
그래서 예를 들어 ZGC가 병합된 뒤에도 JDK 버전이 올라갈 때마다 ZGC가 계속 개발되고 개선되는 모습을 볼 수 있었던 겁니다(G1도 마찬가지고요). 이 GC들은 처음 나왔을 때는 꽤 거칠었지만 지금은 거의 업계 최고 수준입니다.
저는 파이썬 JIT도 같은 방식이라고 봅니다. JIT의 기반 구조를 들여오는 데는 PIP가 필요하겠지만, "기존 코드를 깨뜨리지 않는다"를 넘어서는 "수용 기준" 같은 건 넣지 않겠습니다. 그런 프로젝트는 PEP 없이 계속 업데이트되리라 기대합니다.
보충하자면, 최초의 JIT PR은 꽤 열렬한 호응 속에 병합됐고, PEP 절차를 거쳤어야 했다는 지적은 병합된 뒤에야 나왔습니다 [1]. 뒤이어 나온 PEP 744는 "정보 제공(informational)" 유형이었고, 방금 철회된 PEP 836이 첫 "표준 트랙(standards track)" PEP였습니다. 제가 이해하기로는 이게 SC가 공식적으로 의견을 낼 수 있는 사실상 첫 번째 PEP라는 뜻입니다. 그러니 이번 건은 "JIT를 업데이트해도 되나"를 묻는 PEP가 아니라, "SC가 제안된 형태의 이 JIT를 원하는가"를 처음으로 제대로 묻는 PEP였던 셈입니다.
그렇긴 해도 특히 수용 기준에 관한 부분을 포함해 말씀하신 내용의 대부분에는 동의합니다.
제가 겪고 있고 풀기도 어려운 문제는, 코드가 이미 main에 들어와 있었기 때문에 이 기능이 이미 "매몰 비용" 모드에 들어갔다는 점입니다. 코드가 이미 main에 있고 최적화 PR이 3개씩 늘 코앞에서 대기하고 있으면 곤란합니다. 그래도 SC가 "<몇>% 정도의 속도 향상에 비해 이 복잡도는 가치가 없다고 판단했다"라고 말할 수 있어야 합니다(이번 사례에서 그 판단이 옳았다는 말은 아닙니다). 철회되지 않았다면 PEP가 바로 그런 통제권을 행사하는 수단이었습니다.
[1] https://github.com/python/cpython/pull/113465#issuecomment-1919888849
최초의 JIT는 당연히 JEP를 거치지 않았습니다. JEP는 그 이전의 JSR 절차를 대체한 것이기 때문입니다.
그리고 핫스팟조차 JSR을 거치지 않았습니다. 그 작업은 전부 Sun이 자바 발전을 위해 업계 파트너들과 협력하기 시작하기 전에 끝났으니까요.
그들은 "그냥" Strongtalk 인수로 얻은 JIT 컴파일러를 자바로 이식했습니다.
아, 이건 단순한 성능 최적화가 아닙니다. 본인이 직접 "새 파이썬 인터프리터와 컴파일러"라고 하셨잖아요. 세상에 나와 있는 파이썬 코드 상당수는 CPython 인터프리터의 가정에 기대어 살고 있습니다. 예컨대 JIT가 기존 인터프리터를 대체한다면 pytest도 영향을 받았을 게 거의 확실합니다.
어쨌든 저는 파이썬에 JIT 컴파일러가 필요하다고 보지 않습니다. 그리고 CPython이 커뮤니티 패키지에 큰 문제를 일으키지 않고 인터프리터를 JIT 컴파일러로 현실적으로 대체할 수 있다고도 보지 않습니다.
제가 보는 구도는 이렇습니다. 오늘날 파이썬 사용자는 간절히 자바를 원합니다. 파이썬은 멋지고 자바는 멋지지 않다는 막연한 기억이 아직 남아 있으니 그 이름을 파이썬이라고 부르고 싶어 하는 겁니다.
러시아에는 전쟁에서 돌아온 굶주린 병사와 욕심 많은 노파에 관한 동화가 있습니다. 노파가 병사에게 하룻밤 잘 자리를 내줍니다. 그러고는 저녁으로 줄 음식이 없는 척하자, 병사는 도끼로 죽을 끓이는 마술을 보여 주겠다고 약속합니다. 그래서 노파에게 도끼를 넣은 냄비를 불에 올리라고 하고, 죽을 만드는 데 필요한 재료를 한 단계씩 노파가 직접 냄비에 넣게 만듭니다. 이 이야기에서 "도끼 죽"이라는 관용구가 생겼는데, 다른 목표를 추구하는 척하며 속임수로 만들어 낸 무언가를 가리킬 때 씁니다.
그래서 제가 보기에 파이썬의 현재 상태가 이 "도끼 죽"입니다. 사용자 중 누구도 진짜 파이썬(냄비 밖으로 아직 삐져나와 있는 도끼)을 원하지 않고, 자바를 끓여 내려고 냄비에 자바 재료를 계속 넣고 있습니다. JIT도 그랬고요. 다만 도끼를 버리기는 너무 어려웠습니다. 그래서 죽에는 나무 부스러기도 남아 있고 쇠 맛도 납니다.
참고로 유럽 민담에도 거의 같은 이야기가 흔하고, 영어에는 관용적으로 쓰이는 "돌 수프(stone soup)"라는 개념도 있습니다.
https://en.wikipedia.org/wiki/Stone_Soup
이해가 안 가네요. 몇 년 동안 선택적으로 켤 수 있는 실험 기능으로 두면서 문제를 하나씩 해결하면 안 되나요? 뭐가 문제죠? JDK는 계속 그렇게 해 왔잖아요. 프리뷰 사이에 변경이 있으면 새 JEP를 쓰고요.
저도 이해가 안 가요.
표준을 준수하는 파이썬 런타임에 그걸 억지로 끼워 넣을 가능성은 제로입니다. JIT, 지연 임포트, 스레딩, 복사 GC, 참조 카운팅 같은 일부는 너무 근본적이라 사용자에게 보이는 언어 자체를 건드리지 않고는 바꿀 수 없습니다.
대신 이런 건 어떨까요(이미 있을 수도 있지만요). 인라인 Cython을 쓸 수 있게 해 주는 데코레이터를 두는 겁니다. 이러면 문제의 90%는 해결된다고 봅니다. 처음 실행할 때나 미리 데코레이트한 함수를 컴파일합니다. 말하자면 Cython이 JIT이고, 사용자가 명시적으로 켜는 방식입니다.
이러면 파이썬 비슷한 언어로 진짜 C 속도가 나는 인라인 함수를 쉽게 쓸 수 있습니다.
제가 이런 기능 없이 Cython을 거의 안 쓰는 이유는 다음과 같습니다.
수정하지 않은 파이썬 코드를 Cython으로 돌리면 대체로 더 빠르긴 하지만 그리 많이 빨라지지는 않습니다. 제 경험칙으로는 50% 정도입니다.
그런데 Cython과 파이썬은 개발 방식이 매우 달라서 마찰이 많이 생깁니다. 예컨대 리로딩이 제대로 되지 않고, 프로파일링이 다르고, 배포할 때 빌드 디렉터리와 빌드 단계가 필요합니다.
Cython 자체도 충분히 달라서 직관적이지 않다고 생각하는데, 이런 걸 전부 갖춰야 한다면 차라리 함수를 Rust로 감싸는 편이 낫습니다.
이런 데코레이터가 있으면 필요할 때 마찰 없이 속도를 높일 수 있고, 온갖 Cython 기능으로 훨씬 더 빠르게 만들 여지도 있으면서, 파이썬 같은 의미 체계(특히 "개발 시의 의미 체계")를 유지할 수 있습니다.
다만 Cython은 분명 파이썬의 상위 집합(superset)이었으니 언어를 일부 수정해야 할 것 같습니다. 그 문법 일부는 정리된 걸로 알지만, 지금도 엄밀한 상위 집합일 수 있습니다.
저는 Julia 방식이 좋습니다. 처음 실행할 때 전부 컴파일하고, 이후에는 속도 저하 없이 재사용하며, 함수를 바꾸면 그 함수만 다시 컴파일하는 방식이요.
그건 그렇고, 저는 파이썬용 (큰) PEP를 준비 중인데 메인테이너와 스폰서(파이썬 규칙상 필요합니다)를 찾고 있습니다. 이런 훌륭한 분들을 어디서 찾을 수 있는지 아시는 분 계신가요? (코드는 이미 있고 cython, graalVM, pypy에서 동작하는데, 꽤 큰 변경이지만 언어에 큰 도움이 되리라 믿습니다.)
파이썬은 이미 바이트코드로 컴파일합니다(.pyc 파일이 그 캐시입니다). 문제는 단순한 바이트코드 명령 하나를 해석하는 데도 각각 수십 클럭 사이클이 들 수 있다는 점입니다. 제 생각에 그 상당 부분은 인터프리터 루프(꽤 많이 최적화된 걸로 압니다. 기억하기로는 루프 안의 거대한 switch 문 속에서 "예측형" goto를 쓰는 수준까지 갔습니다)가 아니라, 객체를 풀어내고 값을 레지스터로 옮겨 오가는 작업과 사실상 어떤 것에도 캐시 일관성이 없다는 현실에 대처하는 비용 같은 데서 나옵니다.
결국 바이트코드를 해석하는 데 필요한 기계어 명령 집합을 그대로 풀어 쓴다고 큰 이득이 되리라고는 확신하지 못하겠습니다. 단순한 작업에도 명령 수가 너무 많이 들거든요.
참고로 Julia 방식은 BASIC(원래 설계대로의), Lisp, Prolog와 같은 방식입니다.
BASIC에서는 Julia에서처럼 컴파일된 기계어를 들여다본 기억이 없는데요.
[수정: Dartmouth BASIC을 말씀하시는 거라고 가정합니다.]
그래서요? 실행 전에 기계어로 컴파일됐다는 사실이 바뀌지는 않습니다. 8비트 홈 컴퓨터를 제외하면 메인프레임과 이후의 16비트 홈 컴퓨터에는 컴파일형 BASIC이 얼마든지 있었고요.
인터넷 포럼에서는 뭐든 증명해야 하니까요.
https://archive.org/details/bitsavers_dartmouthB_3679804/mode/1up
=> 컴파일된 프로그램의 저장(Saving of Compiled Programs)
시작은 언어 포럼에서 하시면 됩니다. PEP를 쓰기 전에 거기서 피드백을 모으는 스레드를 이미 열어 두셨어야 하지 않나요?
감사합니다. 오래전부터 품어 온 아이디어인데 마침내 구현까지 해냈고, 지금은 절차를 배우는 중입니다.
본인 애플리케이션 코드라면 괜찮지만, 프로젝트에 끌어다 쓰는 라이브러리에는 아무 도움이 안 됩니다. 라이브러리 코드마다 Cython 코드를 뿌려 놓는 방식이 인기를 끌 것 같지는 않아요. 특히 성능에 중점을 두지 않는 라이브러리라면 더욱이요. JIT의 발상은 기존 코드를 바꾸지 않고도 쓸 수 있는 범용 성능 해법이 되자는 것입니다.
좋은 지적입니다.
그렇다면 모듈을 Cython으로 임포트하는 건 어떨까요?
이러면 처음 실행할 때 컴파일되겠죠?
저는 2001년에 이런 걸 만들었습니다( https://pyinline.sourceforge.net/ ). 그 오래된 물건은 이제 당연히 동작하지 않지만, 그 아이디어는 그때도 통했고 지금도 통할 겁니다. 다만 지금은 훨씬 나은 선택지가 많다고 생각합니다!
기술적으로 흥미로운 새 기능이, 본질적으로는 관료주의(와 개발자 개인의 여력 부족) 때문에 일부 죽게 된 것은 안타깝습니다. 한편으로 PEP 정책과 거기에 따르는 모든 관료적 절차를 엄격히 지키는 것이야말로 파이썬을 훌륭한 언어로 만든 요소라고 해도 무방할 겁니다. 좋든 나쁘든 말입니다.
기술적인 반론이 근거가 없었다는 말은 아닙니다. 아마 근거가 충분히 있었을 테고, 디버거와 계측(instrumentation) 지원 및 유지보수 작업만 해도 그것만으로 꽤 고통스러울 것 같습니다.
이 일이 관료주의와 조금이라도 관련이 있다고 결론짓는 것은 오판이라고 생각합니다. SC가 무력하게 끌려다닌 무생물 같은 정책의 문제가 아닙니다. 관료적 절차는 SC가 이 기능에 자신들이 중요하게 여기는 여러 속성이 부족하다는 점을 드러내는 데 쓴 도구였습니다. 언급된 대로 "유지보수, 호환성, ... 명확한 성공 지표" 같은 것들이죠. 구체적인 이유가 무엇이든, PEP는 SC 비판자들이 납득할 만큼 그것들을 설득력 있게 보여 주지 못해서 철회된 것입니다.
저는 그걸 관료주의라고 부르는 것도 마음에 들지 않습니다. 절차이기는 하죠. 하지만 추상적인 조직의 지옥이 여러 겹 쌓여 있는 얘기가 아닙니다. 프로젝트에서 일하고 프로젝트에 의존하는 다른 사람들이 이해하고, 조율하고, 불필요한 문제를 일으키지 않으리라는 합리적인 확신을 가질 수 있을 만큼, 무엇을 어떻게 할지 문서로 남기는 꽤 직접적인 절차를 말하는 겁니다.
그걸 글로 쓰고 여러 사람의 동의를 얻는 일이 부담스럽게 느껴진다면, 세계에서 두 번째로 인기 있는 프로그래밍 언어의 핵심을 바꾸는 일이 아닌 다른 일을 할 때 더 행복하실 수 있다는 신호일지도 모릅니다.
(수정: JIT 작업을 하는 핵심 개발자들을 깎아내리려는 말이 아니었습니다. 공개 토론 스레드를 보면 이들은 전 과정에서 아주 훌륭하게 대처해 왔습니다. SC가 프로젝트가 처음 PIP의 권한 범위를 한참 넘어섰다는 것을 깨닫기 전에 이만큼 진행되도록 둔 것은 안타깝고, 프로젝트를 이끈 사람들은 분명 몹시 속상할 겁니다. 저라면 이번 좌절을 그들만큼 의연하게 받아들이지 못했을 겁니다.)
문제는 PEP가 요구하는 대로 모든 세부 사항을 명확히 문서화하는 것이, JIT처럼 모든 세부 사항을 미리 알 수 없고 구현하면서 결정해야 하는 복잡한 새 기능과는 맞지 않는다는 겁니다. 절차나 관료주의는 실험과 정면으로 충돌합니다.
하지만 그들이 구현 세부 사항을 전부 요구한 건 아니었습니다. 명확하게 정리된 범위, 성공 기준, 지원 계획 같은 것을 요구했죠.
그들 스스로 지적했듯이 문제는 개방형 실험에 잘못된 점이 있다는 게 아닙니다. 다만 개방형 실험은 하필 main에 있을 게 아니라는 겁니다. 그들에게는 전 세계 핵심 인프라가 안정적이고 신뢰할 수 있는 상태로 유지되도록 고려해야 할 의무가 계속 있으니까요.