파이프 방식의 IPC

 

🧩 1회차: 프로그램 A가 B에게 데이터를 보내기까지 – Windows IPC 구조의 공통 기반

---

1️⃣ 왜 프로그램 A는 프로그램 B에게 데이터를 보내야 했을까?

어떤 운영체제든, 실행 중인 프로그램들은 보통 자기 할 일을 알아서 처리합니다.
하지만 때로는 한 프로그램이 다른 프로그램에게 일을 시키거나, 결과를 전달하거나, 협력해야 하는 상황이 생깁니다.

예를 들어 이런 상황을 생각해볼 수 있습니다.

• 프로그램 A는 온도 센서에서 측정값을 읽어오는 역할을 합니다.
• 프로그램 B는 그 값을 화면에 보여주는 역할을 합니다.

이 두 프로그램은 서로 독립적으로 실행되고 있지만,
A가 수집한 데이터를 B가 반드시 알아야 전체 시스템이 의도한 대로 작동할 수 있습니다.

하지만 문제는,
운영체제는 각 프로그램을 완전히 분리된 공간에서 실행시킵니다.
즉, A는 B의 변수에도, 메모리에도, 파일에도 직접 접근할 수 없습니다.

그래서 필요한 것이 바로 운영체제를 거친 통신 채널, 즉 IPC(Inter-Process Communication) 입니다.

---

2️⃣ Windows는 어떤 방식으로 A와 B를 연결해주는가?

Windows는 A와 B 같은 프로그램이 데이터를 주고받을 수 있도록,
운영체제 차원에서 다음과 같은 통신 흐름의 틀을 제공합니다.

그 흐름은 다음과 같습니다:

[프로그램 A]
   |
   | (쓰기 핸들로 데이터 전송 요청)
   ▼
[운영체제 커널 내부 버퍼]
   ▲
   | (읽기 핸들로 데이터 수신 요청)
[프로그램 B]

이 구조는 이름 없는 파이프, 이름 있는 파이프, 메일슬롯 모두에서 본질적으로 동일합니다.

---

3️⃣ 구조 흐름을 따라가 보자: A가 데이터를 보낼 때 무슨 일이 일어나는가?

🔹 1. A는 먼저 통신 채널에 접근할 수 있는 “핸들”을 가진다

• 운영체제는 각 통신 채널에 대해 고유한 식별자를 제공합니다.
• 이 식별자는 “핸들(handle)”이라 불리며, 일종의 “입구 번호” 같은 것입니다.

핸들은 목적에 따라 두 종류로 나뉩니다:

핸들 종류 설명

쓰기 핸들	데이터를 보낼 수 있는 권한 (보통 A가 소유)
읽기 핸들	데이터를 꺼낼 수 있는 권한 (보통 B가 소유)

A는 이 핸들을 통해 “나 이 통로에 데이터 좀 넣을게”라고 요청할 수 있고,
B는 “저 통로에 뭐가 있나 꺼내볼게”라고 요청할 수 있습니다.

---

🔹 2. A가 데이터를 쓰면, 운영체제는 그걸 “중간 버퍼”에 저장한다

운영체제는 프로세스 간 통신에서 직접 데이터 교환을 허용하지 않습니다.
대신 A가 데이터를 쓰면, 커널 내부에 있는 **버퍼(buffer)**에 임시로 저장됩니다.

이 버퍼는:

• 운영체제가 관리하는 고정된 메모리 공간이며
• 읽는 쪽(B)이 바로 데이터를 꺼내지 않더라도,
• 일단 손실 없이 잠시 보관할 수 있습니다.

즉, B가 잠깐 자리를 비워도 A의 메시지가 사라지지 않습니다.

---

🔹 3. B는 언제든지 버퍼에서 데이터를 읽어갈 수 있다

B는 자신의 읽기 핸들을 통해 언제든 운영체제에 이렇게 요청합니다:

“그 통로에 데이터 있으면 꺼내줘.”

운영체제는:

• 버퍼에 저장된 데이터를 B에게 넘겨주고
• 읽은 만큼 버퍼를 비워서 새로운 데이터가 들어올 수 있게 합니다.

이렇게 해서 A → 커널 버퍼 → B 라는 간접적인 통신 흐름이 완성됩니다.

---

4️⃣ 그럼 실제 데이터 흐름은 어떤 식으로 작동하는가?

💡 전체 동작 순서 정리

