[5회차] 메모리 관리

[github-actions[bot]]

🚀 발표 주제

메모리 관리

---

📅 발표일

2026-07-13

🙋 발표자

초록

🗂️ 카테고리

⚙️ Operating System

📚 발표 자료

발표 자료

🎥 발표 영상

업로드 예정

---

🎯 핵심 개념 요약

물리 메모리는 한정되어 있기 때문에, OS는 모든 프로세스에게 0부터 시작하는 논리 주소 공간이라는 착시를 제공하고, 주소 변환과 적재 방식을 발전시켜(연속 할당 → 세그멘테이션 → 페이징 → 요구 페이징) 메모리를 효율적으로 나눠 쓴다.

1. 왜 메모리 관리가 필요한가

• RAM은 비싸고(RAM is Expensive), 휘발성이다(RAM is Volatile) → 물리 메모리는 언제나 부족한 자원
• 동시에 여러 프로세스(발표 예시: 마인크래프트, 크롬)가 실행되는데, 각 프로세스는 독립된 주소 공간이 필요하다
• 프로세스가 물리 주소에 직접 접근하면? → 서로의 메모리를 침범해 충돌 발생

2. 논리 주소(Logical Address Space)의 도입

• OS는 모든 프로세스에게 0번부터 시작하는 자기만의 주소 공간(논리 주소) 을 만들어 준다
• 프로세스는 논리 주소만 보고, 실제 물리 메모리 어디에 올라가 있는지는 신경 쓰지 않는다
• 논리 주소 → 물리 주소 변환은 하드웨어가 담당: MMU(Memory Management Unit)

3. 메모리 관리 기법의 발전 흐름

기법	아이디어	해결한 것	남은 문제
Contiguous Allocation (연속 할당)	프로세스를 물리 메모리의 연속된 공간에 통째로 배치	주소 변환의 단순함	외부/내부 단편화
Segmentation (세그멘테이션)	의미 있는 단위(Code / Data / Heap / Stack)로 잘라 각각 배치	논리적 단위로 보호·공유 가능	세그먼트 크기가 제각각 → 외부 단편화 여전
Paging (페이징)	논리/물리 메모리를 4KB 고정 크기(Page / Frame)로 쪼개 매핑	외부 단편화 해결	페이지 테이블 관리 비용
Demand Paging (요구 페이징)	당장 필요한 페이지만 메모리에 적재	메모리를 실제보다 크게 활용	Page Fault 처리 비용

4. 단편화(Fragmentation)

• 외부 단편화(External Fragmentation): 빈 공간의 총합은 충분한데, 조각조각 나뉘어 있어 연속된 공간이 없어 프로세스를 못 올리는 상황
• 내부 단편화(Internal Fragmentation): 할당된 블록 안쪽에서 쓰지 않고 남는 공간이 생기는 상황

5. Demand Paging과 Page Fault

• 프로세스 실행에 모든 페이지가 다 메모리에 있을 필요는 없다 → 필요한 페이지만 올려도 실행 가능
• 필요한 페이지가 메모리에 없으면? → Page Fault 발생 → 디스크에서 해당 페이지를 가져와 적재

6. TLB (Translation Lookaside Buffer)

• Segmentation/Paging은 매번 주소 변환을 거치므로 성능 저하 우려
• 최근에 변환한 주소를 캐시(TLB) 에 저장해 변환 속도를 보완

📚 참고 자료

🙋‍♀️ 질문

1. Page Fault가 너무 자주 발생하면 어떻게 될까? (스래싱) "램이 부족하면 컴퓨터가 느려진다"는 일상의 경험이 이 현상과 어떻게 연결되는 걸까?
2. TLB도 캐시라면, 컨텍스트 스위칭이 일어날 때 TLB는 어떻게 처리될까? 다른 프로세스의 변환 정보가 남아 있어도 문제없는 걸까?
3. JVM의 OutOfMemoryError는 OS 관점에서 어떤 상황일까? OS의 Page Fault와는 어떤 관계일까?