CPU 이용률 (CPU Utilization)과 처리량 (Throughput)

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

본질: CPU 이용률은 전체 시간 중 CPU가 유휴(Idle) 상태가 아닌 실제 프로세스 연산을 수행한 시간의 비율을 의미하며, 처리량은 단위 시간당 시스템이 완전히 실행을 끝마친(Terminated) 프로세스의 총 개수다.

가치: 이 두 지표는 스케줄링 기준 5요소 중 **"기계적 효율성(System-oriented Criteria)"**을 대변하며, 관리자 관점에서 비싼 하드웨어 인프라 자원의 투자 대비 수익(ROI)을 측정하는 핵심 척도다.

융합: 단기 스케줄러가 응답성(Response Time)을 높이기 위해 너무 잦은 문맥 교환(Context Switch)을 시도하면 시스템 오버헤드가 급증하여 CPU 이용률의 '순수 연산' 비율이 하락하고 결국 처리량이 붕괴하는 트레이드오프(Trade-off)가 발생한다.

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

개념: CPU 이용률 (CPU Utilization)은 물리적인 CPU 코어가 쉬지 않고 일하고 있는 시간의 백분율이다. 처리량 (Throughput)은 그 결과물로서 시스템이 1초 혹은 1시간 등 일정한 기준 시간 내에 완전히 마무리 지은 작업(프로세스나 트랜잭션)의 총량을 뜻한다.
필요성: 슈퍼컴퓨터, 클라우드 데이터센터의 노드 등 시스템 관리자 입장에서는 수천만 원짜리 장비가 가동 중일 때 이 장비가 1초라도 놀고 있는 꼴(Idle)을 볼 수 없다. 기계는 돌리면 돌릴수록 본전을 뽑는 것이기 때문에, 이 두 지표를 극대화하는 것은 운영체제(특히 장기/중기 스케줄러)의 가장 오래되고 근본적인 사명이다.
💡 비유: 공장(CPU)에 비유하면, CPU 이용률은 공장 기계가 하루 24시간 중 몇 시간을 돌아갔는지(예: 가동률 90%)를 나타내고, 처리량은 그 기계가 하루 동안 생산해 낸 완성품(프로세스)이 총 몇 개인지(예: 1,000개 생산)를 의미하는 **'공장 가동 지표'**와 같다.
등장 배경: 초기 일괄 처리(Batch) 시스템 시대에는 응답 시간이라는 개념조차 희박했다. 오로지 펀치 카드로 입력된 무거운 계산 작업들이 하루 안에 몇 개나 끝나는지(Throughput)만이 유일한 스케줄링의 척도였다. 현재도 I/O 상호작용이 없는 배치 서버(빅데이터 분석, 동영상 인코딩)에서는 여전히 가장 최우선으로 평가되는 지표다.

  [시간 축에 따른 CPU 상태와 지표 계산 (예시: 100ms 구간)]

  [ 0ms ]           [ 40ms ]       [ 70ms ]  [ 80ms ]          [ 100ms ]
     ├─────────────────┼──────────────┼────────┼─────────────────┤
     │   P1 실행       │   I/O 대기   │ P2 실행│ 문맥 교환 (OS)  │
     │  (CPU: 40ms)    │  (CPU Idle)  │ (10ms) │   (10ms)        │
     │                 │   (30ms)     │        │                 │
  P1 종료 (Throughput+1)            P2 종료 (Throughput+1)

  * 총 경과 시간 : 100ms
  * CPU 유휴(Idle) 시간 : 30ms
  * 순수 사용자 프로세스 연산 시간 (Useful CPU) : 40ms(P1) + 10ms(P2) = 50ms
  * OS 스케줄링 오버헤드 시간 : 10ms

  >> 물리적 CPU 이용률 = 70% (유휴 30ms 제외)
  >> 실효적 CPU 이용률 (유효 연산 기준) = 50%
  >> 처리량(Throughput) = 100ms 당 2개 완료 = 20개 / 초

[다이어그램 해설] CPU 이용률의 함정을 잘 보여준다. 단순히 작업 관리자(Task Manager)에 CPU가 70%라고 뜬다고 해서 그 70%가 모두 '사용자를 위해 유효한 일'을 한 것은 아니다. 잦은 문맥 교환 때문에 OS 커널이 소모한 10ms도 물리적인 이용률에는 합산되지만, 궁극적인 생산량(Throughput)에는 기여하지 않는 세금과 같다. 따라서 진정한 의미의 CPU 이용률은 OS 오버헤드를 제외한 순수(Useful) 연산 시간으로 평가해야 한다.

