284. MMU (Memory Management Unit)

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

본질: MMU (Memory Management Unit)는 CPU (Central Processing Unit)가 만든 가상 주소를 물리 주소로 바꾸고, 그 접근이 허용되는지까지 판정하는 메모리 해석기이자 보안 관문이다.

가치: MMU가 있어야 운영체제 (Operating System)는 프로세스마다 독립된 주소 공간, 페이지 보호, 요구 페이징 같은 가상 메모리 정책을 실제 하드웨어에 강제할 수 있다.

판단 포인트: MMU의 성능은 단순 변환 속도보다 TLB (Translation Lookaside Buffer) 적중률, 페이지 테이블 깊이, 컨텍스트 스위치 비용, 보호 예외 처리 전략에서 갈린다.

Ⅰ. 개요 및 필요성

MMU (Memory Management Unit)는 프로세서가 보는 주소 체계와 실제 메인 메모리인 RAM (Random Access Memory)의 주소 체계를 이어 주는 주소 변환 하드웨어다. 프로그램은 자신이 넓고 연속적인 메모리를 독점하는 것처럼 동작하지만, 실제 DRAM (Dynamic Random Access Memory)은 여러 프로세스와 커널이 뒤섞여 사용한다. 이 간극을 소프트웨어만으로 메우면 메모리 접근마다 주소 계산과 권한 검사를 수행해야 하므로 성능이 급격히 무너진다.

MMU가 필요한 이유는 세 가지다. 첫째, 격리다. 한 프로세스의 오류가 다른 프로세스나 커널 메모리를 덮어쓰지 못하게 해야 한다. 둘째, 추상화다. 개발자는 실제 RAM 배치가 아니라 가상 주소 공간 기준으로 프로그램을 작성해야 생산성이 높다. 셋째, 확장성이다. 당장 필요한 페이지만 메모리에 두고 나머지는 보조기억장치와 연계해야, 물리 메모리보다 큰 작업도 실행할 수 있다.

아래 그림은 MMU가 단순 번역기만이 아니라, 권한 검사와 예외 분기를 함께 수행하는 지점임을 보여준다.

┌──────────────────────────────────────────────────────────────────────────────┐
│                  MMU가 개입하는 이유: 주소 해석 + 접근 통제                 │
├──────────────────────────────────────────────────────────────────────────────┤
│ 프로그램 ── 가상 주소 생성 ──▶ CPU ──▶ MMU ──▶ 물리 주소 ──▶ DRAM          │
│                                      │                                       │
│                                      ├─ 권한 위반 ─▶ Protection Fault       │
│                                      │                                       │
│                                      └─ 매핑 없음 ───▶ Page Fault           │
└──────────────────────────────────────────────────────────────────────────────┘

핵심은 MMU가 없으면 운영체제가 설계한 보호 정책이 "규칙"에 머물고, MMU가 있어야 그것이 "강제력 있는 하드웨어 정책"이 된다는 점이다. 즉 MMU는 가상 메모리의 편의 기능을 제공하는 장치이면서, 동시에 시스템 신뢰성의 마지막 방어선이다.

📢 섹션 요약 비유: MMU는 대형 오피스 건물의 안내 데스크와 같다. 방문객에게 회의실 번호를 알려주는 것에서 끝나지 않고, 출입증이 없는 사람이 서버실 문을 열려 하면 즉시 경보를 울린다.

Ⅱ. 아키텍처 및 핵심 원리

MMU의 실제 동작은 "가상 주소를 나눠 보고, 캐시를 먼저 확인하고, 필요하면 페이지 테이블을 따라가며, 마지막에 권한을 검증하는 과정"으로 요약된다. 가상 주소는 보통 **가상 페이지 번호 (Virtual Page Number)**와 **오프셋 (Offset)**으로 분리되며, MMU는 페이지 번호에 대해 매핑을 찾은 뒤 오프셋을 그대로 붙여 물리 주소를 만든다.

