Anthropic의 Scion: Anthropic이 Git을 에이전트 규모 버전 관리 시스템으로 대체한 방법

Anthropic은 자체 버전 관리 시스템인 Scion을 구축하고 5개월 만에 모노레포를 git에서 완전히 이전했다고 발표했습니다. git의 분산형 오프라인 우선 설계가 더 이상 AI 에이전트가 코드를 작성하는 속도를 따라잡을 수 없었기 때문입니다. 회사는 병합된 코드 변경이 2026년 5월 하루 약 2,500건에서 2026년 9월 하루 30,000건 이상으로 증가했으며, Scion의 인프라 footprint는 CPU 및 메모리 측면에서 이전 git 미러링 설정보다 200배 더 작다고 보고합니다.

핵심 문제: 코딩이 더 이상 병목이 아님

Anthropic에서 시스템 구축과 연구의 병목은 더 이상 코드 작성이 아닙니다. 병목은 인간 규모에 맞춰 만들어진 개발자 인프라, 즉 소스 제어, 빌드, CI입니다. Claude는 연구 루프를 자율적으로 반복하고, 복잡한 프로그램을 미세 최적화하며, 새로운 서비스를 처음부터 구축할 수 있으며, 주변 도구가 제약이 되고 있습니다.

Anthropic이 인용한 성장 수치는 가파릅니다. 2026년 5월 Anthropic은 하루 평균 약 2,500건의 코드 변경을 병합했습니다. 2026년 9월 기준으로 하루 30,000건 이상을 병합했습니다. Anthropic은 이러한 성장률이 둔화될 것으로 예상하지 않으며, 코드 병합에 대한 잠재 수요를 "실질적으로 무한"하다고 설명하고 병목이 제거될 때마다 즉시 생산되는 코드 양이 더 증가한다고 언급합니다.

Scion과 함께 Anthropic은 Antique라는 코드 리뷰 표면, 코드 검색, 소스 제어 IAM 시스템, 그리고 대량의 검토된 코드를 관리하고 배포하는 새로운 방법도 같은 5개월 동안 구축하고 출시했습니다.

git이 Anthropic의 모노레포에 맞지 않게 된 이유

Git은 모든 클론이 완전하고 독립적인 저장소이며 오프라인에서도 diff 계산, 기록 및 blame 읽기, 모든 리비전 체크아웃이 가능한 분산 시스템입니다. Anthropic은 대부분의 저장소에서 이것이 올바른 설계이며 git이 표준이 된 큰 이유라고 명확히 밝힙니다. 그러나 Anthropic의 모노레포는 점점 이 설계 공간에서 벗어나고 있습니다.

Anthropic이 제시한 구체적인 규모 수치는 다음과 같습니다.

• 메인 브랜치의 기록만 해도 거의 100GB입니다.
• 압축된 작업 복사본은 25GB가 넘습니다.
• Anthropic은 개발자 환경, 에이전트 샌드박스, 연구 작업을 제외하고 CI를 위해 하루 약 2,500만 건의 코드 체크아웃을 수행합니다.
• 이를 단순하게 가져오면 하루 600PB 이상의 git 트래픽이 발생합니다.

Anthropic은 사용 가능한 모든 표준 해결 방법을 사용했습니다: 얕은 클론, 스파스 체크아웃, 프로미서 리모트, 내부 git 미러, 블롭 스토리지에 보관된 저장소 스냅샷(시드) 등. 최대 부하 시점에 Anthropic은 부하를 처리하기 위해 수백 개의 내부 git 미러를 운영했습니다. 이러한 방법은 시간을 벌어 주었지만 병합 속도가 증가함에 따라 운영이 더 어려워졌습니다. 시드는 새로 고침 사이에 메인 팁에서 더 멀어졌고, 부분 클론에서 diff 및 blame과 같은 기록 종속 작업을 유지하려면 더 많은 주의가 필요했습니다.

핵심 통찰은 Anthropic이 대부분의 회사처럼 git을 하나의 권위 있는 복사본이 있는 중앙 집중식 시스템으로 사용하고 있는 반면, 클라이언트의 거의 대부분이 정의상 온라인인 에이전트와 작업이라는 것이었습니다. 분산 및 오프라인 작업에 탁월한 git의 속성은 저장소가 커짐에 따라 Anthropic의 확장 능력을 적극적으로 훼손하고 있었습니다.

