이 글에서 얻는 것
- WebSocket/SSE/Webhook(그리고 필요하면 Long Polling)을 “유행”이 아니라 **요구사항(방향/지연/규모/신뢰성)**으로 선택할 수 있습니다.
- 실시간 시스템에서 가장 어려운 문제(연결 관리, 재연결, 순서/중복, 백프레셔, 스케일 아웃)를 어떻게 풀지 패턴이 생깁니다.
- Webhook을 안전하게 운영하기 위한 서명 검증/재시도/멱등성 기준을 정리할 수 있습니다.
0) 먼저 “실시간”의 정의를 정하라
실시간은 한 가지가 아닙니다.
- 즉시성: 100ms가 필요한가, 2~3초여도 되는가?
- 방향: 서버→클라이언트만이면 되는가, 양방향이 필요한가?
- 신뢰성: 유실이 0이어야 하나(정산/결제), 몇 개 유실은 허용 가능한가(알림)
이 세 가지가 프로토콜 선택을 거의 결정합니다.
1) 선택 기준: WebSocket vs SSE vs Webhook
1-1) WebSocket
- 양방향, 낮은 지연
- 채팅/실시간 협업/게임/상태 동기화에 적합
대가:
- 연결 관리(수십만 커넥션), LB/프록시 설정, 스케일 아웃(세션/룸) 문제가 생깁니다.
1-2) SSE(Server-Sent Events)
- 단방향(서버 → 클라이언트) 스트리밍
- HTTP 기반이라 브라우저/프록시 친화적이고 운영 난이도가 낮은 편
- 알림/피드 업데이트처럼 “서버가 푸시”만 필요할 때 강력
특징:
- 클라이언트는 자동 재연결을 지원하고,
Last-Event-ID같은 방식으로 이어받기가 가능합니다.
1-3) Webhook
- 서버 → 서버 비동기 알림(외부 연동/동기화)
- 이벤트 기반 통합에 적합(결제 승인, 배송 상태 변경 등)
대가:
- 재시도/중복/서명 검증/수신자 장애를 전제로 설계해야 합니다.
2) 연결 관리: 하트비트와 재연결이 기본이다
WebSocket/SSE 모두 “연결은 끊어진다”를 전제로 해야 합니다.
- 하트비트(ping/pong 또는 주기적 이벤트)로 유령 연결을 정리
- 재연결 시 “마지막으로 받은 이벤트”부터 이어받을 수 있는 설계(이벤트 id, 오프셋)
- 토큰 만료/갱신: 장기 연결에서 인증을 어떻게 갱신할지(재연결 시 재인증, 짧은 토큰 + 리프레시)
3) 스케일 아웃: 커넥션이 서버를 ‘고정’시키는 문제
3-1) Sticky session(세션 고정)만으로는 한계가 있다
초기에는 편하지만, 서버 증설/축소/장애 시 재연결 폭풍(reconnect storm)이 생길 수 있습니다.
3-2) Pub/Sub로 팬아웃을 분리한다
채팅/알림처럼 “여러 서버가 여러 클라이언트에게 푸시”해야 하면 보통:
- 클라이언트 연결은 각 서버가 유지하고,
- 메시지 브로커(예: Redis Pub/Sub, Kafka 등)로 서버 간 fan-out을 합니다.
여기서 중요한 건 “전달 보장 수준(유실/중복)”을 무엇으로 둘지입니다.
4) 백프레셔: 느린 소비자가 전체를 망치지 않게
실시간 시스템에서 흔한 장애:
- 일부 클라이언트가 느리다 → 서버의 버퍼가 쌓인다 → 메모리/스레드가 고갈된다
대응 패턴:
- per-connection 버퍼 제한(초과 시 드롭/연결 종료)
- 메시지 우선순위(중요 이벤트만 유지)
- 서버 측 샘플링/코얼레싱(예: 상태 업데이트는 최신만)
5) Webhook 설계 포인트(운영형)
Webhook은 “상대가 반드시 실패한다”를 전제로 합니다.
- 서명 검증(HMAC 등)으로 위조 방지
- 재시도 정책(백오프 + 최대 횟수)과 DLQ/보관
- 멱등성 키로 중복 처리 방지(같은 이벤트가 여러 번 올 수 있음)
- 타임아웃을 짧게 두고, 수신자는 2xx를 빠르게 반환한 뒤 비동기로 처리(가능하면)
연습(추천)
- SSE로 “알림 스트림”을 만들고, 이벤트 id 기반으로 재연결 시 이어받기(Last-Event-ID)를 구현해보기
- WebSocket에서 느린 클라이언트를 시뮬레이션해 버퍼가 쌓일 때 정책(드롭/종료/샘플링)을 비교해보기
- Webhook 수신 API에 서명 검증 + 멱등성 키 + 재시도(백오프) 정책을 붙이고, 중복/지연이 와도 안전한지 테스트해보기
💬 댓글