구성 요소	역할	병목 또는 설계 포인트
TLB (Translation Lookaside Buffer)	최근 주소 변환 결과 캐시	적중률이 낮으면 page walk 증가
페이지 테이블 (Page Table)	가상 페이지와 물리 프레임 매핑 저장	다단계일수록 메모리 접근 수 증가
PTE (Page Table Entry)	유효 비트, 권한, Dirty/Access 정보 보유	보호 예외와 페이지 폴트 판단 기준
PTBR (Page Table Base Register)	현재 프로세스의 페이지 테이블 시작점 지정	컨텍스트 스위치 시 교체 필요

아래 흐름은 TLB 적중과 실패, 그리고 보호 예외의 차이를 한 번에 보여준다.

┌──────────────────────────────────────────────────────────────────────────────┐
│                        MMU 주소 변환의 실행 경로                            │
├──────────────────────────────────────────────────────────────────────────────┤
│ 1) CPU가 가상 주소 요청                                                     │
│        │                                                                    │
│        ▼                                                                    │
│ 2) TLB 조회                                                                 │
│    ├─ Hit  ───────────────▶ 물리 프레임 획득                                │
│    └─ Miss ─▶ Page Table Walk ─▶ PTE 확인                                   │
│                                 ├─ Invalid ─────▶ Page Fault                │
│                                 └─ Valid ───────▶ TLB 갱신                  │
│                                                        │                     │
│                                                        ▼                     │
│ 3) 권한 비트 검사 (Read / Write / Execute, User / Kernel)                   │
│    ├─ 허용 ───────────────▶ 물리 주소 생성 후 메모리 접근                   │
│    └─ 위반 ───────────────▶ Protection Fault / Trap                         │
└──────────────────────────────────────────────────────────────────────────────┘

이 구조에서 중요한 것은 **페이지 폴트 (Page Fault)**와 보호 예외가 다르다는 점이다. 페이지 폴트는 "주소 체계상 유효하지만 지금 메모리에 없으니 운영체제가 가져와야 하는 경우"이고, 보호 예외는 "그 페이지가 존재하더라도 현재 실행 주체가 접근하면 안 되는 경우"다. 전자는 운영체제가 복구 가능한 정상 제어 흐름일 수 있지만, 후자는 보안 또는 프로그램 오류의 신호인 경우가 많다.

또한 MMU는 혼자 일하지 않는다. 운영체제가 프로세스별 페이지 테이블을 만들고, 컨텍스트 스위치 시 PTBR을 바꾸며, 페이지 폴트가 발생하면 디스크에서 해당 페이지를 적재한다. 즉 MMU는 하드웨어이고 정책은 운영체제가 정한다. 둘의 협업이 맞물려야 가상 메모리가 성립한다.

📢 섹션 요약 비유: MMU는 택배 분류기와 같다. 주소 스티커를 보고 먼저 자주 가는 지역은 기억창고(TLB)에서 바로 처리하고, 기억이 안 나면 중앙 장부(페이지 테이블)를 뒤진 뒤, 마지막으로 "이 물건은 위험물이라 일반 구역에 못 보낸다" 같은 규칙까지 확인한다.

Ⅲ. 비교 및 연결

MMU를 이해할 때 자주 헷갈리는 대상은 MPU (Memory Protection Unit)다. 둘 다 메모리 보호를 다루지만, MMU는 주소 변환 + 보호를 담당하고, MPU는 보통 영역 기반 보호에 집중한다. 그래서 정교한 가상 메모리와 멀티프로세스 격리가 필요한 데스크톱·서버 OS는 MMU를 선호하고, 실시간성·단순성이 중요한 소형 임베디드 시스템은 MPU를 선택하기도 한다.

항목	MMU	MPU (Memory Protection Unit)
주소 체계	가상 주소를 물리 주소로 변환	대체로 물리 주소 기반 영역 보호
가상 메모리	지원 가능	일반적으로 미지원
보호 단위	페이지 단위 세밀 제어	영역 단위 제어
장점	격리, 페이징, 대용량 주소 공간	단순성, 낮은 오버헤드, 예측 가능성
적합 환경	범용 OS, 서버, 모바일	마이크로컨트롤러 (Microcontroller Unit), RTOS (Real-Time Operating System), 소형 임베디드

