Brain내부 단편화 (Internal Fragmentation)
핵심 인사이트 (3줄 요약)
- 본질: 내부 단편화(Internal Fragmentation)는 메모리를 미리 고정된 크기의 블록(파티션, 페이지 등)으로 나누어 할당할 때, 할당된 블록 크기보다 실제 적재된 프로세스의 크기가 작아서 남게 되는 잉여 공간을 의미한다.
- 가치: 이 공간은 OS 장부상 이미 해당 프로세스에게 "할당 완료"된 것으로 처리되므로, 시스템 전체에 메모리가 부족해도 다른 프로세스가 절대 가져다 쓸 수 없는 영구적인 **데드 스페이스(Dead Space)**가 된다.
- 융합: 고정 분할 방식에서 극단적으로 나타났으며, 현대의 페이징(Paging) 기법에서도 프로세스의 마지막 페이지 프레임에서 필연적으로 발생하지만 그 크기가 수 KB(평균 2KB)에 불과해 '허용 가능한 트레이드오프'로 취급된다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 내부 단편화는 메모리 할당 단위(블록) 내부에서 발생하는 조각(Fragment)이다. 메모리를 요구하는 프로세스에게 정확히 요구한 크기만큼만 주는 것이 아니라, 시스템 관리의 편의를 위해 "정해진 규격"으로 올림(Round up)하여 할당할 때 발생하는 필연적 차이(Delta)값이다.
-
필요성: 메모리 관리를 극도로 단순하게 만들고 속도를 높이려면, 모든 프로세스의 크기를 일일이 재고 맞춤 재단하는 것보다 기성복 사이즈(4KB, 8KB, 20MB 등)로 일괄 제공하는 것이 훨씬 빠르다. 즉, 내부 단편화는 **'빠르고 단순한 메모리 관리를 위해 의도적으로 지불하는 공간적 세금(Tax)'**이다.
-
💡 비유: 내부 단편화는 식당에서 무조건 4인용 테이블만 운영하는 것과 같다. 혼자 온 손님이 4인석에 앉으면 남는 의자 3개는 '내부 단편화'가 된다. 식당 입장에서는 다른 손님을 합석시킬 수 없으니 빈자리가 낭비되지만, 1인석/2인석/4인석을 복잡하게 관리할 필요가 없어 안내 속도가 빠르다는 장점을 취한 것이다.
-
등장 배경 및 발생 구조:
- 고정 분할 방식의 부작용: 다중 프로그래밍 초기에 메모리를 10MB, 20MB 등의 커다란 고정 파티션으로 나누었다. 20MB 방에 5MB 프로그램이 들어가면 15MB라는 거대한 내부 단편화가 발생해 시스템 효율을 심각하게 갉아먹었다.
- 가변 분할의 외부 단편화: 이를 해결하고자 가변 분할(프로세스 크기 딱 맞춤)을 도입했더니, 이번엔 내부 단편화는 0이 되었으나 외부 단편화(External)가 발생해 압축(Compaction) 비용이 폭발했다.
- 페이징의 타협: 결국 현대 OS는 메모리를 다시 고정 크기(4KB)로 쪼개는 페이징 기법으로 돌아왔다. 다만 블록 크기를 아주 작게(4KB) 만들어, 프로세스의 맨 마지막 블록에서만 최대 3.99KB의 내부 단편화가 발생하게끔 통제(Control)하는 타협안을 도출했다.
┌──────────────────────────────────────────────────────────────────┐
│ 내부 단편화(Internal Fragmentation)의 발생 메커니즘 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ [ 할당 정책: 블록 1개의 크기는 무조건 4KB (고정 크기) ] │
│ │
│ 프로세스 A의 총 요구 크기: 13KB │
│ │
│ ▶ 물리 메모리 할당 상태 │
│ [ 페이지 1 ] 4KB 꽉 참 │
│ [ 페이지 2 ] 4KB 꽉 참 │
│ [ 페이지 3 ] 4KB 꽉 참 │
│ [ 페이지 4 ] 1KB 사용 + [ 3KB 빈 공간 (내부 단편화 발생) ] │
│ │
│ 결과: 프로세스 A는 4개의 프레임(16KB)을 할당받았고, │
│ 마지막 프레임에서 3KB의 내부 단편화가 발생했다. │
│ (※ 이 3KB는 다른 프로그램이 절대 쓸 수 없음!) │
└──────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 내부 단편화의 수학적 본질은 할당된 공간 - 요구한 공간 = 잉여 공간(내부 단편화)이다. 위 그림처럼 페이징 환경에서 내부 단편화는 오직 프로세스의 '가장 마지막 페이지' 단 한 곳에서만 발생한다. 아무리 거대한(수 GB) 프로세스라도 발생하는 내부 단편화의 크기는 최대 4KB(정확히는 4KB - 1Byte)를 넘지 않는다. 평균적으로는 한 프로세스당 페이지 크기의 절반(약 2KB)의 내부 단편화가 발생한다.
- 📢 섹션 요약 비유: 계란 3개가 필요한데 마트에서는 10개들이 팩으로만 팔아서 어쩔 수 없이 한 팩을 사고 남은 계란 7개가 냉장고에서 썩어가는 현상입니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
내부 단편화 발생 아키텍처
내부 단편화는 소프트웨어(OS)와 하드웨어(MMU)의 매핑 로직 구조상 발생하는 필연적 결과다.
| 관여 요소 | 역할 | 내부 단편화와 관계 | 비유 |
|---|---|---|---|
| OS 할당기 (Allocator) | 빈 블록(Frame) 탐색 및 부여 | 요구 크기를 페이지 크기 배수로 '올림(Ceiling)'하여 할당함 | 옷의 기성 사이즈 올림 |
| 페이지 테이블 (Page Table) | 논리 → 물리 매핑 | 논리 페이지 1개당 물리 프레임 1개를 통째로 매핑함 | 1인 1실 배정표 |
| 물리 프레임 (Frame) | 실제 하드웨어 메모리 조각 | 남는 공간이 있어도 물리적으로 쪼개서 분할 제공 불가능 | 콘크리트로 지어진 방 |
블록 크기(Block Size)와 단편화의 상관관계 공식
시스템 설계자는 이 "규격(Block Size)"을 정할 때 심각한 트레이드오프에 직면한다.
- 페이지 크기를 키우면 (예: 4KB -> 4MB): 페이지 테이블 크기가 줄어들고 디스크 I/O 효율이 좋아지지만, 프로세스당 버려지는 내부 단편화 공간이 최대 3.99MB로 폭증한다. (메모리 낭비 심화)
- 페이지 크기를 줄이면 (예: 4KB -> 512Byte): 내부 단편화 낭비는 최대 511Byte로 줄어들지만, 수억 개의 조각이 생겨 페이지 테이블이 메모리의 절반을 차지해버리는 배보다 배꼽이 큰 상황이 발생한다.
┌────────────────────────────────────────────────────────────────────────┐
│ 페이지 크기 변화에 따른 내부 단편화 손실 곡선 │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ 내부단편화 낭비량 │
│ ▲ │
│ │ / (Huge Page: 2MB) │
│ │ / │
│ │ / │
│ │ / │
│ │ / │
│ │ / │
│ │ / │
│ │ / (Standard Page: 4KB) / │
│ │ / / │
│ │ / / │
│ └─────────────────────────────────────────▶ 페이지 크기 │
│ │
│ * 설계자의 결론: "내부 단편화를 완벽히 0으로 만드는 것은 불가능하다. │
│ 가장 이상적인 타협점이 4KB (또는 8KB)이다." │
└────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 이 그래프는 메모리 관리의 황금비율이 왜 4KB가 되었는지를 설명한다. 페이지 크기가 커질수록 '마지막 블록'에서 버려지는 공간의 기댓값이 선형적으로 증가한다. 내부 단편화는 막을 수 있는 에러가 아니라, 관리 비용(테이블 크기)을 줄이기 위해 자발적으로 지불하는 '구독료' 같은 개념이다.
- 📢 섹션 요약 비유: 택배 박스 규격을 무조건 우체국 5호 상자(큰 페이지)로 통일하면 포장 속도는 빠르지만 빈 공간(내부 단편화)에 뽁뽁이를 엄청 채워야 하고, 박스 규격을 100종류로 늘리면 낭비는 없지만 박스 찾느라 시간이 다 가는 것과 같은 딜레마다.
Ⅲ. 융합 비교 및 다각도 분석
비교 1: 내부 단편화 (Internal) vs 외부 단편화 (External)
이 두 개념을 완벽하게 구분하는 것이 메모리 관리의 핵심이다.
| 비교 항목 | 내부 단편화 (Internal Fragmentation) | 외부 단편화 (External Fragmentation) |
|---|---|---|
| 발생 위치 | 할당된 영역 내부 (In allocated space) | 할당된 영역 외부 (In free space) |
| 낭비 원인 | 프로세스 크기가 방 크기보다 작아서 (올림 계산) | 프로세스들이 나간 자리가 연속되지 않고 쪼개져서 |
| 사용 가능성 | 다른 프로세스가 절대 쓸 수 없음 (장부상 할당됨) | 쪼개져 있을 뿐, 이론적으로는 비어있음 (합치면 쓸 수 있음) |
| 주요 발생 기법 | 고정 분할 방식, 페이징(Paging) | 가변 분할 방식, 세그멘테이션(Segmentation) |
| 해결책 | 완벽한 해결 불가, 페이지 크기 축소로 손실 완화 | 메모리 압축(Compaction), 페이징 도입 |
결합 현상 (세그멘테이션 + 페이징)
현대 OS는 세그멘테이션(외부 단편화 발생)의 단점을 막기 위해, 세그먼트 내부를 다시 페이징(내부 단편화 발생)으로 쪼개는 Paged Segmentation 기법을 쓴다.
- 즉, 최신 시스템에서는 외부 단편화는 완전히 사라지지만, 각 세그먼트의 마지막 조각들에서 다수의 내부 단편화들이 존재하게 된다.
- "외부 단편화는 시스템을 멈추지만, 내부 단편화는 돈(RAM 용량)으로 때울 수 있다"는 공학적 결론이다.
┌──────────┬────────────┬────────────┬────────────────────┐
│ 메모리 기법│ 내부 단편화 │ 외부 단편화 │ 현대 OS 채택 │
├──────────┼────────────┼────────────┼────────────────────┤
│ 연속 고정 │ 매우 심함 │ 없음 │ 폐기 │
│ 연속 가변 │ 없음 │ 매우 심함 │ 폐기 │
│ 페이징 │ 약하게 존재 │ 없음 │ **주력** │
│ 세그멘테이션│ 없음 │ 심함 │ 보조 기법 │
└──────────┴────────────┴────────────┴────────────────────┘
[매트릭스 해설] 컴퓨터 공학자들은 내부 단편화와 외부 단편화라는 두 악마 중 하나를 선택해야 했다. 외부 단편화는 이를 해결하기 위해 메모리 전체를 멈추고 셔플하는 '압축(Compaction)'이라는 극악의 CPU 오버헤드를 유발한다. 반면 내부 단편화는 그냥 램 공간 조금 버리고 무시하면 시스템 속도에는 아무런 타격을 주지 않는다. 그래서 인류는 내부 단편화를 수용하는 쪽(페이징)으로 진화의 방향을 잡았다.
- 📢 섹션 요약 비유: '외부 단편화'가 길이 끊어져서 목적지에 가지 못하는 치명적 붕괴라면, '내부 단편화'는 갓길에 차를 세우면 남는 공간처럼 그냥 조금 아깝고 마는 감수할 수 있는 손해입니다.
Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)
실무 시나리오: Huge Page 도입 시의 OOM(Out of Memory) 스파이크
- 상황: 성능 최적화를 위해 데이터베이스(MySQL) 서버에 리눅스의 Huge Page (2MB)를 적용했다. 기본 4KB보다 512배 큰 블록이다.
- 내부 단편화 폭발:
- 시스템에 수많은 작은 프로세스(예: 백그라운드 스크립트, 크론잡)들이 50KB씩 메모리를 요청한다.
- OS는 할당 정책에 따라 이 50KB짜리 프로세스에게 무조건 2MB(Huge Page)를 통째로 떼어준다.
- 1개의 프로세스마다 무려 1.95MB의 내부 단편화(버려지는 공간)가 발생한다. 프로세스 1000개가 뜨면 2GB의 램이 허공으로 증발한다.
- 의사결정 판단:
- DB 서버처럼 수십 GB를 하나의 통짜 덩어리로 쓰는 프로세스에는 Huge Page가 좋지만, 이를 시스템 전역(Transparent Huge Pages)에 강제로 켜두면, 무수히 작은 프로세스들이 유발하는 거대한 내부 단편화 때문에 서버 메모리가 순식간에 고갈되어 OOM Killer가 발동한다.
- 실무에서는 이 두 가지 상황을 분리하여 적용해야 한다.
안티패턴: 과도한 구조체 정렬(Struct Alignment) 패딩
소프트웨어(C언어) 레벨에서도 내부 단편화가 존재한다.
struct { char a; int b; }를 선언하면, 5바이트가 아니라 컴파일러가 CPU 접근 속도를 위해 8바이트로 패딩(Padding)을 채운다. 이 버려진 3바이트 역시 프로그램 관점에서의 내부 단편화다. 네트워크 통신이나 파일 I/O 시 이를 방치하면 대역폭 낭비가 발생한다.
- 📢 섹션 요약 비유: 큰 창고(Huge Page)를 임대해 큰 물건(DB)을 넣는 건 좋지만, 작은 구슬(작은 프로세스) 하나 보관하려고 200평 창고를 통째로 대여하는 바보 같은 짓을 막는 것이 실무 튜닝의 핵심입니다.
Ⅴ. 기대효과 및 결론 (Future & Standard)
정량/정성 기대효과
| 구분 | 내용 |
|---|---|
| 관리 오버헤드 감소 | 빈 공간을 바이트 단위로 계산하고 쪼개는 연산 로직(Best-fit 등)을 없애 OS 스케줄링 고속화 |
| 예측 가능성 증가 | 메모리 할당과 해제가 항상 4KB 등 정해진 단위로 딱딱 떨어지므로 메모리 풀링(Pool)이 극도로 쉬워짐 |
| 공간적 희생의 수용 | 프로세스당 평균 (페이지 크기 / 2)의 공간 손실을 감수함으로써, 외부 단편화로 인한 시스템 정지를 방지 |
결론 및 미래 전망
내부 단편화 (Internal Fragmentation)는 메모리를 '고정된 블록 단위'로 관리하기로 한 인류의 결정이 낳은 필연적인 찌꺼기다. 메모리 용량이 수십 KB에 불과했던 과거에는 이 찌꺼기조차 아까워서 가변 분할(외부 단편화 방식)에 매달렸지만, 메모리가 수십 GB 단위로 커진 현대에는 4KB 안의 1~2KB 낭비는 현미경으로나 보이는 먼지에 불과해졌다. 관리의 고속화를 위해 약간의 재료 낭비를 쿨하게 허용하는 것, 이것이 컴퓨터 시스템 최적화에서 가장 널리 쓰이는 "공간(Space)을 버리고 시간(Time)을 벌어들인다"는 철학의 완벽한 표본이다.
- 📢 섹션 요약 비유: 두부를 자를 때 칼에 묻어나가 버려지는 두부 찌꺼기(내부 단편화)가 아깝다고 두부를 안 자르고 통째로 끓일 순 없는 것처럼, 맛있는 요리(빠른 시스템)를 위해 기꺼이 감수하는 필수불가결한 손실입니다.
📌 관련 개념 맵 (Knowledge Graph)
- 외부 단편화 (External Fragmentation) | 내부 단편화와 대척점에 있는 개념으로, 자투리 빈 공간이 흩어져 할당할 수 없는 악성 상태
- 페이징 (Paging) | 고정 분할 방식을 4KB 단위로 극소화시켜, 내부 단편화의 낭비를 최소 수준으로 억제한 가상 메모리 기법
- 단편화 낭비 공식 (Fragmentation Loss) | 페이징 환경에서 프로세스당 평균적으로 발생하는 내부 단편화 크기 = 페이지 크기 / 2
- 고정 분할 방식 (Fixed Partition) | 내부 단편화의 폐해가 가장 극단적으로(수십 MB 단위) 드러났던 초창기 연속 할당 기법
- 슬랩 할당기 (Slab Allocator) | 커널 내부에서 발생하는 미세한 내부 단편화조차 없애기 위해 객체 크기별로 캐시를 유지하는 최적화 기법
👶 어린이를 위한 3줄 비유 설명
- 내부 단편화가 무엇인가요? 신발가게에 250mm, 260mm, 270mm 사이즈만 팔아서, 내 발이 255mm인데 어쩔 수 없이 260mm를 사서 신발 안에 빈 공간이 헐렁하게 남는 현상이에요.
- 왜 딱 맞게 안 만들어 주나요? 세상 모든 사람의 발 사이즈를 1mm 단위로 다 맞춰서 신발을 만들면, 신발 공장이 너무 바빠지고 신발 가격이 10배로 비싸지거든요.
- 어떤 효과가 있나요? 조금 헐렁해서 공간 낭비(내부 단편화)는 있지만, 신발 가게에 가서 1초 만에 박스를 꺼내서 바로 신어보고 나갈 수 있는 엄청난 속도를 얻었답니다.