앞선 글에서 프로세스와 스레드가 어떻게 운영체제에서 관리되는지 살펴봤다.
여러 작업이 동시에 돌아가는 상황에서,
운영체제는 “누구에게, 언제, 어떻게 CPU 사용 기회를 줄 것인가?”라는
복잡하고 중요한 결정을 내려야 한다.
만약 이 선택이 효율적이지 못하다면, 어떤 작업은 지나치게 오래 기다리거나 시스템 전체의 응답성이 떨어질 수 있다.
이번 글에서는,
이런 현실적인 문제와 한계를 해결하기 위해 운영체제가 어떤 기준과 원리로
각 작업의 CPU 사용 순서를 정하는지,
CPU의 선택 기준을 결정짓는 스케줄링 전략에 대해 다뤄보고자 한다.
운영체제에서 스케줄러(Scheduler)는 여러 프로세스 중 어떤 것을 실행할지 결정하는 역할을 한다. 효율적 자원 관리와 시스템의 성능 향상에 매우 중요하다.
운영체제에서의 프로세스 상태 전이와도 밀접한 관련이 있다.
앞서 다룬 프로세스의 5가지 상태(생성, 준비, 실행, 대기, 종료, 보류 등)에서
각 스케줄러가 어느 단계에 관여하는지 예시로 보면 더욱 쉽게 이해할 수 있다.
역할: 보조 기억장치(디스크)에 있는 작업 중 어떤 작업을 메모리(주기억장치)에 올릴지 결정한다.
프로세스가 생성된 후,
→ 작업 큐(NEW 상태)에 있던 프로세스가
→ 준비 상태(Ready Queue)로 진입할 때
→ 장기 스케줄러가 개입하여 "입장관리자" 역할을 한다.
특징: 실행 빈도가 낮고, 시스템 전체의 작업 부하 조절 역할
역할: 준비 상태(Ready Queue)에 있는 프로세스 중에서 CPU에 할당할 프로세스를 선택한다.
프로세스가 준비 상태(Ready)에서
→ 실행 상태(Running)로 전환될 때
→ 단기 스케줄러가 개입하여 실제 CPU에 올라갈 프로세스를 결정한다.
특징: 실행 빈도가 매우 높으며, 컨텍스트 스위칭(문맥교환)마다 동작
역할: 실행/대기 중인 프로세스 중 일부를 메모리에서 디스크로 내보내거나(swap-out), 다시 불러옴(swap-in)
예를 들어 입출력 대기(Waiting) 상태나,
시스템에 메모리가 부족할 때
→ 중기 스케줄러가 프로세스를 "보류(Suspended)" 상태로 전환해
일시적으로 메모리에서 내보내고, 필요할 때 다시 메모리에 불러오는 역할을 한다.
특징: 시스템 메모리 부하 조절, 프로세스 상태 전환(ready ↔ suspended) 담당
컴퓨터에서 동시에 실행되는 여러 프로세스(혹은 스레드)들이
모두 한 번에 CPU를 사용할 수는 없다.
따라서 운영체제는 한정된 CPU 자원을 각 작업에 어떻게, 언제, 누구에게 배분할지
지속적으로 판단하고 결정해야 한다.
이처럼 CPU라는 가장 중요한 자원을 여러 작업에게 효율적으로 나누어주는 작업을
바로 CPU 스케줄링(CPU Scheduling)이라고 한다.
CPU 스케줄링은 시스템 전체의 성능, 각 작업의 응답 속도,
자원의 효율적 분배 등 운영체제의 전반적인 품질에 직접적으로 영향을 미치는
핵심 기능 중 하나다.
CPU 스케줄링은 아래와 같은 목표를 달성하기 위해 실행된다.
여러 프로세스가 CPU를 두고 경쟁하는 환경에서는, 작업의 순서뿐만 아니라,
CPU를 할당받은 작업을 얼마나 오랫동안 실행하냐? 또한 하나의 문제다.
이때 운영체제는 CPU 사용권을 프로세스에게 어떻게, 언제까지 맡길지에 따라 크게
두가지 방식의 스케줄링 전략을 사용한다.
선점형(Preemptive):
비선점형(Non-Preemptive):
운영체제에서 프로세스의 성격을 구분할 때,
CPU 집중 프로세스와 입출력(I/O) 집중 프로세스로 나누기도 한다.
CPU 집중 프로세스
입출력 집중 프로세스
운영체제는 모든 프로세스에게 동등한 조건으로 CPU를 배분하지 않는다.
CPU 스케줄링 시 각 프로세서의 중요도나 성격에 따라 우선순위를 부여한다.
우선순위 배정 방식
준비 큐 vs 대기 큐 차이
준비 큐: 한 번에 하나의 프로세스만 꺼내서 CPU를 할당
대기 큐: 여러 프로세스의 입출력이 동시에 끝나면(여러 인터럽트 발생 시),
관련된 여러 프로세스가 한꺼번에 준비 상태로 이동
시스템에는 여러 입출력 장치가 있어, 입출력이 동시에 완료되면 인터럽트 벡터를 통해
완료된 모든 프로세스 제어 블록을 준비 상태로 옮긴다.
CPU 스케줄링 알고리즘을 선택할 때 운영체제는 여러 가지 현실적인 기준을 종합적으로 고려한다.
대표적인 선택 기준은 다음과 같다.
CPU 이용률(Throughput):
단위 시간 동안 처리된 프로세스의 수를 의미.
(값이 높을수록 시스템이 많은 작업을 효율적으로 처리하고 있다는 뜻)
평균 대기 시간(Average Waiting Time):
각 프로세스가 준비 큐에서 실행을 기다린 평균 시간.
(짧을수록 사용자 입장에서 쾌적하다)
반환 시간(Turnaround Time):
프로세스가 시스템에 들어온 시점부터 완전히 끝나는 시점까지 걸린 총 시간.
(사용자/작업의 전체 처리 효율을 평가하는 지표)
응답 시간(Response Time):
사용자 입력(명령) 이후, 시스템이 첫 반응을 보일 때까지 걸린 시간.
(대화형 시스템, 실시간 시스템에서 특히 중요)
공정성(Fairness):
모든 프로세스(사용자)가 합리적으로 CPU 사용 기회를 갖는지 여부.
(특정 작업이 계속 무시되거나, 기아(Starvation)가 발생하지 않게끔 설계)
시스템 특성/요구사항:
예를 들어 실시간 시스템은 빠른 응답이,
대용량 배치 시스템은 전체 처리량이 더 중요할 수 있다.
원리:
응답률 = (대기시간 + 실행시간) / 실행시간
이 값이 가장 높은 프로세스부터 실행
장점:
짧은 작업이 빨리 끝나면서도,
오래 기다린 작업의 우선순위도 자동으로 올라가
기아(Starvation)를 방지할 수 있다.
적용:
다양한 작업이 섞인 환경에서 공정성과 효율성을 동시에 추구
프로세스 | 대기 시간 (W) | 실행 시간 (S) | 응답률 (R) |
---|---|---|---|
P1 | 2 | 4 | (2 + 4) / 4 = 1.5 |
P2 | 4 | 3 | (4 + 3) / 3 = 2.33 |
P3 | 1 | 2 | (1 + 2) / 2 = 1.5 |
실제 운영체제에서는 이들 알고리즘을 조합하거나,
상황에 따라 동적으로 전환하며 시스템 목적(효율/응답/공정성 등)에 최적화합니다.
실제 운영체제에는 다양한 유형의 프로세스(대화형/배치/시스템/실시간 등)가 동시에 존재합니다.
각 유형의 프로세스는 요구하는 서비스 특성이 다르고,
한 가지 스케줄링 알고리즘만으로는 모든 요구를 충족하기 어렵습니다.
다단계 큐(MLQ, Multi-Level Queue) 스케줄링은
이런 현실적인 문제를 해결하기 위한 방식입니다.
동작 원리:
예시:
1번 큐: 실시간 작업(RR, 빠른 응답 보장)
2번 큐: 대화형 프로그램(짧은 타임슬라이스 RR)
3번 큐: 배치 작업(FCFS, 긴 작업도 차례로 처리)
특징:
장점:
단점:
다단계 피드백 큐(MLFQ, Multi-Level Feedback Queue)는
다단계 큐의 한계(큐 간 이동 불가, 고정 우선순위 등)를 극복하기 위해
큐 간 이동과 동적 우선순위를 도입한 더욱 “현대적”인 스케줄링 기법입니다.
동작 원리:
타임퀀텀(Quantum) 특징:
장점:
단점:
예시:
MLQ vs MLFQ 요약 비교
MLQ(다단계 큐) | MLFQ(다단계 피드백 큐) | |
---|---|---|
큐간 이동 | X(불가, 고정 큐) | O(상하위 큐 이동 가능) |
우선순위 | 고정 | 동적(작업 성격에 따라 변화) |
목적 | 유형별 분리, 효율화 | 응답성 + 공정성 + 효율성 |
대표적 적용 | 제한적/과거 OS | 현대 OS(윈도우, 리눅스 등) |