스래싱 (Thrashing)

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

본질: 스래싱 (Thrashing)은 다중 프로그래밍 환경에서 너무 많은 프로세스가 동시에 실행되어 물리적 램(RAM)이 고갈되었을 때, CPU가 실제 연산(유저 코드)은 전혀 하지 못하고 디스크와 램 사이에서 페이지(데이터)를 교체하는 데만 시스템 자원을 100% 탕진하는 붕괴 상태다.

가치: 운영체제의 요구 페이징(Demand Paging)이 가진 "마법 같은 무한 메모리 환상"이 물리적 한계에 부딪혔을 때 나타나는 가장 파괴적인 역효과를 보여주며, 시스템 아키텍트가 메모리 용량 산정과 과부하 차단(Load Shedding)을 설계하는 절대적 기준점이 된다.

융합: 이 문제를 막기 위해 과거에는 워킹 셋(Working Set) 모델이나 페이지 부재 빈도(PFF) 알고리즘을 운영체제에 내장했으나, 현대 클라우드 환경에서는 이를 포기하고 스왑 메모리(Swap)를 아예 비활성화(Off)한 뒤 메모리가 부족하면 OOM Killer로 컨테이너를 가차 없이 죽여버리는 극단적 실용주의로 융합되었다.

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

개념: 프로세스 실행에 필요한 최소한의 페이지 프레임조차 램(RAM)에 할당받지 못해, 명령어를 실행할 때마다 페이지 폴트(Page Fault)가 발생하여 디스크 I/O 대기열에 갇혀버리는 악순환이다. "CPU가 일은 안 하고 짐만 나르는 상태"다.
필요성: 컴퓨터 과학자들은 페이징 기법 덕분에 램보다 큰 프로그램을 맘껏 띄우며 환호했다. 그런데 "여러 개 띄워도 잘 도니까, 아예 1,000개를 띄워보자!"라고 욕심을 내자, 어느 순간 컴퓨터가 굉음을 내며 마우스 커서조차 멈추는 기괴한 현상이 발생했다. 시스템 설계자들은 CPU 이용률이 급락하는 이 치명적 절벽(Thrashing Point)을 수학적으로 분석하고 통제할 안전장치가 절실했다.
💡 비유: 주방(RAM)이 너무 좁은데 무리해서 10가지 요리(프로세스)를 동시에 하려다 보니, 도마에 고기를 올리면 야채를 창고(Disk)에 넣어야 하고, 야채를 꺼내면 고기를 다시 창고에 넣어야 해서 **'정작 칼질(CPU 연산)은 1번도 못 하고 하루 종일 창고만 왔다 갔다 하며 땀을 뻘뻘 흘리는 헛고생'**과 정확히 같다.
등장 배경: 1968년 피터 데닝(Peter Denning)이 가상 메모리 시스템의 성능 붕괴 현상을 'Thrashing(요동치다, 몸부림치다)'이라 명명하며 학계에 보고했다. 이 현상은 운영체제가 "다중 프로그래밍 정도(Degree of Multiprogramming)"를 무한정 높일 수 없다는 물리적 한계를 인류에게 각인시킨 역사적 사건이다.

  [다중 프로그래밍 정도(Multiprogramming)와 CPU 이용률의 스래싱 곡선]

      100% ┼                     (C) 스래싱 발생! (수직 낙하)
           │   (A) 정상 구간        . 
  CPU      │     .··············  │           ..··(↓) 
  이용률    │   .· (↑) 이용률     │        .··   
           │  .·                 │      .·     
           │ .·                  ▼   .·        
           │.·                  (B) 임계점 (Thrashing Point)
        0% ┼───────────────────────────────────────────── 
             0        10        20        30         40
                   메모리에 띄운 프로그램(프로세스) 개수

[다이어그램 해설] 이 그래프는 OS 역사상 가장 유명한 절벽이다.

(A) 구간: 프로그램을 많이 띄울수록 CPU가 쉴 틈 없이 일해서 이용률이 정비례로 솟구친다 (이상적 가상 메모리).
(B) 임계점: RAM의 모든 빈 공간이 사라진 한계점이다.
(C) 구간: 스케줄러가 "CPU가 조금 노네? 프로그램 하나 더 띄워!"라고 착각(오판)하여 프로그램을 하나 더 밀어 넣는 순간, 기존 놈들의 메모리 밥그릇까지 뺏어가며 전원이 연쇄 페이지 폴트를 일으켜 CPU 이용률이 0%로 처박힌다.
📢 섹션 요약 비유: 도로(RAM)에 차가 적당히 많으면 통행량(CPU 이용률)이 극대화됩니다. 하지만 꽉 막힌 도로에 억지로 차(프로세스)를 더 집어넣으면 꼬리물기(페이지 폴트)가 터져서 도로 전체가 주차장이 되어 단 1대도 움직이지 못하는 헬게이트(스래싱)가 열립니다.

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

