Anthropic, AI 코딩으로 늘어난 변경량에 대응해 Git을 자체 버전 관리 시스템 Scion으로 교체

• AI 코딩으로 소스 관리와 빌드, CI가 병목이 되자
  자체 버전 관리 시스템 Scion을 개발하고 5개월 만에 모노레포를 Git에서 이전 - 하루 병합량은
  2026년 5월 평균 약 2,500건에서 9월 3만 건 이상으로 증가했으며, CI에서만 하루 약 2,500만 회 체크아웃 - 항상 온라인인 에이전트와 작업을 전제로
  커밋과 병합, 리베이스, 이력 조회를 서버에서 처리하고 클라이언트는 필요한 데이터만 가져오는 구조 - 기존 Git 미러 인프라 대비
  CPU와 메모리 요구량을 200분의 1로 축소. 내부 측정에서 에이전트의 새 작업 트리 생성은 7.1분에서 5.1초로 단축 7명 팀이 Scion과 코드 리뷰 도구 Antique, 관련 시스템을 구축했으며, 초대형 모노레포에서 얻은 설계 경험을 Git 생태계와 공유

AI 코딩으로 달라진 모노레포 규모

• Claude가 연구 루프를 반복하고 복잡한 프로그램을 최적화하며 새 서비스를 구현하면서, 코드 작성보다
  개발 인프라가 병목이 됨 - 하루 평균 병합량은 2026년 5월 약 2,500건이었으며, 9월에는 하루 3만 건 이상까지 증가
• 병목을 제거할 때마다 코드 생산량이 다시 늘었으며, Anthropic은 이러한 성장세가 당분간 이어질 것으로 예상
• Scion으로 이전하는 동안
  Antique, 코드 검색, 세밀한 소스 관리 접근 제어, 대량의 리뷰 완료 코드를 관리하고 병합하는 방식도 함께 구축 - Claude 사용량이 특히 많은 Anthropic의 경험이며, 일반적인 조직이 당장 같은 규모의 문제를 겪는다는 의미는 아님

Git의 분산 모델과 실제 사용 방식의 간극

• Git은 각 복제본이 독립적인 저장소로 동작해 오프라인에서도 diff와 이력, blame 조회, 리비전 체크아웃을 수행하는 구조

• Anthropic 모노레포는
  main 이력만 약 100GB, 압축된 작업 사본도 25GB 이상 - CI에서만 하루 약
  2,500만 회 체크아웃하며, 개발 환경과 에이전트 샌드박스, 연구 작업은 별도 - 전체 작업 사본을 단순하게 가져온다고 가정하면 하루 Git 트래픽이 600PB를 넘는 규모

• 얕은 복제와 희소 체크아웃, 필요한 객체를 원격에서 받는 부분 복제, 내부 미러와 저장소 스냅샷을 모두 활용

• 최대 수백 개의 내부 미러를 운영

• 병합 속도가 높아질수록 스냅샷이 최신 main에서 더 뒤처짐

• 부분 복제에서도 diff와 blame 등 이력 기반 작업이 정상 동작하도록 유지하는 부담 증가

• 실제로는 하나의 권위 있는 원본을 중심으로 운영하며, 클라이언트 대부분은
  항상 온라인인 에이전트와 작업 - 이 사용 방식에 맞춰 소스 관리의 전제를 다시 설계

에이전트 규모에 맞춘 여섯 가지 원칙

Google Piper와 Meta Sapling의 선행 경험을 참고해 다음 원칙을 적용.

클라이언트는 항상 온라인- 서버에 접근할 수 있다고 가정하고 필요한 순간에 데이터를 가져옴

클라이언트와 서버의 역할은 비대칭- 서버가 커밋과 병합, 리베이스, 파일 이력과 blame 조회 담당

• 클라이언트는 크기가 제한된 객체 캐시와 작업 사본, 파일 변경 감시, 사용자 인터페이스 담당

소스 관리 기능 전체를 API로 제공- 특정 줄의 마지막 수정자나 커밋 간 관계를 알아내기 위해 로컬 저장소를 유지할 필요를 줄임

• 자동 이분 탐색과 되돌리기 파이프라인도 API로 운영

모든 구성 요소를 수평 확장- 저장소 데이터를 분산하고 구성 요소별로 독립 확장

