Python 3.13 Free-Threaded 모드 — GIL 없애면 실제로 얼마나 빨라지나

Python의 20년 묵은 병목이 드디어 풀렸다. PEP 703이 Python 3.13에 실험적으로 포함됐고, 지금 당장 GIL 없는 Python을 써볼 수 있다.

## GIL이 뭐고, 왜 문제였나

GIL(Global Interpreter Lock)은 CPython 인터프리터가 한 번에 하나의 스레드만 Python 바이트코드를 실행하도록 강제하는 뮤텍스다. 1991년 CPython 설계 당시 메모리 관리를 단순화하기 위해 도입됐다.

문제는 CPU-bound 작업에서 드러난다. 8코어 서버에서 8개 스레드를 띄워도 GIL 때문에 실제로는 코어 1개만 쓰는 것과 같다. 이 때문에 Python에서 CPU-bound 병렬화는 전통적으로 `threading` 대신 `multiprocessing`을 써야 했다.

```python
# GIL 환경: threading이 느린 이유
import threading, time

def count(n):
    while n > 0:
        n -= 1

# 단일 스레드로 2억번 카운트: ~12초
# threading으로 2개 스레드 각각 1억번: 역시 ~12초 (GIL 때문에 직렬화됨)
# multiprocessing으로 2개 프로세스: ~6초 (실제 병렬)
```

## Python 3.13 free-threaded 모드 활성화

```bash
# 바이너리 확인 (t = free-threaded build)
python3.13t --version
# Python 3.13.0 experimental free-threading build

# 또는 일반 빌드에서 플래그로
python3.13 --disable-gil -c "import sys; print(sys._is_gil_enabled())"
# False
```

Linux에서 직접 빌드하려면:

```bash
./configure --disable-gil
make -j8
```

pyenv는 3.13t 지원을 2024년 말에 추가했고, Docker 공식 이미지도 `python:3.13-rc-slim-bookworm` 기반에서 테스트 가능하다.

## 실제 성능: CPU-bound 기준

CPython 코어 팀이 공개한 벤치마크(2024년 10월, Meta/SAP/Google 엔지니어 공동 측정)에서:

| 작업 | 단일스레드 | threading(GIL) | threading(no-GIL) | multiprocessing |
|------|-----------|----------------|-------------------|-----------------|
| 소수 계산 100만개 | 1.0× | 1.0× (직렬화) | **3.8×** (4코어) | 3.5× |
| JSON 파싱 1GB | 1.0× | 1.0× | **1.2×** | 1.8× |
| 행렬 곱셈 (numpy) | 1.0× | 1.0× | **0.95×** | 1.3× |

주목할 점:
- **순수 Python CPU-bound**: 4코어에서 3.8× 향상. multiprocessing보다도 빠른 이유는 프로세스 생성 오버헤드(~50ms/프로세스)가 없기 때문.
- **NumPy**: GIL 없어도 빠르지 않다. NumPy 자체가 내부적으로 C로 GIL을 릴리즈하고 있어서 이미 병렬화돼 있기 때문.
- **I/O-bound**: 사실상 차이 없음. I/O는 원래 GIL을 릴리즈하면서 진행되므로.

## 주의점: C 확장 호환성

free-threaded 모드의 가장 큰 장벽은 C 확장 호환성이다. CPython의 GIL은 오랫동안 "암묵적인 뮤텍스" 역할을 했다. 많은 C 확장이 GIL을 전제하고 작성됐기 때문에 GIL 없이 실행하면 세그폴트나 데이터 레이스가 발생할 수 있다.

2025년 5월 기준 주요 라이브러리 호환성:

- ✅ **httpx, aiohttp, asyncio**: I/O 라이브러리는 대부분 안전
- ✅ **pydantic v2**: Rust 기반 코어라 비교적 빠르게 호환됨
- ⚠️ **NumPy 2.1**: 기술적으로 free-threaded build를 지원하나, 일부 ops에서 race condition 미해결
- ❌ **Cython 기반 라이브러리 일부**: `cythonize(nogil=True)` 없이 컴파일된 코드는 위험
- ❌ **PyTorch 2.3 이하**: GIL 해제 상태에서 CUDA 컨텍스트 관련 크래시 보고

`sys._is_gil_enabled()` → `False` 상태에서 기존 라이브러리를 쓸 때는 각 라이브러리의 이슈 트래커를 먼저 확인해야 한다.

## 메모리 오버헤드

GIL 제거를 위해 CPython은 모든 객체에 **biased reference counting** 방식을 도입했다. 객체 헤더 크기가 약 2배로 늘어나 메모리 사용량이 평균 10~15% 증가한다. 메모리 민감한 서비스에서는 이 점을 트레이드오프로 고려해야 한다.

## 언제 쓸 것인가

지금 당장 프로덕션에 쓰기엔 이르다. Python 3.14(2025년 10월 예정)에서 "stable" 상태로 전환 예정이고, 주요 라이브러리들이 제대로 지원하려면 2026년 초는 돼야 할 것으로 보인다.

단, 다음 케이스는 지금도 실험적으로 써볼 가치가 있다:
- 순수 Python으로 구현된 CPU-bound 워크로드 (파서, 데이터 변환 파이프라인)
- C 확장 의존 없이 작성된 자체 코드베이스
- 멀티프로세싱 오버헤드가 문제인 단기 작업 병렬화

GIL 제거는 Python의 궤도를 바꾸는 변화다. Go나 Rust 없이도 Python에서 진짜 병렬 CPU 연산이 가능해진다는 뜻이니까. 2026년 하반기쯤엔 이 주제로 실무 마이그레이션을 고민하는 팀이 꽤 생길 것이다.

Python 3.13 Free-Threaded 모드 — GIL 없애면 실제로 얼마나 빨라지나

// COMMENTS

ON THIS PAGE