📘 비동기 이벤트 푸시 방식 정리 (WebSocket vs SSE + Redis)

사이드 프로젝트를 진행하면서 실시간 알림을 보내는 기능을 게발하게 되었다.

간단히 설명을 하자면,,일정을 등록하면 쇼호스트에게 바로 알림이 가야 하고, 파일 업로드나 상태 변경도 즉시 반영되어야 하는 상황이다.

이번 프로젝트에서는 단순 SSE 구조를 넘어 Redis를 함께 사용하여
서버 간에도 알림이 전달될 수 있도록 구성하였다.

비동기 이벤트 푸시 방식으로 적용을 하였는데 이에 대해 정리 해보자 한다.

---

비동기 이벤트 푸시?

일반적인 웹 통신은 클라이언트가 요청을 보내고 서버가 응답을 주는 구조다.

클라이언트 → 요청 → 서버 → 응답 → 끝

이러한 흐름이 기본이지만, 실시간 알림 같은 경우는 좀 다르다.

클라이언트가 계속 요청을 보내는것이 아니라, 서버에서 이벤트에 발생했을 때 클라이언트에게 알려줘야한다.

이번 프로젝트에서는 관리자가 일정을 등록했을 때, 파일 업로드 시에 (이러한 이벤트 상황에) 클라이언트가 물어보지 않아도 서버가 먼저 알려줘야한다.

이걸 가능하게 해주는게 비동기 이벤트 푸시 방식이다.

클라이언트 → 연결 유지
서버 → 이벤트 발생 → 클라이언트로 push

이러한 구조이며, 요청 기반이 아니라 이벤트 기반으로 동작하는 통신 방식이다.

---

선택지

Polling : 계속 요청함 (비효율)

WebSocket : 양방향 (무겁고 복잡)

SSE : 서버 → 클라 단방향 (가볍고 쉬움)

비동기 이벤트 푸시 방식에는 이렇게 총 3가지의 선택지가 있다.

---

Polling

Polling은 일정 주기마다 서버에 계속 요청을 보내는 방식이다.

알림 있어? → 없음  
알림 있어? → 없음  
알림 있어? → 없음
...

이러한 과정을 계속 반복하는데, 이 방식은 서버에 불필요한 요청이 계속 들어가고 네트워크 낭비가 심해서 제외했다.

---

WebSocket

WebSocket은 클라이언트와 서버가 서로 데이터를 주고받을 수 있는 양방향 통신 방식이다.

한 번 연결을 맺으면 이후에는 HTTP 요청/응답 과정 없이 실시간으로 데이터를 주고받을 수 있다.

클라이언트 ↔ 서버 (양방향)

이러한 구조이며 채팅, 게임, 실시간 협업처럼 클라이언트와 서버가 서로 데이터를 계속 주고받아야하는 경우에 적합하다.

