Short Polling: 개념, 작동 방식 및 사용 사례

Short Polling이란

Short Polling은 클라이언트가 미리 정의된 간격으로 서버에 주기적으로 HTTP 요청을 전송하고, 서버가 각 요청을 동기식으로 처리하여 즉시 결과를 반환하는 통신 패턴입니다. 폴링 간격은 클라이언트 측에서 타이머를 사용하여 설정되며, 데이터 신선도 요구사항에 따라 일반적으로 1~60초 범위입니다.

Short Polling은 역사적으로 웹 애플리케이션에서 실시간 통신을 구성하는 첫 번째 메커니즘이었습니다. 2000년대 초, 2세대 XMLHttpRequest 이전에는 웹 페이지가 <meta http-equiv="refresh"> 또는 주기적인 iframe 리로드를 사용하여 콘텐츠를 업데이트했습니다. 2005년 AJAX(Asynchronous JavaScript and XML) 기술의 등장으로 Short Polling은 전체 페이지를 다시 로드하지 않고 데이터를 업데이트하는 표준 접근 방식이 되었습니다.

Short Polling 아키텍처

Short Polling 아키텍처는 클라이언트 타이머, HTTP 요청, 서버 핸들러의 세 가지 구성 요소로 이루어집니다. 클라이언트가 간격 타이머를 시작하고, 타이머가 작동할 때마다 서버로 GET 요청이 전송됩니다. 서버는 데이터베이스나 다른 소스를 쿼리하여 응답을 생성하고 즉시 클라이언트에 반환합니다. 클라이언트는 인터페이스를 업데이트하고 다음 타이머 작동을 기다립니다. 이 주기는 애플리케이션이 활성 상태인 동안 무한히 반복됩니다.

중복 요청 문제

Short Polling의 주요 문제는 불가피한 빈 요청입니다. 데이터가 드물게 변경되는 경우 대부분의 요청이 "변경 없음" 결과를 반환하여 네트워크 대역폭과 CPU 처리 시간을 낭비합니다. 폴링 간격 5초에 10,000명의 클라이언트가 있는 경우, 서버는 초당 2,000개의 요청을 수신하며, 업데이트 빈도가 분당 1회인 경우 상당 부분이 쓸모없습니다.

Short Polling 작동 방식

Short Polling은 간단한 주기로 작동합니다: 클라이언트가 특정 주기(예: 5000ms)로 간격 타이머를 설정합니다. 각 타이머 작동 시 클라이언트는 서버 엔드포인트에 HTTP GET 요청을 생성하며, 일반적으로 마지막 업데이트의 타임스탬프 매개변수를 포함합니다. 서버는 요청을 수신하고 지정된 타임스탬프 이후의 새 데이터를 확인하여 새 데이터가 있으면 해당 데이터를, 없으면 업데이트가 없음을 나타내는 응답을 반환합니다.

Short Polling 설정의 중요한 매개변수는 폴링 간격입니다. 간격이 너무 짧으면(3초 미만) 서버와 네트워크에 높은 부하가 발생합니다. 너무 길면(30초 초과) 데이터 신선도가 저하됩니다. 최적의 간격은 시나리오에 따라 다릅니다: 모니터링 대시보드의 경우 5~15초, 뉴스 피드의 경우 30~60초, 중요 알림의 경우 1~3초입니다. 간격 선택은 항상 데이터 신선도와 인프라 부하 간의 균형입니다.

적응형 폴링 간격

유휴 시간 동안 부하를 줄이기 위해 적응형 간격이 사용됩니다: 여러 번의 연속 요청이 빈 결과를 반환하면 간격이 증가합니다(예: 5초에서 15초). 새 데이터가 나타나면 간격이 최소값으로 재설정됩니다. 지수 백오프 알고리즘은 드문 업데이트 시 빈 요청 수를 3~5배 줄일 수 있습니다.

JavaScript Short Polling 구현 예제

setInterval과 Fetch API를 사용한 클라이언트 측 Short Polling 구현을 살펴보겠습니다. 이 함수는 엔드포인트 URL과 밀리초 단위의 폴링 간격을 인수로 받습니다.

