스래싱 (Thrashing)

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

본질: 스래싱(Thrashing)은 시스템의 물리 메모리(RAM)가 턱없이 부족해져서, 프로세스들이 서로의 프레임을 뺏고 뺏기는 페이지 부재(Page Fault)의 악순환에 빠져, CPU가 실제 연산은 전혀 하지 못하고 디스크 I/O 심부름만 하다가 서버가 얼어붙는 최악의 뇌사 상태를 의미한다.

가치(위험성): 가상 메모리(요구 페이징)가 가진 "램보다 훨씬 큰 프로그램을 돌릴 수 있다"는 마법이 임계점을 넘어 오만(Over-allocation)으로 변질되었을 때, 시스템이 치러야 하는 가장 파멸적인 대가(Penalty)다.

융합: 이 파국을 막기 위해 운영체제는 '전역 교체(Global)'의 야생성을 억제하고, 다중 프로그래밍 정도(Degree)를 강제로 낮추거나 워킹 셋(Working Set) 모델 및 PFF(페이지 부재 빈도) 제어 알고리즘과 융합하여 프로세스의 생사를 통제하는 비상 방어망을 가동한다.

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

개념: 스래싱은 "프로세스가 실제 코드를 실행하는 시간보다, 페이지를 디스크와 램 사이에서 교체(Paging/Swapping)하는 데 보내는 시간이 더 많아진 현상"이다. CPU 이용률(Utilization)이 1% 밑으로 곤두박질치고 디스크 대기열(I/O Wait)이 100%를 찍으며 화면 마우스조차 뚝뚝 끊기는 환장할 상태다.
필요성(발견의 중요성): 초기 가상 메모리 시대엔 "램이 모자라면 디스크 스왑을 쓰면 되지!" 라며 앱을 수십 개씩 막 띄웠다. 그러자 어느 순간 컴퓨터가 완전히 멈췄다. 램을 아껴보겠다고 만든 기술이 컴퓨터 전체의 숨통을 끊어버린 것이다. OS 설계자들은 스래싱이 왜 터지는지 그 수학적 원인을 분석하고, "어떤 놈을 죽이더라도(OOM) 스래싱 지옥에 빠지는 것만큼은 막아야 한다"는 안전핀(Anti-Thrashing) 로직을 커널의 최우선 순위로 개발해야 했다.
💡 비유: 스래싱은 저글링 묘기를 부리는 광대와 같다. 광대(CPU)가 공(데이터) 3개를 돌릴 땐 아주 매끄럽게 잘 돌린다(정상 상태). 관객이 열광하자 무리해서 공 10개를 던졌다. 광대의 손(RAM)은 2개뿐인데 공이 10개나 떨어지니, 이 공 잡으려다 저 공 놓치고, 저 공 주우러 몸을 숙였다가(디스크 I/O) 다른 공들에 머리를 맞는 대참사가 벌어진다. 결국 광대는 묘기(실제 연산)는 하나도 못 보여주고 바닥에 떨어진 공만 줍다가 쇼가 끝난다(Thrashing).
등장 배경 및 OS 스케줄러의 치명적 오판:
1. 요구 페이징의 무한 신뢰: "램 없어도 스왑으로 막으면 됨!" -> 과도한 프로세스 띄움.
2. 바보 같은 CPU 스케줄러: 디스크 긁느라 CPU가 할 일이 없어지자(CPU Utilization 하락), 멍청한 스케줄러가 "어? CPU가 노네? 앱을 하나 더 띄워!(Degree 증가)"라는 최악의 오판을 내림.
3. 재앙의 나비효과: 새로 들어온 앱이 기존 앱의 얼마 안 남은 램마저 빼앗으면서 페이지 폴트가 지수함수적으로 대폭발.

