가변 분할 방식 (Variable Partition / Dynamic Partitioning)
핵심 인사이트 (3줄 요약)
- 본질: 가변 분할 방식(Variable Partition)은 메모리를 미리 잘라두지 않고, 프로세스가 실행을 요청하는 바로 그 순간 프로세스의 덩치(요구 크기)에 딱 맞춰 메모리 공간을 잘라서 할당하는 유동적인 연속 메모리 할당 기법이다.
- 가치: 프로그램 크기만큼만 정확히 할당하므로 고정 분할 방식의 치명적 결점이었던 내부 단편화(Internal Fragmentation)를 완벽하게 제거하여, 메모리 공간 활용률을 극적으로 끌어올렸다.
- 융합: 하지만 프로그램들이 들어오고 나가기를 반복함에 따라 메모리 중간중간에 쓸모없는 자투리 공간들이 흩어지는 **외부 단편화(External Fragmentation)**라는 새로운 재앙을 낳았고, 이를 합치는 압축(Compaction) 알고리즘 연구의 도화선이 되었다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 가변 분할 방식(MVT: Multiprogramming with a Variable number of Tasks)은 운영체제가 거대한 하나의 빈 물리 메모리 덩어리(Hole)를 가지고 있다가, 프로세스가 들어오면 그 크기만큼만 칼로 자르듯 분할하여 내어주고 나머지를 새로운 빈 구멍으로 관리하는 기법이다.
-
필요성: 고정 분할 방식은 20MB 방에 5MB 앱이 들어가면 15MB가 그냥 버려지는 뼈아픈 내부 낭비를 초래했다. 메모리가 금값보다 비싸던 시절, 이렇게 허무하게 증발하는 용량을 눈뜨고 볼 수 없었다. "손님이 요구하는 평수만큼만 정확히 가벽을 쳐서 임대해주자"는 유연한 임대 방식의 철학이 절실했다.
-
💡 비유: 가변 분할 방식은 치즈를 파는 푸드 트럭과 같다. 미리 잘라놓지 않고, 손님이 "치즈 300g만 주세요" 하면 거대한 치즈 덩어리에서 정확히 300g만 칼로 잘라내어 낭비 없이 팔고, 남은 덩어리는 다음 손님을 위해 남겨두는 장사법이다.
-
등장 배경 및 새로운 딜레마:
- 내부 낭비의 해결: 가변 분할 도입으로 내부 단편화는 0이 되었다. 이제 앱 크기보다 큰 방을 줘서 낭비되는 공간은 존재하지 않게 되었다. 다중 프로그래밍 정도(수)도 무한대로 늘어났다.
- 조각들의 발생: 프로세스들이 각기 다른 크기로 램을 점유하다가 종료(Exit)되면서 중간중간에 치아 빠지듯 빈 구멍(Hole)들이 생기기 시작했다.
- 외부 단편화(External Fragmentation) 출현: 10MB, 20MB, 15MB 등 작은 구멍들이 흩어지게 되었고, 남은 구멍의 총합은 45MB인데 30MB짜리 새 프로그램이 들어갈 '연속된 30MB 구멍'이 없어서 적재를 거부당하는 더 복잡한 사태가 벌어졌다.
┌───────────────────────────────────────────────────────────────────┐
│ 가변 분할 방식의 동작 흐름 및 외부 단편화 발생 과정 │
├───────────────────────────────────────────────────────────────────┤
│ │
│ [ 1. 초기 텅 빈 메모리 ] │
│ ┌─────┬───────────────────────────────────────┐ │
│ │ OS │ 텅 빈 거대한 공간 (Hole) 100MB │ │
│ └─────┴───────────────────────────────────────┘ │
│ │
│ [ 2. 프로세스 3개 맞춤형 할당 (낭비 0%) ] │
│ ┌─────┬────────┬──────────┬─────────────┬─────┐ │
│ │ OS │ A(20) │ B(30) │ C(40) │ 구멍10│ │
│ └─────┴────────┴──────────┴─────────────┴─────┘ │
│ │
│ [ 3. 프로세스 B가 종료되어 이탈 (외부 단편화 발생) ] │
│ ┌─────┬────────┬──────────┬─────────────┬─────┐ │
│ │ OS │ A(20) │ ▒구멍30▒ │ C(40) │ 구멍10│ │
│ └─────┴────────┴──────────┴─────────────┴─────┘ │
│ ※ 문제: 새 프로세스 D(35MB)가 들어오려 함. │
│ 구멍 총합은 40MB(30+10)지만, 연속된 35MB가 없어서 거절! │
└───────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 가변 분할은 시작은 아름다우나 끝은 파편화로 멍든다. 프로세스 크기가 제각각이기 때문에, 나간 자리에 다른 놈이 들어오면 반드시 조금씩 공간이 남게 된다. 이 자투리들이 쌓이고 쌓여 메모리 전체가 벌집처럼 구멍이 숭숭 뚫려버린다. 결국 OS는 이 구멍들을 장부(Free List)에 꼼꼼히 기록하고, 새 놈이 오면 어느 구멍에 넣어야 할지 머리를 쥐어뜯는 '동적 메모리 배치 문제'에 직면하게 된다.
- 📢 섹션 요약 비유: 주차장에 차 선을 그려놓지 않고 차가 오는 크기대로 바짝 붙여서 주차시키면 빈 공간이 남지 않아 좋지만, 큰 차가 나간 자리에 티코가 들어오면 양옆으로 애매한 폭의 빈 공간들이 생겨 결국 트럭을 못 대게 되는 '비정형 주차장의 혼돈'입니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
구성 요소
| 요소명 | 역할 | 내부 동작 | 관련 기술 | 비유 |
|---|---|---|---|---|
| 가변 파티션 | 프로세스 크기에 맞춰 생성된 공간 | 프로세스 적재 시점에 Base/Limit 레지스터 동적 세팅 | 동적 할당 | 맞춤 제작 양복 |
| 자유 공간 리스트 (Free List) | 남은 빈 구멍들의 주소/크기 장부 | 노드(Node) 형태로 구멍들의 위치와 길이를 연결 리스트로 관리 | Linked List | 빈 주차칸 크기 메모장 |
| 동적 메모리 배치 알고리즘 | 어느 구멍에 넣을지 결정하는 로직 | First-fit, Best-fit, Worst-fit 탐색 수행 | 배치 알고리즘 | 발렛파킹 직원의 두뇌 |
| 병합 (Coalescing) | 인접한 빈 구멍 통합 | 프로세스 종료 시, 양옆이 빈 공간이면 하나의 큰 구멍으로 합침 | 메모리 회수 | 옆 칸 비면 선 지워서 합치기 |
동적 메모리 배치 문제 (Dynamic Storage-Allocation Problem)
새로운 프로세스가 들어올 때, Free List에 흩어진 수많은 구멍(Hole) 중 과연 "어느 구멍"에 이 녀석을 집어넣을 것인가? OS는 3가지 뼈대 알고리즘을 사용해 결정을 내린다.
┌──────────────────────────────────────────────────────────────────────────┐
│ 동적 메모리 배치: 15MB 프로세스 P를 어디에 넣을까? │
├──────────────────────────────────────────────────────────────────────────┤
│ │
│ [ 현재 메모리 빈 구멍 상태: 순서대로 20MB, 10MB, 16MB, 30MB ] │
│ │
│ ▶ 1. 최초 적합 (First-Fit) │
│ 처음부터 찾다가 들어갈 수 있는(15MB 이상) 첫 구멍 무조건 선택! │
│ 결과: 맨 앞의 [ 20MB 구멍 ] 에 쏙! → 남은 5MB 쪼가리 발생 │
│ 장점: 찾는 속도가 우주 최강. (실무 채택률 1위) │
│ │
│ ▶ 2. 최적 적합 (Best-Fit) │
│ 모든 구멍을 싹 다 뒤져서, 나랑 크기가 '가장 비슷한' 구멍 선택! │
│ 결과: 전체 검색 후 [ 16MB 구멍 ] 에 쏙! → 남은 1MB 쪼가리 발생 │
│ 장점: 큰 구멍을 아껴둠. 단점: 찾느라 느리고 너무 작은 조각을 양산함. │
│ │
│ ▶ 3. 최악 적합 (Worst-Fit) │
│ 모든 구멍을 뒤져서, 무조건 시스템에서 '가장 거대한' 구멍 선택! │
│ 결과: [ 30MB 구멍 ] 에 쏙! → 남은 15MB 구멍 발생 │
│ 장점: 남은 구멍이 커서 딴 놈이 또 쓸 확률이 높음. 단점: 최악의 삽질. │
└──────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 이 3개의 알고리즘은 트레이드오프의 극치를 보여준다. 언뜻 보면 베스트 핏(Best-fit)이 가장 좋아 보이지만, 막상 16MB에 15MB를 넣으면 남는 1MB는 그 어떤 프로그램도 쓰지 못하는 완벽한 쓰레기 조각이 되어 외부 단편화를 악화시킨다. 반면 퍼스트 핏(First-fit)은 뇌를 비우고 맨 처음 보이는 곳에 찔러넣기 때문에 OS의 탐색 오버헤드를 극적으로 줄여주어, 시뮬레이션 결과 공간 효율과 속도 면에서 First-fit이 승리자임이 증명되었다.
최후의 수단: 메모리 압축 (Compaction)
가변 분할에서 외부 단편화가 한계에 달해 더 이상 프로그램을 못 올리게 되면, OS는 '압축(Compaction)'이라는 극약 처방을 내린다.
-
흩어진 모든 프로세스를 중단시키고, 메모리의 한쪽 끝으로 블록 셔플(Copy & Paste) 하듯 주루룩 밀어버린다.
-
이 과정에서 프로세스의 주소가 실시간으로 바뀌므로, 오직 '실행 시간 바인딩(Execution Time Binding)' 환경에서만 가능한 마법이다.
-
하지만 시스템 전체 메모리를 복사하는 막대한 오버헤드로 인해 시스템이 일시 정지하는 끔찍한 대가를 치른다.
-
📢 섹션 요약 비유: 테트리스를 하다가 블록 중간중간 구멍이 뻥뻥 뚫려서 게임 오버가 되기 직전에, 밑에서부터 남은 구멍들을 다 압축해서 한 줄 쫙 지워버리는 궁극기(압축)를 쓰는 것입니다.
Ⅲ. 융합 비교 및 다각도 분석
비교 1: 고정 분할 vs 가변 분할 vs 페이징
| 비교 항목 | 고정 분할 (Fixed) | 가변 분할 (Variable) | 페이징 (Paging - 비연속) |
|---|---|---|---|
| 할당의 철학 | 방 크기에 사람을 맞춤 | 사람 덩치에 방을 맞춤 | 사람을 4KB로 찢어서 방에 넣음 |
| 발생 단편화 | 내부 단편화 (최악) | 외부 단편화 (극악) | 내부 단편화 (매우 미미함) |
| 운영체제 연산 | 장부 기록(단순) | 배치 알고리즘 & 병합 연산 | 주소 매핑 테이블 관리 |
| 결론적 승자 | 초창기 배치 시스템용 | 1세대 다중 프로그래밍용 | 현대 OS의 최종 승리자 |
50퍼센트 규칙 (50-Percent Rule)
- 통계적 시뮬레이션 결과, 가변 분할 방식에서 First-fit 알고리즘을 사용해 메모리를 꽉꽉 채워 돌려도, 전체 메모리의 3분의 1(약 33%)은 영원히 사용 불가능한 외부 단편화 조각으로 남게 된다.
- 이를 '50퍼센트 규칙'이라 부르며 (할당된 메모리 N 블록일 때 빈 공간 0.5N 블록이 발생한다는 의미), 이 수학적 절망은 가변 분할 방식의 한계를 명확히 긋고 페이징으로 넘어가게 한 원흉이다.
┌──────────┬────────────┬────────────┬────────────────────────┐
│ 최적화 옵션│ 검색 속도 │ 남는 조각 크기│ 장기적 효율성 │
├──────────┼────────────┼────────────┼────────────────────────┤
│ First-fit│ 가장 빠름 │ 랜덤 (보통) │ 가장 우수 │
│ Best-fit │ 가장 느림 │ 너무 작아 못 씀│ 최악 (쓰레기 양산)│
│ Worst-fit│ 느림 │ 커서 재활용 됨│ 이론상 나쁘지 않음 │
└──────────┴────────────┴────────────┴────────────────────────┘
[매트릭스 해설] 인간의 직관(Best-fit)이 컴퓨터 시스템(First-fit)에서 항상 승리하는 것은 아님을 보여주는 대표적 사례다. 크기를 딱 맞추려다 보니 남는 짜투리가 너무 작아져서 누구도 못 쓰는 악성 재고가 되는 현상은, 알고리즘 설계 시 국소 최적화가 전체 최적화를 붕괴시키는 전형적인 안티패턴이다.
- 📢 섹션 요약 비유: 가변 분할은 찰흙을 떼어 파는 것과 같아서 낭비가 없어 보이지만, 결국 책상 위에 너무 작아서 쓸 데 없는 먼지 같은 찰흙 가루(외부 단편화)들만 30% 넘게 쌓이는 지저분한 구조입니다.
Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)
실무 시나리오: 애플리케이션 레벨의 힙(Heap) 메모리 관리
운영체제의 가상 메모리는 페이징으로 진화했지만, 재미있게도 **프로그램 내부의 힙(Heap) 메모리 관리(C언어의 malloc, 자바의 GC)**는 여전히 이 '가변 분할 방식'의 철학을 100% 그대로 따르고 있다.
- 상황: C언어에서
malloc(100),malloc(250)을 막 호출하다가 중간중간free()를 통해 메모리를 해제한다. - 힙 단편화(Heap Fragmentation): 프로그램 내부의 힙 공간은 마치 가변 분할 메모리처럼 외부 단편화로 구멍이 숭숭 뚫린다.
- 가비지 컬렉터(Garbage Collector)의 등장:
- 빈 구멍이 너무 많아져서 큰 객체를 할당할 수 없으면, 자바(Java)의 GC는 가변 분할의 '압축(Compaction)' 기법을 힙 메모리에 적용한다.
- 흩어진 객체들을 한곳으로 쫙 밀어붙이는데, 이때 시스템이 멈추는 'Stop-the-World (STW)' 현상이 발생한다. 이것이 바로 백엔드 개발자들을 밤새우게 만드는 튜닝의 원흉이다.
안티패턴: 파편화 방치
서버를 몇 달 동안 재부팅하지 않고 운영하면, 메모리 관리 체계의 파편화가 극에 달한다. 메모리는 50%나 남았는데, 새 프로세스를 띄우려 하면 OOM(Out of Memory) 에러를 내며 죽어버린다. 이는 가변 분할 구조의 근본적 모순이므로, 정기적인 압축이나 서버 재기동을 통한 메모리 파편화 해소(Defragmentation)가 필요하다.
- 📢 섹션 요약 비유: OS는 방 크기를 잘게 쪼개는 기술(페이징)로 도망쳤지만, 프로그래머가 방 안에서 자기 짐을 정리하는 방식(malloc)은 여전히 가변 분할의 저주(Stop-the-world)에 갇혀 고통받고 있는 아이러니입니다.
Ⅴ. 기대효과 및 결론 (Future & Standard)
정량/정성 기대효과
| 구분 | 내용 |
|---|---|
| 내부 단편화 0% | 프로세스 크기만큼 정확히 잘라 주므로, 할당된 공간 내에서 버려지는 메모리가 원천적으로 존재하지 않음 |
| 동시 실행 프로세스 극대화 | 고정 파티션 개수에 묶이지 않고, 메모리 총량이 허락하는 한 수십 개의 프로세스를 유연하게 적재 가능 |
| 다양한 프로세스 수용 | 극도로 작은 앱부터 램 용량에 육박하는 거대한 앱까지, 크기에 구애받지 않고 유연한 임대 방식 제공 |
결론 및 미래 전망
가변 분할 방식 (Variable Partition)은 고정 분할의 어리석음을 깨고 '동적이고 유연한 자원 할당'이라는 현대 컴퓨터 공학의 핵심 철학을 최초로 정립한 위대한 이정표다. 비록 OS 커널 레벨의 물리 메모리 관리에서는 '외부 단편화'의 한계를 넘지 못해 페이징(Paging)에 왕좌를 내어주었지만, 그 내면의 동적 메모리 배치 알고리즘(First-fit, Best-fit)과 흩어진 구멍을 합치는 압축(Compaction) 알고리즘은 오늘날 수많은 프로그래밍 언어의 가비지 컬렉터(GC)와 힙 관리 엔진 속에서 영원히 살아 숨 쉬고 있다.
- 📢 섹션 요약 비유: 기성복(고정 분할)만 팔던 시대에 나타난 맞춤 양복점(가변 분할)입니다. 천을 자르고 남은 자투리 천(외부 단편화)이 골칫거리지만, 손님 몸에 완벽하게 딱 맞는 옷(내부 단편화 제거)을 선사한 패션의 혁명입니다.
📌 관련 개념 맵 (Knowledge Graph)
- 외부 단편화 (External Fragmentation) | 가변 분할 방식의 치명적 부작용으로, 조각난 빈 공간의 합은 크지만 연속되지 않아 할당할 수 없는 상태
- 최초 적합 (First-Fit) | 동적 메모리 배치 알고리즘 중 공간 검색 속도가 가장 빨라 실무에서 가장 애용되는 기법
- 메모리 압축 (Compaction) | 외부 단편화를 해결하기 위해 프로세스를 한쪽으로 밀착시켜 거대한 빈 공간을 만드는 수집 연산
- 고정 분할 방식 (Fixed Partition) | 가변 분할 이전 시대에 방을 미리 일정한 크기로 잘라두어 내부 단편화를 유발했던 기법
- 가비지 컬렉터 (Garbage Collector) | 애플리케이션 내부의 힙 메모리에서 가변 분할의 철학을 차용하여 빈 공간을 병합하고 압축하는 시스템
👶 어린이를 위한 3줄 비유 설명
- 가변 분할 방식이 무엇인가요? 피자가게에서 손님이 "저 3조각만 주세요" 하면 3조각을 잘라주고, "5조각 주세요" 하면 5조각을 정확히 잘라주는 주문 제작 방식이에요.
- 무엇이 좋은가요? 손님이 배불러서 피자를 남기고 버리는 일(내부 낭비)이 절대로 생기지 않아서 음식을 아주 아껴 쓸 수 있어요.
- 무엇이 문제인가요? 그렇게 팔다 보니 피자판 여기저기에 파먹다 남은 1조각짜리 빵 부스러기(외부 단편화)가 너무 많이 생겨서, 나중에 4조각을 한 번에 원하는 손님한테는 예쁘게 이어진 피자를 줄 수가 없게 된답니다.