IPC(Inter-Process Communication)란? 프로세스들의 대화법, IPC의 세계

우리는 지금까지 커널, systemd, 부트로더 등 시스템의 근간을 이루는 요소를 배웠습니다.
systemd가 수많은 프로세스(서비스, 애플리케이션)를 실행하면, 우리의 AVN 시스템은 비로소 생명을 얻게 됩니다.

그런데 여기서 중요한 질문이 생깁니다.
내비게이션 앱은 경로 안내 음성을 내보내기 위해 오디오 서비스에게 어떻게 말을 걸어야 할까요?
미디어 플레이어는 현재 재생 중인 곡 정보를 홈스크린 UI에 어떻게 알려줄 수 있을까요?

이들은 모두 별개의 집(독립된 메모리 공간)에 사는 별개의 프로세스입니다.
옆집에 소리를 질러도 들리지 않는 것처럼, 한 프로세스는 다른 프로세스의 메모리를 직접 들여다보거나 함수를 호출할 수 없습니다.
바로 이 '소통의 장벽'을 넘기 위해 운영체제가 제공하는 공식적인 대화 채널이 바로 IPC(Inter-Process Communication, 프로세스 간 통신)입니다.

---

Part 1. 왜 IPC가 필요한가? - 고독한 프로세스의 섬

IPC를 배우기 전에, 왜 프로세스들이 서로 대화하기 어려운지 다시 한번 짚어봐야 합니다.
커널 포스팅에서 다뤘듯이, 커널은 시스템의 안정성을 위해 각 프로세스에게 독립된 가상 메모리 공간을 할당합니다.

이는 하나의 앱이 비정상적으로 종료되어도 다른 앱이나 시스템 전체에 영향을 주지 않도록 보호하는 매우 중요한 '격리' 기능입니다.
하지만 이 격리 정책 때문에 모든 프로세스는 기본적으로 자기 자신만의 데이터만 보고 수정할 수 있는 '고독한 섬'이 됩니다.

따라서 이 섬들이 서로 정보를 교환하려면, 섬들을 관리하는 유일한 주체인 커널(운영체제)에게 중재를 요청해야 합니다.
모든 IPC 기법은 이처럼 커널이 제공하는 통신 인프라를 통해 이루어집니다.

비유: 두꺼운 벽으로 막힌 집들 사이의 소통법

• 프로세스: 각자의 집
• 메모리 공간: 집 내부 공간
• 커널: 도시의 모든 인프라(우체국, 전화국, 공용 게시판)를 관리하는 시청

옆집 사람과 대화하기 위해 벽에 대고 소리칠 수는 없습니다. 대신 시청이 마련한 우체국(메시지 큐)을 이용해 편지를 보내거나, 전화국(소켓)을 통해 통화하거나, 마을 회관의 공용 게시판(공유 메모리)에 글을 남겨야 합니다. IPC는 바로 이런 통신 방법들의 모음입니다.

---

Part 2. 전통적인 IPC 기법들

오랫동안 유닉스 계열 시스템에서 사용되어 온 전통적인 IPC 기법들입니다. 각각의 장단점과 용도가 명확합니다.

1. 공유 메모리 (Shared Memory): 가장 빠른 소통법

• 개념: 커널에게 요청하여, 여러 프로세스가 동시에 접근할 수 있는 공용 메모리 공간을 할당받는 방식입니다.
• 비유: 여러 집에서 함께 사용하는 '마을 회관 공용 게시판'. 누군가 게시판에 글을 쓰면, 다른 모든 사람이 즉시 그 내용을 볼 수 있습니다. 데이터를 커널을 통해 주고받는 '복사' 과정이 없으므로, IPC 기법 중 속도가 압도적으로 빠릅니다.
• 장점: 비교할 수 없을 정도로 빠른 속도. 대용량 데이터를 주고받을 때 가장 효율적입니다. (예: 카메라 센서 프로세스가 받은 영상 프레임을 화면 출력 프로세스에 전달할 때)
• 단점: 동기화 문제. 여러 사람이 동시에 게시판의 같은 위치에 글을 쓰려고 하면 내용이 엉망이 되겠죠? 이처럼 여러 프로세스가 동시에 공유 메모리에 접근하면 데이터가 깨질 수 있습니다(Race Condition).
  따라서 개발자는 세마포어(Semaphore)나 뮤텍스(Mutex) 같은 '잠금(Lock)' 장치를 사용해 "지금은 나만 쓸게!"라고 명시하는 복잡한 동기화 코드를 직접 구현해야 합니다.

2. 메시지 큐 (Message Queue): 우체통을 이용한 소통법

• 개념: 커널이 관리하는 메시지(데이터 조각)들의 연결 리스트(큐)를 통해 통신합니다.
  프로세스는 이 큐에 메시지를 넣거나(send), 큐에서 메시지를 빼올 수(receive) 있습니다.
• 비유: '마을 우체통'. 보내는 사람은 받는 사람 주소와 함께 편지를 우체통에 넣기만 하면 됩니다.
  받는 사람은 나중에 우체통에서 자기 앞으로 온 편지를 꺼내 읽습니다. 보내는 시점과 받는 시점이 달라도 괜찮습니다.
