🤗멀티 스레딩 수듄 ㅋㅋ

2026. 3. 14. 16:51·CS

Intro.

지난 게시글에서 프로세스와 스레드, 그리고 멀티 프로세스와 멀티 스레드의 차이에 대해 자세히 알아보았다. 마지막에는 두 방식의 장점을 합친 하이브리드 방식까지 살짝 언급했었다. 이번 게시글에서는 멀티 스레딩과 '성능'의 관계에 대해 조금 더 깊게 설명해 보도록 하겠다.

 

흔히들 "스레드를 여러 개 쓰면 일을 동시에 처리하니까 무조건 성능이 좋아지는 거 아니야?"라고 생각할 수 있다. 반은 맞고 반은 틀린 이야기다. 멀티 스레딩이 어떻게 성능을 높여주는지, 그리고 왜 무조건 정답은 아닌지 알아보자.


멀티 스레딩은 왜 빠를까?

멀티 스레딩이 성능을 높이는 기본 원리는 한정된 CPU 자원을 쉬지 않고 알뜰하게 쓰는 것에 있다.

요즘 우리가 쓰는 CPU는 대부분 코어가 여러 개인 멀티코어 환경이다. 물리적인 코어가 여러 개일 때 여러 스레드를 할당하면, 말 그대로 연산을 동시에 수행하는 병렬성(Parallelism)을 띠게 되어 속도가 비약적으로 높아진다.

 

또한, 어떤 스레드가 데이터베이스나 네트워크에서 응답을 기다리느라 아무것도 안 하고 쉴 때가 있다. 이때 CPU를 놀게 내버려 두지 않고 다른 스레드가 그 빈 시간에 연산을 처리하도록 하는 동시성(Concurrency)을 활용하기 때문에 시스템 전체의 처리 효율이 극대화된다.

 


스레드가 많으면 무조건 빠를까?

그렇다면 스레드를 100개, 1,000개 무작정 늘리면 성능도 그만큼 쭉쭉 올라갈까? 당연히 아니다. 가장 큰 이유는 컨텍스트 스위칭이다. 아무리 멀티 프로세스에 비해 컨텍스트 스위칭의 비용을 줄였다 하더라도 한계가 있다.

 

스레드가 너무 많아지면 CPU는 실제 연산하는 시간보다 '어떤 스레드에게 일을 맡길지 교대하는 시간'에 더 많은 자원을 낭비하게 된다. 이를 쓰레싱(Thrashing)이라고 부른다. 일꾼이 너무 많아서 좁은 문에서 서로 교대하느라 정작 일은 못 하고 시간만 버리는 상황이라고 생각하면 쉽다.

 

이전 게시글에서 멀티 스레드는 프로세스 안에서 메모리(Heap, Data 영역 등)를 공유한다고 설명했다. 이 공유 덕분에 자원 간 통신 속도가 빠르지만, 동시에 성능을 깎아먹는 원인이 되기도 한다.

 

여러 스레드가 동시에 같은 자원에 접근해서 데이터가 꼬이는 동기화 문제(경쟁 상태)를 막기 위해, 우리는 뮤텍스나 세마포어 같은 자물쇠(Lock)를 건다. 문제는 자물쇠가 걸려 있으면 다른 스레드들은 병렬로 일하지 못하고 순서대로 줄을 서서 기다려야 한다는 것이다.

 

