실시간 통신 메커니즘 (Polling / SSE / WebSocket)
핵심 가이드
브라우저는 데이터의 실시간 업데이트를 어떻게 구현할까? 전통적인 HTTP 프로토콜은 "요청-응답" 모델을 기반으로 하며, 클라이언트가 능동적으로 요청을 시작해야 서버가 데이터를 반환할 수 있습니다. 채팅방, 주식 시세 푸시 등의 실시간 시나리오를 구현해야 한다면 이 모델은 한계에 직면하게 됩니다.
이 장에서는 실시간 데이터 통신에 대응하는 프론트엔드의 세 가지 주요 기술인 단폴링(Polling), 서버 전송 이벤트(SSE), 그리고 풀듀플렉스 WebSocket을 소개하고, 그 원리와 적용 시나리오를 탐구합니다.
1. 전통적인 HTTP의 한계
HTTP 프로토콜은 원래 문서 검색을 위해 설계되었으며, 무상태(Stateless)이고 클라이언트가 일방적으로 요청을 시작하는 특징이 있습니다:
- 클라이언트가 HTTP 요청을 시작합니다.
- 서버가 요청을 처리하고 응답을 반환합니다.
- 연결이 작업을 완료한 후 일반적으로 해당 논리적 요청이 해제됩니다(HTTP/1.1은 영구 연결 재사용을 지원하지만, 비즈니스 계층의 요청-응답 모델은 변하지 않습니다).
이 모드에서는 서버가 대기 중인 클라이언트에게 상태 변경을 능동적으로 알릴 수 없습니다. 최신 데이터를 얻으려면 다른 기술 아키텍처 솔루션을 찾아야 합니다.
2. 단폴링 (Polling)
가장 직접적인 해결책은 단폴링입니다. 즉, 클라이언트가 타이머(예: setInterval)를 이용하여 일정한 간격마다 자동으로 서버에 HTTP 요청을 보내 새로운 데이터가 도착했는지 확인합니다.
기술적 특징과 한계:
- 장점: 구현 메커니즘이 매우 간단하며, 표준 HTTP 프로토콜과 AJAX/Fetch 기술에 전적으로 의존합니다.
- 단점: 막대한 네트워크 오버헤드와 자원 낭비가 발생할 수 있습니다. 대부분의 시간 동안 서버의 응답은 "새 데이터 없음"일 수 있습니다. 데이터 유무와 관계없이 모든 요청은 완전한 HTTP 헤더(Headers, Cookies 등)를 전송해야 하므로, 동시 접속자가 많은 시나리오에서는 네트워크 자원이 의미 없는 질의로 대량 점유됩니다.
3. 서버 전송 이벤트 (Server-Sent Events)
잦은 HTTP 연결 설정의 오버헤드를 줄이기 위해, Server-Sent Events (SSE)는 경량의 단방향 데이터 스트림 푸시 아키텍처를 제공합니다.
SSE는 HTTP 프로토콜 위에 구축됩니다. 클라이언트가 특수한 요청 헤더(Accept: text/event-stream)가 포함된 HTTP 요청을 시작하면, 서버는 응답을 반환할 때 하위 TCP 연결을 끊지 않고 유지합니다. 이후 서버는 이 지속적인 채널을 통해 텍스트 형식의 데이터를 지속적으로 클라이언트에 푸시할 수 있습니다.
기술적 특징과 한계:
- 장점: 연결이 지속되어 네트워크 오버헤드가 적습니다; 브라우저가 기본적으로 연결 끊김 시 자동 재연결 메커니즘을 지원합니다; 서버에서 클라이언트로의 단방향 스트리밍 데이터 전송(예: 대규모 언어 모델의 텍스트 글자별 출력, 실시간 거래 시세 푸시)에 매우 적합합니다.
- 단점: 통신 채널이 단방향입니다. 클라이언트가 서버에 제어 명령을 보내거나 새로운 데이터를 전송하려면 별도의 일반 HTTP 요청을 설정해야 합니다.
4. WebSocket: 풀듀플렉스 통신 프로토콜
애플리케이션 시나리오에 고빈도의 양방향 상호작용(예: 다인 온라인 액션 게임, 정밀한 실시간 문서 공동 편집)이 포함될 때, 통신 오버헤드를 줄이면서도 진정한 듀플렉스 통신을 실현할 수 있는 기술이 필요합니다—바로 WebSocket입니다.
WebSocket은 독립적인 네트워크 통신 프로토콜입니다. HTTP 프로토콜을 교묘하게 활용하여 초기 연결을 설정합니다:
- 핸드셰이크 단계: 클라이언트가 특수한 HTTP 요청을 보내 새 프로토콜로 업그레이드하기를 희망한다고 선언합니다(
Upgrade: websocket헤더 포함). - 연결의 질적 변화: 서버가 이를 지원하고 동의하면
101 Switching Protocols상태 코드로 응답합니다. - 완전한 자유: 이 시점에서 HTTP의 규범적 임무는 종료되고, 하위 TCP 연결이 WebSocket 프로토콜로 이관됩니다. 이후 클라이언트와 서버는 평등한 풀듀플렉스(Full-Duplex) 통신 권한을 가지며, 양측은 언제든지 최소 형식의 데이터 프레임을 송수신할 수 있습니다.
기술적 특징과 한계:
- 장점: 진정한 양방향 실시간 통신을 지원합니다; 데이터 프레임의 헤더 정보가 극도로 작아 통신 지연이 낮고 처리 효율이 높습니다; 네이티브 바이너리 데이터(ArrayBuffer) 전송을 지원합니다.
- 단점: 아키텍처와 개발 복잡성이 높습니다; 영구 장기 연결을 유지하므로 서버 측 시스템 아키텍처, 로드 밸런싱 전략 및 하트비트 모니터링 설계에 더 엄격한 엔지니어링 요구 사항을 부과합니다.
5. 요약: 기술 선택 비교
| 차원 | 단폴링 (Polling) | 서버 전송 이벤트 (SSE) | WebSocket |
|---|---|---|---|
| 통신 방향 | 클라이언트가 능동적으로 폴링하여 가져옴 (단방향) | 서버가 지속적으로 능동적으로 푸시 (단방향) | 클라이언트와 서버가 평등한 송수신 권한 보유 (양방향 풀듀플렉스) |
| 하위 프로토콜 | 표준 HTTP | 표준 HTTP | 독립적인 WebSocket 프로토콜 (TCP 기반) |
| 데이터 오버헤드 | 매우 높음 (완전한 HTTP 헤더 포함) | 낮음 | 매우 낮음 (최소한의 데이터 프레임 헤더) |
| 대표적 응용 시나리오 | 백엔드 비동기 작업 완료 상태 정기 확인 | 대규모 언어 모델 대화 단방향 스트림 출력, 뉴스 또는 시스템 알림 푸시 | 실시간 음성/영상 시그널링, 다인 온라인 대전, 협업 화이트보드 및 편집 |
실제 엔지니어링에서 개발자는 특정 비즈니스 시나리오의 실시간성 및 양방향 상호작용 빈도에 대한 요구 사항에 따라 시스템 유지 관리 복잡성과 통신 효율성 사이에서 균형을 잡고 가장 적합한 기술 스택을 선택해야 합니다.