SharedWorker 적용기

작년 7월쯤, 고객사에 나가 있던 제품의 모니터링을 담당하는 서버에서 OOM(Out Of Memory) 에러가 발생했습니다.

정확한 원인을 단정 지을 수는 없었지만, “혹시 프론트엔드에서 줄일 수 있는 리소스가 있지 않을까?” 라는 생각이 들었습니다.

백엔드에서 발생한 문제였지만, 클라이언트에서도 분명 영향을 줄 수 있는 영역이 있을 것이라 판단했습니다.

문제

팀 내부에서는 보통 하나의 개발 서버를 두고 작업을 합니다.

특히 특정 프로세스를 수행한 뒤, 대시보드를 보며 현황 체크를 하는 일이 빈번했습니다.
그 결과 팀원 한 명당 여러 개의 대시보드 탭을 띄워두는 상황이 자연스럽게 반복되었습니다.

문제는 여기서 발생했습니다.

각 탭이 모두 독립적인 WebSocket 연결을 생성하고 있었던 것입니다.

탭 수 × 팀원 수 = WebSocket 커넥션 폭증

모니터링 서버 특성상 연결은 오래 유지되고, 실시간 데이터는 지속적으로 스트리밍됩니다.
이는 결국 서버 메모리 사용량 증가로 이어질 수밖에 없었습니다.

가장 단순하게는 이렇게 생각했습니다.

탭이 비활성화되면 WebSocket을 끊고, 활성화되면 다시 연결하면 되지 않을까?

실제로 구현해보았습니다.

하지만 다음과 같은 문제가 발생했습니다.

즉, 사용자가 탭을 전환할 때마다 UI가 깨졌다가 복구되는 경험을 하게 되었습니다.

이는 명백히 사용자 경험(UX)을 해치는 방식이었습니다.
특히 실시간 모니터링 대시보드에서는 더욱 치명적이었습니다.

그러던 중 Toss Slash 2024에서
SharedWorker를 활용해 다중 탭의 WebSocket 연결을 하나로 중앙화한 사례를 접하게 되었습니다.

그때 처음으로 이런 생각이 들었습니다.

세상에는 내가 모르는 것이 너무 많구나 ..

브라우저 Worker 중 하나인 SharedWorker는 여러 탭에서 하나의 Worker 인스턴스를 공유할 수 있습니다.

즉 다음과 같은 구조가 가능합니다.

탭 (100개)
↓
SharedWorker
↓
WebSocket 연결 (1개)

탭이 몇 개이든, WebSocket 연결은 단 하나만 유지됩니다.

이 구조라면 다음과 같은 장점이 있습니다.

이거다 라는 생각이 들었고, SharedWorker를 적극적으로 적용해보기로 결정했습니다.

작성중이에요 ( 02/12 )