즉, 코드 안에 이렇게 줄 서서 기다려야 하는 구간(순차적 처리 구간)이 많아지면 사실상 싱글 스레드와 다를 바 없이 동작하게 된다. 아무리 스레드와 코어 수를 늘려도 성능 향상에 한계가 온다는 암달의 법칙(Amdahl's Law)이 바로 이런 딜레마를 설명하는 이론

이다.

 


멀티 스레딩의 문제점

멀티 스레딩은 한 프로세스 내에서 여러 개의 스레드가 자원들을 공유하기 때문에 발생할 수 있는 문제들이 많다.

  1. 동기화 문제(Race Condition): 두 개 이상의 스레드가 하나의 공유 자원에 동시에 접근 및 수정
  2. 교착 상태(Deadlock):두 개 이상의  스레드가 서로가 가진 자원을 기다리며 무한 대기
  3. 기아 상태(Starvation): 우선순위에 밀려 영영 자원을 할당 받지 못함

물론 이 문제들을 해결할 수 있는 방법들도 존재한다.

 


동기화 문제(Race Condition)

cnt = cnt + 1; 다음과 같은 코드를 2개의 스레드가 실행한다고 하자.

  1. 메모리에서 cnt 값을 읽어온다.
  2. cnt에 +1을 한다.
  3. 결과값을 메모리에 저장한다.

다음과 같은 과정을 거친다. 만약 A 스레드가 3번 작업 전에 B 스레드가 이 작업을 시작하면 둘 다 원래 값을 읽어버린다. 따라서 결과적으로 +1이 아니라 +2가 된다. 이런 문제들을 해결하기 위해 다음과 같은 개념들을 사용한다.

 

뮤텍스 (Mutex: Mutual Exclusion)

임계 영역에 한 번에 하나의 스레드 혹은 프로세스만 들어가게 하는 기술이다.

임계 영역은 동시에 여러 개의 스레드가 접근하면 위험한 데이터나 코드들이 모여있는 구역이다.

 

스레드가 작업할 때 Lock을 요청하고 작업을 마친 후 Unlock 요청 전까지 다른 스레드들은 이용 불가능하다.

 

세마포어 (Semaphore)

뮤텍스가 한 번에 하나면 세마포어는 한 번에 여러 명이 들어가게 하는 기술이다.

 

미리 정해진 공유 자원의 수를 나타내는 정수값을 갖고, 한 개의 스레드가 들어갈 때마다 정수값을 -1, 스레드가 나오면 +1을 실행한다. 정수값이 0이 되면 다른 스레드들은 입장하지 못하고 대기하게 된다.

 


교착 상태 (DeadLock)

교착 상태에는 먼저 4가지 조건이 있다.

  1. 상호 배제: 자원을 스레드가 독점적으로 사용한다. (위에서 나온 뮤텍스와 세마포어의 핵심)
  2. 점유와 대기: 현재 가진 자원을 버리지 않고, 다른 스레드의 자원을 기다리는 것이다.
  3. 비선점: 다른 스레드가 가진 자원을 강제로 빼앗아 올 수 없다.
  4. 순환 대기: 대기열이 원형을 이루어야 한다. (A -> B -> C -> A)

따라서 이 4가지 중 하나라도 발생하지 않게 하는 것이 곧 데드락을 예방하는 방법이다. 상호 배제를 보면 알겠지만, 데드락을 예방하면 동기화 문제를 해결하지 못한다는 딜레마에 빠지게 된다. 그래서 현실적으로 예방보다는 회피나 탐지 및 회복방식을 택한다.

 

데드락 회피

 

 

그래서 어떻게 써야 할까?

결론적으로 멀티 스레딩은 성능과 응답성을 높여주는 훌륭한 무기지만, 무작정 쓴다고 해서 빨라지는 마법의 지팡이는 아니다. 스레드 교체 비용과 동기화 대기 시간이라는 명확한 비용을 지불해야 한다.

 

따라서 실제 서비스에서는 무한정 스레드를 생성하는 것이 아니라, 시스템의 코어 개수와 작업의 성격에 맞춰 적절한 개수의 스레드만 미리 만들어두고 돌려쓰는 '스레드 풀(Thread Pool)' 방식을 주로 사용한다.

 

서두에 말했듯이 무조건적인 정답은 없다. 내 프로그램이 연산 위주의 무거운 작업인지, 아니면 응답 대기가 많은 작업인지 상황에 맞게 튜닝하는 것이 성능 최적화의 핵심이다.

 

'CS' 카테고리의 다른 글

동기/비동기와 블로킹/논블로킹  (0) 2026.03.14
🤯그게 그거 아닌가? 멀티 프로세스 vs 멀티 스레드  (0) 2026.03.14
💻프로세스? 스레드? 어디서 들어는 봤는데..  (0) 2026.03.10
😗TCP? HTTP랑 비슷한 거 아님?  (0) 2026.03.03
🤔 REST API랑 RESTful API, 뭐가 달라? (진짜 모름)  (0) 2026.02.25
'CS' 카테고리의 다른 글
  • 동기/비동기와 블로킹/논블로킹
  • 🤯그게 그거 아닌가? 멀티 프로세스 vs 멀티 스레드
  • 💻프로세스? 스레드? 어디서 들어는 봤는데..
  • 😗TCP? HTTP랑 비슷한 거 아님?
asht1124
asht1124
DEV blog
  • asht1124
    ASHT
    asht1124
  • 전체
    오늘
    어제
    • 분류 전체보기 (18)
      • 프런트엔드 (0)
      • 백엔드 (0)
        • Sping (0)
      • Dev-ops (0)
      • CS (18)
        • Web 이론 (2)
        • 보안 (1)
        • DB (4)
        • 네트워크 (3)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    rest
    API
    정규화
    http
    비밀키
    BCNF
    비대칭키
    프로토콜
    3-way handshake
    nosql
    프로세스
    스레드
    1NF
    데이터 무결성
    인터페이스
    tcb
    REST API
    반정규화
    멀티 스레드
    3NF
    보안
    멀티 프로세스
    PCB
    OAS
    rdb
    tcp
    acid
    4-way handshake
    RESTful API
    2NF
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.6
asht1124
🤗멀티 스레딩 수듄 ㅋㅋ
상단으로

티스토리툴바