Server Sent Events(SSE): 설계

1. 왜 SSE를 선택했는가

프로젝트를 진행하면서 가장 고민했던 부분 중 하나는 실시간으로 결과를 사용자에게 알리는 방법이었습니다.

AI 분석이나 보안 점검 같은 작업은 백엔드에서 일정 시간이 소요되는데
사용자가 결과를 보기 위해 계속 새로고침을 하거나 폴링을 반복하는 것은 비효율적이었습니다.

 

처음에는 WebSocket을 고려했습니다. 그러나 WebSocket은 전용 프로토콜을 사용하고
핸드셰이크 과정과 커넥션 유지 비용이 높아 서버 자원이 많이 소모되었습니다.

또한 단방향 알림만 필요한 구조였기 때문에 굳이 양방향 통신을 사용할 이유가 없었습니다.

 

이런 이유로 HTTP 기반 단방향 스트리밍 기술인 SSE를 도입했습니다.
SSE는 표준 HTTP 1.1을 기반으로 하며 브라우저가 기본적으로 지원하기 때문에 별도 설정이 필요하지 않습니다.
무엇보다 브라우저 단에서 3초마다 자동으로 재연결을 시도하기 때문에 안정성도 높았습니다.

 

---

 

2. SSE 개념 요약

SSE는 서버에서 클라이언트로 실시간 이벤트를 푸시할 수 있도록 하는 HTML5 표준 기술입니다.

기존 HTTP 연결을 그대로 유지하면서 서버가 데이터를 지속적으로 전송합니다.

• 통신 방향: 단방향(서버 → 클라이언트)
• 프로토콜: 표준 HTTP 1.1 기반
• 데이터 형식: UTF-8 텍스트
• 자동 재접속: 기본 제공(약 3초 주기)
• 브라우저 호환성: IE 제외 대부분 지원
• 서버 구현: Spring SseEmitter 만으로 간단히 구현 가능

 

 

---

 

3. WebSocket vs SSE 비교

WebSocket과 SSE를 비교하는 내용은 Inpa dev 블로그를 참고했습니다.

 

구분	WebSocket	SSE
통신 방향	양방향 (Full-duplex)	단방향 (서버 → 클라이언트)
프로토콜	전용 WebSocket 프로토콜	표준 HTTP 1.1
데이터 형식	Binary, UTF-8 혼용 가능	UTF-8 텍스트 기반
자동 재접속	❌ 직접 구현 필요	⭕ 기본 제공(3초 주기)
브라우저당 연결 수	무제한(설정 의존)	HTTP 1.1 기준 6개, HTTP 2는 100개
배터리 소모	상대적으로 큼	적음 (HTTP Keep-Alive)
방화벽 호환성	낮음	높음 (HTTP 트래픽)

 

---

 

4. SSE의 장점

1. 배터리 소모가 적습니다.
   WebSocket은 지속적인 ping-pong 유지 비용이 큰 반면
   SSE는 HTTP Keep-Alive 기반으로 연결을 유지해 자원 소모가 적습니다.
2. 자동 재연결 기능이 기본 지원됩니다.
   브라우저의 EventSource 객체는 3초마다 자동으로 재시도하며
   재연결 시에는 Last-Event-ID 헤더를 통해 마지막 이벤트 이후부터 다시 수신할 수 있습니다.
3. 서버 구현이 간단합니다.
   별도의 프로토콜 설정 없이 Spring의 SseEmitter 만으로도 충분히 구현 가능합니다.

 

5. 단점 및 고려사항

1. 연결이 언제든 끊길 수 있습니다.
   브라우저 새로고침, 네트워크 지연, 서버 롤링 업데이트,
   로드 밸런서의 idle-timeout 등으로 연결이 쉽게 끊어질 수 있습니다.
2. HTTP 1.1 에서는 연결 수 제한이 있습니다.
   브라우저당 약 6개의 SSE 연결만 가능하므로 동시 요청 이슈를 고려해야 합니다.