function startPolling(url, intervalMs) {
    const lastTimestamp = new Date().toISOString();

    const timerId = setInterval(async () => {
        try {
            const params = new URLSearchParams({
                since: lastTimestamp
            });
            const response = await fetch(url + "?" + params);
            const data = await response.json();

            if (data.updates && data.updates.length > 0) {
                renderUpdates(data.updates);
                console.log("수신됨", data.updates.length, "updates");
            }
        } catch (error) {
            console.error("폴링 실패:", error);
        }
    }, intervalMs);

    return timerId;
}

const timer = startPolling("/api/updates", 5000);
// clearInterval(timer) 중지용

코드는 5초 간격의 폴링을 생성하고 마지막 업데이트의 타임스탬프를 서버에 전달합니다. 서버는 이 매개변수를 사용하여 데이터를 필터링하고 새 레코드만 반환하여 전송되는 정보량을 줄일 수 있습니다. 함수는 폴링을 중지할 수 있도록 타이머 식별자를 반환합니다.

Short Polling 서버 측

Short Polling의 서버 측 구현은 매우 간단합니다. GET 요청을 받아 현재 상태나 지정된 타임스탬프 이후 변경된 데이터가 포함된 JSON 응답을 반환하는 일반적인 REST 엔드포인트입니다.

const express = require("express");
const app = express();

let items = [];

app.get("/api/updates", (req, res) => {
    const since = req.query.since;
    const filtered = items.filter(item => item.timestamp > since);
    res.json({ updates: filtered });
});

app.listen(3000);

서버는 since 매개변수를 받아 타임스탬프가 지정된 값을 초과하는 레코드를 필터링합니다. 이 접근 방식은 각 응답의 데이터 양을 최소화하여 증분 변경만 반환합니다. 새 데이터가 없으면 서버는 빈 배열을 반환하고 클라이언트는 예약된 일정에 따라 폴링을 계속합니다.

Short Polling vs Long Polling

Short Polling과 Long Polling은 동일한 문제(서버에서 클라이언트로 데이터 전달)를 해결하지만 효율성에서 근본적으로 다릅니다. Short Polling은 고정된 요청 간격을 사용하여 예측 가능한 부하를 생성하는 반면, Long Polling은 이벤트가 발생할 때까지 연결을 열린 상태로 유지하여 빈 응답 수를 최소화합니다.

기술 선택은 데이터의 업데이트 빈도에 따라 달라집니다. 이벤트가 10초에 한 번 이상 발생하는 경우 두 접근 방식 모두 비슷한 부하를 발생시키며 Short Polling이 더 간단할 수 있습니다. 이벤트가 드문 경우(변경 간격이 몇 시간 또는 몇 분), Long Polling이 빈 요청을 생성하지 않으므로 선호됩니다. 중간 시나리오의 경우 선택은 인프라 제약 조건과 WebSocket 사용 가능 여부에 따라 달라집니다.

Short Polling 적용 사례

Short Polling은 데이터 신선도 요구사항이 낮고 효율성보다 구현 단순성이 우선시되는 시나리오에서 사용됩니다. 가장 일반적인 경우는 내부 관리 패널, 낮은 알림 빈도의 모니터링 시스템, 15~30초 지연이 허용되는 애플리케이션입니다.

• 모니터링 대시보드 — 10~30초마다 업데이트되는 메트릭 대시보드로, 변경에 즉각적인 대응이 필요하지 않습니다.
• 상태 페이지 — 서비스 가용성 확인 페이지로, 데이터가 30~60초마다 업데이트되며 지연이 중요하지 않습니다.
• 분석 보고서 — 정기적인 데이터 수집이 있는 내부 분석 시스템으로, 최대 1분의 신선도가 허용됩니다.
• 간단한 게임 — 실시간 요구사항이 없는 턴제 멀티플레이어 게임으로, 몇 초마다 턴이 업데이트됩니다.
• 테스트 — 부하 테스트 및 디버깅 시나리오에서 Short Polling이 다른 기술과 비교하기 위한 참조 폴링 방식으로 사용됩니다.

중요한 제한 — Short Polling은 1초의 지연도 허용되지 않는 시간 중요 애플리케이션(트레이딩 터미널, 긴급 경보 시스템)에는 적합하지 않습니다. 이러한 시나리오에서는 WebSocket, Server-Sent Events 또는 Long Polling을 사용해야 합니다. Short Polling으로 시스템을 설계할 때는 요청 예산을 계산해야 합니다: 5초 간격으로 1,000명의 클라이언트가 있는 경우, 서버는 분당 12,000개의 요청을 처리하며, 이에 상응하는 리소스 기반이 필요합니다.