다중 프로그래밍 정도와 CPU 이용률 관계

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

본질: 이 관계 그래프는 램(RAM)에 동시에 올려놓은 프로그램의 개수(Degree of Multiprogramming)가 늘어날 때, CPU가 얼마나 쉬지 않고 100% 팽팽하게 일하는가(Utilization)를 보여주는 운영체제 성능 스케줄링의 알파이자 오메가 곡선이다.

가치: 프로그램 개수를 늘리면 램 효율과 CPU 가동률이 아름답게 상승하다가, 어느 한계점(램의 물리적 수용 한계)을 넘는 단 1개의 프로그램이 추가되는 순간 곡선이 수직으로 절벽을 타듯 곤두박질치는 스래싱(Thrashing)의 극적인 재앙을 시각적으로 가장 완벽하게 증명한다.

융합: 이 꺾이는 변곡점(Knee)을 찾아내기 위해, OS 커널은 멍청한 장기 스케줄러(Long-term Scheduler)의 무지성 앱 띄우기를 버리고, 동적 워킹 셋(Working Set) 추적과 PFF(페이지 부재 빈도) 제어라는 고도화된 소프트웨어 브레이크 장치와 융합하게 되었다.

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

개념: X축은 '다중 프로그래밍의 정도(메모리에 떠 있는 프로세스의 수)', Y축은 'CPU 이용률(가동률)'이다. 그래프는 초반에 산을 오르듯 가파르게 쑥쑥 올라가다가 꼭대기를 찍고, 어느 한순간 수직 낙하하여 바닥에 처박힌다. 이 꼭대기 지점이 시스템이 뿜어낼 수 있는 궁극의 가성비 포인트고, 바닥에 처박힌 상태가 '스래싱 지옥'이다.
필요성: 1970년대 OS 공학자들은 환상에 빠져 있었다. "메모리에 앱을 많이 띄워둘수록, 한 놈이 디스크 I/O를 할 때 다른 놈이 CPU를 쓰면 되니까 CPU 이용률은 영원히 100%에 가까워지겠지!"라고 순진하게 믿었다. 하지만 현실의 서버를 돌려보니, 앱을 50개 띄웠을 땐 CPU가 90%로 일했는데, 51개를 띄우는 순간 갑자기 CPU가 1%로 바닥을 치며 뻗어버렸다. "왜 1개 더 띄웠다고 시스템 전체가 붕괴하는가?"를 경영진과 하드웨어 설계자에게 직관적으로 설명하고 방어 알고리즘을 짤 명분을 제공할 '치명적인 차트'가 절대적으로 필요했다.
💡 비유: 이 그래프는 지하철 푸시맨(Pushman)의 한계 곡선과 같다. 빈 지하철에 사람(프로세스)을 10명, 20명 더 밀어 넣을수록 출근 수송량(CPU 이용률)은 쑥쑥 올라간다. 빈 공간 없이 꽉꽉 채운 200명일 때가 가장 효율적인 수송의 정점이다. 그런데 억지로 1명을 더 밀어 넣어 201명을 만들면? 문이 안 닫힌다(한계 돌파). 기관사가 문을 열고 닫고를 무한 반복하며(Page Fault) 출발을 못 한다. 승객 1명 더 태우려다가 201명 전체가 지각을 하게 되는 출근길의 절망적인 병목 곡선이다.
등장 배경 및 관념의 파괴:
1. 가상 메모리의 과신: 요구 페이징 도입 후, "램 안 써도 디스크 스왑으로 돌리면 되니까 무한대로 앱 띄울 수 있음!"이라는 오만이 팽배했다.
2. I/O 병목의 과소평가: 디스크 속도가 램보다 수만 배 느리다는 사실이 교체 알고리즘과 맞물렸을 때 터질 나비효과를 계산하지 못했다.
3. Denning의 논문: 워킹 셋(Working Set) 이론을 창시한 피터 데닝이 이 절벽 그래프를 발표하며, 무작정 앱을 많이 띄우는 것이 선(Good)이 아님을 수학적으로 증명해 냈다.

