"실시간"이라는 요구는 채팅·알림·시세·게임·협업 도구 등 다양한 형태로 등장합니다. 그러나 모든 실시간 통신을 WebSocket으로 풀 필요는 없습니다. 각 프로토콜은 풀려는 문제와 트레이드오프가 다르며, 잘못된 선택은 인프라 비용과 운영 난이도를 동시에 끌어올립니다. 본 문서는 WebSocket과 그 비교 대상이 되는 실시간 통신 기술들을 무엇·언제·장단점·유의점 관점에서 정리합니다.

실시간 통신 기술 분류

기술	방향성	전송 계층	대표 사례
WebSocket	양방향(Full-duplex)	TCP	채팅, 협업, 게임, 시세
HTTP Polling	클라이언트 → 서버	TCP	단순 상태 갱신
Long Polling	서버 → 클라이언트(유사 푸시)	TCP	레거시 호환 알림
SSE	서버 → 클라이언트(단방향)	TCP / HTTP	서버 이벤트 스트림, 알림
WebRTC	양방향 P2P	UDP(SRTP/SCTP)	화상회의, 음성통화, P2P 데이터
gRPC Streaming	단/양방향 스트림	HTTP/2	서버 간 스트리밍, 마이크로서비스
MQTT	Pub/Sub	TCP(또는 WS)	IoT, 센서, 모바일 푸시 백엔드

1. WebSocket

표준 양방향 실시간 통신 프로토콜 (RFC 6455)

어떤 기술인가

단일 TCP 연결 위에서 양방향(Full-duplex)으로 메시지를 주고받는 표준 프로토콜. 처음에는 일반 HTTP 요청으로 시작해 Upgrade 헤더로 WebSocket으로 전환(handshake)됩니다. 이후로는 HTTP 요청·응답이 아닌 자체 프레임 포맷으로 통신하며, 한 번 열린 연결은 명시적으로 닫을 때까지 유지됩니다.

어떨 때 쓰이는가

• 채팅, 협업 도구(공동 편집), 멀티플레이어 게임
• 주식·암호화폐 시세 스트리밍
• 실시간 알림 + 사용자 액션 동시 처리가 필요한 경우
• HTTP 폴링으로는 비용·지연이 부적합한 트래픽 패턴

2. HTTP Polling (Short Polling)

주기적으로 서버에 묻는 가장 단순한 방식

어떤 기술인가

클라이언트가 일정 주기마다 HTTP GET으로 서버 상태를 확인하는 방식. 별도 프로토콜이 없고 일반 HTTP만 쓰면 되므로 구현 부담이 가장 작습니다.

어떨 때 쓰이는가

• 지연 허용 폭이 큰 상태 갱신 (예: 분 단위 동기화)
• 실시간성이 거의 없는 단순 대시보드
• 실시간 인프라 도입이 부담스러운 초기 MVP

3. Long Polling

HTTP만으로 푸시를 흉내내는 절충안

어떤 기술인가

클라이언트가 HTTP 요청을 보낸 뒤, 서버는 전달할 이벤트가 생길 때까지 응답을 보류합니다. 이벤트가 생기면 응답을 내려주고, 클라이언트는 즉시 다음 요청을 다시 보냅니다. WebSocket이 널리 쓰이기 전 실시간 푸시의 사실상 표준이었습니다.

어떨 때 쓰이는가

• WebSocket·SSE를 차단하는 기업 프록시 환경
• 구형 브라우저·레거시 SDK 호환이 필요한 경우
• 이벤트 발생 빈도가 낮아 양방향 연결까지는 과한 경우

4. Server-Sent Events (SSE)

HTTP 기반 단방향 서버 푸시 표준

어떤 기술인가

HTML5 표준의 EventSource API. 일반 HTTP 응답을 끊지 않고 text/event-stream MIME 타입으로 이벤트를 줄줄이 흘려보냅니다. 서버 → 클라이언트 단방향이며, 끊기면 브라우저가 자동 재연결합니다.

어떨 때 쓰이는가

• 서버 알림, 진행 상황 스트림 (예: AI 응답 토큰 스트리밍, 빌드 로그)
• 읽기 전용 시세/통계 대시보드
• 클라이언트 → 서버는 일반 REST로 충분한 워크로드

5. WebRTC

브라우저 간 P2P 미디어·데이터 통신 표준

어떤 기술인가

