전역 교체 (Global Replacement)

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

본질: 전역 교체(Global Replacement)는 물리 램(RAM)에 빈 공간이 없어 누군가의 페이지를 쫓아내야(Swap-out) 할 때, 나(자신)의 메모리 영역뿐만 아니라 시스템에 떠 있는 다른 모든 프로세스의 메모리 영역까지 무자비하게 뺏어올 수 있는 거시적 페이지 교체 알고리즘이다.

가치: 램이 필요한 활성 프로세스(바쁜 놈)가 유휴 프로세스(노는 놈)의 램을 강제로 수탈하여 자신의 워킹 셋을 채우므로, 물리 램 전체의 놀고 있는 찌꺼기 공간을 0%에 가깝게 쥐어짜 내어 시스템 전체의 처리량(Throughput)을 우주 끝까지 극대화시킨다.

융합: 이 뺏고 뺏기는 무법지대 시스템은 필연적으로 억울하게 램을 뺏긴 남의 프로세스를 버벅대게(Jitter) 만들지만, 그 압도적인 성능적 이득 때문에 현대 리눅스와 윈도우 커널에서 페이징 시스템의 절대적인 디폴트(Default) 스탠다드로 융합되었다.

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

개념: 페이지 폴트(Page Fault)가 났는데 빈 램 프레임(Free Frame)이 0개다. 누군가를 죽여서(희생양 Victim) 램을 확보해야 한다. 이때 희생양의 타겟 범위를 "현재 메모리에 올라와 있는 수백 개의 모든 앱의 수백만 장의 페이지 전체(Global)"로 잡고, 그중 가장 만만한(오래 안 쓴) 놈을 발로 차 디스크로 내쫓는 정책이다.
필요성: 카카오톡, 크롬, 엑셀 3개를 띄워놨는데, 나는 지금 크롬으로 4K 유튜브만 본다 치자. 카톡과 엑셀은 1시간째 배경에서 숨만 쉬고 있다. 만약 "자기 방(Local) 안에서만 메모리를 쫓아내라!"는 룰을 강제하면, 크롬은 자기가 가진 1GB 램 안에서만 유튜브 데이터를 계속 돌려막기(스래싱) 하느라 영상이 뚝뚝 끊긴다. 옆에 있는 엑셀은 3GB 램을 쥐고 아무것도 안 하며 쿨쿨 자고 있는데 말이다. "놀고 있는 엑셀의 램을 크롬이 빼앗아 쓰면 영상이 팽팽 돌 텐데!" 이 지극히 상식적인 자원 펌핑의 필요성이 '전역 교체'라는 약육강식 아키텍처를 탄생시켰다.
💡 비유: 전역 교체는 버스 안의 자유 경쟁 노약자석과 같다. 버스에 빈자리가 없다(RAM Full). 엄청 무거운 짐을 든 사람(Page Fault가 터진 앱)이 탔다. 이때 자기 일행(자신의 프로세스 프레임) 중 한 명을 억지로 일으켜 세우는 게 아니다. 버스 전체(Global)를 휙 둘러보고, 1시간째 멍때리고 있는 가장 만만한 승객 1명(가장 오래 안 쓴 남의 페이지)의 멱살을 잡아 버스 밖(디스크 스왑)으로 쫓아낸 뒤 그 자리에 짐을 내려놓는 살벌한 효율성이다.
등장 배경 및 고정 할당의 죽음:
1. 지역 교체(Local)의 낭비: 초기엔 100프레임씩 주고 니들 안에서 알아서 살아 남으라고 방치했다. 안 쓰는 램이 썩어 넘치는 끔찍한 비효율이 발생했다.
2. 동적 램 재배분의 욕구: "메모리(RAM)라는 건 고정된 땅이 아니라, 숨을 쉬는 유기체다." 바쁜 놈에게 램을 유동적으로 몰아주는 것이 시스템 가동률 100%를 달성하는 길임을 깨달았다.
3. 표준의 정착: 리눅스 데몬 kswapd가 밤낮없이 백그라운드를 순회하며 남의 램을 쓸어다 빈 통장(Free list)에 넣는 전역적(Global) 징수 시스템이 확립되었다.

