1.시스템&인프라/개발 입문자를 위한 운영체제

9편. CPU 스케줄링 성능 지표 - 성능은 어떻게 비교할까?

쿼드큐브 2025. 11. 20. 16:46
반응형
반응형

9편. CPU 스케줄링 성능 지표 - 성능은 어떻게 비교할까?

 

📚 목차
1. 대기 시간 (Waiting Time) - 얼마나 오래 기다렸는가?
2. 응답 시간 (Response Time) - 처음 반응까지 걸린 시간
3. 반환 시간 (Turnaround Time) - 전체 소요 시간
4. 처리량 (Throughput) - 얼마나 많이 처리했는가?
5. CPU 사용률 (CPU Utilization) - 얼마나 바쁘게 일했는가?
6. 공정성 (Fairness) - 모두가 동등한 기회를 얻는가?
✔ 마무리 - 개발자라면 꼭 이해해야 할 스케줄링 지표

 

운영체제가 여러 개의 프로세스를 동시에 다루는 환경에서, 어떤 프로세스를 먼저 실행할지 결정하는 스케줄링 방식은 시스템의 체감 성능에 큰 영향을 줍니다.


하지만 단순히 "어떤 프로세스를 먼저 실행했는가?"만으로는 그 효율을 평가하기 어렵습니다. 사용자의 응답 체감, 자원의 활용도, 처리 속도 등 다양한 요소를 수치화해 비교할 필요가 있습니다.


바로 이때 필요한 것이 CPU 스케줄링 성능 지표입니다.

CPU 스케줄링 성능 지표
CPU 스케줄링 성능 지표


이 글에서는 각 지표의 의미와 계산법, 실무적 해석을 예제와 함께 이해하기 쉽게 정리해 보겠습니다.

 

1. 대기 시간 (Waiting Time) - 얼마나 오래 기다렸는가?

대기 시간은 프로세스가 준비 큐(Ready Queue)에 들어온 시점부터, CPU를 실제로 할당받아 실행되기 전까지 대기한 총시간을 의미합니다.

쉽게 말해, “CPU를 사용하기 위해 줄 서서 기다린 시간”이라고 할 수 있습니다.

 

✔️ 대기 시간 = 반환 시간(Turnaround Time) - 실행 시간(Burst Time)

시작시간(Start Time) - 도착 시간(Arrival Time)

[준비 큐]          [CPU]
   ↑                  ↓
[P2] -- 대기 시간 -- [P2 실행]
[P3] -- 대기 시간 -- [P3 실행]

 

각 프로세스는 준비 큐에 도착한 이후, 자신의 차례가 올 때까지 기다립니다.

이때 대기하는 시간의 길이가 바로 대기 시간이며, CPU가 바쁘거나 다른 프로세스가 우선 처리된다면 대기 시간은 더 길어질 수 있습니다.

 

대기 시간이 길어질수록 사용자 입장에서는 “시스템이 느리다”는 인상을 받기 쉽습니다.

특히 다수의 프로세스가 동시에 실행되거나, 비효율적인 스케줄링 알고리즘을 사용할 경우 대기 시간이 길어지고 이는 전체 성능 저하로 이어질 수 있습니다.

 

따라서 대기 시간은 스케줄링 알고리즘의 효율성과 사용자 경험을 평가하는 데 중요한 기준이 됩니다.

 

✔️ 예제로 살펴보는 대기 시간 계산

다음은 세 개의 프로세스를 FCFS(First-Come, First-Served) 방식으로 스케줄링했을 때의 대기 시간을 계산한 예시입니다.

프로세스 도착 시간(ms) 실행 시간(ms) 실행 시작 시간(ms) 대기 시간(ms)
P1 0 10 0 0
P2 2 5 10 8
P3 4 8 15 11

▸ P1은 가장 먼저 도착한 프로세스이므로 기다리지 않고 바로 실행됩니다. 대기 시간은 0ms입니다.
▸ P2는 2ms에 도착했지만, P1이 10ms 동안 CPU를 점유했기 때문에 8ms 동안 대기합니다.
▸ P3는 4ms에 도착했으며, P2가 끝날 때까지 11ms 동안 대기합니다.

 

평균 대기 시간 = (0 + 8 + 11) / 3 = 6.33ms

 

