286. 페이지 (Page)와 프레임 (Frame)

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

본질: 페이지 (Page)는 프로세스가 보는 가상 메모리 조각이고, 프레임 (Frame)은 운영체제가 관리하는 물리 메모리 조각이며, 둘은 같은 크기여야만 빠른 주소 변환이 가능하다.

가치: 같은 크기 규격 덕분에 어떤 페이지도 어떤 빈 프레임에 적재할 수 있어 외부 단편화 (External Fragmentation)를 없애고, 비연속 물리 메모리를 연속 가상 공간처럼 보이게 만든다.

판단 포인트: 페이지/프레임 구조는 단순한 저장 단위가 아니라 페이지 크기, 변환 비용, TLB (Translation Lookaside Buffer) 효율, 내부 단편화 (Internal Fragmentation) 사이의 균형 문제다.

Ⅰ. 개요 및 필요성

페이지 (Page)와 프레임 (Frame)은 가상 메모리 시스템이 주소 공간을 고정 크기 블록으로 나누어 관리하는 최소 단위다. 페이지는 프로세스 관점의 논리적 조각이고, 프레임은 RAM (Random Access Memory) 관점의 물리적 빈칸이다. 운영체제는 이 둘의 크기를 일치시켜, 프로그램이 요구한 메모리를 반드시 연속된 물리 주소로 배치하지 않아도 되게 만든다.

이 구조가 필요한 이유는 연속 메모리 할당이 커질수록 외부 단편화와 재배치 비용이 커지기 때문이다. 큰 프로세스를 올리려면 중간중간 비어 있는 작은 공간들을 합쳐야 했고, 이를 위해 프로세스를 통째로 옮기는 압축 (Compaction) 비용이 발생했다. 페이지와 프레임을 같은 규격으로 고정하면 운영체제는 "빈칸 하나에 조각 하나"라는 단순 규칙만 지키면 되므로, 메모리 관리가 훨씬 예측 가능해진다.

아래 그림은 왜 페이지와 프레임의 동일 크기가 핵심인지 보여준다. 운영체제는 전체 프로그램을 한 덩어리로 적재하지 않고, 페이지별로 흩어진 프레임에 배치한 뒤 페이지 테이블 (Page Table)로만 연결한다.

┌──────────────────────────────────────────────────────────────────────┐
│        Same-sized blocks make noncontiguous allocation work         │
├───────────────────────────────┬──────────────────────────────────────┤
│ Virtual Memory                │ Physical Memory                      │
│                               │                                      │
│ Page 0  ────────────────────▶ │ Frame 12                             │
│ Page 1  ────────────────────▶ │ Frame 03                             │
│ Page 2  ────────────────────▶ │ Frame 19                             │
│ Page 3  ────────────────────▶ │ Frame 07                             │
│                               │                                      │
│ rule: page size = frame size  │ result: any free frame can be used   │
└───────────────────────────────┴──────────────────────────────────────┘

핵심은 페이지가 "데이터의 의미 단위"가 아니라 "옮기기 쉬운 규격 단위"라는 점이다. 프레임도 마찬가지로 실제 RAM의 내용을 설명하는 개념이 아니라, 운영체제가 할당·회수·교체하기 위한 관리 단위다. 따라서 페이지와 프레임을 이해하면 뒤이어 나오는 페이지 테이블, 페이지 부재, 교체 알고리즘의 논리가 자연스럽게 이어진다.

📢 섹션 요약 비유: 페이지는 이삿짐 상자이고 프레임은 창고 칸이다. 상자와 칸의 크기가 같아야 아무 칸에나 넣어도 딱 맞고, 창고 전체를 다시 정리하지 않아도 된다.

Ⅱ. 아키텍처 및 핵심 원리

페이지/프레임 구조의 핵심 원리는 주소를 번호 + 내부 위치로 분해하는 데 있다. 가상 주소는 페이지 번호 + 오프셋 (Offset)으로 나뉘고, 물리 주소는 프레임 번호 + 오프셋으로 바뀐다. 이때 페이지와 프레임의 크기가 같기 때문에 오프셋은 변하지 않고, MMU (Memory Management Unit)는 페이지 번호만 프레임 번호로 치환하면 된다.

