170. 스케줄링 기준 (Scheduling Criteria) - CPU 이용률, 처리량, 반환시간, 대기시간, 응답시간

핵심 인사이트 (3줄 요약)

본질: 스케줄링 기준 (Scheduling Criteria)은 운영체제 (Operating System, OS)가 CPU (Central Processing Unit) 시간을 잘 배분하고 있는지 평가하는 공통 성능 지표 집합이다.

가치: CPU 이용률, 처리량, 반환 시간, 대기 시간, 응답 시간은 각각 시스템 효율과 사용자 체감 품질을 다른 각도에서 측정하므로, 알고리즘의 우열을 맥락에 맞게 판단하게 해 준다.

판단 포인트: 배치 시스템은 처리량과 반환 시간을, 대화형 시스템은 응답 시간을, 실시간 시스템은 최악 지연과 데드라인을 더 중시하므로 한 가지 기준만 높다고 좋은 스케줄러라고 할 수는 없다.

Ⅰ. 개요 및 필요성

스케줄링 기준은 여러 프로세스와 스레드가 CPU를 경쟁할 때 "무엇을 잘했다고 볼 것인가"를 정하는 채점표다. 같은 스케줄링 알고리즘이라도 어떤 시스템에서는 훌륭하고, 다른 시스템에서는 최악일 수 있다. 그래서 FCFS (First-Come, First-Served), SJF (Shortest Job First), RR (Round Robin), MLFQ (Multilevel Feedback Queue) 같은 알고리즘은 언제나 기준과 함께 평가해야 한다.

이 개념이 필요한 이유는 스케줄링이 본질적으로 트레이드오프이기 때문이다. 타임 퀀텀 (Time Quantum)을 짧게 하면 화면 반응은 좋아질 수 있지만, 문맥 교환 오버헤드 때문에 CPU 이용률과 처리량이 떨어질 수 있다. 반대로 한 작업을 오래 붙잡고 가면 처리량은 좋아져도 사용자는 시스템이 굳었다고 느낄 수 있다. 결국 스케줄러의 목표를 수치로 명확히 정하지 않으면 "빠르다"와 "효율적이다"가 서로 다른 뜻으로 섞이게 된다.

아래 그림은 스케줄링 기준이 왜 크게 두 관점으로 나뉘는지 보여준다.

┌──────────────────────────────────────────────────────────────┐
│         스케줄링 평가는 두 개의 질문으로 요약된다            │
├────────────────────────────┬─────────────────────────────────┤
│ 시스템 입장                │ 사용자 입장                    │
│ CPU를 얼마나 놀리지 않는가 │ 내가 얼마나 빨리 결과를 받는가 │
│ → CPU 이용률, 처리량       │ → 반환/대기/응답 시간          │
├────────────────────────────┼─────────────────────────────────┤
│ 자원 효율, 총량            │ 체감 속도, 공정성, 즉시성      │
└────────────────────────────┴─────────────────────────────────┘

초기 메인프레임 시대에는 비싼 CPU를 놀리지 않는 것이 가장 중요한 목표였기 때문에 CPU 이용률과 처리량이 중심 지표였다. 그러나 시분할, 데스크톱, 웹, 모바일 환경으로 넘어오면서 "얼마나 빨리 첫 반응을 주는가"가 훨씬 중요해졌다. 스케줄링 기준은 이렇게 하드웨어 중심 효율에서 사용자 경험 중심 평가로 확장돼 왔다.

📢 섹션 요약 비유: 스케줄링 기준은 식당 평가표와 같다. 주인은 하루에 몇 그릇을 팔았는지 보고 싶어 하고, 손님은 주문 후 얼마나 빨리 물과 음식이 나오는지 본다. 어느 쪽만 봐서는 식당 전체 품질을 알 수 없다.

Ⅱ. 아키텍처 및 핵심 원리