📢 섹션 요약 비유: 택시 기사가 하루 10시간 운전(이용률 100%)을 했다고 해서 돈을 많이 번 건 아닙니다. 빈 차로 돌아다니거나(Idle), 길을 잃고 헤맨 시간(문맥교환 오버헤드)을 빼고, 진짜 손님을 내려다 준 횟수(처리량)가 기사의 진짜 실력을 증명합니다.

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

지표 측정과 성능 관계의 수식적 이해

CPU 이용률의 산출 (Idle Loop 원리) 운영체제는 Ready 큐에 실행할 프로세스가 단 하나도 없을 때, 전력 관리와 시스템 유지를 위해 아주 가벼운 빈 껍데기 프로세스인 **유휴 프로세스(Idle Process)**를 돌린다.
- 물리적 CPU 이용률 = 1 - (Idle 프로세스의 CPU 점유 비율)
- 만약 모니터링 도구에서 CPU Idle이 20%라면, 물리적 CPU 이용률은 80%가 된다.
처리량 (Throughput)의 산출 구조 처리량(W)은 다음과 같이 거시적으로 계산된다.
- W = (특정 시간 T 동안 완료된 작업 수 N) / T
- 단위: Jobs/sec, Transactions/min 등
- 처리량은 개별 프로세스의 응답시간과 관계없이 평균 반환 시간(Turnaround Time)의 역수 성격을 띤다.

시스템 부하 상태와 지표의 한계 (병목 현상)

시스템이 처리할 수 있는 최대의 처리량을 'Maximum Throughput'이라고 한다. 입력(도착하는 프로세스)을 무한정 늘리면 처리량도 늘어날 것 같지만, 임계점(Saturation Point)을 넘어서면 이용률만 100%를 치고 처리량은 오히려 박살 나는 스래싱(Thrashing)과 흡사한 오버헤드 폭주 현상이 발생한다.

  ┌─────────────────────────────────────────────────────────────────────┐
  │         동시 다중 프로그래밍 정도에 따른 이용률과 처리량 변화       │
  ├─────────────────────────────────────────────────────────────────────┤
  │                                                                     │
  │     100% ┼                     (C) 오버헤드 폭주 구간               │
  │          │   (A) 상승 구간      .·················                  │
  │  CPU     │     .··············  │           ..··(↓) 처리량          │
  │  이용률   │   .· (↑) 이용률     │        .··                        │
  │    &     │  .·                 │      .·                            │
  │  처리량   │ .·                  ▼   .·                              │
  │          │.·                  (B) 임계점 (Saturation)               │
  │       0% ┼─────────────────────────────────────────────             │
  │           0         10        20         30         40              │
  │                 메모리에 적재된 프로세스 개수 (다중 프로그래밍 정도)│
  └─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설]

(A) 구간: 메모리에 프로세스를 추가할수록 CPU를 쉴 틈 없이 돌릴 수 있으므로, 이용률과 처리량이 정비례하여 이상적으로 솟아오른다. I/O 대기 시간의 빈틈을 완벽하게 서로 채워준다.
(B) 임계점: CPU 이용률이 100%에 근접했다. 기계는 최대 효율로 돌고 있으며 더 이상 성능이 오르지 않는다.
(C) 폭주 구간: 욕심을 내서 프로세스를 더 집어넣으면? CPU는 실제 일을 못 하고 프로세스 A, B, C... 사이를 스위칭(Context Switch)하고 메모리를 쫓아내는(스래싱) 커널 일만 하느라 허덕이게 된다. 모니터 상의 CPU 이용률은 100%지만, 실제 일은 완료되지 않아 처리량(Throughput) 곡선은 바닥으로 처박힌다. (이것이 서버가 뻗는 원리다.)
📢 섹션 요약 비유: 도로에 차가 적당히 많으면 고속도로 통행량(처리량)이 최고가 되지만(B), 그 선을 넘어 차를 끝없이 밀어 넣으면 도로에 차가 꽉 차서 아무도 1cm도 못 움직이는 끔찍한 교통 체증(C 구간, 처리량 제로)이 발생합니다.

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

응답 시간 (Response Time)과의 극단적 트레이드오프

서버 아키텍처 설계 시 가장 피를 말리는 부분은 **처리량(Throughput)**과 **응답 시간(Response Time)**을 동시에 만족시킬 수 없다는 본질적 딜레마다. 이 둘은 스케줄러의 타임 슬라이스(Time Quantum, q) 크기를 두고 정면으로 충돌한다.

