subiniwiki

[네트워크] 실시간 통신 기술 - 폴링(Polling), 롱폴링(Long Polling), 웹소켓(Web Socket)

subindev 2026. 4. 13. 11:08

웹 서비스를 만들다 보면 클라이언트와 서버가 데이터를 어떻게 주고받을지 고민하게 된다.

보통은 REST API 방식으로 충분하지만,

채팅이나 실시간 알림처럼 “계속 상태를 확인해야 하는 기능”이 들어가면 다른 방식이 필요해진다.

대표적으로 많이 사용하는 방식이 Polling, Long Polling, WebSocket이다.

이번 글에서는 각각 어떤 방식인지, 왜 사용하는지 정리해보려고 한다.

1. 일반적인 요청 방식 (REST API)

가장 흔하게 사용하는 방식이다.

클라이언트가 서버에 요청을 보내고, 서버가 응답을 주면 통신이 끝난다.

예를 들면:

  • 로그인
  • 게시글 조회
  • 검색
  • 회원가입

같은 기능들이 여기에 해당한다.

흐름은 단순하다.

클라이언트 → 서버 : 요청
서버 → 클라이언트 : 응답
연결 종료

한 번 요청하고 끝나는 구조라서 단발성 통신이라고 볼 수 있다.

일반적인 CRUD 기능은 대부분 이 방식만으로 충분하다.

다만 실시간으로 상태가 바뀌는 기능에는 한계가 있다.

예를 들어 채팅을 생각해보면,

상대방이 메시지를 보냈는지 계속 확인해야 하는데 REST API만으로는 이런 부분을 처리하기 어렵다.

그래서 나온 방식이 Polling이다.

2. Polling

Polling은 클라이언트가 일정 시간마다 서버에 계속 요청을 보내는 방식이다.

쉽게 말하면:

“새 데이터 생겼어?”

를 반복해서 물어보는 구조다.

예를 들어 3초마다 서버에 요청해서 새로운 알림이나 메시지가 있는지 확인할 수 있다.

동작 방식은 대략 이런 느낌이다.

클라이언트 → 서버 : 새 데이터 있음?
서버 → 클라이언트 : 없음

(3초 후)

클라이언트 → 서버 : 새 데이터 있음?
서버 → 클라이언트 : 없음

(반복)

그러다가 데이터가 생기면 서버가 응답해준다.

Polling의 단점

문제는 데이터가 없어도 요청이 계속 발생한다는 점이다.

실제로는 바뀐 게 없는데도 계속 요청을 보내기 때문에 비효율적이다.

사용자가 많아질수록:

  • 서버 부하 증가
  • 네트워크 낭비
  • 불필요한 요청 증가

같은 문제가 생길 수 있다.

특히 요청 주기를 짧게 잡을수록 서버 부담은 더 커진다.

그래서 Polling은 구현은 쉽지만 효율은 좋지 않은 편이다.

3. Long Polling

Long Polling은 Polling의 단점을 조금 개선한 방식이다.

Polling은 요청을 보내면 서버가 바로 응답했지만,

Long Polling은 서버가 바로 응답하지 않고 기다린다.

즉, 데이터가 생길 때까지 응답을 보류하는 방식이다.

흐름은 이런 식이다.

클라이언트 → 서버 : 새 데이터 있음?

(서버 대기)

데이터 생성

서버 → 클라이언트 : 데이터 응답

응답을 받은 클라이언트는 다시 요청을 보낸다.

Polling과 차이점

Polling은 계속 요청을 반복하지만,

Long Polling은 서버가 응답을 늦춘다는 차이가 있다.

그래서 불필요한 요청이 많이 줄어든다.

실시간성도 Polling보다 훨씬 좋아진다.

하지만 한계도 있다

Long Polling도 결국 HTTP 기반이다.

즉:

  • 클라이언트가 먼저 요청해야 하고
  • 서버가 먼저 데이터를 보내지는 못한다

라는 한계가 있다.

그리고 서버 입장에서는 요청을 오래 붙잡고 있어야 해서 연결 유지 비용이 발생한다.

사용자가 많아지면 서버 부담도 커질 수 있다.

 

4. WebSocket

WebSocket은 앞에서 본 방식들과 구조 자체가 조금 다르다.

기존 HTTP처럼 요청/응답으로 끝나는 게 아니라,

한 번 연결하면 계속 연결을 유지한다.

그리고 연결된 상태에서 서로 자유롭게 데이터를 주고받을 수 있다.

클라이언트 ↔ 서버 연결 유지

서버 → 클라이언트 : 데이터 전송
클라이언트 → 서버 : 데이터 전송

여기서 가장 중요한 건 서버도 먼저 데이터를 보낼 수 있다는 점이다.

이게 Polling, Long Polling과 가장 큰 차이다.

WebSocket이 많이 쓰이는 이유

실시간성이 필요한 기능에서는 거의 WebSocket을 사용한다.

예를 들면:

  • 채팅
  • 실시간 알림
  • 게임
  • 주식 시세
  • 협업 툴

같은 서비스들이다.

메시지가 생기면 서버가 바로 사용자에게 전달할 수 있기 때문에 반응 속도가 빠르다.

그리고 계속 HTTP 요청을 반복하지 않아도 되기 때문에 네트워크 낭비도 줄어든다.

단점도 있다

다만 구현 난이도는 상대적으로 높은 편이다.

연결이 끊겼을 때 재연결 처리도 해야 하고,

사용자가 많아질수록 서버가 유지해야 하는 연결 수도 많아진다.

그래서 단순한 기능인데 무조건 WebSocket을 사용하는 건 오히려 비효율적일 수도 있다.

정리

간단하게 정리하면:

  • Polling → 계속 물어보는 방식
  • Long Polling → 응답을 기다리는 방식
  • WebSocket → 연결을 유지하는 방식

정도로 볼 수 있다.

그리고 가장 큰 차이는 이것이다.

Polling / Long Polling은:

클라이언트 → 서버

반드시 클라이언트가 먼저 요청해야 한다.

반면 WebSocket은:

클라이언트 ↔ 서버

서버도 먼저 데이터를 보낼 수 있다.

그래서 진짜 실시간 통신이 필요할 때는 WebSocket을 많이 사용한다.

즉. 실시간 통신 방식은 상황에 따라 선택하는 게 중요하다.

단순 조회 기능이라면 REST API만으로 충분하고, 실시간성이 조금 필요하면 Polling이나 Long Polling,

진짜 실시간 통신이 필요하면 WebSocket을 사용하는 식이다.

무조건 최신 기술을 쓰는 것보다, 서비스에 맞는 방식을 선택하는 게 더 중요하다고 생각한다.