파이썬에서 Gil 삭제⋯병렬 처리의 혁신적 진전

많은 논란 끝에 파이썬 운영 위원회(Python Steering Council)가 “C파이썬에서 전역 인터프리터 잠금(Global Interpreter Lock)을 선택 사항으로 두자”는 PEP 703 제안을 승인하는 쪽으로 가닥을 잡았다. 이 제안은 파이썬의 전역 인터프리터 잠금, 즉 GIL을 제거하기 위한 몇 년에 걸친 노력의 결실이다. GIL은 파이썬에서 멀티 스레딩이 불가능하게 만드는 기능으로, 이를 제거하면 멀티스레딩을 사용할 수 있게 되어 파이썬이 진정한 멀티코어 언어가 되고 병렬성을 활용하는 워크로드의 성능이 크게 향상된다. 이 제안을 통해 파이썬의 멀티스레딩 및 동시성에 대한 지원이 한층 더 발전하게 되었다. PEP 703은 파이썬 커뮤니티에 의해 환영받는 중요한 변화로 평가받고 있다. 파이썬의 GIL을 제거하는 이유

파이썬은 멀티 프로세서 시스템이 흔치 않고 멀티코어 프로세서는 아예 존재하지도 않았던 시절에 만들어진 언어이므로 이 참조 카운트 메커니즘에는 스레드 안전성이 없다. 대신 파이썬은 객체에 대해 한 번에 하나의 스레드만 허용하는 방법으로 스레드 안전성을 확보한다. 파이썬의 GIL(Global Interpreter Lock)은 이러한 스레드 안전성을 유지하기 위해 도입된 기능이다.

몇 년 동안 많은 프로젝트에서 GIL을 제거하려고 시도했고 실제로 멀티스레드 프로그램의 속도를 높이는 결과를 얻었지만 그 대신 싱글 스레드 프로그램의 성능이 저하됐다. 파이썬 애플리케이션의 대다수가 싱글 스레드임을 감안하면 손해가 큰 타협인 셈이다. 또한 GIL이 개선되면서 멀티스레드 앱 처리가 개선됐다고 하지만 여전히 심각한 병목 지점이다. 파이썬 핵심 개발자들은 마침내 싱글 스레드 프로그램의 속도를 저하시키지 않으면서 제거할 수 있어야 한다는 전제 조건을 두고 마침내 C파이썬에서 GIL을 제거하기로 했다. GIL이 제거되면 파이썬은 싱글 스레드와 멀티스레드 앱 모두에서 더 나은 프로세싱 성능을 보여줄 것으로 기대되고 있다.

GIL이 없는 파이썬은 어떻게 동작하는가

GIL이 없는 파이썬은 어떻게 동작하는가?

GIL 파이썬 에디션은 여러 기법을 사용하여 참조 카운팅의 스레드 안전성을 확보하고 싱글 스레드 프로그램의 속도에는 영향을 주지 않거나 최소화하는 제안이다.

편향 참조 카운팅: 싱글 스레드가 액세스하는 객체의 카운트는 멀티 스레드가 액세스하는 객체의 카운트와 다르게(더 빠르게) 처리된다. 대부분의 객체는 싱글 스레드에 의해서만 액세스되므로 싱글 스레드 프로그램에는 영향이 최소화된다.

불멸화: None과 같은 객체는 할당을 해제할 필요가 없으므로 이러한 객체의 참조 카운트도 추적할 필요가 없다.

스레드 안전 메모리 할당: C파이썬 객체에 대한 새로운 메모리 할당 시스템에서는 가비지 수집기에서 더 쉽게 객체를 추적하고 스레드에 안전한 방식으로 메모리를 할당할 수 있다.

지연된 참조 카운팅: 일부 객체(예: 모듈의 최상위 함수)에 대한 참조 카운트는 안전하게 지연될 수 있다. 이로 인해 시간과 리소스 모두 절약된다.

수정된 가비지 수집기: C파이썬 가비지 수집기는 순환 객체 참조에서 둘 이상의 객체가 상호 참조하는 경우 정리한다. no-GIL 빌드에서는 “세대” 시스템을 포함한 많은 가비지 수집기 부분이 변경된다.

남는 CPU로 손해보지 않는 방법

GIL 없는 파이썬의 도입 과정

PEP 703 구현은 몇 년에 걸쳐 여러 단계로 실행되는 장기 프로젝트다. 이 기간 동안 C파이썬 인터프리터에서는 일단 no-GIL 버전이 선택 사항이 되고, 이후 지원 대상이 된 다음 마지막으로 C파이썬의 표준 버전이 되는 과정을 거친다. 이를 위해 C파이썬 개발자들은 C파이썬에 실험적인 “no-GIL” 빌드 모드를 추가해 GIL 적용 여부를 선택해 C파이썬 버전을 컴파일할 수 있도록 한다. 최종적으로는 no-GIL 빌드가 기본값이 된다.

