307. 페이지 크기 (Page Size)의 트레이드오프

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

본질: 페이지 크기 (Page Size)는 가상 메모리를 어떤 입도로 잘라 물리 메모리와 연결할지 정하는 기준이며, 이 한 번의 선택이 내부 단편화, 페이지 테이블 크기, 페이지 탐색 비용을 동시에 바꾼다.

가치: 작은 페이지는 메모리를 촘촘히 쓰게 해 주고, 큰 페이지는 TLB (Translation Lookaside Buffer) 커버 범위와 페이지 워크 효율을 높여 대용량 작업의 병목을 줄인다.

판단 포인트: 정답은 "무조건 크게"도 "무조건 작게"도 아니며, 작업 집합 크기, 접근 패턴, 메모리 낭비 허용치에 따라 기본 페이지와 Huge Page를 함께 운용하는 것이 현대 운영체제의 실전 해법이다.

Ⅰ. 개요 및 필요성

페이지 크기 (Page Size)는 가상 주소 공간을 일정한 블록으로 나누는 기본 단위다. 운영체제와 MMU (Memory Management Unit) 는 이 단위를 기준으로 어떤 가상 페이지가 어떤 물리 프레임에 연결되는지 관리한다. 즉, 페이지 크기는 단순한 숫자가 아니라 주소 변환 비용과 메모리 낭비의 균형점을 정하는 설계 변수다.

이 개념이 중요해진 이유는 가상 메모리가 "연속적으로 보이는 큰 주소 공간"을 제공하는 대신, 실제 하드웨어에서는 그 공간을 수많은 조각으로 관리해야 하기 때문이다. 페이지를 너무 잘게 나누면 필요한 메모리만 딱 맞게 줄 수 있지만 관리 대상이 폭증한다. 반대로 페이지를 너무 크게 잡으면 관리 구조는 단순해지지만, 실제로 쓰지 않는 빈 공간까지 통째로 점유하게 된다.

예를 들어 4KB 페이지는 작은 객체가 많은 일반 응용 프로그램에 유리하다. 반면 수 GB 단위 버퍼를 오래 잡고 순차·반복 접근하는 데이터베이스나 가상 머신은 2MB, 1GB Huge Page에서 훨씬 적은 주소 변환 오버헤드로 동작할 수 있다. 그래서 페이지 크기는 메모리 효율과 변환 효율 사이의 고전적이면서도 여전히 중요한 절충점이다.

┌──────────────────────────────────────────────────────────────┐
│          페이지 크기가 만드는 두 방향의 압력                 │
├──────────────────────────────────────────────────────────────┤
│ 작은 페이지                                                  │
│  ├─ 장점: 빈 공간 낭비 감소                                  │
│  └─ 대가: 페이지 수 증가 → 페이지 테이블/TLB 부담 증가       │
│                                                              │
│ 큰 페이지                                                    │
│  ├─ 장점: 관리 항목 감소 → TLB reach 확대, page walk 감소    │
│  └─ 대가: 내부 단편화 증가, 세밀한 메모리 회수 어려움        │
└──────────────────────────────────────────────────────────────┘

이 그림은 페이지 크기가 "메모리 낭비"와 "주소 변환 효율"을 서로 반대 방향으로 움직인다는 점을 보여준다. 따라서 페이지 크기 논의는 저장 단위의 크기 문제가 아니라, 하드웨어와 운영체제가 어디에 비용을 지불할지 정하는 정책 문제다.

📢 섹션 요약 비유: 택배를 작은 상자에 담으면 빈 공간은 거의 없지만 상자 수가 많아 창고 관리가 복잡해진다. 큰 상자에 담으면 분류는 쉬워지지만, 상자 안의 빈칸이 많아져 창고를 낭비하게 된다.

Ⅱ. 아키텍처 및 핵심 원리

페이지 크기의 핵심은 세 가지 식으로 정리할 수 있다.

