Anthropic은 내부 모노레포에서 하루 병합 변경 건수가 5월 약 2,500건에서 2026년 9월 3만 건 이상으로 늘었다고 밝혔습니다. 10월 13일자 엔지니어링 설명 은 성장의 상당 부분을 뒷받침한 에이전트와 자동화 작업을 위해 구축한 소스 관리 시스템 Scion을 소개합니다. 여기서 유용한 엔지니어링 질문은 클라이언트가 기록, 커밋, 병합을 중앙 서비스에 맡길 수 있을 때 어떤 작업을 여전히 직접 해야 하는가입니다.

가장 큰 변화

  • 달라진 점: Anthropic은 5개월 만에 모노레포를 Git에서 Scion으로 옮겼습니다. Scion 클라이언트는 필요한 객체만 가져오고 커밋, 병합, 리베이스, 기록 조회는 서버에 맡깁니다. Anthropic은 온라인 상태인 에이전트와 작업이 대부분인 워크로드를 위해 Scion을 만들었습니다.
  • 중요한 이유: CI 작업은 로컬 저장소를 유지하지 않고도 API로 diff나 병합 기준점을 요청할 수 있습니다. 파일이 필요하면 부분 또는 가상 체크아웃으로 디스크에 내려받는 범위를 제한합니다. 그만큼 비용과 운영 책임이 중앙 서비스 쪽으로 이동합니다.
  • 앞으로 볼 점: Anthropic은 자체 플릿에서 체크아웃이 빨라지고 인프라 사용량이 줄었다고 보고했지만, 여기서 독립적으로 검증된 것은 아닙니다. 회사는 Scion이 맞춤형 내부 시스템이며, 이전 과정에서 코드 검토, 검색, CI도 바꿔야 했다고 말합니다.

이 모노레포에서 Git 비용이 커진 이유

Git의 분산형 설계에서는 전체 복제본마다 오프라인 작업에 필요한 기록과 객체가 들어갑니다. Anthropic은 모노레포의 기본 브랜치 기록이 거의 100GB이고 압축된 작업 사본도 25GB를 넘는다고 밝혔습니다. CI 플릿은 개발 환경, 에이전트 샌드박스, 연구 작업을 제외하고도 하루 약 2,500만 회 코드 체크아웃을 수행합니다. 이는 Anthropic의 워크로드 수치이지, Git이 작동하지 않기 시작하는 일반적인 기준은 아닙니다.

회사는 이미 얕은 복제, 부분 체크아웃, 내부 미러, 저장소 스냅샷을 사용했습니다. 저장소와 병합 속도가 커지면서 수백 개 미러를 운영하기 어려워졌다고 합니다. Anthropic의 진단은 구체적입니다. 클라이언트 대부분이 원래 온라인 에이전트나 작업이었는데도 도구는 로컬 저장소 유지 비용의 상당 부분을 계속 부담했습니다.

Scion은 온라인 연결을 설계의 전제로 삼습니다. 이 엔지니어링 설명 에 따르면 서버가 기록 및 blame 조회에 응답하고, 커밋을 만들며 병합과 리베이스를 수행합니다. 클라이언트는 제한된 객체 캐시를 보유하고, 요청한 작업 파일을 디스크에 배치하며, 로컬 파일 변경을 감시합니다. 이런 작업을 독립적으로 수행할 능력을 포기하는 것은 각 클라이언트에 보내는 데이터를 줄이기 위한 의도적인 절충입니다.

체크아웃은 더 작아지거나 아예 필요 없을 수 있습니다

Scion은 클라이언트가 사용하는 소스 관리 조회를 API로 제공합니다. Anthropic은 병합 기준점에서 diff가 필요한 CI 작업이 서버에 직접 요청할 수 있다고 말합니다. 자동화된 이분 탐색과 되돌리기 파이프라인도 같은 프로그램 경로를 사용합니다. 이런 작업에는 작업 사본을 아예 만들 필요가 없을 수 있습니다.

