실시간 알림 구현 하기 : 4. 하나의 채널로 SSE 통신하기 (with. Shared Worker)

이전글에서 SSE 연결 테스트를 마친후에 실제로 개발에 착수하는 단계가 되었다. 개발 이전에 내가 고려해야 할 사항들에 대해 정리를 해보았다.

 

1. SSE는 브라우저 탭마다 연결이 새로 열린다.

2. 헤더 커스텀이 필요하지만 SSE의 경우 헤더 커스텀이 불가능하다.

 

이 조건을 동시에 만족시키는 구조를 만드는 것이 이번 실시간 알림 개발의 핵심 과제였다.

 

1. 탭마다 새로 열리는 SSE 연결 문제

SSE는 기본적으로 브라우저 탭 단위로 연결이 생성된다.
즉, 사용자가 같은 서비스에서 탭을 3개 열면 서버 입장에서는 SSE 연결이 3개가 열린다.

 

기술 검토 초기에는 이 부분을 크게 문제 삼지 않았다.
하지만 실시간 알림은 특정 페이지가 아니라 헤더에 항상 떠 있어야 하는 기능이었고, 자연스럽게 사용자는 여러 탭을 열어둔 상태에서도 동일한 알림을 동시에 받아야 했다. 이 구조를 그대로 두면 다음과 같은 문제가 생긴다.

• 서버 입장에서 같은 유저에게 중복된 SSE 연결이 계속 열린다
• 트래픽과 커넥션 수가 사용자 수 × 탭 수만큼 증가한다
• 실서비스 환경에서는 비용과 안정성 모두에 부담이 된다

즉, “탭마다 SSE를 여는 구조는 기술적으로는 간단하지만, 운영 측면에서는 매우 비효율적”이라는 결론에 도달하게 되었다.

 

 

2. SSE는 헤더 커스텀이 불가능하다는 제약

마지막으로 가장 현실적인 제약이 하나 더 있었다. 바로 SSE는 기본 EventSource API로는 커스텀 헤더를 넣을 수 없다는 점이다.

우리 서비스는 인증 구조가 다음과 같았다.

• API 요청 시 Authorization: Bearer accessToken 필요
• 일부 환경에서는 쿠키 기반 인증과 헤더 인증을 함께 사용

하지만 기본 EventSource는 다음과 같은 한계를 가진다.

• Authorization 헤더를 직접 넣을 수 없음
• 즉, 기존 인증 방식 그대로는 SSE 인증이 불가능한 구조

물론 event-source-polyfill 같은 라이브러리를 활용하면 헤더를 추가할 수는 있었다.

하지만 이 방식은 1번 문제를 해결하기 위해 사용했던 Shared Worker와 함께 사용하기에는 여러 제약이 존재했다.

 

특히 Shared Worker는

• next.js에서 public 경로의 순수 .js 파일에서 동작해야 하고
• 번들링된 모듈을 import 하는 것도 제한적이며
• 보안상 토큰을 URL query로 넘기는 방식 역시 부담이 컸다

결국 나는 이렇게 정리하게 되었다.

“SSE 인증 문제는 클라이언트에서 억지로 해결할 게 아니라, 중간에서 한 번 더 제어할 수 있는 레이어가 필요하겠다.”

 

 

그래서 구조를 ‘프록시 기반’으로 다시 보기 시작했다

이 두 가지 문제를 종합하면 다음과 같은 결론에 도달하게 된다.

• SSE 연결은 가능하면 하나만 유지하고 싶고
• 인증 헤더는 안전하게 실어서 전달해야 한다

이 두 요구사항을 동시에 만족시키기 위해, 나는 SSE를 직접 백엔드에 붙이는 구조가 아니라,
이전 글에서 발생했던 Next.js의 gzip 이슈 해결을 위해 고려되었던 Next.js API Routes를 거치는 구조로 가져가기로 확정했다.

 

 

 

✅ API Routes를 SSE 프록시로 사용하기로 한 이유

