117. 프로세스 간 통신 (IPC, Inter-Process Communication)

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

본질: IPC (Inter-Process Communication)는 서로 독립적인 주소 공간을 가진 프로세스 간에 데이터를 교환하고 상태를 동기화하기 위해 운영체제가 제공하는 통신 인프라이며, 핵심 모델로 공유 메모리 (Shared Memory)와 메시지 전달 (Message Passing) 두 가지가 존재한다.

가치: 공유 메모리는 커널 개입 없이 직접 메모리에 접근하므로 속도가 빠르지만 동기화가 복잡하고, 메시지 전달은 커널이 데이터를 중개하므로 안전하고 구현이 단순하지만 커널 모드 전환 오버헤드가 발생한다. 이 두 모델의 트레이드오프 이해가 시스템 설계의 핵심이다.

융합: POSIX IPC(System V 메시지 큐, 세마포어, 공유 메모리), 파이프(Pipe), 소켓(Socket), 그리고 현대의 gRPC, Apache Kafka 같은 분산 메시지 브로커까지, IPC의 기본 원리는 단일 머신에서 클라우드 규모의 분산 시스템까지 모든 통신의 기반이 된다.

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

개념: IPC (Inter-Process Communication, 프로세스 간 통신)는 서로 다른 주소 공간(Address Space)을 가진 프로세스 간에 데이터를 주고받거나 동기화 상태를 공유하기 위한 운영체제의 메커니즘이다. 현대 운영체제는 프로세스마다 독립적인 가상 메모리 공간을 할당하므로, 프로세스 A가 프로세스 B의 메모리에 직접 접근하는 것은 하드웨어 수준(MMU)에서 원천적으로 차단된다. IPC는 이 메모리 격리를 우회하거나 우회하지 않고 안전하게 통신하는 유일한 수단이다.
필요성: 현대 소프트웨어 시스템은 거의 예외 없이 다중 프로세스 구조로 동작한다. 웹 브라우저는 렌더러, 네트워크, GPU 프로세스로 분리되어 있고, 데이터베이스는 클라이언트 프로세스와 서버 프로세스가 통신하며, 운영체제 셸은 파이프라인을 통해 명령어 프로세스 간에 데이터를 전달한다. 이 모든 통신이 IPC 없이는 단 한 건도 이루어질 수 없다.
💡 비유: IPC는 완전히 벽으로 막힌 방에 있는 두 사람이 서로 물건을 전달하기 위해, 벽에 설치된 우편함(메시지 전달)이나 벽 사이의 통로(공유 메모리)를 사용하는 것과 같습니다.
등장 배경: 초기 유닉스 시스템에서는 Ken Thompson이 1973년 파이프 (Pipe)를 발명하여 프로세스 간의 단방향 바이트 스트림 통신을 실현했다. 이후 AT&T Bell Labs의 System V에서 메시지 큐, 공유 메모리, 세마포어를 포함하는 System V IPC가 개발되었고, IEEE의 POSIX 표준위원회가 이를 표준화하여 오늘날의 POSIX IPC 규격이 확립되었다. 네트워크 통신이 보편화되면서 BSD 소켓 (Socket)도 IPC의 중요한 수단으로 자리 잡았다.

IPC의 두 가지 근본 모델인 공유 메모리와 메시지 전달의 구조적 차이를 시각화하면, 각 모델이 왜 다른 설계 철학을 가지는지 이해할 수 있다.

