폴링
Polling · 주기 조회
폴링은 클라이언트가 정해진 간격으로 서버나 API에 요청을 보내 데이터 변경 여부를 확인하는 방식입니다. 변경이 없어도 요청이 발생하므로 주기, 호출 제한, 중복 처리와 지연 허용 범위를 함께 설계합니다.
AI 보조 조사·작성 후 원문과 대조한 설명입니다. 사례·계산은 별도 출처 표기가 없는 한 이해를 위한 가상 예시이며 실제 고객 성과가 아닙니다.
폴링 주기는 무엇으로 정하나요?
업무가 허용하는 지연과 API 비용을 함께 봅니다. 1분 안에 반영돼야 하는 재고와 하루 한 번 갱신해도 되는 보고서는 주기가 달라야 합니다. 매번 전체 목록을 받기보다 수정 시각, 커서, 페이지 토큰이나 마지막 ID를 사용해 변경분만 가져옵니다.
GitHub는 웹훅을 사건이 생길 때 데이터를 자동 전달하는 방식으로 설명하며, 폴링은 API를 간헐적으로 호출해 데이터 유무를 확인하는 방식으로 대비합니다. GitHub 웹훅과 폴링 비교
호출량은 어떻게 계산하나요?
5분마다 고객 40개 계정을 조회하면 시간당 480회, 하루 11,520회입니다. 여기에 페이지네이션 3페이지와 실패 재시도를 곱하면 34,560회를 넘을 수 있습니다. 계정 수만 보고 한도를 계산하면 실제 호출량을 놓칩니다.
응답이 없거나 타임아웃이 났을 때 같은 변경을 다시 받아도 안전하도록 외부 이벤트 ID나 원천 레코드 ID로 중복을 제거합니다. 마지막 성공 시각과 마지막 시도 시각을 분리해야 장시간 누락을 발견할 수 있습니다.
지연과 누락은 어떻게 확인하나요?
폴링 작업이 실행됐다는 로그만으로 데이터 최신성을 증명할 수 없습니다. 원천의 최신 수정 시각과 목적지의 반영 시각 차이, 처리 건수, 마지막 커서, 연속 실패 횟수를 봅니다. 서버 시간이 다르면 수정 시각 경계에서 레코드가 빠질 수 있어 조회 구간을 조금 겹치고 중복 제거합니다.
Google Calendar API는 변경 알림이 폴링의 추가 네트워크·연산 비용을 줄일 수 있다고 설명하지만 알림 채널 생성, HTTPS 수신 주소와 만료 관리가 필요합니다. Google Calendar 푸시 알림 문서
폴링과 웹훅은 어떻게 다른가요?
폴링은 수신 측이 조회 시점과 재시도를 통제하기 쉽지만 변경이 없어도 호출 비용이 듭니다. 웹훅은 변경 때 전달돼 빠르고 효율적이지만 수신 장애, 서명 검증, 순서 뒤바뀜과 재전송에 대비해야 합니다. 둘 중 하나만 고집하기보다 웹훅으로 알림을 받고 폴링으로 누락을 보정하는 조합도 가능합니다.
운영 대시보드에 둘 지표
- 마지막 성공 조회와 마지막 원천 수정 시각
- 요청·성공·오류·재시도 횟수
- 페이지·커서별 처리 건수
- 중복 제거와 누락 보정 건수
- 계정별 호출 제한 잔여량
폴링 작업이 여러 개면 시작 시각을 분산합니다. 매 정각에 모두 실행하면 API와 내부 데이터베이스에 순간 부하가 몰리고, 장애 뒤 재개할 때 같은 문제가 반복될 수 있습니다.
자주 묻는 질문
- 폴링 주기는 짧을수록 좋은가요?
- 아닙니다. 지연은 줄지만 호출 비용과 제한 초과 가능성이 커집니다. 업무 허용 지연에 맞춰 정합니다.
- 폴링 응답이 0건이면 동기화가 정상인가요?
- 반드시 그렇지 않습니다. 잘못된 커서, 권한, 시간대와 필터 때문에 0건일 수 있어 최신 원천 값과 대조해야 합니다.
- 웹훅을 쓰면 폴링이 필요 없나요?
- 누락 보정과 상태 재동기화를 위해 주기적 확인이 필요한 시스템도 있습니다.
출처와 확인 범위
- About webhooks · GitHub Docs · 확인 2026-10-27
웹훅과 폴링의 전달 방식·자원·지연 차이를 설명합니다.
확인 범위: GitHub 환경의 설명이며 모든 API가 웹훅을 제공하지 않습니다.
- Push notifications · Google Calendar API · 확인 2026-10-27
푸시 알림이 폴링 비용을 줄이고 채널·HTTPS 수신 설정이 필요함을 설명합니다.
확인 범위: Google Calendar API 지원 리소스에 한정됩니다.