다섯 가지 대표 기준은 각각 측정 시점과 의미가 다르다. CPU 이용률과 처리량은 시스템 전체가 자원을 얼마나 효율적으로 쓰는지 본다. 반면 반환 시간, 대기 시간, 응답 시간은 개별 작업이 어떤 경험을 겪는지 측정한다. 같은 프로세스라도 "처음 반응"과 "완전히 끝나는 시점"은 서로 다르기 때문에 이 구분이 매우 중요하다.

아래 시간축은 다섯 기준이 프로세스 생애주기의 어느 구간을 보는지 보여준다.

┌──────────────────────────────────────────────────────────────┐
│            프로세스 시간축에서 보는 스케줄링 기준            │
├──────────────────────────────────────────────────────────────┤
│ 도착            첫 실행                            완료       │
│  │                │                                 │         │
│  ▼                ▼                                 ▼         │
│ [Ready]─wait1─[Run]─I/O─[Ready]─wait2─[Run]───────────────▶  │
│   <──── response time ────>                                │
│   <──────────── turnaround time ────────────>              │
│ waiting time = wait1 + wait2                               │
└──────────────────────────────────────────────────────────────┘

이 그림에서 응답 시간 (Response Time)은 도착 후 첫 CPU 할당까지의 시간이고, 반환 시간 (Turnaround Time)은 도착부터 완료까지의 전체 시간이다. 대기 시간 (Waiting Time)은 오직 준비 큐에서 기다린 시간만 더한 값이므로 스케줄러 자체의 성능을 비교하기에 특히 유용하다. CPU 이용률 (CPU Utilization)은 busy time / total time, 처리량 (Throughput)은 완료된 작업 수 / 단위 시간으로 계산한다.

기준	의미	목표 방향	주로 중시하는 환경
CPU 이용률	CPU가 유휴하지 않고 일한 비율	최대화	서버, 배치, 자원 효율 중심 시스템
처리량	단위 시간당 완료된 작업 수	최대화	트랜잭션 처리, 배치 작업
반환 시간	도착부터 완료까지 총 소요 시간	최소화	배치, 일괄 처리, 빌드/렌더링
대기 시간	Ready Queue에서 기다린 총 시간	최소화	알고리즘 순수 비교, 공정성 평가
응답 시간	도착부터 첫 반응까지 시간	최소화	대화형 UI, 웹, 시분할 시스템

핵심은 이 다섯 기준이 서로 독립적이지 않다는 점이다. 작은 타임 퀀텀은 응답 시간을 줄일 수 있지만, 디스패치 지연 (Dispatch Latency)과 문맥 교환 횟수를 늘려 처리량을 떨어뜨릴 수 있다. 반대로 CPU를 한 작업에 오래 주면 처리량이 좋을 수 있지만, 뒤 작업들의 대기 시간과 응답 시간은 악화될 수 있다.

📢 섹션 요약 비유: 병원 접수에 비유하면 응답 시간은 번호표를 뽑고 간호사가 이름을 불러 주기까지의 시간이고, 반환 시간은 진료를 끝내고 집에 돌아갈 때까지의 전체 시간이다. 둘은 비슷해 보이지만 환자가 느끼는 의미는 크게 다르다.

Ⅲ. 비교 및 연결

스케줄링 기준을 비교할 때 가장 먼저 봐야 할 것은 시스템 중심 지표와 사용자 중심 지표의 긴장 관계다. CPU 이용률과 처리량은 시스템 전체 관점에서 효율을 높여 주지만, 사용자는 평균 처리량보다 자신의 작업이 언제 반응하는지에 더 민감하다. 그래서 데스크톱과 웹 서비스에서는 응답 시간이 조금만 흔들려도 전체 시스템이 느리다고 느끼기 쉽다.

