287. 내부 단편화 (Internal Fragmentation)

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

본질: 내부 단편화 (Internal Fragmentation)는 고정 크기 블록으로 메모리를 나눌 때, 할당된 블록 안쪽에 남지만 다른 요청에는 재사용할 수 없는 공간 낭비다.

가치: 이는 페이징 (Paging)이 외부 단편화 (External Fragmentation)를 없애고 주소 변환을 단순화하는 대가로 감수하는 비용이며, 주로 마지막 페이지에서 발생한다.

판단 포인트: 페이지 크기를 키우면 페이지 테이블과 TLB (Translation Lookaside Buffer) 효율은 좋아질 수 있지만, 내부 단편화는 커지므로 시스템 성격에 맞는 균형이 핵심이다.

Ⅰ. 개요 및 필요성

내부 단편화는 할당은 되었지만 실제 데이터가 채우지 못한 고정 블록 내부의 빈 공간을 뜻한다. 가상 메모리에서 운영체제가 페이지 (Page) 단위로 메모리를 나누면, 프로세스는 필요한 크기만큼 정확히 딱 맞춰 받는 것이 아니라 페이지 크기의 배수만큼 받게 된다. 예를 들어 10KB 프로그램을 4KB 페이지로 배치하면 3개 페이지가 필요하고, 마지막 페이지의 2KB는 남더라도 다른 프로세스가 가져다 쓸 수 없다.

이 현상이 중요한 이유는, 페이징이 해결한 문제가 원래 매우 치명적이었기 때문이다. 연속 할당에서는 빈 공간 총합이 충분해도 큰 연속 영역이 없으면 새 프로세스를 적재하지 못하는 외부 단편화가 생긴다. 반면 페이징은 모든 메모리를 같은 크기 프레임 (Frame)으로 잘라 배치하므로 이런 연속성 문제를 제거하지만, 대신 블록 경계 안쪽에서 자투리 공간이 남는 내부 단편화를 받아들인다.

아래 그림은 왜 내부 단편화가 "작지만 구조적으로 필연적인 낭비"인지를 보여준다.

┌────────────────────────────────────────────────────────────────────────────┐
│        10KB 프로세스를 4KB 페이지로 배치할 때의 내부 단편화 발생          │
├────────────────────────────────────────────────────────────────────────────┤
│ 요구 크기: 10KB                                                           │
│ 페이지 크기: 4KB                                                          │
│                                                                            │
│ Page 0  4KB ─────────────────────────────▶ Frame A  4KB 사용               │
│ Page 1  4KB ─────────────────────────────▶ Frame B  4KB 사용               │
│ Page 2  2KB 실제 데이터 + 2KB 남음 ─────▶ Frame C  전체 4KB 점유           │
│                                                                            │
│ Frame C 내부                                                               │
│ ┌──────────────────────────────┬────────────────────────────────────────┐  │
│ │ 실제 데이터 2KB              │ 남는 2KB = 내부 단편화                │  │
│ └──────────────────────────────┴────────────────────────────────────────┘  │
│                                                                            │
│ 핵심: 남는 2KB는 "비어 있어도" 다른 페이지에 재할당할 수 없다.            │
└────────────────────────────────────────────────────────────────────────────┘

즉 내부 단편화는 설계 실패라기보다, 정렬된 고정 단위 관리가 주는 질서의 비용이다. 메모리를 규격품처럼 다루기 때문에 배치와 교체는 쉬워지지만, 규격보다 작은 마지막 조각은 어쩔 수 없이 버리게 된다.

📢 섹션 요약 비유: 책장을 모두 같은 크기 서랍으로 만들면 정리는 쉬워지지만, 얇은 공책 하나를 넣어도 서랍 하나를 통째로 차지하게 된다. 내부 단편화는 바로 그 서랍 안의 남는 빈칸이다.

Ⅱ. 아키텍처 및 핵심 원리

내부 단편화는 고정 크기 할당과 주소 변환 단순화가 결합될 때 생긴다. MMU (Memory Management Unit)는 가상 페이지 번호와 페이지 오프셋을 분리해 물리 프레임으로 변환한다. 이때 페이지 크기가 고정되어 있어야 하드웨어가 빠르게 계산할 수 있고, 운영체제도 프레임 단위로 배치·교체·보호를 관리하기 쉽다.

핵심 계산은 단순하다. 어떤 프로세스 크기를 S, 페이지 크기를 P라고 하면 필요한 페이지 수는 ceil(S / P)이고, 내부 단편화 크기는 ceil(S / P) × P - S다. 따라서 최대 낭비는 페이지 크기보다 작고, 요청 크기가 다양한 환경에서는 평균적으로 마지막 블록 절반 정도가 비는 경향을 보인다.

항목	의미	내부 단편화와의 관계
페이지 크기 (Page Size)	메모리 관리의 기본 단위	클수록 최대 낭비량 증가
프레임 (Frame)	물리 메모리의 고정 블록	페이지가 적재되는 실제 자리
페이지 테이블 (Page Table)	페이지-프레임 매핑 정보	페이지가 작을수록 엔트리 수 증가
TLB	최근 주소 변환 캐시	페이지가 클수록 커버 범위 확대 가능

