GitLab 속도 제한 마이그레이션에 AI 에이전트를 활용한 방법

GitLab은 애플리케이션 레벨 속도 제한 시스템과 Rack 레벨 시스템 두 개를 동시에 운영하고 있었다. 3인 팀이 AI 에이전트를 활용해 121개 키 전체를 labkit-ruby 단일 구현으로 통합하는 마이그레이션을 수행하며 에이전트가 코드 생성의 병목을 해소하지만 리뷰 역량과 롤아웃 판단이 새로운 병목으로 떠오른다는 사실을 발견했다.

핵심 포인트

3인 팀이 121개 속도 제한 키를 30개 이상의 MR을 통해 마이그레이션하면서 AI 에이전트를 코드 생성·검토 보조 도구로 활용했다.
엄격한 에이전트 작업 흐름: epic 읽기 → 명세 작성 → 명세 적대적 검토 → 구현 → 증거 기반 검증 → MR 적대적 검토 → 인간 에스컬레이션 → 머지.
초기 코호트 5개 키(pipelines_create, notes_create, user_sign_in 포함) 롤아웃: 1% → 10% → 50%(5월 4일) → 100%(다음날) 순서로 진행.
에이전트는 코드베이스 전반 95개 호출 지점 통합 같은 기계적 팬아웃 작업에서 특히 효과적이었다.
Redis 클러스터 주요 샤드 CPU 포화로 75,000 커넥션 시점에 강제 중단이 발생해 인프라 제약이 마이그레이션 페이스를 결정했다.

상세 정리

배경: GitLab이 애플리케이션 레벨과 Rack 레벨 두 개의 속도 제한 시스템을 병행 운영하던 상황. 목표는 두 시스템을 labkit-ruby의 단일 구현으로 통합.
팀 구성: Max Woolf, Bob Van Landuyt, Sam Wiskow 3인.
엄격한 작업 흐름: epic 읽기 → 명세 작성 → 적대적 검토(refute-first, 2라운드 이내 해소 안 되면 인간 에스컬레이션) → 블로커 해소 후 구현 → 명시적 증거로 검증 → MR 적대적 검토 → 머지.
초기 코호트 선정: 트래픽 상위 5개 키(pipelines_create, notes_create, user_sign_in 포함)를 먼저 선택.
피처 플래그 기반 점진적 롤아웃: 1% → 10% → 50%(2026-05-04) → 100%(다음날) 순서로 코호트별 확산.
섀도 모드 인시던트: 인증되지 않은 코드 경로에서 식별자가 의도치 않게 누락되는 버그를 섀도 모드에서 발견. 포스 모드 전환 전 수정 완료.
누락 키 발견: 초기 분석에서 EE 전용 제한 키 17개와 고아(orphaned) 어댑터 행이 빠져있었음. 이후 스캐닝으로 발견해 포함.
Redis 병목: 주요 샤드에서 CPU 포화 현상이 발생해 75,000 Redis 커넥션 시점에 강제 중단. 4-샤드 클러스터 구조에서 특정 샤드에 부하 집중.
기계적 팬아웃에서의 효과: 95개 호출 지점을 새 프레임워크로 전환하는 반복 작업에서 에이전트가 큰 효과를 발휘.
병목 이동: 에이전트 도입 후 코드 생성이 아닌 리뷰 역량, 롤아웃 판단, 운영자 주의가 새로운 제약 자원으로 떠오름.
결과: 2026년 6월 중순 기준 121개 키 전체가 새 프레임워크를 통해 동작. 피처 플래그 전략과 시스템 동작 검증에는 인간 판단이 필수적이었음.