Anthropic이 git을 버리고 자체 소스 관리 Scion으로 옮겼다: 하루 병합 2,500건에서 3만 건으로 12배, 체크아웃은 분에서 초로

Anthropic이 10월 13일 엔지니어링 블로그에서 자사 모노레포를 git에서 직접 만든 소스 관리 시스템 Scion으로 옮겼다고 밝혔다. 하루 병합 건수가 2026년 5월 약 2,500건에서 9월 3만 건 이상으로 약 12배 뛰었고 소스 관리가 "가장 큰 개발 병목"이 됐다.

한 줄 정리

Anthropic은 에이전트가 하루 3만 건 넘게 병합하는 규모에서 git을 버리고 서버가 일을 맡는 시스템으로 갈아탔고 사람 속도에 맞춘 공유 도구는 에이전트가 붙는 순간 먼저 막힌다.

한눈에 보기

하루 병합 건수	약 2,500건(5월) → 3만 건 이상(9월)
하루 CI 체크아웃	약 2,500만 건
메인 브랜치 이력	100GB에 가까움
압축 작업 복사본	25GB 이상
git으로 전부 받을 때 하루 트래픽	600PB 이상
CPU·메모리 사용량	기존 미러 방식의 200분의 1
CI·연구용 체크아웃	분 단위에서 초 단위로
CI CPU 여력	25% 증가
개발 인원과 기간	7명, 이전에 5개월

git이 막힌 지점

git은 오프라인 클론을 전제로 한 분산 구조다. 비행기 안에서도 커밋하는 개발자에게 맞는 설계다. Anthropic의 클라이언트는 다르다. 항상 연결된 에이전트와 CI 작업이 대부분이라 분산의 이점은 사라지고 오버헤드만 남는다.

메인 브랜치 이력은 100GB에 가깝고 압축한 작업 복사본만 25GB를 넘는다. 하루 CI 체크아웃이 약 2,500만 건이라 전부 git으로 받으면 하루 600PB가 오간다. 이를 피하려고 피크에는 내부 git 미러를 수백 대 돌렸고 그 미러가 다시 용량 문제를 만들었다.

서버로 넘긴 일

Scion은 이력 조회, blame, 커밋, 병합, 리베이스를 서버가 처리한다. 클라이언트는 필요한 만큼만 가져와 제한된 로컬 캐시와 작업 파일만 들고 있다. 작업 단위는 서버에서 만들어지는 changeset이고 쓰기 선행 로그의 한 항목으로 쌓인다.

소스 관리 질의를 API로 열었기 때문에 CI 작업 상당수가 로컬 저장소 없이 돈다. 팩파일이 없어 저장소 유지보수 작업도 없다. 커밋과 리베이스와 병합은 서버에서 잠금 없이 싸게 돌아간다. 캐시 계층별 적중률은 99%를 넘는다.

수집 단계를 다시 쓴 코드는 Claude Mythos Preview가 만든 버전이 메모리를 20분의 1만 쓰고 4배 빨랐다고 한다. 7명이 Scion과 코드 리뷰 도구 Antique, 코드 검색, 권한 관리 시스템까지 함께 만들었다.

병목은 한 층씩 옮겨 간다

12배라는 숫자는 에이전트가 코드를 더 많이 쓴다는 이야기로 끝나지 않는다. 코드가 늘면 병합이 늘고 병합이 늘면 체크아웃이 늘고 체크아웃이 늘면 미러 서버가 모자란다. Anthropic은 이 사슬을 한 번에 끊으려고 소스 관리만이 아니라 코드 리뷰 도구 Antique와 코드 검색과 권한 관리를 같이 새로 만들었다. 한 층을 고치면 바로 위층이 다음 병목이 되는 구조라 부분 수리로는 따라가지 못했다는 뜻이다.