이 구조의 핵심 트레이드오프는 아래처럼 정리할 수 있다.

┌────────────────────────────────────────────────────────────────────────────┐
│                    페이지 크기 선택의 상반된 효과                         │
├───────────────────────────────┬────────────────────────────────────────────┤
│ 페이지 크기 작음              │ 페이지 크기 큼                            │
├───────────────────────────────┼────────────────────────────────────────────┤
│ 내부 단편화 감소              │ 내부 단편화 증가                          │
│ 세밀한 메모리 활용            │ 마지막 페이지 낭비 확대                   │
│ 페이지 수 증가                │ 페이지 수 감소                            │
│ 페이지 테이블 커짐            │ 페이지 테이블 작아짐                      │
│ TLB 도달 범위 축소            │ TLB 도달 범위 확대                        │
└───────────────────────────────┴────────────────────────────────────────────┘

따라서 내부 단편화는 단순히 "아까운 빈칸"이 아니라, 페이지 기반 메모리 시스템의 성능·복잡도·공간 효율이 만나는 접점이다. 운영체제가 4KB, 2MB, 1GB 같은 여러 페이지 크기를 병행하는 이유도 이 균형점을 상황별로 다르게 잡기 위해서다.

📢 섹션 요약 비유: 택배 상자를 너무 작게 만들면 상자 종류와 관리표가 많아지고, 너무 크게 만들면 빈 공간을 공기로 배송하게 된다. 내부 단편화는 상자 규격을 정할 때 항상 같이 따라오는 배송비 같은 문제다.

Ⅲ. 비교 및 연결

내부 단편화를 정확히 이해하려면 외부 단편화와 경계를 분명히 해야 한다. 외부 단편화는 빈 공간이 메모리 곳곳에 흩어져 있어서 전체 합은 충분하지만 연속 공간이 부족한 상태다. 반면 내부 단편화는 이미 할당된 블록 안쪽에서만 발생하는 잉여 공간이며, 메모리 관리자 입장에서는 남아 보여도 다른 요청에 줄 수 없다.

비교 항목	내부 단편화 (Internal Fragmentation)	외부 단편화 (External Fragmentation)
발생 위치	할당 블록 내부	할당 블록 사이
주 원인	고정 크기 할당	가변 크기 연속 할당
대표 환경	페이징, 고정 파티션	세그멘테이션, 동적 연속 할당
영향	작은 낭비의 누적	큰 요청 실패 가능
대표 대응	페이지 크기 조정, 다중 페이지 크기	압축, 페이징 도입

또한 내부 단편화는 단지 운영체제 문제에만 머물지 않는다. 컴퓨터 구조 관점에서는 페이지 크기가 TLB 적중률, 페이지 테이블 깊이, 캐시 친화성에 영향을 준다. 시스템 소프트웨어 관점에서는 메모리 할당자 슬랩 (Slab)이나 캐시 라인 정렬처럼 다른 계층에서도 같은 유형의 낭비가 반복된다. 즉 "규격화는 관리 효율을 주지만, 마지막 자투리를 만든다"는 패턴이 메모리 계층 전반에 공통으로 나타난다.

특히 Huge Page는 이 연결을 극단적으로 보여준다. 2MB나 1GB 페이지를 쓰면 주소 변환 오버헤드는 줄어들지만, 작은 작업이 큰 페이지를 점유할 경우 내부 단편화가 급증한다. 그래서 데이터베이스 버퍼 풀처럼 큰 연속 메모리를 오래 쓰는 워크로드에는 유리하지만, 짧고 작은 프로세스가 많은 환경에는 오히려 비효율적일 수 있다.

📢 섹션 요약 비유: 내부 단편화는 도시락 칸 안에 남은 반찬 자리이고, 외부 단편화는 식탁 위 여기저기 흩어진 빈 접시 공간이다. 둘 다 남는 공간이지만, 왜 못 쓰는지의 이유가 다르다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 내부 단편화를 절대값보다 워크로드 특성 대비 상대 비용으로 판단해야 한다. 예를 들어 수백 GB 메모리를 가진 서버에서 일반 4KB 페이지의 마지막 페이지 낭비는 대개 치명적이지 않다. 오히려 지나치게 작은 페이지를 써서 페이지 테이블 메모리와 페이지 워크를 늘리는 편이 더 비쌀 수 있다.

반대로 메모리가 매우 제한된 환경에서는 내부 단편화가 실질 손실이 된다. 예를 들어 수 MB 수준 메모리를 쓰는 임베디드 장비나, 수많은 짧은 프로세스가 동시에 뜨는 고밀도 컨테이너 환경에서는 프로세스마다 남는 마지막 페이지가 누적된다. 이때는 페이지 크기, 객체 풀 크기, 메모리 할당 전략을 함께 조정해야 한다.

판단 체크리스트

