지역 교체 (Local Replacement)

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

본질: 지역 교체(Local Replacement)는 물리 램(RAM)에 빈방이 모자라 페이지를 쫓아낼 때, 시스템 전체를 뒤져서 남의 방을 뺏는 전역 교체(Global)와 달리, 오직 해당 프로세스 자신에게 애초에 할당된 램 프레임 풀(Pool) 안에서만 희생양을 골라 돌려막기(Swap)를 하는 폐쇄적인 교체 정책이다.

가치: 프로세스 하나가 미쳐서 무한 페이지 폴트를 뿜어대더라도 그 피해가 절대 다른 프로세스의 램 영역으로 번지지 않는 **완벽한 격리(Isolation)와 예측 가능한 성능(Determinism)**을 보장하여 특정 앱의 폭주로부터 시스템 전체를 보호한다.

융합: 고전적인 메인프레임 방식이라 범용 OS(Linux/Windows)의 기본 정책(전역 교체)에서는 멸종했으나, 컨테이너 가상화 시대에 도래하여 도커(Docker)의 cgroups(메모리 하드 리밋)와 결합하면서 마이크로서비스(MSA)의 생존을 지키는 샌드박싱 철학으로 화려하게 부활했다.

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

개념: 페이지 교체의 타겟(Victim) 범위를 결정하는 기준이다. 프로세스 A가 램 100장을 할당받고, 프로세스 B가 200장을 할당받은 상태(균등/비례 할당)라고 치자. A가 101장째 페이지가 필요해 폴트(Page Fault)를 일으켰을 때, 지역 교체는 "너에게 허락된 100장 안에서 네가 안 쓰는 1장을 디스크로 버리고 새 걸 가져와! 절대 B의 방을 넘보지 마!"라고 철벽을 치는 정책이다.
필요성: 앞서 전역 교체(Global Replacement)는 효율은 좋았지만 '깡패 짓'이 가능했다. 악성 코드를 품은 앱 하나가 무한 루프를 돌며 램을 요청하면, 남의 앱(워드, 게임)의 램 프레임을 싹 다 뺏어버려 멀쩡한 앱들까지 화면이 뚝뚝 끊기게 만들었다. 특히 "내 프로그램은 무조건 1초 안에 100% 일정한 속도로 돌아야 한다"는 실시간 시스템(RTOS)이나 데이터베이스 입장에서, 남 때문에 내 램이 뺏겨서 속도가 들쭉날쭉(Jitter) 해지는 전역 교체의 변덕은 최악의 안티패턴이었다. 서로에게 피해를 주지 않는 철저한 방음벽이 필요했다.
💡 비유: 지역 교체는 회사 워크샵에서의 **엄격한 부서별 팀 회식비(법인카드 한도)**와 같다. 영업팀 카드의 한도가 100만 원, 개발팀 한도가 100만 원(정적 할당)이다. 영업팀이 고기를 엄청 먹어서 100만 원을 다 썼다. 이때 전역 교체(Global)는 영업팀이 고기를 더 시키기 위해 개발팀의 남은 돈 50만 원을 강제로 뺏어 쓰는 깡패 짓이다(개발팀은 굶음). 반면 지역 교체(Local)는 "예산 끝났으니 영업팀 너희는 더 이상 고기 시키지 말고, 먹던 고기를 토해내든(Swap-out) 집에 가든 너희 안에서 해결해!"라고 선을 그어, 개발팀이 조용히 회식을 끝까지 즐길 수 있게 완벽히 보호해 주는 매정한 철벽 룰이다.
등장 배경 및 고정 할당과의 콤비:
1. 정적 할당(Static Allocation)의 필수 짝꿍: 균등 할당이든 비례 할당이든 "처음에 할당량을 픽스(Fix)해준다"는 전제가 깔려야만 지역 교체가 성립할 수 있다. (내 몫이 정해져 있어야 내 몫 안에서 돌려막으니까).
2. 성능 격리(Performance Isolation): 1980년대 대형 컴퓨터 시절, 여러 회사가 비싼 서버 한 대를 쪼개서 임대해 쓸 때 남의 회사 배치 작업 때문에 내 회사 작업이 느려지면 소송이 걸렸다. 이를 막기 위한 철통 격리가 필수였다.
3. 효율성의 한계: 램이 10GB 남아돌아도, 자기 몫(10MB)을 다 쓴 프로세스는 죽어라 디스크만 긁는 끔찍한 비효율 때문에 결국 역사 속으로 잊히게 되었다.

