요구 페이징 (Demand Paging)

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

본질: 요구 페이징(Demand Paging)은 프로세스가 실행될 때 코드 전체를 램(RAM)에 올리지 않고, "CPU가 당장 지금 실행하려고 요구(Demand)하는 그 페이지(4KB)"만 하드디스크에서 램으로 가져오는 게으른(Lazy) 메모리 적재 기법이다.

메커니즘: CPU가 어떤 메모리를 읽으려 할 때 램에 없으면, MMU가 **페이지 폴트(Page Fault)**라는 하드웨어 인터럽트를 터뜨린다. OS는 잠에서 깨어나 해당 프로세스를 멈추고, 디스크에서 그 페이지를 램의 빈 프레임으로 퍼 올린 뒤 프로세스를 다시 실행시킨다.

가치: 이 기술 덕분에 8GB 램을 가진 컴퓨터에서 10GB짜리 게임을 실행할 수 있게 되었으며(가상 메모리의 완성), 부팅 속도와 프로그램 런칭 속도가 비약적으로 빨라져 현대 다중 프로그래밍 운영체제가 존재할 수 있는 근간이 되었다.

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

개념:
- 요구 페이징 (Demand Paging): 프로그램 실행 시 모든 페이지를 물리 메모리에 적재하지 않고, 오직 CPU가 접근(요청)하여 필요해진 페이지만 디스크에서 물리 메모리로 가져오는(Swap-in) 기법.
- 선페이징 (Prepaging): 요구 페이징과 반대로, 앞으로 쓸 것 같은 페이지를 미리 예측해서 램에 올려두는 기법.
필요성 (불필요한 로딩의 낭비 극복):
- 과거에는 워드 프로세서(100MB)를 켜면, 에러 처리 코드, 한 번도 안 쓰는 특수 기능 코드까지 100MB 전체를 램에 다 올릴 때까지 기다려야 했다 (Pure Swapping).
- 통계적으로 프로그램 코드의 80%는 예외 처리나 안 쓰는 기능이라 평생 실행되지 않는다. 즉, 램과 디스크 I/O를 엄청나게 낭비하고 있었다.
- 해결책: "아무것도 램에 올리지 말고 일단 실행부터 해! 그리고 CPU가 코드를 읽으려다 에러가 나면, 그때그때 필요한 조각(4KB)만 디스크에서 가져오자!"라는 궁극의 '게으름(Laziness)' 철학이 등장했다.
💡 비유:
- 기존 (전체 적재): 도서관에서 백과사전(프로그램)을 읽고 싶을 때, 백과사전 1권부터 10권(전체 코드)을 전부 대출해서 내 좁은 책상(RAM)에 억지로 다 올려놓고 1페이지만 읽는다.
- 요구 페이징: 책상(RAM)에는 아무것도 안 둔 채로 일단 자리에 앉는다. 목차를 보다가 "앗! 3권 5페이지가 필요해(Page Fault)"라고 요청(Demand)하면, 사서(OS)가 서고(디스크)에 가서 딱 '그 1장'만 복사해서 내 책상에 올려준다. 책상을 엄청나게 넓게 쓸 수 있다.
발전 과정:
1. 절대 적재: 한 번에 다 올림. 메모리 크기보다 큰 앱은 영원히 실행 불가.
2. 오버레이 (Overlay): 프로그래머가 직접 코드를 쪼개서 메모리에 넣었다 뺐다 함. (개발자 과로사)
3. 요구 페이징: 하드웨어(MMU)와 운영체제가 합작하여, 프로그래머 몰래 뒤에서 자동으로 메모리를 올렸다 뺐다 해줌. (현대 가상 메모리의 표준)
📢 섹션 요약 비유: "오늘 할 일을 내일로 미뤄라." 쓸지 안 쓸지도 모르는 데이터를 미리 램에 올리느라 고생하지 말고, 당장 에러(Page Fault)가 나기 직전까지 끝까지 미루는 것이 메모리 관리 최고의 미덕입니다.

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

