워킹 셋 모델 (Working-Set Model)

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

본질: 워킹 셋 모델(Working-Set Model)은 지역성(Locality)의 법칙을 수학적으로 구체화하여, 프로세스가 최근 $\Delta$(델타, 윈도우 크기) 시간 동안 참조한 페이지들의 고유한 집합(Working Set)을 실시간으로 추적하는 메모리 관리 기법이다.

가치: 스래싱(Thrashing)을 방지하기 위해, OS가 이 **워킹 셋의 크기($WSS$)만큼은 램 프레임을 무조건 보장(할당)**해주고, 만약 시스템 전체의 가용 램이 모든 앱의 워킹 셋 총합보다 모자라게 되면 즉시 프로세스 하나를 강제 수면(Suspend) 시켜버리는 강력한 브레이크 역할을 한다.

융합: 가상 메모리 크기(정적)가 아닌 현재 활발히 쓰는 램(동적)을 측정하므로, 전역 교체(Global Replacement)의 깡패 짓을 제어하고 CPU 스케줄러와 메모리 관리자가 대화(협업)할 수 있는 완벽한 통계적 인터페이스를 제공한다.

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

개념: 워킹 셋(Working Set)은 특정 프로세스가 렉(페이지 폴트) 없이 부드럽게 실행되기 위해 '지금 당장 반드시 물리 램에 존재해야 하는 엑기스 페이지들의 묶음'이다. OS는 과거 $\Delta$(윈도우) 번의 메모리 참조 기록을 뒤져 "최근에 이놈이 부른 페이지 번호들"을 집합으로 묶어 그 크기(Working Set Size, WSS)를 계산한다.
필요성: 아무리 CPU가 빨라도 램 프레임 3개가 필요한 앱한테 2개를 주면 무한 폴트(스래싱)가 터진다. 하지만 10개를 줘도 어차피 3개만 쓰고 7개는 놀린다. "도대체 몇 개를 주는 게 딱 맞는 할당량일까?" 균등 할당과 비례 할당은 런타임의 동적 변화를 반영하지 못해 처참히 실패했다. 피터 데닝(Peter Denning)은 "과거 일정한 시간($\Delta$) 동안 부른 놈들만 세어보면 그게 바로 지금 당장 필요한 최소한의 밥그릇(워킹 셋)이다"라는 통계적 모델을 제시하여 이 딜레마에 마침표를 찍었다.
💡 비유: 워킹 셋은 목수의 **요리사 카트(도구함)**와 같다. 목수의 창고(가상 메모리)에는 1만 개의 공구가 있다. 하지만 오늘 아침 1시간($\Delta$) 동안 지붕을 고치며 꺼내 쓴 공구는 '망치, 못, 줄자(워킹 셋)' 딱 3개뿐이다. 내일 바닥을 고칠 땐 톱과 접착제(새 워킹 셋)로 바뀔 것이다. 작업 반장(OS)은 목수에게 무식하게 공구 1만 개를 올려둘 거대한 테이블(비례 할당)을 주지 않고, **최근 1시간 동안 쓴 공구 3개만 딱 올라가는 맞춤형 미니 카트(워킹 셋 보장)**를 내어줌으로써 작업장 공간을 극한으로 아끼면서도 작업 속도를 100% 보장해 준다.
등장 배경 및 스래싱 방어의 최전선:
1. 전역 교체의 폭주: 남의 램을 무자비하게 뺏다가 다 같이 죽는 스래싱 참사가 발생함.
2. 지역성의 발견: 프로세스의 램 요구량은 시간에 따라 팽창과 수축을 반복한다는 사실 증명.
3. 워킹 셋 모델 도입: 각자의 밥그릇(WSS) 크기를 합친 값이 물리 램 총량보다 커지면, OS가 과감히 앱 하나를 쫓아내는 수학적 명분이 확립됨.

