전산학에서 CPU 스케줄링 기초: 여러 작업을 공정하고 빠르게 처리하는 운영체제의 전략

전산학에서 컴퓨터가 “버벅인다”는 말은 종종 CPU 스케줄링 문제로 설명된다

컴퓨터에서 프로그램을 여러 개 켜고 작업하다 보면, 어떤 순간에는 마우스가 끊기고 화면이 멈춘 듯 느껴지기도 한다. 반대로 사양이 낮은 기기에서도 의외로 여러 작업이 동시에 돌아가며 “생각보다 괜찮다”는 느낌이 들 때도 있다. 이런 체감 차이에는 CPU 성능뿐 아니라 CPU 스케줄링(CPU scheduling)이라는 운영체제의 전략이 깊게 관여한다.
CPU는 한 순간에 하나의 코어에서 하나의 작업만 실행할 수 있다. 그럼에도 사용자가 “동시에” 여러 프로그램을 쓰는 것처럼 느끼는 이유는 운영체제가 CPU 시간을 잘게 나눠 각 작업에 배분하기 때문이다. 이 배분 규칙이 바로 CPU 스케줄링이다.
이 글은 CPU 스케줄링, 프로세스(process), 스레드(thread), 컨텍스트 스위칭(context switching), 타임 슬라이스(time slice), 우선순위(priority)라는 핵심 키워드를 중심으로, 스케줄링이 무엇이고 왜 필요한지, 어떤 방식들이 있으며 실제 성능 체감과 어떤 연결이 있는지까지 입문자 관점에서 정리한다.

 

전산학에서 CPU 스케줄링의 개념, 기본 원리, 관련 용어 정리

1) CPU는 “일꾼”, 운영체제는 “현장 관리자”다

CPU를 작업 현장의 일꾼이라고 보면, 운영체제는 작업을 배정하는 관리자다. 관리자는 한 명의 일꾼에게 한 가지 일만 시키는 것이 아니라, 여러 업무를 순서대로 시키며 전체 성과를 최적화하려고 한다.
컴퓨터에서 그 역할을 하는 것이 운영체제(OS)이며, 운영체제 내부에는 스케줄러(scheduler)가 있다. 스케줄러는 “지금 CPU를 누구에게 줄 것인가”를 정하는 규칙을 실행한다. 이 규칙이 CPU 스케줄링이다.

2) 프로세스와 스레드: 스케줄링의 대상이 무엇인지부터 정리한다

CPU 스케줄링을 이해하려면 먼저 “무엇을 번갈아 실행하는가”를 알아야 한다.

• 프로세스(process): 실행 중인 프로그램의 인스턴스다. 웹브라우저를 실행하면 하나 이상의 프로세스가 생긴다.
• 스레드(thread): 프로세스 안에서 실제로 CPU에서 실행되는 작업 흐름이다. 한 프로세스는 여러 스레드를 가질 수 있다.

운영체제는 보통 스레드를 더 직접적인 실행 단위로 다룬다. 다만 입문자 관점에서는 “여러 실행 단위가 CPU를 나눠 쓴다”라고 이해하면 충분하다.

3) 준비 상태(Ready)와 실행 상태(Running): CPU를 받기 위한 줄서기다

스케줄링은 CPU를 필요로 하는 작업들이 “대기 줄”에 들어와 있는 상태에서 시작된다. 실행 단위는 보통 다음 상태를 오간다.

• Running(실행): 지금 CPU를 실제로 받고 실행 중이다.
• Ready(준비): CPU만 받으면 바로 실행 가능한데, 차례를 기다리는 상태다.
• Blocked/Waiting(대기): 디스크 읽기, 네트워크 응답, 사용자 입력 등을 기다리는 상태다.

CPU를 아무리 잘 배정해도, 작업이 네트워크나 디스크를 기다리느라 멈춰 있으면 속도가 느려질 수 있다. 따라서 “버벅임”은 CPU 스케줄링 문제일 수도 있지만, I/O 대기 문제가 원인일 수도 있다.

4) 컨텍스트 스위칭: 작업을 바꿀 때 드는 ‘교대 비용’이다

