SSE와 Polling, 실시간 데이터 전달 방식 이해하기

웹 서비스에서 서버의 데이터를 실시간으로 전달해야 하는 경우가 있다.
예를 들어 알림, 채팅, 작업 진행 상태, 실시간 로그 등을 사용자에게 보여줘야 한다면 서버와 클라이언트가 데이터를 주고받는 방식에 대한 고민이 필요하다.

 

대표적인 방식으로 Polling과 SSE(Server-Sent Events)가 있다.

 

1. Polling이란?

Polling(폴링)은 클라이언트가 일정한 주기마다 서버에 요청을 보내 새로운 데이터가 있는지 확인하는 방식이다.

예를 들어 새로운 알림이 있는지 확인한다고 하면:

Client → Server : 새로운 알림 있어?

Server → Client : 없어

 

↓ 5초 후

 

Client → Server : 새로운 알림 있어?

Server → Client : 없어

 

↓ 5초 후

 

Client → Server : 새로운 알림 있어?

Server → Client : 있어! 🔔

 

즉, 서버가 먼저 데이터를 보내는 것이 아니라 클라이언트가 주기적으로 확인하는 구조다.

 

장점

• 구현이 비교적 단순하다.
• 일반적인 HTTP 요청/응답 방식이라 기존 인프라와 호환성이 좋다.
• 연결을 계속 유지할 필요가 없다.

단점

• 실제 데이터가 없어도 계속 요청이 발생한다.
• 요청 주기가 길면 데이터 전달이 늦어질 수 있다.
• 요청 주기를 짧게 설정하면 서버와 네트워크에 불필요한 부하가 발생할 수 있다.

---

2. SSE(Server-Sent Events)란?

SSE(Server-Sent Events)는 서버와 클라이언트 사이의 HTTP 연결을 하나 유지하면서, 서버가 새로운 데이터가 발생할 때 클라이언트에게 데이터를 지속적으로 전달하는 방식이다.

Polling과 반대로 서버가 데이터를 전달할 수 있다는 점이 핵심이다.

 

Client ─────────→ Server
       연결 요청

Client ←───────── Server
       연결 유지

Client ←───────── Server
       새로운 데이터

Client ←───────── Server
       새로운 데이터

Client ←───────── Server
       새로운 데이터

 

예를 들어 실시간 알림이라면 클라이언트가 계속

"새 알림 있어?"

라고 물어보는 것이 아니라,

"새 알림이 생기면 서버가 나한테 알려줘."

라고 연결을 유지해두는 것이다.

 

3. SSE와 Polling의 차이

구분	Polling	SSE
데이터 요청	클라이언트가 주기적으로 요청	서버가 이벤트 발생 시 전달
연결 방식	요청 → 응답 반복	하나의 HTTP 연결 유지
실시간성	낮음~중간	높음
서버 요청 수	많아질 수 있음	상대적으로 적음
구현 난이도	비교적 쉬움	상대적으로 복잡
서버 → 클라이언트	가능	가능
클라이언트 → 서버	가능	별도 HTTP 요청 필요
적합한 상황	간단한 주기적 조회	실시간 알림, 로그, 상태 업데이트

 

4. SSE는 왜 사용했을까?

Polling은 일정한 주기로 서버에 요청해야 하기 때문에 데이터가 발생하지 않았는데도 요청이 계속 발생한다는 단점이 있다.

반면 SSE는 연결을 유지하고 있다가 실제로 새로운 데이터가 발생했을 때만 서버가 데이터를 전달할 수 있다.

예를 들어 작업 진행 상황을 보여주는 서비스라면:

 

Polling 이라면..

Client → "작업 끝났어?"
Server → "아직"

Client → "작업 끝났어?"
Server → "아직"

Client → "작업 끝났어?"
Server → "ㅇㅇ 끝남"

 

SSE라면:

 

Client → Server
        "작업 상태 알려줘."

        연결 유지

Server → Client
        "30%"

Server → Client
        "60%"

Server → Client
        "100% 완료!"

불필요한 반복 요청을 줄이면서 서버에서 발생한 이벤트를 빠르게 전달할 수 있음.. 

 

5. 그런데 SSE에도 문제가 있다

SSE는 단순히 HTTP 요청을 한 번 보내고 끝나는 구조가 아니라 연결을 계속 유지하는 Long-lived Connection을 사용한다.

그래서 중간에 있는 Proxy, Load Balancer, Gateway, Service Mesh 등의 네트워크 구성이 연결을 어떻게 처리하느냐가 중요하다.

예를 들어 Kubernetes 환경에서 Istio를 사용하는 경우:

Client
   ↓
Load Balancer
   ↓
Istio / Envoy
   ↓
SSE Server

 

SSE 연결이 Istio/Envoy의 timeout, buffering 등의 설정과 충돌하면 연결이 예상보다 빨리 종료되거나 이벤트가 실시간으로 전달되지 않는 문제가 발생할 수 있다.

따라서 SSE를 도입할 때는 애플리케이션 코드뿐만 아니라 중간 네트워크 계층의 설정까지 함께 확인해야 한다.

 

6. 그래서 Polling으로 변경하기도 한다

SSE 적용
   ↓
Istio / Proxy 환경에서 Long-lived Connection 처리 이슈
   ↓
인프라 설정 변경의 부담
   ↓
Polling 방식으로 변경

 

실제 서비스에서는 SSE가 기술적으로 더 적합하더라도 인프라 환경이나 운영 복잡성 때문에 Polling으로 변경하는 경우도 있다.

이 경우 실시간성을 어느 정도 포기하는 대신 기존 HTTP 요청/응답 구조를 그대로 활용할 수 있다는 장점이 있다.

예를 들어 5초 주기의 Polling을 사용한다면 최대 약 5초 정도의 지연은 발생할 수 있지만, 구현과 운영 측면에서는 훨씬 단순해질 수 있다.

 

마무리

Polling과 SSE는 모두 서버의 변경된 데이터를 클라이언트에게 전달하기 위한 방법이지만 접근 방식이 다르다.

Polling은

"내가 주기적으로 서버에게 물어볼게."

SSE는

"연결해둘 테니까 새로운 데이터가 생기면 서버가 알려줘."

라고 이해하면 가장 쉽다.

 

따라서 단순한 주기적 데이터 확인이 필요하다면 Polling을,

실시간 알림이나 로그처럼 서버에서 발생하는 이벤트를 빠르게 전달해야 한다면 SSE를 고려할 수 있다.

 

다만 SSE는 Long-lived Connection을 사용하기 때문에

Proxy, Load Balancer, Istio와 같은 인프라 환경까지 함께 고려해야 한다.

 

끗