깃랩(GitLab)이 자사 SaaS 서비스인 깃랩닷컴(GitLab.com)의 요청 속도 제한(rate limit) 정책을 구독 등급에 맞춰 재편한다. 회사가 밝힌 일정에 따르면 2026년 10월 19일부터 무료(Free) 계정과 인증되지 않은 요청에 새 제한이 먼저 적용되고, 프리미엄(Premium)과 얼티밋(Ultimate) 등급은 2027년 1월에 이어서 바뀐다. 각 등급별 구체적 수치는 깃랩 공식 속도 제한 문서에 게시된다. 이번 변경은 깃랩닷컴에만 해당하며, 고객이 직접 운영하는 셀프매니지드(Self-Managed)나 전용 인프라 형태인 데디케이티드(Dedicated)에는 적용되지 않는다.
배경은 급증하는 플랫폼 부하다. 깃랩은 수백만 개 프로젝트를 호스팅하고 있으며 올해 플랫폼 부하가 여러 배로 늘어날 것으로 본다고 밝혔다. 특히 팀들이 늘려가는 자동화와 에이전트 워크로드가 부하 증가의 한 축이다. 예측 가능한 제한이 있어야 모든 사용자에게 서비스 속도를 일정하게 유지할 수 있다는 것이 정책 개편의 논리다. 깃랩은 실제 사용 패턴과 유사 플랫폼의 정책을 함께 검토해 수치를 정했다고 설명했으며, 대다수 사용자는 이미 새 제한 범위 안에 있어 체감할 변화가 없을 것이라고 덧붙였다. 무료 등급과 익명 허용치는 업계 표준 수준이고, 프리미엄과 얼티밋은 다른 플랫폼이 엔터프라이즈 등급에나 열어주거나 아예 공개하지 않는 수준으로 더 넉넉하다는 것이 회사 측 주장이다.
인증 여부가 제한을 가른다
이번 정책의 핵심은 인증된 요청과 그렇지 않은 요청을 명확히 구분한다는 점이다. 자격 증명 없이 들어오는 익명 요청은 출처와 무관하게 IP 주소당 시간당 60건으로 묶인다. 유료 계정을 대상으로 돌아가는 자동화라도 자격 증명을 붙이지 않으면 이 익명 한도에 걸린다. 반면 인증된 요청은 사용자별, 그리고 최상위 그룹(top-level group)별로 각자의 구독 등급 한도를 적용받는다. 여러 최상위 그룹에 속한 사용자라면 자신이 접근 가능한 가장 높은 등급이 기준이 된다. 예컨대 얼티밋 그룹의 구성원이면 얼티밋 한도를 쓸 수 있다.
실무자가 당장 취할 수 있는 조치는 요청에 인증을 붙이는 것이다. 개인 액세스 토큰이나 OAuth 토큰, CI/CD 잡 토큰(job token) 중 무엇을 쓰든 요청은 시간당 60건의 익명 한도에서 벗어나 훨씬 높은 등급 한도로 옮겨간다. 대개 큰 수정 없이 적용할 수 있는 변경이다. 그 다음으로는 API 호출 방식을 점검하라고 권한다. 배치 처리, 캐싱, 페이지네이션이 부담을 크게 줄이는 반면, 타이트한 루프로 폴링을 돌리면 허용치가 빠르게 소진된다.
브라운아웃으로 미리 확인
깃랩은 정식 적용에 앞서 무료 및 익명 트래픽을 대상으로 두 차례 프리뷰 창(엔지니어들이 브라운아웃이라 부르는 구간)을 연다. 10월 7일과 10월 14일, 각각 15:00~19:00 UTC(한국 시간 자정~오전 4시)에 새 제한을 잠시 켰다가 끄는 방식이다. 이 시간 동안 서비스의 다른 요소는 그대로이며, 목적은 정식 적용 몇 주 전에 자신의 워크로드가 새 한도 아래에서 어떻게 동작하는지 실제로 관찰하게 하려는 것이다. 프리미엄과 얼티밋의 인증 요청은 한도가 1월까지 바뀌지 않으므로 이 프리뷰의 영향을 받지 않는다.
제한에 걸리면 서버는 HTTP 429(Too Many Requests) 응답과 함께 RateLimit-* 헤더, 그리고 얼마나 기다려야 하는지 알려주는 Retry-After 헤더를 돌려준다. 응답 헤더를 읽는 클라이언트라면 대부분 스스로 회복하며, 즉시 재시도하기보다 지수적 백오프를 적용하는 편이 더 빠르게 정상화된다. 현재 자신이 영향권에 있는지 판단하려면 가장 바쁜 1분의 요청량을 게시된 등급 한도와 비교해보면 된다. 당장은 API 응답의 RateLimit-Remaining 헤더가 남은 여유를 보여주는 가장 빠른 신호이며, 깃랩은 사용량을 등급 한도와 대비해 보여주는 제품 내 화면을 올해 안에 출시할 예정이라고 밝혔다.
공개 프로젝트와 예외 상황
트래픽이 많은 공개 프로젝트 운영자에게는 세 가지 선택지가 제시된다. 프로젝트를 호출하는 자동화가 로그인하도록 해 익명 허용치 대신 자체 한도로 옮기거나, 트래픽이 의도한 사용자층에서 온 것이 아니라면 프로젝트를 비공개로 전환해 익명 호출 자체를 차단하거나, 프리미엄·얼티밋으로 상향해 한도를 크게 늘리는 방법이다. 공개 상태 배지처럼 인증이 원천적으로 불가능한 정당한 익명 패턴도 존재하는데, 이런 통합을 운영 중이라면 깃랩은 limits@gitlab.com으로 문의하라고 안내했다. 표준 한도를 넘는 용량을 상시로 구매하는 방안도 준비 중이며 세부 내용은 올해 후반에 공개된다.
정리하면 이번 조치의 표적은 단일 워크로드가 전체 플랫폼을 느리게 만드는 상황이지, 일상적인 로그인 사용이 아니다. UI 탐색, 에디터 작업, git 푸시·풀, 등급 범위 내 CI/CD 실행은 지금과 동일하게 이어진다. 다만 일부 무거운 자동화와 소수의 무료 등급 워크로드는 새 상한에 닿을 수 있으므로, 해당한다고 판단되면 프리뷰 창을 활용해 미리 자신의 트래픽을 점검하고 인증 적용 여부를 확인해 두는 것이 안전하다.