Job System : 멀티스레딩과 잡 시스템의 효율성 비교

기본 개념 정리 (Hardware & OS)

• 물리 코어 (Physical Core) : 실제로 일을 처리하는 일꾼의 수 (예: 8코어 = 일꾼 8명). 절대적인 물리적 한계치입니다.
• 소프트웨어 스레드 (Software Thread) : 프로그램이 요청하는 작업의 흐름. (개수 제한 없음. 100개든 1000개든 생성 가능).
• 운영체제 (OS)의 역할 : 일꾼(8명)보다 작업 흐름(100개)이 많을 때, 시간을 아주 잘게 쪼개서(Time Slicing) 번갈아 가며 실행합니다.
  • "너 0.001초 일하고 비켜, 다음 애 들어와!"
• 컨텍스트 스위칭 (Context Switching) : 작업 흐름을 바꿀 때 발생하는 교체 비용.
  • 하던 일 저장하기 + 새 일 불러오기 + 캐시 비우기 등 매우 비싼 작업입니다.

 

2. 상황 비교 : 100개의 작업을 처리하는 두 가지 방법

만약 8코어 CPU에서 100개의 몬스터 로직을 처리해야 한다면?

비교 항목	❌ 상황 A : 무지성 스레드 생성	✅ 상황 B : 잡 시스템
방식	new Thread()로 스레드 100개 생성	워커 스레드 8개 (미리 생성 및 재사용) + 잡(Job) 100개 예약
비유	요리사(코어)는 8명인데, 조리대에 100명이 번갈아 가며 들어감.	요리사 8명이 각자 자리를 지키고, 주문서(Job) 100장을 나눠서 처리함.
동작	1번 스레드 일하다가 멈춤(Switch) → 2번 들어옴 → 멈춤 → 3번...	워커 1이 Job 1 처리 → (즉시) Job 2 처리 → (즉시) Job 3 처리...
비용	컨텍스트 스위칭 비용 폭발 (작업 처리보다 스위칭 비용이 더 듬)	교체 비용 "0" (스레드가 바뀌지 않음. 그냥 함수 호출임)
결과	CPU 점유율은 높은데 게임은 느림 (오버헤드)	CPU 자원을 온전히 연산에만 사용 (고효율)

 

최종 요약

"적어도 유니티 안에서 우리끼리(스크립트끼리) 코어 차지하려고 싸우지는 말자."

1. 외부 요인(OS) : 멜론, 카톡, 윈도우 업데이트 등이 코어를 뺏어가는 건 어쩔 수 없다. (받아들임)
2. 내부 요인(Unity) : 하지만 적어도 유니티 내부에서만큼은 스레드를 100개씩 만들어서 서로 비키라고 싸우는 '팀킬'은 하지 말자.
3. 해결책:  딱 코어 수만큼만 스레드를 만들어서 고정 배치하고, 일감(Data)만 계속 밀어 넣어주자.
   • 이렇게 하면 "스레드 교체 비용(Context Switching)"을 "함수 호출 비용"으로 낮출 수 있다.

이것이 바로 Job System이 압도적으로 빠른 이유입니다.