파이썬에서 GIL 삭제된다⋯“병렬 처리의 혁신적 진전”

많은 논란 끝에 파이썬 운영 위원회(Python Steering Council)가 “C파이썬에서 전역 인터프리터 잠금(Global Interpreter Lock)을 선택 사항으로 두자”는 PEF 703 제안을 승인하는 쪽으로 가닥을 잡았다. 이 제안은 파이썬의 전역 인터프리터 잠금, 즉 GIL을 제거하기 위한 몇 년에 걸친 노력의 결실이다. GIL을 제거하면 멀티 스레딩을 가로막는 큰 장애물이 사라지면서 파이썬은 진정한 멀티코어 언어가 되고 병렬성을 활용하는 워크로드의 성능이 크게 향상된다. 이 제안으로 파이썬의 멀티스레딩 및 동시성에 대한 일급(first-class) 지원이 현실에 한 걸음 더 다가섰다. 
 

 

파이썬의 GIL을 제거하는 이유 

파이썬의 메모리 관리 시스템은 각 객체에 대한 참조 횟수를 유지하는 방식으로 객체 사용을 추적한다. 참조 카운트가 0으로 떨어진 객체는 제거 대상이 된다. 파이썬은 멀티 프로세서 시스템이 흔치 않고 멀티코어 프로세서는 아예 존재하지도 않았던 시절에 만들어진 언어이므로 이 참조 카운트 메커니즘에는 스레드 안전성이 없다. 대신 파이썬은 객체에 대해 한 번에 하나의 스레드만 허용하는 방법으로 스레드 안전성을 확보한다. GIL의 용도가 이것이다. 

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

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

no-GIL 파이썬 에디션을 위한 현재의 제안에서는 여러 기법을 함께 사용해서 참조 카운팅의 스레드 안전성을 확보하면서 싱글 스레드 프로그램의 속도에는 영향을 주지 않거나 영향을 최소화한다. 
 

• 편향 참조 카운팅. 싱글 스레드에 의해서만 액세스되는 객체에 대한 카운트는 멀티 스레드에 의해 액세스되는 객체의 카운트와는 다르게(더 빠르게) 처리된다. 대부분의 객체는 단일 스레드에 의해서만 액세스되므로 싱글 스레드 프로그램에 대한 영향은 최소화된다. 
• 불멸화. None과 같은 객체는 할당을 해제할 필요가 없으므로 이러한 객체의 참조 카운트도 추적할 필요가 없다. 
• 스레드 안전 메모리 할당. C파이썬 객체에 대한 새로운 메모리 할당 시스템에서는 가비지 수집기에서 더 쉽게 객체를 추적하고 스레드에 안전한 방식으로 메모리를 할당할 수 있다. 
• 지연된 참조 카운팅. 모듈의 최상위 함수와 같은 일부 객체에 대한 참조 카운트는 안전한 지연이 가능하다. 이렇게 하면 시간과 리소스가 모두 절약된다. 
• 수정된 가비지 수집기. C파이썬 가비지 수집기는 둘 이상의 객체가 상호 참조를 갖는 순환 객체 참조를 정리한다. no-GIL 빌드에서는 객체 추적을 위한 “세대” 시스템이 제거되는 등 가비지 수집기의 많은 부분이 변경된다. 

 

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년 정도 걸릴 것으로 본다”라고 말했다. 
 

GIL 제거의 가장 큰 과제 

이 계획에서 기술적인 과제도 어렵지만 다른 중대한 과제도 있다. 다가오는 큰 문제는 파이썬 생태계의 나머지 부분을 이러한 변화로 이끌고 GIL 없는 파이썬으로 인해 해결되는 문제보다 새로 생기는 문제가 더 많아지지 않도록 하는 것이다. 우터스는 “no GIL 빌드를 수용하기 위해 필요한 서드파티 코드의 모든 변경은 GIL 빌드에서 동작해야 한다. 즉 이전 파이썬 빌드와의 하위 호환성도 여전히 해결해야 한다"라고 말했다.

우터스에 따르면, 또 다른 큰 과제는 위에서 언급한 바와 같이 나머지 파이썬 커뮤니티를 이끌고 우리가 원하는 변화와 그들이 원하는 변화가 모두 만족스러운 변화가 되도록 하는 것이다. 그는 “전체를 no-GIL 빌드로 공식 전환하기 전에 커뮤니티의 지원을 확인해야 한다. 우리 마음대로 기본값을 바꾸고 커뮤니티가 알아서 방법을 찾아 지원해주기를 기대할 수는 없다”라고 말했다. 

파이썬 커뮤니티는 파이썬 2에서 파이썬 3으로 넘어올 때 큰 성장통을 경험한 적이 있으므로 GIL 제거와 같은 중대한 변화는 철저한 하위 호환성을 갖춰야 한다. 우터스는 “파이썬 3 때와 같은 상황이 또 다시 발생해서는 안 된다”라고 말했다. 위험과 과제를 극복한 뒤에는 큰 보상이 따른다. 파이썬이 21세기 프로그래머가 기대하는 병렬 처리를 마침내 지원하는 큰 첫발을 내디뎠다.
editor@itworld.co.kr