리눅스 메모리 관리를
Part 1. 이론(왜 이렇게 설계됐나) → 2. 실무(리눅스는 실제로 어떻게 동작하나) → 3. 재현 실습(직접 눈으로 확인) 순서로 정리합니다.

각 파트별로 글을 나눠 등록하겠습니다.

---

1. 이론

이 파트는 뒤(실무) 내용을 이해하기 위한 최소 개념만 압축했습니다.

1.1 왜 가상 메모리인가

가상 페이지는 RAM의 아무 프레임에나 흩어져 매핑되고, 안 쓰는 페이지는 디스크로 내려갈 수 있다.

가상 메모리는 프로세스마다 독립된 주소 공간이라는 환상을 제공하는 기술입니다.

CPU가 쓰는 가상 주소를 실제 물리 주소로 변환해주기 때문에, 각 프로세스는 "메모리를 나 혼자 연속으로 쓴다"고 착각한 채 동작할 수 있는 것입니다.

이 설계가 주는 것:

• 격리(보호): 한 프로세스가 다른 프로세스의 메모리를 넘볼 수 없음 → 안정성·보안
• 추상화: 물리 메모리가 파편적으로 흩어져 있어도, 프로세스에겐 깔끔한 연속 공간처럼 보임
• 오버커밋의 뿌리: 물리 RAM보다 큰 주소 공간을 "약속"할 수 있음.
  실제로 다 쓰기 전까진 물리 메모리를 안 채우기 때문 (→ 2장에서 다룸)

역사적으로 가상 메모리는 "물리 메모리보다 큰 프로그램을 돌리려고"(디스크를 보조 저장소로) 등장했다.
하지만 RAM이 풍부한 오늘날엔 이 역할보다 격리와 추상화가 더 본질적이다.

그리고 swap에 과도하게 의존하면 성능이 급락(thrashing)하므로 프로덕션에선 신중히 다룬다.

1.2 연속 할당과 그 한계

가상 주소를 물리 메모리에 실제로 어떻게 배치할까요?
가장 단순한 방법은 프로세스를 통째로 연속 공간에 올리는 것입니다.

연속 할당에서 메모리를 나누는 방식은 크게 둘로 나뉩니다.

• 고정 분할(fixed): 메모리를 미리 정해진 크기 칸들로 나눠 둠.
  프로세스를 아무 칸에나 넣음 → 칸이 프로세스보다 크면 남는 공간 낭비(내부 단편화)
• 가변 분할(variable): 칸을 미리 안 정하고, 프로세스가 필요한 만큼 딱 맞춰 공간을 잘라서 할당.

1.2.1 고정 분할 방식

메모리를 미리 정해진 크기의 칸(partition)으로 쪼개 둡니다. (예: 4MB짜리 칸 여러 개)

• 프로세스가 오면 빈 칸 하나에 통째로 넣음
• 내부 단편화(internal): 칸이 프로세스보다 크면 칸 안에 남는 공간이 낭비됨
• 구현은 단순하지만, 칸보다 큰 프로세스는 아예 못 올림

한계: "칸을 고정하니 크기가 안 맞아서 안에서 낭비된다”

1.2.2 가변 분할 방식

내부 단편화를 해결하기 위해 칸을 미리 안 쪼개고, 프로세스 크기에 딱 맞춰 공간을 잘라 할당합니다.

• 내부 단편화 해결 — 딱 맞게 자르니 안에서 남는 게 없음
• 외부 단편화(external) 발생: 프로세스가 들어오고 나가길 반복하면 빈 공간이 여기저기 흩어짐.
  총합은 충분한데 연속이 아니라 큰 요청을 못 받음
• 어느 hole에 넣을지 고르는 문제 → fit 알고리즘(first/best/worst)
• 대응책 압축은 프로세스를 다 옮겨야 해서 비용이 큼

한계: "안쪽 낭비는 잡았지만, 더 골치 아픈 낭비가 발생했다"

물론 고정 분할 방식도 외부 단편화가 발생할 수 있습니다.

→ 큰 프로세스가 들어갈 칸은 없는데 작은 빈 칸들이 남아도는 상황.

위 두 방식 모두 “프로세스를 연속 공간에 통째로 올린다”는 전제를 공유합니다.