이 결과는 FCFS 방식 기준이며, 스케줄링 알고리즘이 바뀌면 대기 시간도 달라질 수 있습니다.

 

✔️시나리오로 이해하기: 콜센터 상담 대기

콜센터에 상담원이 1명뿐이라고 가정해 봅시다.

🔸고객 A는 첫 번째로 전화를 걸고 바로 상담을 받음 → 대기 시간: 0분
🔸고객 B는 2분 후 전화했지만 A가 통화 중 → 대기 시간: 8분

🔸고객 C는 4분 후 전화했지만 A와 B 모두 대기 중 → 대기 시간: 11분

→ 이 대기 시간이 곧 CPU를 기다리는 프로세스의 대기 시간과 동일한 개념입니다.

 

2. 응답 시간 (Response Time) - 처음 반응까지 걸린 시간

응답 시간이란, 프로세스가 준비 큐(Ready Queue)에 도착한 이후, 처음으로 CPU를 할당받을 때까지 걸린 시간을 의미합니다.

쉽게 말해, “사용자의 요청에 시스템이 처음 반응한 시점까지 걸린 시간”이라고 볼 수 있습니다.

 

응답 시간은 특히 사용자 인터페이스 시스템이나 실시간 반응이 중요한 환경에서 매우 중요한 성능 지표로 활용됩니다.

 

✔️ 응답 시간 = CPU 첫 할당 시간 - 프로세스 도착 시간

[사용자 요청] ──▶ (시간 경과) ──▶ [CPU 첫 할당]
        ▲                                 │
        │                                 └───── 응답 시간

이 시간은 사용자가 "시스템이 반응하기 시작했다"고 느끼는 시점을 기준으로 하며, 작업이 모두 끝나는 시간과는 다릅니다.

 

✔️ 특징

🔸비선점형 스케줄링(예: FCFS)

프로세스가 CPU를 한 번 할당받으면 끝까지 실행하므로, 응답 시간과 대기 시간이 항상 동일합니다.
🔸선점형 스케줄링(예: Round Robin)

프로세스가 잠깐이라도 CPU를 할당받으면 그 시점이 응답 시간으로 간주됩니다.

이 경우, 전체 대기 시간보다 응답 시간이 더 짧아질 수 있습니다.

 

✔️ 예시 : FCFS 에서의 응답 시간 계산

다음은 FCFS(First-Come, First-Served) 방식으로 세 개의 프로세스를 스케줄링했을 때의 응답 시간 계산 예시입니다.

프로세스 도착시간 실행 시간 CPU첫 할당시간 응답 시간
P1 0ms 10ms 0ms 0ms
P2 2ms 5ms 10ms 8ms
P3 4ms 5ms 15ms 11ms

▸P1은 0ms에 도착하여 바로 CPU를 할당받으므로 응답 시간이 0ms입니다.

▸P2는 2ms에 도착했지만, P1이 10ms까지 CPU를 점유하므로 첫 할당은 10ms이며, 응답 시간은 10ms - 2ms = 8ms입니다.

▸ P3는 4ms에 도착하지만, P2가 끝나는 15ms까지 기다려야 하므로 응답 시간은 15ms - 4ms = 11ms입니다.

 

평균 응답 시간 = (0 + 8 + 11) / 3 = 6.33ms

 

✔️ 실생활 예시 – 웹 브라우저 반응 시간

🔸사용자가 주소창에 URL을 입력하고 엔터를 누른 시점이 도착 시간
🔸“로딩 중…” 메시지가 표시되는 순간이 응답 시간
🔸페이지가 완전히 로드되는 시점은 반환 시간

즉, 사용자가 “무언가 반응이 왔다”고 느끼는 순간이 바로 응답 시간입니다.

 

3. 반환 시간 (Turnaround Time) - 전체 소요 시간

반환 시간은 프로세스가 시스템에 도착한 시점부터 모든 작업을 마치고 완전히 종료될 때까지 걸린 전체 시간을 의미합니다.

이 시간에는 CPU를 기다린 시간(대기), 실제 실행 시간, 입출력(I/O) 처리 시간 등 프로세스의 전체 생명 주기가 모두 포함됩니다.

 

✔️ 반환 시간 = 종료 시각 – 도착 시각

