반복 계산이 많은 Python 서비스를 PyPy로 옮기려 합니다. trace JIT가 유리한 코드와 예열·C 확장 때문에 불리할 수 있는 경우를 어떻게 검증하나요?

PyPy가 모든 Python 프로그램을 CPython보다 빠르게 실행하는 것은 아닙니다. PyPy는 Python 언어를 실행하는 인터프리터에 trace JIT(Just-In-Time) 컴파일을 적용해, 실행 중 자주 반복되는 경로를 관찰하고 그 경로에 특화된 기계어를 만들어 인터프리터 호출 비용을 줄입니다. 타입과 분기 패턴이 안정적인 긴 루프에서 특히 이득이 생길 수 있습니다.

hot path를 전문화하는 JIT

대신 처음 몇 번의 실행에는 추적·컴파일·최적화 비용이 들어가므로 짧은 CLI나 한 번만 실행되는 작업은 예열 비용 때문에 이득이 없을 수 있습니다. JIT가 가정한 경로에서 벗어나면 deoptimization으로 인터프리터 경로로 돌아갈 수도 있습니다. 따라서 마이크로벤치마크의 첫 실행값이 아니라 실제 요청 수명, steady state 처리량, p95 지연, 메모리 사용량을 CPython과 동일한 조건에서 비교해야 합니다.

예열과 의존 패키지

또 하나의 경계는 C 확장입니다. PyPy는 CPython의 C ABI를 그대로 실행하는 방식이 아니므로 일부 확장은 호환 계층이나 별도 지원에 의존하고, 내부 객체 표현을 직접 다루는 확장은 성능·호환성 제약을 받을 수 있습니다. 순수 Python 계산이 병목인지, NumPy 같은 확장이 이미 대부분의 시간을 쓰는지에 따라 결과가 달라집니다. 런타임만 바꾸기보다 의존 패키지 지원, 배포 이미지, 프로파일 결과를 먼저 확인하고 반복되는 순수 Python 경로가 길면 PyPy를 선택하겠습니다.

선택 기준과 검증

짧은 CLI와 장수 worker의 결론은 다를 수 있습니다. 전자는 trace 생성 비용이 결과를 지배하고 후자는 hot loop가 누적 이득을 만들 수 있습니다. DB·NumPy·암호화처럼 시간이 C 확장이나 외부 서비스에 있으면 PyPy JIT가 병목을 바꾸지 못하므로, 순수 Python 비중과 패키지 호환을 먼저 프로파일링하겠습니다.

추적 JIT는 자주 실행되는 경로를 기계어로 만들면서 타입과 분기 조건에 guard를 둘 수 있습니다. 예를 들어 정수 연산만 하던 루프에 다른 타입이 들어오면 해당 가정을 확인하고 다른 경로로 빠질 수 있습니다. 입력 변화가 항상 전체 코드를 무효화한다는 뜻은 아니며 bridge trace 등 구현의 대응이 있을 수 있으므로 실제 JIT 로그로 판단하겠습니다.

임시 객체가 함수 밖으로 탈출하지 않는 경로는 할당을 제거하거나 값으로 다루는 최적화의 이득을 얻을 수 있습니다. 반대로 외부 C API로 자주 넘어가 객체 표현을 실체화해야 하면 그런 이득이 줄 수 있습니다. JIT가 줄일 수 있는 순수 Python 부분이 전체 요청의 일부뿐이라면 그 부분이 몇 배 빨라져도 전체 응답 개선은 제한됩니다. 이를 암달의 법칙 관점에서 병목 비율과 함께 설명하고, 배포 비용·패키지 호환·메모리 사용까지 포함해 선택하겠습니다.