무슨 일이 있었나요?
파이썬 3.13에서 조용히 들어왔던 실험적 JIT 컴파일러가 CPython에서 빠지게 됐어요. 'JIT가 있었어?' 하는 분들도 꽤 있을 텐데요, 그럴 만해요. 기본값이 꺼져 있었고, 직접 빌드 옵션을 켜거나 환경 변수를 설정해야만 쓸 수 있었거든요. 그래서 대부분의 개발자는 한 번도 써보지 않고 지나갔을 가능성이 커요.
그래도 이 소식이 의미 있는 이유는, 이 JIT가 '파이썬은 왜 이렇게 느려?'라는 오래된 질문에 CPython 본진이 내놓은 가장 야심 찬 대답 중 하나였기 때문이에요. 몇 년간 이어진 '파이썬 빠르게 만들기' 흐름에서 한 갈래가 정리되는 순간이라고 보면 돼요.
잠깐, JIT가 뭐였죠?
JIT(Just-In-Time) 컴파일은 이게 뭐냐면, 프로그램이 실행되는 도중에 자주 쓰이는 코드를 그때그때 기계어로 바꿔서 더 빠르게 돌리는 기술이에요. 자바의 HotSpot이나 크롬의 V8 엔진이 대표적이죠. 매번 통역사를 거쳐 말하다가, 자주 쓰는 문장은 아예 외워버리는 것과 비슷해요.
CPython의 JIT는 조금 독특한 copy-and-patch 방식을 썼어요. CPython을 빌드할 때 LLVM(clang)으로 각 미세 명령(micro-op)에 해당하는 기계어 조각, 이른바 '스텐실'을 미리 만들어 둬요. 그리고 실행 중에는 이 조각들을 복사해서 이어 붙이고, 비어 있는 주소나 상수 자리만 채워 넣는 거예요. 레고 블록을 미리 찍어두고 조립만 하는 셈이라, 실행 시점에 무거운 컴파일러가 필요 없다는 게 장점이었어요.
전체 구조는 이렇게 3단계로 볼 수 있어요.
- 1단계: 3.11부터 들어온 특화 적응형 인터프리터(PEP 659)가 자주 실행되는 바이트코드를 실제 타입에 맞게 특화해요.
- 2단계: 뜨거운(hot) 코드 경로를 더 잘게 쪼갠 micro-op 트레이스로 만들어요.
- 3단계: JIT가 이 트레이스를 스텐실 조립 방식으로 기계어로 바꿔요.
- 파이썬 버전 업그레이드가 가장 싼 성능 개선이에요. JIT가 없어도 인터프리터 자체는 3.11 이후 꾸준히 빨라졌어요. 아직 3.8~3.10에 머물러 있다면 그것부터 검토해 보세요.
- 병목은 측정부터 하세요.
cProfile이나py-spy로 진짜 느린 곳을 찾은 다음, 그 부분만 NumPy·Polars 같은 네이티브 라이브러리나 Rust(PyO3) 확장으로 옮기는 게 여전히 가장 확실한 방법이에요. - free-threading을 지켜보세요. 멀티코어를 제대로 쓰는 쪽이 앞으로 파이썬 성능 이야기의 중심이 될 가능성이 커요.
3.14에서는 공식 Windows·macOS 배포판에도 포함돼서 PYTHON_JIT=1 환경 변수로 켜볼 수 있게 됐지만, 끝내 '실험적' 꼬리표는 떼지 못했어요.
왜 자리를 잡지 못했을까?
정확한 결정 배경은 원문 논의를 꼭 확인해 보시길 권하지만, 그동안 공개적으로 지적돼 온 문제들을 보면 고개가 끄덕여지는 부분이 많아요.
첫째, 성능 이득이 들쭉날쭉했어요. 공식 문서에서도 워크로드와 플랫폼에 따라 오히려 느려질 수 있다고 밝힐 정도였거든요. '켜면 확실히 빨라진다'는 확신을 주기 어려웠죠.
둘째, 유지보수 부담이 컸어요. 빌드에 특정 버전의 LLVM이 필요하고, CPU 아키텍처와 OS 조합마다 챙길 게 많아요. 인터프리터를 고칠 때마다 JIT 쪽도 함께 맞춰야 하니 코어 개발자들의 시간을 계속 잡아먹는 구조였어요.
셋째, 사람과 돈의 문제예요. JIT를 포함한 CPython 성능 작업을 이끌던 마이크로소프트의 Faster CPython 팀이 2025년 정리해고 여파를 크게 받았어요. 오픈소스에서 '누가 계속 책임지느냐'는 기술만큼 중요한 문제거든요.
넷째, 다른 우선순위와의 충돌도 있었어요. GIL 없는 free-threading 빌드가 3.14에서 공식 지원 단계로 올라왔는데, 실험적 JIT는 free-threading 빌드와 함께 쓸 수 없는 상태로 출발했어요. 두 마리 토끼를 쫓기엔 손이 부족했던 거죠.
다른 언어들은 어땠을까?
비교해 보면 재밌어요. Ruby의 YJIT는 Shopify가 전담 팀을 꾸려 꾸준히 투자했고, 대형 Rails 서비스에서 의미 있는 속도 향상을 보여주며 자리를 잡았어요. 반면 PHP 8의 JIT는 수치 연산 같은 CPU 집약 작업에선 효과가 있었지만, 정작 대부분의 웹 애플리케이션에선 체감 효과가 크지 않다는 평가를 받았죠.
파이썬 진영에도 이미 대안이 있어요. 순수 파이썬 코드를 통째로 빠르게 돌리는 PyPy, 수치 계산 함수에 데코레이터 하나로 JIT를 거는 Numba, 메타가 인스타그램 서비스용으로 만든 Cinder 같은 것들이요. 결국 교훈은 'JIT는 한 번 만들고 끝나는 기능이 아니라, 전담 인력이 몇 년씩 붙어야 하는 장기 프로젝트'라는 거예요.
한국 개발자에게는 어떤 의미일까?
솔직히 당장 바뀌는 건 거의 없어요. 기본으로 꺼져 있던 기능이니까요. 다만 빌드 옵션이나 환경 변수로 JIT를 켜서 실험하던 팀이라면 그 설정을 걷어낼 준비만 해두면 돼요. 오히려 이번 소식에서 챙길 실무 포인트는 이거예요.
마무리
한 줄 정리: CPython의 실험적 JIT는 아이디어보다 '지속 가능한 투자'의 벽에 부딪혔고, 파이썬 성능의 무게중심은 인터프리터 개선과 free-threading 쪽으로 옮겨가고 있어요.
여러분은 실무에서 파이썬 성능 문제를 어떻게 풀고 계신가요? 언젠가 CPython에 JIT가 다시 돌아와야 한다고 보시나요, 아니면 '느린 부분은 네이티브로'가 가장 파이썬다운 해법이라고 생각하시나요?
🔗 출처: Hacker News