131. 메모리 맵 파일 IPC (Memory-Mapped File IPC)

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

본질: 메모리 맵 파일 IPC (Inter-Process Communication)는 운영체제의 mmap() 시스템 콜을 통해 파일 또는 익명 메모리 영역을 프로세스의 가상 주소 공간 (Virtual Address Space)에 직접 매핑하여, 프로세스 간 데이터를 커널 버퍼를 경유하지 않고 페이지 폴트 (Page Fault) 기반으로 공유하는 통신 기법이다.

가치: MAP_SHARED 플래그를 사용하면 여러 프로세스가 동일한 물리 페이지 (Physical Page)를 공유하므로, 대용량 데이터를 복사 없이(zero-copy) 교환할 수 있어 고성능 IPC가 가능하며, 파일 시스템과의 일관성도 자동으로 보장된다.

융합: POSIX 공유 메모리 (POSIX Shared Memory, shm_open)의 내부 구현이 사실상 mmap() 기반으로 동작하므로, 메모리 맵 파일은 POSIX IPC의 근간을 이루는 핵심 메커니즘이다. 다만 동기화는 별도의 세마포어 (Semaphore)나 파일 락 (File Lock)으로 명시적으로 수행해야 한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: mmap() 시스템 콜은 디스크 상의 파일이나 익명 영역을 호출자 프로세스의 가상 메모리 (Virtual Memory)에 매핑한다. MAP_SHARED 플래그를 지정하여 매핑하면, 해당 영역에 대한 쓰기가 물리 메모리 상의 동일한 페이지 프레임 (Page Frame)에 반영되므로 매핑을 공유하는 모든 프로세스가 즉시 변경 사항을 관찰할 수 있다. 이를 통해 프로세스 간 IPC를 구현한다.
필요성: 전통적인 파이프 (Pipe)나 소켓 (Socket) 기반 IPC는 데이터가 사용자 공간에서 커널 공간으로, 다시 대상 프로세스의 사용자 공간으로 복사되는 2중 버퍼 복사(2x Copy)를 수반한다. 대용량 데이터 구조(예: 수백 MB의 이미지 버퍼)를 교환할 때 이러한 복사 비용은 치명적이다. mmap()은 페이지 폴트 (Page Fault)를 통해 물리 페이지를 직접 공유하므로 복사 오버헤드를 근본적으로 제거할 수 있다.
💡 비유: mmap() IPC는 두 사람이 동시에 도면을 펼쳐놓고 각자 자기 책상 위에 둔 거울(가상 메모리)을 통해 그 하나의 도면(물리 페이지)을 바라보는 것과 같다. 한쪽에서 도면에 펜으로 선을 추가하면, 다른 쪽의 거울에도 즉시 그 선이 비친다.

운영체제의 페이지 테이블 (Page Table)이 어떻게 여러 프로세스를 동일한 물리 프레임으로 연결하는지 아키텍처 다이어그램으로 확인할 수 있다.

┌─ 프로세스 A 가상 주소 공간 ─┐  ┌─ 프로세스 B 가상 주소 공간 ─┐
│ 0x7F0000_0000 (매핑 주소)    │  │ 0x7F0000_0000 (매핑 주소)    │
│        │                     │  │        │                     │
├────────┼─────────────────────┤  ├────────┼─────────────────────┤
│ Page Table                  │  │ Page Table                    │
│  VA ──────▶ PTE ──────┐     │  │  VA ──────▶ PTE ──────┐       │
│  0x7F000               │     │  │  0x7F000               │     │
└────────────────────────┼─────┘  └────────────────────────┼─────┘
                         │                                       │
                         └──────────┬────────────────────────────┘
                                    ▼
                        ┌────────────────────────────────────────┐
                        │   물리 메모리                          │
                        │  Page Frame #2048   │  ◀── MAP_SHARED 매핑
                        │  [ 공유 데이터 영역 ] │      (커널이 동일 프레임 연결)
                        └────────────────────────────────────────┘

