평범한 HTTP 대신 WebSocket, SSE, 또는 long-polling을 언제 사용하겠는가?

Question

IT Interview Practice · Accepted Answer

평범한 HTTP는 **request/response**다: 클라이언트가 묻고, 서버가 답하면, 끝이다. 그것은 *서버*가 새로운 것이 생길 때마다 데이터를 push해야 하는 **실시간** 기능(채팅, 라이브 대시보드, 알림, 협업 편집)에는 잘 맞지 않는다. 선택지들은 HTTP의 클라이언트 개시(client-initiated) 모델을 우회하는 방법들이며, 복잡도의 스펙트럼을 따라 놓인다:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling**은 어디서나 작동하는 폴백이다: 클라이언트가 평범한 request를 보내면 서버가 데이터가 생길 때까지 그것을 열어둔 채로 있다가, 그다음 클라이언트가 즉시 다시 요청한다. 평범한 HTTP 위에서 push를 근사하지만 메시지당 request 사이클을 낭비하고 지연을 더한다.

**SSE (Server-Sent Events)**는 단일한 오래 지속되는 HTTP response 위의 가볍고 표준화된 **단방향** 스트림(server → client)이다. 서버만 push할 때 이상적이다 — 라이브 피드, 알림, 진행 상황, 스트리밍 LLM 토큰. 단순하고, 평범한 HTTP/2 위에서 실행되며(특별한 인프라 불필요), 자동 재연결한다. 한계: 단방향이고 텍스트 전용이다.

**WebSocket**은 단일 HTTP 연결을 지속적인 **full-duplex** TCP 채널로 업그레이드하여 양쪽이 최소한의 메시지당 오버헤드로 언제든 보낼 수 있게 한다. 진정으로 양방향인 저지연 상호작용에 사용하라: 채팅, 멀티플레이어 게임, 협업 편집기, 트레이딩. 그 대가는 운영적이다 — proxy, load balancer, autoscaler가 맞춰 구성되어야 하는 stateful 연결이고, 재연결, heartbeat, backpressure를 직접 구축해야 한다.

**경험칙:** 기본은 평범한 HTTP; server→client 스트리밍에는 **SSE**; 진정으로 양방향 실시간이 필요할 때만 **WebSocket**에 손을 뻗고; **long-polling**은 범용 폴백으로 남겨둬라.

## 왜 중요한가

실시간 transport를 고르는 것은 순진한 답("그냥 전부 WebSocket 써")이 보통 틀리는 고전적 시니어 설계 결정이다. 면접관은 당신이 도구를 *통신 패턴* — 단방향 vs 양방향, 지연 요구, 메시지 양 — 에 맞추는지, 그리고 stateful하고 오래 지속되는 연결의 **운영 비용**(sticky session, 스케일링, proxy timeout, 재연결 로직)을 저울질하는지 보고 싶어 한다. SSE가 "서버가 업데이트를 push한다"를 WebSocket보다 더 단순하게 자주 커버한다는 것, 그리고 long-polling이 견고한 폴백으로 남는다는 것을 인식하는 것은 가장 화려한 옵션에 손을 뻗는 대신 실제 프로덕션 경험을 나타낸다.

왜 중요한가

관련 질문