앤트로픽, 하루 3만 건 병합에 맞춰 모노레포를 Scion으로 이전

앤트로픽은 2026년 5월 하루 평균 약 2,500건이던 내부 모노레포의 코드 변경 병합량이 9월에는 하루 3만 건을 넘었다고 밝혔습니다. 회사는 이 작업량을 지원하려고 자체 버전관리 시스템 Scion을 만들고, 5개월에 걸쳐 모노레포를 Git에서 이전했습니다. Scion 설계의 출발점은 오프라인 작업을 지원하는 Git의 복제 모델보다, 상시 연결된 에이전트와 작업이 저장소에서 필요한 자료만 요청하는 구조가 내부 환경에 맞는다는 판단입니다.

Git의 일반적인 복제본은 저장소 전체를 갖춰 오프라인에서도 변경 비교, 파일 이력과 blame 조회, 특정 버전의 체크아웃을 할 수 있습니다. 앤트로픽 모노레포의 메인 브랜치 이력은 거의 100GB이고 압축된 작업 복사본은 25GB가 넘습니다. 회사는 개발 환경과 에이전트 샌드박스, 연구 작업을 제외하고도 CI가 하루 약 2,500만 번 코드를 체크아웃한다고 집계했습니다. 저장소를 매번 통째로 가져오는 방식으로 계산하면 하루 전송량이 600PB를 넘을 수 있다는 추산도 제시했습니다. 실제 전송량이 아니라 단순 복제를 가정한 계산입니다.

앤트로픽은 얕은 복제와 부분 체크아웃 같은 Git 기능에 더해 내부 미러와 저장소 스냅샷도 운영했습니다. 미러는 한때 수백 개에 달했습니다. 하지만 병합량이 늘면서 스냅샷이 최신 브랜치에서 더 멀어졌고, 부분 복제본에서 diff나 blame처럼 과거 이력에 의존하는 작업을 유지하기도 까다로워졌다고 회사는 설명했습니다. 실제 내부 운영에서는 기준 저장소 하나를 두고 에이전트와 작업이 온라인으로 접속하는 경우가 대부분이었습니다. 각 클라이언트가 오프라인 작업을 위해 저장소 전체를 갖추는 Git의 특성이 이 환경에서는 데이터 부담으로 이어졌습니다.

Scion은 서버와 클라이언트의 역할을 나눕니다. 서버가 파일 이력과 변경자를 조회하고, 커밋·병합·리베이스를 처리합니다. 클라이언트는 제한된 로컬 객체 캐시를 관리하고 작업 복사본을 디스크에 구성하며 파일 변경을 감시합니다. 클라이언트는 필요한 데이터를 서버에 요청해 사용하고, 서버에도 저장소 전체를 온전히 펼친 사본을 두지 않습니다. 데이터는 분산해 저장하고 각 구성요소가 맡은 작업에 필요한 정보만 전달하는 방식입니다.

Scion의 변경 단위는 쓰기 전 기록(write-ahead log)에 추가되는 changeset입니다. Git 커밋이 파일 트리를 가리키는 것과 달리, changeset에는 첫 번째 부모와 비교해 달라진 파일 목록을 기록하고 파일 내용은 콘텐츠 주소가 붙은 압축 객체로 저장합니다. changeset은 서버에서 만들어져 즉시 공유됩니다. 앤트로픽은 이 구조로 변경을 받아들이는 과정에서 대용량 packfile 처리나 서버 간 조정, 잠금이 필요하지 않아 높은 병합 처리량을 낼 수 있다고 설명했습니다.

변경 목록만으로는 파일의 이전 변경자나 경로의 과거 이력 같은 질문에 빠르게 답하기 어렵습니다. Scion은 blame, 경로 이력, 커밋 그래프를 위한 색인 등 파생 데이터를 changeset과 별도로 계산합니다. 각 파생 데이터는 부모 changeset의 값을 바탕으로 계산되며, 작업 속도를 높일 정보를 미리 만들지 나중에 계산할지도 종류별로 정할 수 있습니다. 따라서 쓰이지 않는 정보를 전부 저장하는 대신 필요한 색인과 데이터를 작업에 맞춰 관리할 수 있습니다.