작업에 파일이 필요하면 Scion은 요청한 디렉터리만 담는 부분 체크아웃과 읽을 때 파일을 만드는 가상 체크아웃을 지원합니다. 클라이언트는 큰 packfile을 협상하는 대신 누락된 특정 트리와 blob을 재귀적으로 요청합니다. 요청된 객체마다 변경되지 않는 콘텐츠 주소형 식별자가 있어, 캐시는 내용이 달라졌는지 확인하지 않고도 객체를 반환할 수 있습니다. Anthropic은 클라이언트와 권한 있는 서버 사이에 노드 수준 데몬과 지역 캐시를 둔다고 설명하며, 모든 계층이 동일한 객체 요청 프로토콜을 사용합니다.

이 설계는 완전한 로컬 복제본과 장애 및 유지보수 경계가 다릅니다. Git이 오프라인에서 할 수 있는 작업에도 클라이언트가 서비스에 의존하고, 서비스는 플릿 전체의 속도에 맞춰 객체와 기록 조회를 제공해야 합니다. Anthropic은 지역 캐시 장애가 상위 서버를 압도하지 않도록 하는 등의 이유로 캐시 계층을 강제한다고 말합니다. 이 아키텍처의 가용성 측정치는 기사에 제시되지 않았습니다.

서버가 저장하고 계산하는 것

Scion의 작업 단위는 쓰기 선행 로그의 변경 집합입니다. Anthropic은 첫 번째 부모를 기준으로 바뀐 파일을 기록하고, blob 저장소의 압축 파일 콘텐츠를 가리키는 포인터를 둔다고 설명합니다. 서버는 쓰기마다 공유 브랜치 포인터를 옮기지 않고 변경 집합을 만듭니다. 별도의 파생 구조가 파일 blame, 경로 기록, 커밋 조상 조회 등을 지원하며, Anthropic은 일부를 즉시 계산하고 나머지는 미룹니다.

이 분리는 API 설계에 중요합니다. 작업은 답을 로컬에서 계산하는 데 필요한 모든 구조를 가져오지 않고도 병합 기준점이나 파일 기록을 요청할 수 있습니다. 그 구조를 유지하는 비용도 Anthropic 서비스로 이동합니다. 회사는 저장소 데이터를 분산하고 구성 요소를 독립적으로 확장하며, 서버에서도 저장소 전체를 완전히 물질화한 복사본은 없다고 말합니다.

Anthropic은 Scion 인프라가 이전 Git 미러링 구성보다 CPU와 메모리를 200배 적게 사용하고, CI 및 연구용 체크아웃 시간이 분 단위에서 초 단위로 줄었다고 보고합니다. CI의 CPU 용량이 25% 늘어난 것도 이 변화의 결과라고 설명합니다. 이는 Anthropic 자체 워크로드에서 이전 내부 시스템과 비교한 수치입니다. BIG CHANGE는 측정을 재현하거나 기반 텔레메트리를 검토하지 않았습니다.

마이그레이션 비용도 결과의 일부입니다

Anthropic은 엔지니어 7명이 Scion과 동반 코드 검토 도구 Antique 및 관련 시스템을 만들고 5개월 만에 모노레포를 이전했다고 밝혔습니다. 설명에는 새로운 코드 검색, 접근 제어, 코드 검토와 반영 방식의 변화도 나옵니다. 이 설계를 평가하는 조직은 소스 관리 서비스 자체뿐 아니라 이런 인접 워크플로도 고려해야 합니다.

Anthropic은 Scion이 범용 Git 대체재로 적합하지 않다고 명시합니다. 내부 검토, 검색, CI 구성 요소는 맞춤형이며 Git에서 벗어나려면 개발 수명 주기 전반을 바꿔야 합니다. 설명이 주는 더 좁은 교훈은 아키텍처에 관한 것입니다. 온라인 서비스가 자동화 클라이언트에 더 많은 소스 관리 답변을 제공하는 동안, 클라이언트는 사용하는 파일만 보유할 수 있습니다. Anthropic은 더 풍부한 서버 API와 Git의 부분·얕은 기능을 더 잘 조합하는 등 일부 아이디어는 Scion을 채택하지 않고도 적용할 수 있다고 제안합니다.

출처 및 추가 읽을거리

  • Anthropic Engineering, Redesigning source control at Anthropic (2026년 10월 13일). Scion 아키텍처, 이전 과정, 내부 워크로드 및 성능 수치에 관한 Anthropic의 1차 설명입니다. 보고된 측정과 운영 결과는 BIG CHANGE가 독립적으로 검증하지 않았으며, 이 기사에서 Scion 시스템을 테스트하지 않았습니다.