[다이어그램 해설] 이 도식의 핵심은 두 프로세스의 페이지 테이블 (Page Table)이 서로 다른 가상 주소(VA, Virtual Address)를 동일한 물리 페이지 프레임(Page Frame) #2048으로 변환한다는 점이다. MAP_SHARED 플래그를 사용하면 커널은 매핑 시점에 COW (Copy-on-Write)를 적용하지 않고, 모든 매핑을 동일한 물리 프레임에 직결한다. 따라서 프로세스 A가 해당 주소에 값을 쓰면 물리 프레임의 내용이 즉시 갱신되며, 프로세스 B가 동일 주소를 읽을 때 페이지 폴트 없이 캐시 일관성 (Cache Coherence) 프로토콜(MESI 등)을 통해 최신 값을 관찰하게 된다.

📢 섹션 요약 비유: 두 집(프로세스)이 동일한 공용 냉장고(물리 페이지)를 각자의 현관문(가상 주소)을 통해 출입할 수 있도록 건축(페이지 테이블 매핑)한 구조와 같습니다. 한쪽에서 우유를 마시고 다시 넣어두면, 다른 쪽에서 열었을 때 바로 빈 자리를 볼 수 있습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

메모리 맵 파일 IPC의 동작은 요구 페이징 (Demand Paging) 메커니즘과 긴밀하게 결합되어 있다.

구성 요소	역할	내부 동작	관련 개념	비유
mmap() 시스템 콜	파일을 가상 메모리에 매핑	VMA (Virtual Memory Area) 생성, 페이지 테이블 항목 초기화	MAP_SHARED, MAP_PRIVATE	도면을 책상 위에 펼치기
페이지 폴트 핸들러	실제 물리 페이지 할당	디스크에서 페이지를 읽어 물리 프레임에 적재	Demand Paging	처음 펼칠 때만 도면을 꺼내오기
MAP_SHARED 플래그	변경 사항을 모든 매핑에 반영	COW 비활성화, 직접 쓰기 모드	Write-Through, Dirty Bit	모두가 동시에 보는 화이트보드
msync() 시스템 콜	변경된 페이지를 디스크에 반영	dirty 페이지를 파일 시스템으로 플러시	fsync(), flush	화이트보드 내용을 원본에 저장

mmap()을 통한 데이터 공유가 실제로 어떤 시점에 물리 메모리를 소비하는지 타이밍 다이어그램으로 시각화할 수 있다.

  프로세스 A                      커널                      프로세스 B
     │                            │                             │
     ├── mmap(fd, MAP_SHARED) ──▶│                              │
     │   [VMA만 생성, 물리 할당 X] │                            │
     │◀── 매핑된 주소 반환 ───────┤                             │
     │                            │                             │
     ├── *addr = 42 (쓰기 시도) ─▶│                             │
     │   [Page Fault 발생!]       │                             │
     │   [디스크→물리 프레임 적재] │                            │
     │◀── 제어권 반환 ────────────┤                             │
     │                            │                             │
     │                            │◀── mmap(fd, MAP_SHARED) ──┤
     │                            │   [동일 물리 프레임 매핑]   │
     │                            ├── 동일 주소 반환 ────────▶  │
     │                            │                             │
     │                            │◀── val = *addr (읽기) ────┤
     │                            │   [Page Hit! 값 42 관찰]    │
     │                            ├── 42 반환 ───────────────▶  │