Scion의 여섯 가지 원칙

Anthropic은 대규모 모노레포의 소스 제어에 대한 선례, 특히 Google의 Piper와 Meta의 Sapling을 언급하며 이러한 교훈을 바탕으로 Scion을 구축했다고 말합니다. 설계는 여섯 가지 원칙에 기반합니다.

1. 클라이언트는 항상 온라인

Git은 클라이언트가 오프라인으로 작업하고 저장소의 완전한 복사본이 필요하다고 가정합니다. Anthropic의 클라이언트가 거의 모두 에이전트와 작업이기 때문에 Scion의 클라이언트와 프로토콜은 항상 연결 가능한 서버를 중심으로 설계되었으며, 클라이언트는 필요할 때 데이터를 가져옵니다.

2. 클라이언트-서버 비대칭

Git에서 모든 클라이언트는 완전한 서버가 될 수 있습니다. Scion에서 서버는 파일 기록 및 blame에 대한 질문에 답하고, 커밋을 생성하고, 병합 및 리베이스를 수행합니다. 클라이언트는 제한된 로컬 객체 캐시를 유지하고, 작업 복사본 파일을 디스크에 배치하고, 파일 시스템 변경을 모니터링하며, 서버와 작업하기 위한 사용자 친화적인 방법을 제공합니다. 클라이언트는 자체적으로 계산할 수 있는 것이 거의 없지만 로컬 데이터는 훨씬 적게 필요합니다.

3. 포괄적인 소스 제어 서비스는 많은 새로운 애플리케이션을 지원할 수 있음

Git에서 저장소에 대해 질문해야 하는 CI 작업이나 도구(마지막으로 줄을 변경한 사람, 두 커밋의 관계 등)는 로컬 복사본을 유지하거나 공급업체별 API에 의존해야 합니다. Scion에서는 클라이언트가 사용하는 모든 소스 제어 쿼리가 API로도 노출되므로 많은 경우 작업에 로컬 저장소가 전혀 필요하지 않습니다. Anthropic은 자동 bisect 및 revert 파이프라인과 같은 내부 도구가 이러한 저렴하고 프로그래밍 방식의 소스 제어 액세스 없이는 대규모로 실용적이지 않을 것이라고 말합니다.

4. 모든 것은 수평적으로 확장 가능해야 함

최대 부하 시 Anthropic은 수백 개의 git 미러를 실행했으며, 이는 용량에 부담을 주고 저장소가 미러의 디스크 또는 메모리 한도를 초과하면 확장이 중단되었습니다. Scion에서 저장소 데이터는 분산되어 있으며 모든 구성 요소는 독립적으로 확장 가능합니다. 서버에도 완전히 구체화된 저장소 복사본은 없습니다. git의 packfile과 같은 것이 없으므로 저장소 유지 관리가 필요 없습니다.

5. 커밋은 저렴하고, 증분적이며, 잠금이 없어야 함

Git에서는 로컬로 커밋한 다음 푸시하여 작업을 공유합니다. Scion에서는 모든 커밋, 리베이스 또는 병합이 서버에서 발생하므로 푸시할 것이 없지만 각 작업은 빨라야 합니다. 커밋 생성 및 다운스트림 데이터 구조 업데이트 비용은 변경 크기에 비례해야 하며 저장소 전체 크기에 비례하지 않아야 합니다. Scion의 개발 수명 주기는 메인 ref 또는 릴리스 브랜치를 제외하고 refs(브랜치 및 태그와 같은 커밋 포인터)를 권장하지 않습니다. 모든 서버가 동의해야 하는 전역 상태는 다가오는 확장 문제이기 때문입니다.

6. 작업 복사본은 선택 사항이며 설계상 스파스함