┌─────────────────────────────────────────────────────────────────────────┐
│        전역 교체 (Global Replacement)의 무자비한 램 약탈 시각화         │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│ [ 상황: 물리 RAM이 100% 꽉 찬 상태 ]                                    │
│ ┌──────────────┬──────────────┬──────────────┐                          │
│ │ 크롬 (바쁘게 돎) │ 엑셀 (쉬는 중) │ 카톡 (잠자는 중)│                 │
│ └──────────────┴──────────────┴──────────────┘                          │
│                                                                         │
│ ▶ 위기: 크롬이 4K 영상을 보느라 "새로운 램 1장 더 줘!" 폴트 발생!       │
│ ▶ 램 잔고 = 0. 누군가를 쫓아내서 빈방을 만들어야 함.                    │
│                                                                         │
│ [ OS의 매의 눈 (Global LRU 스캔) ]                                      │
│ "크롬, 엑셀, 카톡의 모든 페이지를 1열로 쫙 세워봐. 누가 젤 잉여야?"     │
│ "오, 카톡이 들고 있는 '배너 광고 이미지'가 1시간째 터치 안 됐네?"       │
│                                                                         │
│ [ 약탈 실행 (Swap-out) ]                                                │
│ OS가 카톡의 배너 이미지를 무자비하게 디스크(스왑)로 걷어차버림.         │
│ ──▶ [ 카톡의 램 1장 탈취 완료 ]                                         │
│                                                                         │
│ [ 수여 (Swap-in) ]                                                      │
│ OS가 빼앗은 그 램 1장을 크롬의 유튜브 영상 버퍼로 채워줌!               │
│ ✅ 결과: 크롬의 램 점유율 상승 🚀 / 카톡의 램 점유율 하락 📉            │
└─────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이것이 내가 크롬 탭을 100개 띄우면 옆에 켜둔 게임이 렉이 걸리는 근본적인 하드웨어적 이유다. 크롬이 폴트를 미친 듯이 뿜어내며 시스템 전역(Global)의 램 프레임들을 닥치는 대로 훔쳐 가서 자기 배를 불렸기 때문이다. 공산주의적 균등 할당을 완전히 박살 낸 승자 독식의 철학이다.

📢 섹션 요약 비유: 회사에서 프로젝트를 할 때, 내 팀(자신의 앱) 예산이 다 떨어졌다고 우리 팀원 월급을 깎는 게 아니라, 사장님(OS)한테 가서 "저기 맨날 유튜브만 보는 영업팀(남의 앱) 예산 확 뺏어서 우리 팀 서버비로 꽂아주세요!"라고 읍소하여 회사 전체 자금을 융통하는 공격적인 예산(전역 램) 운영 방식입니다.

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

프레임 강탈로 인한 '할당량 고무줄 현상'

전역 교체의 가장 큰 특징은 **"프로세스에 할당된 프레임 개수 자체가 시시각각 미친 듯이 변한다"**는 것이다.

Time 1: 크롬(100장), 카톡(100장) 평화롭게 시작.
Time 2: 크롬 탭 10개 오프닝. 크롬이 폴트를 마구 뿜으며 카톡의 방을 강탈함.
Time 3: 크롬(180장), 카톡(20장)으로 램 영토가 완전히 뒤바뀜.
즉, 내 프로그램의 메모리 점유율이 내 의지가 아니라 "남(타 프로세스)의 실행 패턴"에 의해 수동적으로 결정되는 무서운 부작용(Dependency)이 발생한다.

성능 제어의 불가해성 (Unpredictable Execution Time)

이 전역 교체 아키텍처 때문에, 개발자는 자신의 코드가 "무조건 1초 안에 실행된다"는 보장을 절대 할 수 없게 된다.