사람이 일하던 시절의 도구에는 암묵적 속도 제한이 있었다. 개발자 한 명이 하루에 올릴 수 있는 변경은 손으로 쓰는 속도에 묶여 있었고 모든 시스템이 그 속도를 전제로 용량을 잡았다. 에이전트는 그 제한을 풀어 버렸다. 풀린 제한 뒤에서 가장 먼저 비명을 지른 곳이 소스 관리였고 Anthropic은 그것을 가장 먼저 눈에 띈 증상으로 기록했다.

Anthropic의 선택은 "git을 고쳐 쓴다"가 아니라 "git이 전제한 사용자를 바꾼다"였다. 서버가 상태를 쥐고 클라이언트는 얇아지는 쪽이다. 규모가 다를 뿐 이 방향은 낯설지 않다. 팀이 쓰는 문서 도구나 광고 관리자도 결국 사람이 직접 클릭하는 화면 대신 API로 부르는 쪽이 에이전트에게 맞다.

범용 대체재가 아니다

Anthropic은 Scion이 "git의 범용 대체재가 아니다"라고 선을 긋는다. 수만 명 규모 엔지니어링 조직이나 에이전트 활동이 많은 거대 모노레포를 겨냥했고 구성요소가 회사 내부 인프라에 묶여 있어 공개 배포 가능성도 낮다. 도입하려면 코드 리뷰, 검색, CI까지 개발 수명주기 전체를 옮겨야 한다. 대신 서버 측 RPC나 조합 가능한 sparse·shallow 기능 같은 아이디어는 git 플랫폼이 가져갈 수 있다고 적었다.

이전에 걸린 시간과 사람

수치에서 눈에 띄는 건 인력이다. Scion과 Antique와 관련 시스템을 7명이 만들었고 모노레포 이전은 5개월에 끝났다. 하루 병합이 12배 늘어난 조직이 개발 수명주기 전체를 갈아엎는 데 든 인력이 두 자릿수가 안 된다. 같은 글에서 수집 단계 재작성은 Claude Mythos Preview가 만든 버전이 채택됐다. 병목을 만든 에이전트가 병목을 푸는 코드도 쓴 셈이다.

반대로 이전 비용도 숨기지 않았다. 코드 리뷰, 검색, CI까지 전부 옮겨야 하고 구성요소가 내부 인프라에 묶여 있어 공개해도 쓸 곳이 많지 않다고 Anthropic 스스로 적었다. 그래서 이 글의 값어치는 도구가 아니라 판단 순서에 있다. 먼저 어디가 막히는지 측정하고 그 층을 에이전트 전제로 다시 설계한다.

위시클레이 관점

직원 5~30명 팀이 git을 갈아엎을 일은 없다. 가져갈 건 숫자 12배가 처음 터진 위치다. 모델 요금도 코드 품질도 아니고 여러 갈래의 작업이 하나로 합쳐지는 문이었다.

콘텐츠 에이전시에 에이전트 열 개를 붙이면 같은 일이 작게 벌어진다. 주간 블로그 40편의 초안은 오후 한나절에 나오지만 편집장 한 명이 승인하는 큐와 같은 브랜드 템플릿 파일, 같은 광고 계정의 변경 권한이 그대로 남는다. 초안이 열 배 빨라진 만큼 줄은 열 배 길어진다. 하루 3만 번 부딪히는 구조에서는 사람 한 명이 차례로 여는 문 하나가 곧 전체 처리량이다.

Anthropic이 5개월에 7명을 쏟아 시스템을 새로 만든 건 그 문을 넓히는 비용이 그만큼 든다는 뜻이기도 하다. 작은 팀의 순서는 반대다. 에이전트를 늘리기 전에 우리 일에서 "한 사람이 순서대로 여는 문"을 목록으로 적는다. 공유 드라이브 폴더, 발행 승인, 결제 수단, 고객 응대 계정 정도가 먼저 나온다. 열 개짜리 에이전트 팀의 속도는 그중 가장 좁은 문이 정한다.