Valid-Invalid 비트와 Page Fault

페이지 테이블에는 주소뿐만 아니라, 이 페이지가 현재 램(RAM)에 있는지 디스크(Swap)에 있는지를 표시하는 1비트짜리 상태 플래그가 있다.

Valid (v): 이 페이지는 현재 물리 램에 존재함. (즉각 읽기 가능)
Invalid (i): 이 페이지는 현재 하드디스크에 있거나, 아예 할당되지 않은 쓰레기 주소임.

요구 페이징 동작 파이프라인 (6단계)

CPU가 Invalid 상태의 페이지를 찔렀을 때 일어나는 거대한 폭풍이다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 Page Fault (페이지 부재) 처리 메커니즘 6단계             │
  ├───────────────────────────────────────────────────────────────────┤
  │  [ User Space ]                                                   │
  │   1. CPU가 가상 주소 `0x1000`번지의 변수를 읽으라는 명령어 실행!             │
  │                                                                   │
  │  [ Hardware (MMU) ]                                               │
  │   2. MMU가 페이지 테이블을 보니 해당 페이지가 `Invalid(i)` 상태임.        │
  │      -> MMU가 즉시 CPU에 **[ Page Fault 인터럽트 (Trap 14) ]**를 쏨!!  │
  │                                                                   │
  │  [ Kernel Space (OS) ]                                            │
  │   3. OS 진입: OS가 "이 접근이 불법(해킹)인지, 그냥 디스크에 있는 건지" 검사.  │
  │      - 불법 접근이면 -> 프로세스 Kill (Segfault)                       │
  │      - 합법이면 -> 디스크(Swap 공간)의 어디에 있는지 위치 파악.             │
  │                                                                   │
  │   4. 빈 프레임 확보: RAM에 남는 빈 프레임(Free Frame)을 하나 찾음.        │
  │      (빈칸이 없으면 Page Replacement 알고리즘으로 누군가를 쫓아냄)          │
  │                                                                   │
  │   5. Disk I/O: 디스크 컨트롤러에 "그 페이지 읽어서 아까 찾은 빈 프레임에 넣어" │
  │      라고 명령함. (이 동안 CPU는 다른 프로세스를 실행하며 놂)               │
  │                                                                   │
  │   6. 테이블 갱신 & 재시작: 디스크 읽기가 끝나면 인터럽트가 발생함.            │
  │      OS가 페이지 테이블을 `Valid(v)`로 바꾸고, 아까 1번에서 실패했던        │
  │      **그 명령어부터 다시(Restart) 실행**시킴! 이번엔 성공!               │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 요구 페이징의 핵심은 **"명령어 재시작 (Instruction Restart)"**이다. CPU는 명령어를 실행하다가 멈추고 딴짓(디스크 I/O)을 한 뒤 돌아와서, 아까 에러가 났던 바로 그 줄의 명령어를 아무 일 없었다는 듯이 다시 실행한다. 유저 프로세스 입장에서는 자기가 멈췄다(Block) 깨어난 줄도 모르고 "조금 느리게 읽혔네?" 정도로 착각하게 만드는 완벽한 기만술이다.

Ⅲ. 융합 비교 및 다각도 분석

순수 요구 페이징(Pure) vs 선페이징(Prepaging)

구분	순수 요구 페이징 (Pure Demand Paging)	선페이징 (Prepaging / Read-ahead)
적재 시점	Page Fault가 터질 때만 1개씩 적재	곧 쓸 것 같은 여러 개를 한 번에 미리 적재
장점	사용 안 할 메모리를 절대 램에 안 올림 (공간 절약)	한 번에 읽으므로 디스크 I/O 효율성(Throughput) 좋음
단점	앱 켤 때 수천 번의 Page Fault 터지며 매우 버벅댐	예측 틀리면 안 쓸 데이터를 올리느라 대역폭만 낭비됨
실제 OS	초창기 이론적 모델	현대 OS는 이 둘을 혼합하여 사용

과목 융합 관점

