스케줄링 기준 (Scheduling Criteria)

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

본질: 스케줄링 기준 (Scheduling Criteria)은 CPU 스케줄링 알고리즘들이 시스템 자원을 얼마나 '잘' 분배하고 있는지를 평가하기 위한 정량적·정성적 척도 및 성능 지표 모음이다.

가치: 특정 스케줄러가 절대적으로 완벽할 수는 없으므로(예: 응답성을 높이면 처리량이 감소), 이 지표들을 통해 시스템의 성격(서버, 데스크톱, 실시간 등)에 맞는 최적의 트레이드오프(Trade-off) 지점을 선택할 수 있게 한다.

융합: 시스템 관점의 지표 (CPU 이용률, 처리량)와 사용자 관점의 지표 (반환 시간, 대기 시간, 응답 시간)가 서로 상충(Conflict)하는 특성을 가지며, 현대 OS는 다단계 피드백 큐 (MLFQ)를 통해 이 둘의 황금비를 찾으려 시도한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 여러 개의 스케줄링 알고리즘 (FCFS, SJF, RR 등) 중 하나를 선택하거나 평가할 때 잣대로 삼는 5가지 주요 척도로, CPU 이용률, 처리량, 반환 시간, 대기 시간, 응답 시간으로 구성된다.
필요성: 세상에 만병통치약인 스케줄링 기법은 존재하지 않는다. 잦은 교체(선점)는 체감 속도를 높이지만 기계의 효율을 떨어뜨리고, 반대의 경우는 효율은 높지만 사용자가 답답해한다. 따라서 설계자는 시스템이 투입될 환경에 따라 "무엇을 극대화하고 무엇을 포기할 것인가"를 정량적인 척도로 수치화하여 평가해야 한다.
💡 비유: 자동차를 살 때, **'연비, 제로백, 승차감, 최고속도, 트렁크 크기'**라는 5가지 스펙(기준)을 놓고 스포츠카를 살지 덤프트럭을 살지 저울질하는 것과 같다.
등장 배경: 초기 메인프레임 시절에는 비싼 CPU를 놀리지 않는 것(이용률, 처리량)만이 유일한 선(선)이었다. 하지만 PC 시대와 웹 시대로 넘어오면서 인간과 기계 간의 상호작용이 폭증했고, 아무리 처리량이 높아도 마우스가 버벅거리는 시스템은 외면받게 됨에 따라 사용자 중심의 지표(응답, 대기시간)가 핵심 기준으로 격상되었다.

  [스케줄링 기준의 두 가지 상충되는 관점]

  [시스템/관리자 관점] ──────────────────────▶ [사용자 관점]
  "기계를 1초도 쉬지 않게 풀가동 시켜라!"          "내 프로그램이 당장 클릭하자마자 반응하게 해!"
       (기계적 효율성 중시)                              (체감 응답성 중시)
             ↓                                            ↓
   목표: 극대화 (Maximize)                        목표: 최소화 (Minimize)
   척도 1: CPU 이용률 (CPU Utilization)          척도 3: 반환 시간 (Turnaround Time)
   척도 2: 처리량 (Throughput)                   척도 4: 대기 시간 (Waiting Time)
                                                척도 5: 응답 시간 (Response Time)
                                                
   >> 이 두 관점은 널뛰기 시소처럼 하나를 무리하게 올리면 반드시 반대쪽이 무너진다.

[다이어그램 해설] 스케줄링 기준 5가지는 크게 시스템 중심과 사용자 중심으로 나뉜다. 잦은 문맥 교환(Context Switch)을 하면 사용자 체감인 응답 시간은 짧아지지만, 오버헤드로 인해 시스템 전체의 CPU 이용률과 처리량은 곤두박질친다. 스케줄러 설계의 본질은 이 시소게임에서 완벽한 평형 상태를 유지하거나, 시스템 용도에 맞게 의도적으로 시소를 기울이는 데 있다.

📢 섹션 요약 비유: 공장장(시스템)은 기계가 안 쉬고(이용률) 하루에 물건 1,000개를 찍어내는 것(처리량)이 최고라고 하지만, 고객(사용자)은 자기가 주문한 단 1개의 물건이 당장 내일 도착하는 것(응답/반환 시간)만 중요하게 여기는 상반된 입장과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

