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

· 18분 읽기 · 수정 intermediate tutorial
[2026] WebSocket vs SSE vs 롱 폴링 | 실시간 통신 방식 비교

이 글의 핵심

실시간 웹에서 자주 쓰는 세 가지 패턴 — 양방향은 WebSocket, 서버 푸시 단방향은 SSE, 호환성 우선은 롱 폴링. 선택 기준과 구현 요점, WebSocket 프로토콜(RFC 6455) 핵심을 함께 정리합니다.

세 가지 패턴 비교

롱 폴링SSEWebSocket
방향서버 → 클라이언트서버 → 클라이언트양방향
프로토콜HTTPHTTPWS(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은 직접 백오프 로직을 두는 경우가 많습니다.

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「[2026] WebSocket vs SSE vs 롱 폴링 | 실시간 통신 방식 비교」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]
sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)
  • 불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
  • 결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
  • 경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
  • 백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역운영 관점 질문
관측성요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「[2026] WebSocket vs SSE vs 롱 폴링 | 실시간 통신 방식 비교」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

  1. 입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
  2. 핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
  3. 실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
  4. 호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
  5. 부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.
handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상가능 원인조치
간헐적 실패레이스, 타임아웃, 외부 의존성, DNS최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패환경 변수, 권한, 플랫폼 차이, lockfileCI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치프로필·시크릿·기본값, 리전스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치비멱등 재시도, 부분 쓰기, 캐시 무효화 누락멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.