페이징 (Paging)

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

본질: 페이징 (Paging)은 프로세스가 사용하는 논리적 가상 메모리와 물리적 RAM 공간을 모두 동일한 크기(보통 4KB)의 고정된 블록(Page / Frame)으로 잘게 썰어서 1:1로 매핑시키는 현대 운영체제의 절대적인 메모리 관리 기법이다.

가치: 메모리를 깍두기처럼 똑같은 크기로 썰어버림으로써 남는 빈 공간을 찾기 위한 복잡한 연산을 없애고, 빈 곳이 생기는 즉시 순서와 상관없이 아무 페이지나 끼워 넣을 수 있어 외부 단편화(External Fragmentation) 문제를 100% 원천 차단했다.

융합: 하지만 페이지가 수백만 개로 쪼개지면 이를 관리하는 지도(Page Table) 자체가 너무 무거워지므로, 하드웨어 주소 변환 캐시인 **TLB(Translation Lookaside Buffer)**와 다단계 페이지 테이블(Hierarchical Paging) 기법이 필수적으로 융합되어 성능 저하를 막아낸다.

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

개념: 가상 메모리를 페이지(Page)라는 고정 크기 블록으로 나누고, 물리 메모리를 프레임(Frame)이라는 똑같은 크기의 블록으로 나누어, OS가 찢어진 페이지들을 흩어져 있는 빈 프레임에 테트리스처럼 욱여넣고 페이지 테이블로 길을 연결해 주는 기술이다.
필요성: 페이징이 없던 시절(연속 메모리 할당)에는 100MB짜리 프로그램을 띄우려면 RAM에 100MB의 '빈 연속 공간'이 있어야만 했다. 하지만 10MB, 20MB짜리 프로그램들이 켜졌다 꺼졌다를 반복하며 RAM은 치즈처럼 구멍이 숭숭 뚫렸고, 빈 공간을 다 합치면 200MB인데 정작 100MB짜리 연속 공간이 없어서 프로그램을 실행 못 하는 끔찍한 **외부 단편화(External Fragmentation)**가 발생했다. 이를 막으려면 애초에 프로그램을 "연속적으로 올리지 않겠다"는 발상의 전환이 필요했다.
💡 비유: 이삿짐을 나를 때 책상, 냉장고, 침대 모양 그대로(연속 할당) 트럭에 실으면 트럭 사이사이에 남는 공간(외부 단편화)이 생겨 짐을 다 못 싣는다. 하지만 모든 가구를 부수고 **'가로세로 30cm짜리 똑같은 우체국 규격 박스(Page)'**에 나눠 담아 싣게 하면, 트럭의 빈 공간 1cm까지 낭비 없이 100% 채울 수 있는 것과 완벽히 일치한다.
등장 배경: 1960년대 초반 Ferranti Atlas 컴퓨터에서 처음 개념이 증명되었으며, 이후 프로세스가 메모리의 연속성에 얽매이지 않고 남는 자원을 극한으로 활용하려는 다중 프로그래밍(Multiprogramming)의 핵심 도구로 모든 범용 OS를 지배하게 되었다.

  [연속 할당의 한계(외부 단편화) vs 페이징의 불연속 매핑 마법]

  [ ❌ 과거: 연속 할당 (외부 단편화 발생) ]
  물리 RAM: [ P1 10M ] [ 빈 10M ] [ P2 20M ] [ 빈 20M ]
  ▶ 25MB짜리 P3 실행 요청 ─▶ 🚨 거절! 빈 공간 합치면 30M인데, 연속된 25M가 없음! 

  [ ✅ 현대: 페이징 (불연속 할당) ]
  - P3 (25MB) 를 4KB 단위로 잘게 썬다. (약 6,400개의 페이지 생성)
  - RAM의 빈 공간 여기저기(떨어져 있어도 상관없음)에 6,400개를 막 쑤셔 넣는다.
  - CPU가 P3를 실행할 때, "페이지 테이블"이라는 내비게이션을 보고 
    이리저리 흩어진 조각들을 순서대로 찾아가며 완벽하게 실행해 낸다.