┌─────────────────────────────────────────────────────────────────────┐
│        워킹 셋(Working Set)의 윈도우($\Delta$) 이동 시각화          │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│ [ 프로세스의 페이지 참조열 (시간 흐름 ──▶) ]                        │
│ ... 2, 6, 1, 5, 7, 7, 7, 7, 5, 1, 6, 2, 3, 4, 1, 2 ...              │
│                                                                     │
│ ▶ Time 1: 윈도우 $\Delta$ = 최근 10번의 호출 (t=1 시점)             │
│   [ 2, 6, 1, 5, 7, 7, 7, 7, 5, 1 ]                                  │
│   - 워킹 셋 집합: { 1, 2, 5, 6, 7 }                                 │
│   - 워킹 셋 크기(WSS): 5장 (OS야! 나 램 5장 무조건 보장해줘!)       │
│                                                                     │
│ ▶ Time 2: 시간이 흘러 윈도우가 오른쪽으로 이동 (t=2 시점)           │
│   [ 7, 7, 5, 1, 6, 2, 3, 4, 1, 2 ]                                  │
│   - 워킹 셋 집합: { 1, 2, 3, 4, 5, 6, 7 }                           │
│   - 워킹 셋 크기(WSS): 7장 (OS야! 나 램 7장으로 늘려줘!)            │
│                                                                     │
│ ✅ 원리: 중복된 호출(7,7,7)은 1개로 친다. 워킹 셋은 프로그램의 국면 │
│    (Phase)에 따라 풍선처럼 부풀었다가 쪼그라들기를 무한 반복한다.   │
└─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 모델의 위대함은 '자기 객관화'에 있다. 과거 비례 할당은 "나 가상 메모리 10GB니까 램 10GB 줘"라며 억지를 부렸지만, 워킹 셋 모델은 "내가 비록 10GB지만, 지난 1초 동안 5장(20KB)밖에 안 불렀으니 램 5장만 있으면 살아갈 수 있어"라고 아주 정직한 견적서를 OS에게 제출한다. 이 견적서 덕분에 OS는 수십 개의 앱을 스래싱 없이 테트리스 할 수 있게 되었다.

📢 섹션 요약 비유: 회사에서 부서별 예산을 짤 때, 작년 예산 규모(가상메모리 크기)로 무작정 주는 게 아니라, **최근 3달(윈도우 $\Delta$) 동안 실제로 법인카드를 긁은 영수증 내역(참조열)**만 뽑아서 딱 그 금액(워킹 셋)만큼만 다음 달 예산으로 칼같이 입금해 주는 가장 완벽하고 합리적인 예산 통제 시스템입니다.

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

스래싱(Thrashing) 방어의 절대 공식

운영체제는 모든 프로세스의 워킹 셋 견적서(WSS)를 취합하여 시스템의 생사를 결정한다.

$D = \sum_{i=1}^{n} WSS_i$ (D: 전체 워킹 셋의 총합 / M: 메인보드에 꽂힌 물리 램 총 프레임 수)

$D \le M$ (안전 상태):
- 모두가 원하는 워킹 셋을 다 합쳐도 물리 램 총량보다 작다.
- OS: "전원에게 원하는 만큼 프레임을 뿌려라! 모두가 폴트 없이 쾌적하게 달릴 것이다."
$D > M$ (스래싱 임계점 붕괴):
- 앱을 너무 많이 띄워서(Degree 폭주), 워킹 셋 총합이 램 총량을 돌파했다.
- 냅두면 서로의 워킹 셋을 갉아먹으며 스래싱 지옥에 빠진다.
- OS의 철퇴 (Suspend/Swap-out): OS는 고민 없이 프로세스 중 하나를 찝어서 강제 수면(Suspend) 시키고, 그놈이 갖고 있던 램을 모조리 압수하여 스왑으로 쫓아버린다. 쫓겨난 놈의 WSS가 빠지면서 다시 $D \le M$ 상태로 복귀해 서버 전체가 스래싱의 절벽에서 구조된다.

