다중 프로그래밍 정도 (Degree of Multiprogramming)

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

본질: 다중 프로그래밍 정도 (Degree of Multiprogramming, DOM)는 운영체제가 **"현재 메인 메모리(RAM)에 동시에 적재하여 스케줄링 풀(Pool)로 관리하고 있는 활성 프로세스의 총개수"**를 의미하는 거시적 성능 지표다.

가치: 이 수치가 1이면 낡은 MS-DOS 시절처럼 한 번에 한 가지 일밖에 못 하는 상태고, 수치가 높아질수록 CPU 유휴 시간(Idle Time)을 다른 프로세스가 메꿔주어 시스템의 전체 처리량(Throughput)이 정비례하여 솟구치는 마법을 부린다.

융합: 하지만 이 수치를 물리적 RAM의 한계 이상으로 무리하게 끌어올리면, 프로세스들이 각자의 최소 필요 메모리(Working Set)조차 확보하지 못해 디스크만 긁어대는 스래싱(Thrashing) 현상을 유발하므로, 장기 스케줄러(Long-term Scheduler)의 섬세한 통제가 필수적이다.

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

개념: 컴퓨터 시스템 안에서 디스크에 잠들어 있지 않고, 실제로 메모리를 차지한 채 실행을 위해 CPU를 노리고 있는 활성 프로세스(Active Process)의 숫자를 뜻한다.
필요성: CPU는 빛의 속도로 계산하지만, 디스크에서 파일을 읽거나 네트워크 통신을 하는 I/O 작업은 거북이처럼 느리다. 만약 메모리에 프로세스를 딱 1개만 올려놓는다면, 그 프로세스가 I/O를 할 때마다 CPU는 할 일이 없어서 멍을 때린다(낭비). 이 비싼 CPU를 1초도 쉬지 않게 100% 혹사시키려면, A가 쉴 때 B를 시키고 B가 쉴 때 C를 시킬 수 있도록 메모리에 미리 여러 개의 작업(A, B, C...)을 대기시켜 놔야 했다.
💡 비유: 저글링 쇼를 하는 광대(CPU)가 공(프로세스)을 하늘에 던질 때, **'현재 광대의 양손과 공중에 돌고 있는 전체 공의 개수'**가 바로 다중 프로그래밍 정도다. 공이 1개면 광대는 너무 심심하고, 공이 3~5개면 쉴 틈 없이 멋진 쇼(효율 극대화)가 연출되지만, 100개를 던지면 다 땅에 떨어져서 쇼가 망한다(스래싱).
등장 배경: 1960년대 비싼 메인프레임 컴퓨터의 본전을 뽑기 위해 "어떻게 하면 CPU를 놀리지 않을까?"를 연구하던 학자들은, 메모리를 조각내어 여러 프로그램을 동시에 올려두는 방식(Multiprogramming)을 고안했다. 이때 "과연 몇 개를 올리는 것이 최적인가?"를 증명하기 위한 척도로 이 단어가 탄생했다.

  [다중 프로그래밍 정도(DOM)에 따른 CPU의 시간 활용 변화]

  [ 1. 단일 프로그래밍 (DOM = 1) ]
  P1: [██ 연산 ██] [░░ I/O 대기 ░░] [██ 연산 ██] 
  CPU: 일함       ( 🚨 CPU 놀고 있음 ) 일함      ─▶ CPU 이용률 50%

  [ 2. 다중 프로그래밍 (DOM = 2) ]
  P1: [██ 연산 ██] [░░ I/O 대기 ░░] [██ 연산 ██]
  P2: (대기 중)     [██ 연산 ██] (P1이 쉴 때 P2가 틈새를 치고 들어옴!)
  CPU: 일함        일함            일함      ─▶ CPU 이용률 100% 🚀

[다이어그램 해설] 이것이 운영체제가 존재하는 가장 본질적인 이유다. I/O 대기 시간이라는 어쩔 수 없는 '공백'을, 다른 프로세스를 밀어 넣음으로써(문맥 교환) 메꿔버리는 것이다. DOM이 2가 되는 순간 시스템의 처리량(Throughput)은 마법처럼 2배로 뛴다.

📢 섹션 요약 비유: 세탁기 1대(CPU)를 쓸 때, 빨랫감이 다 모일 때까지 기다렸다 돌리면 세탁기는 계속 놉니다. 하지만 동네 사람 10명(DOM=10)이 각자 빨랫감을 들고 줄 서 있으면, 앞사람 빨래가 끝나자마자 바로 다음 사람 빨래를 돌릴 수 있어서 세탁기가 24시간 풀가동하며 돈을 쓸어 담게 됩니다.

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

