[Network] WebSocket, SSE, gRPC, WebRTC: 실시간 통신 프로토콜 아키텍처 선택 가이드

웹 애플리케이션은 사용자의 요청에 응답하는 단방향 패러다임을 넘어, 실시간으로 데이터를 주고받는 상호작용이 기본이 되었습니다. 주식 시세창, AI 스트리밍 답변, 실시간 화상 미팅, 배달 위치 추적 등이 대표적입니다.

하지만 "실시간"이라는 단어 하나에 백엔드의 선택지는 여러 가지가 있으며, 네트워크 오버헤드와 물리적 한계가 극명히 다릅니다. 오늘은 많이 비교되는 WebSocket, SSE, gRPC, WebRTC의 동작 원리와 실무적인 선택 기준을 딥다이브해 봅니다.

1. 4대 실시간 통신 기술 핵심 요약

① WebSocket (양방향 전이중 통신)

• 메커니즘: HTTP 통신으로 첫 연결(Handshake)을 맺은 후, 프로토콜을 ws:// 또는 wss://로 업그레이드하여 TCP 연결을 계속 유지합니다.
• 특징: 서버와 클라이언트가 연결 통로 하나를 공유하며 언제든 동시에 데이터를 던질 수 있습니다(전이중 통신).
• 적합한 곳: 실시간 다중 사용자 채팅, 멀티플레이어 웹 게임, 실시간 협업 툴(피그마 등).

② SSE (Server-Sent Events / 서버 단방향 스트리밍)

• 메커니즘: 전통적인 HTTP 연결을 그대로 유지(Keep-Alive)하면서, 서버가 클라이언트에게 데이터를 지속적으로 밀어내는(Push) 기술입니다.
• 특징: 클라이언트는 서버에 데이터를 보낼 수 없고 오직 받기만 하는 단방향 구조입니다. 웹소켓과 달리 재연결 처리가 내장되어 있고, 일반 HTTP/2 프로토콜 위에서 가볍게 동작합니다.
• 적합한 곳: ChatGPT 같은 LLM의 실시간 텍스트 출력(Streaming), 실시간 알림창, 실시간 주식/코인 시세판.

③ gRPC (초고속 바이너리 RPC)

• 메커니즘: 구글이 개발한 오픈소스 RPC 프레임워크로, HTTP/2를 기반으로 동작하며 데이터 포맷으로 JSON 대신 바이너리 형식의 Protocol Buffers를 사용합니다.
• 특징: 스트리밍(Client, Server, 양방향 모두)을 지원하며, 텍스트가 아닌 바이너리로 데이터를 압축해 송수신하므로 속도가 압도적으로 빠르고 대역폭 소비가 적습니다.
• 적합한 곳: 마이크로서비스(MSA) 간의 고속 내부 통신, 대용량 데이터 적재 파이프라인.

④ WebRTC (초저지연 P2P 미디어 스트리밍)

• 메커니즘: 웹 브라우저 간에 중간 서버를 거치지 않고 오디오, 비디오, 임의의 데이터 데이터를 직접 주고받는(Peer-to-Peer) 오픈소스 기술입니다.
• 특징: 서버의 리소스를 거의 쓰지 않고 클라이언트끼리 직접 통신하기 때문에 레이턴시(Latency)가 사실상 제로에 가깝습니다. 대다수 UDP 기반 프로토콜을 활용해 신속하게 패킷을 나릅니다. 단, 방화벽을 뚫고 서로의 위치를 찾기 위한 시그널링(Signaling) 서버와 STUN/TURN 서버 인프라가 사전에 필요합니다.
• 적합한 곳: 구글 미트/줌 같은 실시간 화상·음성 통화, 대용량 파일 1:1 직전송 툴, 화면 공유 스트리밍.

2. 한눈에 보는 기술 스펙 비교 테이블