┌────────────────────────────────────────────────────────────────────────┐
│        스래싱(Thrashing)이 폭발하는 연쇄 작용 (Doom Loop) 시각화       │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│ [ 1. 메모리 부족 시작 ]                                                │
│  - 프로세스 A, B가 램(16GB)을 꽉 채우고 치열하게 전역 교체 싸움 중.    │
│  - A가 B의 페이지를 뺏음 -> B가 폴트 나서 A의 페이지를 다시 뺏음.      │
│                                                                        │
│ [ 2. I/O 대기 (CPU 놀림) ]                                             │
│  - A와 B 둘 다 디스크 스왑을 기다리느라 뻗음(Wait/Sleep).              │
│  - CPU 사용률이 10%로 폭락함.                                          │
│                                                                        │
│ [ 3. 💥 멍청한 스케줄러의 자해 공갈 (치명상) ]                         │
│  - OS 스케줄러: "CPU가 왜 10%밖에 안 돌아? 놀지 말고 일해!"            │
│  - 강제로 새로운 프로세스 C를 램에 들이밀어 실행시킴 (Degree 상승).    │
│                                                                        │
│ [ 4. 스래싱 지옥 도래 ]                                                │
│  - C가 들어오면서 A와 B의 마지막 남은 핵심 램마저 다 스왑으로 날려버림.│
│  - A, B, C 세 놈이 0.1초마다 폴트를 뿜으며 디스크 암(Arm)을 찢어버림.  │
│  - CPU 이용률 0%, 디스크 사용률 100%. 서버 뇌사 상태 돌입.             │
└────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 스래싱은 단순한 메모리 부족 에러가 아니다. "시스템이 살려고 발버둥 치는 스케줄링 로직(CPU 가동률 높이기)"이 하필이면 "메모리 시스템의 숨통을 조이는 방향"으로 작용하여 서로 물고 물리며 침몰하는 운영체제 내부의 피드백 루프(Feedback Loop) 모순이다. 이 고리를 끊으려면 누군가가 칼을 들어야 한다.

📢 섹션 요약 비유: 회사에 일이 너무 많아 직원(프로세스)들이 야근하다 과로로 쓰러져 결근(디스크 대기)했습니다. 멍청한 사장(스케줄러)은 회사 출근율(CPU 가동률)이 떨어졌다며 신입사원을 더 뽑아 빈자리에 앉혔습니다. 신입들이 남은 직원들의 모니터와 키보드(램)를 뺏어가자, 회사 전체가 서류 한 장 처리 못 하고 자리 뺏기 싸움만 하는 아수라장(스래싱)이 된 꼴입니다.

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

스래싱의 근본 원인: 최소 프레임 (Minimum Frames) 확보 실패

컴퓨터 구조에서 스래싱을 유발하는 단 하나의 원인은 **"프로세스가 당장 돌기 위해 필요한 '최소한의 물리 프레임 뭉치(Working Set)'를 OS가 빼앗아 버렸기 때문"**이다.

어셈블리 명령어 1줄이 LOAD [배열 A], [배열 B] 라면, 이 1클럭을 넘기기 위해 최소 3장의 페이지(명령어장, A데이터장, B데이터장)가 무조건 램에 있어야 한다.
만약 전역 교체(Global Replacement)로 인해 OS가 이 앱의 램을 2장으로 깎아버리면?
1, 2장을 올렸다가 3장째를 부를 때 1장을 디스크로 내쫓는다. 다시 1장을 부르려 2장을 쫓아낸다. 영원히 이 명령어 1줄을 통과하지 못하는 **무한 폴트 지옥(Infinite Page Fault Loop)**에 빠진다.
이것이 스래싱의 가장 기계적이고 밑바닥에 깔린 물리적 원인이다.

다중 프로그래밍 정도 (Degree of Multiprogramming)와 CPU 이용률 그래프

운영체제론 시험에 무조건 나오는 전설의 그래프 곡선이다. 이 곡선은 스래싱의 무서움을 완벽하게 시각화한다. (다음 키워드에서 더 상세히 다룸)