페이지 수 = 전체 주소 공간 / 페이지 크기
평균 내부 단편화 ≈ 페이지 크기 / 2
TLB Reach = TLB 엔트리 수 × 페이지 크기

즉 페이지 크기를 키우면 페이지 수는 줄고, 평균 낭비 공간은 커지며, TLB (Translation Lookaside Buffer) 가 한 번에 덮을 수 있는 주소 범위는 넓어진다. 이 셋이 동시에 움직이기 때문에 페이지 크기 선택은 항상 연쇄 효과를 만든다.

구분	4KB 페이지	2MB Huge Page	1GB Huge Page
4GB 공간을 나눌 때 페이지 수	1,048,576개	2,048개	4개
평균 내부 단편화	약 2KB	약 1MB	약 512MB
TLB 64엔트리 기준 커버 범위	256KB	128MB	64GB
관리 특성	세밀한 할당	성능 지향 절충	특수 목적 최적화

현대 x86-64 계열에서는 페이지 크기에 따라 페이지 워크 깊이도 달라진다. 4KB 페이지는 보통 최하위 페이지 테이블까지 내려가야 하지만, 2MB 페이지는 중간 단계에서 끝낼 수 있고 1GB 페이지는 그보다 더 위 단계에서 바로 매핑된다. 따라서 큰 페이지는 TLB 미스가 났을 때도 페이지 워크 비용을 줄이는 추가 이점을 갖는다.

다음 그림은 같은 TLB 용량에서 페이지 크기가 바뀔 때 커버 범위와 워크 깊이가 어떻게 달라지는지 보여준다.

┌──────────────────────────────────────────────────────────────┐
│      같은 64엔트리 TLB라도 페이지 크기에 따라 체감이 달라짐    │
├──────────────────────────────────────────────────────────────┤
│ 4KB  페이지: 64 × 4KB  = 256KB   ─▶ 세밀하지만 자주 미스       │
│ 2MB  페이지: 64 × 2MB  = 128MB   ─▶ 대용량 버퍼에 유리         │
│ 1GB  페이지: 64 × 1GB  = 64GB    ─▶ 매우 큰 연속 영역에 유리   │
│                                                              │
│ page walk depth 예시                                         │
│ 4KB  ─▶ PML4 ─▶ PDPT ─▶ PD ─▶ PT ─▶ Frame                    │
│ 2MB  ─▶ PML4 ─▶ PDPT ─▶ PD =====▶ Frame                      │
│ 1GB  ─▶ PML4 ─▶ PDPT =========▶ Frame                        │
└──────────────────────────────────────────────────────────────┘

이 다이어그램의 포인트는 "큰 페이지는 TLB miss를 줄이는 것"에서 끝나지 않는다는 점이다. 페이지 테이블 단계 자체를 덜 거치므로 미스가 났을 때의 벌점도 작아질 수 있다. 대신 이득이 큰 만큼 물리 메모리를 연속적으로 확보해야 하고, 사용량 변화가 잦은 워크로드에서는 낭비가 커질 수 있다.

📢 섹션 요약 비유: 도시 지도를 낱장 메모로 잘게 쪼개면 원하는 골목은 정확히 찾을 수 있지만 메모 묶음이 너무 두꺼워진다. 큰 구역 지도로 묶으면 찾는 책자는 얇아지지만, 실제로는 안 가는 지역까지 한꺼번에 들고 다니게 된다.

Ⅲ. 비교 및 연결

페이지 크기를 제대로 이해하려면 "메모리 효율"과 "주소 변환 효율"의 경계 비교를 동시에 봐야 한다. 작은 페이지는 희소한 주소 공간, 잦은 할당/해제, 다양한 크기의 객체가 섞인 환경에서 강하다. 큰 페이지는 넓은 영역을 오래 유지하고 반복적으로 접근하는 환경에서 강하다.

