AI가 코드를 너무 많이 쓰면 git이 막힌다
안녕하세요! 재니미입니다.
Anthropic이 사내 소스 관리를 git에서 자체 시스템인 Scion으로 옮겼다는 글을 공개했습니다. Claude가 코드를 워낙 많이 쓰다 보니 코드를 쓰는 것보다 코드를 저장하고 꺼내는 쪽이 먼저 막혔다는 이야기입니다. 핵심은 전제 하나를 바꾼 데 있습니다. git은 오프라인에서도 일할 수 있게 만든 도구인데, 정작 저장소를 쓰는 건 대부분 항상 온라인인 에이전트였습니다. 이번 편에서는 git이 왜 병목이 됐는지와 Scion이 무엇을 다르게 설계했는지를 정리했습니다.
이 글은 Anthropic 엔지니어링 블로그 글 Redesigning source control at Anthropic을 읽고 정리한 것입니다. 수치는 모두 원문에 실린 Anthropic 자체 발표입니다.
넉 달 만에 병합이 열 배
Anthropic의 하루 평균 코드 병합 건수는 2026년 5월에 약 2,500건이었습니다. 9월에는 30,000건을 넘었습니다. 원문은 이 증가세가 쉽게 꺾이지 않을 거라고 봅니다. 병목을 하나 없앨 때마다 그만큼 코드가 더 나온다는 겁니다.
저장소 규모도 같이 커졌습니다.
- main 브랜치 기록만 약 100GB입니다.
- 압축한 작업 사본 하나가 25GB를 넘습니다.
- CI에서만 하루에 약 2,500만 번 코드를 체크아웃합니다. 개발 환경이나 에이전트 샌드박스는 뺀 숫자입니다.
이걸 그대로 git으로 받으면 하루 트래픽이 600PB를 넘는다고 합니다.
git으로 버텨 본 방법들
git에도 큰 저장소를 다루는 방법은 있습니다. 기록 일부만 받는 얕은 클론, 필요한 폴더만 받는 부분 체크아웃, 사내 git 미러, 미리 만들어 둔 저장소 스냅샷 같은 것들입니다. Anthropic은 이걸 다 썼고, 가장 많을 때는 사내 git 미러를 수백 대 돌렸습니다.
시간은 벌었지만 병합이 늘수록 운영이 어려워졌습니다. 스냅샷은 갱신하는 사이에 main과 점점 멀어졌고, 일부만 받은 저장소에서 diff나 blame처럼 기록이 필요한 작업을 계속 돌아가게 하는 데 손이 점점 더 많이 갔습니다.
전제가 맞지 않았다
git은 분산 시스템입니다. 모든 클론이 저장소 전체를 갖고 있어서, 인터넷이 끊겨도 기록을 보고 diff를 계산하고 아무 버전이나 꺼낼 수 있습니다. 대부분의 저장소에는 이게 맞는 설계입니다.
그런데 Anthropic은 다른 회사들처럼 git을 사실상 중앙 저장소 하나를 두고 썼습니다. 그리고 저장소를 쓰는 쪽은 거의 다 에이전트와 CI 작업이었습니다. 이들은 애초에 항상 온라인입니다. 오프라인 작업을 위한 git의 장점이 오히려 저장소가 커질수록 발목을 잡고 있었던 겁니다. 그래서 원문은 이렇게 질문을 바꿉니다. 처음부터 에이전트가 항상 온라인이라는 걸 전제로 소스 관리를 설계하면 어떤 모양이 될까?
Scion이 다르게 한 것
Google의 Piper, Meta의 Sapling처럼 거대한 모노레포를 위한 선례가 있어서, Scion은 그 경험을 참고해 만들었습니다. 원문의 원칙을 git과 비교하면 이렇습니다.
| git | Scion | |
|---|---|---|
| 클라이언트 | 오프라인 작업을 위해 저장소 전체를 가짐 | 항상 온라인이라 필요할 때 받아 옴 |
| 역할 | 모든 클라이언트가 서버 역할도 할 수 있음 | 기록 조회, 커밋, 병합, 리베이스는 서버가 함 |
| 저장소에 질문하기 | 로컬 사본이 있어야 함 | 모든 질문을 API로 할 수 있음 |
| 커밋 | 로컬에서 커밋하고 푸시 | 서버에서 바로 만들어짐. 비용은 변경 크기에 비례 |
| 작업 사본 | 기본적으로 전체 | 선택 사항. 필요한 폴더만, 읽는 파일만 받음 |
API로 저장소에 질문할 수 있다는 점이 특히 큽니다. 예전에는 “이 줄을 마지막으로 고친 사람은 누구인가” 같은 질문 하나를 위해서도 CI 작업이 저장소 사본을 갖고 있어야 했습니다. 이제는 서버에 물어보면 됩니다. 원문은 자동으로 문제 커밋을 찾아 되돌리는 파이프라인도 이렇게 싸게 질문할 수 있어서 가능해졌다고 합니다.
내부 구조도 이 원칙을 따릅니다. 데이터는 내용으로 주소를 매겨서 한 번 저장되면 바뀌지 않습니다. 그래서 어느 서버든 다른 서버와 확인할 필요 없이 캐시할 수 있습니다. 요청은 노드의 데몬, 리전의 캐시 서버, 원본 서버 순서로 올라가고, 각 층의 캐시 적중률은 99%가 넘는다고 합니다.
결과
원문이 밝힌 결과는 이렇습니다.
- 인프라가 쓰는 CPU와 메모리가 예전 git 미러 대비 200분의 1로 줄었습니다.
- 체크아웃이 몇 분에서 몇 초로 100배 빨라졌습니다.
- CI에서만 CPU 용량이 25% 남게 됐습니다.
Anthropic만의 이야기일까
원문도 Scion이 일반적인 git 대체재는 아니라고 분명히 말합니다. 엔지니어가 수만 명이거나 에이전트 무리가 쉴 새 없이 코드를 쓰는 초대형 모노레포에서나 의미가 있다는 겁니다. 내부에서 토큰을 쓸 수 있는 규모도 다른 회사와는 비교가 안 된다고 덧붙입니다.
그래도 원문은 6~12개월 안에 다른 회사들도 비슷한 문제를 겪을 거라고 봅니다. 그래서 Scion을 공개하는 대신, git 서버 쪽에 이 아이디어를 적용할 수 있도록 생각을 나누고 GitHub, GitLab, 오픈소스 커뮤니티와 협력하고 싶다고 합니다.
인프라를 다루는 입장에서 제가 가장 와닿은 건 기술보다 질문 쪽이었습니다. 도구가 어떤 사용자를 전제로 만들어졌는지 다시 묻는 것만으로 설계가 통째로 바뀔 수 있다는 점입니다. 다음 편에서는 이 시스템을 일곱 명이 다섯 달 만에 만들면서 엔지니어의 역할이 어떻게 바뀌었는지를 다룹니다.
감사합니다.