Python 자유 스레딩과 지연 임포트로 설계하는 멀티코어 처리

GIL이 만든 CPU 바운드 병목

CPython의 GIL(Global Interpreter Lock)은 한 순간에 하나의 네이티브 스레드만 Python 바이트코드를 실행하도록 제한하는 뮤텍스다. 1990년대 초 레퍼런스 카운팅 기반 메모리 관리를 단순하게 스레드 안전하게 만들기 위해 도입됐다.

ob_refcnt를 여러 스레드가 원자적 증감 없이 함께 변경하면 메모리 해제 오류가 발생할 수 있다. GIL은 이 문제를 단순한 전역 잠금으로 다뤘다. I/O 대기나 C 확장 실행 중에는 잠금이 해제되므로 I/O 바운드 작업에는 일정 수준의 병렬성이 있지만, CPU 집약적인 계산은 결국 단일 코어에서 직렬화된다.

그래서 기존에는 multiprocessing으로 프로세스를 분리하거나 concurrent.futures.ProcessPoolExecutor를 사용하는 방법이 널리 쓰였다. 이 방식은 GIL을 피해 갈 수 있지만 프로세스 사이의 데이터 직렬화 비용을 감수해야 한다.

⤢✕

PEP 703이 바꾸는 CPython의 실행 모델

PEP 703은 Sam Gross가 제안한, CPython에서 GIL을 선택 사항으로 만드는 로드맵이다. 자유 스레딩 빌드는 Python 3.13에서 실험적으로 지원됐고 Python 3.14에서 공식 지원(supported) 단계에 진입했다.

Phase I — Python 3.13 (2024): --disable-gil 플래그를 통한 자유 스레딩 빌드와 python3.13t 바이너리를 실험적으로 제공했다. 단일 스레드 성능 저하는 약 40%였다.
Phase II — Python 3.14 (2025년 10월): PEP 779 수용으로 공식 지원 상태가 됐고, 특화 인터프리터(specializing interpreter)가 다시 활성화됐다. 단일 스레드 오버헤드는 5~10%로 감소했다.
Phase III — 미정 (2028~2029 예상): 자유 스레딩 빌드를 기본값으로 바꾸고 GIL 빌드는 레거시 옵션으로 유지하는 단계다.

객체 구조도 달라진다. 기존 PyObject는 16 bytes 구조였지만, 자유 스레딩에서는 소유 스레드와 공유 레퍼런스 카운트, 경량 뮤텍스, GC 상태를 담아 약 32 bytes가 된다.

// GIL 있는 기존 구조 (16 bytes)
typedef struct {
    Py_ssize_t ob_refcnt;   // 레퍼런스 카운트
    PyTypeObject *ob_type;  // 타입 포인터
} PyObject;

// 자유 스레딩 구조 (~32 bytes)
typedef struct {
    uintptr_t ob_tid;          // 소유 스레드 ID (biased reference counting)
    uint8_t  ob_mutex;         // 경량 뮤텍스
    uint8_t  ob_gc_bits;       // GC 상태 비트
    uint32_t ob_ref_local;     // 로컬 레퍼런스 카운트
    Py_ssize_t ob_ref_shared;  // 공유 레퍼런스 카운트
    PyTypeObject *ob_type;
} PyObject;

Biased Reference Counting은 객체를 만든 스레드가 원자적 연산 없이 카운트를 갱신할 수 있도록 한다. 다른 스레드와 객체를 공유할 때만 원자적 CAS 연산을 적용하는 경량 잠금 구조가 단일 스레드 오버헤드를 낮추는 핵심이다.

객체 안전성을 유지하는 방식

자유 스레딩 빌드는 GIL 대신 여러 층의 동기화 장치를 사용한다.

Mimalloc은 스레드별 로컬 힙으로 메모리 할당 경쟁을 줄인다.
리스트와 딕셔너리 같은 변경 가능 객체에는 객체별 경량 뮤텍스가 들어간다.
객체가 다른 스레드에서 접근되면 레퍼런스 카운트는 ob_ref_shared를 통해 원자적으로 처리된다.
순환 참조 감지 알고리즘은 멀티스레드 환경에서도 정확성을 보장하도록 동작한다.
sys.flags.gil_enabled로 실행 중인 인터프리터의 GIL 활성화 여부를 확인할 수 있다.

자유 스레딩 빌드는 다음처럼 실행하고 점검할 수 있다.

# Python 3.14t 빌드 설치 (UV 사용)
uv python install 3.14t

