LabHub

블로그

2026년 실시간 웹 — WebSocket·SSE·WebTransport·WebRTC 심층 비교 (LLM 스트리밍이 SSE를 선택한 이유까지)

2026-05-14 · 36 분 읽기 · #realtime-web#websocket#sse#webtransport#webrtc#http3#quic#streaming#llm-streaming#communication

한국어English日本語

프롤로그 — "실시간"이라는 단어의 함정

"실시간 기능을 넣어주세요"라는 요청을 받는다. 머리에 가장 먼저 떠오르는 단어는 WebSocket이다. 그래서 일단 WS 서버를 띄우고, 라우터 뒤에 sticky session을 붙이고, 토큰 인증을 얹는다. 6개월 뒤, 같은 회사의 다른 팀이 LLM 토큰을 스트리밍하는데 — 이상하게도 — SSE를 쓰고 있다. 한 명은 묻는다: "왜 WebSocket이 아니지?"

답은 단순하지 않다. "실시간"은 단일 문제가 아니라 스펙트럼이다.

각 문제에 맞는 프로토콜은 다르다. 이 글은 2026년 시점의 다섯 가지 후보 — WebSocket, Server-Sent Events(SSE), WebTransport, WebRTC DataChannel, Long Polling — 를 비교한다. 보너스로 HTTP/2 Server Push가 왜 죽었는지, 그리고 LLM 스트리밍이 거의 모두 SSE로 수렴한 진짜 이유까지.

TL;DR. 한 방향 스트리밍이면 SSE. 양방향 저지연이면 WebSocket. 게임처럼 비신뢰·다중 스트림이면 WebTransport. P2P 또는 미디어면 WebRTC. 그리고 — 정직하게 — "그냥 polling"으로 충분한 경우가 많다.

1장 · 풍경 — 2026년 다섯 가지 프로토콜

        브라우저 ◀──────── 서버 (또는 다른 브라우저)
        ─────────────────────────────────────────────
        WebSocket          양방향, TCP, 프레임 기반
        SSE (EventSource)  서버→클라 단방향, HTTP 위
        WebTransport       양방향, QUIC/HTTP3, 다중화
        WebRTC DataChannel P2P, UDP/SCTP, 비신뢰 가능
        Long Polling       HTTP 폴링, 응답 보류

각 프로토콜을 한 문장으로 요약하면:

그리고 죽은 사람: HTTP/2 Server Push. Chrome이 2022년에 비활성화했고, 명세에서 제거가 진행됐다. 캐시 동작이 미묘하고 실제 성능 이득이 적었다.

2장 · WebSocket — 여전히 일꾼, 여전히 함정

WebSocket은 2011년 RFC 6455로 표준화됐다. 핵심은 단순하다: HTTP/1.1 Upgrade 헤더로 연결을 시작해, 그 후엔 TCP 위에 자체 프레임(텍스트/바이너리/Ping/Close)을 양방향으로 흘린다.

머릿속 모델

        Client                          Server
          │  GET /ws HTTP/1.1               │
          │  Upgrade: websocket             │
          │ ──────────────────────────────▶ │
          │                                 │
          │ ◀────────────────────────────── │
          │  HTTP/1.1 101 Switching         │
          │                                 │
          │   ◀══════ frame ══════▶         │  (양방향)
          │   ◀══════ frame ══════▶         │
          │                                 │
          │   Close 0x88                    │

Upgrade 핸드셰이크가 끝나면 그 TCP 연결은 더 이상 HTTP가 아니다. 그래서 라우터·로드밸런서·프록시·CDN의 동작이 미묘해진다.

강점

함정

  1. HTTP/2가 아니다. WS 자체는 HTTP/1.1 업그레이드다. RFC 8441로 HTTP/2 위 WebSocket이 가능하지만 서버 구현이 들쭉날쭉.
  2. 로드밸런서 sticky session. WS 연결은 같은 백엔드 인스턴스에 고정되어야 한다 — Pub/Sub 같은 fan-out 계층이 필요.
  3. 헤드 오브 라인 블로킹. 단일 TCP라, 한 메시지가 큰 페이로드면 그 뒤가 막힌다.
  4. 자동 재연결 없음. 직접 짜야 함 — exponential backoff, 메시지 재전송 큐, sequence number.
  5. 프록시 비호환. 일부 기업 프록시는 WS 핸드셰이크를 끊는다.
  6. HTTP 캐시 우회. GET이 아니므로 CDN 캐시 혜택 없음.

