gitai는 AI 에이전트 여러 대가 한 저장소에 동시에 코드를 올릴 때를 위해 만든 오픈소스 Git 서버예요. 2026년 10월 21일 제 맥에서 에이전트 50명이 250건을 동시에 올리게 했더니 git은 100건, gitai는 250건을 반영했어요.
숫자만 보면 당장 갈아타고 싶어지는데요. 우리 팀 저장소를 같은 기준으로 재 보니 결론은 "아직 필요 없다"였어요.
에이전트 50명이 몰리면 git은 절반도 못 올렸고, gitai는 다 올렸어요
10명이면 git도 거의 다 올렸어요. 차이가 크지 않았어요
우리 팀에서 가장 바쁜 저장소도 10분 안에 동시에 올린 사람은 최대 2명이라, 지금은 git으로 충분해요
에이전트가 늘자 git이 막히기 시작했어요
저는 지피터스에서 AI 코칭 서비스 로나(Rona)를 만드는 소프트웨어 엔지니어 현진우예요. 클로드 코드(Claude Code) 세션 4개에서 5개를 동시에 띄워 한 저장소를 고치다 보니, 서로 같은 곳을 건드려 다시 작업하는 일이 잦아요.
같은 문제를 훨씬 큰 규모로 겪은 곳이 앤트로픽(Anthropic)이에요. 2026년 10월 13일 공개한 Redesigning source control at Anthropic을 보면, 사내 하루 반영 건수가 5월 약 2,500건에서 9월 3만 건 넘게 늘자 git이 병목이 됐어요.
그래서 7명이 5개월 동안 새 시스템 Scion을 만들어 옮겼는데, Scion은 공개하지 않았어요.
gitai는 그 글을 읽은 개인 개발자가 10월 15일에 공개한 구현이에요. MIT 라이선스 오픈소스이고, 10월 20일에 0.3.0이 나왔어요. 앤트로픽과는 관계없는 프로젝트예요.
10월 19일 사내 AX 스프린트 스레드에 최하영 님이 이 주제를 사례글 후보로 올렸어요(요청 일부).
에이전트 여러 대가 동시에 커밋하는 상황을 위한 버전 관리. 데모로 기존 git과 비교, 우리 규모에 필요한지 판단
git은 먼저 온 1명만 받고, gitai는 서버가 줄을 세워요
차이를 보려면 용어 셋만 알면 돼요.
main: 모두가 함께 쓰는 최신 코드
커밋: 내가 고친 내용 한 묶음
push: 내 커밋을 main에 올리는 일
git에서 에이전트 둘이 동시에 push하면 먼저 도착한 1명만 통과해요. 늦은 쪽은 거절당하고, 그사이 바뀐 main을 다시 받아 와 내 커밋을 그 위에 다시 얹은 다음(rebase) 또 push해요. 50명이 동시에 이러면 매번 1명만 통과하고 나머지는 계속 밀려요.
gitai에서는 에이전트가 push 대신 커밋을 서버에 제출만 해요. 서버가 비슷한 때 들어온 커밋을 모아 순서를 정하고, main을 한 번에 바꿔요. gitai 문서는 이걸 일괄 착지(batched landing)라고 부르고, 기본으로 켜져 있어요.
▲ 에이전트 50명이 250건을 동시에 올렸을 때 git과 gitai의 처리 흐름과 결과, git 100건과 gitai 250건 (2026년 10월 21일, 애플 M5 맥북에서 제가 잰 값)
같은 곳을 고친 커밋은 해결기가 합쳐요
두 에이전트가 같은 파일의 같은 줄을 고치면 충돌이 나요. git은 이걸 사람이나 에이전트가 직접 풀어야 해요.
gitai는 서버에 충돌 해결기를 붙일 수 있어요. 정해 둔 규칙으로 합치는 프로그램이나 LLM 중에서 고르고, 기본값은 꺼짐이에요. LLM이 합 친 결과는 내가 정한 테스트를 통과해야 반영되고, 통과하지 못하면 에이전트에게 돌려보내요.
그 밖에 필요한 파일만 받아 쓰기, 에이전트별 권한, 반영 뒤 자동 테스트 같은 기능도 있어요. 반대로 웹 화면, 이슈, PR 리뷰 흐름, CI는 없어요(저장소의 한계 문서, 2026년 10월 21일 확인). 그래서 깃허브(GitHub) 대신 쓰기는 어렵고, 에이전트가 코드를 주고받는 Git 서버 하나로 보면 맞아요.
실험: 같은 맥에서 git과 gitai를 같은 조건으로 돌렸어요
실제 저장소는 건드리지 않고 데모로만 비교했어요. 스크립트는 클로드 코드가 짜고 돌렸고, 저는 무엇을 비교할지 정하고 "내 저장소만 말고 우리 팀 전체로 다시 재 봐"를 말하는 역할이었어요.
장비: 애플 M5 맥북(10코어, 32GB) 한 대, 2026년 10월 21일
부하: 에이전트 50명이 5건씩 250건, 10명이 5건씩 50건
충돌: 250건 중 20%인 50건은 일부러 같은 줄을 고침
git: 에이전트마다 따로 받아 push, 거절되면 rebase하고 다시 push, 20번까지
gitai: 기본 설정(일괄 착지 켬)에 단순한 충돌 해결기를 붙임
git 쪽은 우리 세션들이 평소 main에 올릴 때 하는 일과 같게 짰어요.
50명이면 git은 100건, gitai는 250건
에이전트 50명이 250건을 동시에 올리자 결과가 크게 갈렸어요.
git: 100건 반영. 1건 올리는 데 평균 8.2번 시도했고, 가장 늦은 1%는 24.8초 기다림
gitai: 250건 모두 반영. 모두 한 번에 들어갔고, 가장 늦은 1%는 9.4초 기다림
git이 못 올린 150건 중 114건은 충돌도 아니었어요. 20번을 다시 시도하는 동안 매번 다른 에이전트가 먼저 올려 서 밀려나다 포기한 거예요. gitai는 서버가 순서를 정하니 이런 자리싸움이 없어요.
▲ 같은 맥에서 돌린 실제 출력. landed는 반영된 건수, gaveup은 20번 밀려 포기한 건수예요. git 쪽은 10월 22일에 한 번 더 돌린 회차라 102건이고, 회차마다 100건 안팎으로 달라요
10명이면 git도 43건을 올렸어요
에이전트를 10명으로 줄이자 git도 50건 중 43건을 올렸고, 가장 늦은 1%도 3초면 들어갔어요. gitai는 50건을 다 올렸지만, 차이는 7건이었어요(같은 날 같은 맥에서 잰 값).
▲ 에이전트 10명과 50명일 때 main에 올린 건수. "gitai 켬"은 기본 설정에 충돌 해결기를 붙인 값, "gitai 끔"은 일괄 착지를 일부러 끈 값이에요(2026년 10월 21일, 제 맥에서 잰 값)
차이를 만든 건 일괄 착지 하나였어요
일괄 착지를 일부러 끄고 다시 돌려 봤어요. 그러자 gitai도 50명일 때 109건만 올려서 git과 비슷해졌어요. 1건 올리는 데 평균 26.2번을 시도해, 오히려 git(8.2번)보다 많이 다시 시도했어요.
서버가 모아서 넣지 않으면 에이전트끼리 먼저 넣으려고 다투는 건 git과 똑같거든요. 반대로 일괄 착지만 켜고 해결기는 끈 경우 50명일 때 200건을 올렸어요. 충돌 50건만 빼고 다 들어간 거예요.
우리 팀은 10분에 최대 2명이었어요
처음엔 제 저장소 하나만 쟀는데, 최근 30일 반영된 PR 60건 중 59건이 제 것이라 여럿이 같이 고치는 상황을 보여 주지 못했어요. 그래서 조직에서 커밋이 가장 많은 저장소 4곳으로 넓혔어요.
기준은 "10분 안에 서로 다른 사람이 몇 명 올렸나"예요. 자리싸움은 같은 순간에 몰릴 때만 생기니까, 하루 커밋 수보다 이게 중요해요. 2026년 9월 21일부터 10월 20일까지 main 커밋으로 제가 잰 값이에요.
가장 바쁜 저장소: 30일 커밋 770개, 작성자 5명, 하루 최대 63개, 한 시간 최대 20개
나머지 3곳: 30일 커밋 134개에서 224개, 한 시간 최대 11개에서 18개
10분 안 서로 다른 작성자: 4곳 모두 최대 2명
데모에서 git이 확실히 무너진 건 50명일 때였어요. 우리 팀은 10명 조건보다도 훨씬 한가해서, 지금 gitai로 옮겨도 얻는 게 거의 없어요.
해결기가 아직 못 푸는 충돌도 있어요
이번에 충돌 50건을 다 합친 해결기는 아주 단순한 규칙이었어요. 두 커밋이 같은 기록 파일에 줄을 하나씩 추가하면 두 줄을 다 남기는 규칙이에요.
실제 코드에서 두 사람이 같은 함수를 다르게 고치면 이 규칙으로는 못 풀어요. LLM 해결기를 붙여야 하는데, 그 결과가 맞는지는 이번 데모로 확인하지 못했어요.
우리 팀이 실제로 겪은 사고도 이쪽이었어요. git이 문제없이 합쳐 줬는데 같은 함수의 다른 줄끼리 안 맞아 버그가 난 경우, 오래된 코드 위에서 작업하다 남이 넣은 코드를 지울 뻔한 경우예요. 글자가 겹친 충돌이 아니라서 gitai도 잡지 못해요.
따라 하는 순서
저장소 최근 30일 main 커밋에서 "10분 안 서로 다른 작성자 수" 최댓값을 구해요
그 숫자가 10명 아래면 여기서 멈춰도 돼요. 우리 팀은 2명이라 여기서 판단이 끝났어요
10명 가까이 나오면 그 숫자로 git 데모와 gitai 벤치마크를 같은 조건으로 돌려요
gitai는 기본 설정 그대로 비교해요. 일괄 착지를 끄면 git과 다를 게 없어요
저는 클로드 코드에 저장소 이름을 주고 이렇게 시작했어요.
최근 30일 main 커밋을 gh api로 뽑아서
하루 최대, 한 시간 최대, 10분 창마다 서로 다른 작성자 수 최댓값을 구해줘.
그다음 같은 숫자의 에이전트가 동시에 push하는 git 데모와
gitai 벤치마크를 같은 조건으로 돌려서 비교해줘.
정리하면
gitai는 에이전트 수십 명이 한 저장소에 몰릴 때 확실히 강했어요. 50명 데모에서 git이 100건을 올릴 때 gitai는 250건을 다 올렸어요. 비결은 서버가 커밋을 모아 한 번에 넣는 일괄 착지였어요.
그런데 우리 팀은 가장 바쁜 저장소도 10분 안 동시 작성자가 2명이라, 지금은 git으로 충분해요.
10분 안에 10명 정도가 동시에 올리는 일이 잦아지면 다시 꺼낼 거고, 그때 먼저 볼 건 LLM 해결기가 실제 코드 충돌을 제대로 합치는지예요. 새 도구를 들이기 전에 우리 커밋 기록부터 세어 보세요!
참고한 자료(2026년 10월 21일 확인)
Redesigning source control at Anthropic, 앤트로픽 엔지니어링 블로그
feder-cr/git-ai, gitai 공개 저장소
지피터스가 사내 AX를 어떻게 하는지는 지피터스는 사내 AX를 어떻게 할까에 모아 두었어요.