비교 축	가까운 지표	차이점
CPU 이용률 vs 처리량	둘 다 시스템 효율 지표	이용률은 바쁘게 일한 비율, 처리량은 실제 완료 개수
반환 시간 vs 응답 시간	둘 다 사용자 체감 지표	반환은 끝날 때까지, 응답은 첫 반응까지만 측정
대기 시간 vs 응답 시간	둘 다 지연을 본다	대기는 모든 Ready Queue 체류 합, 응답은 첫 대기만 측정

또 다른 중요한 비교는 평균값과 꼬리 지연 (Tail Latency)이다. 평균 응답 시간이 짧아도 일부 요청이 길게 밀리면 사용자는 시스템을 불안정하다고 느낀다. 일반 목적 OS에서는 평균값이 자주 쓰이지만, 실시간 시스템에서는 평균보다 최악 응답 시간과 데드라인 미스율이 더 중요하다. 즉 같은 "빠름"이라도 대화형 시스템과 실시간 시스템의 빠름은 뜻이 다르다.

이 기준들은 CPU 바운드 작업과 I/O 바운드 작업의 비중에 따라서도 해석이 달라진다. I/O 바운드 작업이 많을수록 짧은 응답 시간과 빠른 재디스패치가 중요하고, CPU 바운드 작업이 많을수록 처리량과 공정한 배분이 중요해진다. 그래서 현대 스케줄러는 한 지표만 극단적으로 최적화하기보다, 워크로드 성격에 맞는 균형점을 찾는 방향으로 발전한다.

📢 섹션 요약 비유: 놀이공원 운영에서 회전율만 높이면 놀이기구는 많이 태우지만 손님은 오래 기다렸다고 느낄 수 있다. 반대로 줄을 너무 자주 끊어 모두에게 조금씩만 태우면 체감 공정성은 좋아지지만 전체 운영 효율은 떨어질 수 있다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 먼저 "우리 시스템의 대표 성공 기준이 무엇인가"를 정해야 한다. 사용자와 직접 상호작용하는 서비스라면 응답 시간, 특히 평균이 아니라 p95·p99 같은 상위 백분위 지연이 중요하다. 배치 작업이라면 처리량과 반환 시간이 핵심이며, 경성 실시간 시스템이라면 다섯 기준보다 데드라인 준수율이 우선이다.

┌──────────────────────────────────────────────────────────────┐
│              시스템 목적에 따른 우선 지표 선택               │
├──────────────────────────────────────────────────────────────┤
│ 대화형 UI / 웹 API      -> 응답 시간, tail latency 우선      │
│ 배치 / 분석 / 렌더링    -> 처리량, 반환 시간 우선            │
│ 혼합 서버               -> 작업 등급 분리 후 균형 조정       │
│ 경성 실시간 제어        -> 최악 지연, deadline miss 우선     │
└──────────────────────────────────────────────────────────────┘

예를 들어 모바일 앱 백엔드에서 평균 CPU 이용률이 60%라 해도 p99 응답 시간이 800ms로 튀면 사용자는 느리다고 느낀다. 이 경우 CPU 이용률을 더 높이는 것이 아니라, 인터랙티브 요청의 응답 시간을 줄이는 쪽으로 스케줄링과 큐 분리 정책을 조정해야 한다. 반대로 야간 배치 시스템은 첫 반응이 조금 늦어도 전체 완료 시간이 짧고 처리량이 높으면 더 좋은 결과가 될 수 있다.

체크리스트

핵심 성공 기준이 평균 처리량인가, 평균 응답 시간인가, 최악 지연 보장인가?
같은 정책으로 모든 작업을 처리하고 있지는 않은가?
타임 퀀텀, 우선순위, 문맥 교환 비용이 지표에 미치는 영향을 함께 측정하고 있는가?
평균값뿐 아니라 p95·p99 또는 worst-case를 같이 보고 있는가?

안티패턴

