Polling vs SSE vs WebSocket

웹 서비스에서 데이터를 실시간으로 업데이트하는 방식은 크게 세 가지가 있습니다.

---

1. 한눈에 보는 비교표

구분	Polling	SSE (Server-Sent Events)	WebSocket
방식	클라이언트가 주기적으로 질문	서버가 클라이언트에 일방적 푸시	양방향 전용 통로 개설
통신 방향	단방향 (C → S)	단방향 (S → C)	양방향 (C ↔ S)
연결 상태	끊어졌다 연결됐다 반복 (Stateless)	지속 연결 (Stateful)	지속 연결 (Stateful)
프로토콜	HTTP	HTTP	Websocket (ws/wss)
적합한 사례	대기열 순번 조회, 로그 확인	수강신청 대기열, 주식 시세	채팅, 실시간 멀티플레이 게임

---

2. 기술별 핵심 특징 및 장단점

🟢 Polling (폴링): "저기, 데이터 나왔어?" (반복 질문)

클라이언트가 일정 시간마다 서버에 새로운 데이터가 있는지 확인하는 방식입니다.

• 장점:
• 구현이 가장 쉽고 단순함 (표준 REST API 활용).
• 서버가 연결을 유지하지 않아 관리가 편함 (Stateless).

• 단점:
• 데이터가 없어도 계속 요청을 보내므로 서버 부하와 트래픽 낭비가 심함.
• 폴링 주기(Interval)만큼 지연(Latency) 발생.

🔵 SSE (Server-Sent Events): "데이터 나오면 내가 알려줄게!" (일방적 통지)

서버가 클라이언트와 연결을 유지한 채, 이벤트가 발생할 때마다 데이터를 스트리밍하는 방식입니다.

• 장점:
• HTTP 프로토콜을 사용하여 구현이 비교적 쉽고 가벼움.
• 자동 재연결 기능 내장.
• 서버 자원 소모가 WebSocket보다 적음.

• 단점:
• 클라이언트에서 서버로 데이터를 보낼 때는 별도의 HTTP 요청이 필요함 (단방향).
• 브라우저당 연결 개수 제한이 있음 (HTTP/1.1 기준 6개).

🟣 WebSocket (웹소켓): "우리 이제 이 전화선 끊지 말자." (실시간 대화)

서버와 클라이언트가 한 번 연결을 맺으면 자유롭게 데이터를 주고받는 전용 통로를 만듭니다.

• 장점:
• 진정한 실시간 양방향 통신 가능.
• 연결 후에는 HTTP 헤더 오버헤드가 없어 데이터 전송이 매우 효율적임.

• 단점:
• 설계 및 구현이 복잡하고 연결 유지 로직(Heartbeat)이 필요함.
• 연결을 계속 유지하므로 서버 메모리 자원을 많이 소모함.

---

3. [Deep Dive] 수강신청 대기열, 왜 Polling을 많이 쓸까?

이론적으로는 SSE나 WebSocket이 우수해 보이지만, 실무 수강신청 시스템에서 Polling을 선택하는 이유는 "운영의 안정성" 때문입니다.

1. 연결 관리의 부담: 수만 명이 동시에 SSE/WebSocket으로 연결을 유지하면 서버는 수만 개의 소켓을 들고 있어야 합니다. 이는 메모리 부족이나 서버 다운으로 이어질 수 있습니다.
2. Stateless의 장점: Polling은 요청이 끝나는 즉시 연결이 끊기므로, 서버를 수십 대(Auto-scaling)로 늘려도 로드밸런싱이 매우 쉽습니다.
3. Redis의 속도: 5초마다 Polling을 하더라도, 서버가 DB 대신 Redis에서 순번만 읽어준다면 충분히 빠른 속도로 수만 명을 처리할 수 있습니다.

결론: 기술적 우위보다 서비스의 트래픽 규모와 인프라 환경에 맞는 기술을 선택하는 것이 실무자의 역량입니다!

---

• 채팅처럼 주고받아야 한다면? ➡️ WebSocket
• 서버 알림이나 주가 지수처럼 흘려보내야 한다면? ➡️ SSE
• 인프라 관리가 최우선이고 안정적인 운영이 필요하다면? ➡️ Polling

---