WebSocket vs SSE vs 롱 폴링 | 실시간 통신 방식 비교

세 가지 패턴 비교

	롱 폴링	SSE	WebSocket
방향	서버 → 클라이언트	서버 → 클라이언트	양방향
프로토콜	HTTP	HTTP	WS(HTTP 업그레이드)
지연	높음(왕복)	낮음	매우 낮음
복잡도	낮음	낮음	중간
자동 재연결	수동	브라우저(EventSource)	수동(또는 라이브러리)
HTTP/2	예	예(멀티플렉싱)	별도(업그레이드 후 WS 프레임)
로드밸런서	단순	단순	스티키 세션 등 설계 필요
브라우저	넓음	넓음	IE10+ 수준에서 넓음

---

1. 롱 폴링

클라이언트가 요청을 보내면 서버가 데이터가 생기거나 타임아웃될 때까지 연결을 붙잡습니다. 응답을 받은 뒤 클라이언트는 곧바로 다시 요청합니다.

서버 (Node.js)

const waiters = new Map()  // requestId → { res, timeout }

app.get('/api/updates', async (req, res) => {
  const clientId = req.query.clientId
  const lastEventId = parseInt(req.query.lastId ?? '0')

  const pending = await getPendingEvents(clientId, lastEventId)
  if (pending.length > 0) {
    return res.json({ events: pending })
  }

  const timeout = setTimeout(() => {
    waiters.delete(clientId)
    res.json({ events: [] })
  }, 30000)

  waiters.set(clientId, { res, timeout })

  req.on('close', () => {
    clearTimeout(waiters.get(clientId)?.timeout)
    waiters.delete(clientId)
  })
})

function publishEvent(clientId, event) {
  const waiter = waiters.get(clientId)
  if (waiter) {
    clearTimeout(waiter.timeout)
    waiters.delete(clientId)
    waiter.res.json({ events: [event] })
  }
}

클라이언트

async function poll(clientId, lastId = 0) {
  try {
    const res = await fetch(`/api/updates?clientId=${clientId}&lastId=${lastId}`)
    const { events } = await res.json()
    for (const event of events) {
      handleEvent(event)
      lastId = event.id
    }
  } catch (err) {
    await new Promise(r => setTimeout(r, 2000))
  }
  poll(clientId, lastId)
}

쓰기 좋을 때: WebSocket/SSE를 쓰기 어려운 환경(구형 프록시, 내부 방화벽)에서 “거의 실시간”이 필요할 때.

---

2. Server-Sent Events (SSE)

클라이언트에서 서버로 한 번 연결을 열으며, 서버가 이벤트를 푸시합니다. 클라이언트→서버 데이터는 별도 요청이 필요합니다.

서버

app.get('/api/events', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream')
  res.setHeader('Cache-Control', 'no-cache')
  res.setHeader('Connection', 'keep-alive')
  res.setHeader('X-Accel-Buffering', 'no')

  res.write(':connected\n\n')

  function sendEvent(event, data, id) {
    if (id !== undefined) res.write(`id: ${id}\n`)
    if (event) res.write(`event: ${event}\n`)
    res.write(`data: ${JSON.stringify(data)}\n\n`)
  }

  sendEvent('connected', { clientId: req.query.clientId })

  const subscription = eventBus.subscribe(req.query.clientId, (data) => {
    sendEvent('update', data, data.id)
  })

  const heartbeat = setInterval(() => res.write(':heartbeat\n\n'), 15000)

  req.on('close', () => {
    subscription.unsubscribe()
    clearInterval(heartbeat)
  })
})

AI 스트리밍 예시

app.post('/api/chat', async (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream')
  res.setHeader('Cache-Control', 'no-cache')

  const stream = await openai.chat.completions.create({
    model: 'gpt-4',
    messages: req.body.messages,
    stream: true,
  })

  for await (const chunk of stream) {
    const content = chunk.choices[0]?.delta?.content
    if (content) {
      res.write(`data: ${JSON.stringify({ content })}\n\n`)
    }
  }

  res.write('data: [DONE]\n\n')
  res.end()
})

클라이언트

const es = new EventSource('/api/events?clientId=user-123')

es.onopen = () => console.log('Connected')

es.onmessage = (e) => {
  const data = JSON.parse(e.data)
  console.log('Message:', data)
}

es.addEventListener('update', (e) => {
  const data = JSON.parse(e.data)
  updateUI(data)
})

es.onerror = () => {
  console.log('Reconnecting...')
}

es.close()

쓰기 좋을 때: 알림, 라이브 피드, 대시보드, 토큰 스트리밍처럼 서버→클라이언트 일방향이면 충분할 때.

---

3. WebSocket

전이중(full-duplex) — 양이 언제든 메시지를 보낼 수 있습니다.

서버 (Node.js)

import { WebSocketServer } from 'ws'
import http from 'http'

const server = http.createServer(app)
const wss = new WebSocketServer({ server })
const clients = new Map()

wss.on('connection', (ws, req) => {
  const clientId = getClientId(req)
  clients.set(clientId, ws)

  ws.on('message', (data) => {
    const message = JSON.parse(data.toString())
    handleMessage(clientId, message)
  })

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

  ws.send(JSON.stringify({ type: 'CONNECTED', clientId }))
})

자동 재연결 예시