CPU가 A 작업을 하다가 B 작업으로 넘어가려면, A의 실행 상태(레지스터 값, 프로그램 카운터 등)를 저장하고 B의 상태를 복원해야 한다. 이 과정이 컨텍스트 스위칭(context switching)이다.
컨텍스트 스위칭은 필수지만 비용이 있다. 너무 자주 교대하면 “일을 하는 시간”보다 “교대하는 시간”이 늘어 성능이 떨어질 수 있다. 따라서 스케줄링은 공정성과 반응성을 챙기면서도 교대 비용을 과도하게 만들지 않도록 균형을 잡아야 한다.

5) 타임 슬라이스: CPU 시간을 쪼개서 나누어 주는 단위다

대부분의 데스크톱/서버 운영체제는 선점형(preemptive) 스케줄링을 쓴다. 선점형이란, 운영체제가 일정 시간이 지나면 강제로 CPU를 회수해 다른 작업에게 넘길 수 있다는 뜻이다. 이때 사용하는 시간이 타임 슬라이스(time slice) 또는 퀀텀(quantum)이다.
타임 슬라이스가 너무 길면 한 작업이 오래 CPU를 붙잡아 다른 작업의 반응이 느려진다. 반대로 너무 짧으면 컨텍스트 스위칭이 늘어나 전체 효율이 떨어진다. 결국 스케줄러는 “사용자가 체감하는 응답성”과 “전체 처리량” 사이에서 적절한 지점을 찾는다.

 

CPU 스케줄링의 기본 그림(Ready 큐→CPU 실행→타임 슬라이스 종료→다음 작업)

 

 

전산학에서 대표 스케줄링 방식과 실제 체감 성능에 미치는 영향

1) 스케줄링의 목표: 공정성, 빠른 응답, 높은 처리량, 예측 가능성이다

CPU 스케줄링은 단일 목표가 아니다. 환경에 따라 최적의 전략이 다르다. 대표 목표는 다음과 같다.

• 응답 시간(response time): 사용자가 클릭했을 때 빨리 반응하는가
• 처리량(throughput): 일정 시간 동안 얼마나 많은 일을 처리하는가
• 공정성(fairness): 특정 작업이 계속 밀려 굶지 않는가(starvation 방지)
• 대기 시간(waiting time): 준비 큐에서 기다리는 시간이 짧은가
• 예측 가능성(predictability): 처리 시간이 일정하고 안정적인가(특히 실시간 시스템)

일반 PC는 응답성이 중요하고, 서버는 처리량과 안정성이 중요하며, 실시간 시스템은 예측 가능성이 중요하다. 그래서 스케줄링 전략도 환경에 따라 다르게 선택된다.

2) FCFS: 먼저 온 작업을 먼저 처리하는 가장 단순한 방식이다

FCFS(First Come, First Served)는 먼저 준비 큐에 들어온 작업을 먼저 실행한다. 이해하기 쉽고 구현도 단순하다.
하지만 단점이 명확하다. 긴 작업 하나가 앞에 있으면 뒤의 짧은 작업들이 오래 기다리게 된다. 이를 컨보이 효과(convoy effect)라고 부르기도 한다. 사용자 입장에서는 “가벼운 작업도 느려졌다”로 체감된다.

3) SJF: 짧은 작업을 먼저 처리해 평균 대기 시간을 줄인다

SJF(Shortest Job First)는 예상 실행 시간이 짧은 작업을 먼저 처리한다. 평균 대기 시간을 줄이는 데 유리하다.
문제는 “작업 시간이 얼마나 걸릴지”를 정확히 알기 어렵다는 점과, 짧은 작업이 계속 들어오면 긴 작업이 계속 밀릴 수 있다는 점이다(기아 상태). 그래서 현실에서는 보완 장치가 필요하다.

4) 라운드 로빈(Round Robin): 타임 슬라이스로 공정하게 돌아가며 실행한다

