파이썬 GIL 제거, 2025년 현재 어디까지 왔나?

Python의 오랜 난제였던 GIL(Global Interpreter Lock) 제거가 최근 Python 커뮤니티의 뜨거운 화두입니다. 멀티코어 시대에 CPython 인터프리터가 CPU 자원을 온전히 활용하지 못하도록 막아온 GIL이 마침내 단계적으로 해제되는 방향으로 변화하고 있습니다. 이번 글에서는 2025년 현재 Python의 GIL 제거 노력의 현황과 앞으로의 계획을 정리합니다.

목차

• GIL이란 무엇인가
• 왜 GIL을 제거하려 하는가
• PEP 703: GIL 제거 제안의 승인
• Python 3.13의 Free-Threading (GIL Optional)
• 성능 영향 및 메모리 오버헤드
• 라이브러리 호환성과 커뮤니티 대응
• 앞으로의 로드맵
• 맺음말

GIL이란 무엇인가?

GIL은 C 언어로 구현된 CPython 인터프리터가 한 번에 하나의 스레드만 Python 바이트코드를 실행하도록 보장하는 전역 락입니다. 즉 멀티코어 CPU를 장착한 시스템에서도 동시에 두 개 이상의 Python 스레드가 동작하지 못하도록 제한하지요. 이 때문에 파일 I/O 같은 I/O 바운드 작업에서는 스레드가 유용하지만, CPU를 많이 사용하는 CPU 바운드 연산에서는 스레드를 여러 개 돌려도 한 코어만 사용하는 결과가 되어버립니다. GIL은 원래 메모리 관리의 간소화 등 CPython 구현상의 이점을 위해 도입되었지만, 오랫동안 병렬 실행의 걸림돌로 지적되어 왔습니다.

왜 GIL을 제거하려 하는가?

멀티코어를 충분히 활용하지 못하는 문제는 과거부터 다양한 우회책으로 대응해왔습니다. 예를 들어 multiprocessing 모듈을 사용해 프로세스를 여러 개 띄우거나, Cython이나 C 확장 모듈에서 시간이 오래 걸리는 연산 중 GIL을 수동으로 해제하는 방식 등이 대표적입니다. 그러나 이러한 방법들은 프로세스간 통신 부하나 개발 복잡도 증가 등 부작용이 따랐습니다.

특히 과학 연산 및 머신러닝 분야에서 GIL로 인한 제약이 두드러졌습니다. 예를 들어 강화학습 등에서는 수십 개의 시뮬레이션 환경을 병렬로 실행해야 하는데, GIL로 인해 몇 개 스레드 이상 늘리지 못해 병목이 발생하고 맙니다. DeepMind의 사례에서는 스레드를 10개 미만으로만 사용해도 GIL 경합이 걸림돌이 되어, 이를 우회하려 대규모 파이썬 코드를 C++로 다시 작성하기까지 했다고 합니다. 이런 식의 우회는 코드의 접근성을 떨어뜨리고 개발 생산성을 저해하는 요인이 되었습니다. 멀티코어 CPU 성능을 제대로 활용하기 위해서, 그리고 파이썬 코드만으로도 병렬 처리를 쉽게 구현하기 위해 GIL 제거는 피할 수 없는 과제로 대두되었습니다.

PEP 703: GIL 제거 제안의 승인

2023년, 드디어 Python 핵심 개발자들은 GIL을 선택적으로 비활성화할 수 있도록 하는 제안인 **PEP 703**을 승인했습니다. Steering Council(지도 위원회)은 “변경 사항이 가능하면 기존 코드를 깨뜨리지 않도록 점진적으로 도입할 것, 심각한 문제가 생길 경우 언제든지 롤백할 수 있음을 조건으로” PEP 703을 수락하였는데, 이는 GIL 제거가 Python 생태계에 미칠 파장을 신중히 관리하겠다는 의미입니다. 이러한 결정에는 커뮤니티와 기업들의 적극적인 지지 또한 있었습니다. 실제로 **Meta(Facebook 모회사)**는 PEP 703이 받아들여지면 2025년까지 핵심 개발 인력 3인년을 투입해 GIL 제거 작업을 지원하겠다고 약속하기도 했습니다. 그만큼 많은 이들이 GIL 없는 Python의 가치와 필요성에 공감하고 있다는 뜻입니다.

Python 3.13의 Free-Threading (GIL Optional)