[다이어그램 해설] 페이징은 인간의 직관(연속성)을 철저히 파괴하고 기계의 효율성(파편화 허용)을 극대화한 시스템이다. 메모리가 물리적으로 찢어져 있어도, CPU 입장에서는 **"페이지 테이블이 가리키는 주소로 가면 무조건 다음 코드가 있다"**는 논리적 연속성(Logical Contiguity)만 보장되면 그만이기 때문이다.

📢 섹션 요약 비유: 영화 필름을 통째로 1개 영화관에서 틀면 다른 영화를 못 틉니다(연속 할당). 하지만 영화를 1초 단위 필름 조각(Page)으로 다 잘라서 전국 100개 영화관(Frame)에 흩뿌려 놓고, 관객의 눈앞에 특수 안경(페이지 테이블)을 씌워 그 조각들을 원래 순서대로 이어지게 보여주면(논리적 연속), 공간 낭비 0%로 모든 관객이 영화를 볼 수 있습니다.

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

페이징의 3대 핵심 구조체 (Page, Frame, Page Table)

페이지 (Page): 개발자가 짠 프로그램(가상 메모리)을 일정한 크기로 자른 조각. (예: Page 0, Page 1...)
프레임 (Frame): 실제 물리적 RAM을 페이지와 똑같은 크기로 자른 빈 방. (예: Frame 3, Frame 10...)
페이지 테이블 (Page Table): "Page 1번은 Frame 10번에 있다"라고 매핑해 두는 커널 메모리 속의 1차원 배열(지도).

CPU 주소 변환 (Address Translation)의 수학적 원리

CPU는 프로그램 코드에 적힌 **가상 주소(Logical Address)**만 본다. MMU(메모리 관리 장치) 하드웨어가 이 가상 주소를 쪼개서 진짜 **물리 주소(Physical Address)**로 변환한다.

가상 주소는 두 부분으로 나뉜다: $v = (p, d)$

$p$ (Page Number): 페이지 테이블에서 내가 찾을 조각의 인덱스 번호. (책의 몇 번째 '장'인가?)
$d$ (Page Offset): 그 페이지 조각 안에서의 변위(떨어진 거리). (그 '장' 안에서 몇 번째 '줄'인가?)

  ┌────────────────────────────────────────────────────────────────────────┐
  │         MMU의 페이징(Paging) 주소 변환 매커니즘 (가상 ─▶ 물리)         │
  ├────────────────────────────────────────────────────────────────────────┤
  │                                                                        │
  │  [ CPU가 가상 주소 0x1234 를 요청함 ]                                  │
  │  (가정: 페이지 크기 4KB = 0x1000 이므로 하위 3자리가 Offset임)         │
  │                                                                        │
  │  1. 주소 쪼개기: p = 0x1 (페이지 번호 1번), d = 0x234 (오프셋)         │
  │                                                                        │
  │  2. 페이지 테이블(Page Table) 조회                                     │
  │     [ Index ]    [ Frame Number ]    [ Valid ]                         │
  │       0번           5번                 v                              │
  │     ▶ 1번           9번 (0x9)          v  ◀ (여기 매핑됨!)             │
  │       2번          15번                 v                              │
  │                                                                        │
  │  3. 물리 주소 합성: Frame(0x9) + Offset(0x234)                         │
  │     ▶ 🌟 최종 물리 주소: 0x9234                                        │
  │                                                                        │
  │  4. RAM의 0x9234 번지에 꽂혀있는 진짜 데이터를 가져와 CPU에 바침.      │
  └────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 여기서 가장 소름 돋는 점은 오프셋($d$)은 절대 변하지 않는다는 것이다. 가상 메모리에서 1페이지의 50번째 줄에 있던 데이터는, 물리 메모리 프레임으로 통째로 이사 가도 여전히 그 프레임의 50번째 줄에 있다. 박스 채로 짐을 옮겼기 때문이다. MMU는 단지 "박스 번호(p)"를 "트럭 번호(f)"로 치환하는 단순 문자열 치환 놀이만 할 뿐이다.

