Python 3.15와 GIL, 무엇이 실제로 바뀌나

파이썬의 GIL 이야기는 몇 년째 돌고 있어서 "이번엔 진짜 없어지나" 하고 넘기게 된다. 2026년 10월 1일에 나오는 Python 3.15는 그 흐름에서 조용하지만 결정적인 한 걸음을 뗀다. free-threaded 빌드의 ABI가 안정화된다. 이 글은 그게 왜 3.13이나 3.14보다 중요한 변화인지, 그리고 지금 당장 무엇이 달라지고 무엇은 아직 아닌지를 정리한다.

GIL은 없어지는 게 아니라 끌 수 있게 되는 중이다

먼저 사실관계를 정확히 해야 한다. 자주 보이는 "파이썬에서 GIL이 사라졌다"는 표현은 틀렸다.

현재 구조는 이렇다. 기본 파이썬은 여전히 GIL을 켜고 돈다. 그와 별도로 free-threaded 빌드가 따로 제공되고, 그걸 받아서 쓰면 GIL 없이 돈다. 즉 GIL은 제거된 게 아니라 선택 사항이 됐다.

기본값을 free-threaded로 바꾸는 단계는 아직 계획 단계도 아니다. 관련 PEP도 일정도 없고, 현실적인 추정은 2028~2029년이라는 이야기가 나온다. 그러니 "내년쯤 내 코드가 알아서 병렬로 돌겠지"라고 기대하면 안 된다.

성능 이야기도 솔직하게 볼 필요가 있다. free-threaded 빌드는 GIL을 켠 같은 버전 대비 리눅스 x86_64에서 약 9%, macOS ARM64에서 약 6%의 오버헤드가 있다. 단일 스레드 작업만 하는 코드라면 free-threaded 빌드로 바꾸는 것이 손해다.

ABI 안정화가 실제 분기점인 이유

그럼 3.15가 왜 중요한가. C 확장 모듈을 free-threaded 빌드용으로 안정적으로 빌드할 수 있게 되기 때문이다.

파이썬의 실질적 가치는 생태계에 있다. NumPy, Pillow, lxml, cryptography, pandas 같은 라이브러리가 없으면 파이썬을 쓸 이유가 크게 준다. 그런데 이들은 대부분 C 확장이고, C 확장은 파이썬의 ABI에 맞춰 컴파일된다. ABI가 불안정하면 라이브러리 관리자 입장에서 free-threaded용 빌드를 배포할 수가 없다. 파이썬 패치 버전마다 다시 빌드해야 하는 상황을 감당할 수 없기 때문이다.

3.15에서 ABI가 안정화되면 이 장벽이 걷힌다. 주요 라이브러리가 free-threaded 휠을 PyPI에 올리기 시작하고, 그때부터 "GIL 없는 파이썬을 실제로 써볼 수 있는" 상태가 된다.

기술 발표에서 눈에 띄는 기능보다 이런 배관 작업이 판을 바꾸는 경우가 많다. 3.13의 실험적 지원과 3.14의 개선이 언론의 주목을 더 받았지만, 생태계가 움직이는 계기는 3.15의 ABI 안정화다.

단계별로 정리하면 현재 위치가 분명해진다.

점선으로 그린 마지막 단계에 유의해야 한다. 여기에는 PEP도 일정도 없다.

오버헤드 수치도 그래프로 보면 판단이 쉽다.

즉 free-threaded로 바꾸면 스레드를 안 쓰는 코드는 느려진다. 병렬로 얻는 이득이 이 손해를 넘어야 전환할 이유가 생긴다.

지금 시점에서 개발자가 할 일

당장 해야 할 일은 많지 않다. 그래도 두 가지는 해둘 만하다.

의존성이 free-threaded를 지원하는지 확인해 두는 것. 앞으로 몇 달 동안 주요 라이브러리들이 순차적으로 지원을 발표할 것이다. 내가 쓰는 스택이 언제 준비되는지 알고 있으면, 실제로 써볼 시점을 놓치지 않는다.

멀티프로세싱으로 우회하던 코드를 목록화하는 것. GIL 때문에 multiprocessing을 쓰고 프로세스 간 데이터 직렬화 비용을 감수하던 부분이 있을 것이다. free-threaded가 실용화되면 그 코드들이 스레드로 단순화될 수 있다. 미리 어디인지 알고 있으면 전환 판단이 빠르다.