5대 스케줄링 지표 세부 분석

CPU 이용률 (CPU Utilization)
- 정의: 전체 시간 중 CPU가 쉬지 않고(유휴 상태 없이) 실제 작업을 수행한 시간의 비율 (0% ~ 100%).
- 목표: 극대화. 실제 시스템에서는 최소 40%(경부하)에서 최대 90%(과부하)를 유지하려 한다.
처리량 (Throughput)
- 정의: 단위 시간(예: 1초, 1시간) 당 완전히 실행을 끝마친(Terminated) 프로세스의 개수.
- 목표: 극대화. 긴 프로세스 위주면 단위 시간당 1개일 수도, 짧은 트랜잭션 위주면 초당 1만 개일 수도 있다.
반환 시간 (Turnaround Time)
- 정의: 프로세스가 처음 시스템(Ready 큐)에 제출(생성)된 시점부터 완전히 실행을 마치고 종료될 때까지 소요된 총 시간.
- 공식: 반환 시간 = (Ready 큐 대기 시간의 합) + (CPU 실행 시간) + (I/O 작업 시간)
- 목표: 최소화. 하나의 배치(Batch) 작업이나 렌더링 작업이 얼마나 빨리 내 손에 결과물로 돌아오느냐의 척도다.
대기 시간 (Waiting Time)
- 정의: 프로세스가 실행/입출력하는 시간은 제외하고, 순수하게 준비 큐(Ready Queue)에서 대기한 시간의 총합.
- 특징: 스케줄링 알고리즘은 CPU 버스트나 I/O 속도 자체를 바꿀 순 없으므로, 사실상 스케줄러 성능 평가의 가장 직접적이고 순수한 비교 지표가 된다.
- 목표: 최소화.
응답 시간 (Response Time)
- 정의: 프로세스가 레디 큐에 제출된 후, 처음으로 CPU를 할당받아 응답(출력)을 시작하기까지 걸린 시간. (완전히 끝나는 시간이 아님)
- 목표: 최소화. 시분할 시스템이나 대화형(Interactive) UI 환경에서 가장 핵심적으로 방어해야 하는 최우선 지표다.

  ┌─────────────────────────────────────────────────────────────────────┐
  │         프로세스 생명 주기를 통한 시간 지표(Criteria) 시각화        │
  ├─────────────────────────────────────────────────────────────────────┤
  │                                                                     │
  │  도착(생성)                                              종료       │
  │   ▼                                                       ▼         │
  │   ├── Ready ──┼── Run ──┼── Wait(I/O) ──┼── Ready ──┼── Run ──┤     │
  │                                                                     │
  │   │←─ (응답 시간) ─→│                                               │
  │   │                 (첫 반응)                                       │
  │                                                                     │
  │   │██ (대기 시간 1) ██│               │██ (대기 시간 2) ██│         │
  │                                                                     │
  │   │←───────────────── (반환 시간 총합) ───────────────────────→     │
  │                                                                     │
  │   * 대기 시간의 총합 = (대기 시간 1) + (대기 시간 2)                │
  │   * CPU 이용률 계산 = (총 시간 - 스케줄러/오버헤드 시간) / 총 시간  │
  └─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 하나의 프로세스가 시스템에 들어와서 끝날 때까지 겪는 상태 변화의 시간 축이다. 대기 시간은 큐에서 기다린 모든 조각의 합이며, 응답 시간은 오직 "첫 번째" 실행이 일어날 때까지만 잰다. 사용자가 브라우저를 클릭했을 때 화면에 빈 창이라도 "바로" 뜨면(응답시간 짧음), 로딩이 한참 걸려 완성이 늦어지더라도(반환시간 긺) 시스템이 멈췄다고 생각하지 않기 때문에 현대 OS는 응답 시간을 극도로 중시한다.

📢 섹션 요약 비유: 식당 주문에 비유하면, 반환 시간은 '주문부터 음식을 다 먹고 나갈 때까지'고, 응답 시간은 '주문 후 밑반찬(물)이라도 내어주기까지의 시간', 대기 시간은 순수하게 '웨이팅 벤치에 앉아있던 시간의 합'입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