타임 퀀텀 (q) 설정	응답 시간 관점 (사용자)	처리량 관점 (관리자)	시스템 상태 결과
q 가 매우 작을 때 (예: 1ms)	매우 좋음 (즉각 반응)	최악 (수직 하락)	잦은 문맥 교환으로 인한 캐시 무효화 발생. CPU가 OS 오버헤드만 처리하다 연산 시간 낭비.
q 가 매우 클 때 (예: 100ms)	최악 (마우스 멈춤)	매우 좋음 (극대화)	프로세스가 진득하게 캐시를 활용해 일괄 처리를 끝냄. 하지만 뒤의 짧은 프로세스들은 무한 대기.

CPU 바운드 vs I/O 바운드의 기여도

CPU 바운드 프로세스: 이용률을 유지하는 일등 공신이다. 한 번 올려두면 I/O 요청 없이 끝까지 CPU를 태운다. (이용률 상승 기여도 높음)
I/O 바운드 프로세스: 잠깐 CPU를 썼다가 바로 대기(Waiting) 큐로 도망간다. 이들만 있으면 CPU가 금방 유휴(Idle) 상태에 빠진다. (이용률 하락 위험 요소) 장기 스케줄러가 이 두 프로세스의 비율(Mix)을 5:5로 정교하게 맞추려 했던 이유가 바로 CPU 유휴시간을 없애 이용률 100%를 달성하기 위함이었다.
📢 섹션 요약 비유: 수프(응답 시간)를 뜨겁게 하려면 냄비를 작게 쪼개서 빨리 데워야 하고, 많이 만들려면(처리량) 가마솥에 한 번에 끓여야 하는 모순입니다. 한 냄비 안에서 빠름과 많음을 동시에 얻는 것은 물리학적으로 불가능합니다.

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

실무 시나리오

TPS (Transactions Per Second) 모니터링 튜닝: 웹 서버(Tomcat/Nginx)의 성능 테스트 시, 부하를 주면 처음에는 CPU 이용률과 TPS(처리량)가 같이 올라간다. 하지만 어느 순간 CPU 이용률이 100%를 치는 시점부터 TPS가 오히려 깎이거나 지연(Latency)이 치솟는 '병목 지점'을 만나게 된다.
- 기술사적 결단: 이 임계점 이후에는 스레드 풀(Thread Pool) 크기를 더 늘려봐야 단기 스케줄러의 문맥 교환 비용만 기하급수적으로 늘어나 오히려 처리량이 박살 난다. 따라서 로드 밸런서 단에서 큐의 Max Connection을 제한하고 초과분을 빠른 실패(Fast Fail, HTTP 503)로 끊어내 시스템 전체의 붕괴를 막는 백프레셔(Backpressure) 패턴이 도입되어야 한다.
배치 잡(Batch Job) 클러스터 환경 최적화: 매일 자정에 수 테라바이트의 로그를 분석하여 리포트를 뽑아내는 하둡(Hadoop) 클러스터 환경.
- 아키텍처 결단: 여기서는 웹 사용자처럼 응답성을 따질 필요가 1도 없다. 따라서 리눅스의 스케줄링 퀀텀(granularity)을 기본 10ms에서 더 큰 값으로 튜닝하고, 프로세스를 특정 물리 코어에 고정(CPU Pinning / Affinity)시켜 문맥 교환으로 인한 캐시 미스를 원천 차단한다. 이를 통해 CPU가 오직 순수 연산만 하도록 만들어 처리량을 한계치까지 쥐어짠다.

  ┌──────────────────────────────────────────────────────────────┐
  │     CPU 이용률 100% 도달 시 원인 분석 및 실무 대응 플로우    │
  ├──────────────────────────────────────────────────────────────┤
  │                                                              │
  │   [알람 발생: CPU Utilization 100% (서버 응답 지연)]         │
  │                │                                             │
  │                ▼                                             │
  │   [Top / vmstat 분석: 100% 중 커널 시간(sy) 비중 파악]       │
  │          ├─ (sy) 비중이 30% 이상으로 너무 높은가?            │
  │          │      │                                            │
  │          │      ▼                                            │
  │          │  (문제 진단) 과도한 문맥 교환 및 스케줄링 오버헤드│
  │          │  (해결 조치) 스레드 수 축소 / Event-Loop 전환 /   │
  │          │            시스템 콜 남발 최적화                  │
  │          │                                                   │
  │          └─ (us) 비중이 높고 (sy)는 정상적인가?              │
  │                 │                                            │
  │                 ▼                                            │
  │             (문제 진단) 순수 연산 부하에 의한 물리적 한계    │
  │                 │                                            │
  │                 ▼                                            │
  │         (해결 조치) Scale-out(노드 추가) 또는 로직 개선      │
  └──────────────────────────────────────────────────────────────┘