┌─────────────────────────────────────────────────────────────────────────┐
│        지역 교체 (Local Replacement)의 꽉 막힌 철창 생태계 시각화       │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│ [ 상황: 물리 RAM 할당 현황 (할당량 픽스) ]                              │
│ ┌──────────────────────┬──────────────────────┐                         │
│ │ 프로세스 A의 철창 (100장)  │ 프로세스 B의 철창 (100장)  │             │
│ │ 100장 꽉 참 (여유 0)      │ 10장 씀 (90장 텅텅 빔)      │             │
│ └──────────────────────┴──────────────────────┘                         │
│                                                                         │
│ ▶ 위기 발생 (Page Fault)                                                │
│  프로세스 A: "데이터 하나만 더! 101장째 페이지 램에 올려줘!"            │
│                                                                         │
│ [ OS의 냉혹한 판결 (Local Replacement) ]                                │
│  OS: "야 프로세스 A. 네 철창 안에 빈 공간 0장인 거 보이지?"             │
│  OS: "B 철창에 90장 남아도는 거 나도 알아. 근데 규칙은 규칙이야."       │
│  OS: "네 철창(A) 안에서 가장 안 쓴 페이지 1장 골라서 스왑으로 던져."    │
│  OS: "그리고 그 1장 빈자리에 새 데이터 가져와서 써라."                  │
│                                                                         │
│ 💥 결과 (최악의 램 낭비):                                               │
│  - B의 램 90장은 텅텅 비어서 썩어 들어감 (메모리 낭비 극심).            │
│  - A는 혼자서 램 쫓아내고 가져오고 쌩고생을 하며 속도가 바닥을 김.      │
└─────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 그림 하나로 왜 데스크톱과 범용 리눅스 서버가 이 훌륭한 격리 기술을 쓰레기통에 처박고 전역(Global) 교체로 도망쳤는지 알 수 있다. 컴퓨터 자원이 수백만 원 하던 시절에, 램 90장을 놀리면서 한 앱을 버벅대게 방치하는 것은 공학적 범죄에 가까웠다. 지역 교체는 '안전함'을 얻기 위해 '전체 파이의 효율'을 처참하게 희생시키는 극단적 아키텍처다.

📢 섹션 요약 비유: 도서관에 내 지정석 1개, 남의 지정석 99개가 있습니다. 남의 자리 99개가 텅텅 비어있어도 지역 교체(Local) 룰 때문에 나는 내 좁은 지정석 1개에 책 수십 권을 쌓아 올리다 무너뜨리며(스래싱) 혼자 고통받아야 하는, 지독하게 융통성 없는 자리 배정 시스템입니다.

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

지역 교체 알고리즘의 내부 탐색 엔진

페이지 교체 시 누구를 희생양(Victim)으로 죽일지 고르는 알고리즘 자체는 전역이나 지역이나 똑같이 LRU, FIFO 등을 쓴다. 단지 검색하는 리스트의 범위(Scope)가 다를 뿐이다.

전역 교체 LRU 탐색: for(int i=0; i<전체_물리_프레임_400만개; i++) { ... } -> 시스템 전체를 훑어서 가장 늙은 놈 1명 사살.
지역 교체 LRU 탐색: for(int i=0; i<프로세스A에_할당된_프레임_100개; i++) { ... } -> 자기 몫의 짧은 리스트만 빠르게 훑어서 그 안의 가장 늙은 놈 1명 사살.