📢 섹션 요약 비유: CPU가 "아파트 1동 302호(가상 주소)로 배달해 줘!"라고 요청하면, 경비실(MMU) 장부(페이지 테이블)를 봅니다. "1동 사람들은 이번 달에 물리적으로 9동 건물(프레임)로 이사 갔지. 하지만 호수는 똑같이 302호를 쓰니까, 최종 주소는 9동 302호(물리 주소)다!" 하고 찾아가는 완벽한 포워딩 시스템입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

페이징(Paging) vs 세그먼테이션(Segmentation)

운영체제 메모리 관리의 영원한 라이벌이자 시험 단골 문제다.

비교 항목	페이징 (Paging)	세그먼테이션 (Segmentation)
분할 방식	고정 크기 (Fixed Size), 무식하게 4KB로 깍두기 썰기	가변 크기 (Variable), 논리적 덩어리(코드, 데이터, 힙)로 의미 있게 자름
단편화 문제	❌ 내부 단편화(Internal) 발생 (4KB보다 작은 놈도 4KB를 줌)	🚨 외부 단편화(External) 발생 (남은 빈 공간 모양이 다 달라서 할당 불가)
보안 및 공유	1개 페이지에 코드와 데이터가 섞여 들어갈 수 있어 보안 권한(R/W) 주기 불편함	코드 세그먼트(Read Only), 데이터(R/W)가 완벽히 분리되어 권한 관리가 예술임
현대 OS 선택	🏆 압도적 승리 (Linux, Windows 100% 채택)	사실상 멸종. (가끔 페이징 위에 보안용으로 살짝 얹어서 쓰긴 함)

왜 페이징이 이겼을까? **"외부 단편화가 내부 단편화보다 100배 더 끔찍한 버그이기 때문"**이다. 내부 단편화는 기껏해야 박스 빈 공간(수 KB) 낭비로 끝나지만, 외부 단편화는 램이 10GB 남아도 5GB짜리 게임이 안 켜져서 서버가 뻗는 파국을 낳는다. 현대 OS는 의미 따위 개나 주고 일단 물리적으로 똑같이 썰어버리는 평등주의(페이징)를 택했다.

내부 단편화 (Internal Fragmentation)의 현실

페이징을 쓰면 프로세스의 마지막 페이지는 항상 4KB를 다 채우지 못하고 빈 공간이 남는다. 만약 페이지 크기가 4KB인데 프로세스 크기가 10KB라면?

10KB = 4KB + 4KB + 2KB.
총 3개의 페이지(12KB)를 받아야 하고, 마지막 3번째 페이지에서 2KB가 낭비된다.
현실: 요즘 서버 램이 64GB, 128GB 시대다. 프로세스 100개 띄워봤자 프로세스당 최대 4KB씩 낭비되니 총 400KB 버리는 셈이다. 이 정도 세금은 현대 하드웨어 인프라에서 완벽히 무시할 수 있다.
📢 섹션 요약 비유: 이삿짐을 쌀 때, 냉장고 모양 박스, TV 모양 박스(세그먼테이션)를 맞춤 제작하면 짐은 안전하지만 트럭에 실을 때 모양이 안 맞아 빈 공간(외부 단편화)이 생겨 짐을 다 못 싣습니다. 우체국 4호 박스(페이징)로 통일해서 다 때려 부수어 넣으면, 박스 안이 좀 비어도(내부 단편화) 트럭을 천장까지 테트리스로 꽉 채워(효율 100%) 나를 수 있습니다.

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

실무 시나리오