작은 채팅 서버 (Bun + ws 스타일)

// server.ts — 미니멀 WS 에코·브로드캐스트
import { WebSocketServer } from 'ws'

const wss = new WebSocketServer({ port: 8080 })
const clients = new Set<WebSocket>()

wss.on('connection', (ws) => {
  clients.add(ws)
  ws.send(JSON.stringify({ type: 'welcome', count: clients.size }))

  ws.on('message', (raw) => {
    const msg = JSON.parse(raw.toString())
    // 모든 다른 클라이언트에게 브로드캐스트
    for (const c of clients) {
      if (c !== ws && c.readyState === 1) {
        c.send(JSON.stringify({ ...msg, ts: Date.now() }))
      }
    }
  })

  ws.on('close', () => clients.delete(ws))
})

클라이언트 쪽:

const ws = new WebSocket('wss://example.com/ws')
ws.onopen = () => ws.send(JSON.stringify({ type: 'hello', name: '준' }))
ws.onmessage = (e) => console.log('recv:', JSON.parse(e.data))
ws.onclose = () => {
  // 직접 재연결 로직을 작성해야 한다 — 백오프, jitter, 인증 토큰 갱신…
}

이게 끝이 아니다. 프로덕션은 — 인증·하트비트·재연결·메시지 큐·롤아웃 시 graceful drain — 까지 합쳐 수백 줄로 자란다.

3장 · Server-Sent Events — LLM 스트리밍이 고른 우승자

SSE는 2009년에 HTML5 명세로 들어왔다. 너무 단순해서 처음엔 우습게 봤지만, 2024~2026년의 LLM 스트리밍 붐과 함께 사실상 표준이 됐다.

머릿속 모델

        Client                                Server
          │ GET /stream HTTP/1.1                 │
          │ Accept: text/event-stream            │
          │ ──────────────────────────────────▶  │
          │                                      │
          │ ◀──────────────────────────────────  │
          │ HTTP/1.1 200 OK                      │
          │ Content-Type: text/event-stream      │
          │                                      │
          │ ◀── data: {"token":"안녕"}\n\n      │
          │ ◀── data: {"token":"하세요"}\n\n    │
          │ ◀── data: [DONE]\n\n                 │
          │                                      │
          │  (응답이 영원히 안 닫힘)              │

연결은 그냥 HTTP 응답이다. 서버는 응답을 닫지 않고 data: ...\n\n 형식으로 한 줄씩 흘려보낸다. 클라이언트는 EventSource 객체로 자동 파싱·재연결한다.

강점

약점

왜 LLM 스트리밍이 SSE를 골랐는가

OpenAI, Anthropic, Google Gemini, Cohere — 거의 모든 LLM 토큰 스트리밍 API는 SSE다. 자료: OpenAI Streaming docs https://platform.openai.com/docs/api-reference/streaming, Anthropic Messages Streaming https://docs.anthropic.com/en/api/messages-streaming. 이유는 일곱 가지:

  1. 본질적으로 단방향. 프롬프트는 한 번에 POST, 답은 토큰별로 흐른다. WS의 양방향이 필요 없다.
  2. 재시도가 자연스럽다. 보통의 HTTP 재시도 정책(429, 500, 5xx)이 그대로 작동.
  3. 인증·rate limit·과금이 표준 HTTP 미들웨어로 들어간다. WS는 매번 직접 짜야 함.
  4. 방화벽·프록시 통과. 기업망에서 WS는 막힐 수 있음.
  5. CDN과 호환. Cloudflare·Vercel Edge Functions가 SSE를 일급으로 지원.
  6. 테스트가 쉽다. curl -N이면 끝.
  7. HTTP/2·HTTP/3에서 멀티플렉싱이 공짜. 동시 스트림이 한 연결을 공유.

WebSocket을 쓰면 이 일곱 가지가 전부 직접 작성 항목이 된다.

30줄 토큰 스트리머 (Bun/Node)

// app/api/chat/route.ts — 30줄 SSE 토큰 스트리머
export const runtime = 'edge'

export async function POST(req: Request) {
  const { prompt } = await req.json()

  const stream = new ReadableStream({
    async start(controller) {
      const encoder = new TextEncoder()
      const send = (data: unknown) => {
        controller.enqueue(encoder.encode(`data: ${JSON.stringify(data)}\n\n`))
      }

      // 가상 LLM: 토큰을 50 ms마다 보냄
      const tokens = ['안녕', '하세요', ',', ' SSE', ' 데모', '입니다', '.']
      for (const t of tokens) {
        send({ token: t })
        await new Promise((r) => setTimeout(r, 50))
      }
      send('[DONE]')
      controller.close()
    },
  })

  return new Response(stream, {
    headers: {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache, no-transform',
      Connection: 'keep-alive',
    },
  })
}