┌──────────────────────────────────────────────────────────────────────────┐
│              지역 교체의 숨은 장점: O(1) 수준의 빠른 탐색 오버헤드       │
├──────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│ [ 1. 교체 대상을 찾는 시간 (Search Overhead) ]                           │
│ - 전역 교체는 램에 깔린 수백만 장의 페이지 상태를 뒤져야 해서 OS가       │
│   백그라운드 데몬(kswapd)을 띄우고 CPU를 오지게 갉아먹음.                │
│ - 지역 교체는 딱 자기한테 할당된 100장 리스트만 순회하면 끝남!           │
│   탐색 속도 자체가 빛의 속도라 시스템 CPU 연산 낭비가 거의 없음.         │
│                                                                          │
│ [ 2. 메모리 기복 (Performance Jitter) 제로 ]                             │
│ - 전역 교체: 어제는 0.1초, 오늘은 남이 램 뺏어가서 5초 (복불복 심함).    │
│ - 지역 교체: 항상 나한테 100장이 고정되어 있으므로 1년 365일 내내        │
│   똑같이 1초 만에 실행이 끝나는 '시간 결정성(Determinism)' 완벽 보장!    │
└──────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 지역 교체를 그저 융통성 없는 바보라고 치부하면 안 된다. "내 프로그램이 어제는 빨리 돌았는데, 오늘은 왜 이렇게 버벅대지?"라는 스트레스를 원천 차단해 준다. 타인의 간섭(Noisy Neighbor)이 절대 뚫고 들어올 수 없으므로, 금융 거래나 미사일 궤도 계산 같은 '예측 가능한 런타임 성능'이 목숨보다 중요한 특수 분야에서는 오히려 전역 교체보다 수천 배 더 위대한 구원자가 된다.

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

비교 1: 전역 교체 (Global) vs 지역 교체 (Local) 최종 판결

면접의 단골 질문이자 클라우드 인프라 설계의 뼈대다.

평가 지표	전역 교체 (Global Replacement)	지역 교체 (Local Replacement)
물리 램 가동률(Throughput)	99% (빈 곳 싹싹 긁어 씀. 최고)	50% (남는 램 썩어 들어감. 최악)
타 프로세스 간섭도	최악 (남의 램 무자비하게 뺏음)	최상 (완벽한 독립 샌드박싱 0% 간섭)
스래싱(Thrashing) 전파	한 놈이 터지면 서버 전체로 렉이 전염됨	미친 놈 하나 터져도 걔 혼자 멈추고 서버는 평온
할당 베이스	동적 워킹 셋 (수시로 바뀜)	고정 할당 (균등/비례 등 픽스)
주 사용처	리눅스/윈도우의 일반 데스크탑 & 서버	Docker 컨테이너 한도 설정, RTOS

Noisy Neighbor (시끄러운 이웃)의 공포

아파트(서버)에 전역 교체를 켜두면, 매일 밤 쿵쾅대는 윗집 층간소음(Noisy Neighbor) 때문에 아래층 주민(멀쩡한 앱)들이 불면증(스래싱 렉)에 시달려 단체로 응급실에 실려 간다. 클라우드 사업자(AWS, Azure)는 이 시끄러운 이웃을 혐오한다. 내가 돈 내고 빌린 클라우드 서버가, 옆에 가상 머신(VM)을 빌린 남의 회사 트래픽 폭주 때문에 내 서버 램을 뺏겨서 렉이 걸린다면 당장 소송이 걸리기 때문이다. 그래서 클라우드 하이퍼바이저 층위에서는 이 전역 교체를 완벽히 박살 내고, 고객사별로 철저하게 램을 물리적으로 쪼개 묶어버리는 '지역 교체(Local)' 철학을 무조건 강제 적용한다.

📢 섹션 요약 비유: 전역 교체가 넓은 도서관 열람실에서 일찍 온 사람이 4인용 책상을 다 독차지하고 뒤에 온 사람이 바닥에 앉는 서바이벌 야생이라면, 지역 교체는 도서관에 칸막이 독서실을 짜놓고 1인 1실로 가둬서 옆방에서 헤비메탈을 틀든 잠을 자든 내 공부에는 1도 영향이 없게 만드는 프리미엄 독서실입니다. 공간 효율은 떨어져도 만족도는 최상이죠.

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