DOM과 CPU 이용률(Utilization)의 수학적 상관관계

CPU 이용률을 예측하는 유명한 확률 모델 수식이 있다. 한 프로세스가 I/O 대기하며 CPU를 쓰지 않을 확률(I/O Wait Ratio)을 $p$ 라고 하자. (보통 대화형 프로그램에서 $p = 0.8$ 정도로, 80%는 키보드를 기다리며 멍때린다.)

CPU 이용률 (CPU Utilization) = $1 - p^N$ (N은 다중 프로그래밍 정도, 즉 DOM)

[수식 시뮬레이션 ($p = 0.8$ 일 때)]

DOM ($N=1$): $1 - 0.8^1 = 0.2$ ─▶ CPU 이용률 20% (80%의 시간을 낭비함)
DOM ($N=2$): $1 - 0.8^2 = 1 - 0.64 = 0.36$ ─▶ CPU 이용률 36%
DOM ($N=5$): $1 - 0.8^5 \approx 0.67$ ─▶ CPU 이용률 67%
DOM ($N=10$): $1 - 0.8^{10} \approx 0.89$ ─▶ CPU 이용률 89% (거의 풀가동!)

수학이 증명하듯, $p$가 높은(I/O가 많은) 환경에서는 메모리에 프로세스를 더 많이 우겨넣을수록(N을 늘릴수록) CPU 효율이 기하급수적으로 좋아진다.

스케줄러의 통제권 (Who Controls DOM?)

DOM 수치를 마음대로 늘렸다 줄였다 하는 통제권을 가진 녀석이 바로 **장기 스케줄러 (Long-term Scheduler, Job Scheduler)**다.

새로운 프로그램(Job)을 디스크에서 메모리로 올릴지 말지를 결정한다.
장기 스케줄러가 "통과!"를 많이 외치면 DOM이 상승하고, "잠깐 대기!"를 외치면 DOM이 유지된다.
CPU 바운드 프로세스만 10개 올리면 1개만 돌고 9개가 줄을 서서 낭비된다. I/O 바운드 프로세스만 10개 올리면 10개가 전부 마우스만 기다려서 CPU가 논다. 장기 스케줄러는 이 두 가지 성향의 프로세스 비율을 적절히 섞어서(Mix) DOM을 관리하는 지휘자다.
📢 섹션 요약 비유: 나이트클럽 매니저(장기 스케줄러)가 물관리(DOM 조절)를 하는 것과 같습니다. 클럽(메모리) 안에 춤추는 사람(CPU Bound)과 술만 마시는 사람(I/O Bound)의 비율을 절묘하게 섞어서 입장시켜야 클럽 분위기가 가장 핫(이용률 100%)해집니다.

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

컴퓨터 과학도들이 면접에서 가장 많이 털리는 용어 3형제다.

용어	영문 명칭	본질적 철학 및 타깃	동작 핵심
다중 프로그래밍	Multiprogramming	CPU가 '쉬지 않게' 만드는 것 (효율성)	A가 I/O로 스스로 멈출 때만 B로 넘어감 (비선점/선점 무관)
시분할 시스템	Time-sharing	사람들에게 '동시에 하는 것처럼 속이는' 것 (응답성)	A가 일하고 있어도 시간(Quantum)이 다 되면 강제로 뺏어서 B에게 줌 (선점 필수)
다중 처리	Multiprocessing	물리적인 CPU 코어(손)의 '개수'를 늘리는 것	여러 프로세스가 말 그대로 물리적으로 동시에(Parallel) 실행됨

현대의 윈도우/리눅스 PC는 이 3가지가 모두 섞인 혼종이다. "물리적 코어가 8개인 다중 처리 환경 위에서, 메모리에 100개의 프로세스를 올려놓는 **다중 프로그래밍(DOM=100)**을 달성하고, 각 코어는 이들을 10ms 단위로 썰어 돌리는 시분할 시스템"으로 동작한다.

DOM 상승의 함정: 스래싱 (Thrashing)

이론상 DOM을 무한대로 올리면 CPU 이용률이 100%에 수렴해야 한다. 그러나 현실엔 RAM 크기라는 물리적 한계가 있다. DOM이 임계점을 넘어가면, 각 프로세스가 배정받는 메모리 조각(Frame)이 너무 작아져서 "명령어 1줄 읽고 디스크 스왑 ─▶ 다음 줄 읽고 또 스왑"을 반복하는 스래싱(Thrashing) 현상이 터진다. DOM이 100일 때 최고였던 시스템이, DOM이 101이 되는 순간 CPU 이용률이 0%로 수직 낙하하며 서버가 뻗어버리는 것이다.