클라이언트 — EventSource는 POST를 못 받으므로 fetch 스트리밍 또는 SSE 라이브러리(예: eventsource-parser)를 쓴다.

const res = await fetch('/api/chat', {
  method: 'POST',
  body: JSON.stringify({ prompt: '안녕' }),
  headers: { 'Content-Type': 'application/json' },
})
const reader = res.body!.getReader()
const decoder = new TextDecoder()
let buf = ''
while (true) {
  const { done, value } = await reader.read()
  if (done) break
  buf += decoder.decode(value, { stream: true })
  for (const line of buf.split('\n\n')) {
    if (line.startsWith('data: ')) console.log(line.slice(6))
  }
  buf = ''
}

이게 ChatGPT·Claude UI 토큰 스트리밍의 모습이다. 40줄로 끝난다.

4장 · WebTransport — HTTP/3 시대의 새 일꾼

WebTransport는 IETF가 2024년 RFC 9484로 표준화한 새 프로토콜이다. QUIC 위의 양방향 + 데이터그램을 한 연결로 제공한다. 자료: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API.

머릿속 모델

        브라우저 ──────── QUIC (UDP 위) ──────── 서버
                │
                ├── 양방향 신뢰 스트림 #1
                ├── 양방향 신뢰 스트림 #2
                ├── 단방향 신뢰 스트림 #3
                └── 비신뢰 데이터그램 (UDP-스럽게)

한 QUIC 연결 위에서 여러 스트림을 동시에. 한 스트림의 패킷 로스가 다른 스트림을 막지 않는다 — 헤드 오브 라인 블로킹이 없다. WebSocket의 가장 큰 약점이 사라진 셈.

2026년 브라우저 지원 현황

서버 구현: aioquic(Python), quinn(Rust), msquic(MS), Cloudflare Workers WebTransport API. 자료: https://github.com/aiortc/aioquic.

강점

약점

데이터그램 데모

// 게임 좌표를 30 fps로 비신뢰 데이터그램으로 보냄
const transport = new WebTransport('https://game.example.com/wt')
await transport.ready

const writer = transport.datagrams.writable.getWriter()
const reader = transport.datagrams.readable.getReader()

// 송신: 좌표 패킷
setInterval(async () => {
  const buf = new ArrayBuffer(8)
  const view = new DataView(buf)
  view.setFloat32(0, player.x)
  view.setFloat32(4, player.y)
  await writer.write(new Uint8Array(buf))
}, 33)

// 수신: 상대 좌표
;(async () => {
  while (true) {
    const { value, done } = await reader.read()
    if (done) break
    const view = new DataView(value.buffer)
    other.x = view.getFloat32(0)
    other.y = view.getFloat32(4)
  }
})()

이걸 WebSocket으로 똑같이 하면 — 좌표 한 패킷이 늦으면 그 뒤가 막힌다. WebTransport는 그냥 새 데이터그램이다. 잃어버리면 잃어버린 채로.

5장 · WebRTC DataChannel — P2P의 왕, 운영의 지옥

WebRTC는 본래 화상 통화용으로 만들어졌다. RTCDataChannel은 비디오/오디오 트랙과 같은 P2P 연결 위에 임의 데이터를 흘릴 수 있게 해주는 보조 API다.

머릿속 모델

        Peer A                         Peer B
          │       (시그널링 서버)        │
          │ ───── SDP offer ────────▶   │
          │ ◀──── SDP answer ─────────  │
          │ ───── ICE candidates ───▶   │
          │ ◀──── ICE candidates ─────  │
          │                              │
          │  ╔════ P2P SCTP/UDP ════╗   │
          │  ║   DataChannel        ║   │
          │  ║   Video/Audio        ║   │
          │  ╚══════════════════════╝   │

핵심은 시그널링은 별도라는 점이다. WebRTC는 두 피어의 IP·포트·미디어 능력을 협상하는 동안 메시지를 전달할 채널이 필요하다 — 그게 시그널링 서버다(보통 WebSocket이나 SSE로 구현).

강점

약점

언제 쓰나

LLM 토큰 스트리밍에 WebRTC를 쓰는 사람은 없다. 그 칼은 사용처가 좁고 운영 부담이 크다.