모노레포가 너무 크고 CI를 위해 코드가 하루에 수천만 번 체크아웃되기 때문에 Anthropic은 가능하면 체크아웃을 피하고 싶었습니다. 커밋과 병합 베이스 간의 diff가 필요한 CI 작업은 서버에 요청할 수 있습니다. 많은 쓰기 작업도 체크아웃을 건너뛰고 전적으로 API를 통해 기능할 수 있습니다. Scion의 프로토콜은 클라이언트가 요청한 디렉토리만 포함하는 스파스 체크아웃과 요청 시 파일을 구체화하는 가상 체크아웃을 중심으로 하므로 작업은 실제로 읽은 만큼만 비용을 지불합니다.

Scion 작동 방식: 변경 세트 및 파생 데이터

Scion에서 작업 단위는 변경 세트이며, write-ahead 로그의 항목입니다. 변경 세트는 git 커밋이 저장하는 대부분을 저장하지만, git 커밋이 트리에 대한 포인터를 저장하는 반면 변경 세트는 첫 번째 부모를 기준으로 변경된 파일 목록과 블롭 스토리지의 압축된 파일 내용에 대한 콘텐츠 주소 지정 포인터를 저장합니다. 변경 세트는 서버 측에서 생성되며 즉시 모든 곳에서 사용할 수 있습니다.

이 구조 덕분에 Scion은 매우 높은 처리량으로 변경 세트를 수용할 수 있습니다. 수용할 packfile이 없고, 잠금이나 서버 간 조정이 없으며, 이동할 refs도 없습니다. Scion은 기술적으로 refs를 지원하지만 커밋 생성이나 가져오기에 refs가 포함되지 않으므로 ref 이동은 변경 세트 생성과 별도로 단일 Spanner 행에 대한 compare-and-swap입니다.

변경 세트는 변경된 내용만 기록하므로 마지막으로 줄을 편집한 사람이나 파일에 영향을 준 커밋과 같은 질문에 자체적으로 빠르게 답할 수 없습니다. 따라서 Scion은 변경 세트에서 추가 데이터 구조(파일 blame 및 경로 기록 전용 구조, 커밋 그래프용 스킵 리스트)를 구축합니다. Anthropic은 변경 세트의 직접적인 일부가 아닌 모든 것을 파생 데이터라고 부르며, 이를 하나의 일반 메커니즘을 통해 계산합니다. 각 유형의 파생 데이터는 재귀적으로 정의되므로 변경 세트에 대한 값은 해당 변경 세트의 부모에 대한 값에서 계산됩니다.

Anthropic은 이 메커니즘의 세 가지 이점을 언급합니다: 작업을 더 빠르게 만드는 새 데이터 구조가 있을 때 새 유형의 파생 데이터를 쉽게 추가할 수 있고; 각 유형을 즉시 또는 지연 계산하여 불필요한 데이터가 구체화되지 않도록 할 수 있으며; 클라이언트가 이러한 구조의 내부를 볼 수 없으므로 클라이언트를 변경하지 않고 최적화할 수 있습니다. Anthropic은 시스템이 성장함에 따라 복사 감지 및 경로 기반 파일 검색을 위한 새 인덱스를 포함하여 여러 번 새 유형의 파생 데이터를 추가했다고 말합니다.

서빙 아키텍처: 데몬, 캐시 및 서버 계층

소규모 Scion 서버 플릿은 클라이언트가 필요로 하는 모든 작업(변경 세트 가져오기, diff 계산, 병합 베이스 찾기, 블롭 가져오기)에 대한 소스 제어 API를 제공합니다. 모든 소스 제어 데이터는 콘텐츠 주소 지정 방식이므로 데이터는 저장되면 변경되지 않으며 모든 서버는 다른 서버와 확인하지 않고 캐시할 수 있습니다. 따라서 서버는 수평적으로 확장 가능하고 조정이 거의 필요 없으며, 본질적으로 파생 데이터를 즉석에서 계산하고 결과를 Spanner에 다시 쓸 수 있는 대규모 캐시 역할을 합니다.