내 C++ 코드가 어제는 0.1초 만에 돌았다.
오늘 똑같이 돌렸는데, 하필 백그라운드에서 백신 프로그램이 돌면서 내 램 프레임을 전역 교체로 싹 다 훔쳐 가 스왑으로 날려버렸다.
내 코드가 램을 다시 찾느라 페이지 폴트를 10만 번 터뜨려 10초가 걸린다.
결론: 전역 교체 환경에서는 내 프로세스의 Page Fault 발생 횟수가 나 혼자만의 행동이 아니라 외부 환경(External Noise)에 의해 요동치므로, 실시간 시스템(RTOS)이나 지연(Latency)에 민감한 HFT(초고빈도 매매) 환경에서는 최악의 독약(Jitter)으로 작용한다.
📢 섹션 요약 비유: 내 아파트 전세(램 할당량)가 고정된 게 아니라, 매일 아침 집주인(OS)이 와서 "오늘 앞집에 손님이 많이 오니 네 방 2칸만 뺏어서 앞집 주자"라고 마음대로 집 평수를 늘렸다 줄였다(고무줄 할당) 하는 어지러운 세입자의 삶입니다.

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

비교 1: 전역 교체 (Global) vs 지역 교체 (Local)

운영체제 역사상 수없이 맞붙었던 두 철학의 뼈아픈 트레이드오프다.

비교 항목	전역 교체 (Global Replacement)	지역 교체 (Local Replacement)
희생양 탐색 범위	메모리에 있는 모든 프로세스 전체 방	오직 자기 자신에게 할당된 100개의 방
램(RAM) 활용률	극도로 높음 (99%). 노는 램을 즉시 빼앗아 씀	나쁨. 할당받고 쉬고 있으면 램이 썩어 들어감
프로세스 렉(Jitter)	외부 요인에 의해 남의 램 뺏기다 훅 갈 수 있음	자기 방 안에서만 놀므로 성능이 100% 일정하게 예측 가능함
스래싱(Thrashing)	한 놈이 미치면 서버 전체의 램을 뺏어 쑥대밭 만듦	한 놈이 미쳐도 자기 방 안에서만 렉 걸리고 끝 (피해 안 줌)
현대 OS 채택	🟢 Windows, Linux의 압도적 기본값	❌ 거의 폐기됨 (수동 제한 등 특수 경우만 사용)

Page Fault Frequency (PFF, 페이지 부재 빈도) 제어

전역 교체 하에서, 미친 프로세스 하나가 램을 100% 싹쓸이하여 남들을 다 죽이는 마피아 짓(Thrashing)을 어떻게 막을까?

OS는 PFF (페이지 부재 빈도) 상/하한선을 정해둔다.
어떤 앱이 폴트를 1초에 1,000번씩 빵빵 터뜨린다? "아 이놈 지금 방이 너무 좁구나! 남의 램 뺏어서 얘한테 더 몰아줘!(전역 교체의 정당성)"
반대로 어떤 앱이 10분 동안 폴트가 단 1번도 안 났다? "이놈 방이 너무 널널해서 램을 낭비하고 있네! 얘 프레임을 당장 압수(Trim)해서 프리 리스트(Free list)로 회수해!"
이 PFF 조절 로직이 백그라운드에서 실시간으로 돌면서, 전역 교체의 야생성에 '최소한의 공권력'을 부여하여 스래싱을 막아낸다. (상세 내용은 스래싱 챕터에서 다룸)

┌──────────┬────────────┬────────────┬───────────────────────────┐
│ 스케줄러 철학│ 할당량 조절   │ 노는 램의 운명 │ OOM 방어력     │
├──────────┼────────────┼────────────┼───────────────────────────┤
│ 전역(Global)│ 실시간 변동   │ 즉시 남이 뺏어감│ 끝까지 쥐어짬  │
│ 지역(Local) │ 영구 고정     │ 영원히 썩어감  │ 램 남는데 터짐  │
└──────────┴────────────┴────────────┴───────────────────────────┘

[매트릭스 해설] 이 표를 보면 리눅스가 왜 전역(Global)을 택했는지 알 수 있다. 서버 관리자 입장에서 램이 10GB나 비어있는데 지역 교체 룰(Quota)에 묶여서 1개 앱이 뻗어버리는 꼴은 절대 용납할 수 없다. "누가 렉 걸리든 알 바 아니고, 물리 램 16GB의 마지막 한 톨까지 100% 쥐어 짜내서 시스템 전체의 스루풋(Throughput)을 우주 끝까지 높이겠다"는 것이 현대 OS의 서늘한 가치관이다.