C파이썬에서 GIL을 제거하기 위한 계획은 다음과 같이 진행된다.

1단계: no-GIL C파이썬 선택 가능

no-GIL C파이썬의 첫 번째 버전은 C파이썬 개발자와 파이썬 커뮤니티 양쪽 모두에 실험적 성격이다. 이 실험 단계에는 다음과 같은 여러 목표가 있다.

나머지 파이썬 커뮤니티의 참여 유도

파이썬의 모든 주요 변경에는 파이썬 커뮤니티의 참여가 필요하다. 실험 빌드는 파이썬 사용자에게 코드를 안전하게 실험하고 비스레드 및 스레드 코드가 어떻게 동작하는지 살펴볼 수 있는 수단을 제공한다.

파이썬 배포판에 GIL 없는 파이썬 배포를 요구사항이 아닌 옵션으로 제공

콘다(Conda), 윈파이썬(WinPython)과 같은 파이썬 배포판은 기본 C파이썬과의 호환성을 보장해야 한다. 전환 단계에서 이러한 배포판은 일반 버전 또는 GIL 없는 C파이썬 버전을 설치할 수 있는 선택 옵션을 제공한다. 따라서 콘다 또는 윈파이썬 사용자는 각자의 필요에 가장 잘 맞는 버전을 선택할 수 있다.

no-GIL 프로젝트에 가치가 있는지 판단

커뮤니티가 GIL 없는 빌드를 대규모로 실험하면서 그 결과에 만족하지 못한다면 핵심 C파이썬 개발자들은 프로젝트를 철회할 권리를 보유한다. 이중 빌드는 단기적으로 유지보수 부담을 가중시키지만 no-GIL 프로젝트가 무가치한 것으로 입증될 경우 탈출구를 제공한다.

2단계: no-GIL C파이썬 지원

다음 단계는 no-GIL 빌드를 C파이썬의 지원되는 대안 빌드로 제공하는 것이다. 사용자는 no-GIL 또는 GIL 빌드를 선택해서 설치할 수 있으며 둘 모두 C파이썬에서 공식적으로 지원되는 빌드로 버그 수정과 보안 패치, 업데이트 등을 받는다. 이 단계의 중요한 목표는 no-GIL 빌드를 표준으로 정할 날짜를 정하는 것이다. 다른 파이썬 기능의 지원 중단 및 제거와 같은 타임라인상에 정해질 가능성이 높다. 즉, 최소 2~3개 버전에 걸쳐 이뤄지며 이는 2~3년을 의미한다.

3단계: no-GIL C파이썬이 기본값

마지막 단계는 no-GIL C파이썬 버전을 기본 빌드로 만들고 C파이썬에서 모든 GIL 관련 코드를 제거하는 것이다. C파이썬 핵심 개발자인 토마스 우터스는 “너무 오래 끄는 것은 바람직하지 않다. 빌드 모드가 2개라는 것은 커뮤니티에 큰 부담이기 때문이다. 실제로 테스트 리소스와 디버깅 시나리오가 2배로 증가한다. 그러나 서두를 수도 없다. 이 단계에 이르기까지 길면 5년 정도 걸릴 것으로 본다”라고 말했다. 토마스 우터스는 C파이썬의 핵심 개발자다.

[Python] 병렬처리(Multiprocessing)로 업무 효율을 높이자! (1편)

GIL 없는 파이썬의 도입 과정

GIL 제거의 가장 큰 과제는 파이썬 생태계의 나머지 부분을 GIL 없는 파이썬으로 이끌어 나가는 동안 새로운 문제가 더 늘어나지 않도록 하는 것이다. 또한, 기존 파이썬 빌드와의 하위 호환성도 유지해야 한다. 또한, 파이썬 커뮤니티의 지원을 확인하여 우리가 원하는 변화와 그들이 원하는 변화가 모두 만족스러운 결과가 되도록 해야 한다. 파이썬 커뮤니티는 파이썬 2에서 3으로의 전환 과정에서 큰 성장통을 겪었기 때문에 GIL 제거와 같은 중대한 변화는 하위 호환성이 보장되어야 한다. 위험과 과제를 극복한 뒤에는 파이썬이 21세기 프로그래머가 기대하는 병렬 처리를 지원하는 첫발을 내딛게 될 것이다.

Global Interpreter Lock GIL 자세히 톺아보기, 한성민 – PyCon Korea 2022