┌────────────────────────────────────────────────────────────────────┐
│         IPC의 두 가지 근본 모델: 공유 메모리 vs 메시지 전달        │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  [공유 메모리 (Shared Memory)]                                     │
│                                                                    │
│  ┌───────────┐     ┌─────────────────────────┐                     │
│  │ 프로세스 A │     │                         │                    │
│  │ 주소 공간  │     │   ┌───────────────────┐ │                    │
│  │           │     │   │   공유 메모리 영역  │ │                   │
│  │           │────▶│   │   (동일 물리 페이지  │ │◀────┐            │
│  │           │     │   │    매핑됨)         │ │     │              │
│  └───────────┘     │   └───────────────────┘ │     │               │
│                     │         ▲ 커널           │     │             │
│                     │   (초기 설정만 관여)      │     │            │
│                     └─────────┼───────────────┘     │              │
│                               │                     │              │
│  ┌───────────┐                 │               ┌────┴────┐         │
│  │ 프로세스 B │─────────────────┘               │프로세스 B │      │
│  │ 주소 공간  │                                 │주소 공간 │       │
│  └───────────┘                                 └─────────┘         │
│                                                                    │
│  장점: 커널 개입 없이 직접 접근 → 매우 빠름                        │
│  단점: 동기화(뮤텍스 등)이 사용자가 직접 구현해야 함               │
│                                                                    │
│  ─────────────────────────────────────────────                     │
│                                                                    │
│  [메시지 전달 (Message Passing)]                                   │
│                                                                    │
│  ┌───────────┐  send()  ┌─────────┐  recv()  ┌───────────┐         │
│  │ 프로세스 A │────────▶│  커널   │────────▶│ 프로세스 B │         │
│  │ (송신자)   │         │ 메시지  │         │ (수신자)   │         │
│  └───────────┘         │ 버퍼   │         └───────────┘            │
│                        └─────────┘                                 │
│                                                                    │
│  장점: 커널이 중개 → 동기화 불필요, 안전함                         │
│  단점: 매 전송마다 커널 모드 전환 → 오버헤드 발생                  │
└────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 구조도는 IPC의 두 가지 근본 모델이 데이터를 어떻게 교환하는지를 명확히 보여준다. 공유 메모리 모델에서는 두 프로세스의 가상 주소 공간 일부가 동일한 물리 메모리 페이지에 매핑된다. 따라서 프로세스 A가 공유 영역에 데이터를 쓰면 프로세스 B가 즉시 읽을 수 있다(커널 개입 없이). 하지만 두 프로세스가 동시에 같은 메모리 위치에 접근하면 데이터 일관성이 깨지므로, 개발자가 뮤텍스나 세마포어로 동기화를 직접 구현해야 한다. 반면 메시지 전달 모델에서는 프로세스가 커널에 메시지를 보내고(send 시스템 콜), 커널이 이를 버퍼에 저장한 뒤 수신자에게 전달한다(recv 시스템 콜). 모든 통신이 커널을 경유하므로 안전하고 동기화가 자동으로 보장되지만, 매 시스템 콜마다 유저 모드-커널 모드 전환이 발생하여 오버헤드가 크다.

📢 섹션 요약 비유: 공유 메모리는 두 집이 벽을 허물고 하나의 거실을 같이 쓰는 것(빠르지만 질서 유지가 필수)이고, 메시지 전달은 우체부(OS)가 편지를 배달해 주는 것(안전하지만 배달 시간이 걸림)과 같습니다.

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

IPC 기법 분류

IPC 기법	통신 모델	방향성	대상 범위	커널 개입	대표 용도
파이프 (Pipe)	메시지 전달	단방향	부모-자식 프로세스	있음 (버퍼 관리)	셸 파이프라인 (cmd1 \| cmd2)
이름 있는 파이프 (FIFO/Named Pipe)	메시지 전달	단방향	관련 없는 프로세스	있음	로그 수집 시스템
메시지 큐 (Message Queue)	메시지 전달	양방향	관련 없는 프로세스	있음	작업 큐, 이벤트 버스
공유 메모리 (Shared Memory)	공유 메모리	양방향	관련 없는 프로세스	최소 (초기 설정만)	고속 데이터 교환
소켓 (Socket)	메시지 전달	양방향	동일/원격 머신	있음	네트워크 통신
시그널 (Signal)	메시지 전달	단방향	관련/무관 프로세스	있음	프로세스 제어, 예외 통지

POSIX IPC와 System V IPC

IPC 기법은 크게 POSIX 표준과 System V 표준으로 나뉜다. 두 표준의 비교와 발전 과정을 시각화하면, IPC 기술의 진화 방향을 이해할 수 있다.