초반 상승: 램에 앱을 1개, 2개 띄울수록 CPU가 놀 틈이 없어(문맥 교환) CPU 가동률이 쑥쑥 100%를 향해 오른다.
임계점 (Thrashing Point): 램이 감당할 수 있는 워킹 셋의 합을 넘어가는 순간.
수직 낙하 (절벽): 앱을 하나 더 띄우는 그 찰나의 순간, CPU 이용률 곡선이 99%에서 1%로 절벽처럼 수직 자유 낙하한다. 시스템이 스래싱의 늪에 빠진 것이다.
📢 섹션 요약 비유: 고속도로에 차를 100대, 500대 넣을 때까지는 도로 전체의 수송량(CPU 가동률)이 쑥쑥 오릅니다. 하지만 도로 수용량(램)을 1대라도 넘어선 1001대가 들어오는 순간, 차들이 서로 엉켜서 시속 0km(스래싱)로 멈춰버려 고속도로 수송량이 0이 되는 정체 절벽 현상과 똑같습니다.

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

스래싱을 예방하는 3대 아키텍처 방어벽

OS가 이 끔찍한 뇌사를 막기 위해 도입한 방어 전략들이다.

방어 기법	동작 원리	효과와 한계
지역 교체 (Local Replacement)	빈 램이 없어도 남의 램을 못 뺏게 철창(cgroups)을 침. 자기가 램 모자라면 자기 혼자 버벅대고 끝남.	남(서버 전체)에게 스래싱이 전염되는 건 막지만, 본인이 죽는 건 못 막음.
워킹 셋 모델 (Working Set)	프로세스가 쾌적하게 돌기 위한 '최소 필요 램 뭉치(세트)'를 계산해서 그만큼은 절대 안 뺏고 보호해 줌.	가장 이상적이나, 과거 이력을 계속 트래킹해야 해서 CPU 오버헤드가 무거움.
PFF (페이지 부재 빈도) 제어	"초당 폴트가 100번 이상 터지면 램 더 주고, 1번 터지면 램 뺏어라!"라는 상하한선 실시간 조절 로직.	워킹 셋의 훌륭한 짝퉁(근사치). 가벼우면서도 직관적으로 스래싱을 차단함.

전역 교체(Global)의 부작용과 OOM 킬러(OOM Killer)의 최후 심판

현대 리눅스는 효율을 위해 무조건 '전역 교체'를 쓴다. 그래서 누군가 램을 미친 듯이 원하면 스래싱 임계점 절벽으로 시스템을 몰고 가는 걸 알면서도 남의 램을 뺏어다 준다. 스래싱 절벽에 다다르면 리눅스는 어떻게 할까? **'아예 절벽 밑으로 떨어지기 전에 총을 쏴서 죽인다'**를 선택했다.

디스크 암(Arm)이 미친 듯이 돌며 스래싱 조짐이 보이면, OS는 백그라운드의 자비로운 청소부(kswapd)를 거두고 무자비한 암살자 OOM Killer를 출동시킨다.
"지금 이 스래싱의 원흉인 가장 램을 많이 먹은 놈 1명(희생양 프로세스)의 대갈통을 날려라(SIGKILL)!"
앱 하나가 즉사하며 10GB의 램이 허공에 확 풀린다. 폴트가 멈추고 디스크가 조용해지며 서버가 스래싱 절벽에서 극적으로 구출된다.

┌──────────┬────────────┬────────────┬────────────────────────────────┐
│ 위기 단계  │ 램 가용 상태  │ OS의 대응 행동 │ 시스템 체감 상태      │
├──────────┼────────────┼────────────┼────────────────────────────────┤
│ 1단계    │ 약간 부족   │ kswapd가 조용히 청소│ 쾌적함               │
│ 2단계    │ 거의 바닥   │ 강제 폴트(Direct Reclaim)│ 마우스 툭툭 끊김│
│ 3단계(스래싱)│ 완전 바닥   │ ☠️ OOM 킬러 발동 │ 앱 하나 강제 종료   │
└──────────┴────────────┴────────────┴────────────────────────────────┘