class ReliableWebSocket {
  constructor(url) {
    this.url = url
    this.handlers = new Map()
    this.reconnectDelay = 1000
    this.connect()
  }
  connect() {
    this.ws = new WebSocket(this.url)
    this.ws.onopen = () => {
      this.reconnectDelay = 1000
      this.emit('connected')
    }
    this.ws.onmessage = (e) => {
      const data = JSON.parse(e.data)
      this.emit(data.type, data)
    }
    this.ws.onclose = () => {
      this.emit('disconnected')
      setTimeout(() => this.connect(), this.reconnectDelay)
      this.reconnectDelay = Math.min(this.reconnectDelay * 2, 30000)
    }
    this.ws.onerror = (err) => console.error(err)
  }
  on(event, handler) {
    this.handlers.set(event, handler)
    return this
  }
  emit(event, data) {
    this.handlers.get(event)?.(data)
  }
  send(type, data) {
    if (this.ws.readyState === WebSocket.OPEN) {
      this.ws.send(JSON.stringify({ type, ...data }))
    }
  }
  close() {
    this.ws.onclose = null
    this.ws.close()
  }
}

쓰기 좋을 때: 채팅, 협업 편집, 게임, 트레이딩 터미널 등 양방향이 필수일 때.

---

WebSocket 프로토콜 요약 (RFC 6455)

프레임워크가 대부분 가려 주지만, 운영 이슈(업그레이드 실패, 유휴 끊김, UTF-8 종료)를 좁히려면 다음 네 가지가 중요합니다.

업그레이드 핸드셰이크 (HTTP → WebSocket)

1. 클라이언트는 GET에 Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Version: 13, Sec-WebSocket-Key(16바이트 랜덤의 Base64)를 넣습니다.
2. 서버는 101 Switching Protocols로 응답하며, Sec-WebSocket-Accept = Base64(SHA1(key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))를 실행하여줍니다.
3. 이후 같은 TCP 연결에는 HTTP 본문이 아니라 WebSocket 프레임이 흐릅니다. 역프록시는 업그레이드 헤더를 그대로 전달해야 합니다.

프레임 구조

프레임 헤더에는 FIN, opcode(텍스트/바이너리/제어), 페이로드 길이, 클라이언트→서버 마스크 비트 등이 있습니다. 큰 메시지는 여러 프레임으로 나뉠 수 있습니다.

텍스트(opcode 1) vs 바이너리(opcode 2)

• 텍스트 — UTF-8만 허용. 잘못된 인코딩은 연결 종료로 이어질 수 있음. JSON에 흔함.
• 바이너리 — 임의 바이트(Protobuf 등). 브라우저에서는 ArrayBuffer/Blob으로 수신.

하트비트: Ping/Pong vs 애플리케이션 JSON

• Ping(9) / Pong(10) — NAT·로드밸런서의 유휴 타임아웃을 넘기기 위한 제어 프레임.
• 앱 레벨 {"type":"ping"}도 널리 씁니다. Ping 주기는 proxy_read_timeout·ALB 유휴 제한보다 짧아야 합니다.

Node·Socket.io·Redis까지 묶은 실무 흐름은 WebSocket 완벽 가이드를 참고하세요.

---

WebSocket 확장

여러 대의 서버에 연결이 흩어지면 한 서버에만 붙어 있는 소켓으로는 다른 인스턴스의 클라이언트에게 바로 보낼 수 없습니다. Redis Pub/Sub 등으로 메시지를 브로드캐스트하는 패턴이 일반적입니다.

await sub.subscribe('messages', (message) => {
  const { targetClientId, data } = JSON.parse(message)
  const ws = localClients.get(targetClientId)
  if (ws?.readyState === 1) ws.send(JSON.stringify(data))
})

---

선택 흐름도

양방향이 필요한가?
  예 → WebSocket (또는 Socket.IO)
  아니오 ↓

서버→클라이언트 스트리밍이 필요한가?
  예 → SSE
  아니오 ↓

장기 연결을 쓸 수 없는가?
  예 → 롱 폴링
  아니오 → 일반 HTTP(주기적 폴링)

특수 케이스:
  LLM 스트리밍 → SSE
  채팅 → WebSocket
  라이브 알림 → SSE
  협업 편집 → WebSocket

---

핵심 정리

• 롱 폴링: 호환성은 좋지만 지연이 가장 크고, 최후의 수단에 가깝습니다.
• SSE: 단순하고 HTTP/2와 잘 맞으며, 서버 푸시·스트리밍에 적합합니다.
• WebSocket: 지연이 가장 낮고 양방향에 적합합니다.
• 확장: WebSocket은 스티키 세션 또는 Redis 등 공유 계층이 필요한 경우가 많습니다.
• 재연결: SSE(EventSource)는 브라우저가 재시도를 돕습니다. WebSocket은 직접 백오프 로직을 두는 경우가 많습니다.

---

자주 묻는 질문 (FAQ)

Q. 이 내용을 실무에서 언제 쓰나요?

A. 실시간 기능에 맞는 기술을 고릅니다. WebSocket, SSE(Server-Sent Events), 롱 폴링을 사용 사례·코드·장단점·RFC 6455 요약까지 비교합니다. 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.

Q. 선행으로 읽으면 좋은 글은?

A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.

Q. 더 깊이 공부하려면?

A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.

---

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

• WebSocket 완벽 가이드 | 실시간 통신·Socket.io·채팅·알림·게임
• HTTP 프로토콜 완벽 가이드 | HTTP/1.1·HTTP/2·HTTP/3·QUIC 비교

---

이 글에서 다루는 키워드 (관련 검색어)

WebSocket, SSE, 실시간, HTTP, 백엔드, 프론트엔드 등으로 검색하시면 이 글이 도움이 됩니다.