WebSocket vs 폴링 vs SSE

Source: Dev.to

클래식 요청‑응답 모델 (및 그 한계)

표준 웹 앱 작동 방식

• 클라이언트(브라우저/앱)가 서버에 요청을 보냅니다.
• 서버가 이를 처리합니다(데이터베이스 접근, 연산 등).
• 서버가 응답을 반환합니다.
• 연결이 종료됩니다.

이 사이클은 대부분의 애플리케이션에 대해 간단하고 효율적입니다.

핵심 문제: 응답이 전송된 후, 클라이언트가 다시 요청하지 않으면 서버가 새로운 데이터를 푸시할 수 없습니다.

예시: 주식 시장 앱

• 클라이언트 A, B, C가 연결되어 현재 주가를 요청합니다.
• 서버가 응답하고 연결이 종료됩니다.
• 이후 서버에서 가격이 변동하지만, 클라이언트 A, B, C는 여전히 오래된 데이터를 가지고 있습니다.

서버는 어떻게 클라이언트에게 데이터가 변경되었음을 알릴 수 있을까요?

솔루션 1: WebSockets

WebSockets는 클라이언트와 서버 사이에 지속적인 전이중 연결을 유지합니다.

이것은 무엇을 의미하나요?

Instead of:

Client → Server → Response → Connection closes

WebSockets keep the connection open:

Client ↔ Server ↔ Client ↔ Server

이를 통해:

• 서버가 언제든지 업데이트를 푸시할 수 있습니다.
• 클라이언트가 언제든지 데이터를 보낼 수 있습니다.
• 양쪽 모두 연결을 닫지 않고 통신할 수 있습니다.

작동 방식 (간단한 다이어그램)

Client                         Server
  | — WebSocket handshake →     |
  |                             |
  | ← Accept & open channel —   |
  |                             |
  | — Updates can flow both →   |
  |                             |

연결이 열리면 양쪽 모두 데이터를 보낼 수 있습니다.

WebSockets의 장점

• ✅ 실시간 업데이트
• ✅ 낮은 지연 시간
• ✅ 전이중 (양방향 통신)

WebSockets의 단점

• ❌ 확장하기 어려움 – 상태 유지형이며 (서버가 모든 연결된 클라이언트를 기억해야 함)
• ❌ 수백만 개의 연결을 다룰 때 수평 확장이 비용이 많이 듭니다.
• ❌ 클러스터 환경에서 서버 간 업데이트 동기화가 필요합니다.

솔루션 2: 폴링

폴링은 WebSocket에 대한 가장 간단한 대안입니다.

폴링이란?

클라이언트가 서버에 새 데이터를 반복적으로 요청합니다:

Client: “Any new updates?”
Server: “Nope.”
Client: “Any new updates?”
Server: “Yes — here you go!”

간단한 폴링 예시

클라이언트가 2 seconds마다 확인한다면:

0 s → “Give me new data”
2 s → “Give me new data”
4 s → “Give me new data”
…

새 데이터가 3.5 s에 나타나면, 클라이언트는 다음 폴링 시점인 4 s에 데이터를 받습니다.
최대 지연 시간은 폴링 간격과 같습니다.

폴링의 장점

• ✅ 구현이 쉬움
• ✅ 로드 밸런서 및 다수의 서버와 호환
• ✅ 무상태 – 각 요청이 독립적

폴링의 단점

• ❌ 진정한 실시간이 아님
• ❌ 새로운 데이터가 없을 때 요청을 낭비함
• ❌ 빈번한 폴링은 네트워크 부하를 증가시킬 수 있음

Solution 3: Long Polling

Long polling은 최적화된 형태의 폴링입니다.

What Is Long Polling?

서버는 요청을 열어 둔 채 다음 상황이 될 때까지 기다립니다:

• 새로운 데이터가 도착하거나, 혹은
• 타임아웃이 만료될 때

그 후 한 번에 데이터를 응답합니다.

Example: Long Polling for 5 Seconds

Client → Server: “Any updates?”
Server: Hold request for up to 5 seconds

If updates come within 5 s:
  Server → Client: Latest updates
  Client immediately re‑requests.

Pros of Long Polling

• ✅ 짧은 폴링보다 요청 수가 적음
• ✅ 단순 폴링보다 “실시간” 느낌이 더 강함
• ✅ 여전히 무상태(stateless)

Cons of Long Polling

• ❌ 대기 중에 서버 자원을 점유함
• ❌ WebSocket만큼 즉각적이지 않음
• ❌ 서버가 보류된 요청을 관리해야 함

접근 방식 비교

실제 상황 고려사항

항상 전체 실시간이 필요합니까?

반드시 그렇지는 않습니다. 주식 차트 앱에서는 최신 가격 업데이트만 필요하고, 매매는 일반 POST API 라우트를 사용할 수 있습니다. 이런 경우:

• WebSocket은 과도할 수 있습니다.
• 폴링이나 롱 폴링이 충분히 적합합니다.

로드 밸런서와 함께 폴링이 잘 작동하는 이유

다수의 백엔드 서버가 로드 밸런서 뒤에 배치될 때:

• 폴링 요청이 서버들에 고르게 분산됩니다.
• 어떤 서버도 지속적인 연결을 유지하지 않습니다.
• 서버가 장애가 나면, 다음 폴링이 다른 정상 서버로 라우팅됩니다.

최종 생각

• 즉시 푸시 업데이트가 필요합니까? → WebSockets
• 경량이며 확장 가능한 업데이트가 필요합니까? → Polling / Long Polling
• 두 가지를 모두 원하십니까? → Start with polling and evolve as needed

Every choice has trade‑offs. Understanding the fundamental communication patterns helps you make the best architectural decision and avoids unnecessary complexity early on.