이 구조는 CI가 저장소를 쓰는 방식도 바꿉니다. 커밋과 병합 기준 사이의 차이나 파일 이력만 필요한 작업은 Scion 서버 API에 질의해 답을 받을 수 있어 로컬 저장소를 준비할 필요가 없습니다. 실제 파일이 필요한 경우에는 클라이언트가 요청한 디렉터리의 트리와 파일 객체를 가져옵니다. 일부 디렉터리만 구성하는 sparse checkout과 파일을 읽을 때 가져오는 가상 체크아웃도 같은 요청 방식으로 동작합니다.

파일을 가져올 때 Scion 클라이언트는 서버에 자신이 가진 객체 목록을 보내 맞추는 대신, 필요한 트리와 파일 객체를 요청합니다. 클라이언트는 루트 트리부터 로컬에 없는 객체를 재귀적으로 찾아 요청하고, 각 객체는 내용이 바뀌지 않는 주소를 사용하므로 여러 계층의 캐시가 응답할 수 있습니다. 단일 대용량 파일을 내려받는 방식도 아니어서 요청을 나눠 이어받을 수 있습니다. 클라이언트가 원하지 않는 디렉터리의 트리를 요청하지 않으면 부분 체크아웃도 별도 전송 프로토콜 없이 처리됩니다.

앤트로픽의 내부 환경에서는 각 노드의 scion-daemon이 객체를 저장해 같은 컴퓨터에서 실행되는 작업끼리 공유합니다. 데몬은 주기적으로 갱신되는 스냅샷에서 시작해 해당 지역의 scion-cache에 객체를 요청하고, 캐시에 객체가 없으면 scion-server가 Spanner나 클라우드 저장소에서 가져옵니다. 각 계층은 같은 요청 형식으로 동작하지만, 회사는 장애가 지역 캐시에서 상위 서버로 번지지 않도록 계층 간 연결을 제한한다고 밝혔습니다.

앤트로픽은 각 계층의 캐시 적중률이 99%를 넘고, CPU·메모리 요구량 기준 Scion 인프라가 이전 Git 미러링 인프라의 200분의 1 수준이라고 보고했습니다. CI와 연구 작업의 체크아웃 시간은 기존 분 단위에서 초 단위로 줄어 약 100배 빨라졌으며, CI에서는 CPU 처리 여력이 25% 늘었다고 밝혔습니다. 이 수치는 회사 내부 저장소와 기존 미러링 시스템을 비교한 운영 결과입니다.

병합 대기열 운영도 달라졌습니다. 앤트로픽은 수백에서 수천 건의 변경이 테스트 중에도 병합되는 환경에서, 저장소 전체에 잠금을 두는 기존 방식의 병합 대기열을 효과적으로 적용하지 못했다고 설명했습니다. 대신 병합 후와 배포 전에 자동 테스트를 실행하는 데 투자했습니다. 이 운영 방식에서는 변경끼리 충돌할 수 있으며, 회사는 Claude가 대개 사람이 충돌을 알아차리는 데 걸리는 시간보다 빨리 해결한다고 전했습니다.

앤트로픽은 Scion을 일반 저장소에서 Git을 대체할 범용 제품으로 소개하지 않았습니다. 회사는 수만 명의 엔지니어나 많은 에이전트가 코드를 작성하는 초대형 모노레포에 이 설계가 맞을 수 있다고 설명했습니다. 내부 운영에 투입하는 토큰 규모도 다른 기업이 현실적으로 감당하려는 수준을 훨씬 넘는다고 덧붙였습니다. Git과 크게 다른 시스템인 만큼 도입하려면 코드 리뷰, 코드 검색, CI를 비롯한 개발 과정의 여러 구성요소도 함께 이전해야 합니다. 앤트로픽이 만든 관련 도구도 자사 환경에 맞춰져 있어 다른 조직이 그대로 적용하기 어렵다고 밝혔습니다.