서버-발신 이벤트(SSE) vs 웹소켓: Hotwire를 포기해야 할 때

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

웹 개발

대상자

• Ruby on Rails 프레임워크로 실시간 업데이트를 구현하는 개발자
• 스케일링 문제와 리소스 비용 최적화를 고려하는 백엔드 개발자
• SSE/WebSocket 기반 통신 프로토콜 선택에 고민 중인 프론트엔드 개발자
• Hotwire (Turbo + Stimulus)의 한계를 경험한 개발 팀
• 난이도: 중간 (프레임워크 이해 필요)

핵심 요약

• Hotwire의 한계 : 대규모 사용자(1,000명 이상)나 높은 주파수 데이터 전송 시 WebSocket 병목 현상, DOM 폭증, 인프라 복잡성 발생
• SSE 대체 장점 : 10배 저렴한 서버 비용, 로드 밸런서 호환성, 브라우저 내장 지원 (단, 클라이언트→서버 통신 불가)
• WebSockets의 적합성 : 양방향 통신, 저지연 필요 시 (예: 채팅, 협업 편집)

섹션별 세부 요약

1. Hotwire의 한계

• WebSocket 병목 : 10,000개 이상 연결 시 Action Cable 성능 저하
• DOM 폭증 : 실시간 업데이트로 인한 렌더링 복잡성 증가
• 인프라 복잡성 : Redis CPU 사용률 70% 이상 시 서버 오류 발생 가능성

2. SSE의 적합한 사용 사례

• 알림 시스템 (예: "새 메시지 도착")
• 라이브 대시보드 (예: 실시간 분석 데이터)
• 진행률 표시기 (예: 파일 업로드 상태)
• SSE 프로토콜 특징 : HTTP 기반, 자동 재연결, 단방향 통신

3. SSE의 Rails 구현 예시

def updates
  response.headers["Content-Type"] = "text/event-stream"
  stream = SSE.new(response.stream)
  StockTicker.on_change do |price|
    stream.write({ price: price }, event: "update")
  end
ensure
  stream.close
end

• 장점 : 로드 밸런서 호환, 브라우저 내장 지원
• 단점 : 클라이언트→서버 통신 불가, 도메인당 동시 연결 제한 (~6개)

4. WebSockets의 장단점

• 장점 : 양방향 통신, 저지연 (예: 게임, 채팅 앱)
• 단점 : 스케일링 복잡성 (스티키 세션 필요), 높은 인프라 비용

5. 사용자 사례: 경매 대시보드 전환

• 비용 절감 : 서버 비용 60% 감소
• Redis 의존성 제거
• 프론트엔드 코드 유지 : EventSource로 Turbo Streams 대체

6. Hotwire 대체 전략

1. 비중요 기능부터 시작 (예: 알림 시스템)
2. 비용 비교 (SSE가 읽기 중심 앱에 유리)
3. Hotwire 그 외 영역 유지

결론

• SSE를 선택할 때 : 읽기 중심 앱, 저비용 인프라, 단방향 통신 필요 시
• WebSockets를 선택할 때 : 양방향 통신, 고성능 (예: 게임, 채팅)
• Hotwire 대체 전략 : EventSource로 서버 코드 변경, AnyCable 활용 확장성 개선
• 실무 팁 : 프로토타입 단계에서는 SSE로 빠른 개발, 대규모 앱은 WebSockets + DevOps 인프라 조합 권장