스래싱의 연쇄 붕괴 (Domino Effect) 메커니즘

스래싱은 운영체제 스케줄러의 멍청한 '오판' 때문에 눈덩이처럼 커지는 악순환(Vicious Cycle)이다.

메모리 부족: 너무 많은 프로세스가 떠서 각자 쓸 메모리(RAM)가 쪼들린다.
페이지 폴트 떡상: A 프로세스가 명령을 실행하려는데 메모리가 없어서 페이지 폴트(인터럽트)를 낸다. OS는 A를 Sleep 시키고 B를 깨운다.
CPU 유휴 (Idle): B도 메모리가 없어서 폴트를 낸다. C도 폴트를 낸다. 결국 큐에 있는 모든 놈들이 디스크(하드)에서 데이터가 오길 기다리며 다 같이 Sleep(I/O Block) 상태에 빠진다. CPU는 할 일이 없어서 텅텅 논다 (이용률 10% 미만 추락).
🚨 스케줄러의 오판 (치명타): OS 스케줄러가 보기에 "어? CPU가 팽팽 노네? 일을 덜 시켰나 보군!" 하고 멍청하게 새로운 프로세스를 Ready 큐에 더 던져 넣는다(다중 프로그래밍 정도 강제 상승).
파국: 안 그래도 좁은 램에 새 놈까지 들어와서 기존 놈들의 페이지를 쫓아낸다. 디스크 대기열은 10km로 늘어나고, 컴퓨터는 하드 긁는 굉음만 내며 완전히 얼어붙는다.

운영체제의 방어막: 지엽적 교체 (Local Replacement)

초기 OS는 램이 꽉 차면 "아무 놈이나 만만한 놈 거 뺏어(Global Replacement)"라는 정책을 썼다. 이 때문에 A가 메모리 부족을 겪으면 B, C의 메모리를 뺏어대어 다 같이 죽는 스래싱 전염병이 터졌다. 현대 OS는 이 전염을 막기 위해 지엽적 교체(Local Replacement) 옵션을 쓴다. A가 메모리가 부족하면, 무조건 A가 쓰고 있던 낡은 메모리만 버리게 하여 B와 C에게 불똥(스래싱)이 튀는 것을 구조적으로 격리해 버린다.

📢 섹션 요약 비유: 회사가 적자(페이지 폴트) 나서 직원들이 다 놀고(CPU 유휴) 있는데, 멍청한 사장(스케줄러)이 "일이 없나 보네? 신입사원(새 프로세스) 더 뽑아서 일 시켜!"라고 하는 꼴입니다. 신입이 오면 기존 직원 책상(RAM)마저 뺏기게 되어 회사가 연쇄 부도로 망해버립니다.

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

스래싱 예방을 위한 2대 학술적 알고리즘

운영체제가 스래싱 임계점(B)을 넘지 않게 하려면, "각 프로세스가 숨을 쉬기 위해 최소한 몇 개의 페이지 프레임이 필요한가?"를 알아야 한다.

비교 항목	워킹 셋 (Working Set) 모델	PFF (Page Fault Frequency) 알고리즘
설계 철학	"얘가 최근에 많이 본 페이지들을 한 세트로 묶어서 챙겨주자!"	"얘가 페이지 폴트를 얼마나 자주 내는지 그 빈도를 보고 밥을 주자!"
추적 대상	최근 $\Delta$ 시간 동안 참조된 페이지 번호 목록	프로세스 단위의 페이지 폴트 발생 횟수(Rate)
조치 방법	워킹 셋 덩어리 크기만큼의 빈 프레임이 없으면 아예 프로세스를 통째로 Sleep 시킴(Swap-out).	폴트 빈도가 상한선 넘으면 램(Frame)을 더 주고, 하한선 밑이면 램을 뺏어옴.
장점	참조의 지역성을 완벽히 활용하여 스래싱을 100% 방어함.	구현이 워킹 셋보다 훨씬 간단하고 직접적임.
단점 (오버헤드)	매 메모리 참조마다 윈도우 크기를 추적해야 하므로 CPU 부담이 살인적임.	폴트가 터진 뒤에야 수습하는 사후 약방문 격임.