┌─────────────────────────────────────────────────────────────────────┐
│            POSIX IPC vs System V IPC 비교                           │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌─────────────────────┐    ┌─────────────────────────┐             │
│  │  System V IPC       │    │  POSIX IPC              │             │
│  │  (AT&T Bell Labs)   │    │  (IEEE 표준)            │             │
│  ├─────────────────────┤    ├─────────────────────────┤             │
│  │  msgget/msgsnd/     │    │  mq_open/mq_send/      │              │
│  │  msgrcv (메시지 큐) │    │  mq_receive (메시지 큐) │             │
│  │                     │    │                         │             │
│  │  shmget/shmat/      │    │  shm_open/mmap          │             │
│  │  shmdt (공유 메모리) │    │  (공유 메모리)          │            │
│  │                     │    │                         │             │
│  │  semget/semop       │    │  sem_open/sem_wait/     │             │
│  │  (세마포어)         │    │  sem_post (세마포어)     │            │
│  ├─────────────────────┤    ├─────────────────────────┤             │
│  │  식별자: 정수 (ID)  │    │  식별자: 파일 디스크립터 │            │
│  │  API: 독자적, 복잡  │    │  API: 파일 I/O와 통일   │             │
│  │  이식성: 낮음        │    │  이식성: 높음           │            │
│  │  우선순위: 지원 안함│    │  우선순위: 지원          │            │
│  │  통지: 없음         │    │  통지: sigev_notify 지원│             │
│  └─────────────────────┘    └─────────────────────────┘             │
│                                                                     │
│  진화 방향: System V → POSIX (더 나은 이식성과 통합성)              │
│  최신 동향: 파일 디스크립터 기반 통일 API로 수렴                    │
└─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] System V IPC와 POSIX IPC는 기능적으로 유사하지만 설계 철학에서 결정적 차이가 있다. System V IPC는 독자적인 정수 식별자(ID)와 전용 API(msgget, shmget, semget)를 사용하므로, 기존 파일 디스크립터(File Descriptor) 기반 I/O와 통합되지 않는다. 반면 POSIX IPC는 파일 디스크립터를 식별자로 사용하므로, select(), poll(), epoll() 같은 기존 I/O 다중화 함수와 자연스럽게 통합된다. 또한 POSIX 메시지 큐는 우선순위 기반 전송과 비동기 통지(sigev_notify)를 지원하여, 실시간 시스템(POSIX.1b 실시간 확장)에서 더 강력한 기능을 제공한다. 이러한 이유로 최신 리눅스 시스템에서는 POSIX IPC를 권장하며, System V IPC는 레거시 호환성을 위해 유지된다.

메시지 전달의 두 가지 방식: 동기 vs 비동기

메시지 전달 모델은 송수신의 동기화 방식에 따라 차단형 (Blocking)과 비차단형 (Non-blocking)으로 나뉜다. 또한 메시지 버퍼의 관리 방식에 따라 직접 전달 (Direct)과 간접 전달 (Indirect/Queue)으로 구분된다.

📢 섹션 요약 비유: System V IPC는 옛날 특수 우편 시스템(전용 번호, 전용 창구) 같고, POSIX IPC는 기존 우체국(파일 디스크립터)과 통합된 현대적인 시스템과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

공유 메모리 vs 메시지 전달 심층 비교

비교 항목	공유 메모리 (Shared Memory)	메시지 전달 (Message Passing)	실무 판단 포인트
통신 속도	매우 빠름 (커널 개입 없음)	느림 (커널 모드 전환 매번 발생)	대량 데이터 전송 빈도
동기화 필요성	필수 (뮤텍스, 세마포어 필요)	불필요 (커널이 버퍼 관리)	개발 복잡도 수용 여부
데이터 보호	직접 접근으로 오염 위험	커널이 검증하므로 안전	데이터 무결성 요구 수준
구현 복잡도	높음 (동기화 로직 직접 구현)	낮음 (send/recv만 사용)	팀의 동시성 프로그래밍 역량
커널 의존도	낮음 (초기 설정 이후 독립)	높음 (매 통신마다 커널 개입)	실시간 응답 요구 여부

두 모델의 성능 특성을 데이터 크기에 따라 시각화하면, 어떤 상황에서 어떤 모델을 선택해야 하는지 판단 기준이 명확해진다.

