Polling은 client가 일정 간격으로 server에 “새 데이터 있나요?”라고 묻는 방식입니다. 구현은 쉽지만 불필요한 요청이 많거나 실시간성이 떨어질 수 있습니다. SSE는 server가 client에게 event를 계속 보내는 방식입니다. server-to-client 단방향 업데이트에 좋습니다.
WebSocket은 handshake 이후 지속 연결을 만들고 양방향 메시지를 주고받습니다. 채팅, 협업 편집, 게임처럼 client와 server가 자주 주고받아야 하면 WebSocket이 어울립니다. 단순 알림 stream이면 SSE가 더 단순할 수 있습니다.
꼬리질문
조금 더 깊게 물어본다면
답변 뒤에 이어질 수 있는 질문들을 하나씩 열어볼 수 있어요.
long polling은 일반 polling과 어떻게 다른가요?
일반 polling은 주기적으로 바로 응답을 받습니다. long polling은 server가 새 데이터가 생길 때까지 요청을 잠시 열어두고, 응답 후 client가 다시 요청합니다.
실시간성을 조금 높이면서 WebSocket보다 단순하게 구현할 수 있습니다.
SSE는 양방향 통신이 가능한가요?
SSE 자체는 server에서 client로 보내는 단방향 stream입니다. client에서 server로 보내야 하는 데이터는 별도 HTTP 요청을 사용해야 합니다.
양방향 메시지가 빈번하면 WebSocket이 더 자연스러울 수 있습니다.
WebSocket은 HTTP인가요?
처음에는 HTTP Upgrade handshake로 시작하지만, 연결이 upgrade된 뒤에는 WebSocket protocol로 메시지를 주고받습니다.
그래서 proxy, load balancer, timeout 설정을 별도로 고려해야 할 수 있습니다.
어떤 상황에서 무엇을 선택하나요?
업데이트 방향, 빈도, 지연 요구사항, 인프라 지원, reconnect 전략을 봅니다. 단방향 알림이면 SSE, 양방향 빈번한 메시지면 WebSocket, 가끔 확인하면 polling도 충분할 수 있습니다.
무조건 더 복잡한 기술이 좋은 선택은 아닙니다.
부가 설명
Polling: client -> server 반복 요청SSE: server -> client event streamWebSocket: client <-> server 양방향 persistent connection
실시간 기능이라고 무조건 WebSocket을 선택할 필요는 없습니다. 데이터 방향과 빈도, 인프라 지원을 봐야 합니다.
WebSocket은 강력하지만 connection 관리, reconnect, heartbeat, scale-out 시 pub/sub 구조 같은 운영 고민이 생깁니다. SSE는 HTTP 기반이라 단순하지만 binary data나 양방향 통신에는 맞지 않습니다. Polling은 가장 단순하지만 요청 비용과 지연을 감수해야 합니다.