SSE vs WebSocket, 언제 써야 빛을 볼까?

1. ‘실시간’이 필요할 때 두 갈래 길

알림·라이브 피드·채팅 같은 기능을 붙이다 보면 “Server-Sent Events(SSE)로 갈까, WebSocket으로 갈까” 갈등이 온다. 두 프로토콜은 모두 HTTP 위에서 동작하지만 성격이 확연히 다르다. 오늘 글에서는 “상황별 최적 선택법”을 정리한다.

---

2. SSE — 단방향 스트리밍, 가볍고 자동 복구까지

• 단방향: 서버→클라이언트 전용. 클라이언트가 뭘 보낼 일 없는 뉴스·주가·알림에 최적이다.
• HTTP 그대로: 별도 업그레이드 없이 text/event-stream으로 열려서 프록시·로드밸런서 호환성이 높다.
• 자동 재접속 + 체크포인트: 브라우저 EventSource가 끊기면 재연결하고, Last-Event-ID로 놓친 메시지를 이어받는다.
• 가벼운 서버 구현: 응답을 flush만 해 주면 끝. Lambda·Cloud Functions 같은 서버리스 환경에서도 부담이 적다.
• 제한 사항
  • HTTP/1.1에서는 도메인당 동시 6 커넥션 한계. 탭을 많이 열면 막힌다. HTTP/2로 대부분 해소된다.
  • 바이너리 전송 불가, 오직 UTF-8 텍스트.

---

3. WebSocket — 풀 듀플렉스, 대화가 필요할 때

• 양방향: 채팅, 협업 에디터, 멀티플레이 게임처럼 클라→서버 메시지가 필수인 서비스에 필수.
• 경량 프레이밍 & 바이너리 지원: 그림·음성·파일까지 실시간 전송 가능.
• 낮은 지연: 핸드셰이크 후엔 헤더 오버헤드 없이 패킷만 주고받아 속도가 빠르다.
• 주의할 점
  • Upgrade: websocket 단계가 있어서 일부 기업 프록시·방화벽이 막는 경우가 있다.
  • 연결·재시도·하트비트 로직을 직접 짜야 하므로 구현·테스트 비용이 더 든다.

---

4. 이런 상황엔 SSE가 낫다

• 서버→클라 일방 알림(주문 상태, 실시간 로그, 주가 티커)
• 대용량 구독자에게 브로드캐스트할 때 (수천~수만)
• 프록시·CDN·서버리스 인프라, 혹은 조직 내 HTTP만 허용되는 환경
• 간단한 코드 & 자동 재연결이 큰 이점인 MVP 단계

---

5. 이런 상황엔 WebSocket이 낫다

• 채팅·게임·문서 공동편집처럼 양방향 저지연 통신
• 클라이언트가 빈번히 데이터를 올려야 하는 IoT, 실시간 센서 스트림
• 이미지·바이너리 전송이 필요한 라이브캠·파일 공유
• 연결 관리(하트비트, 세션)와 인프라 제약을 컨트롤할 여력이 있을 때

---

6. 기억할 ‘선택 공식’

읽기 전용 + 실시간이면 SSE,
쓰기까지 필요하거나 바이너리·초저지연이면 WebSocket.
둘 다 필요하다면 알림은 SSE, 상호작용은 WebSocket으로 하이브리드를 구성해도 좋다.

---

7. 구현 팁 한 줌

• SSE: HTTP/2 활성화로 6 커넥션 제한 해결, retry·id 필드를 꼭 써서 재전송 대비.
• WebSocket: wss://로 TLS 적용, 프록시 통과 안 될 때는 443 포트 터널링 확인.
• 공통: 클라이언트-서버 버퍼 지연을 줄이려면 핑/펑(WS) · 코멘트 빈 줄(SSE)로 keep-alive를 주기적으로 보내라.