페이지 테이블(Page Table) 크기 오버헤드의 절망과 극복:
- 사건: 32비트 OS(4GB 주소 공간)에서 페이지 크기가 4KB라면, 프로세스 1개당 페이지 테이블 항목이 100만 개($2^{20}$) 필요하다. 이 테이블(4MB)을 메모리에 올려둬야 한다. 만약 크롬 탭(프로세스)을 100개 띄우면? 순수하게 페이지 테이블(지도) 용량으로만 램 400MB가 증발한다! 64비트 시대엔 지도가 테라바이트급이 되어 불가능해졌다.
- 아키텍트 혁명 (다단계 페이징, Hierarchical Paging): 지도를 1장으로 안 만들고 책처럼 쪼갰다. 1단계 책갈피(Page Directory)만 램에 올리고, 유저가 안 쓰는 빈 가상 메모리 공간에 대한 상세 지도는 아예 만들지조차 않는다. 이 기법 덕분에 64비트 OS에서도 페이지 테이블 용량을 수 KB 수준으로 다이어트시켜 현대 운영체제의 구원투수가 되었다.
Transparent Huge Pages (THP)의 양날의 검: 대규모 램을 쓰는 실무 백엔드(DB, Hadoop, Redis)의 핵심 튜닝 요소다.
- 원리: 4KB로 쪼개면 128GB 램에서 페이지 개수가 수천만 개가 되어 TLB 캐시 미스가 폭발한다. 리눅스는 이를 막으려고 백그라운드에서 4KB 페이지 512개를 뭉쳐서 **2MB짜리 거대 페이지(Huge Page)**로 몰래 압축(THP)해 버린다.
- 장애 발생: Redis가 데이터를 백업(BGSAVE)할 때 COW(Copy-On-Write)가 터진다. 원래 4KB만 복사하면 될 걸, THP가 켜져 있으면 2MB를 통째로 복사하느라 레이턴시가 미친 듯이 튀어 서버가 1초씩 멈춘다(Jitter).
- 실무 조치: 고성능 인메모리 DB를 돌리는 K8s 노드나 베어메탈 서버에서는 무조건 echo never > /sys/kernel/mm/transparent_hugepage/enabled 를 때려서 OS의 오지랖(THP)을 강제로 끄는 것이 첫 번째 성능 튜닝 세팅이다.

  ┌─────────────────────────────────────────────────────────────────────┐
  │     메모리 집약적(Memory-Intensive) 백엔드 서버의 페이징 튜닝 가이드│
  ├─────────────────────────────────────────────────────────────────────┤
  │                                                                     │
  │   [요구사항: 256GB RAM을 가진 Oracle / JVM 서버 운영]               │
  │                │                                                    │
  │                ▼ 운영체제 페이징 최적화 결단                        │
  │   [ 1. 일반 4KB 페이징 유지 ]                                       │
  │     ▶ 결과: 수천만 개의 페이지 발생 ─▶ TLB Miss 폭격 ─▶ CPU 낭비    │
  │                                                                     │
  │   [ 2. THP (투명한 거대 페이지 - 리눅스 디폴트) 활성화 ]            │
  │     ▶ 결과: OS가 백그라운드에서 2MB로 뭉치느라 CPU 자원 소모,       │
  │             메모리 파편화 시 단편화 정리(Defrag) 하느라 서버 멈춤.  │
  │     ▶ 판정: 🚨 DB 서버에서는 절대 악(Evil). 즉시 비활성화할 것.     │
  │                                                                     │
  │   [ 3. 명시적 Huge Pages (Explicit Huge Pages) 수동 셋팅 ]          │
  │     ▶ 방식: 부팅 시 커널 파라미터로 `hugepages=1000` 강제 할당.     │
  │     ▶ 결과: 2MB or 1GB 단위로 램을 미리 통째로 썰어둠(Swap도 안됨). │
  │     ▶ 판정: ✅ TLB Hit Rate 99% 달성, 디스크 스왑 원천 봉쇄.        │
  │             JVM이나 DB가 날아다니는 최강의 엔터프라이즈 셋팅.       │
  └─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 가상 메모리 페이징은 너무 위대해서 개발자를 바보로 만들었다. 4KB 단위의 쪼개짐이 내 애플리케이션 성능에 어떤 오버헤드를 가져오는지 잊게 만들었기 때문이다. 하드코어 인프라 아키텍트는 4KB의 족쇄를 풀고, OS에게 "내 DB는 무조건 1GB 단위(Huge Page)로 썰어서 던져줘라!"라고 커널 단위의 수동 제어(Manual Override)를 걸어 궁극의 성능을 탈환한다.

