[PYTHON] 성능 최적화를 위한 ThreadPoolExecutor와 ProcessPoolExecutor의 3가지 Max Workers 설정 기준과 해결 방법

ThreadPoolExecutor와 ProcessPoolExecutor

 

 

파이썬으로 고성능 애플리케이션을 개발하다 보면 반드시 마주하게 되는 벽이 있습니다. 바로 비동기 처리와 병렬성(Parallelism)의 효율적 관리입니다. concurrent.futures 모듈에서 제공하는 ThreadPoolExecutor와 ProcessPoolExecutor는 이를 해결하는 핵심 도구이지만, 대다수의 개발자가 범하는 치명적인 실수는 max_workers 값을 단순히 '적당히 큰 숫자'로 설정하는 것입니다. 잘못된 Worker 설정은 컨텍스트 스위칭(Context Switching) 비용을 증가시키고, 메모리 부족(OOM) 현상을 초래하며, 심지어 단일 스레드보다 느린 결과를 낳기도 합니다. 본 가이드에서는 실전 프로젝트 경험을 바탕으로 CPU와 I/O 바운드 작업에 따른 최적의 Worker 산출 공식과 성능 병목 현상을 해결하는 실질적인 방법을 심도 있게 다룹니다.

---

1. 왜 Max Workers 설정이 중요한가? (성능 저하의 원인과 해결)

파이썬은 GIL(Global Interpreter Lock)이라는 구조적 특징을 가지고 있습니다. 이로 인해 멀티 스레딩 환경에서도 한 번에 하나의 바이트코드만 실행될 수 있습니다. 따라서 작업의 성격(CPU 집중형 vs I/O 집중형)에 따라 Worker의 개수는 하드웨어 자원과 정밀하게 맞물려야 합니다.

• 자원 낭비 방지: 필요 이상의 Worker는 과도한 메모리 점유를 유발합니다.
• 스케줄링 오버헤드: 너무 많은 스레드/프로세스는 OS 커널의 스케줄링 부하를 가중시킵니다.
• 처리량(Throughput) 극대화: 적절한 수치는 대기 시간을 최소화하고 단위 시간당 처리량을 높입니다.

---

2. Executor별 최적의 Max Workers 산출 기준 비교

다음은 작업 유형에 따른 Executor 선택과 max_workers 설정 기준을 요약한 비교표입니다.

항목	ThreadPoolExecutor	ProcessPoolExecutor
주요 대상 작업	I/O Bound (네트워크, 파일 읽기/쓰기, DB 쿼리)	CPU Bound (연산, 이미지 처리, 데이터 분석)
핵심 제약 사항	GIL (Global Interpreter Lock)	메모리 오버헤드 및 프로세스 생성 비용
권장 Max Workers (공식)	$min(32, \text{os.cpu\_count()} + 4)$ (Python 3.8+ 기본값)	$\text{os.cpu\_count()}$ (물리 코어 수 이내)
성능 해결 핵심	대기 시간(Latency) 활용	병렬 연산(True Parallelism)
한계점	CPU 연산 작업 시 성능 향상 미미	데이터 직렬화(Pickling) 비용 발생

---

3. 실전 적용을 위한 3가지 Max Workers 설정 가이드

가이드 01. I/O Bound 작업 (ThreadPoolExecutor)

웹 크롤링, API 호출과 같은 작업은 CPU가 아닌 외부 자원의 응답을 기다리는 시간이 대부분입니다. 이 경우 CPU 코어 수보다 훨씬 많은 수의 스레드를 할당해도 무방합니다. 실제 벤치마크 결과에 따르면, 네트워크 지연 시간이 길수록 Worker 수를 늘리는 것이 유리하지만, 일반적으로 32개를 초과할 경우 스레드 관리 오버헤드가 이득을 상쇄하기 시작합니다. 파이썬 3.8 버전부터는 시스템의 부하를 방지하기 위해 min(32, os.cpu_count() + 4)를 기본값으로 채택하고 있습니다.

가이드 02. CPU Bound 작업 (ProcessPoolExecutor)

수학적 계산이나 대용량 데이터 가공은 GIL을 우회하여 여러 프로세스에서 동시에 실행되어야 합니다. 이때 max_workers는 반드시 기기의 물리적 코어 수(os.cpu_count())와 일치시키거나 그보다 작게 설정해야 합니다. 코어 수보다 많은 프로세스를 생성하면 실제 연산 능력은 늘어나지 않으면서 프로세스 간 전환 비용만 커지는 역효과가 발생합니다.

가이드 03. 하이브리드 부하 조절 방법

만약 I/O와 CPU 연산이 혼합된 작업이라면, 작업을 분리하여 두 가지 Executor를 계층적으로 운용하는 설계가 필요합니다. 데이터를 긁어오는 작업(Thread)과 가공하는 작업(Process)을 구분하여 큐(Queue)로 연결하는 방식이 가장 효율적인 해결책입니다.

---

4. Sample Example: 효율적인 병렬 처리 구현

아래 코드는 대량의 URL에서 데이터를 가져오는 I/O 작업을 ThreadPoolExecutor를 통해 효율적으로 처리하는 예시입니다.

import requests
from concurrent.futures import ThreadPoolExecutor, as_completed
import os

def fetch_url(url):
    response = requests.get(url, timeout=5)
    return f"{url}: {response.status_code}"

urls = [
    "https://www.google.com",
    "https://www.python.org",
    "https://www.github.com",
    # ... 수백 개의 URL 가정
]

# 1. 시스템 코어 수에 따른 가변적 Worker 설정 해결 방법
cpu_cores = os.cpu_count()
max_workers = min(32, cpu_cores + 4)

print(f"설정된 Max Workers: {max_workers}")

with ThreadPoolExecutor(max_workers=max_workers) as executor:
    future_to_url = {executor.submit(fetch_url, url): url for url in urls}
    
    for future in as_completed(future_to_url):
        url = future_to_url[future]
        try:
            data = future.result()
            print(f"성공: {data}")
        except Exception as exc:
            print(f"오류 발생: {url} -> {exc}")

---

5. 성능 병목 현상 해결을 위한 전문가의 제언

단순히 숫자를 맞추는 것보다 중요한 것은 프로파일링(Profiling)입니다. time.time()을 이용한 측정뿐만 아니라, cProfile 모듈을 사용하여 실제 코드의 어느 부분에서 시간이 소요되는지 파악하십시오. 특히 ProcessPoolExecutor를 사용할 때는 인자로 전달되는 데이터의 크기에 유의해야 합니다. 프로세스 간 데이터 전달은 'Pickle'이라는 직렬화 과정을 거치는데, 데이터가 너무 크면 병렬 처리로 얻는 이득보다 데이터 복사 비용이 더 커질 수 있습니다. 이럴 때는 공유 메모리(Shared Memory)나 대용량 파일의 경우 Memory-mapped file (mmap)을 사용하는 것이 진정한 성능 해결의 열쇠입니다.

---

참고 문헌 및 출처

• Python Software Foundation. "concurrent.futures — Launching parallel tasks". Official Documentation.
• Raymond Hettinger. "Modern Concurrency". PyCon Presentation.
• David Beazley. "Understanding the Python GIL". Conference Paper.
• High Performance Python, 2nd Edition by Micha Gorelick and Ian Ozsvald.