FrontEnd

웹 실시간 통신에 대해서 알아보자

J3SUNG 2025. 4. 9. 10:51
728x90

서론

초기의 웹은 단순한 문서를 주고받는 정적인 플랫폼이었습니다. 하지만 채팅, 알림, 실시간 주식 시세, 온라인 게임과 같은 실시간 상호작용 기능이 필요해지면서 기존 HTTP 통신 방식으로는 실시간 상호작용에 한계가 있었고, 이를 보완하기 위한 다양한 통신 기술이 등장하게 되었습니다.

이 글에서는 HTTP의 구조적 한계를 짚어보고, 그에 대한 대안으로 등장한 다양한 통신 기술들을 정리해보려 합니다. 각각의 기술이 어떻게 발전해 왔는지, 어떤 상황에 적합한지 확인해보겠습니다.

실시간 통신이란?

HTTP 웹 통신 구조

웹에서 가장 기본이 되는 HTTP(HyperText Transfer Protocol)는 클라이언트가 요청을 보내고 서버가 응답을 반환하는 구조입니다. 이 요청-응답이 완료되면 연결은 종료되며, 기본적으로는 단방향 통신만 가능합니다. 즉, 서버는 클라이언트의 요청이 있을 때만 응답할 수 있고, 자발적으로 데이터를 전달할 수는 없습니다.

정적인 콘텐츠 제공에는 효과적이지만, 실시간 데이터 처리가 필요한 환경에서는 구조적인 제약이 많습니다.  이러한 한계를 해결하기 위해 등장한 것이 양방향 통신 기술입니다.

양방향 통신

양방향 통신은 클라이언트와 서버가 서로 독립적으로 데이터를 주고받을 수 있는 통신 구조입니다. 사용자의 요청이 없어도 서버가 실시간으로 데이터를 클라이언트에 전송할 수 있어야 하며, 연결이 끊기지 않고 지속적으로 유지되는 것이 핵심입니다.

양방향 통신은 사용자와 서버 간 상호작용을 빠르고 자연스럽게 만들어주며, 특히 실시간성이 중요한 서비스에서는 필수적인 요소입니다.

실시간 통신 기술의 분류

HTTP 기반 통신 방식: 기존 HTTP 프로토콜을 활용하거나 구조를 일부 변형하여 실시간 통신을 구현합니다. 

  • Polling: 클라이언트가 일정 주기로 서버에 요청을 보내는 방식
  • Long Polling: 요청을 보내고 응답이 있을 때까지 연결을 유지하는 방식
  • SSE (Server-Sent Events): 서버에서 클라이언트로 단방향 스트리밍하는 방식

비HTTP 기반 통신 방식: HTTP를 벗어나 별도의 프로토콜 또는 브라우저 간 직접 연결을 통해 실질적인 양방향 실시간 통신을 구현합니다.

  • WebSocket: 전이중(Full-duplex) 통신이 가능한 TCP 기반 연결 방식
  • WebRTC: 브라우저 간 직접 연결을 통해 실시간으로 미디어 및 데이터를 주고받는 기술

실시간 통신 기술

Polling

설명

클라이언트가 일정 주기로 서버에 요청을 보내 서버에 새로운 데이터가 있는지를 확인하는 방식입니다. 서버는 클라이언트가 보낸 요청에 대해 즉각적으로 응답하며, 새로운 데이터가 없어도 요청-응답 사이클은 계속해서 반복됩니다. 구조는 단순하지만 불필요한 요청이 반복되므로 리소스 낭비가 심할 수 있습니다.

https://junhyunny.github.io/information/spring-boot/polling-long-polling-and-spring-example/

작동 방식

setInterval(() => {
  fetch('/data').then(res => res.json()).then(console.log);
}, 5000);

장점

  • 구현이 쉽고 별도의 설정 없이 HTTP 요청만으로 동작
  • 대부분의 환경에서 적용 가능하고 디버깅이 쉬움

단점

  • 실시간성이 낮아 민감한 데이터 처리에는 부적합
  • 새로운 데이터가 없어도 요청이 반복되어 서버와 네트워크에 부하 발생
  • 요청 주기에 따라 성능 저하 또는 반응 지연 발생

Long Polling

설명

클라이언트가 서버에 요청을 보낸 후, 서버가 새로운 데이터를 준비할 때까지 연결을 유지하는 방식입니다. 데이터가 도착하면 응답이 반환되고 클라이언트는 즉시 다음 요청을 보냅니다. Polling보다 실시간성이 우수하며 HTTP 환경에서도 작동합니다.

https://junhyunny.github.io/information/spring-boot/polling-long-polling-and-spring-example/

작동 방식

function longPoll() {
  fetch('/long-poll').then(res => res.json()).then(data => {
    console.log(data);
    longPoll();
  });
}
longPoll();

장점

  • 서버의 응답 시점이 유동적이므로 실시간성 확보 가능
  • 기존 HTTP 통신을 활용해서 도입 장벽이 낮음