[다이어그램 해설] 단순히 "CPU 100% 쳤다"고 노드를 증설하는 것은 하수다. 유저 공간의 순수 연산(us)으로 100%를 친 것(이상적이고 건강한 부하)인지, 시스템 콜과 문맥 교환 등 커널 타임(sy)이 치솟은 구조적 병목(악성 부하)인지를 구분해야 한다. 후자의 경우 아무리 CPU(노드)를 늘려도 코드나 아키텍처(스레드 풀 제한 등)를 바꾸지 않으면 처리량 개선 효과가 미미하다.

📢 섹션 요약 비유: 직원이 땀을 흘리며 일할 때, 진짜 요리를 만드느라 땀을 흘리는지(순수 부하), 아니면 좁은 주방에서 앞사람과 계속 어깨가 부딪히고 자리를 피해주느라 진이 빠지는지(문맥 교환 부하)를 파악해야 올바른 주방 리모델링이 가능합니다.

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

정량/정성 기대효과

구분	오버헤드 억제 실패 시	적절한 스레드/코어 튜닝 후	기대 효과
정량 (TPS)	CPU 100% 상태에서 TPS 급감 (5,000)	문맥 교환 절감 시 TPS 방어 (20,000)	동일 인프라 비용으로 4배의 처리량 확보
정량 (가동률)	I/O 대기로 인한 Idle 시간 발생 (60%)	비동기 I/O로 병렬성 극대화 (95%)	서버 대수 최적화 및 TCO 절감
정성 (안정성)	부하 급증 시 서버 전체 멈춤 (Hang)	임계점 통제로 안정적 응답 (Graceful)	서비스 신뢰도 및 SLA (99.99%) 보장

미래 전망

가상화 컨테이너(Docker, K8s)가 지배하는 클라우드 환경에서는 수천 개의 마이크로서비스가 한 노드에 구겨 넣어지며 다중 프로그래밍 정도가 폭발적으로 증가했다. 이로 인한 엄청난 디스패처/문맥 교환 오버헤드(낮은 순수 처리량)를 극복하기 위해, 리눅스 커널의 최신 eBPF 기술과 커널 우회 기술(Kernel Bypass: DPDK, io_uring)을 통해 커널 타임(sy)을 0으로 소멸시키고 100%의 CPU 이용률을 오직 처리량(Throughput)으로 직결시키는 극단적 아키텍처 혁신이 데이터센터의 새로운 표준으로 자리 잡고 있다.

📢 섹션 요약 비유: 자동차(서버)가 무거워졌을 때 과거에는 엔진(CPU 코어)을 더 큰 걸로 바꿨다면, 미래의 기술은 차체에서 무거운 철판(OS 커널 오버헤드) 자체를 떼어내어 뼈대(eBPF/io_uring)만 남긴 채 달리는 초경량 레이싱으로 진화하고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
응답 시간 (Response Time)	처리량(Throughput)과 항상 대립각을 세우는 사용자 관점의 지표로, 둘 사이의 밸런스 조절이 스케줄링의 알파이자 오메가다.
문맥 교환 (Context Switch)	CPU 이용률이 높음에도 처리량이 낮다면 이 비용(오버헤드)이 과도하게 발생하고 있다는 확실한 증거다.
다중 프로그래밍 정도 (Degree of Multiprogramming)	적당하면 CPU 이용률을 100%로 끌어올리지만, 과도하면 스래싱을 유발하여 처리량을 0으로 박살 내는 양날의 검이다.
가상 실행 시간 (vruntime)	리눅스 CFS가 너무 잦은 문맥 교환으로 인한 처리량 저하를 막기 위해 동적으로 교체 타이밍을 조절하는 공정성 계산 값이다.
I/O 대기 시간 (Idle Time)	디스크 등 외부 장치를 기다리느라 CPU가 연산을 못하고 노는 시간으로, 이 빈틈을 채우는 것이 이용률 극대화의 핵심이다.

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

공부방에서 하루 종일 책상에 앉아있던 시간(딴짓 빼고 진짜 공부한 시간)을 백점 만점으로 나타낸 게 CPU 이용률이에요.
그리고 그 앉아있던 시간 동안 푼 수학 문제집의 총 장수나 개수를 처리량이라고 불러요.
책상에 오래 앉아있어도(이용률 100%), 과목을 1분마다 국어, 영어, 수학으로 계속 바꿔가며 책을 넣었다 뺐다 하면 정작 문제를 거의 못 풀어서 처리량(진짜 푼 문제)은 엉망이 된답니다!