이 전제 자체를 깨는 것이 바로 설명할 페이징입니다.

---

1.3 페이징

“프로세스를 통째로 연속으로 올린다"는 전제를 버린다.

페이징 기법은 가상 주소 공간을 고정 크기(보통 4KB) 조각 페이지(page)로 자릅니다.

물리 메모리도 같은 크기 조각 프레임(frame)으로 자릅니다.

자른 페이지를 아무 프레임에나 넣습니다. 즉, 연속일 필요가 없어진 거죠.

프로세스가 물리 메모리에 흩어져 있어도, 페이지와 프레임 매핑만 있으면 되니까요.

1.3.1 주소 변환

• 가상 주소 → 물리 주소 변환표가 페이지 테이블
• 프로세스마다 하나씩 있고, "내 몇 번 페이지는 물리 몇 번 프레임" 을 기록
• 매번 페이지 테이블을 메모리에서 읽으면 느리니 → TLB(Translation Lookaside Buffer) 라는 캐시로 최근 변환을 저장

1.3.2 뭘 얻었나

• 외부 단편화 원천 제거 — 흩어 놔도 되니까 "연속 공간이 없어서 못 넣는" 문제가 사라짐
• 압축같은 비싼 작업 불필요
• 내부 단편화는 남음 — 마지막 페이지가 딱 안 차면 그 안은 낭비 (근데 최대 1페이지=4KB라 훨씬 작음)

연속 할당(고정·가변)은 "연속" 때문에 단편화를 못 벗어났다.

페이징은 그 전제를 깨서 외부 단편화를 없앴다.

단, fit·단편화가 완전히 사라진 건 아닙니다.

프로세스와 물리 메모리 배치 문제에선 페이징이 해결했지만, 물리 프레임을 관리하는 더 낮은 레이어(커널 buddy allocator 등)엔 여전히 남아있습니다.

---

1.4 물리 메모리가 부족하면

지금까지는 메모리를 어떻게 나누고 매핑하는지에 대해 설명했습니다.

그런데 만약 실제 물리 메모리가 부족해지면 어떻게 될까요?

1.4.1 “애초에 다 올리지 않는다” → 요구 페이징(Demand Paging)

사실 프로세스의 모든 페이지를 처음부터 물리 메모리에 올리지는 않습니다.

실제로 접근하는 순간에만 해당 페이지를 프레임에 올리는데, 이를 요구 페이징이라고 합니다.

이 덕분에 물리 메모리보다 큰 주소를 약속해도 당장은 문제가 없는 것입니다.

1.4.2 “접근했는데 없으면?” → 페이지 폴트(Page Fault)

접근하려는 페이지가 프레임에 없으면 페이지 폴트(Page Fault)가 발생합니다.

커널이 그 페이지를 디스크에서 프레임으로 가져옵니다.

1.4.3 “근데 프레임이 꽉 찼으면?” → 페이지 교체(Page Replacement)

문제는 빈 프레임이 없을 때입니다.

이론적으로 페이지 폴트를 가장 적게 만드는 최적 알고리즘은 OPT(Optimal Page Replacement)입니다. 앞으로 가장 오랫동안 안 쓸 페이지를 골라 내보내는 방식이죠.

하지만, OPT는 미래에 어떤 페이지를 쓸지 미리 알아야 하기 때문에 현실에선 구현할 수 없습니다.

그 대신 현실에서는 과거를 미래의 근거로 삼는 LRU(Least Recently Used)가 기준이 됩니다.

"가장 오래 안 쓴 페이지는 앞으로도 안 쓸 것"이라는 시간 지역성을 가정하는 것이죠.

그런데 LRU조차 매 접근마다 순서를 기록해야 해서 비용이 큽니다.

그래서 리눅스 커널은 참조 비트를 이용한 근사 LRU로 구현합니다.

그리고 이 “페이지 교체”는 리눅스에서 reclaim이라는 이름으로 실제 동작합니다.

백그라운드로는 kswapd가, 급할 땐 할당 경로가 직접(direct reclaim) 페이지를 회수합니다.

여기서부터가 2부에서 다룰 실무의 시작입니다.

---

정택준
Team: https://nangman.cloud/ko
E-mail: taekjunnnn@gmail.com