719. 요구 페이징 (Demand Paging)

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

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

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

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

Ⅰ. 개요 및 필요성

개념:
- 요구 페이징 (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)가 나기 직전까지 끝까지 미루는 것이 메모리 관리 최고의 미덕입니다.

Ⅱ. 아키텍처 및 핵심 원리

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), 빛의 속도로 책(디스크)을 펴서 그 부분만 컨닝해 적어내는 완벽한 벼락치기 시스템입니다.

📌 관련 개념 맵

개념	연결 포인트
다단계 페이지 테이블 사이즈 줄이기	현재 개념으로 들어오기 전에 함께 이해하면 경계가 선명해지는 기반 개념이다.
세그멘테이션 외부 단편화 재발	현재 개념이 등장하게 만든 직접적인 선행 흐름이다.
페이지 폴트 (Page Fault) ISR	현재 개념이 구현·세분화될 때 바로 연결되는 후속 개념이다.
유효/무효 비트 (Valid/Invalid)	확장 학습이나 심화 비교로 이어지는 다음 단계의 키워드다.

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

[세그멘테이션 외부 단편화 재발]
    │
    ▼
[요구 페이징 (Demand Paging)]
    │
    ├──▶ [페이지 폴트 (Page Fault) ISR]
    └──▶ [유효/무효 비트 (Valid/Invalid)]

이 흐름도는 선행 개념에서 현재 개념으로 넘어온 뒤, 구현 세분화와 후속 확장으로 이어지는 학습 순서를 압축해 보여준다.

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

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