📢 섹션 요약 비유: 4KB 페이징은 모래알입니다. 100kg의 짐을 모래알로 옮기려면 숟가락으로 수만 번 퍼 날라야 합니다(TLB Miss). THP는 일꾼(OS)이 몰래 모래를 벽돌(2MB)로 뭉치는 건데, 일꾼이 지쳐서 쓰러집니다(Jitter). 명시적 Huge Page는 아예 처음부터 10kg짜리 거대 바위로 세팅해서 10번 만에 짐을 다 나르는 전문가의 건축법입니다.

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

기대효과

페이징 기법을 통해 운영체제는 외부 단편화(메모리 낭비)를 100% 근절하고, 어떤 크기의 프로그램이든 디스크의 스왑(Swap) 공간과 연계하여 램에 욱여넣을 수 있는 궁극의 다중 프로그래밍(Multiprogramming) 환경과 프로세스 간 메모리 100% 격리(Isolation)를 제공한다.

결론 및 미래 전망

페이징은 현대 컴퓨터 공학에서 단 1개의 예외도 없이 적용되는 가상 메모리의 유일무이한 황제다. 스마트폰, 윈도우 PC, K8s 클러스터 등 모든 시스템이 이 4KB 깍두기 썰기 법칙 위에서 동작한다. 미래에는 메모리 용량이 테라바이트를 넘어가면서 4KB라는 크기 자체가 너무 작다는 비판을 받고 있다. 따라서 기본 페이지 크기를 4KB에서 16KB(최신 Apple M 시리즈 칩), 64KB(ARM 아키텍처)로 점진적으로 키우는 하드웨어적 진화가 일어나고 있으며, 소프트웨어적으로는 eBPF를 통해 애플리케이션이 자신의 메모리 접근 패턴을 커널에 알려주어 OS가 페이지 프리패칭(Prefetching)을 AI처럼 동적으로 최적화하는 지능형 페이징(Intelligent Paging) 시대로 나아가고 있다.

📢 섹션 요약 비유: 4KB 페이징은 지난 40년간 인류의 물류(데이터)를 책임진 컨테이너 박스 표준 규격입니다. 하지만 화물선(RAM)이 너무 거대해져 4KB 박스로는 싣고 내리는 데 한계가 오자, 규격 자체를 16KB, 64KB의 슈퍼 컨테이너로 키워서 물류 속도를 다시 한번 퀀텀 점프시키려는 것이 미래의 컴퓨터 아키텍처입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
가상 메모리 (Virtual Memory)	페이징을 핵심 엔진으로 삼아 "내 메모리는 무한하고 연속적이다"라는 사기를 치는 전체 시스템 아키텍처다.
요구 페이징 (Demand Paging)	페이징 된 조각들을 한 번에 다 올리지 않고, CPU가 부를 때만 디스크에서 1조각씩 가져오는 찰떡궁합의 콤보다.
MMU (Memory Management Unit)	CPU 안에 박혀서 가상 페이지 번호를 물리 프레임 번호로 0.1ns 만에 엑셀(페이지 테이블) 찾듯 변환해 주는 하드웨어 칩이다.
TLB (Translation Lookaside Buffer)	페이지 테이블(RAM)에 다녀오는 시간조차 아까워서, 방금 변환한 '가상-물리' 주소 쌍을 CPU 안에 임시로 저장해 두는 초고속 캐시다.
세그먼테이션 (Segmentation)	페이징의 경쟁자였으나 끔찍한 외부 단편화를 일으키며 페이징에게 왕좌를 내어준 비운의 가변 분할 기법이다.

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

거대한 1000피스짜리 레고(프로그램)를 완성 채로 좁은 책상(RAM)에 올리려면 자리가 부족해서 아예 올릴 수가 없어요. (연속 할당의 실패)
그래서 **페이징(Paging)**이라는 마법을 써요! 완성된 레고를 똑같은 크기의 4칸짜리 블록(Page)으로 250개 다 쪼개버리는 거예요.
그리고 책상 빈 곳 여기저기에 쪼개진 블록들을 막 쑤셔 넣고, 설명서(페이지 테이블)를 보면서 "원래 1번 블록이 저기 있고 2번 블록이 저 구석에 있네" 하고 눈으로만 이어 붙여서 노는 아주 똑똑한 방법이랍니다!