호출 제한

어떤 단위로 제한되나요?

분당 요청 수만 보지 말고 인증 사용자, 앱 설치, IP, 조직, 자원과 엔드포인트별 버킷을 확인합니다. GitHub REST API는 인증 방식에 따라 기본 한도가 다르고 검색 엔드포인트, GraphQL, 동시 요청과 콘텐츠 생성에 별도 제한을 둡니다. GitHub REST API 호출 제한

하나의 토큰을 여러 작업이 공유하면 각 작업의 사용량을 합쳐야 합니다. 읽기와 쓰기의 비용이 다르거나 한 요청이 여러 포인트를 소비하는 제품도 있습니다.

429 응답은 어떻게 처리하나요?

RFC 6585의 429 상태 코드는 일정 시간 안에 너무 많은 요청을 보냈음을 뜻하며 응답에 기다릴 시간을 나타내는 Retry-After가 포함될 수 있습니다. RFC 6585 429 절 서버가 사용자와 요청 수를 세는 방식까지 표준이 정하는 것은 아닙니다.

클라이언트는 공급사가 주는 재시도 시각이나 리셋 헤더를 우선하고, 값이 없으면 지수 백오프와 무작위 지연을 사용합니다. 같은 시간에 여러 작업이 동시에 재시도하는 재시도 폭주를 피합니다.

호출 예산은 어떻게 계산하나요?

분당 600회 한도에서 정상 폴링이 360회, 사용자 요청이 최대 120회라면 남는 120회를 재시도와 급증에 배정할 수 있습니다. 그러나 엔드포인트별 60회 제한이 따로 있다면 전체 예산이 남아도 해당 요청은 거절될 수 있습니다.

대량 작업은 페이지 크기, 증분 조회, 캐시와 배치 API로 호출 수를 줄입니다. 남은 한도 헤더를 모니터링하되 값 하나를 절대적인 서비스 보장으로 보지는 않습니다.

호출 제한·할당량·동시성은 어떻게 다른가요?

호출 제한은 짧은 시간 창의 요청 속도를 가리키는 경우가 많습니다. 할당량은 하루·월 단위 누적 사용량이나 구매한 처리량일 수 있고, 동시성 제한은 같은 시점에 진행 중인 요청 수를 제한합니다. 초당 제한을 지켜도 월간 할당량을 소진할 수 있으며, 직렬 호출은 속도 한도 아래여도 처리 시간이 길어질 수 있습니다.

제한 초과를 줄이는 방법

• 전체 조회를 증분 조회로 바꿉니다.
• 같은 응답을 짧은 시간 캐시합니다.
• 쓰기 요청은 작업 큐에서 속도를 조절합니다.
• 사용자 요청과 배치 작업의 예산을 나눕니다.
• 실패 상한 뒤에는 자동 재시도를 중단합니다.

호출 제한 수치는 요금제나 계약, 인증 방식에 따라 바뀔 수 있습니다. 코드에 숫자를 고정하기보다 응답 헤더와 공급사 문서를 읽고, 변경 알림을 운영 체크리스트에 포함합니다.

한도에 가까워졌을 때 중요도가 낮은 동기화부터 늦추고 사용자 요청과 결제·권한 같은 핵심 처리를 우선하도록 큐와 예산을 나누면 제한 초과가 전체 서비스 장애로 번지는 위험을 줄일 수 있습니다.

자주 묻는 질문

429가 나오면 바로 다시 보내도 되나요?

Retry-After나 리셋 시각을 확인하고 기다립니다. 즉시 반복하면 제한이 길어지거나 통합이 차단될 수 있습니다.

여러 API 키를 쓰면 제한을 우회할 수 있나요?

약관 위반이 될 수 있고 조직·사용자 단위 제한에는 효과가 없습니다. 공식 확장 방법을 확인해야 합니다.

호출 제한과 요금 한도는 같은가요?

아닙니다. 기술적 요청 제한과 계약상 사용량·과금 한도는 별도일 수 있습니다.

출처와 확인 범위

1. RFC 6585: 429 Too Many Requests · IETF RFC Editor · 확인 2026-10-27

   429가 일정 시간의 과도한 요청을 뜻하고 Retry-After를 포함할 수 있다고 규정합니다.

   확인 범위: 서버의 사용자 식별·계수 방식은 정하지 않습니다.

2. Rate limits for the REST API · GitHub Docs · 확인 2026-10-27

   인증·엔드포인트·동시성별 제한과 403·429 재시도 지침을 설명합니다.

   확인 범위: GitHub REST API의 현재 정책입니다.

함께 이해할 용어

이 용어를 적용하는 실무 가이드