┌──────────────────────────────────────────────────────────────────────┐
│        [그림] 다중 프로그래밍 정도와 CPU 이용률의 절벽 그래프        │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│ CPU 이용률 (%)                                                       │
│ 100 │                 ⭐ 최적점 (Optimal Point)                      │
│     │               / |                                              │
│  80 │             /  |                                               │
│     │           /    |                                               │
│  60 │         /      |                                               │
│     │       /        | 💥 스래싱 (Thrashing) 발생!                   │
│  40 │     /          | 뚝!                                           │
│     │   /            |  |                                            │
│  20 │ /              |  |                                            │
│     │/               |  ▼  (절벽 낙하)                               │
│   0 └────────────────┴───|────────────▶                              │
│             다중 프로그래밍의 정도 (Degree / 띄운 앱 개수)           │
└──────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 초반의 상승 곡선은 다중 프로그래밍(Multi-programming)의 위대함을 보여준다. 한 앱이 쉬면 다른 앱이 CPU를 즉시 빼앗아 연산하므로 놀라운 효율을 보인다. 그러나 ⭐최적점을 넘어가는 순간, 램(RAM) 잔고가 0이 되어 누군가를 쫓아내야만(Page Replacement) 램을 얻을 수 있는 상태가 된다. 앱들이 0.1초마다 서로의 램을 뺏고 뺏기느라 디스크 I/O만 폭발적으로 터지고, 정작 CPU는 일감을 못 받아 굶어 죽어버리는 수직 절벽 현상이 일어난다.

📢 섹션 요약 비유: 풍선에 바람(앱 개수)을 불어넣으면 풍선이 커지며 예뻐집니다(CPU 이용률 상승). 하지만 고무의 한계점(램 크기)을 모른 채 "한 번만 더 불면 더 예뻐지겠지?" 하고 딱 한 입 더 불어넣는 순간, 펑! 하고 터져서 0이 되어버리는 과유불급의 절대 곡선입니다.

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

상승 구간의 논리 (문맥 교환의 마술)

그래프의 왼쪽, 가파르게 상승하는 구간은 어떻게 만들어질까?

프로세스 A 하나만 떠 있으면, A가 하드디스크에서 파일을 긁어올 때 CPU는 10밀리초 동안 아무 일도 못 하고 놀아야(Idle) 한다 (이용률 10%).
이때 프로세스 B, C, D를 같이 띄워놓는다.
A가 디스크를 읽으러 쉬러 가면, 그 10밀리초 동안 스케줄러가 재빨리 B를 CPU에 태워 연산을 시킨다. B도 쉬면 C를 태운다.
빈틈없이 CPU를 혹사시키는 이 문맥 교환(Context Switch)의 촘촘한 맞물림 덕분에, 앱을 띄울수록 CPU 이용률이 99%를 향해 아름답게 치솟는다. 이것이 현대 OS의 핵심 철학이다.

수직 낙하 구간의 논리 (스케줄러의 치명적 자해)

그래프의 꼭대기에서 나락으로 떨어지는 끔찍한 과정의 이면에는 **'바보 같은 장기 스케줄러(Long-term Scheduler)'**의 오판이 도사리고 있다.

메모리에 앱을 너무 많이 띄워서(과포화), 각 앱들이 자기가 돌아가는 데 꼭 필요한 '최소한의 램(Working Set)'조차 배급받지 못하는 지경이 되었다.
램이 모자라니 디스크 스와핑(Page Fault)이 터지기 시작한다.
모든 앱이 디스크 I/O를 기다리느라 뻗어버렸다 (Sleep 상태).
CPU 할 일이 없어져 가동률이 99%에서 50%로 떨어진다.
이때 OS의 장기 스케줄러는 바보 같은 판단을 내린다. "어라? CPU가 왜 놀고 있지? 일감이 부족한가 보네! 당장 하드디스크에 있는 새 프로세스 하나 더 램으로 끌고 와서 띄워(Degree +1)!"
새 프로세스가 들어오며 기존에 헐떡이던 앱들의 남은 램 한 줌마저 다 뺏어버린다. 폴트가 핵폭탄급으로 터진다.
CPU 가동률이 1%로 수직 낙하한다. 스래싱(Thrashing)이 완성된다.