[매트릭스 해설] 초보자들은 OOM 킬러가 앱을 죽이는 걸 보고 OS를 원망하지만, 사실 OOM 킬러는 서버 전체가 스래싱에 빠져 모든 서비스가 영원히 멈추는 동반 자살을 막기 위해 자신의 팔을 자르는(Fail-fast) 위대한 구원자다.

📢 섹션 요약 비유: 구명보트(램)에 사람이 너무 많이 타서 보트가 물에 가라앉으려 합니다(스래싱). 다 같이 물귀신이 되어 죽느니, 가장 무거운 짐을 든 뚱뚱한 사람 한 명(OOM 타겟)을 매정하게 바다로 밀어버려서 남은 사람들을 살려내는 타이타닉의 냉혹한 생존 법칙입니다.

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

실무 시나리오: AWS 인스턴스의 크레딧 고갈과 I/O 병목

문제의 발단: AWS의 t2.micro (램 1GB) 싼 서버에 Spring Boot 웹서버를 올렸다.
스래싱의 폭발:
- 램 1GB는 JVM이 뜨자마자 100% 꽉 찼다.
- 요청이 1건 들어올 때마다 서버는 스왑 파티션(EBS 디스크)으로 미친 듯이 페이지를 밀어내며 스래싱에 빠졌다. EAT(접근 시간)가 디스크 속도로 떨어졌다.
AWS EBS Burst Balance(크레딧)의 탕진:
- 더 환장하는 건, 클라우드의 디스크(EBS)는 I/O 횟수(IOPS)에 제한이 있다는 것이다.
- 스래싱 때문에 1초에 수천 번 디스크를 긁어대니, AWS가 제공하는 디스크 크레딧이 10분 만에 0이 되어 버렸다.
- 디스크 속도가 초당 1MB 속도로 강제 제한(Throttling) 걸린다.
- 서버는 뇌사(Thrashing) 상태에 빠진 채 재부팅 명령(SSH)조차 먹히지 않는 영원한 혼수상태에 빠진다.
실무적 결론: "램이 모자라면 스왑(Swap)이 막아주겠지"라는 건 1990년대 생각이다. 클라우드 시대에서 스왑에 기댄다는 것은 곧 스래싱에 빠져 클라우드 자원을 탕진하고 서버가 타버리는 결과를 낳으므로, 애초에 스왑을 끄고(Swapoff), 무조건 램을 증설(Scale-up)하는 것만이 유일한 정답이다.

프론트엔드/모바일 개발자의 시선 (Memory Warning)

iOS나 Android는 PC처럼 든든한 스왑 디스크가 없다. 플래시 메모리 수명을 지키기 위해 스와핑을 최소화한다. 대신 램이 꽉 차 스래싱 조짐이 보이면, OS가 켜져 있는 앱들에게 didReceiveMemoryWarning (아이폰) 같은 경고 방송을 다급하게 때린다. "야! 너희들 들고 있는 캐시 이미지 당장 램에서 다 지워! 안 지우면 내가 다 쏴 죽인다!" 이 경고를 듣고 개발자가 메모리를 비워주면 살고, 무시하면 0.1초 뒤 앱이 크래시(Crash)나며 튕긴다. 이것이 모바일 운영체제가 스래싱을 막아내는 눈물겨운 소프트웨어적 협박 통제 시스템이다.

📢 섹션 요약 비유: 배가 터질 것 같은데 억지로 밥을 더 우겨 넣어서 식체(스래싱)로 쓰러지기 직전에, OS가 강력한 구토 유발제(Memory Warning)를 먹여 위장(램)을 비우게 만들거나 강제로 위세척(OOM Kill)을 해서 환자를 살려내는 응급실 아키텍처입니다.

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

정량/정성 기대효과

구분	내용
하드웨어 한계의 증명	아무리 우아한 페이징 기법과 캐시 매핑을 써도, 물리 램 총량의 부족 앞에서는 소프트웨어가 할 수 있는 일이 없음을 실증
스케줄러 알고리즘 혁신	단순히 CPU 가동률만 보고 무지성으로 앱을 띄우던 스케줄러에게 '메모리 폴트 임계점'이라는 새로운 통제 지표를 이식
워킹 셋(Working Set) 이론 정립	스래싱을 막기 위한 연구가 결국 "프로그램이 최소한 필요로 하는 램의 지역적 묶음"이라는 현대 캐싱 이론의 근본을 탄생시킴

