CPU Scheduling이란? 운영체제가 여러 작업에 CPU 시간을 나눠주는 원리 쉽게 이해하기
CPU Scheduling은 제한된 CPU Core에 여러 Thread의 실행 시간을 배분하는 과정입니다. Ready·Running·Waiting, FCFS·SJF·Round Robin·Priority, Time Slice·Context Switch까지 초보 기준으로 정리합니다.
브라우저·메신저·음악·백그라운드 업데이트가 한꺼번에 돌아가도, CPU Core 수는 제한되어 있습니다. Core 4개에 Runnable Thread가 100개라면 같은 순간에 모두 실행할 수 없습니다. 그래서 운영체제는 「지금 누구를 돌릴까」「얼마 동안」「다음에는 누구에게」를 계속 정합니다. 이처럼 여러 Process·Thread 중 어떤 작업에 CPU 실행 시간을 배분할지 결정하는 과정을 CPU Scheduling(프로세서 스케줄링)이라고 합니다.
CPU Core 4개 실행 가능 Thread 100개 → Scheduler가 선택 · Time Slice · Preempt
식당 주문 · Ready · Running · Waiting
요리사(CPU)는 주문을 한 번에 다 만들 수 없습니다. 먼저 온 순·빨리 되는 순·VIP 순처럼 정책을 고릅니다. Scheduler는 Ready(실행 준비 완료) Thread 중 다음 실행을 고릅니다. Ready Queue(또는 Run Queue)에 줄 선 Thread가 있고, CPU를 받으면 Running, DB·Disk·Lock을 기다리면 Waiting/Blocked입니다. Waiting에 CPU를 줘도 할 일이 없으므로 Scheduler는 다른 Thread를 돌립니다.
Ready → CPU 배정 → Running Running → I/O · Lock → Waiting Waiting → 응답 도착 → Ready
목표 · FCFS · SJF · Round Robin · Priority
목표는 하나가 아닙니다. CPU Utilization·Throughput·Response Time·Waiting Time·Turnaround·Fairness·Deadline을 상황에 맞게 저울질합니다. Interactive는 반응성, Real-Time은 Deadline, Desktop은 Fairness가 더 중요할 수 있습니다.
FCFS는 먼저 온 순입니다. 긴 작업 A 뒤에 짧은 B·C·D가 줄줄이 기다리면 Head-of-Line Blocking과 비슷한 Convoy Effect가 납니다. SJF는 짧은 작업 우선으로 평균 대기를 줄일 수 있지만 실행 시간을 미리 알기 어렵고, 짧은 작업이 계속 들어오면 Long Job이 Starvation될 수 있습니다. SRTF는 남은 시간이 더 짧은 작업이 오면 선점하는 SJF의 Preemptive 형태입니다.
Preemptive는 OS가 중간에 CPU를 회수할 수 있고, Non-Preemptive는 스스로 반납하거나 끝날 때까지 유지합니다. 무한 Loop에서도 Preempt가 있으면 다른 작업에 기회가 갑니다. Round Robin은 Time Slice(Time Quantum)를 순서대로 나눕니다. Slice가 너무 길면 반응이 늦고, 너무 짧으면 Context Switching 비용이 커집니다. Priority Scheduling은 높은 Priority를 먼저 돌립니다. Aging으로 오래 기다린 작업의 Priority를 올려 Starvation을 완화합니다. High가 Low의 Lock을 기다리는데 Medium이 Low를 밀어내면 Priority Inversion이 됩니다. Scheduler는 Runnable만 실행할 수 있어, Block된 High에게 CPU를 줘도 소용없습니다.
FCFS · SJF/SRTF · Round Robin · Priority(+Aging) Preemptive vs Cooperative Time Slice Trade-off ↔ Context Switch
CPU/I-O Bound · 멀티코어 · Affinity · NUMA
CPU Bound는 계산이 길고, I/O Bound는 짧은 CPU Burst 뒤 대부분 기다립니다. I/O 대기 중 다른 Thread가 Core를 쓸 수 있습니다. 멀티코어에서는 Core마다 작업을 배치하고, 한쪽에만 몰리면 Scheduler가 Thread를 옮겨 Load Balancing합니다. Migration은 Cache Locality를 깨뜨릴 수 있어 CPU Affinity와 Trade-off입니다. NUMA·SMT(Hyper-Threading)·Performance/Efficiency Core까지 Topology를 고려하는 현대 Scheduler도 있습니다. Linux·Windows 모두 단순 Round Robin만 쓰지 않습니다.
Event Loop · Queue · 서버 지표
OS Scheduler와 Event Loop·Job Queue Scheduler는 계층이 다릅니다. 다만 「다음에 무엇을 실행할까」라는 질문은 같습니다. JS의 긴 Task는 Cooperative에 가깝고 Long Task로 체감됩니다. Worker·Request Queue의 FIFO·Priority·Fair Queueing도 같은 원리입니다. Runnable이 과도하면 Run Queue·Waiting·Context Switch가 늘고 Latency가 나빠집니다. CPU 100%가 Batch에서는 정상일 수 있고, Web API에서는 Capacity 부족 신호일 수 있습니다. Core만 늘려도 공유 Lock이 병목이면 Resource Contention이 커질 수 있습니다. Deadlock은 Scheduling만으로 풀리지 않습니다. 서버 모니터링에서는 Utilization·Run Queue·Context Switch·p95/p99를 함께 봅니다.
초보 FAQ
Ready Queue란?
실행 준비는 됐지만 아직 CPU를 못 받은 Thread가 기다리는 Queue입니다.
홈페이지에서 Algorithm을 바꿔야 하나?
대부분 기본 OS Scheduler면 충분합니다. Thread·Worker를 과도하게 늘리지 않는 쪽이 더 중요합니다.
SEO와 직접 관련?
SEO 전용 개념은 아닙니다. CPU 포화로 응답이 크게 느려지면 사용자 경험에 간접 영향이 있을 수 있습니다.
정리
CPU Scheduling = 제한된 CPU를 여러 Process·Thread가 나눠 쓰도록 실행 순서를 정하는 과정입니다. Ready에서 골라 Running으로 돌리고, Waiting은 건너뛰며, Preempt·Time Slice·Priority·Fairness·Topology를 저울질합니다. Runnable이 지나치게 많으면 Run Queue·Context Switch·Latency가 늘 수 있어, CPU 사용률만 보지 말고 「CPU를 기다리는 작업이 얼마나 많은지」도 봅니다. 서버 상태를 볼 때 Utilization과 함께 Load Average 같은 숫자도 자주 만납니다. 예를 들어 `1.20, 3.50, 8.10`처럼 보이며, 단순 CPU %와는 다른 의미로 일정 시간 동안 실행 중이거나 실행 기회를 기다리는 시스템 부하를 읽는 단서가 됩니다. 이 지표를 Load Average(로드 애버리지)라고 합니다.