📢 섹션 요약 비유: 식당 주방(CPU)이 팽팽 돌다가 갑자기 프라이팬(램)이 모자라서 요리사들이 요리를 못 하고 멍때립니다(가동률 하락). 이걸 본 멍청한 사장(스케줄러)이 "주방이 왜 놀고 있어? 주문 더 받아!!" 하고 손님(새 프로세스)을 무작정 더 받았습니다. 결국 프라이팬 쟁탈전이 벌어져 주방은 폭동이 나고 요리는 1개도 안 나오는 멸망의 길입니다.

Ⅲ. 융합 비교 및 다각도 분석

워킹 셋(Working Set)과 물리 램의 수학적 공식

이 그래프의 꼭대기 변곡점이 터지는 시점을 수학적으로 예측할 수 있다.

$\sum_{i=1}^{n} WS_i > M$ (물리 메모리의 총합)

$WS_i$ = $i$번째 프로세스가 쾌적하게 렉 없이 돌기 위해 무조건 쥐고 있어야 하는 최소한의 램 카드 뭉치 크기 (Working Set)
$M$ = 컴퓨터 메인보드에 꽂혀있는 실제 물리 램(RAM)의 총 프레임 개수
해석: 띄워놓은 앱들의 필수 워킹 셋을 다 더한 값이 물리 램 총량을 넘어서는 그 1바이트의 순간! 절벽으로 추락한다. 스래싱이 터지는 것이다.

비교 1: 램 증설(Scale-up) vs 알고리즘 튜닝(Optimization)

그래프가 바닥을 기어 다닐 때 대처하는 방식이다.

대처 방식	튜닝 로직	곡선의 변화	결과
물리 RAM 2배 증설	(돈으로 때움)	꺾이는 절벽의 시점 자체가 오른쪽으로 2배 뒤로 밀려남	가장 무식하고 확실하며 100% 성공하는 해결책
Page 교체 (LRU 등)	가장 늙은 놈을 쫓아냄	절벽으로 떨어지는 경사를 아주 미세하게 완만하게 버텨줌	근본적인 워킹 셋 부족 앞에서는 결국 터짐 (한계 뚜렷)
PFF 동적 제어	폴트가 잦으면 앱을 강제 Suspend(일시 정지) 시킴	꼭대기에서 무리하게 안 늘리고 스스로 브레이크를 욺	스래싱 절벽을 아예 회피하여 고원(Plateau) 상태 유지

┌──────────┬────────────┬────────────┬──────────────────────────────┐
│ 상황       │ CPU 이용률  │ 디스크 I/O량 │ OS의 올바른 대처        │
├──────────┼────────────┼────────────┼──────────────────────────────┤
│ 앱 10개 (정상)│ 90% 높음   │ 낮음        │ 놔둠 (더 띄워도 됨)    │
│ 앱 50개 (경고)│ 99% 최고조 │ 슬슬 높아짐   │ 🛑 신규 앱 진입 차단 │
│ 앱 51개 (재앙)│ 1% (수직낙하)│ 100% 불탐   │ 🔪 기존 앱 몇 개 사살│
└──────────┴────────────┴────────────┴──────────────────────────────┘

[매트릭스 해설] 이 매트릭스가 바로 현대 OOM(Out of Memory) 킬러와 Auto-scaling(자동 확장)의 핵심 로직이다. 운영체제는 CPU 가동률이 높다고 안심해선 안 된다. 디스크 I/O가 치솟기 시작하는 '스래싱의 전조 증상'을 잡아내서, 스케줄러의 발목을 묶어버리는 브레이크 장치(Admission Control)가 반드시 필요하다.