워킹 셋 추적의 하드웨어적 한계와 근사치(Approximation)

이론은 완벽하지만 구현은 지옥이다.

$\Delta$가 10,000번 호출이라면, CPU가 메모리를 찌를 때마다 최근 1만 번의 기록을 저장하고 큐를 밀어내야 한다 (Overhead 폭발).
이를 해결하기 위해 OS는 **'타이머 인터럽트'와 '참조 비트(R Bit)'**를 이용한 근사치 기법을 쓴다.
구현 꼼수:
1. 페이지마다 '참조 비트' 외에 2비트짜리 작은 히스토리 변수를 둔다.
2. 5초마다 타이머가 깨어나 R 비트를 읽고 0으로 리셋한다.
3. 최근 3번의 타이머(15초) 동안 R 비트가 1번이라도 1로 켜졌던 페이지들은 모조리 워킹 셋 집합에 포함시킨다.
4. 과거 15초 동안 000을 기록한 놈은 워킹 셋에서 탈락시켜버린다(Drop).
📢 섹션 요약 비유: 엘리베이터(램)의 한계 중량(M)이 1,000kg인데, 타려는 15명 승객들의 몸무게(WSS)를 다 더했더니 1,100kg이 나왔습니다. 이때 억지로 다 태워서 엘리베이터가 고장 나게(스래싱) 두는 게 아니라, 마지막에 탄 제일 무거운 아저씨 1명(Suspend)을 강제로 내리게 해서 남은 14명을 안전하게 올려보내는 냉혹한 하중 계산 공식입니다.

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

윈도우 크기 ($\Delta$)의 딜레마

워킹 셋의 정확도는 $\Delta$(관찰하는 기간)를 얼마로 잡느냐에 따라 천국과 지옥을 오간다.

$\Delta$ 윈도우 크기	현상 및 문제점	결과
너무 작음 (예: 10)	방금 불린 10개만 보므로, 전체 `for` 루프를 다 못 품음	워킹 셋이 축소 측정되어 램을 뺏기고 폴트가 폭발함
적당함 (예: 10,000)	한 국면(Phase)의 전체 지역성을 완벽하게 품음	가장 이상적인 램 할당이 이루어짐 (최적)
너무 큼 (예: 무한대)	과거의 쓰레기 데이터까지 몽땅 워킹 셋에 포함시켜버림	안 쓰는 램까지 껴안고 있어 타 앱이 램을 못 받아 굶어 죽음

비교 1: 워킹 셋(Working Set) vs 페이지 부재 빈도(PFF)

두 알고리즘 모두 "스래싱을 막기 위해 런타임에 램을 조절한다"는 철학은 같지만, 접근 방향이 다르다. (PFF는 다음 키워드에서 상세 서술)

┌──────────┬────────────┬────────────┬──────────────────────────────────────────────┐
│ 모델       │ 측정 대상    │ 동작 원리    │ 시스템 오버헤드                        │
├──────────┼────────────┼────────────┼──────────────────────────────────────────────┤
│ Working Set│ 과거 참조열   │ 윈도우 내의 집합을 계속 계산 유지│ 무거움 (계속 스캔)│
│ PFF (빈도) │ 폴트가 나는 간격│ 폴트 잦으면 램 주고, 적으면 뺏음│ 🟢 매우 가벼움   │
└──────────┴────────────┴────────────┴──────────────────────────────────────────────┘

[매트릭스 해설] 워킹 셋은 "네가 필요한 게 이거지? 다 줄게!"라는 꼼꼼한 비서 스타일이고, PFF는 "너 지금 폴트 나서 아파? 약(램) 줄게! 안 아파? 약 뺏는다!"라는 증상 치료식 의사 스타일이다. 실무 커널에서는 워킹 셋의 무거운 오버헤드를 견디지 못하고, 구현이 훨씬 가벼운 PFF 기반의 로직으로 대체하여 융합 사용하는 경우가 많다.