📢 섹션 요약 비유: 지역 교체가 각 부서에 무조건 예산 1억씩 고정으로 주고 맘대로 쓰라는 공무원 행정이라면, 전역 교체는 월말마다 실적(폴트 빈도)을 평가해서 실적 안 나오는 부서 예산을 싹 뺏어다가 일 잘하는 부서에 팍팍 몰아주는 피도 눈물도 없는 성과주의 대기업의 살벌한 생존 경쟁입니다.

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

실무 시나리오: 도커(Docker) OOM과 cgroups의 로컬 락(Local Lock)

클라우드의 악몽: 클라우드 서버 1대에 고객사 앱(컨테이너)을 10개 띄웠다. A 회사 앱이 메모리 릭(Leak) 버그를 내서 미친 듯이 램을 요구했다. 리눅스의 전역 교체(Global) 알고리즘은 아무 죄 없는 B~J 회사의 램을 몽땅 빼앗아 스왑으로 날려버리고 A 회사에 몰아줬다. B~J 회사의 서비스가 모조리 정지(STW)되었다. (최악의 Noisy Neighbor 문제)
지역 교체(Local)의 멱살 부활:
- 가상화와 컨테이너 시대에는 이 "전역 깡패 짓"이 치명적 독이 되었다. 남의 서비스에 피해를 주면 안 되기 때문이다.
- 구글 엔지니어들은 리눅스 커널에 **cgroups (Control Groups)**라는 감옥을 설계했다.
- 컨테이너를 띄울 때 memory limit = 2GB 라는 절대 족쇄를 채운다.
- 이 족쇄를 찬 앱이 2GB를 넘게 쓰려고 하면, 리눅스 전역 램이 100GB가 남아 돌아도 절대 남의 램을 뺏지(Global) 못하고, 오직 자기 2GB 안에서만 울며 겨자 먹기로 돌려막기(Local Replacement)를 강제당한다. 돌려막다 못 버티면 자기 혼자만 OOM 킬러에게 사살당한다.
실무적 결단: 현대 인프라(k8s)는 리눅스의 폭주하는 전역 교체 알고리즘 위에, cgroups라는 튼튼한 '지역 교체 철창'을 덮어씌워서 속도와 격리(Isolation)의 완벽한 하이브리드 경제를 구축했다.

OOM Score Adjust (oom_score_adj)와 면책 특권

전역 교체가 극에 달해 램 16GB, 스왑 32GB마저 다 털려버리면, 리눅스는 드디어 총(OOM Killer)을 꺼내 든다. 누구를 쏠까? 전역 교체 생태계에서 램을 가장 거대하게 독식한(제일 뚱뚱한) 놈이 1순위 사살 타겟이다. 보통 DB 서버(MySQL 등)가 1순위로 지목당해 머리가 날아간다. 서버 엔지니어는 이 참사를 막기 위해 DB 프로세스의 oom_score_adj 값을 -1000으로 박아두어, "얘는 우리 회사의 심장이니 아무리 뚱뚱해도 절대 쏘지 말고, 저기 구석에 램 10MB 먹는 찌꺼기 로그 수집기나 대신 쏴서 죽여라!"라며 전역 학살극에서 VIP를 살려내는 튜닝을 필수적으로 수행한다.

📢 섹션 요약 비유: 야생의 밀림(리눅스 전역 교체)에서 사자(메모리 릭 앱)가 미쳐 날뛰며 얼룩말들(정상 앱)을 다 잡아먹어 생태계가 파괴되자, 신(k8s 엔지니어)이 거대한 철창(cgroups)을 내려 사자를 가두고 그 안에서만 굶어 죽게(Local OOM) 만들어 초원의 평화를 되찾아준 클라우드 최적화 스토리입니다.

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

정량/정성 기대효과

