Anthropic의 Scion: 에이전트 규모 모노레포를 위한 소스 컨트롤 재설계

Anthropic은 자체 버전 관리 시스템인 Scion을 구축하고 5개월 만에 모노레포를 git에서 완전히 이전했다고 발표했습니다. 이는 인간 규모를 위해 설계된 개발자 인프라(소스 컨트롤, 빌드, CI)가 이제 Claude가 회사 코드의 대부분을 작성하면서 병목 지점이 되었기 때문입니다. 이 글은 제품 출시가 아닌 Scion 설계에 대한 기술 사례 연구입니다. Anthropic은 Scion이 git의 범용 대체재로 적합하지 않으며 광범위하게 제공할 계획이 없다고 명확히 밝히고 있습니다.

문제: 병합 볼륨이 git을 초과함

Anthropic의 병합 속도는 4개월 만에 약 10배 증가했으며, 회사는 이러한 성장이 둔화될 것으로 예상하지 않습니다. 2026년 5월, Anthropic은 하루 평균 약 2,500개의 코드 변경을 병합했습니다. 2026년 9월 현재, 하루 30,000건 이상을 병합합니다. Anthropic은 코드 병합에 대한 잠재적 수요를 "실질적으로 무한하다"고 설명하며, 병목 현상이 제거될 때마다 즉시 생산되는 코드 양이 더욱 증가한다고 지적합니다.

모노레포의 규모는 인프라 부담의 직접적인 원인입니다. 메인 브랜치의 히스토리만 해도 거의 100GB에 달하며, 압축된 작업 복사본은 25GB가 넘습니다. Anthropic은 개발자 환경, 에이전트 샌드박스, 연구 작업을 제외하고 CI를 위해 하루 약 2,500만 건의 코드 체크아웃을 수행합니다. 이를 단순하게 가져오면 하루 600PB 이상의 git 트래픽이 발생합니다.

git의 분산 설계(모든 클론이 완전하고 독립적인 저장소이며, 완전히 오프라인 상태에서도 diff 계산, 히스토리 및 blame 읽기, 모든 리비전 체크아웃이 가능한 설계)는 대다수 저장소에 적합한 설계이며, Anthropic은 이를 명시적으로 인정합니다. 단지 이 작업 부하에는 맞지 않을 뿐입니다. Anthropic은 얕은 클론, 희소 체크아웃, 프로미서 리모트, 내부 git 미러, blob 스토리지의 저장소 스냅샷(시드)을 사용했습니다. 최대치에서 회사는 수백 개의 내부 git 미러를 운영하여 부하를 처리했습니다. 이러한 해결 방법은 시간을 벌어 주었지만 병합 속도가 증가함에 따라 운영이 더 어려워졌습니다. 시드는 새로 고침 사이에 메인 팁에서 더 멀어졌고, 부분 클론에서 diff 및 blame과 같은 히스토리 종속 작업을 유지하려면 더 많은 주의가 필요했습니다.

Scion을 고안하게 된 핵심 관찰: Anthropic은 git을 하나의 권위 있는 사본이 있는 중앙 집중식 시스템으로 사용하고 있었지만, 거의 모든 클라이언트가 정의상 온라인 상태인 에이전트와 작업이었습니다. 분산된 오프라인 작업에 탁월한 git의 속성은 저장소가 커짐에 따라 Anthropic의 확장 능력을 적극적으로 약화시키고 있었습니다.

에이전트 규모 소스 컨트롤을 위한 6가지 원칙

Scion은 git과 다른 가정 집합을 기반으로 설계되었습니다. Anthropic은 대규모 모노레포 소스 컨트롤의 선례(Google의 Piper와 Meta의 Sapling)가 설계에 영향을 주었다고 밝히고 있습니다.

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

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

포괄적인 소스 컨트롤 서비스는 많은 새로운 애플리케이션을 지원할 수 있습니다. git을 사용하면 저장소에 대해 질문(마지막으로 줄을 변경한 사람, 두 커밋의 관계 등)해야 하는 CI 작업이나 도구는 저장소의 로컬 복사본을 유지하거나 공급업체별 API에 의존해야 합니다. Scion을 사용하면 클라이언트가 사용하는 모든 소스 컨트롤 쿼리가 API를 통해서도 노출되므로, 많은 경우 작업에 로컬 저장소가 전혀 필요하지 않습니다. Anthropic은 자동 이분 탐색 및 되돌리기 파이프라인과 같은 많은 내부 도구가 이러한 저렴하고 프로그래밍 방식의 소스 컨트롤 액세스 없이는 대규모로 실용적이지 않을 것이라고 밝히고 있습니다.

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

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

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

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

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

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

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

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

Scion 확장: 계층형 캐시 아키텍처

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

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

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

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

측정된 결과

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

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

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

Anthropic은 Claude Mythos Preview와 Claude Tag가 내부적으로 제공되기 시작한 것과 거의 같은 시기에 Scion 구축을 시작했습니다. 이 글은 두 릴리스가 동시에 Scion에 대한 필요성을 증폭시키고 구축 속도를 의미 있게 가속화했다고 밝히고 있습니다.

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

소규모 팀의 빠른 개발이 더 일반화될 것입니다