브라우저·앱 간 P2P(Peer-to-Peer)로 영상·음성·데이터를 주고받는 기술. UDP 위에서 SRTP(미디어), SCTP(데이터 채널)를 쓰며, NAT/방화벽 통과를 위해 STUN/TURN 서버를 활용합니다. 시그널링(연결 협상) 채널은 별도 구성(WebSocket이나 HTTP)이 필요합니다.

어떨 때 쓰이는가

• 화상 회의·음성 통화 (Google Meet, Discord 음성)
• 저지연 라이브 스트리밍
• P2P 파일 전송, 멀티플레이어 게임의 위치 데이터
• 중앙 서버를 거치지 않아 비용·지연을 줄여야 하는 케이스

6. gRPC Streaming

HTTP/2 기반 RPC의 스트리밍 모드

어떤 기술인가

Google이 만든 RPC 프레임워크 gRPC는 HTTP/2 위에서 동작하며, 단일 호출(unary) 외에도 서버 스트리밍 / 클라이언트 스트리밍 / 양방향 스트리밍 모드를 제공합니다. 메시지는 Protobuf로 직렬화되어 매우 작고 빠릅니다.

어떨 때 쓰이는가

• 마이크로서비스 간 실시간 데이터 파이프라인
• 다국어(polyglot) 백엔드의 강한 스키마 계약 필요
• 대용량/고빈도 메시지 스트림 (텔레메트리, 모니터링)
• 서버 ↔ 서버 통신 (브라우저는 gRPC-Web 등 별도 처리 필요)

7. MQTT

IoT·모바일에 최적화된 경량 Pub/Sub 프로토콜

어떤 기술인가

TCP 위에서 동작하는 Publish/Subscribe 모델의 경량 프로토콜. 토픽(topic)에 발행하고 구독하는 구조이며, 헤더가 매우 작아 좁은 대역폭·저전력 환경에 적합합니다. WebSocket 위에 얹는 변형(MQTT over WebSocket)도 표준화되어 브라우저에서도 사용 가능합니다.

어떨 때 쓰이는가

• IoT 디바이스 (센서, 가전, 차량 텔레메트리)
• 모바일 앱의 푸시 백엔드
• 다대다 메시지 라우팅 (수만~수백만 토픽)
• QoS(0/1/2) 등 메시지 보장 수준이 다양한 케이스

기술 비교 매트릭스

🛠 실습 — WebSocket 채팅 서버와 SSE 비교

Node.js로 WebSocket 에코·브로드캐스트 서버를 만든 뒤, 같은 알림 기능을 SSE로도 구현해 두 패러다임의 차이를 직접 체감합니다.

사전 준비

• Node.js 20+ / npm
• 웹 브라우저 (DevTools Console에서 클라이언트 코드 실행)
• (선택) wscat CLI로 WS 디버깅

STEP 1 — Node `ws`로 에코 서버

mkdir ws-lab && cd ws-lab
npm init -y
npm i ws

cat > echo-server.js <<'EOF'
const { WebSocketServer } = require('ws');
const wss = new WebSocketServer({ port: 8080 });

wss.on('connection', (socket, req) => {
  console.log('connected:', req.socket.remoteAddress);
  socket.on('message', (data) => socket.send(`echo: ${data}`));
  socket.on('close', () => console.log('closed'));
});
console.log('ws://localhost:8080');
EOF

node echo-server.js

// 브라우저 DevTools 콘솔
const ws = new WebSocket('ws://localhost:8080');
ws.onmessage = (e) => console.log(e.data);
ws.onopen = () => ws.send('hi');

STEP 2 — 다중 클라이언트 브로드캐스트(채팅)

// chat-server.js
const { WebSocketServer } = require('ws');
const wss = new WebSocketServer({ port: 8080 });

function broadcast(payload, except) {
  const msg = JSON.stringify(payload);
  for (const c of wss.clients) {
    if (c.readyState === 1 && c !== except) c.send(msg);
  }
}

wss.on('connection', (socket) => {
  socket.on('message', (raw) => {
    try {
      const { user, text } = JSON.parse(raw);
      broadcast({ user, text, ts: Date.now() }, socket);
    } catch { /* ignore malformed */ }
  });
});

탭 두 개를 띄우고 한쪽에서 보낸 메시지가 다른 쪽에 즉시 도착하는지 확인하세요.