• 장점: 비동기 방식에 적합하며, 여러 프로세스가 하나의 큐를 통해 통신할 수 있습니다.
  메시지에 '타입'을 부여하여 원하는 종류의 메시지만 골라서 읽을 수도 있습니다.
• 단점: 주고받는 데이터의 크기에 제한이 있으며, 공유 메모리보다는 느립니다.

3. 파이프 (Pipe) & 소켓 (Socket): 1:1 전화 통화

• 개념: 두 프로세스 사이에 데이터가 흐를 수 있는 통로(Stream)를 만들어 통신합니다.
• 파이프(Pipe): 부모-자식 프로세스처럼 연관된 프로세스 간 단방향 통신에 주로 사용됩니다.
  쉘에서 사용하는 | 기호가 바로 익명 파이프(Anonymous Pipe)입니다. (예: ls -l | grep "test")
• 소켓(Socket): 네트워크 통신을 위해 태어났지만, 같은 시스템 내의 프로세스 간 통신(이를 Unix Domain Socket이라 함)에도 널리 사용됩니다.
  양방향 통신이 가능하며, 전혀 관계 없는 프로세스끼리도 통신할 수 있습니다.
• 비유: '1:1 전화선'. 한번 연결되면 두 프로세스가 자유롭게 양방향으로 데이터를 주고받을 수 있습니다.
• 장점: 실시간 스트림 데이터 교환에 적합합니다. 비교적 구현이 간단합니다.
• 단점: 대규모의 다자간 통신 구조를 만들기에는 복잡합니다.

---

Part 3. 현대 임베디드 시스템의 총아, D-Bus

전통적인 IPC들은 강력하지만, AVN처럼 수십 개의 서비스와 앱이 복잡하게 얽혀 상호작용하는 시스템을 만들기에는 부족함이 있었습니다.
그래서 등장한 것이 바로 D-Bus(Desktop Bus)입니다.

D-Bus는 단순한 통신 채널을 넘어, 객체 지향적인 개념을 도입한 고수준의 메시지 버스 시스템입니다.

비유: 체계적인 '사내 메신저 시스템'

D-Bus는 단순한 전화나 우편이 아니라, 잘 설계된 사내 메신저와 같습니다.

• D-Bus 데몬 (메신저 서버): 모든 메시지를 중개하고 라우팅합니다.
• 메서드 호출 (1:1 대화): 내비게이션 팀원이 오디오 팀원에게 "음악 잠시 멈춰줘" 라고 말을 걸고 응답을 받습니다.
• 시그널 (전체 공지): 미디어 플레이어 팀이 "새로운 노래 재생 시작!" 이라고 전체 공지를 띄우면, 관심 있는 팀(홈스크린 UI 팀 등)은 이 공지를 보고 각자 할 일을 합니다.

D-Bus 통신의 핵심 개념은 다음과 같습니다.

• 메서드 호출 (Method Call): 특정 프로세스의 특정 객체(Object)가 제공하는 함수(Method)를 원격으로 호출하는 방식. (RPC, Remote Procedure Call)
  • 예시: NaviApp이 MediaPlayer의 Pause() 메서드를 호출합니다.
• 시그널 (Signal): 특정 프로세스에서 발생한 이벤트(사건)를 버스에 연결된 모든 프로세스에게 방송(Broadcast)하는 방식.
  • 예시: MediaPlayer가 TrackChanged 시그널을 새로운 곡 정보와 함께 발생시키면, 이 시그널을 구독하고 있던 HomeScreenUI가 정보를 받아 화면을 갱신합니다.

AVN 시스템에서 D-Bus가 사랑받는 이유:

1. 느슨한 결합(Loose Coupling): 각 서비스는 서로의 내부를 알 필요 없이, 약속된 D-Bus 인터페이스를 통해 통신합니다.
   덕분에 미디어 플레이어를 통째로 바꿔도, 홈스크린 UI 코드는 수정할 필요가 없습니다.
2. 체계적인 구조: '메서드', '시그널' 같은 명확한 개념 덕분에 복잡한 상호작용을 체계적으로 설계할 수 있습니다.
3. 보안: 어떤 프로세스가 어떤 메서드를 호출할 수 있는지 등 권한 관리가 가능합니다.
4. 언어 독립성: C, C++, Python 등 어떤 언어로 만들어진 서비스든 D-Bus를 통해 서로 대화할 수 있습니다.

IPC 기법	속도	복잡도	주요 사용처 (AVN 예시)
파일	느림	낮음	시스템 부팅 시 읽는 설정 값 저장
공유 메모리	매우 빠름	높음 (동기화 필요)	카메라 영상 프레임 데이터 공유
소켓	보통	중간	간단한 1:1 서비스 간 데이터 스트리밍
D-Bus	보통	중간	대부분의 서비스 간 상호작용 (상태 알림, 기능 요청)

정리하며

오늘은 고립된 프로세스들이 서로 대화하는 방법, IPC에 대해 알아보았습니다.

• 프로세스는 커널에 의해 메모리가 격리되어 있어, 소통을 위해 IPC가 반드시 필요합니다.
• 공유 메모리는 가장 빠르지만 동기화의 어려움이 있고, 메시지 큐나 소켓은 특정 상황에서 유용하게 사용됩니다.
• D-Bus는 현대적인 AVN 시스템에서 서비스 간의 복잡한 상호작용을 체계적으로 관리하기 위한 사실상의 표준 IPC입니다.