항목	WebSocket	SSE	gRPC (Streaming)	WebRTC
통신 방향	양방향 (Bi-directional)	서버 → 클라이언트 (단방향)	양방향 지원	P2P 양방향 (Peer-to-Peer)
기반 프로토콜	TCP (HTTP/1.1 업그레이드)	TCP (HTTP/2 권장)	TCP (HTTP/2 전용)	UDP / TCP 하이브리드
데이터 포맷	텍스트 / 바이너리 (자유)	텍스트 (text/event-stream)	Protocol Buffers (바이너리)	미디어 프레임 / 바이너리
서버 부하	연결 지속으로 인한 커넥션 부하	웹소켓 대비 상대적으로 가벼움	고성능 멀티플렉싱으로 효율적	매우 낮음 (초기 연결 후 이탈)
브라우저 지원	네이티브 지원 (완벽)	네이티브 지원 (완벽)	브라우저 전용 gRPC-Web 필요	네이티브 지원 (웹 API 확장)

3. WebRTC 도입 시 백엔드 엔지니어가 고려할 아키텍처 병목

많은 개발자가 "WebRTC는 P2P니까 서버가 필요 없겠네?"라고 오해하지만, 현실의 배포 환경에서는 백엔드가 책임져야 할 네트워크 허들이 매우 높습니다.

1. 시그널링(Signaling) 서버 인프라: 두 브라우저가 직접 연결되기 전, 서로의 IP와 미디어 포맷(SDP) 정보를 교환할 중크루(Broker)가 필요합니다. 이 시그널링 레이어는 주로 WebSocket이나 SSE로 구현됩니다. (즉, WebRTC를 쓰려면 웹소켓도 같이 빌드해야 합니다.)
2. NAT 및 방화벽 돌파 (STUN/TURN): 대부분의 사용자 컴퓨터는 가상 IP(NAT)나 사내 방화벽 뒤에 숨어 있어 직통 연결이 불가능합니다. 공인 IP를 찾아주는 STUN 서버, 방화벽이 너무 강해 P2P가 실패할 때 트래픽을 대신 릴레이(우회)해주는 TURN 서버 인프라를 직접 구축해야 합니다. 대용량 미팅 시 TURN 서버의 트래픽 비용 폭탄을 고려해야 합니다.

4. [실무 바이블] 어떤 프로토콜을 선택해야 할까?

프로젝트 요구사항 정의 단계에서 아래 4단계 필터링 질문을 던지면 정답이 도출됩니다.

Q1. 통신의 주 목적이 고품질 미디어(화상/음성) 스트리밍인가?

• YES → WebRTC가 유일한 정답입니다. 1초 미만의 실시간성이 생명인 오디오/비디오 전송은 오직 WebRTC 아키텍처 영역입니다.

Q2. 클라이언트가 서버로 데이터를 보낼 필요가 없는 단방향 구조인가?

• YES → SSE(Server-Sent Events)를 선택하세요. 웹소켓은 불필요한 양방향 오버헤드와 커넥션 관리 공수가 듭니다. AI가 한 글자씩 대답을 내뿜는 시나리오나 실시간 푸시 알림은 SSE가 가장 가볍고 안전합니다.

Q3. 다중 사용자가 동시에 메시지를 주고받는 실시간 상호작용인가?

• YES → WebSocket이 정답입니다. 실시간 채팅, 동시 편집, 인게임 패킷 전송 등 서버와 클라이언트가 끊임없이 양방향으로 핑퐁을 쳐야 한다면 웹소켓 표준을 가동해야 합니다.

Q4. 브라우저 환경이 아닌, 내부 인프라(서버 간) 혹은 모바일 앱 통신인가?

• YES → gRPC 스트리밍을 고려하세요. 웹 브라우저의 제약 조건이 없는 환경(Back-to-Back)이나 앱-서버 환경에서 마이크로 단위의 응답 속도 최적화가 필요하다면 바이너리 기반의 gRPC가 성능을 극대화합니다.

 

과거에는 실시간 통신이라고 하면 무조건 웹소켓(WebSocket)을 떠올렸지만, 기술이 성숙함에 따라 데이터의 흐름과 하드웨어 스펙에 맞추어 SSE의 가벼움, gRPC의 정밀함, WebRTC의 초저지연성을 적재적소에 배치하는 '선택과 집중'이 중요해졌습니다.

구축하려는 서비스의 데이터가 어느 방향으로 흐르는지 네트워크 트래픽 관점에서 분석한 후 최적의 프로토콜 스택을 결정하시기 바랍니다.