페이지 크기 (Page Size)

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

본질: 페이지 크기(Page Size)는 페이징 메모리 시스템에서 가상 메모리와 물리 메모리를 썰어내는 기본 단위 블록의 규격으로, 역사적으로 512바이트에서 시작해 현대에는 **4KB (4096 Bytes)**가 절대 표준으로 자리 잡았다.

가치: 페이지 크기는 시스템 아키텍처의 모든 성능을 결정짓는 핵심 변수다. 크기가 커지면 매핑 장부(페이지 테이블) 크기가 줄고 I/O 속도가 빨라지지만, 자투리로 버려지는 내부 단편화(Internal Fragmentation) 공간 낭비가 극심해진다.

융합: 범용 OS는 이 딜레마를 해결하기 위해 기본 4KB를 유지하면서도, 거대한 데이터베이스나 서버 애플리케이션을 위해 2MB 또는 1GB짜리 Huge Page(거대 페이지) 옵션을 동시에 지원하는 하이브리드 투트랙 방식을 사용한다.

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

개념: 페이징 아키텍처에서 논리 메모리를 자르는 조각을 페이지(Page), 물리 메모리를 자르는 상자를 프레임(Frame)이라 부른다. 이 둘의 크기는 반드시 동일해야 하며, 이 규격화된 크기를 '페이지 크기'라고 부른다. 항상 하드웨어 구조상 2의 승수(2^n) 크기를 갖는다.
필요성: 페이징을 발명한 공학자들은 깊은 고뇌에 빠졌다. "도대체 메모리를 얼만한 크기로 잘라야 할까?" 너무 잘게 다지면 관리가 불가능해지고, 너무 크게 썰어버리면 남는 공간 낭비가 심해진다. 메모리 낭비, 디스크 읽기 속도, 페이지 테이블이 먹는 램 용량, TLB 캐시 적중률이라는 4가지 톱니바퀴가 서로 물고 물리는 극한의 최적점을 찾아내야만 했다.
💡 비유: 페이지 크기를 정하는 것은 택배 회사의 표준 박스 크기를 결정하는 일과 같다. 박스를 너무 작게(512Byte) 만들면 지우개 하나 보낼 땐 좋지만, 컴퓨터를 보낼 땐 박스를 수천 개 포장해야 해서 분류 장부(페이지 테이블)가 터져나간다. 반대로 박스를 무조건 냉장고 크기(4MB)로 통일하면 포장과 배송(I/O)은 엄청 빠르지만, 지우개 하나 보내고 남은 빈 박스 공간(내부 단편화)에 공기만 꽉 차서 물류 창고가 순식간에 동난다.
등장 배경 및 역사적 진화:
1. 과거 (512B ~ 1KB): 초창기 램(RAM) 용량 자체가 몇 MB 수준이었기 때문에, 낭비되는 공간(내부 단편화)을 1바이트라도 줄이기 위해 페이지를 아주 잘게 다져서 썼다.
2. 현대 (4KB 표준): 램 용량이 기가바이트(GB) 시대로 넘어오면서 낭비 좀 하는 건 괜찮아졌다. 대신 페이지 테이블 장부가 너무 뚱뚱해져서 램을 다 파먹는 현상을 막고, 디스크 섹터 크기(4KB)와 규격을 통일해 I/O 성능을 극대화하기 위해 4KB로 상향 고정되었다.
3. 미래 (Huge Page 도입): 빅데이터와 AI 시대가 도래하며 4KB조차 너무 잘다는 불만이 DB 진영에서 터져 나왔다. 오라클이나 MySQL 등은 TLB 캐시 미스를 줄이기 위해 2MB, 1GB짜리 초거대 페이지를 혼용하기 시작했다.

┌───────────────────────────────────────────────────────────────────────┐
│        페이지 크기(Page Size) 결정 시의 양방향 트레이드오프           │
├───────────────────────────────────────────────────────────────────────┤
│                                                                       │
│ [ 페이지 크기를 작게 할 때 (예: 512 Byte) ]                           │
│  ➕ 장점: 프로그램 덩치에 촘촘하게 맞춰 할당. (내부 단편화 최소화)    │
│  ➖ 단점: 1GB짜리 앱을 위해 200만 개의 조각이 생김.                   │
│         페이지 테이블(장부) 크기가 폭발하여 램을 엄청나게 잡아먹음!   │
│                                                                       │
│ [ 페이지 크기를 크게 할 때 (예: 4 MB) ]                               │
│  ➕ 장점: 1GB 앱을 단 250개 조각으로 끝냄. (페이지 테이블 초소형화)   │
│         한 번에 큼직하게 디스크(Swap)로 퍼 나르니 I/O 효율 압도적.    │
│  ➖ 단점: 50KB짜리 작은 앱한테도 4MB를 떼어줘야 함.                   │
│         하나당 3.95MB의 여백이 썩어버리는 끔찍한 내부 단편화 발생!    │
└───────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 시소 게임에서 완벽한 승자는 없다. 공학자들은 수십 년간의 시뮬레이션을 통해, 프로세스의 평균적인 크기 성장세와 물리 메모리의 가격 하락 곡선을 교차시켜 **"4096 바이트 (4KB)"**라는 마법의 타협 숫자를 찾아냈고, 이는 현재 전 세계 모든 범용 x86, ARM 아키텍처의 절대 표준이 되었다.

