파이썬 JIT 컴파일러 정리: 3.13 실험 도입부터 기대치 조정까지

프로그래밍 언어 파이썬 JIT CPython
8 분 소요

파이썬 3.13부터 CPython에 JIT 컴파일러가 실험적으로 들어왔습니다. “파이썬도 드디어 JIT로 빨라진다"는 기사 제목을 봤다면, 기대치를 한 번 점검할 필요가 있습니다. 들어온 것은 맞지만, 지금 당장 체감할 만큼 빨라지는 것은 아니기 때문입니다. 이 글에서는 JIT가 어떤 방식으로 동작하는지, 어떻게 켜는지, 그리고 2026년 중반 시점에서 어디까지 와 있는지를 정리하겠습니다.

Faster CPython이 만들어 온 흐름 #

“파이썬은 느리다"는 통념은 오래됐지만, 최근 몇 년의 CPython은 꾸준히 빨라졌습니다. 변화의 중심에는 Faster CPython 프로젝트가 있었습니다. 파이썬 창시자 귀도 반 로섬과 마크 섀넌이 이끈 이 팀의 첫 큰 성과가 3.11의 특수화 적응형 인터프리터(PEP 659)입니다. 같은 바이트코드 자리에서 같은 타입이 반복해서 들어오면, 그 자리를 타입 전용 명령으로 바꿔치기하는 방식입니다. 이것만으로 3.11은 3.10 대비 평균 1.25배 빨라졌습니다.

3.12는 내부 구조를 다듬었고, 3.13에서 드디어 JIT가 등장했습니다. 특수화가 “인터프리터 안에서 할 수 있는 최적화"였다면, JIT는 그 다음 단계인 “기계어를 직접 만드는 최적화"입니다.

인터프리터와 JIT의 차이 #

인터프리터는 바이트코드를 한 개씩 읽고, 그때마다 “이 명령이 무슨 뜻인지"를 확인한 뒤 해당 C 코드를 실행합니다. 매번 확인하는 비용이 누적되는 구조입니다.

JIT(Just-In-Time) 컴파일러는 실행 중에 자주 반복되는 구간을 골라, 그 구간만 기계어로 만들어 둡니다. 요리사가 처음 보는 메뉴는 레시피를 한 줄씩 확인하며 만들지만, 매일 수백 번 나가는 메뉴는 손에 익어 레시피를 보지 않는 것과 비슷합니다. 자주 도는 루프일수록 “확인하는 비용"을 없애는 효과가 커집니다.

자바의 HotSpot, 자바스크립트의 V8이 이 방식으로 동적 언어를 빠르게 만든 대표 사례입니다. 파이썬 진영에도 PyPy라는 JIT 구현이 오래전부터 있었지만, CPython 본체에 JIT가 들어온 것은 3.13이 처음입니다.

copy-and-patch: 템플릿을 복사해 붙이는 JIT #

3.13의 JIT(PEP 744)는 copy-and-patch라는 기법을 씁니다. 2021년 하오란 쉬와 프레드릭 숄스타드의 연구에서 나온 비교적 새로운 방식입니다.

전통적인 JIT는 런타임에 컴파일러 인프라를 통째로 들고 다닙니다. 중간 표현을 만들고, 최적화 패스를 돌리고, 레지스터를 할당해서 기계어를 생성합니다. 강력하지만 구현과 유지보수 부담이 큽니다.

copy-and-patch는 접근이 다릅니다.

  • 빌드 시점: CPython을 빌드할 때 각 마이크로 연산에 대응하는 기계어 조각, 즉 스텐실(stencil)을 LLVM으로 미리 생성해 둡니다.
  • 실행 시점: 자주 도는 코드 경로가 발견되면, 해당하는 스텐실들을 메모리에 복사(copy)한 뒤 비어 있는 구멍에 실제 주소와 상수만 채워(patch) 이어 붙입니다.