결론 및 미래 전망

스래싱 (Thrashing)은 컴퓨터가 인간의 오만함(Over-allocation)에 보내는 가장 고통스러운 경고장이다. 디스크라는 무거운 족쇄를 매달고 환상(가상 메모리) 속을 걷던 운영체제는, 램 잔고가 바닥나는 순간 환상이 깨지며 디스크 I/O라는 가혹한 현실의 늪(Thrashing)으로 추락하고 만다. 1970년대 학자들을 패닉에 빠뜨린 이 현상은, 수십 년이 지난 지금도 클라우드 OOM 킬러와 컨테이너 스케일링(HPA)이라는 형태로 현업 엔지니어들의 밤잠을 설치게 하고 있다. 미래에는 데이터센터의 모든 램을 광섬유로 엮어 하나로 쓰는 Memory Disaggregation(분산 메모리) 시대가 도래하여 "내 서버 램"이라는 한계가 사라지겠지만, 전체 네트워크의 램마저 고갈되었을 때 발생하는 '글로벌 네트워크 스래싱'이라는 새로운 형태의 괴물과 또다시 맞서 싸우게 될 것이다.

📢 섹션 요약 비유: 신용카드 돌려막기(가상 메모리)로 수십 개의 회사를 차리며 부자 행세를 하던 사람이, 한 은행에서 대출 상환(Page Fault)을 요구하자 다른 은행 빚을 빼서 갚고, 다시 구멍 난 돈을 막느라 하루 종일 뛰어다니다(디스크 I/O) 결국 모든 회사가 부도 처리(스래싱 뇌사)되는 신용 불량자의 슬픈 결말입니다. 유일한 해결책은 진짜 현금(RAM 증설)을 박아 넣는 것뿐입니다.

📌 관련 개념 맵 (Knowledge Graph)

요구 페이징 (Demand Paging) | "필요하면 그제야 가져온다"는 쿨한 마인드로 스래싱의 단초를 제공한 가상 메모리의 코어 엔진
워킹 셋 (Working Set) | 스래싱을 막기 위해, 어떤 앱이 숨을 쉬려면 무조건 가져야 하는 "최소한의 램 조각(프레임) 묶음"
OOM Killer | 스래싱으로 시스템 전체가 동반 자살하는 것을 막기 위해, 가장 램을 많이 먹은 마피아 보스를 총으로 쏴 죽이는 리눅스의 암살자
페이지 폴트 (Page Fault) | 1초에 이 지뢰가 수만 번씩 터지면 스래싱으로 돌입하는 트리거(Trigger) 지표
PFF (Page Fault Frequency) | 스래싱을 예방하기 위해, 폴트가 잦으면 램을 들이붓고 폴트가 적으면 램을 뺏는 지능형 램 배분 조절기

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

스래싱이 뭔가요? 책상이 너무 좁아서 내 국어책을 올리려면 짝꿍의 수학책을 바닥에 떨어뜨려야 하고, 짝꿍이 수학책을 주워 올리면 내 국어책이 떨어져서 둘 다 공부는 하나도 못 하고 책만 줍고 있는 바보 같은 상태예요.
왜 그렇게 되나요? 선생님(스케줄러)이 좁은 책상 1개에 학생 5명을 강제로 꽉꽉 채워 앉혀서, 서로 자기 책을 보겠다고 물어뜯고 싸움이 났기 때문이에요.
어떻게 해결하나요? 제일 뚱뚱해서 자리를 다 차지하고 있는 학생 한 명을 강제로 복도로 내쫓아버리거나(OOM Kill), 아예 더 크고 넓은 책상(램 추가)을 사 와야 평화가 찾아온답니다.