WebSocket vs SSE, 실시간 기능 선택 기준

실시간 기능을 붙일 때 반사적으로 WebSocket을 고르는 경우가 많은데, 절반 이상은 SSE로 충분하고 운영은 훨씬 편하다.

방향부터 따져라

핵심 질문은 하나다. 클라이언트→서버 실시간 전송이 필요한가?

• 알림, 피드 갱신, 진행률, 주가/시세: 서버→클라이언트 단방향 → SSE
• 채팅, 협업 편집, 게임: 양방향 → WebSocket

클라이언트가 보내는 건 어차피 HTTP POST로 하면 되는 경우가 대부분이다. "실시간처럼 보이는 기능"의 다수는 단방향이다.

SSE의 운영상 장점

// 서버 (Next.js route handler)
export async function GET() {
  const stream = new ReadableStream({
    start(controller) {
      const send = (data: unknown) =>
        controller.enqueue(`data: ${JSON.stringify(data)}\n\n`);
      // 구독 로직...
    },
  });
  return new Response(stream, {
    headers: { "content-type": "text/event-stream" },
  });
}

그냥 HTTP다. 프록시, 로드밸런서, CDN, 인증 미들웨어가 전부 그대로 동작한다. 재연결도 브라우저 EventSource가 Last-Event-ID까지 챙겨서 알아서 해 준다. WebSocket은 이 모든 걸 직접 챙겨야 한다.

WebSocket을 골랐다면

• 하트비트(ping/pong)와 재연결 백오프는 1일차에 구현하라. 안 하면 모바일 네트워크에서 유령 연결이 쌓인다
• 스케일아웃 시 연결이 서버에 고정되므로 브로드캐스트용 Redis pub/sub이 사실상 필수
• 서버리스와 궁합이 나쁘다. 연결 유지 비용이 과금과 직결된다

정리

단방향이면 SSE, 양방향이면 WebSocket, 둘 다 애매하면 폴링부터. 3초 폴링이 부끄러운 선택 같지만 유저 수백 명 규모에선 가장 견고한 선택인 경우도 많다.