Next.js API Routes를 중간에 두는 구조는 처음부터 의도한 선택은 아니었다.
하지만 지금 와서 돌아보면, 이 선택 하나로 다음 문제들이 한 번에 정리되기 시작했다.

---

1️⃣ gzip 압축으로 인해 SSE 실시간성이 깨지는 문제 해결

기존에는 next.config.js의 rewrites를 통해
프론트에서 백엔드 SSE 서버로 직접 연결하는 구조를 사용하고 있었다.

하지만 Next.js의 기본 옵션인 compress: true로 인해:

• 응답이 gzip으로 압축되면서
• 충분한 데이터가 쌓이기 전까지 응답이 버퍼링되고
• 그 결과 SSE의 실시간성이 완전히 깨지는 현상이 발생했다.

반면 API Routes는:

• Next.js의 gzip 압축 예외 경로에 해당하고
• 스트리밍 응답을 버퍼링 없이 그대로 전달할 수 있는 구조였다.

즉, API Routes를 프록시로 사용하면, gzip 문제를 구조적으로 회피할 수 있었다.

---

2️⃣ SSE 인증 문제를 서버 사이드에서 해결할 수 있다

앞서 언급했듯이, 기본 EventSource는 Authorization 헤더를 직접 넣을 수 없다.
하지만 API Routes를 거치게 되면 상황이 완전히 달라진다.

• 클라이언트 → API Routes 요청에는 쿠키가 자동으로 포함되고
• API Routes에서는 그 쿠키를 읽어
• 백엔드 SSE 요청 시 Authorization: Bearer token 헤더를 직접 구성해서 전달할 수 있다.

즉, 클라이언트에서는 더 이상 인증을 신경 쓸 필요가 없어지고, SSE 인증 로직은 전부 서버 사이드에서 일관되게 처리할 수 있게 되었다.

---

3️⃣ 이후 Shared Worker 구조까지 자연스럽게 연결할 수 있다

그리고 이 구조는 자연스럽게, “SSE 연결은 무조건 API Routes 한 곳으로만 모은다”라는 전제 조건을 만들어주었다.

이 말은 곧,

• Shared Worker에서 SSE를 열더라도
• 항상 /api/sse/event라는 하나의 고정된 엔드포인트만 바라보게 되고
• 내부 구조가 어떻든, 클라이언트와 백엔드 사이의 접점은 단 하나로 수렴된다.

이 덕분에 이후에:

• Shared Worker에서 SSE를 하나만 열고
• 여러 탭으로 브로드캐스트하는 구조를 설계하는 데에도 큰 방향성 수정 없이 그대로 확장할 수 있었다.

---

정리해 보면

Next.js API Routes를 SSE 프록시로 사용하기로 한 결정은, 단순히 “우회 경로를 하나 추가한 것”이 아니었다.

이 선택 하나로 이 세 가지가 한 번에 정리되기 시작했다.

• ✅ gzip으로 인한 SSE 지연 문제
• ✅ SSE 인증 헤더 전달 문제
• ✅ Shared Worker 단일 채널 구조 설계의 기반

 

 

 

이제 SSE는 항상 /api/sse/event를 통해서만 열리게 되었고,
프론트엔드 입장에서는 “인증과 gzip 문제는 더 이상 신경 쓰지 않아도 되는 상태”가 되었다.

하지만 여전히 해결되지 않은 문제가 하나 남아 있었다.

“SSE 연결은 하나만 유지하고 싶다.”

API Routes가 중간에 생기면서 구조는 정리되었지만, 여전히 브라우저 탭마다 /api/sse/event로 SSE 연결을 새로 열고 있다는 사실 자체는 변하지 않았다.

즉, 구조는 안전해졌지만, 연결 수 자체를 줄이는 문제는 아직 해결되지 않은 상태였다.

 

 

✅ 그래서 다시 마주한 문제: “탭이 여러 개면 SSE도 여러 개다”

