Python 3.14가 출시되었습니다. 얼마나 빨라졌을까요?

• 이번에 공개된 Python 3.14는 지금까지의 CPython 버전 중 가장 빠른 성능을 보임
• 단일 스레드에서는 3.14가 3.13 대비 약 27% 개선을 보였고, JIT 의 성능 향상은 미미하고, Free-threading 인터프리터는 단일 스레드에서 소폭 느림
• 멀티스레드에서는 FT 인터프리터가 GIL 제거 효과로 Fibonacci 3.1배, 버블 정렬 2배 수준의 가속을 보여 CPU 집약 멀티스레드에 유효함
• 결론적으로 3.14가 CPython 중 가장 빠르며, 3.11 이상 권장, Pypy는 여전히 매우 빠르며 JIT은 성숙도 향상 필요

---

벤치마크 전제와 한계

• Python 3.14의 공식 출시 직후 여러 버전의 Python 및 다른 언어와의 성능 벤치마크 결과를 공유함
• 이 테스트는 순수 Python 코드만으로 작성된 간단한 재귀(피보나치)와 반복(버블 정렬) 함수로 진행
• 실제 개발 현장에서는 C/C++/Rust 등 네이티브 코드와 섞어 쓰는 경우가 많으므로, 이 결과는 실제 상황에는 1:1 대응하지 않음

테스트 매트릭스

• 테스트 환경
  • Python 6가지 버전(3.9~3.14), Pypy, Node.js, Rust 포함
  • Python 인터프리터: 표준(Standard), JIT, Free-threading(각각 3.13 이상)
  • 테스트 스크립트: 피보나치(fibo.py), 버블정렬(bubble.py)
  • 스레드 모드: 단일 스레드, 4 스레드
  • 테스트 머신: Linux(Framework i5), macOS(M2)
• Node.js, Rust 버전도 참고 대상으로 함께 비교

테스트 스크립트

• 피보나치(fibo.py): 재귀 구조 사용, fibo(40)을 각 환경에서 실행
• 버블 정렬(bubble.py): 10,000개의 랜덤 숫자 정렬
• 각 테스트는 3회 반복하여 평균값 산출
• 테스트 코드는 GitHub 저장소에 공개

Benchmark #1: 피보나치(단일 스레드)

• Python 3.14는 3.13 대비 약 27% 향상된 속도(6.59초 vs 8.26초) 기록
• 3.11 버전에서부터 "매우 느림"에서 "그나마 덜 느림"으로 전환됨
• Pypy는 3.14보다 약 5배 빠르며, Node.js와 동급, Rust는 압도적으로 가장 빠름
• Free-threading은 단일 스레드에서 표준 버전보다 여전히 느리지만, 3.14로 오면서 속도 차이가 감소(91% 수준)

JIT, Free-threading 인터프리터

• JIT은 이 재귀 함수 구조에서 체감 성능 향상 없음
• Free-threading은 단일 스레드에서는 오히려 약간 느린 결과
• JIT의 성능 향상 한계는 함수 구조에 따라 다를 수 있음

Benchmark #2: 버블 정렬(단일 스레드)

• Python 3.14가 3.11 대비 근소하게 더 빠르나, 격차는 피보나치보다 작음(3.14: 2.18초, 3.11: 2.48초)
• Pypy는 3.14보다 약 18배 빠름
• JIT은 Linux 환경에서 소폭 빠르기도, macOS에서는 차이가 거의 없음

Benchmark #3: 피보나치(멀티스레드)

• 표준 인터프리터에서는 GIL(Global Interpreter Lock)로 인해 스레드 수를 늘려도 기대만큼 빠르지 않음
• Free-threading 인터프리터(3.14)는 표준 대비 3.1배 빨라짐
• JIT의 영향은 거의 확인되지 않음
• Pypy 결과만 측정 진행됨, Node.js/Rust는 이 테스트에서 비교하지 않음

Benchmark #4: 버블 정렬(멀티스레드)

• Free-threading(3.14 FT)이 표준(3.14) 대비 2배 빠른 결과(특히 CPU 집약 작업에서 장점 부각)
• JIT은 명확한 성능 우위 없음
• Mac의 Free-threading 성능이 눈에 띔

