앤트로픽의 자체 버전관리 시스템 Scion

앤트로픽이 에이전트가 쏟아내는 코드량에 git이 더는 버티지 못하자 자체 버전관리 시스템 Scion을 만들어 5개월 만에 모노레포를 통째로 옮겼다고 밝혔다. 기준 시점: 2026-10-13

무슨 일인가

앤트로픽 엔지니어링 블로그에 따르면, 머지되는 코드 변경량이 2026년 5월 하루 약 2,500건에서 9월 하루 30,000건 이상으로 늘었다. 모노레포의 main 브랜치 히스토리는 거의 100GB, 압축된 워킹 카피도 25GB를 넘는다. CI는 하루 약 2,500만 번의 체크아웃을 수행하는데, 이를 그대로 git으로 처리하면 하루 600PB가 넘는 트래픽이 발생한다고 한다. shallow clone, sparse checkout, promisor remote 같은 기존 우회책과 수백 개의 내부 git 미러로 버텨왔지만 머지량이 늘수록 운영이 힘들어졌다.

이 문제를 풀기 위해 7명으로 구성된 팀이 5개월 동안 자체 버전관리 시스템 Scion을 만들어 모노레포 전체를 git에서 이전했다. 같은 기간에 코드 리뷰 도구 Antique, 코드 검색, 소스 제어용 IAM 시스템도 함께 만들었다. Scion은 클라이언트가 항상 온라인이라고 가정하고 필요한 트리·블롭만 그때그때 가져오며, 커밋·머지·리베이스 같은 무거운 연산은 서버에서 처리하고 클라이언트는 제한된 로컬 캐시만 둔다. 변경의 단위는 git의 트리 전체 포인터 대신 변경된 파일만 담는 write-ahead log 엔트리인 "changeset"이고, ref를 옮기는 작업은 Spanner 레코드 하나에 대한 compare-and-swap으로 처리한다.

결과로 Scion 인프라는 기존 git 미러링 대비 CPU·메모리를 약 200배 덜 쓰고, CI·연구용 체크아웃은 분 단위에서 초 단위로 줄었으며 CI만으로 CPU 용량 25%를 확보했다고 밝혔다. 각 캐시 티어의 적중률은 99% 이상이라고 한다.

왜 중요한가

이 사례는 "에이전트가 코드를 더 많이, 더 빠르게 만들어낸다"는 말이 실제로 어떤 인프라 압박으로 이어지는지 보여준다. 사람 하나가 하루에 만드는 커밋 수를 가정하고 설계된 git·CI 파이프라인은, 에이전트가 동시에 대량으로 커밋을 밀어넣는 환경에서 그 가정부터 깨진다. 또한 이 이전 작업 자체에 Claude를 투입해 git-to-Scion 변환 파이프라인을 다시 쓰게 했더니 메모리를 20배 덜 쓰고 4배 빠르게 동작했다고 밝힌 점, 그리고 전역 머지 락 대신 사후 테스트·배포 전 테스트로 전환했다는 점은 에이전트가 많아질수록 "사람 속도에 맞춘 안전장치"를 다시 설계해야 한다는 신호다.

짚고 갈 개념

내 생각

이 글에서 가장 흥미로운 지점은 "에이전트가 글을 많이 쓴다"가 아니라 "에이전트가 글을 쓰는 속도가 사람이 그 글을 리뷰하고 머지 충돌을 감지하는 속도를 앞질렀다"는 쪽으로 보인다. 글쓴이들이 전역 머지 락을 포기하고 사후 테스트로 넘어간 것도, 결국 "사람이 미리 막는" 모델에서 "빠르게 고치는" 모델로 바뀐 것으로 읽힌다. 다만 앤트로픽 스스로도 Scion을 범용 git 대체재로 공개할 계획은 없다고 밝힌 만큼, 이 사례의 일반화 가능성은 조직의 머지 규모와 에이전트 투입 정도에 따라 꽤 다를 것으로 보인다.

출처

CSLOG에서 보기