📢 섹션 요약 비유: 약국에서 약을 처방할 때, 가루약으로 너무 잘게 갈아주면(작은 페이지) 삼키기는 좋지만 포장지(페이지 테이블)가 수백 장 낭비되고, 알약을 야구공만 하게 만들면(큰 페이지) 포장지는 한 장이면 되지만 목구멍에 걸려(내부 낭비) 고생하는 것과 같은 극단적 선택의 조율입니다.

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

1. 페이지 테이블 크기 (Page Table Size)의 압박

페이지 크기가 4KB일 때 32비트(4GB) 주소 공간을 커버하려면 어떻게 될까?

전체 페이지 개수 = 4GB / 4KB = 1,000,000 (100만 개)
장부(테이블) 1줄(엔트리)에 4바이트가 필요하다면, 페이지 테이블 하나 크기가 4MB다.
시스템에 프로세스가 100개 실행 중이면, 오직 '장부'를 놔두는 데만 400MB의 물리 램이 날아간다.
만약 페이지 크기를 1KB로 줄인다면? 페이지 테이블 크기는 4배인 1.6GB로 폭등하여 시스템 램의 절반을 장부로만 쓰게 되는 재앙이 벌어진다. 따라서 페이지 크기는 점차 커지는 쪽으로 진화 압력을 받았다.

2. 디스크 I/O (Swap Time) 와의 궁합

페이징 시스템은 램이 모자라면 페이지를 하드디스크(Swap)로 쫓아내고(Page Out), 다시 불러온다(Page In).

하드디스크는 물리적으로 원판을 돌려서 헤더를 맞추는 **탐색 시간(Seek Time)**이 데이터 전송 시간보다 훨씬 오래 걸린다.
즉, 디스크를 한 번 긁을 때 1KB를 퍼오나 4KB를 퍼오나 걸리는 시간은 사실상 똑같다.
따라서 한 번 헤더를 움직였을 때 최대한 많은 양(큰 덩어리)을 퍼오는 것이 무조건 이득이다. 이 I/O 관점에서도 페이지 크기는 큰 것이 압도적으로 유리하다. (SSD 시대가 오면서 이 갭이 줄긴 했지만, I/O 블록 사이즈 4KB는 여전히 스토리지의 국룰이다.)

┌────────────────────────────────────────────────────────────────────────────┐
│              페이지 크기 증가 추세에 대한 4가지 역학 관계                  │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│ [ ⬇ 페이지 크기를 줄이면 ]          [ ⬆ 페이지 크기를 늘리면 ]             │
│  1. 내부 단편화: 감소 (이득)           1. 내부 단편화: 증가 (손실)         │
│  2. 테이블 크기: 증가 (손실)           2. 테이블 크기: 감소 (이득)         │
│  3. 디스크 I/O: 매우 비효율적          3. 디스크 I/O: 매우 효율적          │
│  4. TLB 적중률: 감소 (자주 교체)       4. TLB 적중률: 증가 (한 번에 넓게)  │
│                                                                            │
│ ▶ 최종 결론 (역사적 방향성): 메모리(RAM) 용량이 폭발적으로 저렴해지면서,   │
│ 내부 단편화(공간 낭비)를 조금 감수하더라도 테이블 크기와 속도(I/O, TLB)를  │
│ 극대화하기 위해 페이지 크기를 계속 "키우는(Up-size)" 방향으로 진화 중.     │
└────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 컴퓨터 아키텍처의 패러다임이 '공간 절약'에서 '시간(속도) 극대화'로 넘어갔음을 보여준다. 1GB 램 시절에는 4MB가 아까웠지만, 64GB 램 시대에는 4MB 낭비는 티도 안 난다. 반면 TLB 미스(캐시 실패)로 인한 속도 지연은 CPU 클럭이 수 GHz로 빨라지면서 절대 용납할 수 없는 최악의 병목이 되었다.

