📘 Multithreading

멀티 스레딩과 성능

한 가게에 직원이 많아질수록 가게는 더 빨리 돌아갈까?

직관적으로는 그렇다고 생각할 수 있다.

하지만 항상 그런 것은 아니다.

직원이 너무 많아지면 오히려 서로 동선이 꼬이고
누가 어떤 일을 하는지 혼란이 생길 수도 있다.

컴퓨터 프로그램에서도 비슷한 일이 발생한다.

여러 작업을 동시에 처리하기 위해 멀티 스레딩(Multithreading)을 사용하지만 스레드가 많다고 해서 항상 프로그램의 성능이 좋아지는 것은 아니다.

이번에는 멀티 스레딩이 프로그램의 성능에 어떤 영향을 미치는지, 그리고 어떤 상황에서 멀티 스레딩이 효과적인지 살펴보려고 한다.

---

동기화 비용 (Synchronization Cost)

멀티 스레드는 같은 프로세스 안에서 실행되기 때문에 메모리를 서로 공유한다.
이 구조 덕분에 스레드 간 데이터 공유가 쉽고 프로세스를 새로 생성하는 것보다 훨씬 가볍다.

하지만 여기에는 한 가지 문제가 있다.

여러 스레드가 같은 데이터를 동시에 수정할 수 있다는 점이다.

예를 들어 여러 스레드가 하나의 전역 변수나 공유 메모리를 동시에 수정하게 되면 데이터 값이 꼬이거나 예상하지 못한 결과가 발생할 수 있다.

이처럼 여러 스레드가 동시에 접근하면 문제가 발생할 수 있는 코드 영역을 임계 영역(Critical Section)이라고 한다.

따라서 이러한 상황에서는 데이터의 일관성과 정확성을 유지하기 위해 동기화(Synchronization) 기법을 사용해야 한다.

동기화 기법에는 대표적으로 뮤텍스(Mutex) 나 세마포어(Semaphore)이 있다.

이들은 한 번에 하나의 스레드만 공유 자원에 접근하도록 제한하여 데이터의 일관성을 유지한다.

하지만 문제는 여기서 끝나지 않는다.

동기화를 위해 사용하는 Lock은 공유 자원을 보호해 주지만, 동시에 프로그램의 병렬성을 제한하는 요소가 되기도 한다.

스레드는 공유 자원에 접근하기위해 Lock 획득, 작업 수행, Lock 해제와 같은 과정이 필요하다.
이때 한 스레드가 Lock을 잡고 있는 동안 다른 스레드들은 해당 자원에 접근하지 못하고 대기 상태에 들어가게 된다.

이러한 상황을 Lock 경쟁(Contention)이라고 한다.

스레드 수가 많아질수록 여러 스레드가 동시에 같은 자원에 접근하려고 하면서 Lock 경쟁과 대기 시간이 점점 증가하게 된다.

결과적으로 여러 스레드를 사용하고 있음에도 불구하고 실제로는 한 번에 하나의 스레드만 작업을 수행하는 상황이 발생할 수 있다.

즉 멀티 스레드를 사용했지만 실제로는 싱글 스레드와 비슷하게 동작하게 되는 것이다.

그래서 멀티 스레드 프로그램에서는 단순히 스레드를 많이 만드는 것보다 공유 자원을 최소화하고 임계 영역을 최대한 짧게 유지하는 것이 중요하다.

물론 그렇다고 해서 스레드를 사용하지 않는 것이 정답은 아니다.

멀티 스레드는 여전히 CPU 코어를 동시에 활용할 수 있기 때문에 많은 상황에서 프로그램의 성능을 크게 향상시킬 수 있다.

다만 중요한 점은 스레드 수를 무작정 늘리는 것이 아니라 프로그램의 구조와 작업 특성에 맞게 설계해야 한다는 것이다.

---

Context Switching 오버헤드

여러 스레드가 존재하면 CPU는 스레드를 번갈아 실행해야 한다.

이 과정에서 발생하는 비용이 Context Switching 오버헤드이다.

Context Switching은 현재 실행 중인 스레드의 상태를 저장하고
다른 스레드의 상태를 불러오는 작업을 의미한다.

싱글 스레드는 실행 흐름이 하나뿐이기 때문에 이러한 전환이 발생하지 않는다.

하지만 멀티 스레드 환경에서는 스레드 수가 많아질수록
CPU가 여러 스레드를 계속 바꿔가며 실행해야 한다.

특히 CPU 코어 수보다 훨씬 많은 스레드를 생성하면
CPU는 실제 작업보다 스레드 전환에 더 많은 시간을 사용하게 될 수도 있다.