Scion의 scn 클라이언트는 여러 중요한 방식에서 git의 fetch 프로토콜과 다릅니다. Scion의 협상은 서버에 클라이언트가 이미 가지고 있는 것을 알려주지 않습니다. 대신 클라이언트가 원하는 트리와 블롭에서만 작동합니다. 루트 트리에서 시작하여 클라이언트는 로컬 저장소에서 누락된 트리를 확인하고 재귀적으로 요청한 다음 블롭에 대해 동일한 프로세스를 반복합니다. 모든 요청은 변경되지 않는 특정 객체에 대한 것이므로 모든 캐시가 응답할 수 있으며 아키텍처는 기존 계층 캐시와 매우 유사합니다. 이 프로세스는 단일 수 기가바이트 packfile 응답이 없기 때문에 효율적이고 재개 가능합니다. 스파스 및 가상 체크아웃은 클라이언트가 원하지 않는 트리를 요청하지 않기 때문에 특별한 지원이 필요 없습니다.

클라이언트는 소켓을 통해 데몬 scion-daemon과 통신하며, 데몬은 전체 노드의 객체를 저장합니다. 대부분의 노드는 모노레포에 액세스해야 하며 동일한 노드의 작업은 대부분 동일한 객체를 재사용합니다. 각 데몬은 주기적으로 새로 고쳐지는 스냅샷에서 시작한 다음 해당 지역의 트리 및 블롭 캐시 서버(scion-cache)와만 통신합니다. 이러한 캐시 서버는 데몬이 사용할 디스크 형식으로 메모리에서 직접 객체를 스트리밍하므로 클라이언트의 누락된 객체를 계산하거나 델타 압축을 수행하는 데 시간을 소비하지 않습니다. 캐시에 객체가 없으면 권위 있는 scion-servers에 요청하며, 서버는 필요에 따라 Spanner 또는 클라우드 스토리지에서 읽습니다.

scion-daemon, scion-cache, scion-server는 모두 이 프로토콜에 대해 동일한 RPC에 응답하므로 클라이언트는 캐시 토폴로지를 알 필요가 없습니다. 이론적으로 모든 계층은 서로 통신할 수 있지만 Anthropic은 장애 도메인을 격리하기 위해 계층화를 엄격히 적용합니다. 특히 지역 scion-cache 장애가 업스트림 scion-servers를 압도하고 전체 시스템을 중단시키는 것을 방지합니다.

측정 결과

Anthropic은 마이그레이션에서 다음과 같은 결과를 보고합니다.

• 시스템의 각 계층은 99% 이상의 캐시 적중률을 유지하며 장기 상태가 필요 없어 확장이 쉽습니다.
• Scion의 인프라 footprint는 CPU 및 메모리 요구 사항 측면에서 이전 git 미러링 인프라보다 200배 더 작습니다.
• CI 및 연구 작업은 코드 체크아웃이 두 자릿수 더 빠르게(분이 아닌 초) 이루어져 플릿 전체에서 상당한 용량을 확보했습니다.
• CI만으로도 25%의 CPU 용량 이득을 실현했습니다.
• 클라이언트와 캐시 모두 저장소 유지 관리를 수행할 필요가 없어 작업 수명 주기 관리가 간소화됩니다.

Scion을 구축하면서 Anthropic이 배운 것

Anthropic은 Claude Mythos Preview와 Claude Tag가 내부적으로 제공되기 시작한 것과 거의 같은 시기에 Scion 구축을 시작했습니다. 두 릴리스 모두 Scion의 필요성을 증폭시키고 시스템 구축 속도를 크게 가속화했다고 말합니다.

Claude가 수집 파이프라인을 재작성

Anthropic은 git-to-Scion 수집 파이프라인의 첫 번째 버전을 프로토타입으로 대부분 손으로 작성했습니다. Claude Mythos Preview의 초기 내부 스냅샷에 액세스한 후 팀은 전체를 재작성하도록 요청했습니다. 추가 지시 없이 Claude는 수집 순서와 데이터 구조에 대한 모든 암시적 불변성을 유지하면서 메모리를 20배 적게 사용하고 4배 더 빠른 버전을 생성했습니다.

소규모 팀이 이제 몇 달 만에 수년 분량의 마이그레이션을 수행할 수 있음

7명으로 구성된 팀이 Scion과 Antique, 그리고 6개 이상의 관련 시스템을 구축하고 5개월 만에 완전히 이전했습니다. 하루 병합 코드 양은 10배 증가했습니다. Anthropic은 이와 같은 소스 제어 시스템을 개발하고 배포하는 것은 이전에는 훨씬 더 많은 엔지니어와 수년간의 반복 마이그레이션이 필요했을 것이라고 언급하며, 이러한 빠르고 민첩한 마이그레이션이 더 일반화될 것으로 기대합니다.