6장 · Long Polling — 옛 친구, 죽지 않았다

브라우저는 HTTP/1.1 시절부터 polling을 했고, 그게 진화한 게 Long Polling이다. 클라가 GET을 보내면 서버는 응답을 즉시 닫지 않고 이벤트가 생길 때까지 보류한다. 이벤트가 생기면 응답하고, 클라는 즉시 다시 GET.

머릿속 모델

        Client                        Server
          │ GET /events                  │
          │ ──────────────────────────▶  │
          │                              │ (이벤트 대기, 보류)
          │                              │
          │                              │ 이벤트 발생!
          │ ◀────── 200 OK [event] ───── │
          │ GET /events?since=...        │
          │ ──────────────────────────▶  │
          │                              │ (또 대기)

지금 봐도 단순하고, 동작 안 하는 환경이 없다.

강점

약점

2026년 현실

여전히 살아 있다. 특히 — 모바일 SDK 폴백, 사내 LAN 채팅, 알림 시스템 — 에서. 그리고 SSE를 못 쓰는 환경(IE는 죽었지만 일부 임베디드 브라우저)에서. "쿨"하지 않다고 무시하면 안 된다.

7장 · 죽은 자 — HTTP/2 Server Push의 짧은 생애

HTTP/2 Server Push는 2015년에 등장했다. 아이디어는 깔끔했다 — 클라가 요청하기 전에 서버가 미리 리소스를 푸시. 페이지가 빨라지리라.

현실은 실망스러웠다. Chrome 텔레메트리(2020~2021)에서 대다수 푸시가 — 이미 캐시에 있어서 — 낭비됐다. 캐시 동작이 미묘했고, 구현이 일관되지 않았다. Chrome은 2022년에 비활성화했다. 자료: https://developer.chrome.com/blog/removing-push. 명세에서도 제거됐다.

대안. 진짜 리소스 푸시가 필요하면 103 Early Hints + <link rel=preload>. 메시지 푸시면 SSE.

8장 · 의사결정 매트릭스

유스 케이스1순위대안비고
LLM 토큰 스트리밍SSEWS서버→클라 단방향, 재시도·CDN 친화
채팅 (1:1, 1:다)WebSocketSSE+POST양방향 저지연
멀티플레이어 게임 (실시간)WebTransportWebRTC비신뢰 데이터그램, no HoL blocking
대시보드·실시간 메트릭SSEWS단방향, 자동 재연결
협업 편집기 (CRDT)WebSocketWT양방향 + 메시지 순서
화상 통화WebRTC—미디어 + 데이터 한 채널
파일 전송 P2PWebRTCWS 릴레이서버 대역폭 절감
알림 (저빈도)Long PollingSSE서버 자원·복잡도 최소
주식·코인 시세 (브로드캐스트)SSEWS단방향, fan-out 단순
IoT 명령 (양방향)WebSocketWT작은 페이로드, 양방향
폴백 마지막 한 줄Long Polling—어떤 환경도 통과

이 표는 정답이 아니라 시작점이다. 모든 결정에는 트레이드오프가 있고, 팀의 운영 능력·기존 인프라·사용자 환경이 매트릭스를 흔든다.

9장 · 정직한 결정 프레임워크

다섯 가지 질문을 순서대로 던지자.

Q1. 진짜로 양방향인가, 아니면 단방향인가?

LLM 답변은 단방향이다. 프롬프트는 POST 한 번이고, 답은 토큰 스트림. 채팅 메시지도 사실 — 송신은 POST로 끝나고, 수신만 stream — 으로 보면 단방향이다.

진짜 양방향은 두 방향에서 동시에 메시지가 흐를 때다 — 협업 편집의 CRDT 업데이트, 멀티플레이어 게임의 입력/상태, IoT 양방향 명령.

단방향이면 SSE를 먼저 검토. 비용·운영·복잡도가 압도적으로 낮다.

Q2. 신뢰가 필요한가, 비신뢰면 되는가?

채팅 메시지·결제 이벤트·상태 업데이트 — 신뢰가 필수다. TCP·QUIC 스트림.

게임 좌표·VOIP·실시간 센서 — 비신뢰 OK. 한 패킷 빠져도 다음 게 따라잡으면 끝. UDP·QUIC datagram.

비신뢰 필요하면 WebTransport(또는 WebRTC). WS는 비신뢰 모드가 없다.

Q3. P2P가 정말 필요한가?