단점

  • 연결 유지 시간 동안 서버 리소스를 점유함
  • 연결 해제/타임아웃 등 예외 처리 복잡
  • 많은 클라이언트가 동시에 접속 시 확장성 저하 가능

Server-Sent Events (SSE)

설명

서버가 클라이언트로 데이터를 지속적으로 보내는 단방향 스트리밍 기술입니다. HTTP 기반으로 작동하며, HTML5에서 표준으로 채택되어 구현이 간단하고 가볍습니다. 반면, 서버 → 클라이언트 전용이므로 양방향 통신에는 한계가 있습니다.

https://api7.ai/ko/blog/what-is-sse

작동 방식

const eventSource = new EventSource('/events');
eventSource.onmessage = (event) => {
  console.log('새로운 메시지:', event.data);
};

장점

      • HTTP 기반이라 방화벽, 프록시와 호환성이 좋음
      • 자동 재연결, 이벤트 ID 관리 등 기본 기능이 내장됨

단점

    • 클라이언트에서 서버로의 통신은 별도 요청이 필요함
    • 바이너리 전송 불가 및 브라우저 연결 수 제한 등의 제약 존재

WebSocket

설명

WebSocket은 처음에 HTTP로 핸드셰이크를 수행한 후, 프로토콜을 업그레이드하여 단일 TCP 연결로 전이중 통신을 수행하는 기술입니다. 클라이언트와 서버가 자유롭게 데이터를 주고받을 수 있어 실시간 채팅, 게임, 알림 등과 같이 양방향 통신이 요구되는 서비스에 적합합니다.

https://velog.io/@nhs075241/WebSocket%EC%9D%B4%EB%9E%80-Network

작동 방식

const socket = new WebSocket('wss://example.com');
socket.onopen = () => socket.send('Hello');
socket.onmessage = (e) => console.log('서버로부터:', e.data);

장점

  • 양방향 통신 가능하며 지연이 거의 없음
  • 텍스트 및 바이너리 전송 지원
  • 하나의 연결로 지속적인 통신 가능, 상태 유지에 유리함

단점

  • 많은 동시 연결 처리 시 서버 리소스 부담
  • 프록시나 방화벽 환경에서 연결 제한 가능성 있음
  • 재연결, 장애 처리 등 연결 관리 로직 필요

WebRTC

설명

WebRTC는 브라우저 간 직접 연결을 통해 오디오, 비디오, 텍스트, 파일 등의 데이터를 실시간으로 주고받을 수 있는 P2P 기반 기술입니다. 고품질 미디어 전송과 낮은 지연 시간 덕분에 화상 회의, 음성 통화, 실시간 파일 전송 등에 적합합니다.

작동 방식

1. RTCPeerConnection 객체를 사용해 클라이언트 간 연결을 시도합니다.  
2. ICE 후보 정보 및 SDP(Session Description Protocol)를 시그널링 서버를 통해 교환합니다.  
3. STUN 서버를 통해 공인 IP를 확인하고, 연결이 불가능한 경우 TURN 서버를 통해 중계합니다.

장점

  • 서버를 거치지 않아 지연이 매우 낮고 대역폭 절감 가능
  • DTLS, SRTP 기반으로 보안이 강화되어 있음
  • 오디오, 비디오 등 다양한 미디어 유형 지원

단점

  • 시그널링 서버, STUN/TURN 인프라 구성 필요
  • 네트워크 환경(NAT, 방화벽 등)에 따라 품질 변동 가능
  • 디버깅 및 구현 복잡도가 높아 숙련된 개발이 필요함

상황에 따른 통신 기술 선택

기술 양방향성 실시간성 구현 난이도 확장성 사용 예시
Polling 단방향 낮음 매우 쉬움 낮음 단순 상태 확인, 간헐적 알림
Long Polling 단방향 중간 쉬움 중간 알림 시스템, 실시간 댓글 등
SSE 단방향 높음 쉬움 제한 있음 뉴스 피드, 서버 로그 모니터링
WebSocket 양방향 높음 중간 높음 채팅, 게임, 주식 시세, 협업 툴
WebRTC 양방향 매우 높음 높음 구조 설계에 따라 다름 화상회의, 음성통화, 실시간 파일 공유 등

마무리

이제는 서비스의 목적에 따라 Polling, Long Polling, SSE, WebSocket, WebRTC 등 다양한 실시간 통신 방식을 선택할 수 있게 되었습니다.

간단한 상태 확인이나 간헐적인 알림이 필요한 경우에는 Polling이나 Long Polling만으로도 충분할 수 있습니다.
실시간성과 처리 효율이 중요한 서비스라면 WebSocket이 적합하며, 고품질의 오디오·비디오 전송이 필요한 경우에는 WebRTC를 고려하는 것이 좋습니다.

기술을 선택할 때는 요구하는 실시간성 수준, 서비스의 성격, 인프라 환경, 유지보수와 확장성, 예상 사용자 수 등을 종합적으로 고려해야 합니다. 또한 필요에 따라 여러 기술을 적절히 조합하는 방식이 효율적인 해답이 될 수 있습니다.

저작자표시 (새창열림)