GIL이 켜진 CPython에서 파일을 기다리는 작업은 스레드를 늘려 빨라졌지만 순수 Python 계산은 그렇지 않습니다. 이유는 무엇이며 CPU 작업은 어떻게 병렬화하나요?

GIL(Global Interpreter Lock)은 일반적인 CPython 빌드에서 한 시점에 하나의 스레드가 Python 바이트코드를 실행하도록 하는 인터프리터 잠금입니다. 따라서 순수 Python으로 계산하는 CPU-bound 작업은 스레드 수를 늘려도 여러 코어에서 동시에 바이트코드를 실행하지 못해 병렬 처리 이득이 제한됩니다. 스레드 전환 비용과 공유 상태 동기화 비용 때문에 오히려 느려질 수도 있습니다.

GIL이 걸리는 실행 층

반면 I/O-bound 작업은 네트워크나 파일 응답을 기다리는 시간이 큽니다. CPython 스레드는 이런 대기 중 실행 기회를 양보하므로 여러 작업을 겹칠 수 있습니다. 또한 일부 C 확장 모듈은 긴 계산이나 I/O 동안 GIL을 해제하므로, 실제 병렬성이 가능한지는 “Python 코드인가”만이 아니라 사용한 확장 모듈의 계약까지 확인해야 합니다. asyncio 역시 GIL을 없애는 수단이 아니라 한 스레드에서 대기 중인 작업을 효율적으로 겹치는 방식입니다.

프로세스와 확장 모듈

CPU 병렬성이 필요하면 프로세스 풀이나 별도 작업 서비스로 분리하고, 그때는 직렬화·메모리 복사·프로세스 시작 비용을 포함해 판단하겠습니다. 최신 CPython에는 GIL을 비활성화할 수 있는 free-threaded 빌드가 있지만 모든 배포 환경의 기본값이 아니며, 확장 모듈 호환성과 단일 스레드 성능·메모리 비용을 별도로 검증해야 합니다. 그러므로 “Python은 멀티스레드 병렬성이 없다”가 아니라 활성 GIL 여부, 코드가 실행되는 층, 병목이 계산인지 대기인지를 측정해 선택해야 합니다.

선택 기준과 검증

프로세스 수를 코어 수만큼 늘려도 작업이 작으면 직렬화·프로세스 간 복사·스케줄링 비용이 계산보다 커집니다. CPU 시간과 전송 시간을 분리해 배치 크기를 정하고, C 확장이 내부 스레드를 만드는 경우 과구독도 확인하겠습니다. 활성 GIL CPython과 free-threaded 빌드는 같은 결과로 취급하지 않고 별도 배포 범위로 검증하겠습니다.

GIL은 인터프리터 내부 접근을 보호하지만 여러 문장으로 구성한 애플리케이션 불변식을 원자적으로 만들지는 않습니다. 재고를 읽고 검사한 뒤 쓰는 사이 다른 스레드가 실행되거나 호출한 확장이 GIL을 놓을 수 있으므로 필요한 락·조건부 갱신은 별도로 사용해야 합니다. 특정 CPython 버전에서 우연히 안전해 보인 바이트코드 배치를 언어 보장으로 삼지 않겠습니다.

프로세스 풀은 별도 주소 공간을 가져 결과가 자동 공유되지 않습니다. 변경 가능한 큰 객체를 보내면 직렬화·복사가 늘고, 공유 메모리를 쓰면 다시 동기화·수명 관리가 필요합니다. 작업 분할도 한쪽만 오래 걸리는 불균형을 피해야 합니다. free-threaded 빌드에서는 기존 C 확장이 GIL 활성화를 요구할 수도 있으므로 빌드 이름뿐 아니라 실제 실행 시 GIL 상태와 확장 지원을 확인하고, 안전성 시험과 처리량 시험을 분리하겠습니다.