[도착] --> [대기] --> [실행] --> [I/O] --> ... --> [종료]
   ▲                                                 │
   │                                                 └──── 반환 시간

반환 시간은 프로세스의 전체 생애 주기를 측정하는 지표로, 시스템의 전반적인 효율성과 사용자가 체감하는 성능을 평가하는 데 매우 중요합니다.

 

✔️ 예시 : FCFS 스케줄링에서의 반환 시간 계산

다음은 FCFS(First Come, First Served) 방식으로 세 개의 프로세스를 처리한 경우입니다.

각 프로세스의 도착 시간, 실행 시간, 종료 시각이 주어졌을 때, 반환 시간을 계산해 보겠습니다.

프로세스 도착시간 실행시간 종료시간 반환시간
P1 0ms 10ms 10ms 10ms
P2 2ms 5ms 15ms 13ms
P3 4ms 8ms 23ms 19ms

반환 시간은 아래와 같이 종료 시간에서 도착 시간을 뺀 값으로 계산됩니다:

▸ P1: 0ms 도착 → 10ms 종료 → 반환 시간 = 10 − 0 = 10ms

▸ P2: 2ms 도착 → 15ms 종료 → 반환 시간 = 15 − 2 = 13ms

▸ P3: 4ms 도착 → 23ms 종료 → 반환 시간 = 23 − 4 = 19ms

 

평균 반환 시간 = (10 + 13 + 19) / 3 = 14ms

 

이처럼 반환 시간은 단순히 실행 시간이 아니라, 도착 후 종료까지 걸린 전체 시간을 나타내므로, 스케줄링 방식에 따라 프로세스마다 큰 차이를 보일 수 있습니다.

 

✔️ 일상 속 예시: 음식점 주문 처리시

고객이 주문한 순간부터 음식이 완성되어 나오는 순간까지 걸린 시간

→ 이 전체 시간이 바로 반환 시간입니다.

→ 요리 시간뿐 아니라, 대기, 재료 준비, 서빙까지 모두 포함됩니다.

반응형

 

4. 처리량 (Throughput) - 얼마나 많이 처리했는가?

처리량(Throughput)은 시스템이 단위 시간당 얼마나 많은 작업(또는 프로세스)을 완료했는지를 나타내는 성능 지표입니다.

쉽게 말해, 컴퓨터가 “얼마나 부지런히 일했는가”를 수치로 표현한 개념입니다.

 

처리량은 특히 서버, 배치 처리 시스템, 병렬 작업 환경 등에서 중요하게 평가됩니다.

하루에도 수천 건의 요청을 처리해야 하는 환경에서는 처리량이 곧 시스템의 처리 능력을 말해주기 때문입니다.

 

✔️ 처리량 = 완료된 작업 수 ÷ 총 소요 시간

 

✔️ 예시

▸ 시스템 A: 1분 동안 10개의 작업을 완료 → 처리량 = 10개/분

▸ 시스템 B: 1분 동안 15개의 작업을 완료 → 처리량 = 15개/분

시스템 B는 같은 시간에 더 많은 작업을 처리했으므로, 더 높은 처리량을 가진 시스템입니다.

이는 곧 높은 생산성과 효율성을 의미합니다.

 

프린터 성능도 처리량으로 비교해 볼 수 있습니다.

▸ 프린터 A: 1시간에 100장을 출력

▸ 프린터 B: 1시간에 250장을 출력

프린터 B는 더 많은 문서를 더 짧은 시간에 출력할 수 있으므로, 대량 작업에 더 적합한 장비입니다.

 

처리량이 높다는 것은 단순히 빠르다는 의미를 넘어서, 더 많은 사용자의 요청을 동시에 감당할 수 있는 시스템이라는 뜻입니다.

 

5. CPU 사용률 (CPU Utilization) - 얼마나 바쁘게 일했는가?

CPU 사용률(CPU Utilization)**은 운영체제에서 CPU가 전체 시간 중 실제로 작업을 수행한 시간의 비율을 의미합니다.

즉, CPU가 일을 한 시간과 놀고 있는 시간(idle time) 중에서, 얼마나 열심히 일했는지를 수치로 나타낸 지표입니다.

 

높은 CPU 사용률은 자원이 잘 활용되고 있다는 뜻이고, 낮은 사용률은 시스템이 한가하거나 비효율적으로 운영되고 있다는 신호일 수 있습니다.

 