[다이어그램 해설] 이 순차 흐름도는 mmap() 기반 IPC의 지연 할당(Lazy Allocation) 특성을 명확히 보여준다. mmap() 호출 시점에는 커널이 단지 VMA (Virtual Memory Area) 객체를 생성할 뿐 실제 물리 메모리를 할당하지 않는다. 프로세스 A가 처음으로 해당 영역에 쓰기를 시도하면 페이지 폴트(Page Fault)가 발생하고, 그 시점에서야 커널이 디스크에서 데이터를 읽어 물리 프레임에 적재한다. 프로세스 B가 이후 동일 파일을 mmap()으로 매핑하면, 커널은 이미 적재된 물리 프레임을 B의 페이지 테이블에 추가로 연결하므로 추가적인 디스크 I/O 없이 즉시 A의 쓰기 결과(값 42)를 읽을 수 있다. 이것이 mmap() IPC가 복사 오버헤드 없이 동작하는 핵심 원리다.

📢 섹션 요약 비유: 도서관에서 책을 빌릴 때 즉시 책의 모든 페이지를 복사해서 가져오는 것이 아니라, 처음 읽으려는 페이지를 펼칠 때만 직원이 찾아오는(demand paging) 지혜로운 시스템과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

mmap() IPC는 POSIX 공유 메모리 (shm_open + mmap) 및 System V 공유 메모리 (shmget + shmat)와 유사한 결과를 낳지만, 내부 구현과 생명주기에서 중요한 차이가 존재한다.

항목	mmap() 파일 매핑	POSIX shm_open + mmap	System V shmget + shmat
백엔드 저장소	실제 파일 시스템의 파일	tmpfs (/dev/shm 내)	커널 내부 메모리
커널 종료 후 지속성	파일에 기록되면 영속	tmpfs이므로 휘발성	커널 파라미터로 제어
동기화 필요 여부	명시적 동기화 필수	명시적 동기화 필수	명시적 동기화 필수
이식성 (Portability)	POSIX 표준, 범용	POSIX 표준, 비교적 최신	System V 계열 한정
복사 횟수 (Copy Count)	0회 (zero-copy)	0회 (zero-copy)	0회 (zero-copy)

세 가지 공유 메모리 IPC 기법의 물리 메모리 연결 방식을 구조적으로 비교할 수 있다.

[1] mmap() 파일 매핑                [2] POSIX shm + mmap
┌─────────┐    ┌───────────┐          ┌─────────┐    ┌────────────┐
│  Proc A │    │  디스크    │          │  Proc A │    │   tmpfs   │
│  VMA ───┼──▶ │  파일     │◀─────────┤  VMA ───┼──▶ │ /dev/shm   │
│         │    │  (백엔드) │          │         │    │ (백엔드)   │
└────┬────┘    └───────────┘          └────┬────┘    └────────────┘
     │                                                            │
     ▼                                      ▼
┌─────────────────┐                 ┌─────────────────────────────┐
│  물리 프레임     │                 │  물리 프레임               │
└─────────────────┘                 └─────────────────────────────┘

[3] System V shmget + shmat
┌─────────┐    ┌──────────────────────────────────────────────────┐
│  Proc A │    │  커널 내부 메모리                                │
│  VMA ───┼──▶ │  shm seg (백엔드)                                │
│         │    │  (파일 시스템 없음)                              │
└────┬────┘    └──────────────────────────────────────────────────┘
                                                                  │
     ▼
┌─────────────────────────────────────────────────────────────────┐
│  물리 프레임                                                    │
└─────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 세 가지 구조의 결정적 차이는 '백엔드 저장소(Backend Store)'의 존재 여부와 위치에 있다. mmap() 파일 매핑은 실제 파일 시스템 상의 파일을 백엔드로 삼아, 물리 메모리가 부족할 때 디스크로 스왑아웃(Swap-out)이 가능하다. 반면 System V 공유 메모리는 파일 시스템과 무관하게 커널 내부에만 존재하며, POSIX 공유 메모리는 tmpfs라는 메모리 기반 파일 시스템을 백엔드로 사용한다. mmap() 파일 매핑의 고유한 장점은 데이터가 자동으로 파일에 반영되므로, 프로세스 재시작 후에도 이전 상태를 복원할 수 있는 지속성(Persistence)을 제공한다는 점이다.