• 서버에도 저장소 전체를 펼쳐 놓은 사본을 두지 않으며, Git packfile에 해당하는 구조가 없어 저장소 유지보수 불필요

커밋은 저비용, 증분 방식, 잠금 없이 처리- 커밋과 리베이스, 병합이 서버에서 일어나 별도 push가 없음

• 처리 비용은 전체 저장소보다 변경 크기에 비례하도록 설계
• 전역 상태를 줄이기 위해 main과 릴리스 브랜치 외의 브랜치/태그 사용을 권장하지 않음

작업 사본은 선택 사항이며 기본적으로 희소- 많은 조회와 쓰기 작업을 체크아웃 없이 API로 수행

• 파일이 필요할 때도 요청한 디렉터리만 받거나 실제 읽는 파일만 생성

Changeset과 파생 데이터

• Scion의 작업 단위인
  changeset은 변경 내용을 기록하는 선행 기록 로그의 항목 - Git 커밋처럼 전체 트리 포인터를 저장하는 대신,
  첫 번째 부모 대비 변경된 파일 목록과 압축된 파일 내용의 콘텐츠 주소를 기록 - Changeset은 서버에서 생성되고 즉시 다른 클라이언트에서 이용 가능

• 커밋 생성에는 packfile 수신과 잠금, 서버 간 조정, 브랜치 포인터 이동이 필요하지 않아 높은 처리량 확보

• 브랜치와 태그를 가리키는 ref는 지원하지만, 생성과 조회에 필수는 아님

• ref 변경은 changeset 생성과 별개로 Spanner의 단일 행을 비교 후 교환하는 방식으로 처리

• 변경분만으로 빠르게 답하기 어려운 질의를 위해
  파생 데이터를 별도로 구성- 파일 blame과 경로 이력 전용 구조

• 커밋 그래프 탐색을 위한 스킵 리스트

• 복사 감지와 경로 기반 파일 검색 인덱스

• 파생 데이터는 부모 changeset의 값에서 재귀적으로 계산

• 데이터 유형마다 미리 계산하거나 필요할 때 계산하도록 선택할 수 있고, 클라이언트를 바꾸지 않고 서버 내부 구조를 최적화 가능

서버 API와 계층형 체크아웃

• Scion 서버는 changeset과 diff 조회, 병합 기준점 탐색, 파일 내용 가져오기 등 필요한 API 제공
• 콘텐츠 주소로 식별되는 객체는 저장 후 변하지 않으므로 서버끼리 확인하지 않고 캐시 가능
• 이전 초기에는 자체 클라이언트와 저장소 형식이 완성되기 전부터
  조상 관계와 blame 같은 메타데이터 조회를 제공- CI와 도구가 로컬 저장소를 가져오고 유지하는 부담부터 줄임

scn

클라이언트는 자신이 가진 객체 목록을 서버에 알리는 대신필요한 트리와 파일 내용만 요청- 루트 트리부터 로컬에 없는 하위 트리를 재귀적으로 요청

• 이후 파일 내용에도 같은 방식 적용

• 거대한 단일 packfile 응답이 없어 중단 후 재개 가능

• 실제 배포 구조는 다음과 같음
  : 같은 노드의 작업들이 객체를 공유하는 로컬 캐시scion-daemon

: 해당 리전의 트리와 파일 내용 캐시scion-cache

: Spanner와 클라우드 스토리지에서 데이터를 읽는 원본 서버scion-servers

• 리전 캐시는 데몬이 사용할 디스크 형식 그대로 메모리에서 객체를 전송

• 클라이언트의 누락 객체를 계산하거나 델타 압축할 필요가 없음

• 세 계층이 같은 RPC에 응답하므로 클라이언트는 캐시 구조를 알 필요가 없음

• 다만 계층 순서는 엄격히 유지해
  리전 캐시 장애가 원본 서버로 요청을 몰아 전체 장애로 번지는 상황을 방지

인프라와 명령별 성능

• 각 캐시 계층의 적중률은
  99% 이상 - 기존 Git 미러 인프라 대비 CPU와 메모리 요구량은
  200분의 1 - 클라이언트와 캐시의 저장소 유지보수가 불필요해 작업 수명주기 관리도 단순화