구분	내용
물리 램 활용률(Utilization) 극대화	가만히 쉬고 있는 프로세스의 프레임을 단 1초도 놀리지 않고 즉각 회수하여 활성 프로세스에 몰아줌으로써 램 투자 가성비 최고치 달성
다중 프로그래밍의 스루풋(Throughput) 상승	바쁜 앱이 메모리 부족으로 멈추는 지연(Stall)을 남의 램을 뺏어서라도 해결해 주므로 전체 시스템 명령어 처리량 극대화
스케줄러의 부하 경감	"누구에게 몇 개를 줘야 하나?"라는 복잡한 할당량(Quota) 계산을 포기하고, 그냥 폴트 나는 놈한테 막 퍼주는 단순 무식한 로직으로 OS 오버헤드 억제

결론 및 미래 전망

전역 교체 (Global Replacement)는 "놀고 있는 자원은 악(Evil)이다"라는 컴퓨터 공학의 살벌한 자본주의적 효율성을 가장 날 것 그대로 보여주는 매커니즘이다. 비록 내 프로그램의 성능이 남의 프로그램 상태에 따라 널뛰기하는 예측 불가능성(Jitter)의 지옥을 낳았지만, 이 야만적인 약탈 시스템이 있었기에 우리는 16GB 램으로 수십 개의 무거운 앱을 동시에 매끄럽게 돌리는 PC의 기적을 매일 누리고 있다. 현대의 클라우드 컴퓨팅은 이 전역 교체의 야생성 위에 cgroups라는 견고한 지역(Local) 격리망을 덮어씌움으로써 보안과 성능의 완벽한 진화를 이루어냈으며, 향후 어떤 가상화 기술이 등장하더라도 "바쁜 놈에게 램을 몰아준다"는 이 Global 뺏기 철학은 시스템 자원 스케줄링의 영원한 대원칙으로 남을 것이다.

📢 섹션 요약 비유: 배가 부른데도 음식을 끌어안고 있는 부자(유휴 앱)의 식량을 강제로 압수해서, 당장 굶어 죽기 직전인 막노동꾼(활성 앱)의 입에 쑤셔 넣어 도시 전체의 공장(시스템)이 100% 풀가동되게 만드는, 거칠지만 가장 위대한 로빈 후드(OS) 식 분배 경제학입니다.

📌 관련 개념 맵 (Knowledge Graph)

지역 교체 (Local Replacement) | 전역 교체의 라이벌로, 남의 램은 절대 안 건드리고 내 할당량 100개 안에서만 돌려막는 고지식한 낡은 기법
페이지 교체 알고리즘 (LRU 등) | 전역 교체가 램을 뺏어올 때, "수백만 개의 램 조각 중 도대체 누구를 제일 먼저 쫓아낼 것인가?"를 가르는 무자비한 살생부 로직
스래싱 (Thrashing) | 전역 교체가 폭주해서, 서로가 서로의 램을 뺏느라 디스크 I/O만 터지고 CPU 연산은 0%로 수렴해 버리는 파멸적 뇌사 상태
cgroups (Control Groups) | 도커가 리눅스의 무지성 전역 교체를 통제하기 위해 씌워놓은, 앱 단위 메모리 강제 상한선(Limit) 철창
워킹 셋 (Working Set) | 전역 교체로 남의 램을 뺏어오다 보면, 결국 내 앱이 쾌적하게 돌아가기 위해 딱 모이는 최적의 램 덩어리 개수 (동적 할당의 완성)

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

전역 교체가 뭔가요? 블록 놀이방(메모리)에 100개의 블록이 있는데 내가 로봇을 만들다가 블록이 모자랄 때, 옆에서 멍때리고 있는 친구(다른 프로세스)가 쥐고 있는 블록을 확 뺏어서 내 로봇을 완성하는 거예요.
친구는 어떻게 되나요? 뺏긴 친구는 나중에 성을 만들고 싶을 때 "내 블록 어딨어!" 하고 울음(페이지 폴트)을 터뜨리며 엄마(디스크)한테 새 블록을 달라고 떼를 써야 해요.
왜 그렇게 뺏어서 쓰나요? 안 쓰는 블록을 가만히 쥐고만 있는 건 놀이방 전체로 보면 엄청난 낭비거든요. 당장 로봇을 바쁘게 만드는 친구한테 남는 블록을 다 몰아줘야 놀이방(시스템)이 가장 재밌게 잘 돌아간답니다.