┌───────────────────────────────────────────────────────────────────┐
│     IPC 모델별 데이터 크기에 따른 성능 비교 (개념도)              │
├───────────────────────────────────────────────────────────────────┤
│                                                                   │
│  지연(Latency)                                                    │
│    ▲                                                              │
│    │  메시지 전달 ────────┬───────────────────────                │
│    │                    │                                         │
│    │                    │  (데이터 크기가 클수록 복사 비용        │
│    │                    │   커널 버퍼 ↔ 유저 버퍼 증가)           │
│    │                    │                                         │
│    │  공유 메모리 ────┐  │                                        │
│    │                │  │                                          │
│    │   (고정 비용:    │  │                                        │
│    │    매핑 설정만)  │  │                                        │
│    └────────────────┼──┼──────────────────────────▶               │
│                데이터 크기 (Bytes)                                │
│                                                                   │
│  ┌────────────────────────────────────────────────────────┐       │
│  │ 실무 선택 가이드:                                       │      │
│  │                                                        │       │
│  │  소량 데이터 (< 1KB):     메시지 전달이 간편하고 충분    │     │
│  │  중량 데이터 (> 1MB):     공유 메모리가 압도적으로 빠름    │   │
│  │  초소량 (플래그 등):      시그널이나 이벤트fd가 최적      │    │
│  └────────────────────────────────────────────────────────┘       │
└───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 성능 비교 그래프는 IPC 모델 선택의 핵심 기준이 되는 데이터 크기와 지연(Latency)의 관계를 보여준다. 공유 메모리의 지연은 데이터 크기에 관계없이 거의 일정하다. 왜냐하면 초기에 shmget()/shmat()로 메모리 매핑을 설정한 이후에는, 프로세스가 메모리에 직접 접근하는 일반적인 포인터 연산과 동일하기 때문이다. 반면 메시지 전달의 지연은 데이터 크기에 비례하여 선형적으로 증가한다. 왜냐하면 send() 호출 시 유저 버퍼에서 커널 버퍼로 데이터를 복사하고, recv() 호출 시 다시 커널 버퍼에서 유저 버퍼로 복사하는 두 번의 메모리 복사가 매번 발생하기 때문이다. 따라서 소량의 제어 메시지를 주고받는 용도에서는 메시지 전달이 간편하고 충분하지만, 비디오 프레임이나 대규모 데이터 배열 같은 중량 데이터를 교환할 때는 공유 메모리가 압도적으로 유리하다.

과목 융합 관점

컴퓨터 네트워크 (CN): IPC의 메시지 전달 모델은 네트워크 통신의 TCP/IP 모델과 구조적으로 동일하다. 로컬 파이프는 TCP 연결의 단일 머신 버전이고, 소켓은 네트워크 IPC의 표준 인터페이스다. 두 환경 모두에서 흐름 제어(Flow Control), 혼잡 제어(Congestion Control), 순서 보장(Ordering)이 핵심 설계 요구사항이다.
분산 컴퓨팅 (DC): Apache Kafka, RabbitMQ, NATS 같은 현대 메시지 브로커는 IPC의 메시지 전달 모델을 클러스터 규모로 확장한 것이다. 로컬 메시지 큐의 pub-sub 패턴이 분산 시스템의 이벤트 드리븐 아키텍처(Event-Driven Architecture)로 진화한 결과다.
📢 섹션 요약 비유: 편지(메시지 전달)는 소포(데이터 크기)가 작을 때는 편리하지만, 가구(대량 데이터)를 보낼 때는 이웃집 벽을 뚫고 직접 가져다 놓는(공유 메모리) 것이 훨씬 효율적입니다.

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

실무 시나리오

시나리오 -- 고빈도 금융 거래 시스템의 IPC 선택: 초당 100만 건 이상의 시장 데이터(Tick Data)를 수신 프로세스에서 분석 프로세스로 전달해야 하는 고빈도 거래 (HFT, High-Frequency Trading) 시스템.
- 판단: 마이크로초(us) 단위의 지연이 거래 수익에 직결되는 HFT 환경에서는 메시지 전달의 커널 개입 오버헤드(매건당 약 1~10us)가 치명적이다. 공유 메모리에 시장 데이터를 기록하고, 분석 프로세스가 직접 읽는 구조를 채택해야 한다. 동기화는 락 프리(Lock-free) 큐(예: CAS 기반 링 버퍼)를 사용하여 뮤텍스의 오버헤드마저 제거하는 것이 현대 HFT의 표준 아키텍처이다.
시나리오 -- 마이크로서비스 간 비동기 통신: 주문 서비스와 재고 서비스가 각각 독립 컨테이너에서 실행되며, 주문 완료 시 재고를 차감해야 하는 전자상거래 백엔드 시스템.
- 판단: 프로세스가 물리적으로 다른 머신에 분산될 수 있으므로 공유 메모리를 사용할 수 없다. 메시지 큐(예: Apache Kafka, RabbitMQ)를 사용하여 주문 서비스가 '주문 완료' 이벤트를 발행(Publish)하고, 재고 서비스가 이를 구독(Subscribe)하는 pub-sub 패턴을 적용해야 한다. 이벤트 기반 비동기 통신은 서비스 간 결합도(Coupling)를 낮추고 장애 격리를 보장한다.

도입 체크리스트

