가상 메모리 (Virtual Memory), MMU, SWAP

1. 가상메모리 

우리가 한글(hwp)도 켜고, 유튜브도 보고, 게임도 합니다. 그런데 각 프로그램 입장에서 메모리를 들여다보면 재미있는 현상이 보입니다.

• 모든 프로그램은 자신이 메모리 0번지부터 끝번지까지를 혼자 독점하고 있다고 착각합니다.
• 자신이 쓰는 메모리 공간이 아주 매끄럽고 연속적이라고 생각합니다.

하지만 실제 물리 메모리(RAM)의 상황은 다릅니다. 여러 프로그램의 데이터가 이곳저곳에 조각조각 흩어져 있고, 남은 공간도 별로 없죠.

2. 매트릭스의 설계자: MMU

지난 시간에 보신 그림에 있던 MMU(Memory Management Unit)가 바로 이 '사기극'의 주동자입니다.

• CPU: "가상 주소 100번지 데이터 내놔." (속음)
• MMU: (재빠르게 변환표를 확인하며) "아, 100번지는 실제로는 RAM 구석탱이 5500번지에 박혀있네." → 5500번지에서 가져옴.
• 결과: 프로그램은 자기 데이터가 물리적으로 어디에 있는지 전혀 모릅니다.

"물리적 방(RAM)이 꽉 차면, 안 쓰는 짐을 창고(SSD)로 잠깐 빼둔다." 이것이 가상 메모리 시스템이 굴러가는 핵심 비결이며,

이때 SSD에 잡히는 그 공간을 스왑(Swap) 영역이라고 부릅니다.

 

2-1. MMU의 주소 변환 로직 (VPN, PPN, Offset)

MMU가 가상 주소를 물리 주소로 바꾸는 건 복잡한 수학 공식을 쓰는 게 아닙니다.표(Table)를 보고 베껴 적는방식입니다.

 

주소의 구조 (32bit 예시)

가상 주소(Virtual Address)는 통짜 숫자가 아니라, 비트 단위로 쪼개져 있습니다.

• VPN (Virtual Page Number): "몇 번째 페이지냐?" (상위 20bit)
• Offset: "그 페이지 안에서 몇 번째 줄이냐?" (하위 12bit)

변환 알고리즘 (Table Lookup)

1. 자르기: CPU가 "가상 주소 0x12345678 내놔!" 하면, MMU는 이걸 두 동강 냅니다.
   • VPN: 0x12345
   • Offset: 0x678 / 여기서 Offset은 보통 하위 12비트로 잡는다고 한다.(페이지크기를 4kB로 정했기 때문)
2. 찾기 (Lookup): 메모리(RAM)에 있는 **페이지 테이블(Page Table)**로 갑니다. 이 테이블은 배열(Array)과 똑같습니다. PageTable[0x12345]를 조회합니다.
3. 읽기: 그 칸에 적혀 있는 **PPN (Physical Page Number)**을 읽습니다.
   • 예: "가상 페이지 0x12345는 실제로는 0x99999 번지에 있다."
4. 합치기: 찾아낸 PPN(0x99999) 뒤에 아까 떼어놨던 Offset(0x678)을 그대로 갖다 붙입니다.
   • 최종 물리 주소: 0x99999678

핵심: Offset(페이지 내부 위치)은 변하지 않습니다. 책꽂이 위치(Page Number)만 바뀔 뿐입니다.

---

3. 스왑(Swap): RAM인 척하는 SSD

운영체제는 SSD의 일부분(예: 4GB 정도)을 뚝 떼어서 "여기는 이제부터 비상용 RAM이다"라고 선언합니다.

• Swap Out (짐 빼기): RAM이 꽉 찼는데 새로운 데이터를 넣어야 한다면? OS는 RAM에 있는 데이터 중 "가장 오랫동안 안 건드린 녀석(Least Recently Used)"을 골라내서 SSD의 스왑 영역으로 쫓아냅니다.
• Swap In (다시 부르기): 사용자가 아까 쫓겨난 그 프로그램(예: 최소화해둔 유튜브)을 다시 클릭하면? OS는 부랴부랴 SSD에서 그 데이터를 읽어 다시 RAM으로 가져옵니다.

3-1. SSD가 Swap 메모리로 동작할 수 있는 이유

RAM이나 SSD나 전자를 가두는 원리(데이터를 0과 1로 구분)는 비슷합니다.

하지만 "연결된 도로(Bus)"와 "접근 단위"가 다릅니다.

