앤트로픽은 10월 13일 엔지니어링 회고를 공개하고, 5개월에 걸쳐 모노레포 전체를 git에서 자체 개발한 버전 관리 시스템 Scion으로 옮겼다고 밝혔다. 같은 기간 코드 리뷰 도구 Antique도 함께 만들었다. 핵심 팀은 7명뿐이었다.
계기는 머지 건수였다. 2026년 5월 앤트로픽 모노레포의 하루 머지는 약 2,500건이었는데, 9월에는 3만 건을 넘어섰다. 회고에는 이렇게 적혀 있다.
“As our merges per day grew more than tenfold, source control became our biggest development bottleneck.”
하루 머지 건수가 10배 넘게 늘면서 소스 관리가 우리의 가장 큰 개발 병목이 됐다.
코드를 짜는 일 자체는 더 이상 발목을 잡지 않았다. 막힌 곳은 소스 관리, 빌드, CI였다.
git이 버티지 못한 지점
앤트로픽은 몇 가지 수치를 제시했다. 트렁크 히스토리는 100GB에 가깝고, 압축한 작업 사본은 25GB가 넘으며, CI는 하루 약 2,500만 번 체크아웃을 수행한다. 매번 전체를 그대로 받으면 하루 git 트래픽이 600PB를 넘는다. 피크 때는 사내에서 수백 개의 git 미러를 돌렸고, 머지가 빨라질수록 미러와 사전 스냅샷을 유지하기가 점점 어려워졌다.
회고가 짚은 근본 원인은 설계 목표의 불일치다. git은 오프라인 환경에서 사람끼리 분산 협업하도록 만들어졌고, 모두가 저장소 전체를 손에 쥔다. 지금 앤트로픽의 주된 클라이언트는 항상 온라인 상태인 에이전트와 자동화 작업이다.
그래서 Scion은 발상을 뒤집었다. 히스토리, blame, 커밋, 머지, 리베이스를 모두 서버에 두고, 클라이언트에는 제한된 로컬 캐시와 작업 사본만 남겨 데이터를 필요할 때 가져온다. 커밋은 서버에서 끝나며 비용은 변경 크기에 따라 달라질 뿐 저장소 전체 크기와는 무관하다. 브랜치는 트렁크와 릴리스 브랜치만 남기고, 브랜치 포인터를 옮기는 일은 데이터베이스 한 행에 대한 compare-and-swap 한 번이다. 클라이언트는 로컬 데몬, 계층형 캐시, 마지막으로 서버 순으로 접근하며, 각 캐시 계층의 적중률은 99%를 넘는다.
숫자로 따져 보면
회고의 수치로 대략 계산해 보자. 600PB를 2,500만 번의 체크아웃으로 나누면 한 번에 약 24GB로, "작업 사본 25GB 초과"와 거의 맞아떨어진다. 600PB는 매번 전체를 받는다고 가정해 잡은 상한선으로 보인다.
3만 건의 머지를 24시간에 나누면 평균 분당 20건을 조금 넘는다. git의 푸시 모델에서는 푸시 전에 매번 원격과 먼저 동기화해야 하므로, 이 빈도에서는 충돌 재시도가 대기열을 막아 버린다. Scion은 머지를 서버로 옮겨 푸시 단계를 없앴다. 앤트로픽은 전역 머지 락도 없애고, 머지 후 배포 전 자동 테스트로 품질을 지키는 방식으로 바꿨으며, 동시 변경이 충돌하면 Claude가 고치게 했다.
회사 측 설명에 따른 성과는 다음과 같다. Scion 인프라의 CPU와 메모리 사용량은 기존 git 미러 클러스터보다 약 200배 적고, CI와 연구 작업의 체크아웃은 분 단위에서 초 단위로 줄었으며, CI만으로도 CPU 용량의 약 25%가 비었다.
Claude는 무엇을 했나
마이그레이션 자체에도 모델이 쓰였다. 초기에 손으로 짠 git-Scion 가져오기 파이프라인을 Claude Mythos Preview가 다시 작성해 메모리 사용량은 20분의 1로, 속도는 약 4배로 개선됐다. 회고에 따르면 Claude는 알고리즘 수준의 최적화도 찾아냈고 대량의 테스트, 시뮬레이션, 퍼징 테스트를 작성했다. 엔지니어의 일은 설계 의도를 쥐고, 부적절한 안을 걷어내고, 코드를 한 줄씩 읽는 대신 변경의 의도를 검토하는 쪽으로 바뀌었다.
Antique의 세부 내용은 회고에서 다루지 않았다. 승인에 의미 기반 규칙을 설정해 주석만 바꾸는 커밋과 민감한 로직을 건드리는 커밋을 구분하고, 사람의 리뷰를 후자에 집중시킬 수 있다는 설명이 전부다.
Scion은 오픈소스로 공개되지 않는다. 앤트로픽의 표현은 직설적이다. “Scion is by no means a suitable replacement for git for general use.” 내부 구성 요소의 맞춤화 정도가 너무 높아 다른 곳에 패키지로 내놓을 수 없다는 것이다. 회사는 GitHub, GitLab, 오픈소스 커뮤니티가 서버 측 RPC나 스파스 체크아웃 같은 아이디어를 참고해 git을 개선하기를 기대한다. 구글의 Piper와 메타가 오픈소스로 공개한 Sapling도 비슷한 길을 걸었는데, 이번에는 재작성을 밀어붙인 압력이 AI가 쓴 코드의 양에서 나왔다는 점이 다르다.
참고 출처: CocoLoop, 앤트로픽 엔지니어링 블로그. 하루 머지 건수, 체크아웃 횟수, 자원 사용 감소 배수는 앤트로픽이 밝힌 수치이며, 1회 체크아웃 용량은 해당 수치를 바탕으로 편집부가 대략 계산한 값입니다.