PEP 703 승인 이후 첫 단계로, Python 3.13 버전(2024년 10월 출시)에서 GIL 없는 실행 모드, 일명 “free-threaded” 모드가 실험적 기능으로 도입되었습니다. 이는 CPython을 컴파일할 때 --disable-gil 플래그를 주어 빌드하면 GIL을 완전히 제거한 인터프리터를 얻을 수 있는 기능입니다. 다만 이 기능은 아직 기본 설정으로 활성화된 것은 아닙니다. Python 3.13 공식 배포판이나 표준 설치본에는 GIL 제거 모드가 포함되어 있지 않고, 직접 소스에서 특수 옵션으로 빌드해야만 합니다. 실제로 Python 핵심 개발팀도 안정성을 위해 당분간 GIL 활성 버전과 비활성 버전의 두 가지 인터프리터를 병행 유지할 계획입니다. (GIL 비활성 버전은 내부 구현 변경으로 ABI가 달라지기 때문에, 일반 CPython과 호환되지 않는 별도 인터프리터로 취급됩니다.) 참고: What’s New In Python 3.13

활용 예시: 리눅스 배포판 중 하나인 openSUSE Tumbleweed에서는 Python 3.13의 GIL 없는 버전을 **python3.13t**라는 별도 패키지로 제공합니다. python3.13t 인터프리터는 GIL이 제거되어 있으므로 threading.Thread를 이용한 여러 스레드의 Python 코드가 실제로 병렬 실행되며, 싱글 스레드 인터프리터 대비 CPU를 더욱 효율적으로 활용할 수 있습니다. 아래는 python3.13t로 실행한 REPL에서 GIL 상태를 확인한 예시입니다. sys._is_gil_enabled() 함수를 호출하였을 때 **False**가 반환되면 GIL이 비활성화된 빌드임을 의미합니다. 참고: Python 문서 sys._is_gil_enabled

성능 영향 및 메모리 오버헤드

GIL을 제거하면 하나의 스레드만 돌 때는 약간의 성능 손실이 발생합니다. 동기화 기법 추가로 인한 오버헤드 때문인데요. 초기 실험 단계에서는 싱글스레드 성능이 약 40%까지 저하되기도 했지만, Python 3.13 출시 시점까지 핵심 개발자들의 최적화 작업을 통해 현재는 대부분의 플랫폼에서 10% 미만의 성능 차이로 좁혀졌습니다. 예컨대 macOS에서는 차이가 거의 없을 정도이고, Ubuntu 리눅스나 Windows 환경에서도 7~8% 정도 느린 수준으로까지 개선되었습니다. 물론 멀티스레드로 CPU를 활용하는 상황에서는 전체 성능이 크게 향상되므로, 이 정도 단일 스레드 손해는 수용할 만한 트레이드오프로 보입니다.

다만 메모리 사용량 증가는 약 20% 정도로 다소 크게 보고되었습니다. 참고로 CPython의 GIL 제거 구현은 메모리 할당자(mimalloc) 도입, 레퍼런스 카운팅 방식 변경 등 다양한 내부 변경을 포함하는데, 이러한 요인들로 메모리 오버헤드가 증가한 것으로 파악됩니다. 개발팀은 메모리 효율 개선 작업도 막 시작한 단계이며, 실제 현업 워크로드에서는 이 정도 증가분은 크게 문제되지 않을 수 있다는 입장입니다. 향후 최적화를 통해 메모리 오버헤드도 줄일 여지가 있으며, 궁극적으로 멀티코어 활용에 따른 성능 향상이 메모리 증가를 상쇄할 것이라는 기대가 있습니다.

라이브러리 호환성과 커뮤니티 대응

GIL 제거로 가장 큰 영향을 받는 부분은 C로 구현된 각종 확장 모듈과 파이썬 C API입니다. 앞서 언급했듯 GIL 없는 CPython은 새로운 ABI(tag에 t가 붙은)를 사용하기 때문에, C로 작성된 Python 확장 라이브러리는 **별도의 빌드(rebuild)**가 필요합니다. 한마디로 기존 바이너리 확장 모듈(wheel)은 GIL 없는 인터프리터에서 그대로 동작하지 않습니다. 이 때문에 Python 3.13 단계에서는 당분간 동일 패키지에 대해 GIL용 빌드와 no-GIL용 빌드를 따로 제공해야 하는 상황입니다. 예를 들어 NumPy나 Pandas 같은 라이브러리는 cp313 대신 cp313t와 같이 이름에 t가 포함된 추가 휠 파일을 배포하는 방식입니다.