P2P는 — 정말 — 서버를 거치지 않는 경우만이다. 화상통화, 파일 전송, 진짜 P2P 게임. 그 외에는 클라이언트-서버가 압도적으로 간단하다.

P2P 한다고 결정했으면 STUN + TURN 인프라 비용·운영을 받아들이는 거다. TURN으로 폴백되면 그건 사실상 릴레이고, P2P 이득이 사라진다.

Q4. 기존 인프라는?

회사가 이미 Kafka + Pub/Sub + nginx로 SSE를 잘 돌리고 있다면 — 새 기능에 WS를 넣지 마라. 운영팀이 둘 다 알아야 한다.

WS를 잘 운영 중이라면 — SSE를 새로 도입하는 게 합리적일 수도 있다. 두 프로토콜이 다른 문제를 푼다면.

Q5. 사용자의 네트워크 환경은?

기업망·통신사망에는 — UDP 차단, WS 차단, idle 응답 차단 — 별 게 다 있다. 사용자가 다양한 환경이면 폴백이 필수다.

        WT 시도 ──실패──▶ WS 시도 ──실패──▶ SSE 시도 ──실패──▶ Long Polling

대부분의 프로덕션 실시간 스택은 이 폴백 체인을 어느 정도 갖는다.

10장 · 실전 사례 — 누가 무엇을 쓰는가

패턴이 보인다 — 단방향 스트리밍은 SSE, 양방향 채팅은 WS, 미디어는 WebRTC, 게임은 점진적으로 WT.

11장 · 운영 노트 — 진짜로 아픈 부분들

sticky session

WS·WT는 클라이언트가 같은 백엔드 인스턴스에 묶여야 한다. ALB·Envoy·HAProxy의 sticky session 설정 필요. SSE는 — 응답이 끝까지 한 인스턴스에서 흐르긴 하지만 — 재연결마다 다른 인스턴스로 가도 OK(서버가 stateless하다면).

graceful shutdown

배포할 때 WS 연결을 끊으면 사용자 1만 명이 동시에 재연결을 시도해 thundering herd. 정해진 패턴:

  1. 새 연결을 거부(헬스체크 fail).
  2. 기존 연결에 "곧 끊겠다" 메시지 전송.
  3. 클라가 jitter 두고 자발적 재연결.
  4. 30~60초 후 강제 종료.

SSE도 같은 문제. Long Polling은 — 한 요청이 짧으니 — 운이 좋다.

인증

WS의 Upgrade 핸드셰이크는 HTTP니까 쿠키·헤더·토큰 다 보낼 수 있다. 그러나 — 일부 라이브러리는 핸드셰이크 후 인증을 확인 — 이 패턴은 위험. 핸드셰이크 단계에서 인증하라.

WT는 인증서 기반 + 헤더. SSE는 — 그냥 HTTP니까 — 가장 단순.

WebRTC는 시그널링 서버 단계에서 인증. P2P 연결 자체는 DTLS-SRTP로 암호화.

비용

대규모(연결 10만 이상)에서는 — 한 연결당 메모리 — 가 결정적. Node WS는 약 30~50 KB/연결, Go·Rust는 5~15 KB. 언어 선택이 운영비를 좌우.

모니터링

OpenTelemetry는 — WS 일부, SSE 완전, WT는 2026년 시점 진행 중 — 지원이 다르다.

12장 · 직접 만들어보는 WT 데이터그램 서버 (Node + aiortc 없이)

브라우저 데모는 위에 있고, 서버는 Rust wtransport나 Python aioquic가 가장 흔하다. Node는 2026년 5월 현재 @fails-components/webtransport 같은 패키지가 가장 성숙.

// server.ts — 최소 WebTransport 데이터그램 에코
import { Http3Server } from '@fails-components/webtransport'
import { readFileSync } from 'node:fs'

const server = new Http3Server({
  port: 4433,
  host: '0.0.0.0',
  secret: 'demo',
  cert: readFileSync('./cert.pem'),
  privKey: readFileSync('./key.pem'),
})
server.startServer()

const stream = await server.sessionStream('/wt')
const reader = stream.getReader()
while (true) {
  const { value: session, done } = await reader.read()
  if (done) break

  await session.ready
  const dgReader = session.datagrams.readable.getReader()
  const dgWriter = session.datagrams.writable.getWriter()

  ;(async () => {
    while (true) {
      const { value, done } = await dgReader.read()
      if (done) break
      // 에코백
      await dgWriter.write(value)
    }
  })()
}