런타임에는 컴파일러가 필요 없고, 기계어 생성이 사실상 “복사 + 빈칸 채우기"라서 매우 빠릅니다. 코드 규모도 작아서 적은 인원으로 유지보수할 수 있습니다. 모든 플랫폼을 지원해야 하고 릴리스 주기가 정해져 있는 CPython에는 이 단순함이 결정적인 장점이었습니다. 3.13에서 도입된 Tier 2 마이크로 연산 트레이스 위에 그대로 얹히는 구조라는 점도 맞아떨어졌습니다.

3.13에서 켜는 법 #

3.13의 공식 배포 바이너리에는 JIT가 들어 있지 않습니다. 직접 소스를 빌드해야 합니다.

3.13: 소스 빌드로 활성화 
./configure --enable-experimental-jit
make

빌드에는 포함하되 기본은 꺼 두는 옵션도 있습니다. 이 경우 실행 시점에 환경변수로 켭니다.

빌드는 포함, 실행 시점에 선택 
./configure --enable-experimental-jit=yes-off
make

# 실행할 때만 켜기
PYTHON_JIT=1 python myapp.py

Windows에서는 PCbuild/build.bat --experimental-jit을 사용합니다. 어느 쪽이든 3.13에서 JIT를 써 보려면 빌드 환경을 직접 갖춰야 했기 때문에, 사실상 코어 개발자와 얼리어답터를 위한 기능이었습니다.

3.14에서의 상태 #

2025년 10월에 나온 3.14에서 문턱이 낮아졌습니다. 공식 macOS·Windows 설치 파일에 실험적 JIT 빌드가 포함됐습니다. 여전히 기본은 꺼져 있고, 환경변수로 켭니다.

3.14: 공식 설치 파일에서 켜기 
PYTHON_JIT=1 python myapp.py

켜졌는지는 3.14에 추가된 sys._jit 네임스페이스로 확인할 수 있습니다.

JIT 상태 확인 (3.14+) 
import sys

print(sys._jit.is_available())  # 이 빌드에 JIT가 포함됐는지
print(sys._jit.is_enabled())    # 지금 켜져 있는지

내부적으로도 핫 경로 감지와 메모리 사용이 다듬어졌습니다. 다만 한 가지 구분할 점이 있습니다. 3.14가 3.13보다 전반적으로 빨라진 것은 맞지만, 그 공의 대부분은 JIT가 아니라 인터프리터 자체 개선(테일 콜 기반 인터프리터 등)에 있습니다. JIT는 아직 “기본으로 켤 만큼 검증된 가속 수단"이 아니라 “공식 바이너리에 실려 누구나 실험해 볼 수 있게 된 기능"입니다.

현실 점검: 지금 얼마나 빨라지는가 #

그래서 지금 JIT를 켜면 얼마나 빨라질까요? 솔직한 답은 “거의 차이 없다"입니다.

  • 공식 문서의 표현 자체가 “일부 프로그램이 빨라질 수 있다"이고, 성능 향상은 아직 크지 않다고 명시합니다.
  • 공개된 벤치마크들에서 JIT의 효과는 평균 수 퍼센트 수준이고, 워크로드에 따라 오히려 느려지는 경우도 있습니다. 3.14 출시 직후 미겔 그린버그의 측정에서도 JIT 빌드는 일반 빌드와 의미 있는 차이를 보이지 못했습니다.
  • 짧게 실행되고 끝나는 스크립트나 CLI 도구는 워밍업 비용 때문에 JIT가 불리합니다. 핫 루프가 충분히 돌아야 컴파일된 코드가 본전을 뽑습니다.

이는 실패가 아니라 예고된 단계입니다. copy-and-patch의 첫 목표는 “당장 빠른 JIT"가 아니라 “기계어 생성 기반을 본체에 안전하게 들여놓는 것"이었습니다. 토대 위에 최적화를 쌓는 작업은 이제 진행 중입니다. 정리하면, 지금 시점에 JIT가 의미 있는 대상은 CPython 내부에 관심 있는 개발자와 벤치마크를 직접 돌려 보고 싶은 사용자이고, 프로덕션 서비스가 이것으로 비용을 줄일 단계는 아닙니다.

