WebSocket vs HTTP Polling: 실시간 통신 기술에 대해 알아보기

현대 웹 애플리케이션에서 실시간 통신은 필수 요소가 되었습니다. 채팅 앱, 실시간 알림, 주식 시세, 온라인 게임 등 수많은 서비스가 즉각적인 데이터 업데이트를 필요로 합니다.

이런 실시간성을 구현하는 두 가지 주요 기술이 바로 HTTP Polling과 WebSocket입니다. 각 기술은 고유한 특징과 장단점을 가지고 있어, 상황에 따라 적절한 선택이 필요합니다.

이 글에서는 두 기술의 작동 원리부터 실제 구현, 성능 비교, 그리고 어떤 상황에서 어떤 기술을 선택해야 하는지까지 상세히 알아보겠습니다.

기본 개념 이해하기

HTTP Polling이란?

HTTP Polling은 클라이언트가 주기적으로 서버에 요청을 보내 새로운 데이터가 있는지 확인하는 방식입니다.

동작 흐름

시간 0초: 클라이언트 → 서버: "새 메시지 있어요?"
        서버 → 클라이언트: "없어요" (빈 응답)

시간 3초: 클라이언트 → 서버: "새 메시지 있어요?"
        서버 → 클라이언트: "없어요" (빈 응답)

시간 6초: 클라이언트 → 서버: "새 메시지 있어요?"
        서버 → 클라이언트: "네, 여기요!" (메시지 전달)

---

WebSocket이란?

WebSocket은 클라이언트와 서버 간에 지속적인 양방향 연결을 유지하는 프로토콜입니다.

동작 흐름

시간 0초: 클라이언트 ⇄ 서버: 연결 수립 (핸드셰이크)
        연결 완료!

시간 2초: 클라이언트 → 서버: "안녕하세요!"
        서버 → 클라이언트: "반갑습니다!"

시간 5초: 서버 → 클라이언트: "새 알림이 도착했어요"
        (서버가 먼저 보낼 수 있음!)

시간 8초: 클라이언트 → 서버: "확인했어요"

---

비교 정리

비교 항목	HTTP Polling	WebSocket
연결 방식	매번 새로 연결	한 번 연결 후 유지
통신 방향	클라이언트 → 서버만	양방향 자유롭게
비유	우편함 확인 (반복 방문)	전화 통화 (연결 유지)
요청 주체	항상 클라이언트가 물어봄	양쪽 모두 먼저 보낼 수 있음
실시간성	폴링 간격만큼 지연	즉시 전달

HTTP Polling 깊이 알아보기

Short Polling (단기 폴링)

Short Polling은 가장 단순한 형태의 폴링입니다. 클라이언트가 정해진 간격으로 반복적으로 서버에 요청합니다.

단기 폴링 시퀀스

위 다이어그램에서 볼 수 있듯이, Short Polling은 일정한 시간 간격(예: 3초)마다 클라이언트가 서버에 요청을 보냅니다. 서버는 데이터베이스를 확인하여 새로운 메시지가 있으면 즉시 응답하고, 없으면 빈 응답을 반환합니다. 이후 클라이언트는 정해진 시간(3초)을 기다린 후 다시 요청을 반복합니다.

이 방식의 가장 큰 문제는 새로운 데이터가 없어도 지속적으로 요청을 보낸다는 점입니다. 예를 들어, 새 메시지가 1분에 한 번만 도착한다면, 3초마다 요청하는 20번 중 19번은 빈 응답을 받게 되어 네트워크와 서버 리소스를 낭비하게 됩니다.

장점	단점
구현이 매우 간단	불필요한 요청으로 서버 부하 증가
모든 브라우저에서 지원	실시간성 부족(폴링 간격만큼 지연)
방화벽 친화적	네트워크 트래픽 낭비

Long Polling (장기 폴링)

Long Polling은 Short Polling의 단점을 개선한 방식입니다. 서버가 즉시 응답하지 않고 새 데이터가 있을 때까지 연결을 유지합니다.

장기 폴링 시퀀스

Long Polling의 핵심은 서버가 즉시 응답하지 않고 "기다린다"는 점입니다. 클라이언트가 요청을 보내면, 서버는 최대 30초 동안 연결을 유지하면서 0.5초마다 데이터베이스를 확인합니다. 새로운 메시지가 도착하는 즉시 응답을 보내거나, 타임아웃(30초)이 발생하면 빈 응답을 반환합니다.

클라이언트는 응답을 받는 즉시 다시 연결을 시도하므로, Short Polling과 달리 불필요한 대기 시간이 없습니다. 이를 통해 실시간성을 크게 개선하면서도 불필요한 요청을 줄일 수 있습니다. 다만 여전히 서버는 각 클라이언트마다 연결을 유지해야 하므로, 동시 접속자가 많을 경우 서버 부하가 발생할 수 있습니다.