STEP 3 — Heartbeat (ping/pong)

// 서버: 30초마다 ping → 60초 내 pong 없으면 종료 (NAT/ALB Idle timeout 회피)
function heartbeat() { this.isAlive = true; }

wss.on('connection', (ws) => {
  ws.isAlive = true;
  ws.on('pong', heartbeat);
});

setInterval(() => {
  for (const ws of wss.clients) {
    if (!ws.isAlive) return ws.terminate();
    ws.isAlive = false;
    ws.ping();
  }
}, 30_000);

실제 운영에서는 ALB(기본 60초)·NAT·기업 프록시가 idle 연결을 끊으므로 heartbeat는 선택이 아닌 필수입니다.

STEP 4 — 인증 + 재연결 클라이언트

// 서버: handshake 시점에만 토큰 검사 가능
wss.on('connection', (ws, req) => {
  const url = new URL(req.url, 'http://x');
  const token = url.searchParams.get('token');
  if (!isValid(token)) return ws.close(4001, 'unauthorized');
});

// 클라이언트: 지수 백오프 재연결
function connect(retries = 0) {
  const ws = new WebSocket(`ws://localhost:8080/?token=${getToken()}`);
  ws.onclose = () => {
    const delay = Math.min(1000 * 2 ** retries, 30_000);
    setTimeout(() => connect(retries + 1), delay);
  };
  ws.onopen = () => { retries = 0; };
}
connect();

STEP 5 — 같은 기능을 SSE로 (단방향)

// sse-server.js — Express 없이 순수 http
const http = require('http');

http.createServer((req, res) => {
  if (req.url !== '/events') return res.end();
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive',
    'X-Accel-Buffering': 'no',
  });
  let i = 0;
  const id = setInterval(() => {
    res.write(`id: ${++i}\n`);
    res.write(`data: ${JSON.stringify({ tick: i, ts: Date.now() })}\n\n`);
  }, 1000);
  req.on('close', () => clearInterval(id));
}).listen(8090, () => console.log('sse on 8090'));

// 브라우저 — 자동 재연결과 Last-Event-ID는 EventSource가 처리
const es = new EventSource('http://localhost:8090/events');
es.onmessage = (e) => console.log('sse:', e.data);

관찰 포인트

• WebSocket: 양방향 메시지가 자유롭지만 재연결·인증·heartbeat를 직접 짜야 함
• SSE: 클라이언트 → 서버는 별도 REST. 대신 재연결·이벤트 ID는 브라우저가 무료로 처리
• 둘 다 운영에서는 TLS(WSS / HTTPS) 강제, 프록시·LB의 idle timeout 점검 필수

의사결정 가이드 — 무엇을 언제 쓸까

상황	권장 기술	이유
실시간 채팅·게임·협업 도구	WebSocket	양방향, 저지연, 표준 지원
서버 푸시만 필요 (알림·진행상황·LLM 토큰 스트림)	SSE	단방향, HTTP 인프라 그대로, 자동 재연결
분 단위 갱신으로도 충분한 단순 대시보드	HTTP Polling	구현 비용 최소
프록시·방화벽이 WS/SSE를 차단	Long Polling	HTTP만 통과하면 됨
화상회의, 음성통화, 저지연 미디어	WebRTC	P2P, UDP, 미디어 표준 스택 내장
서비스 간 고빈도 데이터 스트림 (S2S)	gRPC Streaming	스키마, Protobuf, HTTP/2
IoT 디바이스, 수백만 동시 연결 푸시	MQTT	초경량 헤더, Pub/Sub, QoS

🎯 핵심 요약

• WebSocket — 양방향이 정말 필요할 때의 표준 선택
• HTTP/Long Polling — 인프라가 받쳐주지 않거나 빈도가 낮을 때의 현실적 대안
• SSE — 서버 → 클라이언트 단방향이면 가장 간단·견고
• WebRTC — 오디오·비디오·P2P 데이터의 사실상 표준
• gRPC Streaming — 서버 간 강한 스키마 + 고빈도 스트림
• MQTT — IoT·수백만 디바이스 푸시의 정답

"실시간"은 단일 기술이 아니다. 양방향성, 지연 허용 폭, 클라이언트 환경, 서버 자원 모델, 운영 가능성을
함께 따져 트래픽 성격에 맞는 프로토콜을 고르는 것이 핵심이다.