📢 섹션 요약 비유: $\Delta$(윈도우 크기)를 1일로 잡으면 내가 어제 먹은 음식(워킹 셋)만 기억해서 오늘 또 먹으려니 영양 불균형이 오고, $\Delta$를 10년으로 잡으면 10년 전에 먹던 이유식까지 오늘 밥상에 올라와 상다리가 부러집니다. 적당히 '최근 한 달 치 식단'을 유지하는 것이 완벽한 윈도우 튜닝의 예술입니다.

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

실무 시나리오: 윈도우즈(Windows OS)의 Working Set 튜닝

리눅스가 PFF나 전역 교체에 치중했다면, Microsoft의 Windows OS는 전통적으로 이 워킹 셋(Working Set) 모델을 OS 핵심 아키텍처로 신봉해 왔다.

작업 관리자의 비밀:
- 윈도우 작업 관리자(Task Manager)를 열어 프로세스 탭의 메모리 컬럼을 보면, 그것이 가상 메모리 총량이 아니라 바로 "현재 워킹 셋(Working Set)" 크기다.
Min / Max Working Set의 강제:
- 윈도우 커널은 프로세스를 띄울 때 기본적으로 최소 워킹 셋(Min)과 최대 워킹 셋(Max)을 부여한다.
- 램이 모자라면 OS가 프로세스들의 워킹 셋을 강제로 Min(최소 뼈대) 크기로 쥐어짜서(Trimming) 빈 램을 확보한다.
C++ Win32 API 튜닝 (SetProcessWorkingSetSize):
- 게임 개발자나 실시간 음원 처리 개발자는 윈도우 OS가 자기 램을 뺏어가는 걸 막기 위해 이 함수를 호출한다.
- "OS 형님, 내 게임의 Min Working Set을 2GB로 락(Lock) 걸어주십쇼!"
- 이 락을 걸면 윈도우가 아무리 램이 쪼들려도 절대 이 게임의 2GB 프레임을 스왑으로 쫓아내지 않는다(Page Fault 원천 차단). 무거운 PC 게임이 윈도우에서 렉 없이 돌아가는 궁극의 실무 API다.

안티패턴: 워킹 셋을 초과하는 잦은 Full Scan

데이터베이스 서버에서 인덱스(Index)가 깨져서 10GB짜리 테이블을 Full Table Scan 하는 악성 쿼리가 터졌다고 치자. 이 쿼리는 평소의 얌전한 워킹 셋(100MB)을 뚫고, 10GB 전체의 페이지를 1장씩 훑고 지나간다. 워킹 셋 모델 입장에선 "헉! 이놈의 워킹 셋이 10GB로 팽창했다!"라고 착각하고, 남의 램을 모조리 뺏어다 얘한테 10GB를 쏟아붓는다. 정작 이 쿼리는 10GB를 한 번 읽고 버릴 쓰레기인데 말이다. 이로 인해 서버 전체의 워킹 셋이 붕괴하며 대재앙(Cache Pollution)이 벌어진다.

📢 섹션 요약 비유: 윈도우 OS는 식당 주인으로서 손님(프로세스)마다 "이 손님은 밥그릇 3개(Min) ~ 5개(Max)면 충분해"라고 워킹 셋을 철저히 관리합니다. 그런데 갑자기 푸드파이터(풀 스캔 쿼리)가 들어와서 그릇 1,000개를 달라고 난동을 부리면, 주인이 당황해서 다른 손님 밥그릇을 다 뺏어주는 바람에 식당이 망해버리는 치명적 안티패턴입니다.

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

정량/정성 기대효과