WebSocket

WebSocket 연결 및 핸드셰이크

WebSocket은 HTTP 핸드셰이크로 시작해 프로토콜을 업그레이드합니다.

WebScoket 핸드셰이크 시퀀스

WebSocket 연결은 일반 HTTP 요청으로 시작합니다. 클라이언트는 서버에 Upgrade: websocket 헤더를 포함한 HTTP 요청을 보내 "WebSocket으로 프로토콜을 업그레이드하고 싶다"고 알립니다. 서버가 이를 승인하면 101 Switching Protocols 응답을 반환하며, 이 시점부터 HTTP 연결이 WebSocket 연결로 전환됩니다.

연결이 확립되면 클라이언트는 onopen 이벤트를 수신하고, 이후부터는 양방향 통신이 가능한 지속적인 연결 상태가 유지됩니다. 이 연결을 통해 클라이언트와 서버는 언제든지 자유롭게 메시지를 주고받을 수 있으며, 매번 새로운 HTTP 요청을 만들 필요가 없습니다.

WebSocket 이벤트 처리 및 브로드캐스트

Websocket 브로드캐스트 시퀀스

브로드캐스트는 WebSocket의 중요 기능 중 하나입니다. 위 다이어그램은 한 클라이언트(Client 1)가 메시지를 보내면 서버가 이를 다른 모든 연결된 클라이언트들(Client 2, 3)에게 동시에 전달하는 과정을 보여줍니다.

서버는 연결된 모든 클라이언트 목록을 관리하며, 메시지를 받으면 발신자를 제외한 다른 클라이언트들에게 즉시 전파합니다. 각 클라이언트는 onmessage 이벤트를 통해 메시지를 수신하고 UI를 업데이트합니다. 이러한 방식으로 실시간 채팅, 협업 도구, 멀티플레이어 게임 등이 구현됩니다.

WebSocket 재연결 로직

지수백오프 방식 재연결 시퀀스

네트워크는 항상 불안정할 수 있으므로, 재연결 로직은 필수입니다. 위 다이어그램은 연결이 끊어졌을 때 지수 백오프(Exponential Backoff) 전략을 사용하여 재연결을 시도하는 과정을 작성했습니다.

연결이 끊기면 클라이언트는 즉시 재연결을 시도하지 않고, 1초 → 2초 → 4초 → 8초와 같이 점진적으로 대기 시간을 늘려가며 재연결을 시도합니다. 이는 서버가 일시적으로 과부하 상태일 때 더 많은 재연결 요청으로 상황을 악화시키지 않기 위함입니다.

재연결에 성공하면 재시도 카운터를 리셋하고, 연결이 끊어진 동안 큐에 쌓인 메시지들을 순차적으로 전송합니다. 최대 재시도 횟수(예: 5회)를 초과하면 재연결을 포기하고 사용자에게 알립니다.

성능 비교표

특성	HTTP Short Polling	HTTP Long Polling	WebSocket
레이턴시	높음 (폴링 간격)	중간 (즉시~타임아웃)	낮음 (즉시)
서버 부하	높음 (지속적 요청)	중간 (연결 유지)	낮음 (단일 연결)
네트워크 효율	낮음 (헤더 오버헤드)	중간	높음 (최소 오버헤드)
양방향 통신	불가능	불가능	가능
연결 수	요청마다 새 연결	긴 연결 유지	지속적 연결
프록시 호환성	매우 좋음	좋음	제한적
방화벽 통과	쉬움	쉬움	어려울 수 있음
브라우저 지원	모든 브라우저	모든 브라우저	현대 브라우저
구현 복잡도	매우 낮음	낮음	중간
확장성	제한적	제한적	높음

 

선택 가이드

시퀀스로 비교해보기

폴링과 소켓의 비교 시퀀스

10초라는 짧은 시간 동안에도 두 방식의 차이는 극명합니다. Short Polling은 3초 간격으로 3번의 완전한 HTTP 요청/응답 사이클을 거치며, 매번 약 500바이트의 HTTP 헤더 오버헤드가 발생합니다. 총 1.5KB 이상의 헤더 데이터만으로도 상당한 대역폭을 소비합니다.

반면 WebSocket은 초기 핸드셰이크 이후 연결을 유지하며, 각 메시지마다 단 2바이트의 프로토콜 헤더만 필요합니다. 동일한 데이터를 전송하더라도 네트워크 효율은 수십 배에서 수백 배까지 차이가 날 수 있습니다. 이러한 차이는 동시 접속자가 많거나 메시지 빈도가 높을수록 더욱 두드러집니다.