📢 섹션 요약 비유: 옛날 가난할 때는 쌀 한 톨(메모리 단편화) 아끼려고 밥그릇을 아주 작게(작은 페이지) 만들었지만, 부자가 된 현대에는 밥을 좀 남겨서 버리더라도 무조건 큰 식판(큰 페이지)에 한 번에 퍼 와서 설거지 횟수(I/O 오버헤드)를 줄이는 귀족적 아키텍처로 변모한 것입니다.

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

워킹 셋 (Working Set)과 페이지 크기의 역설

페이지 크기가 무조건 크다고 좋은 것만은 아니다. 메모리 지역성(Locality) 관점에서 함정이 있다.

프로세스 A가 현재 실행 중인 핵심 코드 라인(워킹 셋)은 딱 100바이트뿐이라고 치자.
페이지가 작을 때 (1KB): 그 100바이트가 든 1KB짜리 페이지 1장만 메모리에 올려놓으면 램을 1KB만 쓰고도 쾌적하게 실행된다.
페이지가 클 때 (4MB): 그 100바이트를 실행하기 위해, 굳이 필요 없는 주변 데이터 3.99MB까지 한 덩어리로 묶여 램으로 멱살 잡혀 끌려 올라온다.
결과적으로 멀티태스킹 환경에서 불필요한 쓰레기 데이터들이 거대한 페이지 덩어리에 묻어 올라와 램을 낭비하는 현상이 발생하며, 이를 처리하기 위해 오히려 디스크 I/O 대역폭이 쓸데없이 낭비되는 패러독스(역설)가 존재한다.

하드웨어 설계 (TLB 커버리지)

TLB(고속 주소 변환 캐시)는 하드웨어 칩셋이라 용량을 늘리기 매우 비싸고 뜨겁다. 기껏해야 64개~128개의 엔트리만 기억할 수 있다.
4KB 페이지 × 64 엔트리 = TLB가 커버하는 메모리 범위는 고작 256KB다. (이 범위를 벗어나면 지옥의 지연 발생)
2MB 페이지 × 64 엔트리 = TLB가 커버하는 메모리 범위가 128MB로 뻥튀기된다!
이것이 빅데이터 서버들이 미친 듯이 Huge Page(2MB) 옵션을 켜려고 안달이 난 진짜 이유다.

┌──────────┬────────────┬────────────┬────────────────────────┐
│ 페이지 크기│ TLB 커버리지│ 내부 단편화  │ 불필요 데이터 로드│
├──────────┼────────────┼────────────┼────────────────────────┤
│ 4 KB (표준)│ 너무 좁음   │ 매우 작음   │ 거의 없음          │
│ 2 MB (거대)│ 극강의 넓이 │ 매우 큼    │ 심하게 발생         │
└──────────┴────────────┴────────────┴────────────────────────┘

[매트릭스 해설] 거대 페이지(Huge Page)는 양날의 검이다. 거대한 DB 데이터를 순차적으로 긁어모을 때 TLB 미스를 0으로 만들어주는 갓옵션이지만, 카카오톡 같은 자잘한 앱 수백 개를 띄운 데스크탑에 적용하면 빈 공간 낭비와 찌꺼기 로딩 때문에 서버가 터져버린다.

📢 섹션 요약 비유: 그물을 작게 짜서(작은 페이지) 던지면 딱 원하는 물고기만 잡히지만 그물질을 수천 번 해야 하고, 그물을 축구장만 하게 짜서(큰 페이지) 던지면 한 번에 다 잡히지만 원치 않는 쓰레기(불필요 데이터)까지 다 끌려 올라와 배가 가라앉을 수 있는 딜레마입니다.

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

실무 시나리오: Linux Transparent Huge Pages (THP)의 그림자

의도: 리눅스는 최신 서버의 성능을 높이기 위해 투명한 거대 페이지(THP)라는 기능을 만들었다. 앱이 요구하지 않아도, OS가 눈치껏 백그라운드에서 4KB 페이지들을 모아 2MB짜리 Huge Page로 합쳐주는 기능이다.
Redis / MongoDB 데이터베이스의 재앙:
- Redis 같은 인메모리(In-memory) DB는 아주 작은 단위(수 바이트)로 메모리에 읽고 쓴다.
- OS가 억지로 2MB 단위로 메모리를 묶어버리면, Redis가 데이터 1바이트를 수정하려고 할 때마다 OS는 2MB 덩어리 전체의 상태를 갱신하거나 페이지 병합 연산을 도느라 CPU를 100% 쳐버린다.
- 갑자기 서버 응답 속도가 100배 이상 느려지는 레이턴시 스파이크(Latency Spikes)가 발생한다.
실무적 해결 원칙:
- 모든 인메모리 데이터베이스 매뉴얼의 1장 1절에는 **"반드시 리눅스 OS 설정에 들어가서 THP 기능을 완전히 꺼버려라(Disable)"**라고 명시되어 있다.
- 페이지 크기는 OS가 눈치껏 키우게 내버려두면 대참사가 나며, 오직 오라클(Oracle) SGA 같은 거대 캐시 공간에만 관리자가 수동(Explicit Huge Pages)으로 켜주는 것이 실무 인프라 엔지니어링의 기본기다.