프로세스 또는 객체 크기가 페이지 크기보다 훨씬 작은가?
TLB 성능 이득이 내부 단편화 증가분보다 큰가?
Huge Page를 쓰려는 영역이 장시간 고정적으로 큰 메모리를 점유하는가?
메모리 부족이 실제 장애 원인인가, 아니면 주소 변환 오버헤드가 병목인가?

대표 안티패턴

무조건 큰 페이지 선호: "페이지 수가 줄면 무조건 빠르다"는 생각으로 전체 시스템에 Huge Page를 강제하는 경우다. 작은 프로세스가 많은 환경에서는 성능 이득보다 낭비가 더 커질 수 있다.
낭비 원인 혼동: 내부 단편화 문제를 압축 (Compaction)으로 해결하려는 접근은 방향이 틀렸다. 압축은 외부 단편화 대응책이지, 이미 할당 블록 내부에 남은 공간을 살려주지 못한다.

결국 기술사 관점의 답은 단순하다. 내부 단편화는 제거 대상이라기보다 통제 대상이다. 설계자는 페이지 크기, 다중 페이지 정책, 워크로드 특성을 함께 보고 "얼마나 버리고 얼마나 단순성을 얻을 것인가"를 수치로 판단해야 한다.

📢 섹션 요약 비유: 대형 버스를 투입하면 승객 계산은 편하지만, 손님이 두세 명뿐인 노선에서는 좌석 대부분이 빈 채로 달리게 된다. 실무 판단은 버스가 커서 멋져 보이느냐가 아니라, 그 노선에 정말 맞느냐를 보는 일이다.

Ⅴ. 기대효과 및 결론

내부 단편화를 감수하면 얻는 가장 큰 이점은 관리 단순성과 예측 가능성이다. 모든 페이지가 같은 크기이므로 메모리 할당, 주소 변환, 페이지 교체, 보호 비트 관리가 표준화된다. 이는 운영체제 구현을 단순하게 만들고, 하드웨어도 빠른 주소 계산과 캐싱 전략을 설계하기 쉬워진다.

물론 한계도 분명하다. 페이지 크기가 커질수록 마지막 페이지 낭비가 커지고, 메모리 밀도가 중요한 환경에서는 비용이 무시되지 않는다. 그래서 현대 시스템은 단일 해법보다 기본 페이지 + Huge Page 병행, 워크로드별 메모리 풀 분리, NUMA (Non-Uniform Memory Access) 및 캐시 특성까지 고려한 배치 같은 절충 전략으로 문제를 다룬다.

정리하면 내부 단편화는 "메모리를 반듯하게 관리하기 위해 지불하는 구조적 사용료"로 기억하는 것이 좋다. 외부 단편화를 없애고 성능 좋은 주소 변환 체계를 얻는 대신, 마지막 조각 몇 개는 포기하는 방식이다. 중요한 것은 낭비 자체를 제로로 만드는 것이 아니라, 그 낭비가 시스템 전체 이익보다 작도록 설계하는 일이다.

📢 섹션 요약 비유: 정리된 옷장에서는 옷을 빨리 찾을 수 있지만, 작은 양말 하나가 서랍 한 칸을 차지할 때도 있다. 좋은 설계는 빈칸이 아예 없는 옷장이 아니라, 찾기 쉽고 낭비도 감당 가능한 옷장이다.

📌 관련 개념 맵

개념	연결 포인트
페이징 (Paging)	내부 단편화를 유발하는 대표적 고정 크기 메모리 관리 방식
페이지 (Page) / 프레임 (Frame)	내부 단편화가 실제로 생기는 논리·물리 블록 단위
페이지 테이블 (Page Table)	페이지 크기 선택이 테이블 크기와 주소 변환 비용에 영향
TLB (Translation Lookaside Buffer)	큰 페이지가 TLB 도달 범위를 늘리지만 단편화는 키울 수 있음
Huge Page	주소 변환 효율과 내부 단편화 증가가 직접 충돌하는 사례
외부 단편화 (External Fragmentation)	내부 단편화와 대비해 메모리 낭비 위치와 해결책을 구분하게 해주는 개념

📈 관련 키워드 및 발전 흐름도

연속 할당의 외부 단편화 문제
    │
    ▼
페이징 (Paging) 도입
    │
    ▼
페이지 (Page) / 프레임 (Frame) 기반 고정 크기 관리
    │
    ▼
마지막 페이지 자투리 공간 = 내부 단편화
    │
    ▼
페이지 크기 최적화 · TLB 균형 설계
    │
    ▼
Huge Page · 다중 페이지 크기 정책으로 확장

이 흐름은 "연속성 문제 해결 → 고정 단위 관리 → 자투리 낭비 발생 → 성능과 낭비의 균형 최적화"라는 발전 방향을 보여준다.

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

사탕을 담는 상자가 모두 똑같이 크면 정리는 쉬운데, 작은 사탕 하나도 상자 하나를 다 써야 해요.
그래서 상자 안에 빈 자리가 남아도 다른 친구 사탕을 같이 넣을 수 없어요.
내부 단편화는 이렇게 "상자 안에 남았지만 못 쓰는 자리"예요.