비교 축	작은 페이지 (예: 4KB)	큰 페이지 (예: 2MB, 1GB)
메모리 낭비	적음	큼
페이지 테이블 크기	큼	작음
TLB 미스 가능성	높음	낮음
페이지 폴트 단위	작아서 세밀함	커서 한 번에 많이 적재
복사-쓰기 (Copy-on-Write) 유연성	높음	낮음
적합 워크로드	일반 앱, 희소 접근	DB, 분석, VM, HPC

운영체제는 이 차이를 그대로 정책에 반영한다. 리눅스의 THP (Transparent Huge Pages) 는 연속적이고 자주 접근되는 영역을 2MB 단위로 승격해 TLB 부담을 줄이고, 다시 조각내야 유리한 상황에서는 분할할 수 있다. 반면 메모리 맵 파일, 복사-쓰기, 페이지 교체 같은 메커니즘은 작은 페이지일수록 세밀하게 작동하므로, 모든 영역을 무조건 Huge Page로 바꾸는 것은 오히려 전체 시스템 민첩성을 떨어뜨릴 수 있다.

또한 페이지 크기는 입출력과도 연결된다. 큰 페이지는 페이지 폴트 한 번에 더 많은 데이터를 가져오므로 순차 접근에서는 유리하지만, 실제로 필요한 데이터가 페이지 일부뿐이면 캐시 오염과 불필요한 I/O를 키울 수 있다. 결국 페이지 크기는 CPU의 주소 변환 계층, 운영체제의 메모리 정책, 저장장치의 전송 단위까지 함께 엮는 시스템 통합 변수다.

📢 섹션 요약 비유: 작은 접시는 반찬을 딱 먹을 만큼만 담아 낭비가 적다. 큰 쟁반은 한 번에 많이 나를 수 있어 편하지만, 조금만 먹어도 식탁 자리를 크게 차지한다.

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

실무에서는 "어떤 페이지 크기가 더 좋은가?"보다 "어떤 메모리 구간에 어떤 페이지 크기를 써야 하는가?"가 더 정확한 질문이다. 예를 들어 데이터베이스 버퍼 캐시, 인메모리 분석 엔진, 하이퍼바이저의 게스트 메모리처럼 큰 배열을 오래 유지하는 경우에는 Huge Page가 높은 확률로 이득을 준다. 반대로 짧게 생성되고 자주 사라지는 작은 객체 중심 애플리케이션은 4KB 페이지가 낭비를 줄이고 회수도 쉽다.

실무 체크리스트

작업 집합(Working Set)이 충분히 크고 연속적인가?
TLB reach가 병목이라면 Huge Page의 효과가 크다.
메모리 낭비를 감당할 수 있는가?
2MB 페이지는 평균 1MB, 1GB 페이지는 평균 512MB 정도의 내부 단편화를 감수할 수 있어야 한다.
복사-쓰기와 메모리 압축, 세밀한 회수가 중요한가?
중요하다면 기본 페이지가 유리하다.
운영체제가 자동 승격(예: THP)할지, 명시적 Huge Page를 쓸지 정했는가?
지연시간 예측 가능성이 중요하면 명시적 관리가 더 낫다.

대표 적용 예시

데이터베이스: 대형 버퍼 풀에서 TLB miss를 줄이기 위해 Huge Page를 적극 활용한다.
가상화 환경: 게스트 OS 메모리가 커질수록 호스트와 게스트 모두에서 주소 변환 비용이 누적되므로 큰 페이지의 효과가 커진다.
일반 웹 애플리케이션: 프로세스가 작고 메모리 배치가 자주 바뀌면 4KB 기본 페이지가 더 안정적이다.

안티패턴

"서버니까 무조건 Huge Page"처럼 워크로드 분석 없이 일괄 적용하는 것
메모리 여유가 부족한 환경에서 큰 페이지를 강제해 낭비와 할당 실패를 동시에 키우는 것
페이지 크기 효과를 보지도 않고 CPU 사용률만 보고 성능 문제를 판단하는 것