예를 들어 1부터 1000까지 덧셈을 하는 작업을 100번 수행하는 프로그램이 있다고 가정해보자.

싱글 스레드라면 다음과 같이 간단히 작성할 수 있다.

long sum = 0; 
for(int j=0; j<100; j++) {
  for(int i=0; i<1000; i++) {
    sum += i;  
  } 
}

이 코드는 하나의 스레드가 순서대로 계산을 수행한다.

반면 멀티 스레드 프로그램이라면 다음과 같이 각 작업을 여러 스레드로 나누어 동시에 실행할 수도 있다.

long sum = 0; 

/*  스레드 1 */
new Thread(() -> {
    for (int i = 0; i < 10000000; i++) {
        sum += i;
    }
}).start();

/*  스레드 2 */
new Thread(() -> {
    for (int i = 0; i < 10000000; i++) {
        sum += i;
    }
}).start();

// ... 스레드 3~99 ...

/*  스레드 100 */
new Thread(() -> {
    for (int i = 0; i < 10000000; i++) {
        sum += i;
    }
}).start();

직관적으로 생각하면 멀티 스레드는 100개의 스레드가 동시에 실행되기 때문에 싱글 스레드보다 훨씬 빠를 것처럼 보인다.

하지만 실제로는 그렇지 않을 수도 있다.

스레드 수가 많아질수록 CPU는 여러 스레드를 번갈아 실행해야 하고 그 과정에서 Context Switching이 계속 발생하게 된다.

이 전환 과정에서도 CPU 시간과 자원이 사용되기 때문에 경우에 따라서는 실제 계산 작업보다 스레드 전환 비용이 더 커질 수도 있다.

즉 멀티 스레드를 사용했다고 해서 항상 성능이 선형적으로 증가하는 것은 아니다.
“스레드가 많을수록 작업을 분리해서 동시에 처리하니까 항상 빠르다”는 고정관념은 틀렸다는 것이다.

특히 CPU 코어 수보다 훨씬 많은 스레드를 생성하면 CPU는 계속 스레드를 바꿔가며 실행해야 하고
이로 인해 오히려 프로그램의 성능이 떨어질 수도 있다.

그래서 멀티 스레드 프로그램에서는 CPU 코어 수에 맞는 적절한 스레드 수를 설정하는 것이 중요하다.

---

Thread Pool

멀티 스레드 프로그램에서는 항상 모든 스레드가 일을 하는 것은 아니다.
서비스가 한산한 시간에는 많은 스레드가 아무 작업도 하지 않고 대기 상태에 있을 수 있다.

하지만 스레드가 대기 상태라고 해서 아무 자원도 사용하지 않는 것은 아니다.

스레드는 존재 자체만으로 메모리, CPU 스케줄링 자원을 사용한다.

그래서 너무 많은 스레드를 생성하면불필요한 자원 낭비가 발생할 수 있다.

이 문제를 해결하기 위해 사용하는 것이 Thread Pool이다.

Thread Pool은 말 그대로 미리 만들어 둔 스레드들의 집합이다.

프로그램이 실행될 때 일정 개수의 스레드를 미리 생성해 두고, 작업이 발생하면 새로운 스레드를 만들지 않고 이미 존재하는 스레드를 재사용하는 방식이다.

맥도날드 비유로 다시 생각해보자.

손님이 올 때마다 직원을 새로 뽑는다면 채용 과정만으로도 시간이 많이 걸릴 것이다.
그래서 보통은 적당한 수의 직원이 항상 대기하고 있다가 손님이 오면 바로 일을 처리한다.

Thread Pool도 같은 개념이다.

필요한 만큼의 스레드를 미리 만들어 두고 작업이 생길 때 해당 스레드를 할당하는 방식이다.

웹 서버를 예로 들어보자. 사용자 요청이 동시에 많이 들어올 때 서버는 여러 작업을 처리해야 한다.

이때 매번 새로운 스레드를 생성하면 성능에 부담이 될 수 있기 때문에 Thread Pool을 사용해 스레드를 재사용한다.

from concurrent.futures import ThreadPoolExecutor
import time

# 사용자 요청을 처리하는 함수
def handle_request(user_id):
    print(f"사용자 {user_id} 요청 처리 시작")
    
    # 서버가 요청을 처리하는데 2초 걸린다고 가정
    time.sleep(2)
    
    print(f"사용자 {user_id} 요청 처리 완료")