하지만 별도의 프로토콜(ws://) 사용, 연결 관리 필요, 설정과 구현이 복잡하다는 특징으로 인해 단순 알림 기능을 구현하기에 과하다고 판단하여 제외하였다.

---

SSE

SSE(Server-Sent Events)는 서버에서 클라이언트로 데이터를 보내는 단방향 통신 방식이다.

HTTP 기반으로 동작하며, 클라이언트가 한 번 요청을 보내면 서버는 연결을 끊지 않고 유지하면서 이벤트가 발생할 때마다 데이터를 전송한다.

클라이언트 -------- 연결 유지 -------- 서버

             (끊기지 않는 HTTP)

서버 → 이벤트 발생 → 클라이언트로 push

WebSocket과 비교했을 때 별도의 프로토콜이 아니라 HTTP를 사용하고 구현이 간단하며, 서버에서 클라이언트 알림에 최적화된다는 장점이있다.

이번 프로젝트에는 일정 생성, 파일 업로드 시 알림이라는 서버에서 클라이언트로 이벤트를 전달하는 것이라 (클라이언트가 서버로 실시간 데이터를 보낼 필요는 없다) SSE로 선택을 하였다.

---

SSE 구조의 한계

기본적인 SSE 구조는 서버가 1대일 경우에는 문제가 없지만, 서버가 여러 대로 확장되는 경우 문제가 발생할 수 있다.

A 서버에서 이벤트가 발생하였는데, B 서버에 클라이언트 연결이 존재한다고 예를 들어보자,,

이 경우 A에서 발생한 알림은 B에 전달되지 않는다,,서버가 2개 이상부터는 그렇다.

이 문제를 해결하기 위해 Redis를 추가하였다.

---

Redis

Redis는 인메모리 기반의 데이터 저장소로, 빠른 속도를 바탕으로 캐시, 세션 저장, 메시지 브로커로 많이 사용된다.

이번 프로젝트에서는 데이터를 저장하는 용도가 아니라 서버 간 메시지를 전달하기 위한 역할로 사용하였다.

기본적인 SSE 구조에서는 서버가 1대일 경우 문제가 없지만, 서버가 여러 대로 늘어나는 순간 알림 전달이 끊기는 문제가 발생한다.

이를 해결하기 위해 Redis의 Pub/Sub 구조를 활용하였다.

Publisher → Redis → Subscriber

Publisher : 이벤트 발생 시 메시지 발행
Redis : 메시지를 중간에서 전달
Subscriber : 메시지를 받아 처리

위 구조를 통해 어떤 서버에서 이벤트가 발생하더라도 모든 서버가 동일한 메시지를 전달받으며, 각 서버는 자신이 가지고 있는 SSE 연결을 통해 클라이언트에게 알림을 보낼 수 있다.

즉 Redis를 통해 서버 간 의존성 제거, 확장 가능한 구조, 안정적인 알림 전달+빠름..이렇게 3가지를 얻을 수 있다.

---

SSE 구현

SSE를 구현하기 위해 크게 3가지 구성으로 나누어 설계하였다.

1. Emitter 저장소

Emitter : 서버가 클라이언트에게 계속 메시지를 보내기 위한 연결 통로

SSE는 사용자마다 연결이 유지되기 때문에 각 사용자별 연결을 저장할 공간이 필요하다.

이를 위해 SseEmitter를 Map 형태로 관리하였다.

private final Map<Long, SseEmitter> emitters = new ConcurrentHashMap<>();

key는 사용자 ID, value는 해당 사용자의 SSE 연결 객체이다. 이 구조를 통해 특정 사용자에게 알림을 보낼 수 있다.

2. SSE 연결 생성

클라이언트가 SSE 연결을 시작하는 API이다.

@GetMapping("/subscribe")
public SseEmitter subscribe(...) {
    return notificationService.connect(memberId);
}

SseEmitter emitter = new SseEmitter(60 * 60 * 1000L);
emitterRepository.save(memberId, emitter);

클라이언트가 이 API를 한 번 호출하면 서버와의 연결이 유지되며, 이후에는 별도의 요청 없이도 이벤트를 받을 수 있다.

3. 이벤트 발생

일정 생성, 파일 업로드 등 이벤트가 발생하면 즉시 Redis로 메시지를 전달한다.

notificationPublisher.publish(notification);

이 시점에서 Notification 객체를 생성한 뒤, Redis로 메시지를 발행한다.

서버는 직접 클라이언트에게 알림을 보내는 것이 아니라, Redis를 통해 메시지를 전달하는 구조로 구성하였다.

4. Redis Publisher

redisTemplate.convertAndSend("notification", json);

Notification 객체를 JSON으로 변환한 뒤 “notification” 채널로 메시지를 발행한다.

이때 Redis는 해당 채널을 구독하고 있는 모든 서버에게 메시지를 전달하게 된다.

5. Redis Subscriber

Redis에서 메시지를 수신하여 실제 SSE로 전달하는 역할이다.

java

public void onMessage(Message message, byte[] pattern) {
    String body = new String(message.getBody());
    Notification notification =
        objectMapper.readValue(body, Notification.class);
    SseEmitter emitter =
        emitterRepository.get(notification.getMemberId());
    if (emitter != null) {
        emitter.send(
            SseEmitter.event()
                .name("notification")
                .data(notification)
        );
    }
}

Redis에서 메시지를 수신하면 JSON 데이터를 객체로 변환한 뒤, 해당 사용자에 대한 SSE 연결(emitter)을 조회한다.

여기서 해당 연결이 존재할 경우 그 emitter를 통해 클라이언트에게 알림을 전송한다.

Redis → 서버 → 사용자 emitter → 클라이언트

이 흐름으로 실제 알림이 전달된다.

---

전체 흐름

1. 클라이언트 → /subscribe 요청 (SSE 연결 생성)
2. 서버 → 사용자별 emitter 저장
3. 관리자 → 일정 생성 (이벤트 발생)
4. 서버 → Redis Publisher 호출
5. Redis → 메시지 전달
6. Redis Subscriber → 메시지 수신
7. 서버 → 특정 사용자 emitter 조회
8. SSE로 알림 push
9. 클라이언트 → 실시간 알림 수신

즉, SSE를 통해 클라이언트와의 연결을 유지하고, Redis Pub/Sub을 통해 서버 간 메시지를 전달하며 확장 가능한 실시간 알림 구조를 구성하였다.