상황에 맞는 실시간 통신 선택법

지연 시간 목표를 만족하는 가장 단순한 도구를 골라

네 가지 실시간 통신 방식에 우열은 없어. 상황에 맞춰 고르는 선택표에 가까워. 답은 세 질문에 달렸지. 방향 은 일방향인가 양방향인가, 빈도 는 분당 한 번인가 초당 열 번인가, 허용 지연 시간 은 30초도 괜찮은가 100ms 미만이어야 하는가?

선택 흐름

분당 한 번 새 데이터가 필요하다면 polling 으로 충분해. 서버에서 클라이언트로만 밀어 준다면 SSE 가 가장 가벼운 답이고, 양쪽이 자주 밀어 주면서 지연 시간도 짧아야 한다면 WebSocket 이 맞아. 양쪽 모두 자주 보내지 않고 데이터가 요청과 응답의 모양에 잘 맞는다면 실시간 통신 자체를 쓰지 않는 게 좋아.

혼합 구성이 보통이야

운영 중인 시스템 대부분은 여러 방식을 섞어 써. cwkPippa 는 대화 CRUD 에 REST, AI 토큰 전송에 SSE, 장비 상태 확인에 polling 을 사용해. ChatGPT 는 사용자 입력을 HTTP POST 로 보내고 답변은 SSE 로 전송하지. Slack 은 채팅에 WebSocket, 일부 알림에 SSE, 모든 CRUD 에 REST 를 써. 실시간 통신은 도구 하나로 끝나는 문제가 아니야.

Code

통신 방식 선택 흐름도·text

  Do you need real-time updates at all?
  |-- No  -> Use plain HTTP/REST.
  |-- Yes
      |-- Server -> Client only?
      |   |-- Yes -> SSE (Server-Sent Events).
      |   |-- No (bidirectional)
      |       |-- Frequency low + latency tolerant -> long polling can suffice.
      |       |-- Frequency high or latency tight  -> WebSocket.
      |-- Need binary frames?
          |-- Yes -> WebSocket (SSE is text-only).

한눈에 보는 비교표·text

| Approach     | Direction        | Latency      | Complexity | Best for                           |
| ------------ | ---------------- | ------------ | ---------- | ---------------------------------- |
| Polling      | client-driven    | interval     | very low   | dashboards refreshing every 30s+   |
| Long Polling | server -> client | low-medium   | medium     | legacy, when SSE/WS blocked        |
| SSE          | server -> client | low          | low        | AI streaming, notifications, feeds |
| WebSocket    | bidirectional    | very low     | higher     | chat, collab, gaming, trading      |

Exercise

다음 기능마다 알맞은 방식(polling, long polling, SSE, WebSocket) 을 고르고 그 이유를 한 줄씩 적어 봐. (a) GitHub Actions 빌드 상태 배지, (b) Figma 의 실시간 커서, (c) 읽지 않은 메일 수 알림 배지, (d) Discord 채팅, (e) ChatGPT 답변 전송, (f) 공개 홈페이지의 실시간 주가 표시. 각 항목에는 근거를 댈 수 있는 답이 하나씩 있어.