롱 폴링과 숏 폴링의 차이는 무엇인가요?

숏 폴링은 타이머에 맞춰 요청을 보내고, 서버는 바뀐 것이 없어도 즉시 응답합니다. 롱 폴링은 새 소식이 생기거나 타임아웃이 될 때까지 서버가 열어 두는 요청을 보내며, 클라이언트는 보통 응답을 받자마자 다시 요청합니다. 롱 폴링은 전달 지연과 낭비되는 요청을 줄이려는 방식입니다. 그 대가로 클라이언트마다 요청 하나를 열어 두어야 하고, 이 요청은 프록시 타임아웃보다 먼저 끝날 만큼 짧게 유지해야 합니다.

정의는 롱 폴링에 관한 IETF의 정보성(informational) RFC인 RFC 6202와 MDN의 WebSocket API, 서버 전송 이벤트 페이지에서 가져왔습니다. Sume의 대기 방식은 Job과 결과 (영문), 인증 문서에서 가져왔습니다. 모두 2026-09-28에 확인했습니다.

롱 폴링은 숏 폴링과 어떻게 다른가요?

숏 폴링에서는 요청할 때마다 그 시점에 있는 것을 가져옵니다. 아무것도 없으면 서버는 빈 응답을 돌려주고, 클라이언트는 잠시 기다렸다가 다시 폴링합니다. 폴링 주기는 감당할 수 있는 지연에 따라 정해지며, 허용할 수 있는 지연이 짧을수록 요청이 많아집니다. 롱 폴링에서는 이벤트, 상태 변경, 타임아웃 중 하나가 일어날 때만 서버가 응답합니다. 클라이언트는 보통 곧바로 새 롱 폴링 요청을 보내므로, 서버는 거의 항상 요청 하나를 열어 두고 있습니다.

롱 폴링의 단점은 무엇인가요?

RFC 6202는 다음과 같은 비용을 설명합니다.

• 리소스 점유. 기다리는 클라이언트마다 TCP 연결과 HTTP 요청을 하나씩 열어 두며, 일부 게이트웨이, 프록시, 서버는 처리되지 않고 대기 중인 요청 수를 제한합니다.
• 중간 경로의 타임아웃. 요청을 너무 오래 붙잡으면 클라이언트가 서버에서 408 Request Timeout을, 프록시에서 504 Gateway Timeout을 받을 수 있습니다. 이 RFC는 타임아웃을 120초까지 늘려도 잘 동작했다고 전하지만, 일반적으로는 30초가 더 안전한 값이라고 말합니다.
• 헤더 오버헤드. 롱 폴링 요청과 응답은 모두 전체 헤더를 갖춘 완전한 HTTP 메시지이므로, 작고 드문 메시지에서는 헤더가 데이터의 큰 비중을 차지할 수 있습니다.
• 최악의 지연. 응답을 보낸 직후에 도착한 소식은 다음 요청이 올 때까지 기다려야 합니다.

몇 분 걸리는 작업에는 무엇을 써야 하나요?

어느 방식도 요청 하나를 그렇게 오래 붙잡지 않습니다. RFC 6202는 일반적으로 30초를 더 안전한 롱 폴링 타임아웃으로 보므로, 몇 분의 대기는 여러 요청으로 나뉩니다. 백오프로 간격을 둔 숏 폴링이나, 연달아 반복하는 롱 폴링입니다. 서버라면 기다리지 않고 웹훅을 받을 수도 있습니다. Sume API는 이 방식을 모두 제공하며 방식마다 한도가 있습니다. 이미지 Job은 30초 제출 대기 안에 끝나는 경우가 많지만, 영상 Job은 대개 그렇지 않습니다.

• 숏 폴링: terminal이 true가 될 때까지 GET /v1/jobs/{id}/status를 읽으세요. next_poll_after_seconds가 있으면 그만큼 쉬고, 없으면 지수 백오프하세요. 읽기에는 쓰기 예산의 마흔 배인 별도 예산이 있으므로, 촘촘한 상태 폴링 루프 때문에 내 제출 요청이 429를 받는 일은 없습니다. 루프 코드는 영상 생성 Job 상태 API 폴링하기에 있습니다.
• 제출 시의 제한된 대기: mode를 받는 경로에서 mode: "sync"나 그 별칭인 subscribe를 보내면 생성 요청을 최대 30초 동안 붙잡아 두며, waiter 용량이 없으면 그보다 짧습니다. 그때까지 종료 상태가 아니라면 다시 제출하지 말고 폴링하세요. 동작이 다른 경로는 영상 생성 API 동기 vs 비동기에 정리되어 있습니다.
• 롱 폴링 반복: 호스팅 MCP의 jobs_wait는 호출 한 번을 최대 55초, 기본 50초 동안 붙잡아 둡니다. 문서에 따르면 아무것도 전송하지 않은 채 열려 있는 요청은 어떤 엣지든 결국 끊으므로, 십 분짜리 렌더는 더 긴 대기를 요청하지 말고 대기를 반복해서 기다리세요. MCP 도구 호출 타임아웃을 참고하세요.
• 웹훅: 기다리지 말고, 웹훅과 API의 차이에서처럼 Sume가 종료 이벤트를 서버로 POST하게 하세요.

WebSocket과 서버 전송 이벤트는 어떤가요?

둘 다 폴링을 기다리지 않고 서버가 소식을 보낼 수 있게 합니다. WebSocket은 브라우저가 답을 받으려고 폴링하지 않고도 메시지를 보내고 응답을 받을 수 있는 양방향 세션입니다. 서버 전송 이벤트(Server-sent events)를 쓰면 서버가 언제든 웹 페이지에 새 데이터를 푸시할 수 있습니다. 현재 Sume Developer API는 둘 다 제공하지 않으며, GET /v1/jobs/:id/events는 스트림이 아니라 pull 스냅샷입니다. 브라우저 페이지가 대신 어떻게 기다리는지는 React Query 폴링에서 보여 줍니다.