[HTTP] Long Polling과 Short Polling의 차이

Polling이라는 단어는 예전부터 자주 봤지만, 막상 누군가가 “short polling이랑 long polling은 뭐가 달라?”라고 물으면 한 번에 깔끔하게 답하기가 쉽지 않았습니다.
저도 오늘 이 주제를 다시 공부하면서, 둘의 차이는 단순히 “요청을 많이 보내느냐 적게 보내느냐”보다 서버가 언제 응답하느냐에 더 가깝다는 생각이 들었습니다.

이번 글에서는 long polling과 short polling이 각각 어떤 방식으로 동작하는지, 그리고 어떤 상황에서 더 적합한지 정리해보려고 합니다.

Polling이란?

Polling은 클라이언트가 서버에 변경 사항이 있는지 주기적으로 확인하는 방식입니다.
즉, 서버가 먼저 알려주는 것이 아니라 클라이언트가 먼저 묻는 구조라고 볼 수 있습니다.

이 polling 방식은 크게 short polling과 long polling으로 나눌 수 있습니다.

Short Polling

Short polling은 가장 단순한 방식입니다.
클라이언트가 일정 시간 간격으로 서버에 요청을 보내고, 서버는 요청이 들어올 때마다 즉시 응답합니다.

예를 들어 5초마다 상태를 확인한다면, 흐름은 대략 이렇습니다.

1. 클라이언트가 서버에 요청을 보냅니다.
2. 서버는 현재 상태를 바로 응답합니다.
3. 클라이언트는 5초 뒤 다시 같은 요청을 보냅니다.

즉, 주기적으로 계속 물어보는 방식입니다.

장점

• 구현이 단순합니다.
• 일반적인 HTTP 요청/응답 흐름에 잘 맞습니다.
• 서버 쪽에서도 특별한 연결 관리 없이 처리하기 쉽습니다.

단점

• 변경이 없더라도 계속 요청이 발생합니다.
• polling 주기가 길면 최신 상태를 늦게 알게 됩니다.
• polling 주기를 짧게 잡으면 서버와 네트워크에 부담이 커집니다.

결국 short polling은 단순하지만, 빈 요청이 많이 생기고 지연도 polling interval에 영향을 많이 받는 방식이라고 볼 수 있습니다.

Long Polling

Long polling은 이름은 비슷하지만 응답 방식이 다릅니다.
클라이언트가 요청을 보내면 서버는 바로 응답하지 않고, 새로운 데이터가 생길 때까지 요청을 잠시 붙잡고 기다립니다.

흐름은 보통 이렇게 됩니다.

1. 클라이언트가 서버에 요청을 보냅니다.
2. 서버는 바로 응답하지 않고 대기합니다.
3. 새 데이터가 생기면 그때 응답합니다.
4. 클라이언트는 응답을 받자마자 다시 다음 요청을 보냅니다.

즉, 질문 하나를 오래 들고 있다가, 바뀌는 순간 답을 주는 방식입니다.

장점

• short polling보다 불필요한 요청이 줄어듭니다.
• 새 데이터가 생기면 비교적 빠르게 클라이언트에 전달할 수 있습니다.
• WebSocket을 쓰기 어려운 환경에서도 실시간에 가까운 경험을 만들 수 있습니다.

단점

• 서버가 열린 요청을 오래 관리해야 합니다.
• 동시 접속 수가 많아지면 서버 부담이 커질 수 있습니다.
• 타임아웃, 재시도, 프록시/로드밸런서 설정을 신경 써야 합니다.

즉, long polling은 short polling보다 실시간성은 좋아지지만, 서버가 감당해야 할 연결 관리 비용이 더 커진다고 이해하면 됩니다.

둘의 차이를 한 번에 정리하면

짧게 표현하면,

• Short polling = 주기적으로 계속 물어보기
• Long polling = 한 번 물어본 뒤, 서버가 기다렸다가 답해주기

라고 정리할 수 있습니다.

언제 어떤 방식을 쓰면 좋을까?

Short Polling이 더 어울리는 경우

• 데이터가 자주 바뀌지 않는 경우
• 약간의 지연이 허용되는 경우
• 구현을 최대한 단순하게 가져가고 싶은 경우

예를 들어 관리자 페이지에서 30초마다 작업 상태를 확인하는 정도라면, short polling만으로도 충분할 수 있습니다.

Long Polling이 더 어울리는 경우

• 변경 사항을 가능한 빨리 보여줘야 하는 경우
• WebSocket까지는 도입하지 않고 싶지만, short polling보다 빠른 반응이 필요한 경우
• 접속 규모가 아주 크지 않거나, 서버가 열린 요청을 감당할 수 있는 경우

예를 들어 간단한 채팅, 알림, 주문 상태 갱신처럼 바뀌면 바로 보여주는 경험이 중요한 경우에는 long polling이 더 적합합니다.

예시로 보면 더 쉬운 주문 상태 조회

주문 상태가 아래처럼 바뀐다고 가정해보겠습니다.

• 결제 완료
• 상품 준비 중
• 배송 시작

이 상황에서 short polling은 클라이언트가 5초마다 /orders/:id/status를 호출합니다.
만약 상태가 1초 전에 바뀌었더라도, 다음 요청이 4초 뒤라면 사용자는 그때까지 기다려야 합니다.

반면 long polling은 요청을 한 번 보내고 서버가 상태 변경 시점까지 기다렸다가 응답합니다.
상태가 바뀌자마자 서버가 응답하면, 클라이언트는 바로 다음 요청을 이어서 보냅니다.

이렇게 보면 둘의 차이는 결국 **“새로운 상태를 얼마나 빨리 전달할 수 있느냐”**와 **“그걸 위해 서버가 어느 정도 비용을 감당하느냐”**의 차이로 볼 수 있습니다.

결론

short polling과 long polling은 모두 HTTP 기반으로 상태 변화를 확인하는 방식이지만,
핵심 차이는 서버가 응답을 즉시 주느냐, 아니면 기다렸다가 주느냐에 있습니다.

제가 이번에 다시 정리하면서 느낀 건,
short polling은 단순해서 이해하기 쉽지만 실시간성이 약하고,
long polling은 더 빠르게 반응할 수 있지만 서버가 훨씬 더 많은 책임을 져야 한다는 점이었습니다.

결국 어떤 방식이 더 좋다기보다는,
데이터 변경 주기, 허용 가능한 지연, 서버 부담을 기준으로 선택하는 것이 가장 중요하다고 생각합니다.

References

• MDN - Connection management in HTTP/1.x
• Ably - What is HTTP long polling?
• PubNub - What is Long Polling?
• PubNub - Evaluating Long Polling vs WebSockets