현실적인 사용 시나리오를 다시 떠올려 보면 다음과 같았다.

• 사용자는 메인 화면을 켜 둔 상태에서
• 새로운 기능을 보겠다고 탭을 하나 더 열고
• 필요하면 또 하나를 더 연다

UI는 전부 동일하고,
헤더에는 동일한 실시간 알림 종 아이콘이 떠 있다.

하지만 기술적으로는:

• 각 탭이 전부 독립적으로 /api/sse/event에 연결
• 결과적으로 같은 유저가 동일한 알림 스트림을 여러 개로 받아가고 있는 상태

이 구조를 그대로 두면:

• 서버는 같은 데이터를 같은 유저에게 여러 번 중복 전송
• 클라이언트도 필요 이상으로 동일한 이벤트를 여러 번 처리
• SSE의 장점인 “가볍고 단순한 실시간 스트림”이
  오히려 구조적으로 무거워지는 상황이 된다.

그래서 이 시점부터 고민은 이렇게 바뀌었다.

“SSE 연결을 탭마다 열지 말고, 브라우저 단에서 하나로 공유할 수는 없을까?”

 

이 답에 대해서는 다음 레퍼런스를 통해서 돌파구를 찾을 수 있었다.

toss slash 24: N개의 탭, 단 하나의 websocket와 플렉스 팀의 모든 탭에 퍼지는 실시간 이벤트, SSE 1개로 끝내는 전략 글을 통해서 worker의 존재를 통해 이를 해결할 수 있다는 힌트를 얻었다.

 

toss slash24 : N개의 탭, 단 하나의 웹소켓 장표 발췌

 

두 글의 공통된 핵심은,Worker를 허브로 두고 실시간 연결을 하나로 수렴시킨다는 전략이었다.

---

✅ Service Worker가 아닌, Shared Worker를 선택한 이유

Worker를 사용한다는 방향성은 잡혔지만, 다음 선택지는 Service Worker vs Shared Worker였다.

Service Worker는:

• 캐싱, 네트워크 인터셉트, 푸시 알림 등
• 앱 전체를 대표하는 백그라운드 구조에 가깝다.

반면 내가 만들고자 했던 구조는:

• 지금 열려 있는 탭들끼리만
• SSE 하나를 공유하는 실시간 허브

이 성격에는 Shared Worker가 훨씬 잘 맞았다.

Shared Worker는:

• 여러 탭이 하나의 워커를 공유할 수 있고
• 그 안에서 SSE 연결을 단 하나만 유지할 수 있으며
• 모든 탭이 닫히면 워커도 자연스럽게 종료된다.

즉, 실시간 알림 전용 허브 역할에는 Service Worker보다 Shared Worker가 더 적절한 선택지였다.

그래서 이 시점에서 방향은 명확해졌다.

“SSE는 Shared Worker 안에서 하나만 열고, 각 탭은 그 결과를 받아서 보여주자.”

---

✅ 다만, Shared Worker는 ‘만능 해결책’은 아니었다

Shared Worker는 구조적으로는 완벽해 보였지만, 실제 도입을 고려하면서 몇 가지 현실적인 제약도 함께 마주하게 되었다.

• 모바일 브라우저에서는 지원이 제한적이고
• public 경로의 순수 .js 파일에서 로드되어야 하며
• 번들링, 모듈 import, 디버깅 방식도 기존과는 전혀 달랐다

그럼에도 불구하고,“SSE 연결을 사용자 기준으로 하나만 유지한다”는 목표를 가장 정확하게 달성할 수 있는 수단은 여전히 Shared Worker뿐이었다.

 

❓Broadcasting Channel로도 해결할 수 있지 않을까?

한편으로는 이런 생각도 자연스럽게 들었다.

“Broadcasting Channel을 통해 채널을 하나만 열고, 리더 탭에서 다른 탭으로 실시간 이벤트 알림을 동기화하면 되지 않을까?”