# GIL 비활성화 확인
python3.14t -c "import sys; print(sys.flags.gil_enabled)"  # → 0

# 환경 변수로 GIL 강제 활성화 (호환성 테스트용)
PYTHON_GIL=1 python3.14t script.py

멀티코어 성능과 단일 스레드 비용

Python 3.14 자유 스레딩의 벤치마크는 CPU 바운드 멀티스레드 작업에서 차이를 보여 준다.

피보나치 병렬 계산은 GIL 활성화에서 1,377ms, 자유 스레딩에서 279ms로 약 5배 향상됐다.
20M primes 소수 계산은 Python 3.12 대비 약 2.8x 스피드업을 달성했다. Python 3.12는 멀티스레드에서 스피드업이 없었다.
CPU 바운드 멀티스레드 코드는 코어 수에 비례해 최대 4x 성능 향상이 가능하다.
단일 스레드 오버헤드는 Linux x86-64에서 약 8%, macOS ARM64에서 약 6%다.
pyperformance 기준으로 자유 스레딩은 표준 빌드 대비 단일 스레드 속도의 약 91%를 기록했다.

다음 예제는 자유 스레딩 환경에서 CPU 작업을 여러 스레드에 나누는 형태다.

# 자유 스레딩 멀티코어 활용 예시
import threading
import time

def cpu_bound_task(n: int) -> int:
    """CPU 집약적 소수 계산"""
    count = 0
    for i in range(2, n):
        if all(i % j != 0 for j in range(2, int(i**0.5) + 1)):
            count += 1
    return count

def parallel_benchmark(num_threads: int = 4, limit: int = 100_000):
    threads = []
    start = time.perf_counter()

    for _ in range(num_threads):
        t = threading.Thread(target=cpu_bound_task, args=(limit,))
        threads.append(t)
        t.start()

    for t in threads:
        t.join()

    elapsed = time.perf_counter() - start
    print(f"스레드 {num_threads}개: {elapsed:.3f}초")
    # GIL 비활성화 시: 코어 수에 비례한 선형 스케일링

parallel_benchmark(num_threads=4)

공유 상태는 코드에서 보호해야 한다

GIL이 제거되면 기존 코드가 암묵적으로 기대했던 원자성이 사라진다. 공유 딕셔너리를 동시에 수정하거나, 리스트의 append와 pop을 교차 실행하거나, 클래스 변수와 전역 카운터를 갱신하는 경로를 점검해야 한다.

정수, 문자열, 튜플 같은 불변 타입은 자유 스레딩에서도 안전하다. 반면 list, dict는 단일 메서드 호출 수준의 원자성은 유지되더라도 여러 단계로 구성된 연산은 안전하지 않다.

명시적인 threading.Lock은 복합 연산을 보호하는 기본 패턴이다.

import threading

class ThreadSafeCounter:
    def __init__(self):
        self._value = 0
        self._lock = threading.Lock()

    def increment(self) -> None:
        with self._lock:
            self._value += 1  # 비원자적 복합 연산 보호

    @property
    def value(self) -> int:
        with self._lock:
            return self._value

counter = ThreadSafeCounter()
threads = [threading.Thread(target=counter.increment) for _ in range(1000)]
for t in threads: t.start()
for t in threads: t.join()
print(counter.value)  # 항상 1000

스레드마다 분리할 수 있는 상태는 threading.local()에 둬서 공유 자체를 피할 수 있다.

import threading

_thread_local = threading.local()

def get_connection():
    """스레드별 독립 DB 연결 관리"""
    if not hasattr(_thread_local, 'conn'):
        _thread_local.conn = create_db_connection()
    return _thread_local.conn

생산자와 소비자 사이에는 스레드 안전한 queue.Queue를 사용할 수 있다.

import queue
import threading

task_queue: queue.Queue = queue.Queue(maxsize=100)

def producer(items: list) -> None:
    for item in items:
        task_queue.put(item)  # 스레드 안전 enqueue
    task_queue.put(None)  # 종료 신호

def consumer() -> None:
    while True:
        item = task_queue.get()  # 스레드 안전 dequeue
        if item is None:
            break
        process(item)

@functools.cache도 검토 대상이다. 자유 스레딩에서는 스레드 안전하지 않으므로, 초기화 단계에서 캐시를 워밍업해 읽기 전용으로 쓰거나 호출을 잠금으로 감싸야 한다.

import functools
import threading

# 자유 스레딩에서 functools.cache는 스레드 안전하지 않음
# → 초기화 단계에서 캐시 워밍업 후 읽기 전용으로 활용

