실무에서 널리 쓰이는 네트워크 기반 프로세스 통신 기술(HTTP / Message Queue / WebSocket)

 

IPC 데몬 헌터스

 

 

🚩 개요

 

팀 업무 특성상 외부 서버와 통신 서비스를 구현하면서 매우 흥미로웠던 점은, 사내 Rac(Remote Access Control) 객체에 적절한 구성 요소만 채우면 곧바로 HTTP Request 메시지가 생성되어 외부 컴포넌트와 통신이 이루어진다는 사실이었습니다. 마치 “HTTP Client를 직접 구현하지 않아도 네트워크 요청이 만들어지는” 추상화 계층이 존재하고, 이 인터페이스를 사용하여 외부와 통신하고 있었습니다.

이 글에서는 사내 서비스 내부에서 IPC(Inter-Process Communication), 특히 외부 시스템과 통신하는 Rac의 동작 흐름을 중심으로 정리합니다. 더불어 실무에서 쓰이는 다양한 IPC 방식 (HTTP / Message Queue / WebSocket) 간의 구조적 차이와 목적도 함께 다뤄 보도록 하겠습니다.

 

 

🤔 IPC란 무엇인가?

IPC(Inter Process Communication)는 프로세스 간 통신을 의미합니다. 독립적인 프로세스들이 데이터를 교환하며 협업할 수 있도록 만드는 핵심 기술입니다.

IPC는 두 가지 범주로 구분할 수 있습니다

1. 동일 OS 내 프로세스 간 통신
2. 네트워크 기반 프로세스 간 통신

이번 글의 초점은 ② 네트워크 기반 IPC이며, 이는 “서로 다른 시스템(서버/서비스)이 데이터를 교환하는 방식”을 말합니다.
마이크로서비스 아키텍처, 분산 시스템, 외부 API 연동 등 대부분의 실제 비즈니스 통신이 여기에 포함됩니다.

 

 

 

1️⃣ HTTP 통신 - 네트워크 IPC의 가장 기본

 

HTTP(Hypertext Transfer Protocol)는 클라이언트-서버 모델을 기반으로 동작하는 가장 보편적인 통신 규약입니다.
Client는 HTTP Request를 전송하고, Server는 Response를 반환합니다.
이 과정에서 반드시 HTTP Message 구조와 프로토콜 스펙을 준수해야 합니다.

HTTP 요청 메시지는 다음과 같은 구조를 갖습니다

HTTP Request 구조

개발자는 이 Message를 직접 구성하거나 HTTP Client를 사용해 생성합니다.
사내에서 Rac이 이 역할을 추상화한 계층입니다.

 

Rac의 역할 - HTTP Client 추상화

Rac(Remote Access Control)은 사내에서 만든 외부 서버와 통신하는 책임만을 가지는 객체입니다.

Rac 객체는 대부분 공통 Base 클래스를 상속하고, onExecute() 내부에서 HTTP 핸들러 옵션을 구성해 요청을 수행합니다.
핵심은 Rac이 하는 일이 단순한 wrapper가 아니라, TS(JS) → C# Core → OS 네트워크 스택 까지 이어지는 다층 구조의 실행 체인을 만든다는 점입니다.

[Rac]
   ↓ onExecute()
[$HttpClient]
   ↓ sendAs()
[HttpClientObject]
   ↓ __STUB__SendAs()
[HttpClient]
   ↓ SendAsync()
[SocketsHttpHandler]
   ↓ SendAsync()
[System.Net.Sockets / SocketAsyncEngine]
   ↓
[OS 커널의 TCP/IP 스택]
   ↓
[TCP/IP 처리 → NIC 드라이버 → 네트워크 전송]
   ↓
[인터넷]
   ↓
[외부 서버의 NIC 드라이버]
   ⋮

 

 

이런 과정을 통해서 Rac 셋팅 했던 값들이 HTTP Request Message 구성 요소가 되고 TCP 세그먼테이션, 패킷, 데이터 프레임, 전기 신호가 되어 외부 서버에 도달 하게 됩니다.
이후 외부 모듈에서 과정은 조립은 해체의 역순인 걸 다들 아시는 것처럼 역순으로 진행되게 됩니다.