컴퓨터구조 (CA, Computer Architecture) 관점: mmap()은 TLB (Translation Lookaside Buffer)를 최대한 활용하는 설계다. 한 번 매핑된 페이지에 대해 TLB 엔트리가 생성되면, 이후의 접근은 하드웨어 수준에서 주소 변환이 완료되므로 소프트웨어 개입 없이 나노초 단위의 접근 지연으로 공유 데이터를 읽고 쓸 수 있다.
📢 섹션 요약 비유: 세 가지 방식은 모두 같은 '공용 게시판(물리 프레임)'을 사용하지만, 게시판이 밖에 있는지(mmap 파일), 사내 라커에 있는지(POSIX shm), 아니면 사장님 서랍에만 있는지(System V shm)가 다른 셈입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

mmap() 기반 IPC는 고성능 애플리케이션에서 널리 사용되지만, 동기화 누락 시 데이터 일관성이 파괴되는 치명적 리스크가 존재한다.

실무 시나리오 1. 영상 처리 파이프라인에서의 프레임 버퍼 공유: 4K 해상도(3840x2160)의 미처리 영상 프레임 한 장은 약 33MB(RGB 3바이트/픽셀)이다. 파이프나 소켓으로 매 초 60프레임을 전송하면 초당 약 2GB의 버퍼 복사가 발생한다. mmap() 기반 공유 메모리 버퍼를 사용하면, 프로듀서(카메라 캡처 프로세스)가 프레임을 버퍼에 기록하고 소비자(인코딩 프로세스)가 즉시 동일 주소를 읽으므로 복사가 전혀 발생하지 않는다.

실무 시나리오 2. 동기화 누락으로 인한 레이스 컨디션 (Race Condition): 두 프로세스가 mmap()으로 공유한 카운터를 동기화 없이 증가시키면, 읽기-수정-쓰기(Read-Modify-Write) 연산이 원자적(Atomic)이지 않아 값이 소실된다. 반드시 futex 기반의 POSIX 세마포어 또는 pthread_mutex를 공유 메모리 내에 배치하여 보호해야 한다.

아키텍트는 IPC 메커니즘 선택을 위한 의사결정 기준을 수립해야 한다.

   [ IPC 메커니즘 선택 트리 ]
                │
                ▼
     교환할 데이터 크기가 1MB 이상인가?
        ├── 예 ──▶ 실시간성이 필수적인가?
        │              ├── 예 ──▶ mmap() MAP_SHARED (zero-copy)
        │              │          + POSIX semaphore 동기화
        │              └── 아니오 ──▶ 공유 메모리 + msync() 주기적 플러시
                │
        └── 아니오 ──▶ 단방향 스트림인가 양방향인가?
                       ├── 단방향 ──▶ 파이프 (Pipe) 또는 FIFO
                       └── 양방향 ──▶ Unix Domain Socket
                          (작은 메시지에 최적화, 커널 버퍼 관리 자동)

[다이어그램 해설] 이 의사결정 트리는 데이터 크기와 실시간성 요구를 기준으로 최적의 IPC를 선택하는 기준을 제공한다. mmap() IPC는 대용량 데이터의 zero-copy 전달에 압도적 우위를 가지지만, 작은 제어 메시지(수바이트~수킬로바이트)에는 오히려 VMA 설정 및 페이지 폴트 처리 오버헤드가 더 크다. 따라서 명령어나 상태 신호 같은 소규모 메시지에는 파이프나 소켓이 더 효율적이다. 또한 mmap()은 반드시 외부 동기화 수단을 병행해야 하므로, 개발 복잡도도 함께 평가해야 한다.

도입 체크리스트:

공유 메모리 영역에 대한 접근이 반드시 세마포어 또는 뮤텍스로 보호되고 있는가?
매핑 크기가 페이지 크기(Page Size, 일반적으로 4KB)의 배수로 정렬되어 있는가?
프로세스 종료 시 munmap()을 호출하여 VMA를 해제하고 있는가?
📢 섹션 요약 비유: 대량의 화물(대용량 데이터)을 옮길 때는 트럭을 여러 번 보내는 것(소켓/파이프)보다, 두 창고 사이에 직통 도로를 깔아놓고(mmap) 지게차가 직접 드나들게 하는 것이 효율적이지만, 출입 순서를 안내하는 교통 정리(동기화)는 반드시 필요합니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

mmap() 기반 IPC는 대용량 데이터 공유의 표준으로 자리 잡았으며, 컨테이너 및 가상화 환경에서도 핵심적인 역할을 수행한다.

구분	파이프/소켓 기반 IPC	mmap() 기반 IPC	비즈니스 파급 효과
데이터 복사 횟수	2회 (User-Kernel-User)	0회 (zero-copy)	대용량 처리 시 CPU 활용률 극대화
지연 시간 (Latency)	마이크로초~밀리초	나노초(TLB Hit 시)	실시간 영상/금융 시스템에서 결정적 응답 보장
구현 복잡도	낮음 (커널이 관리)	높음 (동기화 직접 구현)	개발 및 테스트 비용 증가, 디버깅 난이도 상승

미래 전망: mmap() 메커니즘은 커널 바이패스 (Kernel Bypass) 기술인 DPDK (Data Plane Development Kit) 및 SPDK (Storage Performance Development Kit)와 융합하여, 네트워크 및 스토리지 I/O 경로에서도 zero-copy를 실현하는 핵심 기반으로 진화하고 있다. 또한 CXL (Compute Express Link) 메모리 의미론( Semantics)이 도입되면서, mmap()으로 매핑된 영역이 다른 노드의 원격 메모리를 직접 참조하는 분산 공유 메모리 (DSM, Distributed Shared Memory) 패러다임으로 확장될 전망이다.

📢 섹션 요약 비유: mmap()은 두 도시(프로세스) 사이에 성벽(커널)을 뚫고 직통 고속도로(zero-copy)를 건설하여 화물을 실시간으로 주고받게 한 획기적인 인프라로, 앞으로는 다른 나라의 창고까지 연결하는 국제 고속도로(분산 공유 메모리)로 확장될 것입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
페이지 폴트 (Page Fault)	`mmap()` 호출 시에는 VMA만 생성되며, 실제 데이터 접근 시 페이지 폴트가 발생하여 물리 프레임이 지연 할당되는 핵심 메커니즘.
MAP_SHARED	매핑된 영역의 변경 사항을 모든 공유 프로세스 및 백엔드 파일에 반영하는 플래그로, IPC를 가능하게 하는 결정적 옵션.
POSIX 공유 메모리 (shm_open)	내부적으로 `mmap()`을 사용하여 `tmpfs` 상에 익명 파일을 생성하고 매핑하는 현대적 IPC API.
세마포어 (Semaphore)	`mmap()` IPC는 동기화를 제공하지 않으므로, 공유 메모리 영역에 대한 상호 배제를 위해 병행 사용되어야 함.
COW (Copy-on-Write)	`MAP_PRIVATE`로 매핑 시 적용되며, 쓰기 시에만 개별 물리 프레임을 복사하는 기법으로 `MAP_SHARED`와 대비됨.

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

mmap()은 두 사람이 같은 그림책(물리 페이지)을 각자의 책상 위에 펼쳐놓고 동시에 보는 마법의 거울을 만들어주는 시스템이에요.
MAP_SHARED라고 말하면 한쪽에서 그림을 수정하면 다른 쪽의 거울에도 즉시 반영되어, 책을 복사해서 전해줄 필요가 없어요.
하지만 두 사람이 동시에 같은 페이지에 그림을 그리면 엉망이 되니까, 돌아가면서 그릴 수 있게 순서표(세마포어)를 반드시 함께 사용해야 해요!