_CACHE_LOCK = threading.Lock()

@functools.cache
def expensive_compute(n: int) -> int:
    return sum(range(n))

def safe_cached_call(n: int) -> int:
    with _CACHE_LOCK:
        return expensive_compute(n)

기존 코드베이스를 자유 스레딩으로 옮길 때

자유 스레딩 전환은 빌드를 바꾸는 작업만으로 끝나지 않는다. 공유 상태를 찾고, 경합을 검출하고, 동기화를 추가한 뒤 실제 성능 목표를 다시 확인하는 과정이 필요하다.

⤢✕

점검할 항목은 다음과 같다.

전역 변수(global) 접근 패턴을 검토하고 필요한 잠금을 추가한다.
싱글턴은 threading.Lock() 기반 이중 확인 잠금(double-checked locking)으로 교체한다.
C 확장 라이브러리가 Py_GIL_DISABLED 매크로를 지원하는지 확인한다. NumPy 2.x와 Cython 3.x는 지원을 완료했다.
PYTHON_GIL=1로 GIL을 강제 활성화해 기존 동작과 비교한다.
sys.flags.gil_enabled를 사용해 런타임 분기 처리를 검토한다.

PEP 810이 줄이는 시작 경로

Python 3.15에 수용된 PEP 810(Explicit Lazy Imports)은 모듈을 실제로 사용할 때까지 임포트를 미룬다. 기존 import는 문장에 도달하면 모듈 전체를 로드하고 파싱하고 실행한다. 지연 임포트는 먼저 플레이스홀더 객체를 만들고, 속성에 처음 접근할 때 모듈 로드를 트리거한다.

AWS Lambda에서는 지연 임포트 적용으로 콜드 스타트가 150~~400ms 단축될 수 있고, 웹 애플리케이션 시작 시간도 100~~500ms 절감할 수 있다. Gartner 전망에 따르면 클라우드 네이티브 애플리케이션의 60% 이상이 서버리스 아키텍처를 채택하므로, 시작 경로에서 불필요한 모듈을 제외하는 일은 비용과 응답 시간 모두에 영향을 준다.

서버리스 함수의 병목은 종종 핸들러가 아니라 임포트 단계에 있다.

Lambda 함수 호출
     ↓
컨테이너 초기화 (수백ms)
     ↓
Python 인터프리터 시작
     ↓
import 문 순차 실행  ← 병목
   ├─ import numpy        (200~400ms)
   ├─ import pandas       (100~300ms)
   ├─ import boto3        (80~200ms)
   └─ import sklearn      (300~600ms)
     ↓
핸들러 함수 실행 (실제 작업)

필요한 모듈만 늦게 불러오는 패턴

PEP 810 이전에도 importlib을 이용해 지연 로딩을 구현할 수 있었다.

import importlib
import types

class LazyModule:
    """지연 로딩 모듈 래퍼"""
    def __init__(self, module_name: str):
        self._module_name = module_name
        self._module = None

    def _load(self):
        if self._module is None:
            self._module = importlib.import_module(self._module_name)
        return self._module

    def __getattr__(self, name: str):
        return getattr(self._load(), name)

# 사용 예
numpy = LazyModule("numpy")
pandas = LazyModule("pandas")

def handler(event, context):
    # numpy는 이 시점에 처음 로드됨
    arr = numpy.array([1, 2, 3])
    return {"result": arr.sum().item()}

Python 3.15 이후에는 PEP 810의 공식 문법을 사용할 수 있다.

# 명시적 지연 임포트 블록
from __future__ import lazy_imports

import numpy          # 실제 사용 전까지 로드 안 됨
import pandas as pd   # 실제 사용 전까지 로드 안 됨
import sklearn        # 실제 사용 전까지 로드 안 됨

def train_model(data):
    # sklearn이 여기서 처음 로드됨
    from sklearn.ensemble import RandomForestClassifier
    clf = RandomForestClassifier()
    clf.fit(data['X'], data['y'])
    return clf

서비스 경로에 따라 필요한 라이브러리가 달라지는 Lambda 핸들러라면 수동 지연 임포트도 적용할 수 있다.

# 콜드 스타트 최적화 Lambda 핸들러
import sys
import time

# 항상 필요한 경량 모듈만 즉시 임포트
import json
import os

# 무거운 모듈은 지연 임포트
_boto3 = None
_pandas = None

def _get_boto3():
    global _boto3
    if _boto3 is None:
        import boto3
        _boto3 = boto3
    return _boto3

def _get_pandas():
    global _pandas
    if _pandas is None:
        import pandas
        _pandas = pandas
    return _pandas