• 아래는 Anthropic 모노레포에서 측정한 명령별 중앙값

• CI만으로도
  CPU 처리 여력 25% 개선 - 수치는 Anthropic 내부 환경의 측정 결과이며, 일반적인 Git 저장소의 성능 비교로 확대할 수는 없음

Claude와 7명 팀의 개발 경험

• Scion 개발은 Claude Mythos Preview와 Claude Tag를 내부에서 사용하기 시작한 시기와 맞물림

• 두 제품은 Scion의 필요성을 키우는 동시에 구현과 이전 속도도 높임

• 대부분 사람이 작성했던 Git-to-Scion 수집 파이프라인을 초기 Mythos Preview에 다시 작성하도록 요청

• 추가 지시 없이
  메모리 사용량을 20분의 1로 줄이고 속도를 4배 향상 - 수집 순서와 자료구조의 암묵적 불변 조건도 유지

• 추가 지시 없이

• 7명 팀이 Scion과 Antique, 약 6개 관련 시스템을 만들고 5개월 만에 이전 완료

• 참여 엔지니어들은 Claude의 코드 작성 능력을 높게 평가했지만,
  시스템 관계와 설계 절충안, 해결할 문제와 목표 규모는 계속 직접 판단 - 엔지니어가 Claude에게 “안 된다”고 말해야 하는 경우도 많았음

• 변경의 병합 시점을 코드 리뷰 도구에 묻는 대신 커밋 로그를 선형 탐색하려는 구현

• 다른 내부 서비스를 지나치게 불신한 검토 결과, 불필요한 검증과 복잡성을 추가한 구현

• 모든 변경 요청을 검토하되, 코드의 모든 줄보다
  변경 의도와 시스템 제약에 집중

테스트와 보안, 운영과 CI

• 외부 의존성을 차단한 시뮬레이션으로 복잡한 인프라와 소스 관리의 상호작용을 테스트하고, 퍼징과 요청 속도 제한 구축
• 기존 인덱스를 활용하지 못하던 조상 관계 질의 등에서 Claude가 알고리듬 최적화를 발견
• 저장소 수준의 접근 제어와
  디렉터리별 권한으로 민감한 코드 보호 - 코드 리뷰 도구는 주석만 바꾸는 변경과 민감한 로직 변경을 구분하는 승인 조건 지원
• Claude Tag를 활용한
  “superfan” 에이전트가 구성 요소별 상태를 집중 감시scion-daemon

,scion-cache

, Antique 병합 대기열마다 담당 에이전트를 두고 로그와 텔레메트리 접근 제공- 기존 경보도 유지하면서 미묘하거나 새로운 문제를 탐지

• 테스트가 실행되는 동안에도 수백에서 수천 개 변경이 병합될 수 있어 기존 병합 대기열과 CI의 전제를 재검토
• 저장소 전체를 잠그는 병합 대기열 대신
  병합 후와 배포 전 자동 테스트에 투자 - 동시 변경 사이의 충돌은 생길 수 있지만, 내부 경험에서는 Claude가 사람이 파악하기 전에 수정하는 경우가 일반적이었음

Git 생태계에 적용할 여지

• Scion은 수만 명의 엔지니어나 대량의 코드를 생성하는 에이전트가 사용하는
  초대형 모노레포에 특화 - 일반적인 Git 대체재로 적합하지 않으며, Anthropic의 내부 토큰 사용 여력도 다른 기업이 현실적으로 지출하려는 규모와 다름

• 외부 조직이 도입하려면 코드 리뷰와 검색, CI까지 이전해야 하고 각 구성 요소도 Anthropic 환경에 맞춰져 있음

• 범용 공개 버전을 만드는 대신 다음과 같은 설계 경험을 공유

• Git 클라이언트와 다른 방식으로 확장하는 서버 구조

• 호스팅 플랫폼 간 표준화할 수 있는 포괄적인 서버 측 RPC

• 객체 전송과 협상 프로토콜 개선

• 희소 체크아웃과 얕은 복제 기능의 조합 개선

• Anthropic은 유사한 문제가 향후 6~12개월 동안 더 흔해질 것으로 예상하며, GitHub와 GitLab, 오픈소스 커뮤니티와 경험을 공유하려함