고정 분할 방식 (Fixed Partition / Static Partitioning)
핵심 인사이트 (3줄 요약)
- 본질: 고정 분할 방식(Fixed Partition)은 운영체제가 부팅될 때 물리 메모리를 사전에 정해진 크기의 여러 파티션(방)으로 영구적으로 쪼개어 놓고, 각 파티션에 하나의 프로세스만 들어가도록 하는 가장 원시적인 연속 메모리 할당 기법이다.
- 가치: 메모리 관리가 극도로 단순하다. 빈 파티션이 있으면 넣고, 없으면 대기시키면 끝이다. 알고리즘 오버헤드가 사실상 제로에 가깝다.
- 융합: 하지만 방 크기보다 작은 프로그램이 들어가면 남는 공간이 통째로 버려지는 치명적인 **내부 단편화(Internal Fragmentation)**를 유발하며, 이는 이후 프로그램 크기에 맞춰 방을 쪼개는 가변 분할 방식(Variable Partition)으로 진화하는 원인이 되었다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 고정 분할 방식(MFT: Multiprogramming with a Fixed number of Tasks)은 메모리를 파티션 단위로 나누며, 한 번 분할된 파티션의 크기와 개수는 시스템을 재부팅하기 전까지 절대 변하지 않는다. 각 분할의 크기는 모두 같을 수도 있고(균등 분할), 서로 다를 수도 있다(비균등 분할).
-
필요성: 초기 컴퓨터 시대(IBM OS/360 초기 버전 등)에 한 번에 여러 프로그램을 띄우는 '다중 프로그래밍(Multiprogramming)'을 구현해야 했다. 하지만 당시 하드웨어와 OS는 복잡한 메모리 계산을 감당할 성능이 없었다. 가장 쉽고 빠르게 시스템을 다중 사용자 환경으로 바꾸는 방법은 아예 램을 물리적인 바둑판처럼 미리 선을 그어놓고 배정하는 것이었다.
-
💡 비유: 고정 분할 방식은 코인 노래방에 크기가 똑같은 2인용 방을 10개 미리 만들어 놓는 것과 같다. 혼자 오든 둘이 오든 방 하나를 통째로 줘야 하고, 만약 3명이 오면 들어갈 방이 없어 노래를 아예 부를 수 없다.
-
등장 배경 및 발생 문제:
- 초기 다중 프로그래밍의 도입: CPU 유휴 시간(Idle time)을 줄이기 위해 메모리에 무조건 여러 프로그램을 구겨 넣어야 했다.
- 관리의 극단적 단순화 추구: 100MB 램을 20MB 방 5개로 쪼개 놓으면, OS는 방 5개의 비었는지 찼는지(0과 1)만 관리하면 된다.
- 내부 단편화의 비극: 20MB 방에 5MB짜리 작은 앱이 들어가면 나머지 15MB는 아무도 쓰지 못하고 썩어버린다(내부 단편화). 방이 다 차면 전체 램 용량이 남아돌아도 새 앱을 켤 수 없었다. 다중 프로그래밍 정도(Degree of Multiprogramming)가 파티션 개수로 엄격히 제한되었다.
┌───────────────────────────────────────────────────────────────────┐
│ 고정 분할 방식의 메모리 맵과 내부 단편화 발생 구조 │
├───────────────────────────────────────────────────────────────────┤
│ │
│ [ 균등 고정 분할 (모든 방 20MB) ] │
│ ┌────────────────┐ │
│ │ OS 영역 (10MB) │ │
│ ├────────────────┤ │
│ │ 파티션 1 (20M) │ ◀ 프로세스 A (18MB) 할당 → [ 2MB 낭비 ] │
│ ├────────────────┤ │
│ │ 파티션 2 (20M) │ ◀ 프로세스 B ( 5MB) 할당 → [15MB 낭비 ] │
│ ├────────────────┤ (※ 이 버려진 공간을 '내부 단편화'라 함) │
│ │ 파티션 3 (20M) │ ◀ 텅 빈 방 │
│ ├────────────────┤ │
│ │ 파티션 4 (20M) │ ◀ 프로세스 C (25MB) 요청 → [적재 거부!] │
│ └────────────────┘ (방보다 커서 영원히 실행 불가) │
└───────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 고정 분할 방식의 아킬레스건을 보여준다. 프로세스 B는 단 5MB만 필요하지만 파티션 전체(20MB)를 독점해버려 15MB가 증발한다. 더 심각한 것은 프로세스 C다. 25MB짜리 프로그램은 시스템 전체에 남은 메모리가 50MB가 넘음에도 불구하고, 어떤 단일 파티션 크기(20MB)보다 크기 때문에 이 시스템에서는 아예 실행조차 되지 못한다. 파티션 크기를 넘는 대형 프로그램은 오버레이(Overlay) 기법을 써서 개발자가 수동으로 코드를 잘라 올려야 했다.
- 📢 섹션 요약 비유: 신발 가게에서 260mm 사이즈 상자 100개만 만들어놓고, 240mm 발을 가진 사람은 헐렁하게(낭비) 신게 하고, 270mm 발을 가진 사람은 아예 쫓아내 버리는 경직된 판매 전략입니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
구성 요소
| 요소명 | 역할 | 내부 동작 | 관련 기술 | 비유 |
|---|---|---|---|---|
| 파티션 (Partition) | 프로그램이 적재되는 고정된 공간 | 부팅 시 분할되어 고정된 시작/끝 물리 주소를 가짐 | Memory Block | 기숙사의 고정된 1인실 방 |
| 할당 상태 테이블 | 각 파티션의 사용 여부 기록 | 파티션 1: 사용(1), 파티션 2: 빈방(0) 등 단순 비트맵 | 비트맵(Bitmap) | 기숙사 경비실의 빈방 불빛 |
| 작업 큐 (Job Queue) | 디스크에서 대기 중인 프로그램 줄 | 파티션마다 개별 큐를 두거나, 하나의 통합 큐를 운영 | Scheduling Queue | 방 배정을 기다리는 대기 줄 |
| MMU 방어선 | 파티션 밖 메모리 침범 방지 | 베이스와 한계 레지스터가 해당 파티션 크기로 락(Lock)됨 | Memory Protection | 방을 못 벗어나게 하는 자물쇠 |
작업 큐(Job Queue) 운영 아키텍처
고정 분할 방식에서 비균등 분할(크기가 다른 파티션 혼재)을 사용할 경우, 대기 중인 프로세스들을 어떻게 방에 배정할 것인지 큐 운영 아키텍처가 두 가지로 나뉜다.
┌────────────────────────────────────────────────────────────────────────┐
│ 비균등 고정 분할의 작업 큐 운영 방식 2가지 │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 파티션별 다중 큐 (Multiple Queues) │
│ [10M 대기줄] → [ P A ] ───▶ [ 파티션 1 (10MB) ] │
│ [20M 대기줄] → [ P B, C] ──▶ [ 파티션 2 (20MB) ] │
│ [30M 대기줄] → (텅 빔) ───▶ [ 파티션 3 (30MB) ] 놀고 있음! │
│ 장점: 내 몸에 맞는 방을 바로 감. 단점: 빈방이 있어도 줄을 못 서면 놀림.│
│ │
│ 2. 단일 통합 큐 (Single Queue) │
│ ┌─▶ [ 파티션 1 (10MB) ] │
│ [모든 프로세스 통합 대기줄] ──────┼─▶ [ 파티션 2 (20MB) ] │
│ [ P A, P B, P C, P D ... ] └─▶ [ 파티션 3 (30MB) ] │
│ 장점: 빈 파티션이 생기면 줄 맨 앞의 애가 바로 들어감 (공간 활용 높음) │
│ 단점: 10M짜리가 30M 방에 들어가면 내부 단편화(20M 낭비) 극심해짐. │
└────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 초기에는 1번 방식(크기별 큐)을 썼다. 하지만 30MB짜리 큰 프로그램이 별로 없어서 가장 큰 방은 항상 비어있고, 작은 방 큐는 터져나가는 스케줄링 불균형이 발생했다. 이를 해결하기 위해 2번 단일 큐로 바꾸었더니, 방이 비기 무섭게 작은 프로그램들이 큰 방을 차지해버려 '내부 단편화'가 극단적으로 심해지는 진퇴양난의 트레이드오프에 빠졌다.
내부 단편화 (Internal Fragmentation)의 본질
-
정의: 파티션(할당된 공간)의 크기보다 그 안에 적재된 프로세스의 크기가 작아서, 파티션 내부에 남아도는 아무도 못 쓰는 잉여 공간.
-
외부 단편화(External)가 밖(시스템 전체)에 흩어진 파티션 바깥의 빈 공간이라면, 내부 단편화는 파티션 '내부'의 닫힌 공간에서 발생하는 낭비다.
-
이 공간은 OS 입장에서는 "이미 그 프로세스에게 줬다"고 장부에 적혀있으므로, 다른 프로세스가 절대 가져다 쓸 수 없다.
-
📢 섹션 요약 비유: 피자 라지 사이즈(고정 파티션)를 한 판 시켰는데, 나는 2조각(프로세스 크기)만 먹고 배불러서 남은 6조각(내부 단편화)은 버려버리는 지독한 식량 낭비 상황입니다.
Ⅲ. 융합 비교 및 다각도 분석
비교 1: 고정 분할 vs 가변 분할
| 비교 항목 | 고정 분할 (Fixed Partition) | 가변 분할 (Variable Partition) |
|---|---|---|
| 파티션 크기 | 부팅 시 고정됨 (불변) | 프로세스 크기에 맞춰 런타임에 동적으로 잘라줌 |
| 단편화 종류 | 내부 단편화 발생 (방이 남음) | 외부 단편화 발생 (자투리 공간이 쪼개짐) |
| 다중 프로그래밍 정도 | 파티션 개수(N)로 고정 제한됨 | 메모리가 꽉 찰 때까지 무한정 유동적임 |
| OS 관리 오버헤드 | 거의 제로 (가장 단순함) | 빈 공간을 찾고 합치느라 연산 리소스 소모 |
| 프로세스 크기 한계 | 가장 큰 파티션보다 큰 앱은 절대 실행 불가 | 남은 전체 빈 공간 안에서는 어떻게든 실행 가능 |
현대 페이징(Paging) 기법과의 기묘한 유사성
놀랍게도 가장 원시적인 고정 분할 방식은 현대의 최첨단 기법인 '페이징(Paging)' 기법과 철학적 뿌리가 맞닿아 있다.
- 페이징 기법 역시 물리 메모리를 4KB 크기의 똑같은 방(Frame)으로 '고정 분할' 해놓은 것이다.
- 단지 옛날 고정 분할은 방이 수십 MB로 거대해서 낭비(내부 단편화)가 심했을 뿐, 페이징은 방 크기를 4KB로 아주 잘게 쪼개어 마지막 1개 프레임에서 발생하는 내부 단편화의 피해를 평균 2KB로 최소화시켰다는 차이만 있을 뿐이다.
┌──────────┬────────────┬────────────┬────────────────────┐
│ 기법 │ 분할 크기 │ 내부 단편화 │ 프로세스 배치 │
├──────────┼────────────┼────────────┼────────────────────┤
│ 고정 분할 │ 10MB ~ │ 매우 큼 │ 통째로 1방에 │
│ 페이징 │ 4KB 고정 │ 평균 2KB │ 수천 방에 찢어 │
└──────────┴────────────┴────────────┴────────────────────┘
[매트릭스 해설] 컴퓨터 공학은 돌고 돈다. 관리하기 귀찮아서 고정 크기로 잘랐던 투박한 과거의 방식이, 시간이 흘러 하드웨어가 발전하자 방 크기를 현미경 단위(4KB)로 썰어버리면서 외부 단편화를 완벽히 잡아내는 궁극의 기술(페이징)로 재탄생한 것이다.
- 📢 섹션 요약 비유: 옛날엔 수박을 반 갈라 파는 고정 분할이라 다 못 먹고 버리는 내부 낭비가 컸다면, 지금은 깍둑썰기로 4KB씩 잘게 파는 페이징으로 진화하여 낭비 없이 먹을 수 있게 된 것입니다.
Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)
실무 시나리오: 메인프레임과 은행 배치 처리
-
과거의 영광 (IBM OS/360):
- 1960년대, 다수의 은행 월말 정산 배치(Batch) 프로그램을 돌리기 위해 IBM은 MFT(고정 분할 다중 프로그래밍) OS를 개발했다.
- 은행 관리자는 매일 아침 "1번 방은 50MB 컴파일러용, 2번 방은 30MB 급여 정산용" 식으로 펀치 카드를 뚫어 파티션을 하드코딩으로 세팅했다.
- 이토록 원시적이었지만, OS가 메모리 관리 연산을 하느라 버벅대는 낭비가 '0'에 가까웠으므로, 주어진 배치 작업을 밀어내는 처리량(Throughput) 면에서는 당대 최강의 효율을 자랑했다.
-
현대적 잔재: 가상 머신(VM) 및 컨테이너 제한
- 오늘날의 클라우드 환경에서 하이퍼바이저(VMware 등)가 게스트 OS에 메모리를 할당할 때 "RAM 4GB 고정 할당"을 거는 행위는, 논리적으로는 이 거대한 고정 분할 방식의 오마주라 볼 수 있다.
- 즉, 게스트 OS가 1GB만 써도 나머지 3GB는 호스트가 가져가지 않고 버려두는(내부 단편화) 대신, 격리와 할당의 관리 오버헤드를 제로로 만드는 강력한 보안/관리 정책이다.
- 📢 섹션 요약 비유: 헬스장에서 한 달 치 락커룸 비용을 통째로 내게(고정 할당) 만들면, 회원이 며칠 안 와서 락커가 비더라도(내부 단편화) 헬스장 사장님은 복잡하게 관리할 필요 없이 돈 계산이 편해지는 원리입니다.
Ⅴ. 기대효과 및 결론 (Future & Standard)
정량/정성 기대효과
| 구분 | 내용 |
|---|---|
| OS 오버헤드 최소화 | 복잡한 런타임 빈 공간 검색 알고리즘이나 쓰레기 수집 연산이 필요 없어 속도 저하 제로 |
| 결정론적 다중 프로그래밍 | 실행 중인 프로세스의 최대 개수가 파티션 수로 엄격히 통제되어 시스템 과부하(OOM) 원천 차단 |
| 보안 및 격리 용이성 | 파티션의 경계선이 고정되어 있어 한계 레지스터 설정이 영구적이고 실수가 없음 |
결론 및 미래 전망
고정 분할 방식 (Fixed Partition)은 메모리라는 자원을 효율성보다는 '관리의 편의성'과 '시스템 오버헤드 최소화'에 방점을 두고 설계한 초창기 컴퓨터 공학의 순수한 유산이다. 너무 큰 내부 단편화와 경직성 때문에 범용 메모리 관리 아키텍처에서는 가변 분할과 페이징으로 왕좌를 넘겨주고 사라졌다. 하지만, 이 '고정된 크기로 자른다'는 발상의 단순성은 현대에도 하드웨어 캐시(Cache Line), 네트워크 패킷 스위칭(MTU), 블록 스토리지 등 오버헤드를 극도로 혐오하는 모든 초고속 하드웨어 설계의 밑바탕에 진리로 살아 숨 쉬고 있다.
- 📢 섹션 요약 비유: 뷔페 식당을 운영할 때, 손님이 얼만큼 먹을지 매번 재서 담아주기 귀찮으니까 그냥 똑같은 크기의 식판에 일괄 배식(고정 분할)하여 버려지는 짬타이거(내부 단편화)를 감수하더라도 배식 속도를 빛처럼 빠르게 만든 시스템입니다.
📌 관련 개념 맵 (Knowledge Graph)
- 내부 단편화 (Internal Fragmentation) | 고정된 공간에 그보다 작은 프로세스가 들어가며 남게 된, 영원히 낭비되는 구멍
- 가변 분할 방식 (Variable Partition) | 고정 분할의 내부 낭비를 해결하기 위해, 프로세스 크기만큼만 딱 맞춰서 메모리를 잘라주는 발전된 기법
- 다중 프로그래밍 정도 (Degree of Multiprogramming) | 메모리에 동시에 올라가 있는 프로세스의 수로, 고정 분할에서는 파티션 개수와 정확히 일치함
- 페이징 (Paging) | 고정 분할의 논리를 미시적 세계(4KB)로 끌고 내려와 외부 단편화를 없앤 현대 가상 메모리 기법
- 단일 큐 / 다중 큐 스케줄링 | 비균등 고정 분할 환경에서 프로세스들을 어떻게 대기시키고 방에 넣을지 결정하는 알고리즘
👶 어린이를 위한 3줄 비유 설명
- 고정 분할 방식이 무엇인가요? 호텔 주인이 처음 건물을 지을 때, 모든 방을 똑같은 침대 2개짜리 고정된 크기로 미리 벽돌로 막아놓은 거예요.
- 무엇이 편한가요? 손님이 올 때마다 "몇 명이세요? 방을 얼만큼 쪼개드릴까요?" 고민할 필요 없이 무조건 방 하나씩 열쇠만 던져주면 돼서 안내 속도가 엄청 빠르죠.
- 무엇이 문제인가요? 혼자 여행 온 손님이 들어가도 침대 하나는 남아서 낭비되고(내부 단편화), 3명 가족이 오면 방 하나에 못 들어가서 호텔에서 쫓겨나게 된답니다.