엔지니어의 가치는 줄어들지 않았지만 작업은 변화하고 있음

Anthropic은 이 시스템에서 작업한 모든 엔지니어가 이제 Claude가 코드 작성에 있어 자신보다 낫다고 평가할 것이라고 밝힙니다. 그 엔지니어들은 여전히 높은 수준의 시스템 간 구성 요소와 설계 수준의 트레이드오프에 대한 이해를 제공하고, 어떤 문제를 해결하고 어떤 규모를 달성할지에 대해 정보에 입각한 선택을 합니다. Anthropic은 엔지니어의 역할이 종종 Claude에게 "아니요"라고 말하는 것이라고 설명합니다. 에이전트는 허용되어서는 안 되는 패턴을 충족시키기 위해 핵심 시스템 제약을 위반하는 경우가 있습니다. 이는 마이그레이션 중에 특히 흔했습니다. 예를 들어 여러 시스템이 코드 리뷰 도구에 묻는 대신 커밋 로그를 선형으로 읽어 변경 사항이 메인에 병합된 시점을 찾으려고 무차별 대입 방식으로 시도했습니다.

Anthropic은 또한 적대적 리뷰를 광범위하게 사용하며, 이는 매우 효과적이지만 때로는 근시안적이라고 말합니다. 숙련된 엔지니어는 가상의 우려에 대응하여 과도한 엔지니어링을 하지 않도록 Claude를 이끌어야 했습니다. 그러한 리뷰 중 하나는 다른 내부 서비스를 신뢰하는 것에 대해 지나치게 방어적이어서 Claude가 과도한 검증과 복잡성을 추가했습니다. 팀원들은 여전히 시스템에 대한 모든 변경 요청을 검토하지만 이제는 모든 코드 줄을 읽는 대신 변경의 의도를 검토합니다.

최적화와 품질이 크게 향상

Claude가 인간보다 훨씬 빠르게 방대한 양의 코드를 작성할 수 있기 때문에 Scion은 Anthropic이 작업한 코드베이스 중 가장 잘 테스트되고 잘 방어된 코드베이스 중 하나입니다. 빠듯한 일정에도 불구하고 팀은 직면한 모든 사소하지 않은 인프라 및 소스 제어 상호 작용에 대한 밀폐 시뮬레이션과 퍼징 및 정교한 속도 제한을 구축했습니다. Anthropic은 또한 Claude가 우연히 상당한 최적화를 발견했다고 보고합니다. 예를 들어 팀의 인덱스 중 하나를 놓친 조상 쿼리에 대한 알고리즘 최적화는 전문가가 며칠 또는 몇 주간의 분석과 튜닝이 필요했을 작업이었고, 다음 날 다시 수행했습니다.

새로운 형태의 모노레포 보안

Scion은 저장소에 대한 풍부한 액세스 제어와 개별 디렉토리에 권한을 적용하는 기능을 지원하여 모노레포의 이점을 잃지 않으면서 가장 민감한 코드를 보호합니다. Anthropic이 구축한 코드 리뷰 도구는 승인에 대한 복잡한 의미론적 제약을 표현할 수 있어 팀이 주석 전용 편집과 같은 단순한 변경과 민감한 논리적 변경을 구분할 수 있으며, 인간 리뷰어가 가장 중요한 변경에 집중할 수 있습니다.

"슈퍼팬": Claude를 구성 요소 수준 모니터로 사용

팀은 Claude Tag를 많이 사용합니다. Claude가 단일 구성 요소의 상태에 집착적으로 집중하도록 하는 Slack 채널을 만들었습니다. scion-daemon 슈퍼팬, scion-cache 슈퍼팬, Antique 병합 큐 슈퍼팬 등입니다. 이러한 Claude는 텔레메트리와 로그에 액세스할 수 있으며 차트를 새로 고치고 이상한 점을 찾는 것 외에는 할 일이 없는 숙련된 엔지니어처럼 행동합니다. Anthropic은 여전히 모든 시스템에 대해 기존 알림을 실행하지만 슈퍼팬은 이러한 알림이 비교적 단차원적으로 보이게 만드는 미묘하고 새로운 문제를 감지한다고 말합니다.

