SharedWorker 적용기

작년 7월쯤, 고객사에 나가 있던 제품의 모니터링을 담당하는 서버에서 OOM(Out Of Memory) 에러가 발생했습니다. 또한, 이 문제는 팀 내부에서 작업을 진행하면서도 빈번하게 발생하는 문제였습니다.

정확한 원인을 단정 지을 수는 없었지만,

“혹시 프론트엔드 영역에서 줄일 수 있는 서버 리소스가 있지 않을까?”

라는 생각이 들었습니다.

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

---

문제의 원인 파악하기

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

• 대시보드 탭 여러 개
• 로그 확인용 탭
• 기능 테스트 용

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

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

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

이는 다음과 같은 결과를 초래했습니다.

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

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

---

해결책 생각해보기

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

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

실제로 visibilitychange 이벤트를 활용해 구현해보았습니다.

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

• 탭 비활성화 → WebSocket disconnect
• 다시 활성화 → reconnect
• 데이터 수신 전까지 UI는 Error 차트 상태
• 데이터 수신 후 정상 UI 복구

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

이는 명백히 사용자 경험을 해치는 방식이라 생각하였고, 사용자의 오해를 불러일으킬 수 있는 방식이라 생각하였습니다.

---

Toss Slash 2024

그러던 중 Toss Slash 2024에서 SharedWorker를 활용해 다중 탭의 WebSocket 연결을 하나로 중앙화한 사례를 접하게 되었습니다. 해당 세션 발표를 진행했던 개발자분도 SharedWorker을 알기 전에 저와 같은 해결 방법을 고민했던 것으로 보아 적용하기 전에 더 신뢰가 갔던 것 같습니다.

Reference

토스ㅣSLASH 24 - N개의 탭, 단 하나의 웹소켓: SharedWorker

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

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

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

SharedWorker를 활용한 다중 탭의 WebSocket 연결 중앙화는 결국 아래와 같은 장점을 가지게 된다고 생각하였습니다.

• 탭이 몇 백개여도 WebSocket은 1개
• 서버 커넥션 수 감소
• UX 저하 없음
• 실시간 데이터 유지 가능

SharedWorker를 활용하면 프론트엔드 영역에서 서버의 부하를 무조건적으로 줄일 수 있다 생각하였고, WebSocket 연결이 도중에 끊어지는 방법 또한 아니기 때문에, 사용자 경험을 해칠 일이 없다고 생각했습니다.

따라서 SharedWorker를 적극적으로 적용해보기로 결정했습니다.

---

SharedWorker 적용해보기

SharedWorker 컨텍스트에서 실행될 스크립트 파일을 먼저 작성해주어야합니다.

SharedWorker 인스턴스를 생성할 때, 파일 경로를 필수 인자로 전달해주어야하고, 그 경로의 파일이 SharedWorker 컨텍스트에서 실행되게 됩니다.

worker.ts 파일을 먼저 작성해주겠습니다.

SharedWorker 전역 설정

파일 상단에 /// <reference lib="webworker" /> 를 추가해주어야합니다. 이는 Worker 컨텍스트에서 실행될 파일임을 명시하는 역할을 합니다.

그리고 workerScope 변수에 self 키워드를 사용하여 SharedWorkerGlobalScope 타입으로 타입 추론이 가능하게 해주도록 하겠습니다.

/// <reference lib="webworker" />
const workerScope = self as unknown as SharedWorkerGlobalScope

해당 변수는 추후에 탭과 SharedWorker 간 통신 시 사용됩니다.

탭 고유 ID 생성

각 탭을 식별하기 위해 Worker 내부에서 UUID v4를 생성합니다. 프로젝트에서는 uuid 생성 관련 라이브러리를 사용하고 있었지만, Worker는 별도 스레드이므로 설치된 패키지의 참조를 찾을 수 없으므로, 빌트인 crypto API를 직접 사용하겠습니다.