운영체제와의 연결도 중요하다. 페이지 테이블은 운영체제가 관리하고, MMU는 그것을 해석한다. TLB는 MMU의 속도를 지키기 위한 내부 캐시이고, 컨텍스트 스위치는 이 캐시의 효율을 흔드는 이벤트다. 결과적으로 MMU는 컴퓨터구조의 주제가 아니라 운영체제, 보안, 가상화까지 이어지는 경계 개념이다.

특히 가상화 환경에서는 한 번의 주소 변환으로 끝나지 않는다. 게스트 운영체제 (Guest Operating System)가 만든 가상 주소를 다시 하이퍼바이저의 물리 주소 체계에 맞춰 해석해야 하므로, EPT (Extended Page Tables)나 NPT (Nested Page Tables) 같은 2단계 변환 구조가 등장한다. 이 지점에서 MMU 성능은 곧 클라우드 밀도와 직결된다.

📢 섹션 요약 비유: MMU는 상세한 도로명 주소와 출입 권한까지 관리하는 스마트 내비게이션이고, MPU는 "여긴 공장 구역, 여긴 주거 구역"처럼 큰 구역만 막는 울타리에 가깝다. 둘 다 질서를 만들지만 정밀도와 유연성의 수준이 다르다.

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

실무에서 MMU는 이론보다 "어디서 비용이 터지는가"를 읽는 능력이 더 중요하다. 첫 번째 판단 포인트는 TLB 미스 비용이다. 다단계 페이지 테이블 구조에서 TLB 미스가 나면 실제 데이터 접근 전에 여러 번의 메모리 참조가 선행된다. 데이터베이스, 가상화 호스트, 대용량 인메모리 애플리케이션처럼 메모리 지역성이 깨지는 환경에서는 이 비용이 눈에 띄게 커진다.

두 번째는 컨텍스트 스위치와 주소 공간 식별이다. 프로세스 전환 때마다 TLB를 과도하게 비우면 스케줄링 자체가 메모리 변환 오버헤드로 바뀔 수 있다. 이를 줄이기 위해 ASID (Address Space Identifier) 또는 PCID (Process-Context Identifier) 같은 기능을 활용하면, 서로 다른 주소 공간의 항목을 TLB 안에 함께 유지할 수 있다.

세 번째는 보안 정책의 하드웨어화다. NX (No-eXecute) 비트, 사용자/커널 분리, 읽기 전용 코드 페이지 같은 설정은 보안 솔루션이 아니라 MMU의 기본 기능에서 출발한다. 버퍼 오버플로우나 임의 코드 실행 공격을 막는 데서 MMU는 매우 직접적인 역할을 한다.

실무 체크리스트

TLB 적중률이 낮아 page walk가 과도하게 발생하지 않는가?
Huge Page 사용이 메모리 낭비보다 TLB 효율 향상에 더 유리한가?
컨텍스트 스위치 빈도와 ASID/PCID 활용 여부가 함께 검토되었는가?
NX 비트, 커널 분리, 읽기 전용 매핑이 실제로 활성화되어 있는가?
가상화 환경이라면 2단계 주소 변환 비용을 모니터링하고 있는가?

안티패턴

"RAM만 충분하면 MMU 비용은 무시해도 된다"고 보는 태도
TLB 미스를 캐시 미스와 동일하게 취급하며 별도 분석하지 않는 운영
보안 권한 비트를 운영체제 옵션 정도로 여기고 하드웨어 보호 모델과 분리해 보는 설계
📢 섹션 요약 비유: MMU 튜닝은 창고 크기만 키우는 일이 아니다. 자주 쓰는 물건을 입구 가까이에 두고, 출입증 정책을 정교하게 만들고, 교대 근무 때 창고 지도를 매번 버리지 않게 하는 운영 설계까지 함께 봐야 한다.