구분	내용
스래싱(Thrashing) 원천 방어	$\sum WSS > M$ 공식을 통해 스래싱 임계점을 수학적으로 탐지하고 프로세스를 정지(Suspend)시켜 시스템 뇌사를 방어
다중 프로그래밍 최적화	과할당(Over-allocation)의 늪에서 벗어나, 램 잔고가 허락하는 한계점(Knee)까지만 앱을 띄우는 이상적인 스케줄링 달성
지역성(Locality)의 수치화	막연했던 '지역성'이라는 개념을 $\Delta$(윈도우)와 페이지 번호 집합으로 치환하여, OS가 코드로 다룰 수 있는 정량적 지표로 승화

결론 및 미래 전망

워킹 셋 모델 (Working-Set Model)은 "과거의 기억으로 현재의 밥그릇을 잰다"는 통계적 우아함을 뽐내며, 가상 메모리 스래싱 문제에 종지부를 찍은 컴퓨터 구조론의 위대한 이정표다. 1968년 피터 데닝이 이 모델을 발표한 이후, 램(RAM)은 무작정 뺏고 뺏기는 투기장이 아니라 각 프로세스의 '호흡권(Working Set)'을 존중해 줘야만 생태계가 유지된다는 진리가 확립되었다. 비록 구현 오버헤드 때문에 순수 워킹 셋 알고리즘이 리눅스 커널에서 100% 돌아가진 못하지만, 이 철학은 PFF, 윈도우즈의 워킹 셋 튜닝, 가비지 컬렉터의 세대별(Generational) 힙 관리 등 모든 메모리 최적화 기법의 바닥에 거대한 뿌리로 자리 잡고 있다.

📢 섹션 요약 비유: 심해 잠수부(프로세스)를 바다(가상 메모리)에 넣을 때, 무작정 잠수부 숫자를 늘려 산소(물리 램)가 모자라 다 같이 질식사(스래싱)하게 두는 대신, 잠수부 각자의 현재 폐활량(워킹 셋)을 실시간으로 측정하여 산소 탱크 한계에 다다르면 마지막 잠수부를 밧줄로 강제 인양(Suspend)시켜 모두를 살려내는 가장 완벽한 해상 안전 시스템입니다.

📌 관련 개념 맵 (Knowledge Graph)

스래싱 (Thrashing) | 워킹 셋 총합이 물리 램을 초과했을 때 발생하는 시스템 마비로, 워킹 셋 모델이 세상에 태어난 1순위 타겟 적군
참조 지역성 (Locality) | 프로그램이 $\Delta$ 윈도우 동안 특정 페이지들만 뺑글뺑글 맴돈다는 절대 법칙으로 워킹 셋의 존재 이유
PFF (페이지 부재 빈도) | 워킹 셋의 복잡한 윈도우 계산을 포기하고, 그냥 폴트 터지는 횟수만 보고 램을 줬다 뺏는 가성비 워킹 셋 짝퉁 기술
Suspend (강제 수면) | $\sum WSS > M$ 이 되어 시스템이 폭발하기 직전, OS가 앱 하나를 골라 기절시키고 램을 몽땅 회수하는 최후의 방어기제
윈도우즈 작업 관리자 | 프로세스 탭에서 보여주는 '메모리 사용량'이 바로 이 워킹 셋(WSS)의 현재 크기를 실시간으로 출력해 주는 모니터

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

워킹 셋이 뭔가요? 내가 장난감 방에 1,000개의 장난감이 있어도, 방금 전 10분(윈도우) 동안 진짜로 내 손에 쥐고 논 '최애 장난감 3개'의 묶음이에요.
왜 이걸 계산하나요? 엄마(OS)가 방이 어질러졌다고 장난감을 다 창고(디스크)에 버리려 할 때, "엄마! 이 3개(워킹 셋)만큼은 지금 갖고 노는 거니까 절대 버리면 안 돼!"라고 방어막을 치려고요.
만약 엄마가 3개 중 하나라도 버리면요? 나는 그림 그리다 말고 크레파스 찾으러 창고까지 가야 해서 엉엉 울고(페이지 폴트), 결국 아무것도 못 하고 뻗어버리게(스래싱) 된답니다.