스래싱(Thrashing) vs 교착 상태(Deadlock)의 본질적 차이

초보자들은 둘 다 컴퓨터가 멈추니까 헷갈리지만 원인은 하늘과 땅 차이다.

Deadlock: 서로가 가진 락(자물쇠)을 안 풀어서 소프트웨어적(논리적)으로 영원히 멈춘 상태. 디스크 I/O는 조용하고 CPU도 0%로 잔잔하다.
Thrashing: 락이 아니라 물리적인 램(RAM) 공간이 모자라서, 디스크에 짐을 나르느라 물리적 병목으로 시스템이 버벅대며 뻗은 상태. 하드디스크 불이 미친 듯이 깜빡거리고 마우스가 뚝뚝 끊긴다. 돈을 주고 램(RAM)을 더 꽂으면 1초 만에 해결된다.
📢 섹션 요약 비유: 워킹 셋 모델은 학생이 자주 보는 교과서 5권(Working Set)을 파악해서 책상에 딱 5권 놓을 공간이 있을 때만 도서관 입장을 허락하는 깐깐한 사서입니다. PFF는 일단 앉혀놓고, 애가 책 찾으러 계속 돌아다니면(폴트 잦음) 책상을 넓혀주고, 가만히 있으면 책상을 뺏는 실용주의 사서입니다.

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

실무 시나리오

Windows의 OOM(Out of Memory) 스래싱 지옥: 램이 8GB인 윈도우 PC에서 게임을 3개 켜면 갑자기 화면이 멈추고 10분 동안 하드 긁는 소리가 난다.
- 이유: 윈도우는 데스크톱 OS답게 어떻게든 프로그램을 죽이지 않고 살려보려고, 디스크 스왑 파일(pagefile.sys)에 남은 메모리를 미친 듯이 욱여넣으며 **전통적인 스래싱(Thrashing)**의 늪으로 자진해서 걸어 들어간다.
- 사용자 경험: 프로그램이 죽진 않지만 10분 동안 렉이 걸려 사용자가 답답해서 강제 리부팅을 하게 만드는 최악의 UX를 낳는다.
Linux 서버 / K8s 클라우드의 "Swap Off" 절대 룰: 백엔드 서버나 쿠버네티스 클러스터에서는 윈도우 같은 짓을 절대 용납하지 않는다.
- 아키텍트 결단: 클라우드 엔지니어는 서버를 세팅할 때 무조건 sudo swapoff -a 명령어로 가상 메모리(스왑) 자체를 끄거나 비활성화한다.
- 현대적 복구 (Fail-Fast): 서버는 메모리가 모자라면 10분 동안 디스크를 긁으며 스래싱(연명 치료)을 하는 대신, 즉시 OOM Killer가 튀어나와 메모리를 제일 많이 먹는 놈을 쏴 죽인다(즉사). 그리고 K8s가 1초 만에 새 파드를 띄워 서버를 재개시킨다. 스래싱을 막기 위해 가상 메모리의 유연함을 포기하고 "빠른 죽음과 빠른 부활"을 택한 모던 아키텍처의 혁명이다.

  ┌────────────────────────────────────────────────────────────────────────┐
  │     메모리 부족(OOM) 시나리오에 대처하는 아키텍트의 의사결정 트리      │
  ├────────────────────────────────────────────────────────────────────────┤
  │                                                                        │
  │   [요구사항: 16GB 서버에 트래픽 폭주로 메모리 20GB 요구 발생]          │
  │                │                                                       │
  │                ▼ 운영체제의 스왑(Swap) 파라미터 튜닝                   │
  │   [ 1. Swap 공간을 넉넉히(16GB) 잡아둔다 (고전적 방식) ]               │
  │     ▶ 작동: 16G 램 + 4G 스왑(디스크) 사용. 프로그램 생존함.            │
  │     ▶ 결과: 🚨 완벽한 스래싱(Thrashing) 발생. API 응답 속도가          │
  │             10ms에서 5,000ms로 500배 폭증하며 유저 다 떨어져 나감.     │
  │                                                                        │
  │   [ 2. Swap 공간을 아예 삭제(0GB)해버린다 (클라우드 네이티브) ]        │
  │     ▶ 작동: 16G 램 꽉 차는 순간 OS가 OOM 에러 뱉고 앱 킬(Kill).        │
  │     ▶ 결과: ✅ 서버가 느려지는 꼴을 절대 안 봄(Fail-fast).             │
  │             죽은 앱은 로드밸런서가 즉시 차단하고 새 노드로 트래픽 우회.│
  └────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "메모리가 부족하면 스왑을 늘려라"는 쌍팔년도 조언이다. 데이터베이스(RDBMS, Redis) 서버에서 스왑이 도는 순간 그 서버는 죽은 것이나 다름없다. 현대 인프라는 스래싱이라는 고통스러운 연명 치료를 혐오한다. 메모리가 부족하면 쿨하게 뻗고 램(RAM)을 사서 끼우는(Scale-up) 것이 돈과 정신 건강을 지키는 유일한 정답이다.