3. 데이터가 휘발성입니다.
   SSE는 실시간 스트림이기 때문에 이력을 서버에서 저장하지 않으면 복구가 불가능합니다.

 

---

 

6. SSE 적용 전략 

A안: 현재 적용

현재 프로젝트에서는 SSE + DB(최종 스냅샷) + GET API 구조를 사용하고 있습니다.
즉 실시간 알림은 SSE로 전송하고 최종 데이터는 DB에 저장하여 GET API로 조회합니다.

 

장점

• DB가 단일 소스 역할을 하기 때문에 서버 재시작이나 네트워크 끊김 상황에서도 데이터 손실이 없습니다.
• 브라우저 새로고침 또는 재연결 시에도 GET API로 결과를 복구할 수 있습니다.
• SSE는 단순히 즉시 알림 채널로만 사용되기 때문에 운영이 간단합니다.

단점

• AI 분석처럼 여러 단계 로그를 전송하는 경우, 중간 이벤트가 끊긴 사이에 유실될 수 있습니다.

 

B안: 분산 캐시 활용 전략 (향후 고려)

A안의 보완 방안으로 Redis와 같은 단기 캐시를 도입해 최근 이벤트를 보관하는 B안도 있습니다.
이를 통해 재연결 시 Last-Event-ID 이후 이벤트만 백필 형태로 전송할 수 있습니다.

 

이 방식은 진행 로그나 Progress 상태를 UI에 실시간으로 누적 표시할 때 유용합니다.
다만 Redis 운영 부담과 메모리 관리 이슈가 있기 때문에, 현재 프로젝트에서는 적용하지 않았습니다.

항목	선택	이유
주요 전략	A안 (DB + GET 중심)	AI/보안/웹성능 결과는 DB 저장, SSE는 즉시 알림용
캐시 도입	X (현재 불필요)	이벤트 손실은 GET 재조회로 복구 가능
유지 기능	GET API	새로고침 및 재연결 시 복구 경로 제공
SSE 목적	결과 완료 알림 / UX 향상 / 폴링 비용 절감

 

---

 

7. 다중 구독자 전략

테스트가 실행될 때마다 새로운 testId가 생성되므로 동시 구독 필요성은 낮습니다.
그러나 운영자 대시보드나 모니터링 뷰가 여러 창에서 같은 testId를 감시할 수 있으므로
다중 구독 (Set 구조) 를 허용하는 방식으로 확장했습니다.

 

이로써 재연결 중 일시적 중복 연결이 생겨도 안정적으로 처리할 수 있으며
2~3개의 Emitter 추가는 비용 측면에서도 무시할 수 있습니다.

 

---

 

8. SSE 통신 흐름 (A안 기준)

1. 클라이언트가 테스트 생성을 요청 → 서버는 DB에 testId 를 저장하고 반환합니다.
2. 클라이언트는 EventSource를 통해 /api/tests/{testId}/events 경로로 SSE 연결을 엽니다.
3. 서버는 ping 및 진행 이벤트를 순차적으로 전송합니다.
4. AI/보안 분석이 완료되면 결과를 DB에 저장하고 “done” 이벤트를 보냅니다.
5. 클라이언트는 SSE 연결을 종료하고, 별도의 GET API로 최종 결과를 조회합니다.

 

---

 

마무리

SSE는 WebSocket보다 구현이 간단하고, 브라우저 자동 재연결 및 낮은 전력 소모, HTTP 친화성이 큰 장점입니다.
다만 연결이 언제든 끊길 수 있기 때문에
SSE는 즉시 알림용, 데이터는 DB + GET으로 복구 라는 전략으로 프로젝트에 적용했습니다.

아직 프론트엔드와 연결하기 전이지만 연결 시 발생하는 여러 문제들도 기록해두었다 블로그에서 풀어보겠습니다.