1. 연결 방식의 차이 (접근성)
   • RAM: CPU의 메모리 컨트롤러와 병렬 버스로 직결되어 있습니다. CPU가 "몇 번지!" 하면 즉시 전기 신호로 찌를 수 있습니다. (Byte Addressable)
   • SSD: PCIe 버스 → NVMe 컨트롤러를 거쳐야 합니다. CPU가 직접 주소를 찌르는 게 아니라, **"명령어 패킷"**을 만들어서 보내야 합니다. CPU 입장에서는 직접 대화가 불가능한 '외부 장치(I/O Device)'일 뿐입니다.
2. 동작 로직
   • Swap은 SSD가 RAM처럼 동작하는 게 아니라, OS가 RAM에 있는 데이터를 SSD로 '복사(I/O)'해두는 것입니다.
   • CPU가 Swap 영역의 데이터를 요청하면?
     • Page Fault 발생: MMU가 "어? 이거 지금 RAM에 없고 SSD(Swap)에 있는데요?"라고 CPU에 인터럽트를 겁니다.
     • OS 출동: OS가 하던 일을 멈추고 SSD에 가서 해당 데이터를 읽어와서 다시 RAM의 빈 공간에 채워 넣습니다.
     • 재실행: 데이터가 RAM에 들어왔으니, CPU는 이제서야 읽을 수 있습니다.

결론: SSD가 RAM 역할을 대신하는 게 아니라, RAM의 내용물을 잠시 보관해두는 창고 역할을 할 뿐입니다. 실행(Execution)은 무조건 RAM 위에서만 일어납니다.

3-2. 윈도우 스왑 설정 & 용량 제한의 이유(참고)

윈도우 설정 과정 (pagefile.sys) 예시

사용자가 윈도우에서 "가상 메모리 10GB 설정"을 누르면 벌어지는 일:

1. 파일 생성: OS는 C드라이브(SSD)에 pagefile.sys라는 10GB짜리 거대한 파일을 만듭니다.
2. 공간 예약: SSD 컨트롤러에게 "이 파일이 차지하는 LBA(주소)들은 건드리지 마"라고 예약합니다.
3. 매핑 테이블 업데이트: 커널은 "이제부터 RAM에서 쫓겨난 놈들은 이 파일의 0번지부터 차곡차곡 쌓는다"라고 기록합니다.

+ 왜 용량 제한이 있을까? (무한대로 늘리면 안 되나?)

1. 관리 비용 (Overhead): 스왑 공간이 100TB라면, 그 위치를 관리하기 위한 페이지 테이블 자체의 크기가 어마어마하게 커져서 오히려 RAM을 잡아먹습니다.
2. 성능 임계점: 스왑이 많다는 건 이미 RAM이 부족하다는 뜻입니다. 스왑 영역이 아무리 커봤자, SSD 속도 한계 때문에 시스템은 이미 기어가는 중일 겁니다. (밑 빠진 독에 물 붓기)

3-3. 스왑 시 가장 오래 안 건드린 놈을 찾는 법 (LRU & Reference Bit)

OS가 모든 페이지의 사용 시간을 초시계로 잴 수는 없습니다. (오버헤드가 너무 큼). 그래서 하드웨어(CPU)의 도움을 받습니다.

 

하드웨어의 도움: Reference Bit (참조 비트)

페이지 테이블의 각 항목(Entry)에는 주소만 있는 게 아니라 R 비트라는 스위치가 있습니다.

• CPU의 역할: CPU가 어떤 페이지를 읽거나 쓸 때마다, 하드웨어적으로 R 비트를 1로 만듭니다. (자동)

 

OS의 역할: 시계 알고리즘 (Clock Algorithm)

OS는 주기적으로(또는 메모리가 부족할 때) 빗자루를 들고 페이지들을 순찰합니다.

1. 페이지를 하나 봅니다. R 비트가 1인가요?
   • "아, 최근에 썼구나. 봐준다." -> R 비트를 0으로 끄고(Reset) 다음으로 넘어갑니다. (Second Chance)
2. 페이지를 봤는데 R 비트가 0인가요?
   • "너 내가 지난번에 0으로 껐는데, 한 바퀴 돌 동안 한 번도 안 쓰였네? 넌 아웃이야."
   • Swap Out 대상 당첨!

이 간단한 0과 1의 비트 토글링만으로, OS는 기가 막히게 "최근에 안 쓴 놈"을 찾아냅니다.

 

요약

1. 가상 메모리: OS가 프로그램들에게 "너네 혼자 다 써!"라고 뻥을 치는 기술.
2. MMU: 그 뻥이 들통나지 않게 주소를 실시간으로 번역해주는 하드웨어.
3. 스왑(Swap): RAM이 모자랄 때 SSD를 빌려 쓰는 기술. (하지만 느리다