컴퓨터구조 (CA): 요구 페이징이 성립하려면 하드웨어 레벨에서 한 가지 엄청난 조건이 만족되어야 한다. 바로 **"명령어를 취소(Undo)하고 되돌릴 수 있는 구조"**다. x86의 REP MOVSB처럼 수만 바이트를 한 번에 복사하는 복잡한 명령어를 치다가 중간에 Page Fault가 터지면, CPU는 레지스터를 복사 전 상태로 롤백하고 Fault를 처리한 뒤 복사를 다시 이어가야 한다. 이를 지원하기 위한 CPU 파이프라인의 엄청난 하드웨어적 복잡도가 현대 칩셋 설계의 난제 중 하나다.
저장 장치 (Storage): 이 기술 때문에 **스왑 영역(Swap Space)**이라는 개념이 생겼다. 램(RAM)의 확장판 역할을 하는 하드디스크의 숨겨진 공간이다. 요구 페이징의 성능은 전적으로 이 스왑 디스크의 I/O 속도에 달려있기 때문에, 현대 서버 아키텍처에서는 스왑을 무조건 초고속 NVMe SSD로 잡거나 아예 스왑을 꺼버리는(K8s) 전략을 취한다.
📢 섹션 요약 비유: 넷플릭스 스트리밍과 같습니다. 2시간짜리 영화를 다 다운받아야 볼 수 있는 것(순수 스와핑)이 아니라, 내가 지금 보는 1초 앞의 장면만 버퍼링(요구 페이징)해서 바로 재생을 시작하는 기술입니다.

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

실무 시나리오

시나리오 — 클라우드 서버의 Major Page Fault 폭주로 인한 지연 (System Hang): Java 어플리케이션을 새로 배포하고 트래픽을 넣었더니, 첫 5분 동안 CPU iowait이 100%를 치고 응답 시간이 10초를 넘김(Warm-up 문제).
- 원인 분석: 자바 프로세스가 켜지자마자 1만 명의 유저가 몰려왔다. 코드를 램에 다 올리지 않고 켜는 요구 페이징의 특성상, 수만 개의 Major Page Fault(디스크를 읽어야 하는 끔찍한 폴트)가 1초 만에 터졌다. OS가 디스크에서 수만 장의 4KB 페이지를 하나씩 긁어오느라(Thrashing) 디스크 큐가 터진 것이다.
- 대응 (기술사적 가이드):
  - 1. Pre-warming (예열): 앱 배포 후 로드밸런서(L4)에 트래픽을 열기 전에, 가짜 트래픽(Dummy Request)을 수천 번 날려서 OS가 Page Fault를 미리 겪고 핵심 코드(Page)들을 램에 올려두도록 훈련시킨다.
  - 1. 리눅스의 mlockall() 시스템 콜을 사용하여, 애플리케이션 기동 시 자신의 모든 가상 메모리 코드를 램에 강제로 퍼올리고(Prefault) 절대 디스크로 쫓겨나지 않게(Pinning) 아키텍처를 강제한다.
시나리오 — 데이터베이스(DBMS)와 OS 요구 페이징의 충돌: MySQL(InnoDB) 서버에 64GB 램을 줬는데, OS가 자꾸 페이징(스왑)을 치면서 쿼리 속도가 100배 느려짐.
- 원인 분석: DBMS는 자기가 똑똑해서, 가장 많이 쓰는 데이터를 자기만의 캐시(Buffer Pool)에 올려두고 LRU 관리를 완벽하게 한다. 그런데 OS 입장에서는 "MySQL 네가 램을 너무 많이 먹네? 내가 좀 디스크로 쫓아낼게(Swap-out)" 하고 요구 페이징 로직을 발동시켜 버렸다. DB가 램에 있는 줄 알고 읽었는데 Page Fault가 터지면서 디스크 I/O가 발생해 속도가 박살 난 것이다 (Double Paging의 저주).
- 아키텍처 적용: DB 전용 서버에서는 절대로 OS의 요구 페이징(스와핑)을 믿으면 안 된다. 시스템의 스왑을 완전히 꺼버리거나(swapoff -a), 리눅스 커널 파라미터인 vm.swappiness=1 (또는 0)을 주어 "커널아, 제발 죽기 직전이 아니면 요구 페이징으로 메모리를 쫓아내지 말아 줘"라고 OS의 개입을 원천 차단하는 튜닝이 필수적이다.