📢 섹션 요약 비유: 고속도로 통행량(DOM)은 적당히 많을 때 물동량(효율)이 최고를 찍습니다. 하지만 차가 너무 많아져 도로 수용량(RAM)을 초과하는 순간 꽉 막힌 주차장(스래싱)이 되어 물동량은 0이 됩니다. 경찰(OS)은 통행량을 늘리되 막히기 직전에 톨게이트를 닫아 통행량(DOM)을 강제 제한해야 합니다.

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

실무 시나리오

장기 스케줄러의 죽음과 중기 스케줄러(Swapper)의 등장: 현대 데스크톱 OS나 스마트폰(iOS, Android)에는 과거 메인프레임 시절의 깐깐한 "장기 스케줄러(입장 거부 관리자)"가 아예 존재하지 않는다.
- 사용자의 오만: 유저가 앱 아이콘을 클릭하면 OS는 묻지도 따지지도 않고 무조건 메모리에 올린다(DOM 무한 상승).
- 실무 아키텍처 (중기 스케줄러의 투입): DOM이 걷잡을 수 없이 높아져 램이 터지기 직전이 되면, **중기 스케줄러 (Medium-term Scheduler)**가 깨어난다. 이 녀석은 현재 메모리에서 놀고 있는(Sleep) 프로세스들을 골라 통째로 압축해서 디스크(Swap 영역)로 쫓아내 버린다(Swap-out). 이를 통해 강제로 메모리 공간을 확보하여 살아남은 프로세스들의 DOM 한계치를 방어해 낸다.
웹 서버 (Tomcat, Apache)의 Max Connections 및 Thread Pool 튜닝: 실무 백엔드에서 DOM을 통제하는 것은 OS가 아니라 개발자가 짠 '스레드 풀'이다.
- 서버 폭파 사례: 트래픽이 몰릴 때마다 스레드를 무한 생성(Thread per request)하게 짜면 DOM이 수만 개로 치솟아 서버가 OOM으로 죽는다.
- 아키텍트 조치: application.yml에서 server.tomcat.threads.max=200을 설정한다. 이는 **"내 웹 서버 애플리케이션의 유효 DOM을 절대 200 이상으로 올리지 않겠다"**는 선언이다. 201번째 고객은 OS 큐에서 얌전히 대기하게 하여, 앞선 200명이 스래싱 없이 빛의 속도로 응답을 받아 나갈 수 있게 지켜주는 현대판 DOM 컨트롤 아키텍처다.

  ┌──────────────────────────────────────────────────────────────────┐
  │     부하(Load) 급증 시 아키텍트의 DOM(Degree of MP) 제어 트리    │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │   [장애 현상: 동시 접속자가 1만 명으로 폭주하여 서버 응답 지연]  │
  │                │                                                 │
  │                ▼ 1. 서버 메모리(RAM) 용량 확인                   │
  │      [ 메모리가 남아돈다 (가용량 충분) ]                         │
  │       ├─▶ 상태: CPU가 100%를 못 치고 있음. DOM이 너무 낮음.      │
  │       └─▶ 액션: `Max Threads` 설정치를 대폭 올려서(DOM 증가)     │
  │                 메모리를 깎아먹더라도 CPU 연산량을 극한으로 땡김!│
  │                                                                  │
  │      [ 메모리가 90% 이상 꽉 차서 스왑(Swap)이 돌고 있다 ]        │
  │       ├─▶ 상태: 🚨 스래싱(Thrashing) 임계점을 돌파함!            │
  │       │                                                          │
  │       ▼ 2. 아키텍트의 결단 (Down-sizing)                         │
  │       ▶ 액션: 역설적이지만 `Max Threads` 수치를 절반으로 낮춤.   │
  │       ▶ 효과: 강제로 DOM을 낮춰 각 스레드가 쓸 메모리를 확보해줌.│
  │               스왑이 멈추고 캐시 히트율이 오르며 서버 부활!      │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "접속자가 많으니 스레드를 더 늘리자"는 하수의 발상이다. 메모리가 부족할 때 DOM을 올리는 것은 불난 집에 기름을 붓는 것이다. 시니어 엔지니어는 램(RAM)의 수용 한계를 정확히 계산하여, 시스템이 감당할 수 있는 **'최적의 DOM 임계점(Sweet Spot)'**을 찾아내고, 그 선을 넘는 트래픽은 가차 없이 대기 큐(Rate Limiting)로 던져버린다.