📢 섹션 요약 비유: 엘리베이터에 꽉 타서 삐- 소리가 나면(워킹 셋 초과), 가장 나중에 탄 사람을 강제로 내리게(앱 Suspend) 해야 엘리베이터가 정상적으로 올라갑니다. 억지로 우겨 넣고 문 닫기 버튼을 연타(스래싱)해 봐야 엘리베이터는 고장 나서 평생 출발하지 못합니다.

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

실무 시나리오: Kubernetes(k8s)의 HPA와 OOM Killed 튜닝

문제의 발단: 클라우드 인프라에서 개발자가 Node.js 컨테이너 1개에 램 Limit을 안 걸어놓고 띄웠다. 이 녀석이 램을 10GB 다 빨아먹자, 같은 서버에 있던 옆 컨테이너들이 램을 못 받아 뻗기 시작했다 (그래프의 절벽 낙하).
과거의 멍청한 대응: 로드밸런서가 "어라? 1번 서버 응답이 없네? 일감이 밀렸으니 2번 서버에 컨테이너 10개 더 띄워!"라고 무지성 오토 스케일링을 때린다 (멍청한 장기 스케줄러의 재현). 2번 서버도 즉각 스래싱 절벽에 빠져 클러스터 전체가 10분 만에 잿더미가 된다 (Cascading Failure).
현대 K8s의 철벽 방어 (Memory Request/Limit):
- 클라우드 엔지니어는 이 절벽 그래프를 완벽히 이해하고 있다.
- 그래서 컨테이너를 띄울 때 resources.requests.memory="1Gi" (나 최소 1GB 램 필요해, 안 주면 안 켜질 거야!) 라고 워킹 셋(Working Set) 하한선을 명시한다.
- 쿠버네티스 스케줄러는 서버(Node)의 남은 램 총합과 저 Request를 계산해서, 램이 모자라면 아예 컨테이너를 그 서버에 띄우지 않고 대기(Pending) 상태로 막아버린다.
- 즉, OS가 절벽을 향해 달려가는 것 자체를 입구 컷(Admission Control)으로 원천 차단해 버리는 신의 한 수 아키텍처다.

실무 디버깅 팁: CPU가 낮은데 서버가 느려요?

신입 엔지니어가 top 명령어를 치고 "팀장님, CPU 사용률이 2%밖에 안 되는데 서버 접속이 안 됩니다!"라고 하면, 고수 팀장은 뒤통수를 때리며 "이 바보야, 그건 놀고 있는 게 아니라 스래싱 터져서 뇌사 상태인 거야. wa (iowait) 수치랑 디스크 불 들어온 거 봐!"라고 일갈한다. 이 그래프의 오른쪽 밑바닥 절벽(CPU 낮음 + 렉 폭발)을 경험해 본 자만이 진정한 시스템 엔지니어로 거듭난다.

📢 섹션 요약 비유: 클럽(서버) 문지기(k8s 스케줄러)가 클럽 안에 사람이 꽉 차서 발 디딜 틈이 없으면, 밖에 손님(새 프로세스)이 아무리 줄을 서서 떼를 써도 절대 문을 열어주지 않고 막아서는(Pending) 이유가 바로 안에 있는 손님들의 유흥의 질(워킹 셋)을 보호해 스래싱을 막기 위함입니다.

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

정량/정성 기대효과

구분	내용
스케줄링 패러다임의 진화	CPU 가동률만 맹신하던 바보 같은 스케줄링(Multiprogramming)의 환상을 박살 내고, 메모리 폴트율을 연계한 멀티 차원 스케줄링 시대를 엶
워킹 셋(Working Set) 모델 촉발	이 그래프의 모순을 해결하기 위해, 각 앱이 숨 쉬기 위해 필요한 '최소 영토'를 동적으로 추적하는 획기적 알고리즘 연구가 폭발함
오토 스케일링(Auto-Scaling) 지표	클라우드 환경에서 램 사용률 80% 언저리를 임계점으로 잡고, 절벽에 떨어지기 직전에 서버를 증설(Scale-out)하게 만드는 경고 나침반

