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

파이프 사용 예시

부모가 자식에게 데이터를 보내는 전형적인 파이프 코드는 다음과 같다. 파이프는 읽기용과 쓰기용 파일 디스크립터 한 쌍으로 만들어지고, fork 이후 각자가 쓰지 않는 쪽 끝을 닫는 것이 관례다. 파이프는 커널 안의 고정 크기 버퍼로 구현되어 있어서, 버퍼가 가득 차면 쓰는 쪽이 블로킹(blocking)되고 버퍼가 비면 읽는 쪽이 블로킹된다. 이 흐름 제어 덕분에 생산 속도와 소비 속도가 달라도 자연스럽게 조율되며, 셸 파이프라인에서 빠른 명령이 느린 명령을 기다리게 되는 이유이기도 하다. 쓰기 끝이 모두 닫힌 파이프에서 read는 0을 반환해 EOF를 알리고, 읽기 끝이 닫힌 파이프에 write하면 SIGPIPE 시그널을 받는다.

int fd[2];
pipe(fd);                 // fd[0]: 읽기, fd[1]: 쓰기
pid_t pid = fork();
if (pid == 0) {           // 자식: 읽는 쪽
    close(fd[1]);
    char buf[128];
    ssize_t n = read(fd[0], buf, sizeof(buf));
    // n 바이트 처리
} else {                  // 부모: 쓰는 쪽
    close(fd[0]);
    write(fd[1], "hello", 5);
    close(fd[1]);         // 닫으면 자식의 read가 0(EOF)을 받는다
}

선택 기준과 실무 감각

기법 선택은 몇 가지 질문으로 정리된다. 통신 상대가 같은 머신에 있는가, 데이터가 스트림인가 메시지 단위인가, 처리량이 중요한가 지연이 중요한가, 상대 프로세스와 생성 관계가 있는가다. 같은 호스트의 서비스 간 통신에는 유닉스 도메인 소켓이 TCP 루프백보다 오버헤드가 적어 널리 쓰이고(도커 데몬의 소켓이 대표적이다), 고성능 데이터 교환에는 공유 메모리 위에 링 버퍼(ring buffer)를 얹는 구조가 흔하다. 분산 환경이라면 결국 네트워크 소켓 위의 gRPC나 메시지 브로커 같은 상위 프로토콜로 올라가게 된다. 스레드 간 통신과 달리 IPC는 커널 경유 비용이나 매핑 관리가 따르므로, 애초에 프로세스 분리가 필요한지부터 따지는 것이 설계의 출발점이다.

면접에서 이렇게 물어본다

• 공유 메모리 방식과 메시지 전달 방식의 장단점을 복사 비용과 동기화 관점에서 비교해 보라.
• 익명 파이프와 명명 파이프의 차이는 무엇이고 각각 언제 쓰는가.
• 공유 메모리를 쓸 때 별도의 동기화 도구가 반드시 필요한 이유를 설명해 보라.
• 같은 호스트의 두 데몬이 통신할 때 유닉스 도메인 소켓이 TCP 루프백보다 유리한 점은 무엇인가.
• 셸에서 명령어 A | B 를 실행하면 내부적으로 어떤 IPC가 어떻게 구성되는지 설명해 보라.