결론

• CPython 3.14가 현존 CPython 중에서 가장 빠른 성능을 보임
• 업그레이드가 어렵다면 3.11 이상 버전 사용 권장
• JIT 인터프리터는 실제로 체감되는 속도 증가는 미미했음
• Free-threading 인터프리터는 멀티스레드 CPU 집약 상황에서 뚜렷한 장점
• Pypy는 압도적으로 빠르며, 추가적인 탐구의 가치가 큼

기타

• 결과는 다양한 환경 변수에 따라 다를 수 있으니, 직접 벤치마크 및 확인 권장
• 자세한 내용 및 코드는 GitHub 저장소 참조 가능

[GN⁺]

Hacker News 의견

• 저의 인생을 바꿔 준 분에 대해 이야기하고 싶음. Flask mega tutorial을 통해 첫 웹사이트를 만들었고, 런칭 직전 Flask에서 깨진 파일을 처리하는 중요한 부분에서 막혔는데, 질문을 했더니 Stack Overflow 답변으로 해결해서 바로 사이트에 반영해 버림. 그 이후 사이트가 엄청 퍼졌음. 참고용으로 답변 링크를 남겨둠 stackoverflow link

  • Flask와는 상관 없지만, 새로운 Flask 로고는 정말 마음에 안 듦. 이전 로고는 빈티지하고 손수 만든 듯한 느낌이 있었는데, 새 로고는 마치 고등학생이 WordArt로 장난삼아 만든 작품 같음. 이전 로고, 새 로고

  • 혹시 네가 만든 사이트가 yout.com 인가 질문하고 싶음. 아직도 Flask를 쓰고 있는지 궁금함

  • 한번쯤 다시 vibe coding을 하며 microphonetest.com 사이트가 부활하면 정말 좋겠음

• 벤치마크를 짤 때 루프 안에서 시간을 측정해서 합산하는 식으로 하지 않길 권장함. 전체 루프의 실행 시간을 측정한 후 반복 수로 나누는 게 좋음. 시간 측정 자체에서 생기는 지터로 결과가 왜곡될 수 있음

  • 표준 라이브러리의 timeit을 추천함 timeit docs

• Python이 3.14 버전에서 TeX처럼 고정될까봐 걱정됨 Reddit 링크

  • "멈추지" 않길 바란다는 의견을 보며, Donald Knuth가 변화보다는 지속적으로 동일한 결과를 내는 시스템을 더 중시한다는 부분이 신선하게 느껴짐. 모든 게 몇 년만 지나면 구식이 되는 세상에서, 뭔가 OOO가 새로 나왔다고 무조건 바꿔야 하는 강박은 병 같다는 생각임. 우리가 정말 100년 쓸 코드를 쓸 수 없을 이유가 없음. 코드는 결국 수학임. 수천 년 전 발명된 다항식 쓰면 촌스러운 사람 취급받지 않는 것처럼, 검증된 것에 머무르는 자세도 필요하다고 봄. 매번 새 버전, 새 도구에만 집착하지 않아도 됨. 바꿀 이유 없는 코드를 쓰는 사람들이 진짜 기여하는 분들이라고 생각함

  • πthon 관련 농담에 놀랍게 잘 어울리는 상황이라는 코멘트

• Python 뉴스가 나올 때마다, 2025년에도 PyPy가 여전히 별도의 노선이라는 사실이 아쉬움. GIL 없는 Python이 someday GIL 없는 C FFI까지 가능하게 해줄지 궁금함. 그건 Python에 정말 큰 도움이 될 거라고 생각함

  • C FFI는 예전부터 GIL을 수동 해제할 수 있었기 때문에, 그 의미가 뭔지 정확히 궁금함

  • C 언어에서 출발해 여러 컴파일러 구현으로 다양한 방언이 탄생하는 게 건강한 생태계라고 생각함. 실험과 발전을 촉진하기 때문. PyPy와 CPython의 차이도 크지 않다고 여기며 호환성도 높음 pypy 호환 안내

  • freethreading이 바로 그 목적임. 아직 여러 C FFI 라이브러리가 GIL 없이 동작하도록 바뀌지 않아서, 기본값으로 freethreading을 쓸 수 없다고 알고 있음

  • Python이 실험적 JIT을 추가하여 PyPy에 한 발짝 더 다가간 셈임. 앞으로 새로운 JIT을 직접 만들지 PyPy를 합칠지는 모르겠지만, PyPy에서 많은 것을 배웠다고 믿음

  • 이런 문제(별도 구현 체계를 합치는 것)가 바뀔 수 있다고 보는지 묻고 싶음. Python이 우연히 성능에 악영향을 끼치는 또 다른 브레이킹 체인지를 도입하는 시나리오는 넓은 범위의 사용자들에게 해가 될 것임. Python 조직이 과연 그걸 바랄까 의문임

