Hotwire의 실시간성 한계: 실시간이 항상 유리한가?

카테고리

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

서브카테고리

웹 개발

대상자

• *웹 애플리케이션 개발자** (특히 Hotwire/Turbo를 사용하는 경우)
• *난이도 관점**: 중간 (기초적인 DOM 조작 및 WebSocket 이해 필요)

핵심 요약

• Turbo Stream은 DOM 노드가 메모리에 남아 있어 장시간 사용 시 10,000+ 요소로 인한 성능 저하 발생
• WebSocket 연결 수 증가로 Redis + Action Cable이 부하에 무너짐 (30% CPU 사용량)
• Turbo Frame의 상태 관리 문제로 이탈 시 데이터 손실 발생
• 에러 발생 시 UI 피드백 누락 문제 해결을 위해 이벤트 리스너 추가 필요

섹션별 세부 요약

1. Turbo Stream의 메모리 누수 문제

• DOM 노드가 제거되지 않아 메모리 사용량 증가
• 10,000+ 요소로 인한 5초 지연 및 크롬 충돌
• 해결책: document.querySelectorAll(".notification:not([data-turbo-permanent])")로 불필요 요소 제거

2. WebSocket 스케일링 문제

• 10,000명 사용자 시 10,000개 연결 유지로 Redis 부하 증가
• 30% CPU 사용량 발생 (연결 오버헤드 때문)
• 해결책: adapter: nats로 NATS 서버 사용 (Redis 대체)

3. Turbo Frame의 상태 관리 문제

• 다중 단계 폼 이탈 시 상태 손실
• 해결책: localStorage.setItem("form-state", JSON.stringify(myFormState))로 수동 저장

4. Turbo Stream 에러 피드백 누락

• 500 에러 시 UI 변화 없음
• 해결책: turbo:before-fetch-response 이벤트 리스너로 알림 표시

5. 사용하지 않는 시나리오

• 고호출 앱 (예: Figma)
• 대규모 트래픽 페이지 (WebSocket 비용 증가)
• 오프라인 지원 필요 앱 (Turbo 캐싱 성능 저하)

6. Golden Rule 및 Basecamp 사례

• Hotwire는 SPA 대체가 아닌 보완 도구로 사용 (예: 알림은 Turbo Streams, 차트는 React)
• Basecamp의 성공 요인: 전담 인프라 팀, 스케일링 전략 (WebSocket 모니터링, 필요 시 SPA 전환)

결론

• Hotwire 사용 시 메모리 관리 및 WebSocket 스케일링에 주의
• SPA 전환 필요 시점 (복잡한 UI, 오프라인 지원)을 명확히 파악해야 함
• Turbo는 보완 도구로, 전체 앱 대체는 피해야 함