예를 들어 페이지 크기가 4KB라면 하위 12비트는 오프셋이고, 상위 비트는 페이지 번호다. 프로세스가 가상 주소 VPN 5, offset 100을 접근하면 MMU는 페이지 테이블에서 VPN 5 -> PFN 9를 찾고, 최종 물리 주소를 PFN 9, offset 100으로 조립한다. 즉 변환 비용은 "블록 내부 위치를 다시 계산하는 것"이 아니라 "어느 프레임에 있는지만 찾는 것"으로 단순화된다.

구성 요소	역할	설계상 의미
페이지 (Page)	가상 주소 공간의 고정 크기 블록	프로세스별로 독립적 의미를 가짐
프레임 (Frame)	물리 메모리의 고정 크기 블록	시스템 전체가 공유하는 실제 저장 공간
오프셋 (Offset)	블록 내부의 상대 위치	페이지와 프레임에서 동일하게 유지
페이지 테이블 엔트리 (Page Table Entry, PTE)	페이지→프레임 매핑 정보	유효 비트, 보호 비트, dirty 비트 등을 함께 보관
TLB (Translation Lookaside Buffer)	최근 매핑의 캐시	주소 변환 지연을 줄이는 핵심 장치

아래 그림은 주소 변환에서 페이지와 프레임이 어떻게 맞물리는지 보여준다.

┌──────────────────────────────────────────────────────────────────────┐
│                 Address translation with equal-size blocks           │
├──────────────────────────────────────────────────────────────────────┤
│ Virtual Address                                                      │
│ ┌───────────────────────┬──────────────────────────────────────────┐ │
│ │   VPN (page number)   │          Offset within page             │ │
│ └───────────────────────┴──────────────────────────────────────────┘ │
│              │                                                       │
│              ▼                                                       │
│        Page Table / TLB lookup                                       │
│              │  replace VPN with PFN                                 │
│              ▼                                                       │
│ Physical Address                                                     │
│ ┌───────────────────────┬──────────────────────────────────────────┐ │
│ │   PFN (frame number)  │         Same offset as above            │ │
│ └───────────────────────┴──────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘

이 구조는 왜 빠른가를 이해해야 한다. 페이지 크기와 프레임 크기가 다르면 블록 내부 위치까지 다시 계산하거나 데이터를 쪼개어 적재해야 하므로 매핑이 복잡해진다. 하지만 크기가 같으면 변환은 단순 인덱스 교체가 되고, 하드웨어는 이를 TLB 캐시와 결합해 거의 한 번의 테이블 조회처럼 처리한다.

동시에 이 구조는 한계를 남긴다. 블록이 고정 크기이므로 마지막 페이지는 덜 찬 채 프레임 하나를 점유할 수 있고, 이것이 내부 단편화다. 그래서 페이지/프레임 구조는 외부 단편화를 없애는 대신, 페이지 크기 선택에 따라 내부 단편화와 변환 오버헤드를 조절하는 설계가 된다.

📢 섹션 요약 비유: 페이지와 프레임은 똑같은 칸 수를 가진 책장 번호표와 실제 책장 칸이다. 어느 칸에 꽂혀 있는지만 찾으면 되고, 책 안의 몇 번째 줄인지는 그대로 유지된다.

Ⅲ. 비교 및 연결

페이지와 프레임은 짝을 이루는 개념이지만 역할은 다르다. 페이지는 프로세스별 가상 공간에 속하므로 같은 페이지 번호라도 프로세스마다 의미가 다를 수 있다. 반면 프레임은 시스템 전체의 실제 RAM 자원이므로, 운영체제는 빈 프레임 리스트와 교체 정책을 통해 전역적으로 관리한다.