const generateUUID = () => {
  const randomValues = new Uint8Array(16)
  self.crypto.getRandomValues(randomValues)
 
  // UUID v4 형식
  randomValues[6] = (randomValues[6] & 0x0f) | 0x40
  randomValues[8] = (randomValues[8] & 0x3f) | 0x80
 
  let uuid = ""
 
  for (let i = 0; i < 16; i++) {
    if (i === 4 || i === 6 || i === 8 || i === 10) uuid += "-"
    uuid += randomValues[i].toString(16).padStart(2, "0")
  }
 
  return uuid
}

탭 별 MessagePort 생명주기 관리 클래스 생성하기

SharedWorker는 탭과 통신을 위해 MessagePort를 사용합니다. 이 MessagePort는 탭이 종료되면 자동으로 닫히게 됩니다. 이를 관리하기 위해 BrowserPort 클래스를 생성하겠습니다.

class BrowserPort {
  private readonly weakRef: WeakRef<MessagePort>
  readonly id: string
 
  constructor(port: MessagePort) {
    this.weakRef = new WeakRef(port)
    this.id = generateUUID()
  }
 
  isAlive(): boolean {
    return !!this.weakRef.deref()
  }
 
  postMessage(message: unknown): void {
    this.weakRef.deref()?.postMessage(message)
  }
 
  close(): void {
    this.weakRef.deref()?.close()
  }
}

위에서 보시다시피 BrowserPort 클래스에서 Port를 WeakRef로 한 번 래핑하였습니다.

Toss Slash 2024에서 발표한 세션에서는 WeakRef를 사용하여 탭 별 MessagePort를 관리하였습니다.

특히 모바일 환경이나 비정상 종료의 경우, 사용자 입장에서는 탭이 닫힌 것처럼 보이더라도 실제로는 관련 이벤트가 정상적으로 전파되지 않는 상황이 발생할 수 있습니다. 이로 인해 MessagePort가 명시적으로 정리되지 않고 남아 있게 됩니다.

예를 들어,MessagePort를 단순 배열로 관리하면 더 이상 사용하지 않는 포트가 배열에 계속 남아 있을 수 있습니다. 이때 강한 참조가 유지되면 가비지 컬렉션의 대상이 되지 않아 메모리 누수로 이어질 수 있습니다.

이 문제를 해결하기 위해 WeakRef를 사용하면, MessagePort에 대한 약한 참조(Weak Reference)만 유지하게 되어 실제로 더 이상 참조되지 않는 객체는 GC의 대상이 될 수 있습니다. 즉, 비정상 종료나 예외적인 상황에서도 불필요한 메모리 점유를 방지할 수 있다고 이해하였습니다.

탭 별 MessagePort 관리 및 WebSocket 연결 관리

아래와 같이 <uuid, BrowserPort> 형태의 Map 인스턴스를 생성하고, 탭 별 MessagePort를 관리하겠습니다.

const ports = new Map<string, BrowserPort>()

다음으로 WebSocket 연결 관리를 위해 ws 변수를 생성하고, connectWebSocket 함수를 생성하겠습니다.

let ws: WebSocket | null = null
 
const connectWebSocket = (url: string) => {
  if (ws && ws.readyState === WebSocket.OPEN) return // 재연결 방지
 
  ws = new WebSocket(url)
 
  ws.onclose = () => {
    ws = null
  }
 
  ws.onmessage = (event) => {
    const { portId, ...chartData } = JSON.parse(event.data)
 
    //후처리..
  }
}

탭 연결 처리 (onconnect)

제일 처음에 SharedWorker 인스턴스가 생성될 때, onconnect 이벤트 핸들러가 호출됩니다.

이벤트 핸들러 내부에서는 탭과 통신을 위해 MessagePort를 생성하고, 해당 MessagePort를 WeakRef로 한 번 감싸기 위해 BrowserPort 인스턴스를 생성하고, Map 인스턴스에 저장하겠습니다.

e.ports[0] 은 탭과 통신을 위해 생성된 MessagePort 인스턴스입니다.

ports 프로퍼티가 배열로 넘어오지만, 연결된 탭의 관련 port 아이템만 넘어오게 됩니다.

