현대의 웹 애플리케이션은 단순히 페이지를 렌더링하는 것을 넘어, 채팅, 주식 호가창, 매칭 시스템 등 ‘실시간(Real-time)’ 데이터를 처리하는 것이 핵심입니다. 과거의 투박했던 방식부터 최신 기술까지, 실시간 웹 통신의 발전 과정을 정리해 봅니다.
1. Polling (폴링): “새 메시지 왔어?” 무한 반복
가장 원초적인 방식입니다. 클라이언트가 주기적으로(예: 3초마다) 서버에 요청을 보냅니다.
- 장점: 구현이 극도로 단순하며 모든 브라우저에서 호환됩니다.
- 단점: 바뀐 데이터가 없어도 계속 질문하므로 서버와 네트워크 자원이 심각하게 낭비됩니다. 실시간성도 떨어집니다.
2. Long-Polling (롱 폴링): 대답할 때까지 끊지 않기
폴링의 단점을 개선한 방식입니다. 서버에 요청을 보내면, 서버는 새로운 데이터가 생길 때까지 응답을 보류하고 기다립니다. 데이터가 생기면 응답을 보내고, 클라이언트는 받자마자 다시 요청을 걸어 기다립니다.
- 장점: 쓸데없는 요청 횟수가 줄어들고 즉각적인 응답을 받을 수 있습니다.
- 단점: 다수의 클라이언트가 연결을 계속 물고 있기 때문에 서버의 커넥션 유지 비용이 높습니다.
3. SSE (Server-Sent Events): 서버에서 밀어주기 (단방향)
HTML5에서 표준화된 기술로, 한 번 연결을 맺어두면 서버가 클라이언트에게 일방적으로 계속 데이터를 보낼 수 있는 기술입니다. 브라우저의 HTTP 연결을 재사용합니다.
- 장점: 웹소켓보다 가볍고 HTTP/2와 찰떡궁합입니다. 자동 재접속 기능을 브라우저가 지원합니다.
- 단점: 서버에서 클라이언트로의 일방향 통신만 가능합니다.
- 사용 사례: 알림 시스템, 주식 피드, VoiceLink의 실시간 매칭 성공 푸시 알림!
4. WebSocket (웹소켓): 진정한 양방향 고속도로
HTTP라는 기존의 룰을 깨고, 아예 새로운 통신 프로토콜(ws://)을 사용해 서버와 클라이언트 간에 양방향으로 언제든 데이터를 주고받을 수 있는 파이프를 뚫습니다.
- 장점: 매우 빠르고 실시간 양방향 통신에 완벽히 최적화되어 있습니다.
- 단점: HTTP가 아니기 때문에 방화벽, 프록시, 로드밸런서 설정이 까다로우며, 연결이 끊어졌을 때의 예외 처리를 직접 다 구현해야 합니다.
- 사용 사례: 실시간 채팅방, 멀티플레이어 게임.
5. WebRTC: 서버를 거치지 않는 브라우저 간의 만남
데이터가 서버를 거쳐가는 웹소켓과 달리, 브라우저와 브라우저가 직접 P2P로 연결되는 기술입니다. 음성, 영상과 같은 대용량 미디어 데이터를 극단적으로 짧은 지연시간(Ultra Low Latency)으로 전송하기 위해 탄생했습니다.
- 장점: 서버의 트래픽 비용이 파격적으로 줄어들고 속도가 압도적으로 빠릅니다.
- 단점: NAT 방화벽 우회를 위한 STUN/TURN 서버 구축 등 인프라 설정이 매우 복잡합니다.
- 사용 사례: 화상 회의, 실시간 라이브 스트리밍, VoiceLink의 핵심 통화 엔진!
각 기술은 상하 관계가 아니라 상황에 맞는 도구입니다. VoiceLink 프로젝트에서도 알림 푸시에는 가벼운 SSE를, 실제 미디어 통신에는 WebRTC를 적재적소에 배치하여 최적의 아키텍처를 구현했습니다.