1. 왜 이 글을 쓰게 되었나
현업에서 DevOps 겸 클라우드 엔지니어로 일하다 보면, 개발팀이 “실시간”이라는 요구사항이 있을 때 대부분 SSE(Server-Sent Event)을 쓰거나, 혹은 실시간 양방향 통신을 원할 때는 WebSocket 를 선택하는 경우가 있습니다.
따라서, 애플리케이션의 특성과 통신 방식의 장단점을 맞춰야 효율적인 아키텍처를 만들 수 있습니다.
최근 우리 팀도 SSE(Server-Sent Events) 통신 방식를 쓰고 있었는데, 정작 개발자들이 “왜 SSE를 쓰는지”, “어떻게 동작하는지” 정확히 몰라서 아키텍처 논의가 힘들었습니다.
그래서 이번 글에서는 SSE의 개념, 동작 원리, 장단점, 아키텍처 설계 시 고려사항까지 정리하려 합니다.
SSE란 무엇인가?
SSE(Server-Sent Events) 는 서버가 클라이언트(브라우저, 앱 등)로 단방향 스트리밍 데이터를 전송하는 기술입니다.
HTTP 연결을 끊지 않고 유지하며, 새로운 데이터가 있으면 즉시 전송합니다.
📌 한 줄 정의
“서버에서 클라이언트로만, 실시간으로, 텍스트 기반 데이터를 계속 밀어주는 HTTP 스트리밍 방식”
SSE vs 다른 방식 비교
| 항목 | Polling | SSE | WebSocket |
|---|---|---|---|
| 통신 방향 | 단방향(클라이언트 → 서버) | 단방향(서버 → 클라이언트) | 양방향 |
| 연결 방식 | 매번 새 요청 | 장기 연결 | 장기 연결 |
| 브라우저 지원 | 전부 지원 | HTML5 지원 | HTML5 지원 |
| 전송 데이터 | 텍스트/바이너리 | UTF-8 텍스트 | 텍스트/바이너리 |
| 복잡도 | 낮음 | 낮음 | 중간~높음 |
| 사용 예시 | 날씨 업데이트, 알림 | 알림, 로그, 시세 | 채팅, 게임 |
SSE 동작 원리
클라이언트 요청
- 브라우저나 앱이 서버 /events 엔드포인트에 연결 요청
- 요청 헤더에 Accept: text/event-stream 포함
서버 응답
- Content-Type: text/event-stream로 응답 후 연결 유지
데이터 전송
- data:로 시작하는 텍스트 이벤트를 전송 (\n\n로 구분)
자동 재연결
- 연결이 끊어지면 EventSource API가 자동 재연결 시도
이러한 동작 특성을 가지고 있다보니, 실시간 통신 및 업데이트가 필요한 시나리오에 적합 합니다.
이와 반대로, 무조건은 아니지만 부적합한 경우가 있습니다.
- 양방향 통신 필요: 채팅, 게임 -> WebSocket 권장
- 대규모 바이너리 전송: 이미지, 동영상 -> WebSocket/gRPC 권장
마무리
종합해서 마무리를 해보자면,
SSE는 단방향 실시간 전송이 필요한 서비스에서 단순하고 효율적으로 쓸 수 있는 기술입니다.
하지만 모든 실시간 통신에 SSE가 답은 아닙니다.
DevOps/클라우드 엔지니어라면 서비스 특성을 보고 SSE vs WebSocket vs gRPC 중 무엇이 최적일지 판단해야 합니다.