이 방식 역시 이론적으로는 가능하다. 특정 탭을 리더 탭으로 삼아 그 탭에서만 SSE를 열고,수신한 이벤트를 Broadcasting Channel을 통해 다른 탭으로 전파하는 방식이다.

 

하지만 이 구조는 명확한 단점을 가지고 있었다.

• 리더 탭이 닫히는 순간 SSE 연결이 함께 끊기고
• 그 즉시 새로운 리더 탭을 선출하는 로직이 추가로 필요해진다
• 결과적으로 구조가 단순해지기보다는 오히려 더 복잡해질 가능성이 컸다

즉,“항상 하나의 채널을 유지한다”는 목표를 안정적으로 달성하기에는, Broadcasting Channel 기반 구조는 불확정성이 큰 선택지라고 판단하게 되었다.

 

그래서 나는 결국 이 시점에서 이렇게 결정을 내리게 된다.

“PC 환경에서는 Shared Worker로 단일 SSE 채널을 구성하고, 지원하지 않는 환경에서는 기존 SSE 방식으로 fallback 처리하자.”

 

 

최종 아키텍처: Shared Worker + Fallback 이중 구조

좌 : shared worker, 우: fall back

앞선 고민과 선택을 바탕으로,
실시간 알림 시스템의 최종 아키텍처는 Shared Worker 기반 + Fallback 구조로 정리되었다.

핵심 전제는 다음과 같다.

• PC 환경 → Shared Worker를 통해 SSE 연결 1개만 유지
• Shared Worker 미지원 환경(모바일 등) → 기존 방식대로 탭마다 SSE 직접 연결

이렇게 이중 구조를 가져가면:

• 성능과 비용이 중요한 PC 환경에서는 가장 이상적인 구조
• 호환성이 중요한 모바일 환경에서는 안정성이 우선인 구조

를 동시에 만족시킬 수 있었다.

---

Shared Worker가 동작하는 흐름

Shared Worker 기반 구조의 동작 흐름은 다음과 같다.

1. 브라우저의 여러 탭에서 useEventSSE 훅이 실행된다.
2. 각 탭은 Shared Worker에 연결하고, MessagePort를 통해 통신한다.
3. Shared Worker 내부에서는 단 하나의 SSE 연결만 생성된다.
4. 서버에서 실시간 이벤트가 도착하면,
5. Shared Worker가 그 이벤트를 모든 탭으로 브로드캐스트한다.
6. 각 탭은 전달받은 이벤트를 그대로 UI에 반영한다.

이 구조를 통해
브라우저 탭 수와 상관없이 SSE 연결은 항상 1개로 유지된다.

---

Shared Worker 미지원 환경의 Fallback 구조

반면 Shared Worker를 사용할 수 없는 환경에서는
초기 설계대로 단순한 구조를 유지하도록 했다.

• 각 탭이 /api/sse/event로 직접 SSE 연결
• 이벤트는 개별 탭에서 바로 처리
• 별도의 브로드캐스트나 허브 레이어는 두지 않음

이 방식은 연결 수는 늘어나지만, 지원 범위와 안정성 면에서는 가장 확실한 선택지이기도 하다.

즉, 이 아키텍처는 처음부터 “최적화된 구조 + 언제든 fallback 가능한 구조”를 함께 갖도록 설계된 형태라고 볼 수 있다.

---

이 구조의 핵심 요약

정리하면, 최종 구조의 핵심은 딱 세 가지다.

1. SSE는 사용자 기준으로 1개만 유지하는 것을 목표로 한다
2. PC 환경에서는 Shared Worker가 그 역할을 담당한다
3. Shared Worker 미지원 환경에서는 기존 SSE 방식으로 안전하게 fallback 한다

이제 실시간 알림은:

• 브라우저 탭이 몇 개든
• 인증과 실시간성은 유지하면서
• 서버와의 연결 수는 최소화하는 구조로 동작하게 되었다.