의사결정 및 튜닝 플로우

  ┌───────────────────────────────────────────────────────────────────┐
  │                 메모리 접근 성능(Page Fault) 최적화 플로우               │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [서버 모니터링: `sar -B` 또는 `vmstat` 명령어로 페이지 폴트 지속 확인]        │
  │                │                                                  │
  │                ▼                                                  │
  │      Minor Page Fault (디스크 I/O 없이 램 내에서 매핑만 새로 함)인가?       │
  │          ├─ 예 ─────▶ [정상] 앱이 힙(Heap) 공간을 새로 할당받는 자연스러운 과정│
  │          │                                                        │
  │          └─ 아니오 (Major Page Fault : 디스크를 긁어오며 I/O Wait 폭발)  │
  │                │                                                  │
  │                ▼                                                  │
  │      Major Fault의 원인이 무엇인가?                                    │
  │          ├─ [Case 1] 램(RAM) 자체가 부족해서 쫓겨났다 다시 들어옴을 반복     │
  │          │    대책: Thrashing 상태. RAM 증설 또는 배치 프로세스 킬(Kill)  │
  │          │                                                        │
  │          └─ [Case 2] 앱 기동 시점의 자연스러운 요구 페이징 초기화 과정        │
  │               대책: 앱 시작 시 메모리를 다 채워버리는(mmap MAP_POPULATE)  │
  │                     플래그를 주어 런타임 지연(Latency Jitter)을 사전에 차단  │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "요구 페이징이 알아서 메모리를 아껴주니까 최고다"라는 것은 일반 PC에서나 통하는 얘기다. 0.001초의 멈춤도 용납하지 않는 증권사(HFT)나 고성능 게임 서버 아키텍트에게 Page Fault는 '반드시 멸종시켜야 할 악마'다. 이들은 서버를 켤 때 Page Fault를 일부러 수만 번 터뜨려서(Prefaulting) 모든 코드를 램에 못 박아두고(mlock) 서비스를 시작한다.

도입 체크리스트

Copy-On-Write (COW): 리눅스에서 fork()로 자식 프로세스를 만들면, 1GB짜리 부모 메모리를 1GB 복사하는 게 아니라 일단 "공유(Shared)"만 해둔다. 자식이 글자를 하나 수정하려고 할 때 비로소 **Page Fault(Protection Fault)**가 터지고, OS가 그때서야 4KB 페이지 딱 1장만 복사해 준다. 이 요구 페이징의 기적적인 응용 기술(COW) 덕분에 Nginx나 Redis 백그라운드 세이브가 1나노초 만에 fork()를 끝낼 수 있음을 이해하고 있는가?
📢 섹션 요약 비유: OS는 구두쇠 사장님입니다. "사무용품(메모리) 필요해요"라고 결재를 올리면 일단 "결재 완료(가상 주소 매핑)" 도장만 찍어주고 물건은 안 줍니다. 직원이 진짜로 그 볼펜을 쓰려고 서랍을 여는 순간(Page Fault), 허겁지겁 창고(디스크)로 달려가 볼펜을 사 와서 서랍에 넣어주는 극단적인 후불제 시스템입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	전체 스와핑 (Pure Swapping)	요구 페이징 (Demand Paging)	개선 효과
정량 (부팅/시작)	전체 10GB 디스크 로드 후 시작 (수 분)	요구된 4KB만 로드 후 시작 (수 밀리초)	프로그램 런칭 속도 수천 배 상승
정량 (다중화)	램 8GB면 2GB 앱 4개 띄우면 끝	각 앱의 핵심(10%)만 램에 상주	동시에 수백 개의 앱 실행 가능 (N 증가)
정성 (유연성)	프로그램 크기가 물리 램 크기에 종속됨	물리 램보다 큰 프로그램도 실행 가능	가상 메모리(Virtual Memory) 철학의 완성