CPU 이용률을 100%에 가깝게 만드는 것만 좋은 튜닝이라고 믿는 것
평균 응답 시간만 보고 긴 지연 스파이크를 무시하는 것
대화형 작업과 배치 작업을 같은 큐와 같은 우선순위로 섞어 두는 것
📢 섹션 요약 비유: 스케줄링 튜닝은 자동차 계기판에서 연비만 보고 운전하는 것과 같다. 연비가 좋아도 브레이크 반응이 느리면 위험하고, 반응만 빠르다고 짐을 하나도 못 싣는 차도 목적에 맞지 않는다. 무엇을 위해 달리는 차인지 먼저 정해야 한다.

Ⅴ. 기대효과 및 결론

스케줄링 기준을 명확히 세우면 알고리즘 선택과 파라미터 조정이 훨씬 구체적인 엔지니어링 작업이 된다. "느리다"라는 막연한 불만을 응답 시간, 대기 시간, 처리량 같은 수치로 바꿀 수 있고, 어떤 튜닝이 실제 목표를 개선했는지도 검증할 수 있다. 이는 운영체제 설계뿐 아니라 서비스 운영과 성능 분석에도 그대로 적용된다.

다만 이 기준들은 만능 정답이 아니다. CPU 이용률과 처리량은 시스템 전체의 생산성을 보여 주지만, 사용자가 느끼는 품질과 일치하지 않을 수 있다. 반대로 응답 시간만 좇으면 문맥 교환이 늘고 전체 효율이 떨어질 수 있다. 결국 스케줄링 기준은 알고리즘을 맹목적으로 고르는 체크박스가 아니라, 시스템 목적에 맞는 균형점을 찾기 위한 좌표축이다.

따라서 이 주제는 "어떤 스케줄러가 최고인가"가 아니라 "무엇을 최고로 볼 것인가"라는 질문으로 기억하는 편이 정확하다. 스케줄러는 목적을 수행하는 도구이고, 스케줄링 기준은 그 도구가 잘 작동하는지 판단하는 기준선이다.

📢 섹션 요약 비유: 스케줄링 기준은 스포츠 경기의 기록표와 같다. 축구에서 골 수가 중요하다고 해서 농구도 골대 하나만 세면 안 되듯이, 시스템도 종목에 맞는 점수판을 먼저 정해야 제대로 평가할 수 있다.

📌 관련 개념 맵

개념	연결 포인트
CPU 이용률	자원 활용 효율을 보여 주는 시스템 중심 지표
처리량	완료된 작업 수로 본 생산성 지표
반환 시간	배치 작업 완료 속도를 해석하는 핵심 지표
대기 시간	Ready Queue 체류 시간으로 스케줄러 자체를 비교하기 좋은 지표
응답 시간	대화형 시스템의 체감 성능을 대표하는 지표
디스패치 지연	응답 시간과 문맥 교환 효율에 직접 영향을 주는 전환 비용
타임 퀀텀	응답성과 처리량 사이 균형을 좌우하는 파라미터

📈 관련 키워드 및 발전 흐름도

워크로드 성격 파악
    │
    ▼
주요 평가 기준 선택
    │
    ├──────────────▶ CPU 이용률 · 처리량
    ├──────────────▶ 반환 시간 · 대기 시간
    ├──────────────▶ 응답 시간 · tail latency
    ▼
스케줄링 알고리즘 및 파라미터 결정

이 흐름도는 스케줄링 기준이 단순 설명 항목이 아니라, 워크로드 분석에서 알고리즘 선택과 모니터링까지 이어지는 실무 의사결정의 출발점임을 보여준다.

👶 어린이를 위한 3줄 비유 설명

놀이터에서 친구들이 그네를 탈 때는 "많이 태웠는지", "얼마나 오래 기다렸는지", "금방 차례가 왔는지"를 다 볼 수 있어요.
컴퓨터도 여러 일이 차례를 기다리기 때문에 이런 기준으로 일을 얼마나 잘 나눠 줬는지 확인해요.
그래서 어떤 컴퓨터는 빨리 반응하는 것을, 어떤 컴퓨터는 많은 일을 끝내는 것을 더 중요하게 생각한답니다.