그리고 해당 MessagePort의 onmessage 이벤트 핸들러를 설정하고, start 메서드를 호출하여 탭이 메시지를 받을 수 있게 해주었습니다.

workerScope.onconnect = (e) => {
  const port = e.ports[0]
 
  const browserPort = new BrowserPort(port)
 
  ports.set(browserPort.id, browserPort)
 
  port.onmessage = (portEvent) => {
    const { type, data: recvData } = portEvent.data
 
    switch (type) {
      case "CONNECT_WS":
        connectWebSocket(recvData.url)
 
        break
 
      case "SEND_DATA":
        if (ws?.readyState === WebSocket.OPEN) {
          ws.send(JSON.stringify({ ...recvData, portId: browserPort.id }))
        }
 
        break
 
      case "DISCONNECT":
        ports.delete(browserPort.id)
 
        browserPort.close()
 
        checkAndCleanupWebSocket()
 
        break
 
      case "CLEANUP_WS":
        ws?.close()
        ws = null
        break
    }
  }
 
  port.addEventListener("messageerror", () => {
    ports.delete(browserPort.id)
 
    browserPort.close()
 
    checkAndCleanupWebSocket()
  })
 
  port.start()
}

위에서 사용된 sendToPort메서드와 checkAndCleanupWebSocket 메서드는 다음과 같은 역할을 합니다.

/**
 * 탭과 통신을 위해 MessagePort를 전송하는 메서드
 * @param portId - 탭 고유 ID
 * @param message - 전송할 메시지
 */
const sendToPort = (portId: string, message: unknown) => {
  const port = ports.get(portId)
 
  if (port?.isAlive()) {
    port.postMessage(message)
  }
}
 
/**
 * WebSocket 연결 상태를 확인하고, 연결이 끊어진 경우 WebSocket을 닫는 메서드
 */
const checkAndCleanupWebSocket = () => {
  const hasActivePorts = Array.from(ports.values()).some((port) => port.isAlive())
 
  if (!hasActivePorts && ws) {
    ws.close()
    ws = null
  }
}

디버깅 하기

SharedWorker 인스턴스를 디버깅 하기 위해서는 탭 별 브라우저 개발자 도구가 아닌 다른 방법으로 디버깅을 해야합니다.

chrome://inspect/#workers
 
혹은
 
edge://inspect/#workers

위 경로로 접속하고, 테스트 하는 url 아이템의 inspect 버튼을 클릭하면 아래와 같이 브라우저 개발자 도구와 동일한 UI 팝업이 나오게 됩니다.

worker.ts 파일에서 console.log를 호출했다면, 아래와 같이 콘솔에 로그가 찍히게 됩니다.

회고

결과적으로 서버 부하는 눈에 띄게 감소했고, 이 글을 작성하는 현재까지 모니터링 서버에서 OOM(Out Of Memory) 현상은 발생하지 않았습니다. 물론 이번 이슈는 프론트엔드만의 개선으로 해결된 것이 아니라, 백엔드 영역과 병행하여 대응한 결과이기 때문에 SharedWorker를 적용했기 때문에 OOM이 해결되었다고 단정할 수는 없습니다. 다만, 전체적인 안정성 개선에 분명 일정 부분 기여했을 것이라고 생각합니다.

또한 MessagePort를 WeakRef로 관리한 부분 역시 의미 있는 시도였습니다. 토스증권과 같이 다양한 디바이스와 브라우저 환경을 지원해야 하는 서비스라면, 예외적인 종료 케이스까지 고려한 생명주기 관리는 실제 운영 환경에서 분명 체감할 수 있는 효과가 있었을 것이라 생각합니다.

반면, 저희 팀 프로젝트는 대부분 데스크톱 환경에서 실행되고 모바일을 지원하지 않기 때문에, WeakRef 기반 관리 방식이 다소 오버엔지니어링이 아니었을까 하는 아쉬움도 남습니다. 그럼에도 불구하고, 잠재적인 메모리 누수 가능성을 구조적으로 차단해보는 경험이었다는 점에서 충분히 의미 있는 시도였다고 정리하고 싶습니다.

이상으로 글을 마치겠습니다.