📢 섹션 요약 비유: 물이 새는 배에 짐(DOM)을 계속 실으면 가라앉습니다. 이때 승객들이 춥다고 난방을 틀어달라(스레드 증설)고 해도 선장은 단호히 무거운 짐을 바다로 던져버려야(DOM 감소 튜닝) 배가 목적지에 무사히 도착할 수 있습니다. 살기 위해선 때론 덜어내는 것이 정답입니다.

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

기대효과

다중 프로그래밍 정도(DOM)를 시스템 하드웨어 스펙(CPU 코어 수, RAM 크기)에 딱 맞는 스위트 스팟(Sweet Spot)으로 튜닝하면, 디스크 I/O에 낭비되는 시간을 완벽하게 숨기면서 CPU 이용률을 99%로 유지하는 극강의 가성비(Cost-Effectiveness) 런타임 환경을 구축할 수 있다.

결론 및 미래 전망

DOM이라는 개념은 1960년대 비싼 메인프레임을 놀리지 않기 위해 탄생한 클래식 중의 클래식이다. 시대가 흘러 메모리가 테라바이트(TB) 단위로 커지고 멀티코어가 기본이 되면서, OS 커널 단에서 이 수치를 깐깐하게 막는(장기 스케줄러) 짓은 사라졌다. 하지만 이 철학은 클라우드 네이티브(Cloud Native) 환경으로 고스란히 이식되었다. 쿠버네티스(K8s) 클러스터에서 한 노드에 띄울 수 있는 파드(Pod)의 최대 개수(max-pods), 혹은 AWS Lambda의 동시 실행(Concurrency) 제한 설정 들이 바로 21세기형 '다중 프로그래밍 정도'의 통제 수단이다. 무한 확장이 가능해 보여도 결국 물리적 자원은 유한하기 때문에, 아키텍트가 적정 DOM을 통제해야만 시스템 붕괴를 막을 수 있다는 진리는 영원히 변하지 않을 것이다.

📢 섹션 요약 비유: 과거에는 동네 목욕탕(OS) 주인이 탕 안의 사람 수를 직접 세며(DOM) 꽉 차면 손님을 안 받았습니다. 지금은 거대한 워터파크(클라우드)가 되어 자동 입장권(K8s)을 팔지만, 결국 락커룸(메모리) 개수라는 물리적 한계가 존재하기 때문에 매표소 컴퓨터가 락커룸 수를 1단위로 깐깐하게 통제하는(현대판 DOM 제어) 원리는 완전히 똑같습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
스래싱 (Thrashing)	DOM을 무지성으로 너무 높게 올렸을 때 메모리가 부족해져서 시스템이 파멸하는 치명적인 부작용 현상이다.
장기 스케줄러 (Long-term Scheduler)	하드 디스크에 있는 프로그램을 램으로 올릴지 말지 결정하여 DOM의 전체 숫자를 조절하던 과거의 밸브 관리자다.
중기 스케줄러 (Swapper)	DOM이 너무 높아져 램이 터질 것 같을 때, 램에 있는 놈을 디스크로 강제로 내쫓아 DOM을 낮춰주는 현대의 구원투수다.
CPU 이용률 (Utilization)	DOM을 올리는 궁극적인 목적. I/O 대기 시간을 겹쳐서 CPU가 1초도 안 쉬게 100% 혹사시키기 위함이다.
스레드 풀 (Thread Pool)	OS가 통제하던 DOM을 애플리케이션 개발자가 직접 통제하기 위해 도입한 백엔드 아키텍처의 필수 패턴이다.

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

세탁기(CPU) 1대로 빨래를 할 때, 내 빨랫감만 넣고 돌리면 물이 다 찰 때까지(I/O 대기) 세탁기가 멍하니 노는 시간이 생겨요.
그래서 동네 사람 5명(다중 프로그래밍 정도 = 5)이 세탁기 앞에 대기하면서, 세탁기가 잠깐 쉴 때마다 잽싸게 자기 빨래를 밀어 넣는 거예요!
덕분에 세탁기는 단 1초도 쉬지 않고 24시간 팽팽 돌아가면서 엄청난 양의 빨래를 해치울 수 있는 최고 효율의 세탁소가 된답니다!