WebSocket vs SSE: 실시간 통신 인프라 선택 기준

실시간이라고 다 WebSocket이 아닙니다

채팅, 알림, 실시간 시세, 진행률 표시처럼 "실시간"이라는 말이 붙는 기능은 많습니다. 그런데 이들을 한 묶음으로 보고 전부 WebSocket으로 구현하려 하면, 필요 이상으로 복잡해질 수 있습니다.

둘을 가르는 질문은 하나입니다. 클라이언트도 서버로 무언가를 계속 보내야 하는가, 아니면 서버가 보내주는 것만 받으면 되는가. 채팅이나 게임처럼 양쪽이 수시로 주고받아야 하면 양방향 채널이 필요하고, 알림이나 피드처럼 서버가 새 소식을 밀어주기만 하면 되는 경우라면 단방향으로 충분합니다. 이 차이가 WebSocket과 SSE를 가릅니다.

WebSocket: 양방향 채널

WebSocket은 RFC 6455로 정의된 프로토콜로, 단일 TCP 연결 위에서 양방향(full-duplex) 통신을 제공합니다. 양쪽이 서로 독립적으로, 원할 때 데이터를 보낼 수 있는 채널이죠.

흥미로운 점은 시작이 HTTP라는 것입니다. 클라이언트가 Upgrade: websocket 헤더로 업그레이드를 요청하면, 서버가 HTTP 101 Switching Protocols로 응답하며 연결을 WebSocket으로 전환합니다. 그리고 이 핸드셰이크 이후에는 더 이상 HTTP가 아니라 자체 프레이밍 프로토콜로 데이터를 주고받습니다. 주소 스킴도 ws://와 wss://(보안)를 씁니다.

WebSocket은 텍스트와 바이너리 메시지를 모두 다룰 수 있어, 이미지나 게임 상태 같은 데이터도 보낼 수 있습니다. 다만 한 가지 알아둘 점이 있습니다. RFC 6455에는 자동 재연결 메커니즘이 규정되어 있지 않습니다. 연결이 끊겼을 때 이를 감지하고 다시 잇는 일은 애플리케이션이 직접 처리해야 합니다.

SSE: 서버가 미는 단방향 스트림

SSE(Server-Sent Events)는 WebSocket과 결이 다릅니다. 우선 RFC가 아니라 WHATWG HTML Living Standard의 Server-sent events 섹션에 정의되며, 브라우저에서는 EventSource API로 씁니다.

핵심은 서버에서 클라이언트로 향하는 단방향이라는 점입니다. 클라이언트가 이 연결로 서버에 데이터를 보낼 수는 없습니다. 대신 평범한 HTTP 응답 위에서 동작하고, 응답의 MIME 타입은 text/event-stream입니다. 데이터는 UTF-8 텍스트 전용이라 바이너리는 적합하지 않습니다.

SSE의 큰 장점은 자동 재연결이 사양에 내장되어 있다는 것입니다. 서버가 보내는 스트림의 retry 필드로 재연결 간격을 정할 수 있고, 연결이 끊기면 브라우저가 마지막으로 받은 이벤트의 ID를 Last-Event-ID 헤더로 보내 그 지점부터 재개합니다. WebSocket이라면 직접 만들어야 할 부분을 표준이 대신 처리해 주는 셈이죠.

그래서 무엇을 언제 쓰나

선택의 출발점은 앞에서 본 질문 하나로 돌아갑니다. 양방향이 정말 필요한가.

여기에 한 가지 운영상의 함정을 더해야 합니다. MDN에 따르면 HTTP/2가 아닌 환경에서 SSE는 브라우저와 도메인 조합당 동시 연결 수가 6으로 제한됩니다. 사용자가 탭을 여러 개 열면 이 한도에 쉽게 부딪힐 수 있죠. HTTP/2에서는 동시 HTTP 스트림 수(기본 100)로 협상되어 이 제약이 크게 완화됩니다. 그래서 SSE를 본격적으로 쓸 계획이라면 HTTP/2 환경인지부터 확인하는 편이 좋습니다.

정리하면, 둘은 우열의 문제가 아니라 쓰임이 다른 도구입니다. 양방향 상호작용이 핵심이면 WebSocket이, 서버가 밀어주는 것만으로 충분하면 더 단순하고 HTTP 친화적인 SSE가 합리적인 출발점입니다. 참고로 둘 다 모던 브라우저에서 지원되며, EventSource는 일부 오래된 브라우저에서만 빠져 있습니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)