미래 전망

CXL(Compute Express Link) 기반 원격 요구 페이징: 서버의 로컬 RAM과 NVMe SSD 스왑을 넘어서, 네트워크로 연결된 다른 랙(Rack) 서버의 RAM을 나의 스왑 공간처럼 빌려 쓰는 시대가 왔다. Page Fault가 터지면 로컬 디스크가 아니라 CXL 버스를 타고 수 마이크로초 안에 남의 서버 램에서 페이지를 퍼오는 원격 메모리 요구 페이징 아키텍처가 차세대 데이터센터의 표준이 될 것이다.

결론

요구 페이징(Demand Paging)은 "모든 것을 완벽하게 준비해 놓고 시작한다"는 고전적인 공학의 완벽주의를 산산조각 낸 파괴적 혁신이다. 필요할 때 닥쳐서 해결하는 '지연(Lazy)의 미학'을 시스템의 가장 깊은 곳에 심어 넣음으로써, 인류는 물리적 메모리의 한계를 속이고 무한한 동시 실행의 자유를 얻었다. 개발자가 수 기가바이트의 코드를 거침없이 짜내려 갈 수 있는 든든한 배경에는, Page Fault라는 치명적인 인터럽트를 무기 삼아 디스크와 램 사이를 1초에 수만 번씩 미친 듯이 오가는 운영체제의 눈물겨운 뒷수습이 자리하고 있다.

📢 섹션 요약 비유: 시험 전날 벼락치기하는 학생의 철학이 컴퓨터를 지배했습니다. 한 달 전부터 교과서(메모리)를 펴놓고 낭비하지 않습니다. 시험지(CPU)를 받아 들고 문제가 나오는 딱 그 순간(Page Fault), 빛의 속도로 책(디스크)을 펴서 그 부분만 컨닝해 적어내는 완벽한 벼락치기 시스템입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Page Fault (페이지 폴트)	요구 페이징의 핵심 방아쇠. CPU가 요구한 페이지가 램에 없을 때 MMU가 터뜨리는 하드웨어 인터럽트
Valid-Invalid Bit (유효-무효 비트)	페이지 테이블 안에서, 이 페이지가 현재 램에 있는지 아니면 아직 디스크(가짜)에 있는지를 OS에게 알려주는 등대
Copy-On-Write (COW)	요구 페이징의 철학(미루기)을 프로세스 복사(`fork`)에 적용하여, 데이터를 수정하기 전까지는 메모리 복사를 무한정 미루는 궁극의 최적화
Page Replacement (페이지 교체)	요구 페이징으로 램에 페이지를 계속 채우다 꽉 찼을 때, 누구를 다시 디스크로 쫓아낼지(LRU 등) 결정하는 방어 기제
Thrashing (스래싱)	요구 페이징의 부작용. 램이 꽉 차서, OS가 CPU 연산은 못하고 디스크에서 페이지를 넣고 빼는 뻘짓만 하느라 서버가 죽어버리는 현상

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

철수가 책 100권이 들어가는 '거대한 마법의 가방'을 샀어요. 그런데 사실 철수의 방(메모리)은 책 10권밖에 못 들어갈 만큼 엄청 작아요.
철수가 가방에서 책을 1권 꺼내려 할 때마다 엄마(운영체제)가 눈치채고, 0.1초 만에 지하 창고(디스크)로 달려가서 그 책을 가져와 철수 손에 몰래 쥐여준답니다! (요구 페이징)
책 100권을 방에 다 꺼내놓지 않아도, 철수는 자기가 100권을 다 가지고 있다고 착각하며 재밌게 놀 수 있어요. 필요한 것만 그때그때 가져다주는 엄마의 엄청난 달리기 실력 덕분이죠!