Polling이란? Short Polling·Long Polling 차이와 WebSocket 전환 기준

Polling이란? Short Polling·Long Polling 차이와 WebSocket 전환 기준#

1장 Polling은 왜 필요한가#

관제 화면에서 다음 정보를 실시간에 가깝게 표시해야 한다고 생각해보겠습니다.

Gate 상태

차량 감지 여부

주차 가능 면수

장비 Online·Offline 상태

결제 상태

문제는 Server가 새로운 상태를 가지고 있다고 해서 Browser나 Client 화면이 자동으로 그것을 알 수 있는 것은 아니라는 점입니다.

가장 단순한 해결 방법은 Client가 계속 묻는 것입니다.

Client
→ 지금 상태가 뭐야?

Server
→ CLOSED

잠시 후

Client
→ 지금은?

Server
→ CLOSED

잠시 후

Client
→ 지금은?

Server
→ OPEN

이것이 Polling의 기본 개념입니다.

즉 Client가 일정한 간격으로 Server에 Request를 보내 새로운 데이터가 있는지 확인합니다.

2장 Short Polling은 일정 주기로 계속 조회한다#

가장 일반적인 Polling 방식은 Short Polling입니다.

예를 들어 관제 화면이 1초마다 다음 API를 호출한다고 하겠습니다.

GET /api/gates/gate-01/status

Server Response:

{
  "gateId": "gate-01",
  "status": "closed"
}

1초 후 다시 요청합니다.

GET /api/gates/gate-01/status

이런 동작이 반복됩니다.

Client        Server

  │ GET         │
  ├────────────>│
  │ 200 CLOSED  │
  │<────────────┤
  │             │
  │ 1초 대기    │
  │             │
  │ GET         │
  ├────────────>│
  │ 200 CLOSED  │
  │<────────────┤
  │             │
  │ 1초 대기    │
  │             │
  │ GET         │
  ├────────────>│
  │ 200 OPEN    │
  │<────────────┤

구현이 매우 단순하다는 것이 가장 큰 장점입니다.

Polling 주기가 곧 최대 지연에 영향을 준다#

Polling Interval이:

5초

라면 Event가 발생한 직후 Polling을 놓쳤을 경우 화면에 반영되기까지 거의 5초 가까이 기다릴 수도 있습니다.

개념적으로:

Polling Interval ↓
→ 화면 반영 지연 ↓
→ Request 수 ↑

Polling Interval ↑
→ Request 수 ↓
→ 화면 반영 지연 ↑

라는 Trade-off가 생깁니다.

3장 Short Polling의 가장 큰 문제는 빈 요청이다#

Gate 상태가 10분 동안 바뀌지 않았다고 하겠습니다.

그런데 Client가 1초마다 조회하면:

1분
60 Requests

10분
600 Requests

가 발생합니다.

실제 상태 변경은:

0건

이어도 Server는 600개의 요청을 처리해야 합니다.

Client가 하나일 때는 문제가 작아 보입니다.

하지만:

관제 Monitor 20대

운영자 Browser 30대

Mobile App 100대

Dashboard 10대

처럼 Client가 늘어나면 Request 수도 함께 증가합니다.

요청 수를 단순 계산해보자#

Client 500개가 1초마다 Polling한다고 가정하면:

500 Requests / second

입니다.

5초마다 Polling한다면 평균적으로:

100 Requests / second

정도가 됩니다.

하지만 실제 Server 부하는 Request 개수만으로 결정되지 않습니다.

각 Request마다:

Authentication

Database Query

Cache Lookup

Business Logic

JSON Serialization

Access Log

가 실행될 수 있기 때문입니다.

4장 Polling이 느린 이유가 Network만은 아니다#

관제 화면 갱신이 늦다고 하겠습니다.

바로 Network 문제라고 판단하면 안 됩니다.

전체 흐름은 다음과 같습니다.

Browser
↓
HTTP Request
↓
Proxy
↓
API Server
↓
Database
↓
Response
↓
Browser
↓
화면 Rendering

어느 지점에서든 지연이 발생할 수 있습니다.

예를 들어:

Network
20ms

API Logic
30ms

Database Query
800ms

라면 가장 큰 문제는 Network가 아니라 Database입니다.