반대로 지금 free-threaded 빌드로 프로덕션을 옮기는 것은 권하지 않는다. ABI가 안정화됐다는 것은 라이브러리가 빌드할 수 있게 됐다는 뜻이지, 그 라이브러리들이 스레드 안전하다는 보장은 아니다. GIL은 여러 라이브러리의 암묵적인 안전망 역할을 해왔다. 그게 사라지면 지금까지 드러나지 않던 경쟁 조건이 나온다. 실전 검증에는 시간이 필요하다.

스레드로 바꿔서 이득이 나는 코드의 모양

free-threaded가 실용화됐을 때 무엇이 달라지는지 구체적으로 보자. 지금 이런 코드를 쓰고 있다면 후보다.

# 지금: 프로세스를 띄우고 데이터를 직렬화해서 주고받는다
from multiprocessing import Pool

def score(record):
    return heavy_cpu_work(record)

with Pool(8) as pool:
    results = pool.map(score, records)   # records 를 피클로 복사

여기서 비용은 두 가지다. 프로세스를 띄우는 비용과, records를 피클로 직렬화해 자식으로 보내고 결과를 다시 받아오는 비용이다. 데이터가 크면 이 복사가 계산보다 오래 걸리는 일도 생긴다.

free-threaded 환경에서는 이렇게 바뀐다.

from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor(8) as ex:
    results = list(ex.map(score, records))   # 메모리 공유, 복사 없음

같은 메모리를 본다. 복사가 없다. 대신 공유 상태에 대한 책임이 생긴다. GIL이 우연히 보장해 주던 원자성이 사라지므로, 여러 스레드가 건드리는 자료구조에는 락이 필요하다. 지금까지 "파이썬은 GIL이 있으니 괜찮겠지" 하고 넘어간 코드가 있다면 그게 그대로 버그가 된다.

이 전환이 공짜가 아니라는 점이 중요하다. 멀티프로세싱은 느리지만 안전했고, 스레드는 빠르지만 조심해야 한다.

GIL 이야기에 가려진 다른 변화들

3.15를 GIL로만 보면 놓치는 것이 있다. 파이썬 릴리스는 매년 10월에 나오고, 매번 실용적인 개선이 쌓인다. 오류 메시지 개선, 타입 힌트 문법 정리, 표준 라이브러리 정리 같은 것들이다.

특히 최근 몇 년간 파이썬 생태계에서 체감이 큰 변화는 언어 자체보다 도구 쪽에서 나왔다. uv 같은 패키지 관리 도구가 설치 속도를 자릿수 단위로 줄였고, 이게 CI 시간과 개발 환경 구성 시간을 실제로 바꿨다. 언어 버전을 올리는 것보다 도구를 바꾸는 편이 체감 효과가 큰 경우가 많다.

그래서 GIL 논쟁은 어떻게 끝날까

내 판단은 이렇다. GIL은 앞으로도 한동안 기본값으로 남고, free-threaded는 필요한 곳에서만 쓰이는 선택지로 자리 잡는다.

이유는 두 가지다. 첫째, 오버헤드가 있다. 단일 스레드 성능이 6~9% 떨어지는 것을 모든 사용자가 감수할 이유가 없다. 파이썬 사용자의 상당수는 스크립트와 데이터 처리를 하고, 이들에게 GIL은 문제가 아니다.

둘째, 진짜 CPU 병렬이 필요한 영역은 이미 다른 해법을 갖고 있다. NumPy 같은 라이브러리는 내부에서 GIL을 풀고 C 레벨에서 병렬 처리를 한다. 무거운 연산은 애초에 파이썬 루프에서 돌지 않는다.

그렇다고 free-threaded가 무의미하다는 말은 아니다. 웹 서버처럼 I/O와 CPU가 섞이고 스레드를 많이 쓰는 워크로드, 그리고 메모리를 공유해야 해서 멀티프로세싱이 비효율적인 경우에는 분명한 이득이 있다. 요점은 모두를 위한 변화가 아니라 특정 워크로드를 위한 선택지라는 것이다. 그 눈으로 보면 3.15의 ABI 안정화가 왜 조용하면서도 중요한지가 분명해진다.

참고 자료

• Python support for free threading — Python 공식 문서 — free-threaded 빌드의 현재 지위와 사용 방법
• Python 3.15: What's Actually True Right Now — 릴리스 일정, ABI 안정화의 의미, 과장된 보도와 사실의 구분
• Free-Threaded Python: What Backend Devs Need to Know — 오버헤드 수치와 백엔드 관점의 판단 기준