# 최대 3개의 스레드를 가진 Thread Pool 생성
with ThreadPoolExecutor(max_workers=3) as executor:

    # 사용자 5명이 동시에 요청했다고 가정
    for user in range(1, 6):
        executor.submit(handle_request, user)

이 코드에서는 3개의 스레드로 이루어진 Thread Pool을 만들고 5개의 작업을 실행한다.

Thread 1 → 사용자 1 요청 처리
Thread 2 → 사용자 2 요청 처리
Thread 3 → 사용자 3 요청 처리

요청이 끝나면 기존 스레드를 재사용해 다음 요청을 처리

Thread 1 → 사용자 4 요청 처리
Thread 2 → 사용자 5 요청 처리

스레드를 계속 새로 생성하는 것이 아니라 기존 스레드를 재사용하며 작업을 처리하는 식으로 동작을 하는 것이다.

만약 Thread Pool을 사용하지 않는다면 사용자 요청이 들어올 때마다 새로운 스레드를 생성해야 한다.

하지만 스레드를 계속 생성하고 제거하는 작업은 생각보다 많은 비용이 발생한다.

그래서 실제 서버 프로그램에서는 위와 같이 Thread Pool 방식을 사용한다.

---

CPU Bound vs I/O Bound

멀티 스레딩의 효과는 프로그램의 성격에 따라 크게 달라진다.

대표적으로 CPU Bound와 I/O Bound 두 가지가 존재한다.

우선 CPU Bound는 CPU 연산에 의존하는 작업. 즉 CPU 계산이 대부분인 작업이다.

영상처리, 데이터 분석, 암호화 연산 등이 있는데 이 경우 스레드를 너무 많이 생성하면 CPU가 계속 스레드를 바꾸느라 오히려 성능이 떨어질 수 있다.

그래서 보통 스레드 수(스레드 수 ≈ CPU 코어 수)가 적절하다고 알려져 있다.

I/O Bound는 입출력 작업이 많은 프로그램, 즉 I/O 장치의 응답 속도에 의존하는 작업을 말한다.

대표적인 예로는 웹 서버, 파일 다운로드, 데이터베이스 요청과 같은 작업이 있다.

이러한 작업들은 대부분 CPU 연산보다 입출력 장치의 응답 시간이 더 오래 걸린다.

예를 들어 데이터베이스에서 데이터를 조회하거나 파일을 읽어오는 작업은 디스크 접근이나 네트워크 통신이 필요하기 때문에 CPU 계산보다 훨씬 느리다.

이때 싱글 스레드 프로그램이라면 입출력 작업이 완료될 때까지 CPU는 다음 작업을 수행하지 못하고 대기 상태(Blocked)에 들어가게 된다. 즉 프로그램은 실제로 아무 일도 하지 못한 채 I/O 작업이 끝나기만을 기다리게 되는 것이다.

하지만 멀티 스레드를 사용하면 상황이 달라진다.

한 스레드가 I/O 작업을 수행하며 대기하는 동안 다른 스레드가 CPU를 사용해 다음 작업을 처리할 수 있기 때문이다.

이렇게 하면 CPU가 놀지 않고 계속 작업을 수행할 수 있기 때문에 전체 시스템의 처리량이 크게 향상된다.

그래서 I/O 작업이 많은 프로그램에서는 CPU 코어 수보다 더 많은 스레드를 사용하는 것이 오히려 성능에 도움이 되는 경우가 많다.

하지만 스레드를 계속 늘리면 Context Switching 증가, 동기화 비용 증가, 불필요한 자원사용과 같은 문제가 있는데??라는 의문이 들수있다. 정답이다. 이를 해결하기 위해는 따로 비동기 I/O 기반의 이벤트 모델이 존재한다. 이에 대해서는 추후 다른 글에서 설명을 하겠다.

---

정리

싱글 스레드는 단 하나의 스레드가 모든 작업을 처리하기에 프로그램 구조가 단순하여 개발이 더 쉽고 CPU, 메모리를 적게 사용한다.

하지만 멀티 스레드는 앞서 언급했듯이 Race Condition, Deadlock, Synchronization과 같은 문제를 고려해야한다. 그래서 프로그램 구조가 훨씬 복잡해지고 개발 난이도도 크게 올라간다.

멀티 스레드는 분명 성능을 향상시킬 수 있는 강력한 기술이지만, 무턱대고 적용한다고 해서 항상 좋은 결과를 얻을 수 있는 것은 아니다. 잘못 설계하면 성능과 안정성 모두를 잃어버리는 상황이 발생할 수도 있다.

중요한 것은 “스레드를 많이 만드는 것”이 아니라 “적절한 수의 스레드를 사용하는 것”이다.