결론 및 미래 전망

다중 프로그래밍 정도와 CPU 이용률 관계 그래프는, 컴퓨터 과학에서 "욕심이 과하면 모든 것을 잃는다(과유불급)"는 동양의 지혜를 가장 날카로운 2차원 수리 모델로 증명해 낸 예술 작품이다. 가상 메모리의 무한한 공간이라는 오만한 환상 속에서, 물리적 한계(디스크 I/O)라는 현실의 벽에 부딪혀 수직 낙하하는 이 뼈아픈 곡선은 수많은 운영체제 설계자들의 밤을 지새우게 했다. 이 절벽을 막기 위해 인류는 LRU, 워킹 셋 모델, PFF, OOM 킬러 등 수백 가지의 갑옷을 덧대어 왔다. 미래에 CXL 메모리 풀(Pool)이 적용되어 "내 서버 램이 꽉 차면 0.001초 만에 옆 서버 램을 빌려다 쓰는" 마법의 시대가 열린다면 이 절벽의 경사가 조금 더 완만해지겠지만, 자원의 물리적 희소성이 존재하는 한 이 우상향 후 수직 낙하하는 자연 법칙의 굴레는 IT 시스템의 영원한 숙명으로 남을 것이다.

📢 섹션 요약 비유: 이 그래프는 인간의 탐욕을 그리는 심전도입니다. 빚(가상 메모리)을 내서 주식을 1개, 10개, 100개 투자할 때마다 수익률(CPU 가동률)은 짜릿하게 우상향하지만, 내 원금(물리 램) 한도를 1원이라도 초과하여 마진콜(Page Fault)이 터지는 순간 반대매매로 내 전 재산이 1초 만에 0원(스래싱)으로 수직 낙하하는 가장 잔인하고 정직한 자본주의 곡선입니다.

📌 관련 개념 맵 (Knowledge Graph)

스래싱 (Thrashing) | 이 그래프에서 우상향하던 꼭대기를 지나 수직으로 바닥에 처박힌 우울하고 파괴적인 현상의 이름
워킹 셋 (Working Set) | 스래싱 절벽에 떨어지지 않게 하기 위해, OS가 각 앱에게 꼭 쥐어줘야 하는 최소한의 램 카드 뭉치
문맥 교환 (Context Switch) | 그래프 초반, 앱 개수가 늘어날 때 디스크 대기 시간을 피해 남의 앱을 팽팽 돌리며 상승 곡선을 만들어내는 효자 기술
OOM Killer | 절벽으로 떨어지는 것을 감지한 OS가, 자해 공갈을 막기 위해 무거운 앱 하나를 쏴 죽여 램을 확보하는 비상 탈출구
장기 스케줄러 (Long-term Scheduler) | 램 꽉 차서 버벅대는 걸 'CPU가 논다'고 오판하여 앱을 더 밀어 넣어 스래싱 절벽에 등 떠민 멍청한 주범

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

이 그래프가 무슨 뜻인가요? 엄마가 나한테 장난감 1개, 2개, 3개를 꺼내줄수록 내가 너무 재밌어서 양손을 바쁘게 움직이며(CPU 100%) 잘 노는 아름다운 그림이에요.
왜 갑자기 바닥으로 뚝 떨어져요? 내 손은 두 개(램 용량)뿐인데 엄마가 장난감을 10개나 쏟아부어서, 이 장난감 잡으려다 저 장난감 놓치고 줍기만 하느라 정작 재미있게 노는 시간은 0(스래싱)이 되어버린 슬픈 상황이에요.
어떻게 고칠 수 있나요? 욕심내지 말고, 딱 내 두 손이 감당할 수 있는 2~3개의 장난감만 꺼내놓고(워킹 셋 보장) 100% 신나게 노는 게 제일 똑똑한 방법이랍니다.