최적화 목표의 상충 (Trade-off) 딜레마

스케줄링의 진정한 어려움은 모든 지표를 동시에 좋게 만들 수 없다는 물리적 모순에 있다.

전략 방향	유리해지는 지표 (극대화/최소화)	희생되는 지표 (부작용)
잦은 선점(Time Slice를 작게 조각냄)	응답 시간 최소화 (모두 즉시 반응)	CPU 이용률 저하 (문맥교환 폭증), 반환 시간 늦어짐
선점 최소화 (끝까지 1명에게 몰아줌)	처리량/이용률 극대화 (오버헤드 소멸)	응답/대기 시간 최악 (앞에 큰 놈 있으면 무한 대기)
짧은 놈 우선 (SJF 방식)	평균 대기시간 수학적 최소화	긴 작업의 처리량 붕괴 (기아 상태 발생)

평균(Average) vs 분산(Variance) 최적화

초기에는 5가지 지표의 **평균값(Average)**을 최적화하는 데 몰두했다. 하지만 데스크톱 환경에서는 평균 대기시간이 1ms여도 100번 중에 1번 마우스가 10초 동안 굳어버린다면 최악의 시스템으로 평가받는다. 따라서 현대 스케줄링 기준은 단순히 평균을 줄이는 것에서 나아가, **응답 시간의 편차(Variance, Jitter)**를 최소화하여 사용자에게 "항상 일관되고 예측 가능한 속도로 동작한다"는 환상을 심어주는 방향으로 기준이 진화했다.

📢 섹션 요약 비유: 100명을 진료할 때 99명을 1분 만에 진료하고 1명을 10시간 방치하는 병원(평균 최적화)보다, 100명 모두를 공평하게 10분씩 대기하게 하는 병원(분산 최적화)이 환자 불만이 훨씬 적은 것과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오

AWS EC2 워크로드 최적화 (목표 지표가 다른 아키텍처 분리):
- 배치/빅데이터 노드: 하둡(Hadoop)이나 영상 인코딩 서버는 응답 시간이 의미가 없다. 하루 밤새워 수테라바이트의 영상 변환만 끝내면(반환 시간 최소화) 된다. 이 경우 잦은 문맥 교환을 꺼버려 **처리량(Throughput)**에 올인하도록 커널 스케줄러 슬라이스를 길게 튜닝한다.
- 웹 API/모바일 백엔드 노드: 넷플릭스나 쿠팡의 검색 API 서버는 초당 수만 건의 쿼리가 들어온다. 여기선 응답 시간(Response Time) 0.1초가 늘어나면 매출이 수억 원 하락한다. 처리량이 조금 손해 보더라도 잦은 선점과 이벤트 루프를 통해 극단적으로 응답 지연을 낮추는 방향으로 아키텍처를 잡는다.
평균 vs 최악의 경우 (Hard Real-time):
- 일반 범용 서버에서는 5대 기준의 "평균"을 좋게 하는 리눅스 CFS 등을 쓰지만, 자동차 에어백 제어나 심박 측정기 같은 하드 리얼타임 OS(RTOS)에서는 5대 기준보다 **데드라인 준수율(Deadline Miss Rate 0%)**과 **최대 응답 시간(Maximum Response Time)**이라는 완전히 다른 절대 기준 잣대를 들이댄다.

  ┌─────────────────────────────────────────────────────────────────┐
  │     시스템 목적에 따른 1순위 스케줄링 기준 평가 트리            │
  ├─────────────────────────────────────────────────────────────────┤
  │                                                                 │
  │   구축하려는 시스템의 최종 사용자(User)는 누구인가?             │
  │                │                                                │
  │                ▼                                                │
  │      [대화형 사용자 (웹/데스크톱/게임)]                         │
  │       ├─▶ 핵심 목표: 렉이 안 걸리고 즉각 반응할 것!             │
  │       └─▶ 최우선 평가 기준: 응답 시간(Response Time) 분산 최소화│
  │                                                                 │
  │      [백그라운드 머신 (DB/AI 훈련/분석)]                        │
  │       ├─▶ 핵심 목표: 밤사이 던져둔 데이터 다 끝내놓을 것!       │
  │       └─▶ 최우선 평가 기준: 시스템 처리량(Throughput) 극대화    │
  │                                                                 │
  │      [생명 직결 기계 (의료기기/우주선/자동차)]                  │
  │       ├─▶ 핵심 목표: 정해진 0.001초 안에 브레이크를 밟을 것!    │
  │       └─▶ 최우선 평가 기준: 최악 응답 시간(Worst-case RT) 보장  │
  └─────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 아키텍트가 성능 튜닝을 할 때 어떤 지표의 모니터링 그래프(Grafana 등)를 대시보드 정중앙에 띄워놓고 방어해야 하는지 보여주는 의사결정 트리다. 목적에 맞지 않는 엉뚱한 지표를 개선하려 하면 자원만 낭비하게 된다.

