Git-AI: 같은 브랜치에 몰리는 에이전트 변경을 서버에서 처리하기

배경과 문제

코딩 에이전트는 사람과 다르게 몇 개 파일만 고치는 짧은 작업을 수천 개씩 같은 브랜치에 몇 초 안에 반영하려 한다. 기존 Git 호스팅은 사람이 저장소를 통째로 클론해 몇 시간 작업하고 한 번 push하는 흐름에 맞춰져 있어, 전체 클론과 병합 대기열, 클라이언트에서 이력을 훑는 작업이 병목이 된다. Anthropic은 사내 모노레포에 병합되는 변경이 2026년 5월 하루 약 2,500건에서 9월 하루 30,000건 이상으로 늘었고, 그 사이 소스 관리가 가장 큰 개발 병목이 됐다고 밝혔다.

gitai는 이 문제를 서버 중심으로 풀려고 한다. 에이전트는 전체 클론 대신 필요한 경로의 파일만 받고, blame이나 파일 이력 같은 질문은 서버가 한 번 계산해 저장해 둔 값으로 답한다. 변경은 병합 대기열을 거치지 않고 서버가 rebase한 뒤 CAS로 브랜치를 옮겨 반영한다. 같은 브랜치에 동시에 들어온 변경은 한 번의 참조 갱신으로 묶어 처리한다. 이 방식은 Anthropic이 공개한 Scion 설계를 따르지만, gitai는 Scion의 내부 코드가 아니라 공개된 글만 보고 만든 독립 구현이다. 10월 21일 커뮤니티 글은 초기 v0.1.0의 설명이고, 함께 대조한 현재 README는 v0.3.0을 설명한다. 기능과 측정값은 버전을 나눠 읽어야 한다.

기존 접근의 한계

일반 Git 서버에 에이전트가 동시에 push하면 브랜치 끝(tip)이 계속 움직여 클라이언트가 rebase와 push를 반복해야 한다. 커뮤니티가 소개한 옛 phase 4a 벤치마크에서 배칭을 끈 서버는 에이전트 50개가 변경 250개를 보낼 때 99개만 반영됐고, 성공·실패 요청의 시도를 모두 합쳐 성공한 반영 수로 나누면 27.94회였다. 이 값에는 실패한 요청의 재시도도 포함되므로 성공한 한 요청이 20회 상한을 넘게 실행됐다는 뜻은 아니다. 참조 갱신 경쟁 때문에 일부 요청은 재시도 상한에 도달해 포기했다.

병합 대기열은 이런 경쟁을 줄이지만 변경을 하나씩 직렬화하므로 대기 시간이 길어진다. gitai는 대기열 대신 서버가 rebase와 CAS를 수행하고, 동시 요청을 배치로 묶어 한 번의 참조 갱신으로 처리한다. 다만 실제 내용 충돌, 즉 두 에이전트가 같은 줄을 다르게 고치는 문제는 배칭으로 해결되지 않으며 별도의 충돌 해소기가 필요하다.

연구방법을 단계별로

클라이언트는 우선 변경을 임시 브랜치에 커밋한다. 서버의 UserLand가 대상 브랜치 끝인 tip을 읽고, 현재 tip이 새 커밋의 조상이면 브랜치 끝만 앞으로 옮기는 fast-forward가 가능하다. 반대로 새 커밋이 현재 tip의 이력에 이미 포함돼 있으면 already_landed로 처리한다. 갈라진 이력이면 tip 위로 rebase한 뒤 훅과 접근 정책을 검사하고 CAS로 참조를 바꾼다. 경쟁에서 지면 재시도하되 일반 비배치 경로의 기본 상한은 20회이고, 배치 전체 재시도와 일부 참조 백엔드는 다른 규칙을 쓴다. 반영한 변경과 행위자는 기록에 남는다.

에이전트가 많아지면 CAS 경쟁이 병목이 되므로 gitai는 배칭을 도입한다. 서버는 브랜치마다 요청 대기열(lane)을 두고, 첫 요청 뒤 10ms가 지나거나 요청이 50개 모이면 배치를 만들어 한 번의 참조 갱신으로 반영한다. 대기열 하나는 한 번에 배치 하나만 실행하므로, 대기열이 꽉 차면 요청은 앞선 배치가 끝나기를 기다린다. rebase 중 충돌이 나면 서버는 충돌 파일 목록을 담아 merge_conflict 오류를 돌려주고, 운영자가 리졸버를 설정하고 클라이언트도 충돌 해소를 요청한 경우에만 그 경로를 사용한다.

저장 방식도 선택할 수 있다. 기본은 일반 Git 저장소를 쓰고, storage core를 켜면 데이터베이스와 객체 저장소를 기준으로 각 서버의 로컬 Git 복제본을 다시 만들 수 있게 한다. SQLite는 한 노드, 여러 노드는 PostgreSQL을 사용한다. 로컬 저장소와 pack 파일은 여전히 필요하므로 완전히 상태 없는 서버나 pack 파일을 없앤 Scion 구현이라고 이해하면 안 된다.