병합 큐와 CI 재고

이 프로젝트는 Anthropic이 인간 규모에 맞게 설계된 다른 워크플로를 재검토하도록 했습니다. 적절한 병합 큐는 에이전트 규모에서는 별 의미가 없으며, 회사는 테스트가 실행되는 동안 수백 또는 수천 개의 변경 사항이 병합될 수 있을 때 CI가 무엇을 의미하는지 묻습니다. Anthropic은 병합 큐에 대한 업계 표준인 전역 저장소 잠금을 효과적으로 복제할 수 없었기 때문에 대신 병합 후 및 배포 전 자동화 테스트에 투자했습니다. 이는 동시 변경 사항이 충돌할 수 있음을 의미하지만 Anthropic은 Claude가 일반적으로 인간이 충돌을 식별하는 것보다 더 빨리 이러한 충돌을 수정할 수 있다고 말합니다.

Scion은 일반적인 사용을 위한 git 대체품이 아님

Anthropic은 Scion이 일반적인 사용을 위한 git의 적합한 대체품이 결코 아니라고 명시합니다. 설명된 개념은 수만 명의 엔지니어 또는 코드를 많이 작성하는 에이전트 무리가 있는 진정으로 거대한 모노레포에서만 의미가 있습니다. Anthropic은 또한 내부 사용을 위해 토큰을 지출하는 능력이 다른 어떤 비즈니스가 현실적으로 지출하려는 것보다 훨씬 뛰어나다는 점에서 독특하다고 언급합니다. 자체 소프트웨어 개발 요구를 해결하고 Claude의 능력을 테스트하기 위해서입니다.

실질적으로 Anthropic은 Scion을 다른 조직에 광범위하게 유용한 형태로 제공하는 것이 어려울 것이라고 말합니다. git과 크게 다르므로 회사는 개발 수명 주기의 모든 부분을 마이그레이션해야 하며 자체 코드 리뷰, 코드 검색 및 CI가 필요합니다. Anthropic의 이러한 구성 요소의 내부 버전은 매우 맞춤화되어 있어 다른 조직이 채택하기 어려울 것입니다. 모든 사람을 만족시키려는 공개 버전은 실제로 그다지 유용하지 않을 것이라고 우려합니다.

더 넓은 git 생태계에 대한 Anthropic의 제안

Anthropic은 이러한 종류의 문제가 향후 6~12개월 내에 더 일반화될 것으로 예상하며, git을 사용하는 모든 회사가 유사한 문제에 직면하는 것은 엔지니어링 리소스의 비효율적인 사용이라고 주장합니다. 따라서 기여는 Scion의 가장 성공적인 부분을 전체 모델에서 벗어나지 않고 git에 적용할 수 있도록 생각을 공유하는 것입니다.

Anthropic이 git에 대해 제안하는 구체적인 방향은 다음과 같습니다.

• git 서버는 git 클라이언트와 동일한 방식으로 작동할 필요가 없습니다. 상당한 확장 개선을 제공하는 새로운 서버 아키텍처가 존재합니다.
• git 플랫폼은 Scion과 같은 포괄적인 서버 측 RPC를 제공할 수 있으며, 아마도 git 클라이언트가 통신할 수 있도록 포지 간에 표준화된 방식으로 제공할 수 있습니다.
• 협상 프로토콜이 오늘날과 정확히 같을 필요는 없습니다.
• git의 다양한 스파스 및 얕은 기능이 잘 구성되도록 만들 수 있습니다.

Anthropic은 git 커뮤니티가 수백만 개발자를 위해 플랫폼을 확장하는 데 거의 20년을 보냈다는 점을 인정하며 마무리합니다. 자체 기여는 훨씬 더 좁은 범위, 즉 에이전트 소프트웨어 개발이 이러한 시스템과 상호 작용하는 방식에 대한 초기 관점을 공유하는 것이라고 설명하고, 소프트웨어 개발 수명 주기가 AI 지수 곡선과 교차함에 따라 개발자의 변화하는 요구를 지원하기 위해 GitHub, GitLab 및 OSS 커뮤니티와 협력하고 싶다고 말합니다.