(1) 통신 채널이 생성됨 → 읽기/쓰기 핸들이 할당됨  
(2) A는 쓰기 핸들을 통해 데이터를 전송  
(3) 운영체제는 내부 버퍼에 데이터를 임시 저장  
(4) B는 읽기 핸들로 데이터를 요청  
(5) 커널은 데이터를 꺼내서 B에게 전달  

이 동작은 이름 없는 파이프, 이름 있는 파이프, 메일슬롯 모두 공통적으로 따르는 흐름입니다.
(단, 메일슬롯은 일부 동작 방식이 비동기이며 약간 다르지만, 버퍼 기반 흐름은 동일합니다.)

---

5️⃣ 세 가지 방식은 이 구조 위에서 어떤 공통점을 가지는가?

구조 요소 이름 없는 파이프 이름 있는 파이프 메일슬롯

커널이 버퍼 제공	✅	✅	✅
핸들 기반 접근	✅	✅	✅
송신자가 데이터 씀	✅	✅	✅
수신자가 데이터 읽음	✅	✅	✅
데이터 흐름 구조	A → 커널 → B	A → 커널 → B	A → 커널 → B

이처럼 데이터를 버퍼에 넣고 꺼내는 흐름,
커널이 중재자 역할을 하는 구조,
읽기/쓰기 핸들을 통한 간접 통신은
세 방식이 모두 공유하는 공통 구조입니다.

---

6️⃣ 그럼 이 구조는 왜 이렇게 설계됐을까?

이런 설계는 다음의 핵심 원칙을 지킵니다:

설계 원칙 의미

메모리 보호	A와 B는 서로의 메모리에 접근할 수 없음
데이터 안전성	커널 버퍼를 통해 데이터 유실 방지
통신 단순화	쓰기-읽기만으로 구성, 사용자 간섭 최소화
유연성	읽는 쪽이 늦게 읽어도 문제 없음
보안 제어	핸들에 권한을 부여해 접근 제어 가능

운영체제가 중간에서 조율자 역할을 하면서
각 프로그램은 자신의 작업만 신경쓰면 되게끔 만든 것입니다.

---

🔚 정리: 오늘 다룬 핵심

• 이름 없는 파이프, 이름 있는 파이프, 메일슬롯은 기술적으로는 다르지만,
  모두 운영체제가 관리하는 통신 채널을 통해 데이터를 주고받는다는 공통 구조를 가집니다.
• 이 구조의 핵심은:
  **“A → 커널 버퍼 → B”**라는 간접 통신 흐름과,
  읽기/쓰기 핸들을 통한 제어 방식입니다.
• 이 구조는 데이터의 안정성, 메모리 보호, 권한 제어, 유연한 흐름을 동시에 달성하기 위한 설계입니다.

---

📘 다음 회차 예고 – 차이는 무엇인가?

이번 글에서는 “공통 구조”에 집중했습니다.
하지만 다음 회차에서는 다음 질문에 답합니다:

“그럼 도대체 왜 이름이 있고 없고를 나누는 거지?”
“왜 어떤 방식은 네트워크가 되고, 어떤 건 안 되지?”
“메일슬롯은 왜 메시지 단위로 작동하지?”
“단방향인데 어떻게 양방향 통신을 하지?”

즉, 구조는 같지만 기능은 다른 이 세 방식을
정확히 구분하는 기준과 차이점을
2회차에서 본격적으로 설명드립니다.

 

---

✅ 2회차: 같은 목적, 다른 길 – 통신 상황 속에서 드러나는 이름 없는 파이프, 이름 있는 파이프, 메일슬롯의 차이

---

🧭 이야기의 시작: 프로그램 A가 데이터를 전달하고 싶을 때

이야기를 하나 만들어 보겠습니다.
A라는 프로그램은 어떤 계산을 통해 텍스트 데이터를 생성합니다.
이 데이터는 다른 프로그램인 B가 즉시 받아서 처리해야만 시스템이 제대로 작동합니다.

여기서 중요한 조건은 다음과 같습니다:

• 데이터는 A가 쓰고, B가 읽어야 한다.
• A와 B는 별개의 프로세스로 실행된다.
• 둘 사이에 데이터를 직접 건네는 방법은 없다.
• 운영체제가 중간에서 이 연결을 지원해야만 한다.

이때 사용할 수 있는 방법이 바로 IPC입니다.
그중에서도 Windows가 제공하는 세 가지 방식:
이름 없는 파이프, 이름 있는 파이프, 메일슬롯이 있습니다.

지금부터 이 하나의 통신 상황을 기준으로,
각 방식이 어떻게 구성되고,
어떤 방식으로 데이터를 전달하며,
어떤 제약을 갖는지를 따라가 보겠습니다.