따라서 Polling 장애를 분석할 때는 전체 Latency를 분해해야 합니다.

5장 Long Polling은 Server가 바로 응답하지 않는다#

Long Polling은 Short Polling과 동작 방식이 다릅니다.

Client:

GET /api/events/longpoll

Request를 보냅니다.

Server에 새로운 Event가 없다면 바로 Response를 반환하지 않습니다.

Client                  Server

  │ GET Long Poll         │
  ├──────────────────────>│
  │                       │
  │       기다림          │
  │                       │
  │       Event 발생      │
  │                       │
  │ Event Response        │
  │<──────────────────────┤

Event가 발생하면 Server가 Response를 반환합니다.

Client는 Response를 받은 뒤 다시 새로운 Long Polling Request를 시작합니다.

Response
↓
Event 처리
↓
새 Long Poll Request
↓
대기

이 과정을 반복합니다.

6장 Long Polling은 왜 Short Polling보다 효율적일 수 있을까#

Short Polling:

새 Event 없음
→ 그래도 Request

새 Event 없음
→ 그래도 Request

새 Event 없음
→ 그래도 Request

Long Polling:

Request
↓
기다림
↓
Event 발생
↓
Response

이기 때문에 Event가 드문 시스템에서는 불필요한 Response를 상당히 줄일 수 있습니다.

예를 들어 Gate 상태가 하루에 몇 번밖에 변경되지 않는다면 1초마다 상태를 조회할 필요는 없습니다.

하지만 Long Polling에도 비용이 있습니다.

7장 Long Polling에서는 열린 Connection을 관리해야 한다#

Client가 5,000개라면 최대 수천 개의 Long Poll Connection이 동시에 열릴 수 있습니다.

Server나 Infrastructure에서는 다음을 고려해야 합니다.

Open Socket 수

Memory

File Descriptor

Connection Pool

Proxy Connection Limit

Load Balancer

Timeout

현대의 비동기 Server는 많은 Connection을 효율적으로 처리할 수 있지만, Application 구조와 Infrastructure 설정이 이를 지원해야 합니다.

특히 오래된 Thread-per-Connection 구조나 제한된 Embedded System에서는 부담이 커질 수 있습니다.

Thread 수와 Connection 수를 항상 같은 것으로 보면 안 된다#

Long Polling Connection 하나가 반드시 OS Thread 하나를 계속 점유해야 하는 것은 아닙니다.

비동기 I/O 기반 Server에서는 많은 Socket을 적은 Thread로 처리할 수도 있습니다.

따라서:

Long Polling
=
Connection 하나당 Thread 하나

라고 일반화해서는 안 됩니다.

Server Framework와 I/O Model을 함께 확인해야 합니다.

8장 Timeout은 Long Polling에서 필수다#

Server가 영원히 Connection을 유지해서는 안 됩니다.

예를 들어 Server에서:

Long Poll Timeout
30초

를 설정할 수 있습니다.

30초 동안 Event가 없다면:

204 No Content

또는 API가 정의한 Response를 보내 Connection을 종료합니다.

Client는 다시 Long Poll Request를 시작합니다.

Request
↓
30초 대기
↓
Event 없음
↓
Timeout Response
↓
새 Request

이런 구조를 사용하면 Connection이 무한정 남아 있는 것을 방지할 수 있습니다.

9장 Proxy와 Load Balancer Timeout도 맞춰야 한다#

Application Server가:

Long Poll Timeout
60초

를 사용한다고 하겠습니다.

그런데 Reverse Proxy가:

Idle Timeout
30초

라면 어떻게 될까요?

Application은 60초까지 기다리려고 하지만 Proxy가 30초에 Connection을 종료할 수 있습니다.

구조:

Client
↓
Load Balancer
↓
Reverse Proxy
↓
API Server

각 계층의 Timeout을 확인해야 합니다.

주요 항목은 다음과 같습니다.

Client Timeout

Reverse Proxy Timeout

Load Balancer Idle Timeout

Firewall Session Timeout

Application Timeout

입니다.

10장 Polling에서 가장 위험한 순간은 장애 복구 직후다#

Server가 잠시 장애를 일으켰다고 하겠습니다.

Client 10,000개가 동시에 실패했습니다.

모든 Client가 정확히 1초 뒤 다시 접속하면:

10,000 Requests
↓
Server

가 순간적으로 들어옵니다.

Server가 복구되는 순간 다시 과부하가 발생할 수 있습니다.

이를 Thundering Herd 형태의 문제로 볼 수 있습니다.

Retry에는 Backoff가 필요하다#

단순한 Retry:

실패
↓
1초 후 Retry
↓
실패
↓
1초 후 Retry

보다:

1초
↓
2초
↓
4초
↓
8초

처럼 간격을 늘리는 Exponential Backoff를 사용할 수 있습니다.

그리고 많은 Client가 완전히 같은 시점에 재시도하지 않도록 Jitter를 추가하기도 합니다.

약 1초

약 2초

약 4초

처럼 약간의 무작위 지연을 추가하는 방식입니다.

11장 주차관제 시스템에서는 어떤 방식이 좋을까#

모든 데이터를 같은 방식으로 전달할 필요는 없습니다.

주차 가능 면수#

몇 초 정도 지연되어도 된다면:

Short Polling

으로도 충분할 수 있습니다.

Gate 장애 Alarm#

즉각적인 알림이 중요하다면:

Long Polling

SSE

WebSocket

같은 방식을 고려할 수 있습니다.

차량 입출차 Event#

이런 Event는 오히려 Device가 Server로 직접:

POST /events

하는 구조가 더 적절할 수도 있습니다.

즉 Polling은 모든 실시간 데이터를 해결하는 기술이 아닙니다.

Data가 어느 방향으로 흐르는지도 함께 봐야 합니다.

12장 장비 → Server와 Server → 화면을 구분하자#

산업 시스템에서 자주 혼동하는 부분입니다.

차량 Sensor에서 Event가 발생합니다.

Sensor
↓
Gateway
↓
Server

이 방향에서는 Device가:

POST /api/events

로 Event를 전송할 수 있습니다.

그다음:

Server
↓
관제 Browser

방향에서는 Polling이나 WebSocket 같은 방식이 필요할 수 있습니다.

전체 구조는:

Sensor
↓
Gateway
↓
POST Event
↓
Server
↓
Database
↓
Polling / SSE / WebSocket
↓
관제 화면

이 됩니다.

따라서:

센서가 Polling한다.

와:

관제 화면이 Polling한다.

은 전혀 다른 설계 문제일 수 있습니다.

13장 Short Polling과 Long Polling을 비교해보자#

항목 Short Polling Long Polling
요청 방식 일정 주기 반복 Request 후 Event까지 대기
구현 난이도 낮음 중간
Event 없는 경우 빈 요청 계속 발생 Connection 유지
실시간성 Polling 주기에 영향 상대적으로 좋음
서버 부담 Request 처리량 증가 Connection 관리 증가
Proxy 설정 비교적 단순 Timeout 확인 필요
오래된 Client 대응 쉬움 지원 여부 확인 필요
장애 복구 Retry 폭주 가능 재연결 폭주 가능

어느 하나가 항상 더 좋은 것은 아닙니다.

시스템 특성에 따라 선택해야 합니다.

14장 WebSocket은 무엇이 다른가#

Long Polling도 결국:

HTTP Request
↓
HTTP Response
↓
다시 HTTP Request

구조를 반복합니다.

WebSocket은 연결을 만든 뒤 하나의 Connection을 지속적으로 유지하면서 양방향 Message를 주고받습니다.

개념적으로:

Client              Server

   │                   │
   │ WebSocket 연결    │
   ├──────────────────>│
   │                   │
   │<──── Message ─────│
   │                   │
   │──── Message ─────>│
   │                   │
   │<──── Message ─────│

그래서:

관제 Dashboard

Chat

실시간 Monitoring

Device 상태 Push

양방향 Control

처럼 자주 Message가 오가는 환경에서 유용할 수 있습니다.

WebSocket이 무조건 Polling보다 좋은 것은 아니다#

Client가 하루에 몇 번 상태를 확인하는 시스템이라면 WebSocket Connection을 계속 유지할 필요가 없을 수도 있습니다.

또 WebSocket을 도입하면:

Connection 관리

Reconnect

Authentication

Heartbeat

Message Ordering

Scale-out

Load Balancer

Connection 상태 Monitoring