def handler(event: dict, context) -> dict:
    action = event.get("action", "")

    if action == "query":
        # boto3는 query 액션에서만 로드
        boto3 = _get_boto3()
        s3 = boto3.client("s3")
        return {"status": "ok"}

    elif action == "analyze":
        # pandas는 analyze 액션에서만 로드
        pd = _get_pandas()
        df = pd.DataFrame(event.get("data", []))
        return {"rows": len(df)}

    return {"status": "unknown action"}

라이브러리별 효과는 실행 경로에 해당 모듈이 없을 때 나타난다.

라이브러리	즉시 임포트	지연 임포트 효과
numpy	~350ms	미사용 경로에서 0ms
pandas	~250ms	미사용 경로에서 0ms
boto3	~150ms	미사용 경로에서 0ms
sklearn	~500ms	미사용 경로에서 0ms
합계(최악)	~1,250ms	필요한 것만 로드

빠른 초기화와 병렬 처리를 함께 구성하기

자유 스레딩은 CPU 작업을 멀티코어로 분산하는 축이고, 지연 임포트는 초기화 단계에서 불필요한 작업을 미루는 축이다. 둘을 조합하면 요청 처리 경로의 콜드 스타트와 실행 중 병렬성을 함께 설계할 수 있다.

⤢✕

다음 코드는 지연 로딩한 NumPy를 자유 스레딩 환경의 스레드 풀에서 사용하는 파이프라인 예시다.

import sys
import threading
from concurrent.futures import ThreadPoolExecutor
from typing import Any

# GIL 비활성화 확인
assert not sys.flags.gil_enabled, "자유 스레딩 빌드(3.14t) 필요"

# 지연 임포트 래퍼
class _LazyImport:
    def __init__(self, name): self._n = name; self._m = None
    def __getattr__(self, a): 
        if self._m is None: import importlib; self._m = importlib.import_module(self._n)
        return getattr(self._m, a)

numpy = _LazyImport("numpy")

_results_lock = threading.Lock()

def parallel_process(chunks: list[list[Any]]) -> list[Any]:
    results = []

    def process_chunk(chunk: list[Any]) -> None:
        # numpy는 이 시점에 처음 로드됨 (지연 임포트)
        arr = numpy.array(chunk)
        result = numpy.sum(arr ** 2)  # CPU 바운드 연산
        with _results_lock:
            results.append(result)

    # 자유 스레딩: GIL 없이 진정한 병렬 실행
    with ThreadPoolExecutor(max_workers=len(chunks)) as executor:
        futures = [executor.submit(process_chunk, c) for c in chunks]
        for f in futures:
            f.result()

    return results

호환성은 배포 전에 확인할 문제다

자유 스레딩의 실용화는 CPython만의 변화가 아니다. C 확장과 바인딩 라이브러리까지 호환돼야 한다.

NumPy 2.x는 Py_GIL_DISABLED 매크로를 지원하며 대부분의 연산이 스레드 안전하다.
Cython 3.x는 자유 스레딩 빌드를 지원하고 nogil 블록을 활용할 수 있다.
PyO3는 v0.27 이상에서 자유 스레딩 지원을 공식화했다.
지원하지 않는 라이브러리는 PYTHON_GIL=1로 GIL을 강제 활성화해 안전하게 실행할 수 있다.
C 확장이 자유 스레딩을 완전히 활용하려면 Py_mod_gil: Py_MOD_GIL_NOT_USED를 선언해야 한다.
GIL 빌드가 기본값에서 제거될 것으로 예상되는 2028~2029까지는 두 빌드가 함께 운영된다.

객체 크기가 16→32바이트로 늘어나 메모리 사용량은 약 10~20% 증가한다. 락 경합이 심한 코드에서는 멀티스레드 이점이 줄어들 수 있으며, 싱글스레드 중심 코드는 8% 이하의 성능 저하가 가능하다. functools.cache, logging 등 일부 표준 라이브러리 모듈의 스레드 안전성도 다시 검토해야 한다.

자유 스레딩은 멀티코어 CPU 바운드 작업에서 기존 대비 최대 5배의 병렬 처리 성능을 제공하고, 단일 스레드 오버헤드는 5~10% 수준이다. PEP 810 지연 임포트는 FaaS 환경에서 서버리스 콜드 스타트를 최대 400ms 이상 단축할 수 있다. 두 기능을 함께 쓰려면 성능 수치보다 먼저 공유 상태와 확장 모듈의 호환성을 확인해야 한다.