---

1️⃣ 이름 없는 파이프: 가장 단순한 연결, 하지만 가장 폐쇄적

A가 데이터를 쓰고, B가 그걸 즉시 읽는 구조.
가장 간단한 방법은 이름 없는 파이프입니다.
운영체제는 이 파이프를 만들 때, A에게 쓰기용 입구, B에게 읽기용 출구를 나눠줍니다.

하지만 이 방식에는 결정적인 전제가 있습니다:
👉 A와 B는 처음부터 서로 연결된 존재여야 합니다.
즉, A가 B를 직접 실행시키는 구조,
정확히 말하면, B는 A의 자식 프로세스여야만 합니다.

왜냐하면,
이름 없는 파이프는 이름이 없습니다.
운영체제 입장에서도 “이 파이프는 누구를 위한 것”인지 외부에서 알 방법이 없습니다.
핸들을 직접 물려주는 방식 외에는 통신할 방법이 없습니다.

또한 단방향입니다.
A가 데이터를 보내고 B가 받는 것까지만 됩니다.
그 반대는 불가능하며, 필요하다면 두 번째 파이프를 만들어야 합니다.

즉, 이름 없는 파이프는 단순한 구조, 빠른 연결, 짧은 생명주기를 가진 통신입니다.
아주 밀접하게 연결된 두 프로세스 간에만 사용 가능합니다.

---

2️⃣ 이름 있는 파이프: 이름을 가졌다는 것의 의미

이번에는 조금 더 일반적인 상황을 생각해봅시다.
A와 B는 전혀 관련 없는 두 프로그램입니다.
둘은 동시에 실행되기도 하고, 한 쪽이 늦게 실행되기도 합니다.
이름 없는 파이프처럼 실행 시점에 핸들을 넘겨주는 건 불가능합니다.

이럴 땐 이름 있는 파이프가 필요합니다.

A는 말합니다:

“나는 \.\pipe\ChannelAB라는 통로를 만들 테니,
B야, 네가 원할 때 거기로 와서 데이터를 읽어가.”

이제 통신은 고정된 이름을 기반으로 성립됩니다.
운영체제는 이 이름을 기억하고,
누구든 이 경로를 통해 파이프에 접근할 수 있도록 관리해줍니다.

핵심은 바로 이 이름입니다.
이름이 있다는 건 다음을 의미합니다:

• 다른 프로세스가 운영체제에게 “이 파이프에 연결하고 싶어요”라고 말할 수 있다.
• 즉, 관계없는 프로세스 간 통신이 가능해진다.
• 심지어 다른 컴퓨터에서도 이 파이프 이름을 통해 접속할 수 있다.
• 게다가 서버는 여러 클라이언트를 동시에 받아들일 수도 있다.

이름 있는 파이프는 구조적으로 훨씬 더 복잡합니다.
연결을 수립해야 하고, 접속을 기다려야 하며,
보안 속성, 읽기/쓰기 동기화, 다중 클라이언트 처리 등을 고려해야 합니다.
하지만 그만큼 범용성, 확장성, 제어력이 있습니다.

또한, 이름 있는 파이프는
단방향 뿐 아니라 양방향 통신도 가능합니다.
단 하나의 파이프를 통해 A와 B가 서로 데이터를 주고받을 수 있습니다.
이는 이름 없는 파이프보다 훨씬 실용적입니다.

---

3️⃣ 메일슬롯: 통신이 아니라 메시지 전파

마지막으로, 아주 다른 통신 요구가 있습니다.

A는 데이터가 아니라
“B야, 일이 생겼어. 확인해줘.”
이런 간단한 알림성 메시지만 보내고 싶습니다.

그런데 B는 A가 누군지 모릅니다.
A도 B가 실행 중인지 모릅니다.
중요한 건 메시지가 도착하는 것이지,
서로 연결되거나 응답을 주고받을 필요는 없습니다.

이때 등장하는 방식이 메일슬롯입니다.

B는 우체통을 하나 엽니다.
\.\mailslot\NoticeBox라는 이름을 운영체제에 등록합니다.

A는 말합니다:

“저기 우체통 있네. 여기 메시지 하나 넣고 간다.”
(그리고 돌아섭니다. 연결도, 응답도 기다리지 않습니다.)

메일슬롯은 다음과 같은 원리를 가집니다:

