깃랩닷컴 레이트 리밋 개편 — 10월 19일부터 요금제 연동, 미인증 요청은 시간당 60회

이 공지의 진짜 대상은 사람이 아니다. 시간당 60회라는 숫자는 브라우저로 저장소를 구경하는 사람에게는 넉넉하다. 반면 파일 목록을 훑고 파일을 하나씩 가져오는 자동화나 AI 에이전트에게는 순식간이다. 깃허브를 비롯한 여러 플랫폼이 비슷한 방향으로 움직여 온 흐름의 연장선이다.

변경 요약

무엇이 깨지나 — 익명 접근에 기대던 것들

가장 먼저 영향을 받는 건 토큰 없이 공개 저장소를 긁던 스크립트다. 구체적으로는 이런 것들이다.

• 공개 저장소의 원시 파일을 매 빌드마다 받아 오는 도커 빌드 단계
• 토큰 없이 API로 릴리스 목록·태그를 조회하는 버전 체크 스크립트
• 공유 IP 뒤에 있는 사내 CI 러너 — IP 단위 한도를 여럿이 나눠 쓰게 된다
• 코드 예시나 설정 파일을 원격에서 가져오는 문서 빌드
• 공개 저장소를 순회하는 AI 코드 에이전트·인덱서

세 번째 항목이 특히 함정이다. NAT 뒤에 러너 수십 대가 있으면, 각각은 요청을 조금씩 보내도 IP 기준으로는 한 덩어리로 집계된다. 사무실 전체가 한 시간에 60회를 나눠 쓰는 상황이 될 수 있다.

지금 해 둘 대응

# 재시도 예시: Retry-After 를 존중하는 최소 구현
import time, requests

def get(url, token, max_retry=5):
    headers = {"PRIVATE-TOKEN": token}
    for attempt in range(max_retry):
        r = requests.get(url, headers=headers, timeout=10)
        if r.status_code != 429:
            r.raise_for_status()
            return r.json()
        # 서버가 알려 준 대기 시간을 우선 사용, 없으면 지수 백오프 + 지터
        wait = int(r.headers.get("Retry-After", 2 ** attempt))
        time.sleep(wait + (attempt * 0.3))
    raise RuntimeError("rate limited")

맥락 — 공개 API의 무료 시대가 정리되는 중

지난 2년간 코드 호스팅·패키지 레지스트리·문서 사이트는 예외 없이 같은 압력을 받았다. 학습·인덱싱·에이전트 실행을 위한 자동 트래픽이 사람 트래픽을 압도하기 시작했고, 그 비용은 플랫폼이 부담해 왔다. 한도를 요금제에 연동하는 건 그 비용을 사용자 쪽으로 명시적으로 옮기는 조치다.

개발자 입장에서는 불편하지만 방향 자체는 되돌리기 어렵다. 그래서 습관을 바꾸는 게 낫다. 인증을 기본값으로 하고, 원격 리소스는 캐싱하며, 자동화는 필요한 만큼만 호출한다. 어차피 좋은 엔지니어링이기도 하다.

출처

• GitLab Blog, "Rate limits on GitLab.com are changing" — https://about.gitlab.com/blog/rate-limit-change-2026/
• GitLab Docs, "GitLab.com rate limits" — https://docs.gitlab.com/user/gitlab_com/rate_limits/
• InfoWorld, "GitLab joins rush to slow AI coders with rate limits" — https://www.infoworld.com/article/4223949/gitlab-joins-rush-to-slow-ai-coders-with-rate-limits.html

자주 묻는 질문

깃랩닷컴 레이트 리밋은 언제부터 바뀌나요?

2026년 10월 19일부터 무료 계정과 미인증 요청에 먼저 적용됩니다. 프리미엄과 얼티밋 등급은 2027년 1월로 예정돼 있습니다. 10월 7일과 14일 15:00~19:00 UTC에는 사전 확인용 브라운아웃 창이 열립니다.

미인증 요청 한도는 얼마인가요?

IP당 시간당 60회입니다. 토큰 없이 공개 저장소를 조회하는 스크립트나 도커 빌드 단계가 가장 먼저 영향을 받습니다. 인증을 붙이면 등급별로 훨씬 높은 한도가 적용됩니다.

사내 CI 러너가 여러 대인데 괜찮을까요?

공유 IP를 쓰면 러너 전체가 하나의 IP 한도를 나눠 쓰게 되므로 주의가 필요합니다. 각 잡이 인증 토큰을 사용하도록 바꾸면 사용자·그룹 단위 한도가 적용돼 상황이 크게 나아집니다.

429를 받으면 어떻게 처리해야 하나요?

즉시 재시도하지 말고 Retry-After 헤더가 지정한 시간을 기다린 뒤 재시도해야 합니다. 헤더가 없으면 지수 백오프에 지터를 더해 간격을 벌리세요. 무한 재시도 대신 상한을 두고 실패를 명확히 보고하는 편이 낫습니다.

AI 코딩 에이전트를 쓰는데 영향이 있나요?

있습니다. 저장소를 순회하며 파일을 다수 조회하는 패턴은 한도를 빠르게 소진합니다. 에이전트에 인증 토큰을 제공하고, 필요한 파일만 선택적으로 가져오도록 도구 인터페이스를 설계하며, 로컬 클론을 우선 활용하도록 지침을 두는 것이 좋습니다.