같은 문제가 추가됩니다.

따라서 단순히:

실시간
=
WebSocket

으로 결정하면 안 됩니다.

15장 Polling에서 WebSocket으로 넘어갈 기준#

다음 질문을 던져보면 좋습니다.

상태 변경이 얼마나 자주 발생하는가#

하루 몇 번
→ Polling도 충분할 수 있음

초당 여러 번
→ Push 방식 검토

어느 정도 지연을 허용할 수 있는가#

5초 허용
→ Polling 가능

수백 ms 수준 요구
→ WebSocket 등 검토

Server에서 Client로 먼저 알려줘야 하는가#

Yes
→ Long Polling / SSE / WebSocket 고려

Client도 Server에 자주 Message를 보내는가#

양방향 Message 빈도 높음
→ WebSocket에 유리

운영 환경이 지속 Connection을 지원하는가#

Proxy

Firewall

Load Balancer

Client Firmware

까지 확인해야 합니다.

16장 Polling을 사용한다고 Database를 매번 조회할 필요는 없다#

Polling 부하가 심하다고 바로 Polling 자체를 버릴 필요는 없습니다.

다음 구조:

Client
↓
GET /status
↓
API Server
↓
Database Query

에서 매 요청마다 Database를 조회하면 DB 병목이 발생할 수 있습니다.

대신:

Client
↓
API Server
↓
Cache

를 활용할 수도 있습니다.

예:

Redis

Memory Cache

Materialized Status

등입니다.

즉 성능 문제의 원인이 Polling이 아니라 Polling Request 하나가 너무 비싼 것일 수도 있습니다.

17장 Polling 주기를 고정하지 않는 방법도 있다#

항상 1초마다 Polling할 필요는 없습니다.

예를 들어:

화면 활성 상태
→ 1초

사용자 활동 없음
→ 5초

Browser Background
→ 30초

처럼 조정할 수 있습니다.

또 장애 발생 시:

1초
→ 2초
→ 4초
→ 8초

로 늘리는 Adaptive Polling을 사용할 수도 있습니다.

이 방식은 Server 부하를 상당히 줄일 수 있습니다.

18장 Polling API를 설계할 때 전체 데이터를 매번 보내지 않아도 된다#

Client가 매번 전체 Gate 목록을 받는다고 하겠습니다.

{
  "gates": [
    "...수백 개..."
  ]
}

상태 하나만 바뀌어도 전체 데이터를 다시 전송하면 비효율적입니다.

대신:

lastUpdated

version

cursor

since

같은 값을 활용할 수 있습니다.

예:

GET /api/events?since=2026-09-24T10:30:00Z

처럼 마지막 확인 이후 변경된 Event만 요청하는 방식입니다.

또는:

GET /api/events?cursor=abc123

처럼 Cursor 기반 API를 설계할 수도 있습니다.

19장 중복 Event도 고려해야 한다#

Long Polling Response를 Client가 받았지만 Network가 바로 끊겼다고 하겠습니다.

Client가 다시 연결하면서 같은 Event를 받을 수도 있습니다.

따라서 Event에는:

{
  "eventId": "evt-10001"
}

같은 고유 ID를 두는 것이 좋습니다.

Client 또는 Server는:

eventId 확인
↓
이미 처리했는가?
↓
Yes
→ 중복 처리 방지

할 수 있습니다.

Polling 방식에서도 Exactly Once를 당연하게 가정하면 안 됩니다.

20장 Polling 장애는 계층별로 진단한다#

Request 자체가 안 나간다#

확인:

Client Timer

JavaScript Error

Application 상태

Request는 나가지만 Connection이 안 된다#

확인:

DNS

Routing

Firewall

TCP Port

HTTP Response가 느리다#

확인:

Proxy

API Server

Database

External API

Long Poll이 자꾸 30초마다 끊긴다#

확인:

Proxy Idle Timeout

Load Balancer Timeout

Application Timeout

장애 후 Request가 폭증한다#

확인:

Retry Interval

Backoff

Jitter

Rate Limit

이렇게 계층별로 보면 단순히 Polling이 느리다는 문제를 더 구체적으로 분석할 수 있습니다.

21장 현장 판단 체크리스트#

□ Polling이 필요한 데이터인가?