그렇다면 어느 기술을 적용해야할까?

프로젝트에 적합한 기술을 선택하려면 실시간성의 중요도, 통신 방향, 업데이트 빈도, 시스템 제약사항을 종합적으로 고려해야 합니다. 해당 섹션은 핵심조건 기준으로 AI 에게 실제 적용된 사례에 대한 답변을 바탕으로 작성했습니다.

HTTP Polling이 적합한 경우

핵심 조건

• 업데이트 빈도가 낮음 (분 단위 이상)
• 단방향 통신으로 충분 (서버 → 클라이언트)
• 레거시 시스템 호환성 필요
• 간단한 구현과 낮은 복잡도 우선
• 프록시/방화벽 제약이 심한 환경

실제 상황 예시

1. 이메일 클라이언트 (Gmail, Outlook)
이메일은 몇 분 정도 지연되어도 사용자 경험에 큰 영향이 없습니다. 5분마다 새 메일을 확인하는 Short Polling으로도 충분하며, 배터리 소모를 최소화할 수 있습니다.

2. 뉴스 피드 / SNS 타임라인
뉴스 피드는 RESTful API 구조를 유지하면서 CDN을 통한 캐싱이 가능해야 합니다. HTTP Polling은 기존 API 엔드포인트를 그대로 활용할 수 있어 아키텍처 변경이 최소화됩니다.

3. IoT 센서 데이터 수집
온도, 습도, 전력 사용량 등을 수집하는 IoT 센서는 주기적으로 데이터를 보고하는 패턴입니다. 센서가 슬립 모드로 전환될 수 있고, 지속적인 연결 유지가 어렵기 때문에 Polling이 더 적합합니다.

4. 대시보드 / 모니터링 화면
관리자 대시보드나 시스템 모니터링 화면은 수십 초 단위의 업데이트로도 충분합니다. 복잡한 WebSocket 인프라 없이 간단하게 구현할 수 있습니다.

---

WebSocket이 적합한 경우

핵심 조건

• 진정한 실시간성 필요 (밀리초~수백 밀리초)
• 양방향 통신 필수
• 높은 업데이트 빈도 (초당 여러 번)
• 대량의 동시 접속 처리
• 낮은 레이턴시가 핵심 요구사항

실제 적용 사례

1. 실시간 채팅 (Slack, Discord, KakaoTalk)
메시지를 보낸 즉시 상대방이 받아야 하고, 타이핑 표시나 읽음 확인 같은 실시간 피드백이 필수입니다. WebSocket의 양방향 통신으로 자연스러운 대화 경험을 제공할 수 있습니다.

2. 온라인 멀티플레이어 게임
게임에서는 밀리초 단위의 레이턴시가 승패를 결정합니다. 플레이어의 입력을 즉시 서버에 전송하고, 다른 플레이어의 움직임을 실시간으로 받아야 하므로 WebSocket이 필수입니다.

3. 금융 거래소 (주식, 암호화폐)
초 단위 가격 변동이 수익과 직결되는 트레이딩에서는 실시간 데이터가 생명입니다. WebSocket을 통해 오더북, 체결 내역, 가격 차트를 지연 없이 스트리밍합니다.

4. 협업 도구 (Google Docs, Figma, Notion)
여러 사용자가 동시에 문서를 편집할 때, 각자의 변경사항이 즉시 다른 사용자에게 반영되어야 합니다. WebSocket으로 모든 편집 작업을 실시간으로 동기화하여 충돌을 방지합니다.

5. 실시간 알림 시스템
사용자가 페이지를 새로고침하지 않아도 주문 상태 변경, 배달 기사 위치, 시스템 알림 등을 즉시 받을 수 있습니다.

6. 라이브 스트리밍 채팅 / 댓글
YouTube Live, Twitch 등에서 수천 명이 동시에 채팅하는 환경에서는 WebSocket의 효율적인 연결 관리가 필수입니다.

마무리

WebSocket과 HTTP Polling은 각각의 장단점을 가진 실시간 통신 기술입니다. 대부분의 현대적인 실시간 애플리케이션에서는 WebSocket이 선호되지만, 레거시 지원이나 단순한 요구사항에서는 HTTP Polling도 여전히 유효한 선택일 수 있습니다. 중요한 것은 프로젝트의 요구사항을 정확히 파악하고, 그에 맞는 기술을 선택하는 것입니다. 때로는 두 기술을 조합하여 사용하는 것이 최선의 해결책이 될 수도 있습니다.

앞으로 WebTransport, WebRTC DataChannel 등 새로운 기술들도 등장하고 있지만, WebSocket과 HTTP Polling의 기본 개념을 이해한다면 이러한 새로운 기술들도 쉽게 학습할 수 있을 것 같습니다.