실무 시나리오: 도커(Docker) OOM Killer와 cgroups `memory.limit_in_bytes`

문제 상황: 현대 마이크로서비스(MSA) 인프라. 리눅스 서버 1대에 Node.js, Spring, Python 컨테이너 30개가 올라가 있다. 리눅스는 태생이 '전역 교체(Global)'다.
사고의 발생:
- 파이썬 앱에 무한 루프 메모리 릭 버그가 터졌다.
- 리눅스 전역 교체 로직이 파이썬을 돕기 위해 29개 컨테이너의 램을 싹 다 뺏어 파이썬에 부어줬다.
- 29개 앱의 서비스가 올스톱되는 서버 전체 블랙아웃이 발생했다.
cgroups를 통한 Local Replacement의 강제 부활:
- 쿠버네티스 엔지니어는 이 사태를 막기 위해 도커를 띄울 때 무조건 resources.limits.memory = "2Gi" (2기가바이트 제한) 옵션을 설정 파일(YAML)에 박아버린다.
- 이 옵션 하나가 리눅스의 전역 교체 심장에 '지역 교체 철창(cgroups)'을 꽂아 넣는다.
- 이제 파이썬 앱이 2GB를 넘게 쓰려고 하면, 리눅스 커널이 전역에서 램을 안 뺏어오고 그 파이썬 컨테이너 철창 안에서만 지역 교체(Local Replacement)를 돌린다.
- 돌려막기 하다가 2GB를 진짜 꽉 채우면? OS가 파이썬 컨테이너 딱 1놈만 깔끔하게 총으로 쏴 죽인다(OOM Killed).
- 결과: 나머지 29개의 컨테이너는 옆방 파이썬이 미쳐 날뛰다 죽는 동안 0.001초의 렉도 없이 평온하게 서비스를 이어간다. 고전적인 지역 교체 이론이 현대 클라우드 오케스트레이션의 가장 강력한 방어막으로 부활한 눈부신 실무 현장이다.

JVM 메모리 사이즈 고정의 비밀 (`-Xms`, `-Xmx`)

자바 백엔드 서버를 띄울 때 java -Xms4G -Xmx4G 처럼 시작 램과 최대 램을 4GB로 똑같이 묶어버리는 세팅이 국룰이다. 이는 OS가 램을 줬다 뺏었다 하는 전역 교체의 변동성(Jitter)을 거부하고, 아예 부팅할 때 OS로부터 4GB의 프레임을 통짜로 뜯어내 내 뱃속에 박아둔 뒤, 그 안에서 내가 자체적으로 가비지 컬렉션(GC)을 돌리며 순수 지역 교체 100% 샌드박스로 서버를 굴리겠다는 백엔드 개발자들의 거만한(?) 최적화 선언이다. 이 덕분에 자바 서버는 OS의 스왑 렉에 휘둘리지 않고 극강의 안정성을 유지한다.

📢 섹션 요약 비유: 수영장에 애들 30명을 다 풀어놓고 튜브(메모리) 쟁탈전을 벌이게(전역 교체) 두었다가 한 명이 다 뺏어서 사고가 나니, 아예 수영장에 30개의 레인을 치고 "너는 1번 레인에서 네 튜브 하나만 가지고 놀아!"라며 물리적으로 찢어버린(cgroups 지역 할당) 극강의 안전 조치입니다.

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

정량/정성 기대효과

구분	내용
장애 격리 (Fault Isolation)	1개의 악성 프로세스가 유발한 스래싱 지옥이 OS 전체의 CPU 사용률(load average)을 터뜨리는 연쇄 마비 완벽 차단
예측 가능성 (Predictability)	페이지 교체 시 장부 스캔 시간이 $O(1)$ 수준의 상수 시간으로 떨어져 실시간(RT) 처리에 필요한 타임 바운드 보장
클라우드 과금 정합성 확보	고객이 지불한 2GB 램 요금에 맞춰, 정확히 2GB 풀(Pool) 안에서만 교체가 돌게 강제하여 컴퓨팅 자원의 자본주의적 분배 실현