• PyPy가 멀티스레드 코드에서도 free threaded CPython보다 더 빠르다는 점이 흥미로움

• non-GIL로 전환이 매우 매끄럽게 진행된 것이 눈에 띔. 2→3 버전 때랑 비교하면 이번 전환은 정말 대단함. 표준 속도에 금방 도달한 점도 기대가 크며, 비호환 요소들도 곧 사라질 수 있을 거라 희망함

• 벤치마크를 빠르게 직접 해보고 싶다면 fast_langton_ant 리포를 추천함. "python3 server.py -s 10000000 -n" 식으로 실행하면 됨

• 접히는 댓글(fold comment) 기능이 karma나 다른 옵션에 따라 적용되는지 궁금함. Miguel이 도와준 에피소드가 가장 인기 있는 글이라 인상 깊었지만, 본문과 관련된 이야기만 보고 싶을 때 접기 기능이 없다는 걸 처음 깨달았음

• 단순한 반복문과 정수 연산만 사용하는 벤치마크로 Python의 현실적인 사용을 평가하기엔 무리라고 생각함. 해시맵이나 문자열 처리가 더 실제 코드에 가까움. 많은 Python 사용자는 숫자 연산은 외부 라이브러리에 맡김

  • 벤치마크는 모두 특정 기준으로 측정하게 설계되기 마련임. 본인이 글에서 목표를 설명했으니 궁금하면 참고하길 추천함

  • 더 철저히 분석하는 글이었다면 좋겠지만, 그래도 내 실제 사용에는 이런 벤치마크가 더 잘 맞음. 나의 경우 대부분 몬테카를로 시뮬레이션 또는 간단한 과학계산을 다양한 문제에 반복해서 만듦. 일회성 시뮬레이션에 굳이 빠른 알고리즘이나 익숙하지 않은 라이브러리를 쓰지 않음. 가끔 10분이나 걸려도 상관없음(예, scipy, numpy는 주로 쓰긴 함). 반복 가정 변경을 자주 하다보니 최대한 단순하게 접근함. 가독성과 즉석 코드가 중요하고, 최적화가 잘 안 되어도 상관 없음(예: 피보나치, 버블 소트, 중첩 for문처럼). 만약 진짜 성능이 필요할 땐 cpp/zmp/pybind/numba로 내용을 직접 구현함

  • FastAPI 엔드포인트 호출이나 numpy 계산 같이 대중적인 예제를 벤치마크에 포함시키는 게 현실적인 Python사용에 더 가까움. 이런 부분이 순수 python코드가 아닐 수 있지만, 실제로 많은 사람들이 Python을 그렇게 씀

• tight loop와 int연산만으로 벤치마크하는 것이 얼마나 현실적인지 의문임

• 새로운 실험적 tail call 인터프리터(옵션 --with-tail-call-interp)가 벤치마크에 포함됐는지 궁금함 tail-call-interp 공식 문서. 테스트 결과에서 언급이 없어 아마 포함이 안 된 것 같다고 추측함. tail call interpreter가 기존 다른 구현과 얼마나 차이나는지 비교해보고 싶음

  • 본인이 사용한 Python 빌드는 tail call 기능이 켜진 상태(옵션 --with-tail-call-interp)였음. 최적화가 재귀 tail call에도 적용되는지 확실하진 않지만, 적용됐다면 Fibonacci 테스트에서 성능 향상을 봤어야 함