기존 가속 수단과의 관계 #

“파이썬을 빠르게"라는 요구 자체는 새롭지 않고, 이미 검증된 수단들이 있습니다.

  • PyPy: JIT를 가진 별도의 파이썬 구현입니다. 순수 파이썬 코드라면 지금도 CPython JIT와 비교할 수 없이 빠르지만, C 확장 호환성이 약점입니다.
  • Cython·mypyc: 핫스팟을 C로 컴파일하는 방식입니다.
  • Rust 확장(PyO3): 성능이 중요한 부분을 Rust로 작성합니다.
  • NumPy 벡터화: 수치 계산이라면 여전히 가장 효과가 큰 선택입니다.

당분간 실무의 답은 그대로입니다. 느린 곳을 측정으로 찾고, 그 부분에 위 수단을 적용하는 것입니다. 느린 곳을 찾는 방법은 모던 파이썬 고급 #7에서 정리했습니다. CPython JIT의 의미는 이런 우회 수단 없이 “그냥 최신 파이썬을 쓰면 빨라지는” 미래를 본체 안에서 준비한다는 데 있습니다.

free-threading과의 관계 #

“더 빠른 파이썬"에는 두 개의 축이 있습니다. 단일 스레드 실행 속도를 올리는 JIT, 그리고 여러 코어를 동시에 쓰게 하는 free-threading입니다. 둘은 별개의 프로젝트이고 진행 속도도 다릅니다. free-threading은 3.14에서 공식 지원 단계(PEP 779)로 올라섰지만, JIT는 여전히 실험 단계입니다. 또한 3.14 기준으로 free-threaded 빌드에서는 JIT를 함께 쓸 수 없습니다. 두 축을 한 빌드에서 결합하는 것은 앞으로의 과제입니다.

앞으로 지켜볼 것 #

변수가 하나 있습니다. 2025년 5월 마이크로소프트가 대규모 감원 과정에서 Faster CPython 팀 대부분을 내보냈습니다. 프로젝트를 후원하던 가장 큰 동력이 빠진 셈입니다. 다만 JIT 개발 자체는 코어 개발자들과 커뮤니티 주도로 계속되고 있고, 3.14의 개선도 그 흐름에서 나왔습니다.

앞으로 확인할 항목은 세 가지입니다.

  1. 3.15 이후의 성능 곡선: 토대 위에 쌓이는 최적화가 평균 수 퍼센트의 벽을 넘는지가 관건입니다.
  2. 기본 활성화 시점: 공식 빌드에서 JIT가 기본으로 켜지는 버전이 나오면 그때가 진짜 전환점입니다.
  3. free-threading과의 결합: 두 축이 한 빌드에서 함께 동작해야 “빠르고 병렬적인 파이썬"이 완성됩니다.

정리 #

CPython 3.13에 copy-and-patch 방식의 JIT가 실험적으로 들어왔고, 3.14부터는 공식 macOS·Windows 설치 파일에서 PYTHON_JIT=1만으로 켜 볼 수 있습니다. 빌드 시점에 만들어 둔 기계어 템플릿을 복사해 붙이는 단순한 구조 덕분에 CPython이 감당할 수 있는 형태로 들어왔지만, 현재 성능 효과는 평균 수 퍼센트 수준에 머뭅니다. 지금은 “켜면 빨라지는 스위치"가 아니라 “앞으로 빨라질 기반"으로 이해하는 것이 정확합니다. 당장의 성능 문제는 프로파일링과 검증된 가속 수단으로 풀고, JIT는 3.15 이후의 성능 곡선과 기본 활성화 시점을 기준으로 지켜보면 됩니다.

X