실시간 알림 구현 하기 : 0. 요구사항 분석과 방법론 비교

이전에는 서비스에 알림을 볼 수 있는 채널이 존재하지 않았다.

서비스 내에 기존에 지원하던 분석과 관련된 서비스 외에 SBOM을 활용한 서비스의 공유 기능이 생기게 되면서 알림 기능이 요구사항으로 추가 되었다. 

 

 

주요 요구 사항은 다음과 같았다.

• 이벤트 수신 여부 실시간 반영
• 새로운 이벤트 발생 시 실시간 업데이트
• 이벤트 삭제 시 실시간 업데이트

 

요구 사항 분석

 ✅ 새로운 이벤트 발생 시 실시간 업데이트

• 데이터 전송 흐름
  • case 1 : 클라이언트 → 서버 (요청)
  • case 2 : 서버 → 클라이언트

✅ 이벤트 수신 여부 실시간 반영, 이벤트 삭제 시 실시간 업데이트

• 데이터 요청/전송 흐름
  • 클라이언트 동작 → 서버 (요청)
  • 실시간성이 아닌 클라이언트 동작에 따른 서버 요청으로 실시간 알림과 별개로 생각
  • 기존 REST 요청을 통한 구현

따라서, 실시간 알림 처리의 경우 새로운 이벤트 알림 발생 시 실시간 업데이트 되는 방향에 대해서만 고려

 

구현 방법론 비교

방식	데이터 흐름	장점	단점	우리 요구(서버→클라 단방향) 적합도	운영 난이도
Polling	클라이언트 → 서버 (단방향 요청)	구현 쉬움, 인프라 단순	불필요한 트래픽↑, 응답 지연(간격 만큼)	△(가능은 함)	★☆☆
Long polling	클라이언트 → 서버 (단방향 요청)	지연↓, 프록시/로드밸런서 친화	연결/해제 반복 오버헤드	○	★★☆
SSE (Server-Sent Events)	서버 → 클라이언트(단방향 푸시)	단방향 push 최적, 브라우저 기본지원(EventSource), HTTP/LB 친화, 자동재연결	바이너리×, 채팅같은 쌍방향에는 부적합	◎ (권장)	★★☆
WebSocket	클라이언트 ↔ 서버(양방향 소통)	완전한 양방향, 지연 최소	LB/프록시/스케일링 복잡성↑, 헬스/백프레셔 설계 필요	△(오버스펙)	★★★

1. polling
   • 단순히 일정 주기로 클라이언트가 서버에게 요청을 보내는 구조
   • 그러나 이벤트가 없는 경우일 때도 클라이언트는 불필요한 요청을 계속 보내야 함
   • Polling 주기가 길어질 수록 데이터의 실시간성이 떨어진다는 문제
   • 구현 난이도 용이 (이미 분석 진행중 퍼센트에서 활용되고 있는 방식)
2. long polling
   • 클라이언트의 요청에 대해 서버가 바로 응답을 보내지 않고 이벤트가 발생할 때까지 Connection을 유지
   • Polling방식보다는 실시간성이 증가하면서도 불필요한 요청수를 줄일 수 있음
   • 다만 결국은 응답이 올 수도 있는 상황 때문에 불필요한 요청을 보낸다는 점은 polling 방식과 동일
3. SSE(Server Sent Event)
   • HTML5 표준기술로서 클라이언트 요청없이도 서버 -> 클라이언트로 데이터를 보낼 수 있음
     • 최초 연결 시 클라이언트 측에서 요청을 보내야 함
   • 앞선 두 기술과 다르게 실시간 이벤트 데이터를 받아볼 수 있는 기술
   • HTTP를 사용하기 때문에 방화벽 개방 등의 절차 불필요
4. websocket
   • 웹소켓은 양방향 통신을 지원하는 Layer 7 프로토콜
   • SSE보다는 조금 더 양방향 실시간성을 보장

 

 

🥊 SSE vs WebSockets

두 기술 모두 실시간 통신을 가능하게 하지만, 기본적인 동작 방식에서 차이가 있다.

• WebSockets
  • 양방향(full-duplex) 통신을 지원한다.
  • 즉, 클라이언트와 서버가 서로 메시지를 주고받을 수 있다.
  • 이런 특성 덕분에 **양방향 상호작용이 필요한 서비스(예: 실시간 채팅, 멀티플레이어 게임)**에 적합
• SSE (Server-Sent Events)
  • 서버가 일방적으로 클라이언트로 데이터를 전송(push) 할 수만 있다.
  • 클라이언트가 데이터를 계속 서버로 보낼 필요가 없는 경우, 구현이 단순하고 가벼운 선택지

🥊 SSE vs Polling

• Long Polling
  • 클라이언트가 주기적으로 서버에 “새로운 데이터가 있나요?” 하고 요청을 보내는 방식
  • 새로운 데이터가 없더라도 계속 요청을 보내야 하므로 비효율적
• SSE
  • 한 번 연결을 맺은 뒤, 서버에서 새로운 데이터가 생길 때마다 클라이언트로 직접 푸시
  • 따라서 클라이언트의 반복 요청이 필요 없고, 네트워크 리소스를 절약

 

 

결론

항목 추천 방식 비고

항목	추천 방식	비고
실시간 알림 (신규 이벤트 발생)	SSE	서버 → 클라이언트 단방향 푸시
이벤트 읽음/삭제 처리	REST API	클라이언트 액션에 따라 요청 발생

• 기존 서비스의 현재 진행 중인 분석 진행률 표시 기능은 클라이언트가 명시적으로 요청하는 Polling 방식이 적합 (일시적 상태 확인 목적).
• 반면, 헤더에서 전역적으로 표시되는 실시간 알림 기능은 클라이언트의 지속적인 요청 없이 서버가 변경사항을 푸시해야 하므로 → SSE(Server-Sent Events) 방식이 가장 적합.

 

 

Reference

https://kangs-develop.tistory.com/40

https://sanghee01.tistory.com/186

https://velog.io/@galmegi/5.-알람기능-구현

https://velog.io/@tkddn_dev8430/실시간-통신-어떻게-할래-폴링부터-WebSocket까지

https://sol-aftercoding.tistory.com/entry/STOMP란-WebSocket과의-차이

https://leejincha.tistory.com/264