서버는 요청 메세지를 처리해서 응답을 보내주게 됩니다. HTTP Response 의 간략한 구조는 다음과 같습니다.

HTTP Response 구조

 

 

 

2️⃣ Message Queue - “발행 후 신경 쓰지 않기” 방식의 비동기 IPC

 

메시지 큐는 생산자-소비자 모델로 동작합니다.
발행(Publish)한 메시지는 큐가 전달 보증을 담당하고, 생산자는 이후 과정을 신경쓰지 않습니다.

이 방식은 다음 장점을 제공합니다

 

• 생산자와 소비자 간 결합도 최소화
• 수평 확장에 강함
• 장애 복구 지점 명확
• 메시지 기반 이벤트 모델(EDA) 구현

 

Publisher는 생산에만 책임과 역할이 있고 해당 메세지를 어떻게 할 것인지에 대해선 관심이 없기 때문에 상대적으로 결합도가 낮은 아키텍처입니다.(의존도가 낮음)
그래서 분산 시스템 아키테처를 갖는 많은 회사에서 애용하는 방식입니다. 실제로 많은 엔터프라이즈 시스템들이 MQ를 중심으로 동작합니다.

 

 

사내 환경에서 MQ는 PGMQ, Kafka, Redis Pub/Sub 등 다양한 구현체를 지원합니다.
핵심 차이는 전달 보증 방식, Partitioning, 메세지의 중요도 입니다.
Publiser와 Consumer 구현체로는 여러 기술 스택이 있지만, TS Rac 관점에서는 동일한 인터페이스로 Publish 하여 유지보수성을 높였습니다.

 

 

해당하는 채널 대하여 어떤 커넥션 ID 로 연결 서버를 가져올지, 어느정도 max task 수를 가질지, 토픽의 이름은 무엇으로 할지는 config 파일로 관리할 수 있습니다. 

 

 

3️⃣ WebSocket — 진정한 양방향 통신

HTTP는 “요청 → 응답” 모델이므로 근본적으로 단방향입니다.
서버는 요청이 오기 전까지 클라이언트에 임의 push를 할 수 없습니다.

WebSocket은 TCP 기반으로 전 이중 통신 채널을 형성합니다. 

핸드셰이크는 HTTP 기반으로 요청합니다.

GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade

 

서버가 HTTP 101 Switching Protocols 로 응답하면
이후 통신 프로토콜은 ws:// (TLS 시 wss://) 로 전환됩니다.

 

 

사내 WebSocket 활용

웹 브라우저 JS 런타임에 Socket wrapper 객체를 활용합니다.
이 객체는 내부적으로 브라우저 WebSocket API를 사용하며, 서버 측은 TCP_NetClient 기반으로 패킷을 수신/분배합니다.

이 방식은 실시간 채팅, 알림, 협업 UI 에 적합합니다.

• 지속 연결 유지
• 서버 Push
• 메시지 latency 최소화

HTTP Polling / SSE 대비 안정적인 실시간성을 제공합니다.

 

 

📍마무리

IPC는 무엇이 더 최신인가? 어떤 기술이 더 좋나?가 아니라 비즈니스 요구를 해결하는 방식이어야 합니다.

방식	장점	단점	사례
HTTP	단순/표준/Restful	단방향/실시간 부족	외부 API, CRUD
MQ	비동기/확장성	순서/재처리 복잡	이벤트 기반 시스템
WebSocket	실시간/양방향	연결 유지 비용	채팅/모니터링

같은 회사 시스템이라도 도메인에 따라 최적의 IPC는 달라질 수 있습니다.

 

 

사내의 Rac를 분석하면서 단순히 “HTTP 요청을 보내는 코드”가 아니라,
TS(JS) → C# Core → OS 네트워크 스택으로 이어지는 수직적 추상화 레이어 위에서 우리의 비즈니스 로직이 작동하고 있다는 사실을 명확히 이해할 수 있었습니다.


결론적으로, IPC는 단순한 기술이 아니라 서비스 간 계약과 메시지 모델링을 설계하는 영역입니다.
Rac가 제공하는 추상화는 개발자가 네트워크 통신 내부에 신경 쓰는 대신 비즈니스 도메인 문제 해결에 더욱 집중할 수 있게 해줍니다.