• 비연결형 구조입니다.
• 송신자는 수신자가 준비됐는지 신경쓰지 않습니다.
• 메시지 단위로 전송되며, 버퍼 안에 깔끔하게 정리되어 저장됩니다.
• 다수의 클라이언트가 하나의 수신자에게 메시지를 보낼 수 있습니다.
• 수신자는 한꺼번에 메시지를 꺼내 읽거나, 하나씩 순서대로 꺼냅니다.

이는 일반적인 통신이라기보다는,
브로드캐스트, 알림, 로그 기록, 이벤트 감지 등에 어울립니다.
무겁게 연결을 유지할 필요가 없는 상황에 최적화된 구조입니다.

---

🧩 정리: 세 가지 방식은 ‘접속의 성격’에서 갈린다

지금까지 따라온 이야기 흐름에서
다음과 같은 패턴이 보입니다.

방식 연결 방식 주도권 메시지 구조 이상적인 상황

이름 없는 파이프	직접 연결 (부모-자식)	생산자(A)	스트림	A가 B를 실행시킬 수 있는 구조
이름 있는 파이프	명시적 연결 (이름 기반)	수신자(B)가 접속	스트림 또는 메시지	연결 유지 + 응답 필요
메일슬롯	비연결 (우체통)	생산자(A)가 던지고 끝	메시지	알림, 브로드캐스트, 상태 보고 등

세 방식은 모두 운영체제가 만든 커널 버퍼, 핸들, 읽기/쓰기 흐름을 기반으로 작동하지만
접속 관계, 메시지 단위, 응답 여부, 이름 유무에서
서로 다른 전략을 취합니다.

---

📘 다음 회차 예고: 어떤 상황에서 어떤 방식을 써야 할까?

지금까지는 구조와 흐름을 봤다면,
3회차에서는 실제 예시를 통해

“내가 만들고 싶은 프로그램에서는 어떤 IPC 방식을 선택해야 할까?”
“속도, 보안, 다중 연결, 네트워크, 비동기… 어떤 걸 고려해야 하지?”
를 상황별로 정리해서 설명드릴 예정입니다.

 

 

✅ “그럼 실제로 언제 뭘 써야 하지?”

– 상황에 맞는 IPC 방식 선택 가이드 (이름 없는 파이프 / 이름 있는 파이프 / 메일슬롯)

를 시작하겠습니다.
이번 글에서는 추상적인 기술 비교가 아니라,
실제 현실적인 프로그래밍 상황 속에서 어떤 방식이 적합한지를 설명합니다.
통신 구조, 응답 필요성, 보안, 확장성 등 다양한 조건을 바탕으로
세 방식이 어떻게 선택되는지를 구체적 시나리오 중심으로 안내드립니다.

---

🧭 글의 구조

1. 통신 설계 시 고려해야 할 핵심 질문
2. A → B 상황별 구체적 예시 (실행 구조, 응답 유무 등)
3. 각 상황에서 적합한 IPC 방식 설명
4. 정리: 조건별 선택 가이드 표
5. 마무리: 기술이 아닌 ‘요구’에서 시작하라

---

1️⃣ 통신 설계 전에 던져야 할 질문

IPC는 기술적인 API 선택이 아니라,
**“이 프로그램들이 어떻게 대화해야 하는가”**에 대한 설계입니다.
따라서 먼저 이 질문들을 던져야 합니다:

• 📌 두 프로그램은 서로 어떤 관계인가?
  (직접 실행하는 관계인가? 전혀 무관한가?)
• 📌 연결을 지속할 필요가 있는가?
  (한 번 연결 후 요청-응답을 계속 주고받는가?)
• 📌 반대쪽에서 응답이 꼭 필요한가?
  (알림만 주고 끝나는 구조인가, 아니면 결과가 다시 돌아와야 하는가?)
• 📌 여러 개의 송신자/수신자가 존재하는가?
  (단일 통신인가, 다자간인가?)
• 📌 네트워크 너머에서도 통신해야 하는가?
  (같은 컴퓨터 내인가, 다른 PC와도 통신해야 하는가?)

이제 이 질문들을 실제 상황에 적용해보겠습니다.

---

2️⃣ 상황별 통신 시나리오와 적합한 방식

---

📦 상황 1: 프로그램이 자식 프로세스를 실행하면서 데이터를 전달해야 한다

예: 부모 프로세스가 자식 프로세스를 실행하고, 초기 설정값이나 인자 데이터를 전달해야 한다.

이때는 두 프로그램이 아주 밀접하게 연결되어 있고,
데이터 전달은 한 번만 간단히 일어나면 됩니다.

✅ 적합한 방식: 이름 없는 파이프