다행히도 커뮤니티 주요 프로젝트들은 발 빠르게 대응하고 있습니다. 현재 상위 360개 인기 패키지 중 약 1/6 가량(약 16%)이 GIL 없는 빌드 지원을 완료했으며, 여기에 NumPy, Pandas, SciPy 등 과학 컴퓨팅 필수 라이브러리들이 포함되어 있습니다. Quansight Labs에서는 free-threading 전환 가이드와 호환 현황 페이지를 마련하고 별도 Discord 채널과 포럼(Discourse)에서 정보를 공유하는 등, 패키지 생태계 전반의 전이를 돕고 있습니다. 또한 PyCon US 2025에서는 핵심 개발자들이 모여 주요 패키지들의 free-threading 지원 현황과 어려움을 논의하기도 했습니다. 참고: Quansight Labs의 업데이트 글 링크는 아래 참고자료를 참조하세요.

앞으로의 로드맵

GIL 제거의 도입은 한두 버전 내에 완료될 일이 아니며, 몇 년에 걸친 단계적 계획으로 진행됩니다. PEP 703에서도 몇 단계에 걸쳐 GIL을 점진적으로 없애는 청사진을 제시하고 있는데요. 요약하면 다음과 같습니다.

1. Python 3.13 (2024년) – GIL 비활성 빌드를 실험적 옵션으로 제공 (현재 단계).
2. 향후 23개 릴리스 (20262027년경) – 기본 CPython 배포판에 GIL 옵션을 런타임 선택으로 통합. (-X no_gil 또는 환경변수 등으로 GIL 끄고 켤 수 있도록) 단, 기본값은 기존처럼 GIL 활성화 상태로 유지하여 호환 기간을 갖춤.
3. 그 이후 23개 릴리스 (20282030년경) – GIL 비활성화가 기본값이 되며, 필요시 옵션으로 GIL을 켤 수 있는 최종 단계.

위 로드맵은 이상적인 시나리오이며, 실제로 이 단계에 도달하기까지 해결해야 할 과제가 많습니다. Python 개발진 역시 *“아직 공식 배포판에서 GIL을 완전히 제거할 시점이 정해진 것은 아니며, 만약 free-threading 도입으로 인해 Python 성능이 크게 나빠지거나 문제를 일으킨다면 언제든 계획을 철회할 수 있다”*는 신중한 입장입니다. 즉, 단일 스레드 성능 저하를 최소화하고 생태계 호환성 문제를 해결하는 것이 계속된 과제로 남아 있고, 이러한 부분이 만족스럽게 풀릴 때까지는 GIL을 기본으로 유지하는 보호장치도 갖춰두고 있는 것입니다. 앞서 언급했듯 Steering Council이 PEP 703을 **“조건부 승인”**한 것도 같은 맥락입니다.

그럼에도 불구하고 현재까지의 진행 상황을 보면 낙관적인 전망이 힘을 얻고 있습니다. GIL 없는 Python 구현은 아키텍처적으로 건전함이 입증되었고, 싱글 스레드 성능 손실도 예상보다 많이 개선되었습니다. 핵심 개발자 풀도 점차 늘어나고 있어, 이 복잡한 변화를 지속해서 감당할 수 있을 것으로 보입니다. 커뮤니티의 협력 아래 서드파티 라이브러리들의 지원도 빠르게 확산되고 있습니다.

맺음말

**“GIL 없는 파이썬”**은 오랜 Python 개발자들의 꿈이었고, 이제 그 꿈이 서서히 현실에 가까워지고 있습니다. 아직은 실험적인 초기 단계이므로 일반 사용자들에게 미치는 영향은 크지 않지만, 머지않아 멀티코어를 더욱 효율적으로 활용하는 Python을 만나게 될 것입니다. GIL 제거 작업은 Python 언어에 있어 수년 간의 대공사가 될 전망이지만, 그만큼 Python 생태계 전반에 긍정적인 성능 향상과 새로운 가능성을 열어줄 변화입니다. 개발자 여러분도 앞으로 나올 새 Python 버전들의 동향을 주시하면서, 필요한 경우 코드나 사용 라이브러리를 업데이트하는 등 천천히 대비를 시작해보시면 좋겠습니다. 멀티코어 시대를 맞아 진화해가는 Python의 행보를 함께 지켜보죠. 🔥

참고자료

• PEP 703: Making the GIL Optional – https://peps.python.org/pep-0703/
• What’s New In Python 3.13 – https://docs.python.org/3.13/whatsnew/3.13.html
• Python sys._is_gil_enabled 문서 – https://docs.python.org/3.13/library/sys.html#sys._is_gil_enabled