7명의 팀이 Scion과 Antique(Anthropic의 코드 검토 도구) 및 6개 이상의 관련 시스템을 구축하고 5개월 만에 완전히 이전했습니다. 이 모든 과정은 하루에 병합되는 코드 양이 10배 증가하는 동안 이루어졌습니다. Anthropic은 이와 같은 소스 컨트롤 시스템을 개발하고 배포하는 데는 이전에는 회사가 더 많은 엔지니어와 함께 수년간의 반복적 마이그레이션이 필요했을 것이라고 지적하며, 이러한 빠르고 민첩한 마이그레이션이 더 일반화될 것으로 기대합니다.

엔지니어의 가치는 줄어들지 않지만, 그들의 작업은 변화하고 있습니다

Anthropic은 이 시스템에서 작업한 모든 엔지니어가 이제 Claude가 코드 작성에서 자신보다 낫다고 평가할 것이라고 밝히고 있습니다. 그러나 엔지니어는 여전히 높은 수준의 시스템 간 구성 요소와 설계 수준의 트레이드오프에 대한 이해를 제공하여 어떤 문제를 해결하고 어떤 규모를 달성할지 정보에 입각한 선택을 했습니다. Anthropic은 엔지니어의 역할이 종종 Claude에게 "아니요"라고 말하는 것이라고 설명합니다.

에이전트는 때때로 처음부터 허용되지 않았어야 할 패턴을 충족시키기 위해 핵심 시스템 제약 조건을 위반합니다.

이는 마이그레이션 중에 특히 일반적이었습니다. 예를 들어, 여러 시스템이 코드 검토 도구에 묻는 대신 커밋 로그를 선형으로 읽어 변경 사항이 메인에 병합된 시기를 찾으려고 무차별 대입 방식으로 시도했습니다. Anthropic은 또한 적대적 검토를 광범위하게 사용하는데, 이는 매우 효과적이지만 때로는 근시안적이라고 설명하므로 숙련된 엔지니어는 가상의 우려에 대응하여 시스템의 일부를 과도하게 엔지니어링하지 않도록 Claude를 유도해야 했습니다. 그러한 검토 중 하나는 다른 내부 서비스를 신뢰하는 데 지나치게 방어적이어서 Claude가 과도한 검증과 복잡성을 추가하게 되었습니다. 팀원들은 여전히 시스템에 대한 모든 변경 요청을 검토하지만 이제는 모든 코드 줄을 읽는 대신 변경의 의도를 검토합니다.

최적화 및 품질이 크게 향상됨

Claude가 인간보다 훨씬 빠르게 엄청난 양의 코드를 작성할 수 있기 때문에 Anthropic은 Scion을 지금까지 작업한 코드베이스 중 가장 잘 테스트되고 잘 방어된 코드베이스 중 하나라고 설명합니다. 빠듯한 일정 속에서도 팀은 경험한 모든 사소하지 않은 인프라 및 소스 컨트롤 상호 작용에 대한 폐쇄적 시뮬레이션, 퍼징, 정교한 속도 제한을 구축했습니다. Claude는 또한 중요한 최적화를 찾아냈습니다. 예를 들어 팀의 인덱스 중 하나를 놓친 조상 쿼리에 대한 알고리즘 최적화로, 전문가가 며칠 또는 몇 주간의 분석과 튜닝이 필요했을 것이라고 Anthropic은 말하며, 다음 날에도 다시 수행했습니다.

새로운 형태의 모노레포 보안을 위한 기반

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

새로운 수준의 운영 우수성이 가능합니다

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

Anthropic은 기존의 가정을 다시 생각하고 있습니다

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

Scion은 git 대체품이 아니며 Anthropic은 오픈소스로 공개하지 않습니다

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

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

대신 Anthropic은 가장 영향력 있는 일은 생각을 공유하여 다른 개발자가 git에 Scion의 가장 성공적인 부분을 적용할 수 있도록 하는 것이라고 말합니다. 이 글의 구체적인 제안은 다음과 같습니다.

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

Anthropic은 이러한 종류의 문제가 향후 6~12개월 내에 더 흔해질 것으로 예상하며, git을 사용하는 모든 회사가 유사한 문제에 직면하는 것은 엔지니어링 리소스의 비효율적인 사용이라고 주장합니다. 이 글은 git 커뮤니티가 수백만 개발자를 위해 플랫폼을 확장하는 데 거의 20년을 보냈다는 점을 인정하면서 마무리되며, Anthropic의 기여를 더 좁은 범위로 설명합니다. 즉, 에이전트 소프트웨어 개발이 이러한 시스템과 어떻게 상호 작용하는지에 대한 초기 관점을 제공하여 GitHub, GitLab 및 오픈 소스 커뮤니티와 협력하는 것입니다.

기술 각주

Scion은 병합의 첫 번째 부모를 기준으로 변경된 파일을 저장합니다. Anthropic은 이를 스타일상의 선택으로 설명하며, 실제로 사람들은 모노레포의 트렁크 기반 개발에서 메인 라인의 커밋에 대한 히스토리나 blame에만 관심이 있다고 지적합니다.

이 글은 Nick G.와 소스 컨트롤 팀(S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P.)이 작성했으며, 팀을 지원한 Vilas J.와 Sergiu D., 그리고 Antique에 초기 기여를 한 Amir O.에게 감사를 표합니다.