웹소켓 (WebSocket)

SSE, Socket.IO와의 차이

실시간 통신 기술을 고를 때 자주 비교되는 대상이 서버 전송 이벤트(SSE, Server-Sent Events)와 Socket.IO다.

서버가 일방적으로 알림이나 진행 상황을 흘려보내기만 하면 되는 경우에는 SSE가 더 단순하고 HTTP 인프라를 그대로 활용할 수 있어 유리하다. Socket.IO는 웹소켓 그 자체가 아니라 웹소켓을 우선 사용하되 실패 시 롱 폴링으로 폴백하고, 재연결과 룸(room) 브로드캐스트 같은 편의 기능을 얹은 라이브러리라는 점을 구분해서 말할 수 있어야 한다. 따라서 Socket.IO 클라이언트는 표준 웹소켓 서버와 직접 통신할 수 없다.

실무 예시와 운영 시 고려 사항

브라우저에서는 표준 WebSocket API로 간단히 연결할 수 있다.

const socket = new WebSocket("wss://api.devfit.dev/chat");

socket.addEventListener("open", () => {
  socket.send(JSON.stringify({ type: "join", room: "interview" }));
});

socket.addEventListener("message", (event) => {
  const data = JSON.parse(event.data);
  console.log("수신:", data);
});

socket.addEventListener("close", () => {
  // 지수 백오프로 재연결을 시도한다
});

운영 단계에서는 다음을 함께 설계해야 한다. 첫째, 연결이 끊겼을 때를 대비한 하트비트(ping/pong)와 지수 백오프 재연결 로직이 필요하다. 둘째, 웹소켓은 서버에 연결 상태를 남기는 스테이트풀 통신이므로 서버를 여러 대로 늘리면 Redis Pub/Sub 같은 메시지 브로커로 서버 간 브로드캐스트를 중계해야 한다. 셋째, 로드 밸런서와 리버스 프록시가 Upgrade 헤더를 통과시키도록 설정하고 유휴 타임아웃을 하트비트 주기보다 길게 잡아야 한다. 넷째, 인증은 핸드셰이크 시점의 쿠키나 최초 메시지의 토큰으로 처리하고 연결 수명 동안의 만료 정책도 정해 두어야 한다.

면접에서 이렇게 물어본다

• HTTP 폴링, 롱 폴링, 웹소켓의 동작 차이를 트래픽과 지연 관점에서 비교해 보라.
• 웹소켓 핸드셰이크 과정을 설명하고 Sec-WebSocket-Key가 왜 필요한지 말해 보라.
• SSE와 웹소켓 중 하나를 선택해야 한다면 어떤 기준으로 판단하겠는가.
• Socket.IO는 웹소켓과 무엇이 다르며, 표준 웹소켓 서버와 호환되지 않는 이유는 무엇인가.
• 웹소켓 서버를 수평 확장할 때 생기는 문제와 해결 방법을 설명해 보라.