Redesigning source control at Anthropic

Anthropic 엔지니어링 블로그 글의 앞부분부터 'Scaling Scion' 절까지 읽고 옮겼어요. 글이 길어 뒷부분(마이그레이션 과정 등)은 다루지 못했어요.

병목이 바뀌었다

Anthropic에서는 이제 코드 작성이 병목이 아니에요. Claude가 연구 루프를 스스로 돌리고 복잡한 프로그램을 최적화하고 새 서비스를 처음부터 만들어요. 병목은 사람 규모에 맞춰 만든 개발 인프라, 즉 소스 관리, 빌드, CI로 옮겨 갔어요.

• 2026년 5월 하루 평균 병합 약 2,500건 → 9월 하루 30,000건 이상
• 병합 수요는 사실상 무한하고, 병목을 하나 없애면 곧바로 코드가 더 늘어난다고 해요.

그래서 자체 버전 관리 시스템 Scion을 만들고 모노레포를 git에서 5개월 만에 완전히 옮겼어요. 같은 기간에 코드 리뷰 도구(Antique), 코드 검색, 소스 관리 IAM 등도 만들었어요. 글쓴이들은 Claude의 코드 작성 능력이 이 상황을 만든 원인이자 빠르게 해결한 수단이었다고 말해요.

git이 맞지 않게 된 이유

• main 브랜치 히스토리만 거의 100GB, 압축된 작업 사본이 25GB 이상이에요.
• CI만으로 하루 약 2,500만 번 체크아웃해요. 단순하게 받으면 하루 git 트래픽이 600PB가 넘어요.
• 얕은 클론, sparse checkout, promisor remote, 내부 미러, blob 저장소 스냅샷(seed)을 다 썼고, 한때 내부 git 미러를 수백 대 운영했지만 병합 속도가 오르면서 운영이 점점 어려워졌어요.

결국 대부분 회사처럼 git을 '권위 있는 사본 하나'를 둔 중앙집중 시스템으로 쓰고 있었고, 클라이언트 대부분은 원래 온라인인 에이전트와 잡이었어요. git의 오프라인·분산 장점이 오히려 확장을 막고 있었던 거예요.

에이전트 규모 소스 관리 원칙

Google Piper, Meta Sapling 같은 선례를 참고해 이런 원칙을 세웠어요.

1. 클라이언트는 항상 온라인: 서버가 늘 닿는다고 보고, 필요할 때 데이터를 가져와요.
2. 클라이언트-서버 비대칭: 히스토리·blame 조회, 커밋 생성, 병합·리베이스를 서버가 해요. 클라이언트는 계산을 거의 안 하는 대신 로컬 데이터가 훨씬 적어요. 모든 질의가 API로도 열려 있어 많은 잡은 로컬 저장소가 아예 필요 없어요. 자동 bisect·revert 파이프라인도 이 덕분에 가능했어요.
3. 모든 것이 수평 확장: 저장소 데이터가 분산돼 있고, 서버에도 완전한 사본이 없어요. packfile 개념이 없어 저장소 유지 보수도 필요 없어요.
4. 커밋은 싸고 증분적이며 락이 없어야: 모든 커밋·리베이스·병합이 서버에서 일어나므로 push가 없어요. 비용이 저장소 크기가 아니라 변경 크기에 비례해야 해요. 모든 서버가 합의해야 하는 전역 상태가 문제라 main과 릴리스 브랜치 외에는 ref 사용을 권하지 않아요.
5. 작업 사본은 선택이고 기본이 sparse: 머지 베이스와의 diff 같은 건 서버에 물어보면 되고, 쓰기도 API로 가능해요. 필요하면 요청한 디렉터리만 담는 sparse checkout이나 파일을 그때그때 만드는 가상 체크아웃을 써요.

데이터 구조

Scion의 작업 단위는 write-ahead log 항목인 changeset이에요. git 커밋이 트리 포인터를 저장한다면, changeset은 첫 번째 부모 대비 바뀐 파일 목록과 blob 저장소의 압축 콘텐츠를 가리키는 콘텐츠 주소를 저장해요. packfile, 락, 서버 간 조정, ref 이동이 없어 아주 높은 처리량으로 받을 수 있어요. ref 이동은 Spanner 행 하나에 대한 compare-and-swap이에요.

blame이나 경로 히스토리 같은 질문에는 changeset에서 만든 파생 데이터(derived data)를 써요. 각 파생 데이터는 부모의 값에서 재귀적으로 계산되는 하나의 일반 메커니즘으로 정의돼서, 새 유형을 쉽게 추가하고, 즉시 계산할지 미룰지 고르고, 클라이언트를 바꾸지 않고 최적화할 수 있어요.

확장 구조

• 데이터가 모두 콘텐츠 주소 방식이라 한번 저장되면 바뀌지 않아, 어느 서버든 확인 없이 캐시할 수 있어요.
• scn 클라이언트는 서버에 '내가 가진 것'을 알리지 않고, 루트 트리부터 필요한 트리와 blob만 재귀적으로 요청해요. 요청이 모두 불변 객체라 어떤 캐시든 답할 수 있고, 거대한 packfile 응답이 없어 재개도 쉬워요.
• 노드마다 scion-daemon이 객체를 저장하고, 지역 캐시 scion-cache, 권위 서버 scion-server로 계층을 엄격히 나눠 장애 영역을 격리해요.
• 각 계층의 캐시 적중률은 99% 이상이고, 인프라는 이전 git 미러 대비 CPU·메모리 기준 200배 작아졌어요. CI와 연구 잡의 체크아웃은 두 자릿수 배 빨라졌다고 해요.