TECH 으로 돌아가기
TECH HACKER NEWS 오늘 8분 읽기 24 READS

파이썬 3.15는 얼마나 빨라졌을까? 인터프리터·JIT·프리스레딩으로 보는 현주소

파이썬 3.15는 얼마나 빨라졌을까? 인터프리터·JIT·프리스레딩으로 보는 현주소
SOURCE IMAGE · HACKER NEWS
파이썬 3.15는 얼마나 빨라졌을까? 인터프리터·JIT·프리스레딩으로 보는 현주소

매년 10월이면 돌아오는 질문

파이썬은 매년 10월에 새 버전이 나와요. 그리고 그때마다 “그래서 이번엔 얼마나 빨라졌는데?”라는 질문이 따라오죠. Flask 메가 튜토리얼로 유명한 Miguel Grinberg는 몇 년째 새 버전이 나올 때마다 여러 파이썬 버전을 같은 조건에서 비교하는 글을 써왔는데, 이번에 3.15 편이 올라왔어요.

그의 벤치마크는 일부러 단순하게 만들어져 있어요. 그동안 재귀 피보나치나 버블 정렬처럼 순수 파이썬 코드로 CPU만 열심히 쓰는 작업을 여러 버전에서 돌려서 시간을 비교해왔거든요. DB나 네트워크 대기 같은 변수를 빼고 “인터프리터 자체가 얼마나 빨라졌나”만 보려는 거예요.

파이썬 성능을 보는 세 가지 축

요즘 파이썬 성능 이야기는 크게 세 갈래로 나뉘어요.

1. 기본 인터프리터 개선. 3.11부터 이어진 'Faster CPython' 흐름 덕분에 버전마다 꾸준히 빨라졌어요. 대표적인 게 적응형 특화(specializing) 기법인데요, 이게 뭐냐면 같은 a + b라도 a와 b에 계속 정수만 들어오면 '정수 덧셈 전용' 명령으로 바꿔치기해서 매번 타입을 확인하는 비용을 줄이는 거예요.

2. JIT 컴파일러. 3.13에서 실험적으로 들어온 JIT는 자주 실행되는 코드를 기계어로 바꿔서 더 빠르게 돌리려는 시도예요. 3.14부터는 윈도우·macOS 공식 설치 파일에도 들어가서 환경 변수로 켤 수 있게 됐지만, 기본값은 여전히 꺼져 있어요. 작년 3.14 측정에서는 JIT를 켜도 눈에 띄는 차이가 거의 없었는데, 3.15 개발 과정에서 JIT 성능이 좋아졌다는 소식이 나왔던 만큼 이번엔 그게 숫자로 얼마나 드러나는지가 관전 포인트예요.

3. 프리스레딩(free-threading). GIL을 없앤 빌드예요. GIL(Global Interpreter Lock)은 “한 번에 한 스레드만 파이썬 코드를 실행할 수 있다”는 자물쇠인데, 이게 있으면 스레드를 여러 개 띄워도 CPU 코어를 사실상 하나밖에 못 써요. 프리스레딩은 3.14에서 공식 지원 단계로 올라왔고, 작년 측정에서는 단일 스레드에선 일반 빌드보다 조금 느렸지만 멀티스레드 CPU 작업에선 코어 수에 따라 크게 빨라지는 모습을 보였죠.

숫자에 안 잡히는 3.15의 변화들

벤치마크 수치 말고도 체감할 만한 변화가 꽤 있어요. 우선 명시적 지연 임포트(PEP 810)가 들어왔어요. lazy import json처럼 쓰면 그 모듈을 실제로 쓰는 순간까지 로딩을 미뤄줘서, CLI 도구처럼 시작 속도가 중요한 프로그램에선 효과가 클 수 있어요. 실행 중인 프로세스를 거의 방해하지 않고 들여다보는 샘플링 프로파일러(PEP 799)도 표준 라이브러리에 들어왔고요. 그리고 UTF-8 모드가 기본값(PEP 686)이 됐어요. 한국어 윈도우에서 인코딩 지정 없이 파일을 열었다가 cp949 관련 UnicodeDecodeError를 만나본 분들께는 정말 반가운 소식이죠.

마이크로벤치마크 읽는 법

주의할 점도 있어요. 피보나치나 버블 정렬은 함수 호출, 반복문, 정수 연산만 잔뜩 하는 코드예요. 실제 웹 서버는 대부분의 시간을 DB 응답이나 네트워크를 기다리며 보내니까, 인터프리터가 20% 빨라져도 API 응답 시간이 20% 줄지는 않아요. 데이터 분석도 핵심 연산은 NumPy·pandas 안쪽의 C 코드에서 돌아가기 때문에 영향이 크지 않고요.

반대로 순수 파이썬으로 짠 알고리즘, 파서, 시뮬레이션처럼 CPU를 많이 쓰는 코드라면 버전만 올려도 공짜로 성능이 좋아져요. 그리고 이런 순수 연산 벤치마크에선 본격적인 JIT를 갖춘 PyPy가 여전히 CPython보다 한참 앞서 있다는 것도 매년 반복되는 풍경이에요.

업계 맥락

파이썬의 속도 문제를 푸는 방식은 여러 갈래로 나뉘었어요. CPython 본체는 인터프리터 최적화와 JIT를 조금씩 쌓아가는 중이고, 정말 빨라야 하는 쪽에서는 핵심 도구를 아예 Rust로 다시 쓰거나(uv, Ruff) Rust로 확장 모듈을 짜는(PyO3 기반 pydantic-core 등) 흐름이 대세가 됐죠. 2025년에는 마이크로소프트가 Faster CPython 팀 지원을 줄이면서 개선 동력이 꺾이지 않을까 걱정하는 목소리도 있었는데, 그 뒤로도 커뮤니티 중심으로 개선이 이어지고 있다는 건 반가운 일이에요.

한국 개발자에게 주는 시사점

운영 중인 서비스라면 업그레이드 전에 주요 의존성, 특히 C 확장이 들어간 패키지가 3.15용 휠을 제공하는지부터 확인하세요. 그리고 남의 벤치마크보다 내 코드로 잰 숫자가 훨씬 중요해요. uv를 쓰면 여러 버전을 비교하는 게 아주 간단하거든요.

uv python install 3.14 3.15 3.15t
uv run --python 3.14 bench.py
uv run --python 3.15 bench.py
uv run --python 3.15t bench.py

여기서 3.15t가 프리스레딩 빌드예요. 멀티스레드로 CPU 작업을 나눠 처리하는 코드라면 꼭 한번 비교해보세요. 더 정밀하게 재고 싶다면 pyperf 같은 도구에 반복 측정과 통계 처리를 맡기는 게 좋아요.

마무리

한 줄 정리: 파이썬은 매년 조금씩 꾸준히 빨라지고 있어요. 하지만 진짜 성능 개선은 내 코드가 어디서 시간을 쓰는지 아는 데서 시작해요.

여러분 팀은 파이썬 버전 업그레이드를 보통 언제 하시나요? 프리스레딩이나 JIT를 실서비스에서 켜볼 생각이 있으신지도 궁금해요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://blog.miguelgrinberg.com/post/how-fast-is-python-3-15
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...