기술사 관점에서는 페이지 크기를 정적 규격이 아니라 계층별 최적화 레버로 설명해야 한다. 즉, 작은 페이지는 세밀한 자원 관리에, 큰 페이지는 변환 오버헤드 절감에 강하며, 현대 운영체제는 둘을 혼합해 전체 시스템 목적함수를 맞춘다고 정리하면 된다.

📢 섹션 요약 비유: 이삿짐이 책 몇 권이면 작은 상자가 맞고, 창고 전체를 옮기면 지게차 팔레트가 맞다. 중요한 것은 상자의 우열이 아니라 짐의 성격에 맞는 포장 단위를 고르는 일이다.

Ⅴ. 기대효과 및 결론

적절한 페이지 크기 전략을 쓰면 같은 물리 메모리에서도 체감 성능이 크게 달라진다. 작은 페이지는 메모리 이용률을 높이고 세밀한 보호·회수·공유를 가능하게 한다. 큰 페이지는 TLB miss와 page walk 비용을 줄여 대용량 워크로드의 CPU 낭비를 줄인다.

다만 큰 페이지가 항상 우월한 것은 아니다. 내부 단편화가 커지고, 세밀한 페이지 교체나 복사-쓰기 최적화가 어렵고, 연속 물리 메모리 확보 실패가 문제가 될 수 있다. 따라서 "성능 향상"이라는 결과만 보지 말고 그 뒤에 숨은 메모리 유연성 손실까지 함께 판단해야 한다.

결론적으로 페이지 크기는 메모리 시스템의 확대경 배율과 같다. 4KB는 세밀한 관찰과 정교한 관리에, 2MB·1GB는 넓은 장면을 빠르게 훑는 데 유리하다. 현대 시스템이 기본 페이지와 Huge Page를 함께 쓰는 이유도 바로 이 두 시야를 상황별로 바꿔 써야 하기 때문이다.

📢 섹션 요약 비유: 현미경과 망원경은 누가 더 좋은 도구가 아니라, 보는 대상이 다를 뿐이다. 페이지 크기도 마찬가지로 문제의 크기에 맞는 렌즈를 고를 때 가장 큰 효과가 난다.

📌 관련 개념 맵

개념	연결 포인트
페이지 테이블 (Page Table)	페이지 수가 늘수록 엔트리 수와 메모리 오버헤드가 커진다.
TLB (Translation Lookaside Buffer)	페이지 크기가 클수록 동일 엔트리 수로 더 넓은 주소 범위를 커버한다.
내부 단편화 (Internal Fragmentation)	페이지 크기가 커질수록 평균 낭비 공간이 증가한다.
THP (Transparent Huge Pages)	운영체제가 큰 페이지를 자동 승격·분할하며 절충점을 찾는 기법이다.
페이지 폴트 (Page Fault)	페이지 크기는 한 번의 폴트로 읽어오는 데이터 양과 I/O 성격을 바꾼다.
메모리 맵 파일 (Memory-Mapped File)	큰 연속 파일 매핑에서는 Huge Page가 주소 변환 오버헤드를 줄일 수 있다.

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

고정 크기 페이지 분할
    │
    ▼
페이지 테이블 (Page Table) · 내부 단편화 (Internal Fragmentation)
    │
    ▼
TLB (Translation Lookaside Buffer) · page walk 비용
    │
    ▼
Huge Page (2MB, 1GB) · TLB reach 확대
    │
    ▼
THP (Transparent Huge Pages) · 혼합 페이지 크기 정책
    │
    ▼
워크로드 인지형 메모리 최적화

이 흐름은 "단순 분할 단위"였던 페이지 크기가, 점차 주소 변환 성능과 운영체제 정책을 함께 좌우하는 최적화 레버로 발전해 온 과정을 보여준다.

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

페이지 크기는 장난감을 담는 상자의 크기를 정하는 규칙이에요.
작은 상자는 낭비가 적지만 상자가 너무 많아 찾기 힘들고, 큰 상자는 찾기 쉽지만 빈칸이 많이 남아요.
그래서 컴퓨터는 작은 상자와 큰 상자를 상황에 따라 섞어서 쓰는 거예요.