롱 폴링 (long polling)

클라이언트가 요청을 보내면 서버가 응답을 곧바로 주지 않고 붙잡고 있다가, 알릴 일이 생기는 순간에 응답하는 방식.

먼저 — 그냥 폴링의 문제

클라이언트: "새 소식 있어?"  →  서버: "없어"      (3초 후)
클라이언트: "새 소식 있어?"  →  서버: "없어"      (3초 후)
클라이언트: "새 소식 있어?"  →  서버: "있어!"

요청 대부분이 헛걸음이고, 소식이 생겨도 다음 주기까지 기다려야 알게 된다. 여기서 근본적인 딜레마가 나온다.

주기를 3초로 줄이면  → 지연 ↓  트래픽 ↑
주기를 30초로 늘리면 → 트래픽 ↓  지연 ↑ (최대 30초 늦게 안다)

둘 다 좋게 만들 방법이 없다

트래픽과 지연을 맞바꿀 수밖에 없다는 것이 폴링의 한계다.

롱 폴링의 해법 — 응답을 미룬다

클라이언트: "새 소식 있어?"  →  서버: (응답을 안 준다. 붙잡고 대기)
                                       ...30초 후 사건 발생...
                             ←  서버: "있어!"
클라이언트: (받자마자) "새 소식 있어?"  →  다시 대기

헛걸음이 사라지고 지연도 거의 0이 된다. 사건이 없으면 서버가 일정 시간(예: 30초) 뒤 빈 응답을 주고, 클라이언트가 다시 건다 — 프록시·로드밸런서의 타임아웃에 걸리지 않기 위해서다.

남는 비용

이벤트 하나마다 요청-응답이 한 번씩 끝난다. 사건이 잦으면 연결을 다시 세우는 비용(헤더 전송 포함)이 계속 든다. 그리고 서버 쪽에서는 응답하지 않은 요청이 계속 쌓인다 — 요청마다 스레드를 붙잡는 전통적 서버 모델에서는 이것만으로 스레드가 마른다.

이 두 가지를 각각 해결한 것이 다음 단계다 — SSE는 응답을 끝내지 않아 재수립 비용을 없앴고, WebSocket은 프로토콜 자체를 바꿔 양방향까지 열었다.

지금도 쓰나

SSE·WebSocket을 못 쓰는 환경의 폴백으로 여전히 살아 있다. 오래된 브라우저, WebSocket을 막는 기업 프록시 같은 경우다. 실시간 라이브러리들이 "WebSocket 시도 → 실패하면 롱 폴링" 식의 단계적 폴백을 갖는 이유가 이것이다.

면접 포인트

"폴링 대비 장점이 뭔가요?"라는 질문에 트래픽과 지연의 맞바꿈이 사라진다고 답하고, 이어서 "그래도 이벤트마다 연결이 끝나는 비용은 남아서 SSE·WebSocket으로 갔다" 까지 말하면 계보를 이해했다는 신호가 된다.

면접 함정

❌ "롱 폴링은 그냥 폴링을 느리게 하는 것" → 주기가 아니라 응답 시점을 바꾼 것이다.

서버 쪽 모양

// 요청을 붙잡아 두고, 사건이 생기면 그때 응답한다
@GetMapping("/events")
public DeferredResult<Event> poll(@RequestParam long since) {
    var result = new DeferredResult<Event>(30_000L);   // 30초 뒤 타임아웃
    result.onTimeout(() -> result.setResult(Event.empty()));  // 빈 응답으로 종료
    eventBus.register(since, result::setResult);              // 사건 발생 시 응답
    return result;
}

타임아웃을 두는 이유가 중요하다 — 프록시·로드밸런서가 응답 없는 연결을 먼저 끊어 버리기 때문에, 그보다 짧은 주기로 스스로 빈 응답을 주고 클라이언트가 다시 걸게 한다.

서버 자원 문제

요청마다 스레드를 붙잡는 모델에서

동시 접속 10,000 → 응답 대기 중인 스레드 10,000개 → 스레드 고갈

그래서 비동기 응답(DeferredResult 등)이나 가상 스레드가 없으면 롱 폴링은 규모를 못 키운다

이 제약이 SSE·WebSocket으로 넘어간 기술적 동기 중 하나였다.