결과와 숫자의 의미

현재 README의 벤치마크는 에이전트 50개가 한 브랜치에 변경 5개씩, 총 250개를 보내고 20%는 일부러 충돌하게 만든 조건에서 두 번 실행한 결과를 제시한다. 배칭을 끈 'classic'은 100~106개를 반영했고 분당 264~385건, p99 지연은 4.4~5.2초다. 배칭을 켠 'gitai'는 200개를 반영했고 분당 1,487~1,944건, p99 지연은 1.9~2.7초다. 반영되지 않은 50개는 설계상 충돌이며, 이 실행에서는 충돌 해소기를 쓰지 않아 에이전트로 돌려보낸 것이다.

이 수치는 합성 부하 실험이라는 점을 주의해야 한다. 벤치마크의 에이전트는 goroutine으로 만든 가짜 클라이언트이며 실제 LLM 코딩이나 코드 품질을 평가하지 않는다. 또 현재 BENCH.md 서두에는 같은 조건에서 classic이 100~101개, 분당 240~272건, p99 6.3~7.0초, gitai가 분당 1,862~2,544건, p99 1.5~1.8초로 README와 수치가 다르다. 확보한 문서만으로 불일치의 원인을 확정할 수 없으므로 하나의 일관된 성능 수치로 합치지 않고 각 표를 구분해 읽어야 한다.

구체적인 예시

같은 브랜치에 겹치지 않는 파일 수정이 몰리는 경우를 생각해 보자. 에이전트 A가 docs/readme.md를, 에이전트 B가 src/api.go를 각각 고쳐 동시에 반영하려 하면, 배칭을 끈 서버에서는 둘 중 하나가 먼저 tip을 옮기고 다른 하나는 rebase 후 CAS에서 실패해 재시도한다. 배칭을 켜면 두 변경이 한 배치로 묶여 한 번의 참조 갱신으로 반영되므로 재시도가 줄어든다.

반면 두 에이전트가 같은 파일의 같은 줄을 다르게 고치는 내용 충돌은 배칭으로 해결되지 않는다. 이 경우 서버는 merge_conflict 오류를 돌려주고, 운영자가 deterministic resolver를 설정하면 trivial, union, rerere 같은 전략으로 기계적 충돌을 해소할 수 있다. 하지만 임의의 코드 충돌에 대한 의미적 정답을 보장하지는 않으며, LLM을 쓰는 해소기는 서버 밖에서 동작한다. 현재 README에서는 LLM 결과를 제안으로 취급하며, 자동 반영하려면 정확히 반영될 후보 트리에서 설정된 검증 명령을 통과해야 한다고 설명한다.

한계와 오해하기 쉬운 점

gitai는 버전 0.x로 인터페이스가 1.0 전까지 바뀔 수 있고, 벤치마크는 개발자 노트북 한 대의 WSL2에서 측정한 합성 부하라 독립적인 재현이 없다. 문서 간 측정 수치도 불일치한다. 파일 경로별 권한은 아직 구현되지 않았고, S3·GCS·Azure 같은 클라우드 객체 저장소는 테스트되지 않았다. storage core의 checkpoint와 GC는 현재 존재하지만 GC는 기본 off이며, 분산 프로덕션 확장이나 실사용 SLA는 입증되지 않았다.

커뮤니티 글에 소개된 옛 phase 4a 결과는 배칭을 켰을 때 p99가 9.9초에서 12.7초로 악화했다고 보고했지만, 이는 이후 코드 변경으로 대체된(superseded) 결과다. 현재 README와 BENCH.md는 배칭이 p99를 개선한다고 제시하지만, classic은 stock Git이 아니라 배칭을 끈 gitai 서버라는 점도 혼동하기 쉽다. 또 남은 50개 변경은 충돌이므로 무조건 유실되는 것이 아니라 해소기 없이 에이전트로 돌아간 것이다.

실제로 어떻게 활용할까

코딩 에이전트 수십 개가 한 저장소의 같은 브랜치에 변경을 보내며 push 충돌과 재시도, 병합 대기열 대기를 겪는 플랫폼 팀이라면 gitai로 서버 쪽 반영과 에이전트별 토큰 정책, 변경 기록을 실험해 볼 수 있다. 빌드에는 Go 1.26과 Gitaly 빌드 도구가 필요하므로 이 환경을 직접 다루고 자체 서버에 실험용 저장소를 띄울 수 있는 팀이 대상이다.

현재 버전도 인터페이스 변경 가능성이 있는 0.x 프로젝트다. GitHub나 GitLab처럼 웹 UI·이슈·CI까지 갖춘 호스팅 서비스로 볼 수는 없다. 다만 현재 README에는 에이전트용 리뷰 기능이 있으며, storage core 문서는 checkpoint와 GC를 설명하므로 초기 글의 기능 부재를 그대로 현재 상태에 적용하면 안 된다. 운영 저장소에 적용하려면 자체 부하에서 지연과 반영 성공률을 재고, 코드 충돌의 검증 절차와 저장·복구 동작을 별도로 확인하는 접근이 적절하다.