📢 섹션 요약 비유: 엄마가 방 청소 속도를 높이려고(THP) 아이의 레고 블록 수백 개를 거대한 본드 통에 한 덩어리로 붙여버렸더니(Huge Page), 아이가 블록 하나를 빼서 놀려 할 때마다(DB 접근) 덩어리 전체를 망치로 부수고 다시 붙여야 하는 대참사가 벌어지는 실무 사고입니다.

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

정량/정성 기대효과

구분	내용
메모리 보호 효율	4KB의 미세한 크기별로 Read/Write/Execute 비트를 세팅할 수 있어 정밀한 해킹 방어 시스템 구축 가능
TLB 미스율 하락	적절히 상향된 페이지 크기는 캐시 히트율을 높여 Memory Access Latency를 기계적 한계까지 낮춤
스토리지 정합성	하드디스크와 SSD의 기본 섹터/블록 I/O 사이즈(4KB)와 일치시켜 DMA 전송의 오버헤드를 제로화함

결론 및 미래 전망

페이지 크기 (Page Size)는 단순한 숫자(4096)가 아니라, 하드웨어 칩셋 설계자(MMU, TLB)와 스토리지 제조사(SSD Block), 그리고 운영체제 커널 해커들이 수십 년간 머리를 맞대고 도출해 낸 '컴퓨터 공학 최대의 대통합 규격'이다. 4KB라는 표준은 지난 30년간 IT 생태계를 지배해 왔지만, 테라바이트(TB) 램 시대가 다가오면서 이제 그 굳건한 벽에 금이 가고 있다. 미래의 ARM이나 x86 아키텍처는 기본 페이지 크기를 16KB나 64KB로 은밀하게 상향 조절하는 시도를 하고 있으며, 앱의 성격에 따라 4KB와 1GB 페이지를 다이내믹하게 섞어 쓰는(Mixed Page Size) 초정밀 하이브리드 아키텍처가 향후 운영체제의 패권을 쥘 것이다.

📢 섹션 요약 비유: 해운 물류의 속도를 폭발적으로 증가시킨 규격화된 '컨테이너 박스'의 크기(페이지 사이즈)가, 이제는 초대형 화물선을 위해 두 배, 세 배 더 거대해진 특수 컨테이너(Huge Page)와 섞여 진화하는 물류 혁명의 최전선입니다.

📌 관련 개념 맵 (Knowledge Graph)

내부 단편화 (Internal Fragmentation) | 페이지 크기가 커질수록 비례하여 폭증하는 논리적 빈 공간 낭비의 근원
페이지 테이블 (Page Table) | 페이지 크기가 작아지면 엔트리 개수가 기하급수적으로 폭발하여 메모리를 다 파먹는 거대한 번역 장부
TLB (Translation Look-aside Buffer) | 페이지 크기를 키웠을 때 가장 큰 이득(커버리지 확장)을 보는 하드웨어 주소 번역 캐시 칩셋
Huge Page (거대 페이지) | 4KB 규격을 깨고 성능 극대화를 위해 2MB, 1GB 등 통짜로 찍어내는 초대형 페이지
I/O 블록 사이즈 | 페이지 크기가 하드디스크의 4KB 입출력 규격과 정확히 일치해야 불필요한 디스크 헤드 움직임(오버헤드)이 없어짐

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

페이지 크기가 무엇인가요? 소풍 갈 때 간식을 싸가는 '락앤락 반찬통'의 정해진 크기예요.
왜 큰 통 하나에 다 안 넣나요? 아주 커다란 통(Huge Page) 하나에 사탕 3알만 넣어가면 공간이 너무 아깝잖아요(내부 단편화).
그럼 아주 작은 통 수백 개를 쓰면요? 작은 통 100개를 가방에 넣으면, 엄마가 어느 통에 무슨 간식이 들었는지 쪽지(페이지 테이블)를 100장이나 써야 해서 가방이 쪽지 구겨 넣느라 꽉 차버린답니다. 그래서 적당한 중간 크기(4KB) 통을 쓰는 거예요.