데모용 인증서가 필요하고(브라우저가 자체서명을 받으려면 serverCertificateHashes 옵션 필요), Chrome 플래그를 켜서 테스트.

13장 · 안티패턴 10가지

  1. 모든 실시간 요구사항에 WebSocket 반사적으로 선택. 단방향이면 SSE가 더 단순·저렴.
  2. 인증을 핸드셰이크 이후에. WS upgrade 단계에서 인증하지 않으면 미인증 연결을 잠시 받게 됨.
  3. 자동 재연결을 직접 짜지 않음. 모바일 네트워크에서 끊김은 일상.
  4. 하트비트 없음. idle 프록시가 30초 후 끊을 때 모름.
  5. 메시지 sequence ID 없음. 재연결 후 중복·결손 메시지를 못 잡음.
  6. graceful shutdown 없이 재배포. thundering herd 자가 DDoS.
  7. 거대한 단일 메시지. WS의 head-of-line blocking을 자기 손으로 트리거.
  8. WebRTC를 P2P 아닌 곳에. 클라이언트-서버면 WS·WT가 더 간단.
  9. HTTP/2 Server Push를 부활시키려고 시도. 죽은 자다.
  10. 폴백 체인 없음. 사용자의 30%가 회사 프록시 뒤에 있을 수 있음.

14장 · 2026년 예측과 미래

LLM 시대 이후의 실시간 웹은 — 한 프로토콜이 모든 걸 푸는 게 아니라 — 유스 케이스별로 최적 도구를 고르는 시대다. WS가 모든 걸 풀던 2010년대는 끝났다.

에필로그 — 프로토콜은 도구다

이 글의 한 문장 요약: "실시간"이라는 단어를 보면 먼저 양방향인지 단방향인지를 묻고, 그다음 신뢰·비신뢰를 묻고, 그다음 P2P 여부를 묻는다. 세 질문이 4~5 줄이면 답이 나온다.

LLM 토큰 스트리밍이 SSE를 고른 건 SSE가 "최고"여서가 아니다. 그 문제에 SSE가 가장 단순한 답이기 때문이다. 같은 논리로, 협업 편집은 WebSocket이 가장 단순하고, 게임 좌표는 WebTransport가 가장 자연스럽다.

도구를 사랑하지 말고, 문제를 사랑하자.

14개 항목 체크리스트

  1. 양방향이 진짜 필요한가, 사실은 단방향인가?
  2. 신뢰가 필수인가, 비신뢰면 되는가?
  3. P2P가 정말 필요한가?
  4. 사용자 네트워크 환경(기업망·모바일·해외)을 가정했는가?
  5. 폴백 체인이 있는가?
  6. 인증을 핸드셰이크 단계에서 하는가?
  7. 자동 재연결 + 백오프 + jitter가 있는가?
  8. 하트비트·idle ping이 있는가?
  9. 메시지 sequence ID와 재개 메커니즘이 있는가?
  10. graceful shutdown 절차가 있는가?
  11. sticky session·세션 친화도 설정이 라우터에 있는가?
  12. 연결당 메모리 비용을 측정했는가?
  13. 모니터링·SLO가 정의돼 있는가?
  14. (LLM이면) SSE를 먼저 검토했는가?

안티패턴 10가지 (요약)

  1. 단방향에 WebSocket.
  2. 인증 늦음.
  3. 재연결 없음.
  4. 하트비트 없음.
  5. sequence ID 없음.
  6. graceful shutdown 없음.
  7. 거대 단일 메시지.
  8. WebRTC를 P2P 아닌 곳에.
  9. HTTP/2 Server Push 부활 시도.
  10. 폴백 체인 없음.

다음 글 예고

다음 글 후보: 에지 런타임 위 SSE — Vercel/Cloudflare/Deno에서 LLM 토큰 스트리밍 패턴 비교, MoQ(Media over QUIC) 입문 — 차세대 라이브 미디어, CRDT + WebSocket — 협업 편집의 운영 노트.

"실시간 웹의 다음 10년은 한 프로토콜이 아니라 — 문제에 맞는 도구를 고르는 — 시대다. 단방향이면 SSE, 양방향이면 WebSocket, 비신뢰 다중 스트림이면 WebTransport, P2P면 WebRTC. 그리고 그래도 모자라면 Long Polling은 죽지 않았다."

— 2026 실시간 웹 심층, 끝.

참고 / References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-14-realtime-web-2026-webtransport-webrtc-server-sent-events-websocket-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다