📢 섹션 요약 비유: 스포츠카 엔지니어에게 "짐을 많이 싣는 기준(처리량)"을 들이대며 설계하라고 하거나, 화물 트럭 엔지니어에게 "제로백(응답 시간)"을 최우선으로 평가하겠다는 것만큼 바보 같은 성능 평가는 없습니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기대효과

정확한 스케줄링 기준을 수립하고 모니터링함으로써, 시스템 관리자는 "우리 서버가 느리다"라는 추상적 불만을 "응답 시간 분산이 30% 증가했다" 혹은 "반환 시간이 2배 길어졌다"와 같이 구체적으로 계량화하여 정확한 병목을 찾아내고 조치(Scale-out, 커널 튜닝 등)할 수 있다.

결론 및 미래 전망

과거에는 알고리즘 하나가 5가지 기준 중 하나를 타깃팅하는 단편적 방식이었다면, 현재와 미래의 스케줄러(CFS, BPF 기반 커스텀 스케줄러)는 기계학습(ML)과 동적 휴리스틱을 이용해 워크로드를 실시간 분석한다. 즉, I/O 프로세스에게는 '응답 시간 기준'으로 우선권을 주고, CPU 프로세스에게는 '처리량 기준'으로 긴 슬라이스를 주는 등 다중 기준 하이브리드 최적화 패러다임으로 진화하여 사용자 경험과 기계 효율성의 딜레마를 동시에 극복해 나가고 있다.

📢 섹션 요약 비유: 이제 운영체제는 5과목(5대 기준) 중 하나만 100점을 맞는 극단적 천재가 아니라, 상황에 따라 수학이 필요할 땐 수학 지능을 끌어올리고 체육이 필요할 땐 체력을 끌어올리는 인공지능 카멜레온으로 진화하고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
응답 시간 (Response Time)	대화형 시분할 시스템에서 가장 목숨 걸고 최소화(방어)해야 하는 체감 성능 제1지표다.
처리량 (Throughput)	시스템 관리자나 배치 작업 환경에서 가장 중시하는 거시적 효율성 지표로, 컨텍스트 스위치가 잦을수록 떨어진다.
호위 효과 (Convoy Effect)	긴 프로세스가 앞에 있어서 짧은 프로세스들의 '대기 시간(Waiting Time)' 기준이 최악으로 무너지는 대표적 실패 사례다.
타임 퀀텀 (Time Quantum)	이 조각의 크기가 작으면 응답 시간은 좋아지지만 반환 시간과 처리량은 박살 나는 절대적인 트레이드오프 파라미터다.
문맥 교환 (Context Switch) 오버헤드	스케줄러가 응답 시간을 좋게 하려고 개입할 때마다 CPU 이용률(Utilization) 기준을 갉아먹는 숨겨진 세금이다.

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

뷔페식당이 손님을 얼마나 '잘' 모셨는지 평가하려면 5가지 채점표(기준)가 필요해요.
식당 주인의 채점표는 "오늘 음식을 몇 접시 팔았어?(처리량)"이고, 손님의 채점표는 "주문하고 물 한 잔 나오기까지 얼마나 걸렸지?(응답 시간)"예요.
이 두 사람의 채점표를 다 100점 맞게 하는 건 마법 같은 일이라, 똑똑한 지배인(스케줄러)은 손님이 화내지 않을 정도로만 기다리게 하면서 음식을 쉴 새 없이 찍어내는 황금 비율을 찾아낸답니다!