에이전트 수천 개가 붙는 Git, GitLab의 답

출처: GitLab Blog (Bill Staples)
원문: https://about.gitlab.com/blog/scaling-git-for-the-agentic-software-factory/
작성자: 팔복소프트-김팔복

한눈에 보기

• GitLab이 AI 에이전트 수천 개가 동시에 붙는 상황을 겨냥한 차세대 소스 관리(next-gen SCM)를 프라이빗 베타로 운영하고 있습니다.
• 핵심은 Git 프로토콜을 유지한 채 서버 아키텍처를 바꾸는 것이고, 폐쇄망 데이터센터에서도 돌아가도록 설계했습니다.
• 내부 초기 테스트에서는 기존 방식 대비 최대 50배 빠른 처리, 최대 2배 적은 토큰, 최대 1,000배 적은 네트워크 트래픽을 기록했지만, GitLab 스스로 특정 조건에서의 최댓값이라고 선을 그었습니다.
• 비교 대상은 Anthropic입니다. 모노레포 일일 머지가 5월 약 2,500건에서 9월 30,000건 이상으로 늘자 Anthropic은 전용 시스템 Scion을 만들었고, GitLab은 범용 노선을 택했습니다.
• 소스 관리가 빨라지면 병목은 CI, 보안 검토, 배포로 옮겨간다는 점도 함께 짚었습니다.

배경

Git은 모든 클라이언트가 저장소 사본을 통째로 갖는 분산 구조입니다. 사람은 한 번 clone해 두고 오래 쓰지만, 에이전트는 작업마다 새 환경을 띄워 저장소를 내려받습니다. Git에도 shallow clone, partial clone, sparse checkout 같은 완화책이 있지만, 이것들은 클라이언트 쪽 요령이지 서버 구조 자체를 바꾸지는 않습니다.

무엇이 문제인가: 에이전트 1회 호출의 비용

기존 Git 워크플로에서는 에이전트가 한 번 호출될 때 5~10GB의 데이터가 오가고, 질문 하나에 답하기 전 준비 시간만 30초가 넘게 걸릴 수 있습니다. 에이전트가 수천 개라면 소스 관리 서버가 가장 먼저 막힙니다.

그림 1. 에이전트 규모 소스 관리에 대한 세 가지 접근 (팔복소프트 작성)

Anthropic의 Scion은 이 문제를 정면으로 풀었지만 조건이 분명합니다. 초대형 모노레포에, 클라이언트 대부분이 항상 접속해 있는 에이전트인 환경을 전제로 합니다. Anthropic도 Scion이 Git의 범용 대체재가 아니며 코드 리뷰, 검색, CI 인프라를 별도로 갖춰야 한다고 인정했습니다. 그런 Anthropic 소스 관리 팀의 Nick G.는 GitLab과의 협업에 대해 이렇게 말했습니다.

"Git 서버가 이런 워크로드를 위해 할 수 있는 일을, 전체 Git 모델에서 벗어나지 않고도 넓힐 여지가 있다고 봅니다." — Nick G., Anthropic Source Control

GitLab의 설계: 프로토콜은 그대로, 백엔드만 교체

또 하나의 축은 격리 세션입니다. 수천 개 에이전트가 각자 세션에서 병렬로 실험하고, 실패한 시도는 공유 코드를 건드리지 않고 버립니다. 성공한 변경만 기존 Merge Request, 파이프라인, 보안 점검, 거버넌스 통제를 거쳐 운영으로 나갑니다.

그림 2. 에이전트가 만든 변경이 운영까지 가는 경로 (팔복소프트 작성)

병목은 다음 단계로 옮겨간다

GitLab은 소스 관리만 빨라져서는 의미가 없다고 봅니다. 지난 1년 사이 GitLab.com 고객이 만든 CI/CD 파이프라인은 40%, 코드 푸시는 50% 늘었습니다. 에이전트가 몇 초 만에 짠 코드가 검증을 몇 시간씩 기다린다면 이득이 사라집니다. 그래서 컨텍스트 그래프인 GitLab Orbit, 에이전트 작업을 조율하는 GitLab Duo Agent Platform, 에이전트 행동의 귀속·권한 관리까지 묶어 "거버넌스가 있는 소프트웨어 공장"으로 제시합니다.

팔복소프트 관점

• 국내 기업에는 '폐쇄망 지원'이 가장 눈에 띕니다. 금융·공공처럼 망 분리 환경에서 GitLab self-managed를 쓰는 곳이 많은데, 에이전트용 SCM을 SaaS 전용으로만 냈다면 이 시장은 처음부터 빠졌을 겁니다. 고객 소유 S3 호환 스토리지 지원은 국내 클라우드 오브젝트 스토리지와 조합할 여지도 엽니다.
• 숫자는 마케팅용 상한선으로 읽어야 합니다. "최대 50배", "최대 1,000배"는 GitLab 스스로 특정 조건의 최댓값이라고 밝혔고, 지속적인 동시 부하 검증은 아직 진행 중입니다. 도입 판단은 자기 저장소로 직접 재 본 뒤에 해야 합니다.
• 당장 대부분의 팀에는 급한 이야기가 아닙니다. 에이전트 몇 개 수준이라면 partial clone, sparse checkout, 작업 디렉터리 캐시로 충분합니다. 이 제품이 필요한 쪽은 모노레포가 크고 에이전트를 수백 개 단위로 병렬 실행하려는 조직입니다.
• 진짜 비용은 CI 쪽에서 터집니다. 원문도 인정하듯 소스 관리가 풀리면 병목은 파이프라인으로 넘어갑니다. 에이전트 도입을 검토 중인 팀이라면 SCM보다 먼저 CI 러너 용량, 머지 큐 정책, 에이전트 변경의 리뷰 기준부터 점검하는 편이 현실적입니다.
• 아쉬운 점도 있습니다. 에이전트 전용 인터페이스가 구체적으로 어떤 API인지, GitHub나 다른 Git 서버에서도 쓸 수 있는 공개 표준이 될지는 원문에 없습니다. 차별점을 '플랫폼 통합'으로 둔 이상 GitLab 생태계 안에서 가장 잘 동작하는 구조가 될 가능성이 큽니다.

정리

에이전트가 코드를 쓰는 비용이 내려가자 이번에는 Git 서버가 병목으로 드러났습니다. Anthropic은 전용 시스템을 직접 만들었고, GitLab은 Git 호환을 지키면서 백엔드를 바꾸는 길을 택했습니다. 기억할 점은 두 가지입니다. 에이전트 규모의 개발에서는 저장소를 통째로 받는 방식이 더는 공짜가 아니라는 것, 그리고 소스 관리 다음 병목은 CI와 리뷰라는 것입니다. next-gen SCM은 아직 프라이빗 베타이니 수치보다 실제 워크로드 검증 결과를 기다려 보는 편이 좋습니다.

• GitLab
• Git
• AI 에이전트
• 모노레포
• DevOps