📢 섹션 요약 비유: 피를 너무 많이 흘려 죽어가는 환자에게, 인공 심폐기(스왑 메모리)를 달아 식물인간으로 10년을 살게 하는 것이 고전적 스래싱 방치입니다. 현대 시스템은 가망이 없으면 즉시 안락사(OOM Kill) 시키고, 똑같은 클론(새 컨테이너)을 바로 태어나게 하는 과격하지만 확실한 부활 시스템입니다.

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

기대효과

스래싱의 본질을 이해하고 인프라 레벨에서 스왑을 차단하거나 메모리 Limit(Cgroups)을 정교하게 걸어두면, 악의적인 트래픽 폭주나 메모리 릭(Leak)이 터지더라도 서버 전체가 렉에 걸려 동반 자살하는 끔찍한 연쇄 장애(Cascading Failure)를 100% 방어해 낼 수 있다.

결론 및 미래 전망

스래싱은 가상 메모리(요구 페이징)라는 달콤한 마법이 빚어낸 가장 치명적인 청구서다. 학자들은 워킹 셋, PFF 등 우아한 알고리즘으로 이 빚을 갚아보려 했으나, 동적으로 변하는 현대 애플리케이션 앞에서는 모두 무용지물이 되었다. 결국 이 복잡한 알고리즘들은 "RAM 값이 똥값이 되는 하드웨어 혁명"과 "스왑을 꺼버리는(Swap-off) 클라우드의 Fail-Fast 철학" 앞에서 완전히 사멸했다. 미래의 인프라는 소프트웨어적으로 램을 아끼려는 쪼잔한 노력을 멈추고, AWS EC2에서 버튼 한 번으로 1TB RAM 인스턴스를 1초 만에 프로비저닝하거나 서버리스(Serverless)로 무한 확장하는 "압도적 물리량으로 스래싱을 찢어버리는" 자본주의 아키텍처로 완전한 결론을 맺었다.

📢 섹션 요약 비유: 옛날엔 식량이 부족해서 배고픔(스래싱)을 참는 명상법(워킹 셋 알고리즘)을 수련했습니다. 하지만 현대 시대는 그냥 마트(아마존 클라우드)에 가서 돈을 내고 고기(RAM)를 무한정 사 먹으면 됩니다. 스래싱은 굶주리던 시절의 슬픈 질병일 뿐, 풍요로운 현대 클라우드 시대에는 돈(스케일업)으로 1초 만에 완치되는 병입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
가상 메모리 (Virtual Memory)	램보다 큰 놈을 무리해서 올릴 수 있게 허락해 주어, 결국 스래싱이라는 재앙을 잉태한 어머니 기술이다.
요구 페이징 (Demand Paging)	게으르게 페이지를 나르다가 한계점에 달해 짐꾼들이 파업해 버리는 병목 현상이 바로 스래싱이다.
페이지 폴트 (Page Fault)	스래싱 상태에 빠진 컴퓨터가 1초에 10만 번씩 뿜어내는 피 토하는 비명 소리다.
OOM Killer (Out Of Memory)	스래싱 지옥에 빠지기 직전, 리눅스 커널이 칼을 들고 나타나 비대한 프로세스를 죽여 서버를 구출하는 사신이다.
스왑 영역 (Swap Space)	스래싱이 터졌을 때 CPU가 아무 일도 못 하고 짐만 나르며 혹사당하는 무겁고 느린 하드디스크의 늪지대다.

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

내 책상(RAM)에 문제집을 딱 2권만 펼칠 수 있는데, 욕심을 부려 10과목 공부를 동시에 하려고 했어요.
수학 한 문제 풀고 책 덮고 창고(디스크)에서 국어 꺼내오고, 국어 한 문제 풀고 다시 영어 꺼내오느라 방을 왔다 갔다만 했어요.
결국 책 찾으러 뛰어다니느라 힘은 다 빠지고, 정작 공부(CPU 연산)는 한 글자도 못 한 채 하루가 다 가버린 최악의 삽질 상태를 스래싱이라고 한답니다!