Rate limits on GitLab.com are changing
GitLab.com의 레이트 리밋이 변경됩니다 — 구독 티어별로 차등 적용
GitLab.com이 10월 19일부터 레이트 리밋을 구독 티어별로 차등 적용합니다. 미인증 요청은 IP당 시간 60회로 제한되며, Free는 10월, Premium·Ultimate는 2027년 1월부터 적용됩니다. 대부분의 사용자는 영향이 없지만 익명 자동화 트래픽은 인증 도입이 필요합니다.
- 주제
본문
GitLab이 GitLab.com의 레이트 리밋 정책을 구독 티어 기반으로 개편한다고 발표했습니다. 플랫폼 수요가 빠르게 증가하고 있으며 올해 플랫폼 부하가 몇 배로 커질 것으로 예상되는 가운데, 팀들이 구축하는 자동화와 에이전트 워크로드를 포함해 모든 사용자에게 빠른 서비스를 유지하기 위해서는 예측 가능한 리밋이 필요하다는 것이 배경입니다.
적용 일정과 티어별 구조
새 리밋은 2026년 10월 19일부터 Free 계정과 미인증 요청에 먼저 적용되며, Premium과 Ultimate는 2027년 1월로 이월됩니다. 리밋은 사용자 단위와 최상위 그룹 단위로 적용되고, 인증된 요청은 각 구독 플랜의 리밋을 따릅니다. 자격 증명 없이 들어오는 요청은 IP 주소당 시간 60회로 제한됩니다. 플랜별 구체적인 수치는 레이트 리밋 문서에 공개되어 있습니다.
프리뷰 윈도우(브라운아웃) 운영
GitLab은 Free와 미인증 트래픽을 대상으로 10월 7일과 10월 14일, 각각 UTC 15:00~19:00에 두 차례 프리뷰 윈도우를 운영합니다. 엔지니어들이 '브라운아웃'이라 부르는 이 방식은 새 리밋을 짧게 켰다가 다시 끄는 계획된 테스트로, 정식 적용 몇 주 전에 자신의 워크로드가 새 리밋 아래에서 어떻게 동작하는지 실제로 확인할 수 있게 해줍니다. 미인증 요청은 유료 계정을 대상으로 한 자동화라도 자격 증명이 없으면 모두 상한이 적용되며, 로그인한 Premium·Ultimate 요청은 1월까지 영향이 없습니다.
리밋 산정 기준과 대응 방법
GitLab은 실제 GitLab.com 사용 패턴을 분석해 리밋을 정했으며, 거의 모든 사용자는 이미 새 리밋 범위 안에 있어 변화를 체감하지 못할 것이라고 설명합니다. 유사 플랫폼과 비교했을 때 Free 리밋과 익명 허용량은 업계 표준 수준이고, Premium·Ultimate는 다른 플랫폼이 엔터프라이즈 티어에만 제공하거나 아예 공개하지 않는 수준으로 더 넉넉하다고 덧붙입니다. 리밋에 근접했다면 요청을 인증하는 것이 첫 번째 대응입니다. Personal Access Token, OAuth 토큰, CI/CD Job Token을 사용하면 익명 60회 리밋에서 벗어나 훨씬 높은 플랜 리밋을 적용받습니다. 이어서 배칭, 캐싱, 페이지네이션 같은 API 호출 최적화가 권장되며, 짧은 루프로 폴링하는 방식은 허용량을 빠르게 소진합니다. 리밋 초과 시 HTTP 429와 함께 Retry-After 헤더가 반환되므로, 응답 헤더를 읽는 클라이언트는 사실상 스스로 복구되며 즉시 재시도보다 지수 백오프가 더 빨리 회복됩니다.
변하지 않는 것과 추가 옵션
UI 탐색, 에디터 작업, git push/pull, 플랜 범위 내 CI/CD 실행은 그대로 유지됩니다. 영향을 받는 것은 일부 무거운 자동화와 소수의 Free 티어 워크로드입니다. 상시로 더 높은 리밋이 필요한 경우 표준 플랜을 초과하는 용량을 구매하는 방안이 연내 공개될 예정이며, [email protected]으로 문의할 수 있습니다. 인증이 불가능한 합법적인 통합 — 예컨대 공개 상태 배지 — 도 같은 채널로 상담이 가능합니다. 여러 최상위 그룹의 멤버라면 접근 가능한 가장 높은 티어의 리밋이 적용됩니다. 이 변경은 GitLab.com에만 해당하며 Self-Managed와 Dedicated는 대상이 아닙니다. 사용량 확인은 응답의 RateLimit-Remaining 헤더로 가능하고, 플랜 대비 사용량을 보여주는 제품 내 뷰도 연내 출시됩니다.
Hacker News 반응
- @tempest_ — 이게 LLM 스크래핑 때문이라고 생각합니다.
- @nijave — 아마 그렇겠지만, 레이트 리밋과 차단 대신 코드 최적화나 페이지를 완전히 캐시 가능하게 만드는 쪽에도 집중해줬으면 합니다.
- @swatcoder — 캐시가 있어도 요청을 보내는 것이 응답을 전달하는 것보다 본질적으로 쌉니다. 효율 개선은 주어진 리소스로 약간의 시간을 벌 뿐이고, 이제 누구나 12초 만에 커스텀 봇을 만들 수 있고 그렇게 하도록 권장받는 상황에서 봇 포화 문제는 해결하지 못합니다. 레이트 리밋, 차단, 종량제가 유일한 출구이며, 모델이 해킹과 위장에 능해지면서 그마저 오래가지 않을 수 있습니다. 우리가 LLM과 함께 쓰고 싶은 인터넷은 애초에 LLM을 감당할 수 있는 구조가 아니며, LLM이 사라지지 않는 한 인터넷 경험 전체가 바뀔 것입니다.
- @jayd16 — 이 리밋은 API 요청에 대한 것 아닌가요? 아니면 그냥 무관한 성능 불만인가요?
- @nijave — 마지막으로 확인했을 때는 모든 것에
cache-control: max-age=0을 일괄 적용했습니다. https://gitlab.com/gitlab-org/gitlab 페이지를 로드하면 API 호출이 14건 보이는데, 공개 페이지 하나에 DB 쿼리가 훨씬 많을 것입니다.
원문: Hacker News / 번역·요약: Trawling