라운드 로빈(RR)은 준비 큐에 있는 작업들에게 타임 슬라이스만큼씩 CPU를 돌려주는 방식이다. 사용자가 여러 프로그램을 동시에 쓰는 환경에서 공정성과 응답성을 확보하기 좋다.
다만 타임 슬라이스가 너무 짧으면 컨텍스트 스위칭이 잦아지고, 너무 길면 특정 작업이 오래 CPU를 점유해 응답성이 떨어진다. 라운드 로빈의 성능은 타임 슬라이스 설정에 크게 영향을 받는다.

5) 우선순위 스케줄링: 중요한 일을 먼저 처리한다

우선순위(priority) 스케줄링은 우선순위가 높은 작업을 먼저 실행한다. 운영체제는 “사용자가 지금 보고 있는 창”, “오디오 재생”, “입력 처리” 같은 작업에 더 높은 우선순위를 부여해 체감 성능을 개선할 수 있다.
하지만 우선순위만 믿으면 문제가 생긴다. 낮은 우선순위 작업이 계속 밀려 실행되지 않는 기아 상태가 발생할 수 있다. 이를 완화하기 위해 많은 시스템은 에이징(aging) 같은 기법을 사용해 오래 기다린 작업의 우선순위를 서서히 올린다.

6) 멀티레벨 피드백 큐(MLFQ): 현실에서 자주 쓰이는 “적응형” 전략이다

현대 운영체제는 단일 알고리즘만 쓰기보다, 여러 큐와 정책을 결합해 상황에 맞게 조정한다. 대표적인 아이디어가 멀티레벨 피드백 큐(MLFQ)다.
개념은 다음과 같다.

• 짧게 CPU를 쓰고 자주 양보하는 작업(대화형 작업)은 높은 우선순위 큐에서 자주 실행한다.
• 오래 CPU를 점유하는 작업(배치 작업)은 낮은 우선순위 큐로 내려 보내 처리한다.
• 작업의 행동을 관찰해 큐를 이동시키므로 “추정”이 아니라 “피드백”으로 조정한다.

이 방식은 웹브라우징, 문서 작업처럼 사용자 입력이 많은 환경에서 체감 성능을 높이는 데 유리하다. 사용자는 “클릭했을 때 바로 반응한다”를 느끼게 된다.

 

스케줄링 방식별 특징 비교(응답성·처리량·공정성·기아 위험)

 

7) 실제 문제 해결: “버벅임”을 스케줄링 관점에서 점검하는 순서

일반 사용자가 체감하는 느려짐은 CPU 스케줄링뿐 아니라 메모리 부족, 디스크, 네트워크 등 여러 원인이 섞일 수 있다. 그럼에도 스케줄링 관점에서 도움이 되는 점검 흐름은 다음과 같다.

1. CPU 사용률이 지속적으로 90~100%인지 확인한다.
2. 특정 프로그램이 CPU를 독점하는지 확인한다(백그라운드 업데이트, 브라우저 탭 등).
3. 동시에 실행 중인 무거운 작업(압축, 영상 인코딩, 백신 검사)을 줄여 Ready 큐 경쟁을 낮춘다.
4. “응답성”이 필요한 작업(화상회의, 오디오)은 다른 무거운 작업과 동시에 하지 않는다.
5. 멀티코어 환경에서도 특정 작업이 단일 코어를 과도하게 점유할 수 있음을 이해한다(스레드 구조 문제).

이 흐름은 사용자가 “왜 지금 느린지”를 감으로 추측하지 않고, 상황을 분해해 보는 데 도움이 된다.

 

전산학에서 CPU 스케줄링은 ‘공정하게’와 ‘빠르게’를 동시에 만족시키려는 운영체제의 전략이다

CPU 스케줄링은 여러 프로세스와 스레드가 CPU를 공유하는 환경에서, 제한된 CPU 시간을 어떻게 배분할지 결정하는 운영체제의 핵심 기능이다. 타임 슬라이스와 컨텍스트 스위칭을 통해 사용자는 동시에 여러 프로그램을 쓰는 것처럼 느끼며, 라운드 로빈, 우선순위, MLFQ 같은 전략은 응답성과 처리량, 공정성 사이의 균형을 맞추기 위해 사용된다. 결국 체감 성능은 CPU 성능만이 아니라, 운영체제가 작업을 어떤 규칙으로 배치하느냐에도 크게 좌우된다.