기술적: IPC 통신이 성능 병목이 아닌지 프로파일링했는가? 대량 데이터 전송 시 커널 버퍼 복사 오버헤드를 측정하여 공유 메모리 전환을 검토했는가?
운영·보안적: IPC 채널(파이프, 큐, 공유 메모리)의 접근 권한이 최소 권한 원칙(Least Privilege)에 따라 설정되어 있는가? System V IPC 객체가 시스템 재부팅 후에도 남아있지 않도록(IPCRM 정리) 관리 절차가 있는가?
📢 섹션 요약 비유: 우체국(메시지 전달)이 붐빌 때는 직접 전달(공유 메모리)로 전환하되, 우편물을 도난당하지 않도록 보안 시스템(동기화, 접근 제어)을 반드시 설치해야 합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	메시지 전달만 사용	공유 메모리 도입 (대량 데이터)	개선 효과
정량 (전송 지연)	1MB당 약 50~200us (커널 복사 2회)	1MB당 약 0.1us (직접 접근)	지연 500배 이상 단축
정량 (CPU 사용률)	커널 모드 전환으로 CPU 점유 증가	유저 모드에서만 동작	CPU 오버헤드 70% 이상 감소
정성 (안전성)	커널이 검증하여 자동 보장	개발자가 동기화 직접 구현 필수	메시지 전달이 개발 난이도 우위

미래 전망

io_uring에 의한 커널 개입 최소화: 리눅스 5.1부터 도입된 io_uring은 시스템 콜 오버헤드를 극적으로 줄여, 메시지 전달 모델의 성능을 공유 메모리에 근접하게 끌어올리고 있다. 커널-유저 간 데이터 복사를 회피하는 고정 버퍼(Fixed Buffer)와 제출 완료 큐(Completion Queue)를 통해 비동기 메시지 전달이 효율화되고 있다.
원격 공유 메모리 (RDMA, CXL): RDMA (Remote Direct Memory Access)와 CXL (Compute Express Link) 기술이 발전하면서, 네트워크를 경유하더라도 타 머신의 메모리를 로컬 메모리처럼 직접 접근할 수 있게 되고 있다. 이는 IPC의 공유 메모리 모델을 분산 환경으로 확장하는 혁신적인 접근이다.

참고 표준

POSIX.1 (IEEE 1003.1): 파이프, FIFO, 메시지 큐, 공유 메모리, 세마포어의 표준 API 규격.
System V IPC (AT&T): msgget, shmget, semget 계열의 레거시 IPC API.
Linux io_uring (2019~): 시스템 콜 오버헤드를 최소화하는 차세대 비동기 I/O/IPC 인터페이스.
📢 섹션 요약 비유: IPC 기술은 편지(파이프)에서 우편함(메시지 큐)을 거쳐 공용 창고(공유 메모리)로 진화해 왔으며, 앞으로는 우주 통신(RDMA)처럼 거리의 한계를 뛰어넘는 방향으로 발전하고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
공유 메모리 (Shared Memory)	IPC의 가장 빠른 방식으로, `shmget()/shmat()` 또는 `mmap()`을 통해 구현되며 동기화 도구와 반드시 함께 사용되어야 한다.
파이프 (Pipe) 및 FIFO	단방향 바이트 스트림 기반의 IPC로, Unix 철학의 "모든 것은 파일" 원칙을 따르며 셸 파이프라인의 근간이 된다.
메시지 큐 (Message Queue)	구조화된 메시지를 큐에 저장하는 IPC로, 파이프와 달리 메시지 경계를 유지하고 우선순위를 지원한다.
소켓 (Socket)	네트워크 통신을 위한 IPC로, 로컬 IPC(UNIX 도메인 소켓)와 원격 통신(TCP/IP 소켓)을 모두 지원하는 범용 인터페이스다.
소프트웨어 동기화 (Mutex/Semaphore)	공유 메모리 기반 IPC에서 데이터 일관성을 보장하기 위해 필수적으로 요구되는 동기화 도구다.

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

IPC는 벽으로 완전히 막힌 두 방에 있는 친구들이 서로 물건을 주고받기 위해, 벽에 만든 우편구멍(메시지 전달)이나 벽 사이에 만든 통로(공유 메모리)와 같아요.
우편구멍(메시지 전달)은 우체부(OS)가 편지를 안전하게 배달해 주어 편하지만 배달 시간이 걸리고, 통로(공유 메모리)는 직접 물건을 주고받아 빠르지만 누가 먼저 가져갈지 규칙을 정해야 해요.
요즘은 이 두 가지 방법을 잘 섞어서 쓰는데, 중요한 연락은 우편구멍으로 안전하게 보내고, 큰 짐은 통로로 빠르게 나눠 가져가는 것이 현대 컴퓨터 시스템의 지혜랍니다!