결론 및 미래 전망

지역 교체 (Local Replacement)는 자원이 모자랐던 과거에는 "남는 램을 버리는 최악의 비효율"이라 욕먹으며 교과서 구석으로 쫓겨난 비운의 알고리즘이었다. 자원의 활용률이 목숨보다 중요했던 90년대 리눅스 환경에서 이 폐쇄성은 설 자리가 없었다. 그러나 램 용량이 기가바이트를 넘어 테라바이트로 팽창하고 클라우드 가상화가 세상을 집어삼킨 현대에 와서, "효율(남의 것 뺏기)보다 격리(내 것만 지키기)가 수만 배 더 중요하다"는 새로운 패러다임이 도래하자 백조로 화려하게 부활했다. 오늘날의 시스템 아키텍처는 운영체제 하부에서는 1바이트까지 쥐어짜는 '전역 교체'의 칼춤을 추게 놔두고, 상부의 도커/KVM 하이퍼바이저 단에서는 강제로 쇠사슬을 채워 '지역 교체'의 샌드박스를 구축하는 이중(Dual) 구조의 기괴하고도 완벽한 타협을 이뤄냈으며, 이는 보안과 성능이 충돌하는 한 영원히 계속될 컴퓨팅 인프라의 표준 골조가 되었다.

📢 섹션 요약 비유: 가난하던 시절엔 온 가족이 거실 한가운데 연탄난로(전역 교체 램) 하나에 다닥다닥 붙어 싸우며 온기를 100% 흡수해야 살았지만, 부자가 된 현대에는 방마다 개별 보일러(지역 교체 락)를 달아서 빈방에 난방비(램 낭비)가 좀 새더라도 남의 눈치 안 보고 각자 쾌적하게 자는 독립 공간을 최고의 가치로 치는 시대적 진화입니다.

📌 관련 개념 맵 (Knowledge Graph)

전역 교체 (Global Replacement) | 빈방 없으면 옆집 문 부수고 램 뺏어오는, 효율은 우주 최강이지만 렉을 전염시키는 지역 교체의 영원한 라이벌
스래싱 (Thrashing) | 폴트가 미친 듯이 터지는 현상으로, 전역 교체에서는 서버 전체를 파멸시키지만 지역 교체에서는 그 앱 하나만 뻗고 끝나는 차이가 있음
cgroups (Control Groups) | 리눅스의 깡패 같은 전역 교체를 억누르고, 컨테이너별로 지역 교체를 강제하여 샌드박스를 치는 현대 클라우드의 방패막이
고정 할당 (Fixed Allocation) | 지역 교체가 성립하기 위해, "너는 100장만 써라"라고 부팅 시에 딱 못 박아주는 전제 조건
Noisy Neighbor (시끄러운 이웃) | 옆에 입주한 미친 앱이 램을 긁어가서 내 서버가 렉이 걸리는 클라우드 최악의 문제 (지역 교체로 완벽 차단 가능)

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

지역 교체가 뭔가요? 레고 놀이방에서 내 통에 레고 100개가 꽉 차서 새 레고를 못 넣을 때, 옆 친구 통이 비어있어도 절대 뺏지 않고 내 통 안에서 낡은 레고를 하나 버리고 넣는 아주 정직한 방법이에요.
왜 뺏으면 안 되나요? 내가 새 레고가 필요하다고 남의 것을 맘대로 뺏어오면(전역 교체), 그 친구는 레고가 부족해서 울음을 터뜨리고 놀이방 전체가 아수라장(서버 마비)이 되거든요.
무엇이 제일 좋나요? 내 통에 레고를 넣고 빼다 실수를 해서 내 성이 무너져도, 옆에서 성을 쌓고 있는 친구한테는 먼지 하나 튀지 않게(완벽한 보호막) 안심하고 놀 수 있답니다.