비교 축	페이지 (Page)	프레임 (Frame)	세그먼트 (Segment)와의 대비
소속	가상 메모리	물리 메모리	세그먼트는 의미 단위, 크기가 가변적
기준	프로세스 관점	운영체제 관점	세그먼트는 코드/데이터/스택처럼 논리 구조 중심
크기	고정	고정	세그먼트는 가변 크기라 외부 단편화 가능
주소 변환	페이지 번호를 프레임 번호로 치환	실제 적재 위치 제공	세그먼트는 base+limit 계산이 핵심
대표 문제	내부 단편화	프레임 부족, 교체 비용	외부 단편화, 압축 필요

이 비교에서 중요한 경계는 "페이지와 프레임은 왜 둘 다 필요하냐"는 질문이다. 페이지만 있으면 프로그램이 보는 논리 단위는 설명되지만 실제 RAM 어디에 들어가는지 알 수 없다. 프레임만 있으면 물리 메모리 칸은 설명되지만, 각 프로세스에 독립적인 큰 주소 공간을 제공할 수 없다. 둘을 나누어야만 가상 주소의 독립성과 물리 메모리의 공유를 동시에 달성할 수 있다.

또한 이 개념은 뒤 주제와 강하게 연결된다. 페이지 테이블은 페이지를 프레임에 연결하는 지도이고, 페이지 부재 (Page Fault)는 필요한 페이지에 대응하는 프레임이 RAM에 없을 때 발생한다. 내부 단편화는 페이지 크기에서 비롯되는 부산물이며, Huge Page는 이 구조를 유지한 채 페이지/프레임 크기 자체를 키워 TLB 효율을 높이는 확장 전략이다.

📢 섹션 요약 비유: 페이지는 손님에게 나눠 준 보관함 번호표이고 프레임은 실제 사물함 칸이다. 번호표와 실제 칸을 분리해 두어야 손님은 자기 번호만 기억하면 되고, 관리자는 전체 사물함을 효율적으로 돌릴 수 있다.

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

실무에서는 페이지/프레임을 단순 정의로 묻기보다, "어떤 페이지 크기가 이 워크로드에 맞는가"를 판단하는 문제로 나온다. 기본 4KB 페이지는 내부 단편화를 줄이고 세밀한 보호에 유리하지만, 메모리 접근 범위가 큰 데이터베이스나 가상화 환경에서는 TLB 미스가 늘어날 수 있다. 이때 Huge Page를 쓰면 한 번의 매핑으로 더 넓은 메모리 범위를 덮을 수 있어 변환 오버헤드는 줄지만, 작은 객체가 많은 워크로드에서는 낭비 공간이 커질 수 있다.

운영체제 관점에서는 빈 프레임 확보와 회수 정책도 중요하다. 프레임이 충분하면 페이지는 자유롭게 적재되지만, 프레임이 부족하면 어떤 페이지를 내보낼지 결정해야 하므로 교체 알고리즘과 디스크 입출력 비용이 성능을 좌우한다. 즉 페이지/프레임 구조는 메모리 관리의 출발점이지만, 실제 체감 성능은 TLB, 페이지 테이블 깊이, 프레임 압박, 페이지 부재율이 함께 결정한다.

실무 판단 체크리스트

메모리 접근 패턴이 넓고 반복적인가, 아니면 작고 산발적인가?
TLB 미스로 인한 지연이 병목인가, 아니면 RAM 자체 부족이 병목인가?
Huge Page 적용 시 내부 단편화 증가를 감수할 만큼 이득이 큰가?
가상화 환경이라면 2단계 주소 변환으로 인한 오버헤드를 줄일 장치가 있는가?

대표 안티패턴

페이지 크기 선택을 애플리케이션 특성 없이 일괄 적용하는 경우
프레임 부족 상황을 캐시 문제로 오해해 불필요한 튜닝만 반복하는 경우
페이지/프레임 구조를 무시하고 "메모리는 연속으로 있어야 빠르다"고 단정하는 경우

기술사 답안에서는 "페이지는 논리 단위, 프레임은 물리 단위, 동일 크기, 오프셋 공유, 외부 단편화 제거, 내부 단편화 잔존"까지를 하나의 흐름으로 묶어 설명하면 좋다. 여기에 TLB, Huge Page, 페이지 부재를 연결하면 단순 정의를 넘어 설계 판단까지 보여줄 수 있다.