✔️ CPU 사용률(%) = (작업 시간 / 전체 시간) × 100

┌────────────────────────────────────────────┐
│                전체 시간                    │
├────────────┬───────────────────────────────┤
│ 작업 시간   │       유휴 시간(idle time)    │
└────────────┴───────────────────────────────┘

🔸작업 시간: 사용자 앱 실행, 시스템 작업 등 CPU가 바쁘게 일하는 시간
🔸유휴 시간: 아무런 요청이 없어 CPU가 쉬고 있는 시간

→ CPU 사용률은 이 중 작업 시간의 비율입니다.

 

✔️ 예시

어떤 시스템의 CPU가 100초 동안 작동했다고 가정합시다. 이 중:

🔸 80초는 실제로 사용자 프로그램이나 시스템 작업을 수행하는 데 사용되었고,

🔸 20초는 아무런 작업도 없이 유휴 상태였다면,
CPU 사용률 = (80초 / 100초) × 100% = 80%


즉, CPU는 전체 시간 중 80% 동안 실제로 일을 하고 있었고, 나머지 20%는 아무 작업 없이 대기하고 있던 상태입니다.

 

✔️ 일상 속 시나리오

CPU 사용률은 마치 카페에서 일하는 바리스타의 근무 시간과 같습니다.

🔸 바리스타가 손님을 응대하고 커피를 만드는 시간 = CPU가 작업 중인 시간

🔸 바리스타가 손님이 없어 잠시 쉬고 있는 시간 = CPU의 유휴 시간

🔸 손님이 많아 바리스타가 쉬지 않고 계속 일한다면 → CPU 사용률이 높음

🔸 손님이 드물어 바리스타가 자주 쉰다면 → CPU 사용률이 낮음

이러한 비유는 CPU가 얼마나 '바쁘게' 또는 '효율적으로' 일하고 있는지를 직관적으로 이해하는 데 도움을 줍니다.

 

✔️ 너무 높아도 문제? 너무 낮아도 문제!

🔸 CPU 사용률이 너무 낮은 경우

시스템이 유휴 상태로 자원을 낭비하고 있을 가능성

처리할 작업이 부족하거나, 대기 중인 I/O 작업이 병목을 일으킬 수 있음

 

🔸 CPU 사용률이 너무 높은 경우 (90~100%)

시스템 과부하 상태일 수 있음

다른 프로세스가 CPU를 받을 기회를 얻지 못해 지연이나 기아 현상 발생 가능성

 

CPU 사용률은 단순히 “얼마나 바쁘게 일했는가”를 보여주는 지표이지만, 이를 통해 시스템의 성능, 병목, 과부하 여부까지 유추할 수 있습니다.

운영체제 설계자뿐 아니라, 시스템 관리자, 서버 엔지니어에게도 매우 중요한 진단 지표로 활용됩니다.

 

시스템이 느리다고 느껴진다면, 먼저 CPU 사용률을 top, htop, 또는 Windows의 작업 관리자로 확인해 보세요.

 

6. 공정성 (Fairness) - 모두가 동등한 기회를 얻는가?

공정성(Fairness)은 운영체제가 모든 프로세스에게 CPU 사용 기회를 얼마나 균등하게 제공하는가를 평가하는 지표입니다.


특정 프로세스가 자원을 독점하거나, 반대로 어떤 프로세스는 거의 CPU를 할당받지 못하는 상황이 발생한다면, 이는 공정하지 못한 스케줄링이라 할 수 있습니다.

 

공정성은 단순한 ‘형평성’의 문제가 아니라, 시스템 전체의 안정성과 예측 가능성에 직접적인 영향을 줍니다.

 

🔷 공정한 스케줄링 vs 불공정한 스케줄링

CPU공정성 : 공정한 스케줄링 vs 불공정한 스케줄링
CPU공정성 : 공정한 스케줄링 vs 불공정한 스케줄링

✔️ 공정한 스케줄링: Round Robin 방식

Round Robin은 모든 프로세스에게 동일한 시간만큼 CPU를 번갈아 가며 할당하는 방식입니다.

예를 들어 두 개의 프로세스 P1, P2가 다음과 같이 실행된다고 가정해 봅시다.