□ Device → Server인가, Server → Client인가?

□ Polling Interval은 얼마인가?

□ 허용 가능한 화면 지연은 얼마인가?

□ Client 수는 몇 개인가?

□ 초당 Request 수를 계산했는가?

□ Request마다 DB Query가 발생하는가?

□ Cache를 사용할 수 있는가?

□ 변경된 데이터만 받을 수 있는가?

□ Timeout을 정의했는가?

□ Retry 횟수를 제한했는가?

□ Exponential Backoff를 사용하는가?

□ Jitter를 고려했는가?

□ Long Poll Timeout을 정의했는가?

□ Proxy·Load Balancer Timeout을 확인했는가?

□ Event ID가 있는가?

□ 중복 Event를 처리할 수 있는가?

□ HTTPS를 사용하는가?

□ Connection 수를 Monitoring하는가?

□ WebSocket이 정말 필요한가?

22장 자기 점검#

Short Polling과 Long Polling의 가장 큰 차이는 무엇인가#

Short Polling은 Client가 일정한 주기로 Request를 보내고 Server가 즉시 Response를 반환합니다. Long Polling은 Event가 발생하거나 Timeout이 될 때까지 Server가 Response를 지연시킵니다.

Polling Interval을 짧게 하면 무엇이 좋아지고 무엇이 나빠지는가#

상태 변화 감지 지연은 줄어들지만 Request 수와 Server·Network 부하는 증가할 수 있습니다.

Long Polling은 Request가 적으니 비용이 없는가#

아닙니다. 열린 Connection을 유지해야 하므로 Socket, Memory, Proxy와 Load Balancer 설정 등을 고려해야 합니다.

장애 발생 후 모든 Client가 즉시 Retry하면 어떤 문제가 생길 수 있는가#

복구 순간 Request가 집중되어 다시 Server를 과부하시킬 수 있습니다. Backoff와 Jitter를 적용할 수 있습니다.

언제 WebSocket을 고려할 수 있는가#

낮은 지연이 필요하고 Server Push 또는 지속적인 양방향 Message 교환이 많으며 Infrastructure가 지속 Connection을 안정적으로 지원할 때 고려할 수 있습니다.

23장 이 글을 마치며#

Polling은 오래되고 단순한 방식이지만 여전히 매우 유용합니다.

Short Polling의 구조는:

Request
↓
Response
↓
대기
↓
Request

이고 Long Polling은:

Request
↓
Server 대기
↓
Event 발생
↓
Response
↓
새 Request

입니다.

WebSocket은:

Connection
↓
지속 유지
↓
Client ↔ Server Message

라는 차이가 있습니다.

중요한 것은 어떤 기술이 더 최신인지가 아닙니다.

데이터가 얼마나 자주 변하는지, 어느 정도의 지연을 허용할 수 있는지, Client가 몇 개인지, Server Push가 필요한지, 지속 Connection을 운영할 수 있는지를 기준으로 선택해야 합니다.

특히 다음 다섯 가지를 기억하면 됩니다.

Short Polling은 구현이 단순하지만 Polling Interval이 짧아질수록 불필요한 Request가 증가할 수 있습니다.

Long Polling은 Event가 없을 때 불필요한 Response를 줄일 수 있지만 많은 Connection을 안정적으로 유지해야 합니다.

Polling 성능 문제는 방식 자체보다 Database Query·Authentication·Logging처럼 Request 한 건의 처리 비용에서 발생할 수도 있습니다.

Timeout과 Retry를 잘못 설계하면 장애 복구 순간 대규모 재접속과 Request 폭주가 발생할 수 있으므로 Backoff와 Jitter가 중요합니다.

WebSocket은 Polling의 무조건적인 상위 기술이 아니라 지속적인 Server Push와 양방향 통신이 필요한 경우 선택할 수 있는 또 다른 통신 방식입니다.

결국 Polling을 이해한다는 것은 단순히 몇 초마다 API를 호출한다는 개념을 아는 것이 아닙니다.

Client 수, Polling 주기, 요청 처리 비용, 연결 유지 비용, 장애 복구와 데이터 최신성 사이의 균형을 계산해 시스템에 맞는 통신 패턴을 선택하는 것이 핵심입니다.

이 페이지의 목차