• 부모가 자식 프로세스를 실행하면서 핸들을 상속할 수 있음
• 빠르고 간단한 구조
• 복잡한 연결 관리, 보안 설정 불필요
• 단방향 통신으로 충분

---

📦 상황 2: 별도의 서비스 프로세스가 있고, 여러 클라이언트가 여기에 요청을 보내고 응답을 받아야 한다

예: 중앙 서비스가 백그라운드에서 실행되고,
여러 개의 사용자 애플리케이션이 명령을 보내고 결과를 받아야 함

이 구조에서는

• 연결을 유지해야 하며
• 요청 → 응답 흐름이 필요하고
• 다수의 클라이언트가 접속 가능해야 합니다.

✅ 적합한 방식: 이름 있는 파이프

• 이름을 기반으로 어느 클라이언트든 접속 가능
• 서버-클라이언트 구조에 적합
• 양방향 통신 가능
• 보안 속성 설정 가능 (누가 접속 가능한지 제어 가능)
• 네트워크 확장 가능

---

📦 상황 3: 여러 클라이언트가 상태 변경 사실을 서버에 알리기만 하면 된다

예: 여러 앱이 자신이 변경된 상태를 중앙 수신자에게 간단히 알림
예: “나는 작업을 끝냈습니다”, “파일이 업로드되었습니다” 같은 알림성 메시지

이 경우는

• 연결을 유지할 필요가 없고,
• 응답도 필요 없으며,
• 메시지 하나를 보내고 끝나는 구조입니다.

✅ 적합한 방식: 메일슬롯

• 수신자가 이름 있는 메일슬롯을 열어두기만 하면 됨
• 송신자는 언제든 메시지를 던지고 사라지면 됨
• 비연결형 구조
• 네트워크 브로드캐스트도 가능
• 구조가 간단하고 오버헤드가 적음

---

📦 상황 4: 클라이언트가 요청을 보내고, 응답까지 꼭 받아야 하는데, 연결은 길게 유지하지 않아도 된다

예: 프로그램 A가 서버 B에게 어떤 작업을 요청하고,
B는 바로 응답을 주지만 이후에는 다시 연결할 필요 없음

이 구조는 약간 애매합니다.

• 요청/응답이 필요하므로 메일슬롯은 부족하고
• 연결을 유지할 필요는 없으므로 이름 있는 파이프는 오버스펙입니다.

✅ 적합한 방식: 이름 있는 파이프 + 짧은 세션 유지

• 한 번의 ConnectNamedPipe → 통신 → Close
• 서버는 단일 응답만 주고 연결 종료
• 메일슬롯은 응답이 불가능하기 때문에 부적절

---

📦 상황 5: 여러 컴퓨터에서 하나의 수신자에게 메시지를 보내야 한다

예: 네트워크상의 클라이언트들이 상태 보고를 중앙 서버로 전달

이 상황은 메일슬롯의 대표적 사용 예입니다.

✅ 적합한 방식: 메일슬롯

• 수신자는 \.\mailslot\mySlot 이름으로 수신 대기
• 클라이언트는 \ComputerName\mailslot\mySlot 형태로 원격 전송
• 비연결형 구조 + 메시지 단위 처리
• 네트워크 브로드캐스트도 지원됨

---

3️⃣ 조건별 선택 가이드

이제 위 시나리오를 요약해보면 다음과 같습니다:

조건 이름 없는 파이프 이름 있는 파이프 메일슬롯

부모-자식 관계	✅	❌	❌
관계 없는 프로세스	❌	✅	✅
응답 필요	❌	✅	❌
단방향	✅	✅	✅
양방향	❌	✅	❌
연결 유지	필요	필요	❌
네트워크 지원	❌	✅	✅
다수 클라이언트 지원	❌	✅	✅
메시지 기반	❌	옵션 (메시지 모드 설정 시)	✅

---

🔚 마무리: 기술이 아니라 ‘요구’에서 시작하라

파이프냐, 메일슬롯이냐는 기술의 문제가 아닙니다.
**"프로그램이 어떤 관계에 있고, 어떤 대화를 주고받으려 하는가"**라는
설계적 요구에서 출발해야만 올바른 방식이 선택됩니다.

• 밀접한 관계 → 이름 없는 파이프
• 제어 가능한 양방향 연결 → 이름 있는 파이프
• 간단한 메시지 전파 → 메일슬롯

Windows가 이 세 가지 방식을 제공하는 이유는
모든 통신이 같은 구조로 이뤄지지 않기 때문입니다.

---