📢 섹션 요약 비유: 작은 상자는 공간 낭비가 적지만 재고 관리가 많고, 큰 상자는 관리가 쉽지만 빈칸이 늘어난다. 창고 운영자는 물건 종류를 보고 상자 규격을 정해야 한다.

Ⅴ. 기대효과 및 결론

페이지/프레임 구조의 가장 큰 효과는 메모리 관리를 "연속 공간 확보" 문제에서 "규격 블록 배치" 문제로 바꿨다는 점이다. 그 결과 프로세스는 자신만의 큰 연속 주소 공간을 가진 것처럼 동작하고, 운영체제는 실제로는 흩어진 프레임들을 조합해 이를 제공할 수 있다. 이는 멀티프로그래밍, 보호 기법, 스와핑, 요구 페이징 같은 현대 운영체제 기능의 기반이 된다.

하지만 만능은 아니다. 페이지 테이블 메모리 사용량, TLB 미스, 내부 단편화, 페이지 부재 시 디스크 지연은 여전히 비용으로 남는다. 그래서 현대 시스템은 다단계 페이지 테이블, Huge Page, EPT (Extended Page Table)·NPT (Nested Page Table) 같은 하드웨어 지원으로 이 비용을 줄이는 방향으로 진화해 왔다.

결국 페이지와 프레임은 "같은 크기의 두 단위"라는 단순한 규칙으로 복잡한 메모리 문제를 다루는 설계다. 이 개념은 주소 변환의 출발점이자, 가상 메모리를 이해할 때 반드시 붙잡아야 할 기준 좌표로 기억하는 것이 맞다.

📢 섹션 요약 비유: 복잡한 창고도 모든 박스와 칸의 규격만 통일하면 훨씬 쉽게 운영된다. 페이지와 프레임은 메모리 세계에서 그 규격 통일을 담당하는 약속이다.

📌 관련 개념 맵

개념	연결 포인트
페이징 (Paging)	페이지와 프레임을 고정 크기로 대응시키는 전체 관리 방식
MMU (Memory Management Unit)	페이지 번호를 프레임 번호로 변환하는 하드웨어
페이지 테이블 (Page Table)	페이지→프레임 매핑과 보호 정보를 저장하는 구조
내부 단편화 (Internal Fragmentation)	고정 크기 페이지/프레임 구조의 대표 부작용
TLB (Translation Lookaside Buffer)	자주 쓰는 페이지→프레임 매핑을 캐시해 주소 변환을 가속
페이지 부재 (Page Fault)	필요한 페이지에 대응하는 프레임이 메모리에 없을 때 발생
Huge Page	페이지/프레임 크기를 키워 TLB 효율을 높이는 확장 방식

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

연속 메모리 할당
    │
    ▼
외부 단편화 (External Fragmentation) 문제
    │
    ▼
페이징 (Paging)
    │
    ├── 페이지 (Page): 가상 메모리 조각
    │
    └── 프레임 (Frame): 물리 메모리 조각
             │
             ▼
페이지 테이블 (Page Table) · MMU (Memory Management Unit)
             │
             ▼
TLB (Translation Lookaside Buffer) · Huge Page
             │
             ▼
페이지 부재 (Page Fault) · 교체 알고리즘 (Replacement Policy)

이 흐름은 "단편화 해결 → 고정 크기 매핑 → 주소 변환 가속 → 부족 시 교체"로 이어지는 가상 메모리의 사고 흐름을 보여준다.

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

페이지는 책을 똑같은 크기의 카드로 잘라 놓은 것이고, 프레임은 그 카드가 들어가는 서랍 칸이에요.
카드와 서랍 칸의 크기가 같아서 어느 칸에 넣어도 잘 들어가요.
그래서 컴퓨터는 책 전체를 한곳에 두지 않아도, 필요한 카드만 꺼내서 똑똑하게 정리할 수 있어요.