Ⅴ. 기대효과 및 결론

잘 설계된 MMU 활용 전략은 세 가지 효과를 만든다. 첫째, 안정성이다. 프로세스 간 침범을 막아 장애가 국소화된다. 둘째, 확장성이다. 가상 주소 공간 덕분에 큰 프로그램과 많은 프로세스를 동시에 다룰 수 있다. 셋째, 보안성이다. 실행 권한과 접근 수준이 하드웨어에서 강제되므로, 소프트웨어 버그가 곧바로 시스템 전체 붕괴로 이어질 가능성이 줄어든다.

반면 전제조건도 분명하다. 페이지 테이블이 지나치게 깊거나, TLB 설계가 부적절하거나, 메모리 지역성이 나쁜 워크로드에서는 MMU의 이점이 오히려 지연 비용으로 체감될 수 있다. 또한 MMU는 만능이 아니어서, 잘못된 공유 메모리 설계나 과도한 페이지 폴트 같은 상위 계층 문제까지 자동 해결해 주지는 못한다.

앞으로는 CPU용 MMU를 넘어 IOMMU (Input-Output Memory Management Unit)와 보안 격리 기술이 더 중요해진다. 장치 DMA (Direct Memory Access) 격리, 가상 머신 간 메모리 보호, 기밀 컴퓨팅 같은 주제가 모두 "누가 어떤 주소를 믿고 접근할 수 있는가"라는 MMU 철학 위에 서 있기 때문이다. 결국 MMU는 주소를 바꾸는 회로가 아니라, 현대 시스템이 안전하게 멀티태스킹하고 가상화될 수 있게 만드는 신뢰 인프라로 기억해야 한다.

📢 섹션 요약 비유: MMU는 도시의 주소 체계와 출입 통제 시스템을 함께 맡은 관제소다. 길 안내만 잘해서는 부족하고, 허가받은 사람만 맞는 건물에 들어가게 해야 도시가 안전하게 굴러간다.

📌 관련 개념 맵

개념	연결 포인트
페이지 테이블 (Page Table)	운영체제가 만든 주소 변환 장부로, MMU가 직접 참조하는 정책 데이터다.
TLB (Translation Lookaside Buffer)	MMU 내부의 변환 캐시로, page walk 지연을 줄이는 핵심 성능 장치다.
페이지 폴트 (Page Fault)	MMU가 매핑 부재를 감지해 운영체제 개입을 요청하는 대표 예외다.
메모리 보호 (Memory Protection)	읽기/쓰기/실행 권한과 사용자/커널 분리가 MMU에서 강제된다.
IOMMU (Input-Output Memory Management Unit)	CPU뿐 아니라 장치 입출력까지 주소 변환과 격리 범위를 확장한 개념이다.

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

고정 물리 주소 직접 접근
        │
        ▼
메모리 보호 요구 증가
        │
        ▼
MMU (Memory Management Unit)
        │
        ├─▶ 페이지 테이블 (Page Table)
        │        │
        │        ▼
        │   TLB (Translation Lookaside Buffer)
        │
        ├─▶ 가상 메모리 (Virtual Memory)
        │        │
        │        ▼
        │   요구 페이징 (Demand Paging)
        │
        └─▶ 가상화 확장
                 │
                 ▼
          EPT / NPT · IOMMU

이 흐름은 "보호 필요성 → 주소 변환 하드웨어 → 성능 보완 → 가상 메모리 확장 → 가상화/장치 격리"로 MMU의 역할이 넓어지는 과정을 보여준다.

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

MMU는 컴퓨터 안에서 "이 주소는 진짜 어디야?"를 바로 찾아주는 아주 빠른 안내원이에요.
그런데 안내만 하는 게 아니라, "넌 이 방에 들어가면 안 돼" 하고 나쁜 접근도 막아줘요.
그래서 많은 프로그램이 한 집에 같이 살아도 서로 방을 망가뜨리지 않고 안전하게 지낼 수 있어요.