P1: 10ms 실행
P2: 10ms 실행
P1: 10ms 실행
P2: 10ms 실행
… 반복

→ 이 방식에서는 어느 프로세스도 소외되지 않고, 모두 정기적으로 CPU를 할당받기 때문에 공정성이 매우 높습니다.

 

✔️ 불공정한 스케줄링: 우선순위 기반 방식

우선순위(priority)에 따라 CPU를 할당하는 방식은 효율적일 수 있으나, 공정성을 해치는 사례가 자주 발생합니다.

예를 들어 우선순위가 높은 P1이 항상 CPU를 점유하고, 낮은 P2는 계속 대기하는 상황을 보겠습니다.

P1(우선순위 높음): 100ms 실행  
P2(우선순위 낮음): 계속 대기  
P1: 계속 실행  
P2: 여전히 대기...

→ 이런 구조에서는 P2가 CPU를 거의 받지 못하는 기아 상태(Starvation)에 빠질 수 있으며, 시스템은 점점 특정 작업에 편향되게 됩니다.

 

🔷 교실에 비유해 보기 – 운영체제도 선생님처럼 공정해야 합니다

공정성은 일상 속에서도 쉽게 이해할 수 있습니다. 아래 교실 상황을 예로 들어 보겠습니다.

 

✔️ 공정한 경우

선생님이 수업 시간에 다양한 학생에게 골고루 질문하고, 모두에게 발언 기회를 줍니다.

→ 학생들은 수업에 집중하게 되고, 수업의 참여도도 높아집니다.

→ 운영체제에서는 모든 프로세스가 CPU를 일정 주기로 배정받는 Round Robin 방식과 유사합니다.

 

✔️ 불공정한 경우

선생님이 항상 손을 드는 몇몇 학생만 지목하고, 다른 학생들은 전혀 발언 기회를 얻지 못합니다.

→ 일부 학생은 점점 흥미를 잃고 수업에서 소외됩니다.

→ 운영체제에서 우선순위가 낮은 프로세스가 기아 상태에 빠지는 것과 같습니다.

 

🔷 실무 적용에서의 중요성

멀티 사용자 환경(예: 클라우드, 웹 서버)에서는 공정성이 없으면 일부 사용자의 요청만 집중 처리되고, 다른 사용자는 계속 대기하게 됩니다.

실시간 시스템에서는 응답이 지연되면 시스템 전체가 오작동할 수 있어, 공정한 자원 분배가 더욱 중요합니다.

 

✔ 마무리 - 개발자라면 꼭 이해해야 할 스케줄링 지표

CPU 스케줄링 알고리즘을 평가할 때, 단순히 "어떤 프로세스가 먼저 실행되었는가"만으로는 충분하지 않습니다.

대기 시간, 응답 시간, 반환 시간, 처리량, CPU 사용률, 공정성 등 여러 지표를 종합적으로 고려해야 시스템의 실제 성능을 제대로 판단할 수 있습니다.

 

운영체제는 단순히 프로세스를 실행하는 도구가 아니라, 수많은 요청을 조율하고 자원을 공정하게 분배하는 스마트한 매니저입니다.

 

📌 실무 개발자가 꼭 활용해야 할 포인트
🔸서버 튜닝 시: 처리량과 CPU 사용률을 확인해 병목 원인을 파악합니다.

🔸서비스 체감 성능 분석 시: 사용자 요청의 응답 시간과 대기 시간을 함께 고려합니다.

🔸모니터링 시스템에서는 htop, Grafana, Prometheus 등을 통해 각 지표를 시각화하고 추적합니다.

🔸멀티 사용자 시스템 설계 시: 공정성(Fairness)을 반영하여 기아(starvation)를 방지합니다.

CPU 스케줄링 성능 지표는 단순한 이론이 아닌, 성능 분석, 병목 진단, 사용자 경험 개선을 위한 실질적인 도구입니다.

운영체제의 스케줄링을 이해하면, 여러분은 한층 더 깊이 있는 시스템 설계와 디버깅 역량을 갖춘 개발자가 될 수 있습니다.

 


※ 게시된 글 및 이미지 중 일부는 AI 도구의 도움을 받아 생성되거나 다듬어졌습니다.

반응형

 

반응형