주요 IPC 메커니즘은 무엇이며, 각각 언제 쓰는가?

Question

IT Interview Practice · Accepted Answer

각 프로세스는 **격리된 주소 공간**을 갖기 때문에, 변수를 그냥 공유할 수 없다 — **프로세스 간 통신(inter-process communication, IPC)**이 필요하다. OS는 속도, 방향, 그리고 머신을 넘어 동작하는지 여부가 다른 여러 메커니즘을 제공한다.

## 주요 메커니즘

```text
Pipe / FIFO      → byte stream, one direction; anonymous pipe = parent↔child, named FIFO = any procs
                   e.g.  ls | grep foo   (the shell wires stdout→stdin via a pipe)
Shared memory    → both map the SAME physical pages → FASTEST (no copy), but you must
                   synchronize access yourself (semaphore/mutex)
Message queue    → kernel-managed queue of discrete messages; decoupled, preserves boundaries
Socket           → bidirectional stream/datagram; UNIX-domain (same host) or TCP/UDP (across network)
Signal           → tiny async notification (a number), e.g. SIGINT, SIGTERM — control, not data transfer
```

## 하나 고르기

- **Pipe** — 단순한 단방향 byte stream. shell 파이프라인과 parent/child 배관의 근간.
- **Shared memory** — **높은 throughput / 낮은 latency**가 필요할 때(예: 데이터베이스의 shared buffer). 데이터가 kernel을 통해 복사되지 않아 가장 빠르다 — 하지만 동기화를 *전혀* 제공하지 않으므로 semaphore와 함께 짝지어 쓴다.
- **Message queue** — 경계가 보존되고 느슨하게 결합된 **개별 메시지**를 원할 때.
- **Socket** — 가장 유연하다: 같은 호스트의 **UNIX-domain socket**은 빠르고, TCP/UDP socket은 **머신을 넘어서도** 동작하므로 네트워크 서비스가 이를 쓴다.
- **Signal** — **제어(control)** 이벤트(인터럽트, 종료, 자식 프로세스 종료)용이지 데이터 이동용이 아니다.

```text
        copy through kernel                          no copy
  slower ◀─────────────────────────────────────────────▶ faster
  socket / message queue / pipe            shared memory (+ your own locking)
```

## 왜 중요한가

IPC 선택은 시스템의 아키텍처와 성능을 좌우한다. 면접관은 당신이 메커니즘을 필요에 맞추는지 보고 싶어 한다: 순수 속도에는 shared memory(동기화 부담을 감수), 유연성과 네트워크 투명성에는 socket, 단순 스트리밍에는 pipe, 제어에는 signal. 이는 shell 파이프라인, 멀티 프로세스 웹 서버, 데이터베이스의 shared buffer, 또는 마이크로서비스가 실제로 어떻게 서로 대화하는지 이해하는 토대다.

주요 메커니즘

하나 고르기

왜 중요한가

관련 질문