Anthropic의 소스 제어 시스템 재설계

AI 요약

Anthropic은 2026년 5월 하루 평균 약 2,500건이던 코드 변경 병합량이 9월에는 3만 건을 넘었다고 밝혔습니다. 코드를 작성하는 속도보다 소스 제어와 빌드, CI 같은 개발 인프라가 병목이 되자 자체 버전 관리 시스템 Scion을 만들었습니다. 코드 리뷰 도구 Antique와 검색, 접근 제어 시스템도 함께 구축했으며, 7명으로 구성된 팀이 5개월 만에 모노레포 이전을 마쳤다고 설명합니다.

Git의 분산 구조가 대규모 모노레포에서 부담이 됐습니다

Git은 각 클라이언트가 저장소 전체를 복제해 오프라인에서도 이력 조회와 체크아웃을 할 수 있게 설계됐습니다. Anthropic의 모노레포는 메인 브랜치 이력만 약 100GB이고 압축된 작업 복사본도 25GB가 넘습니다. CI만 하루 약 2,500만 회 체크아웃을 수행합니다. 저장소를 매번 그대로 전송한다면 하루 Git 트래픽이 600PB를 넘을 수 있다고 회사는 추산했습니다.

Anthropic은 얕은 복제, sparse checkout, promisor remote와 내부 Git 미러, 저장소 스냅샷을 이미 사용했습니다. 한때 수백 개의 미러를 운영했지만 병합량이 늘자 관리 부담도 커졌습니다. 스냅샷이 메인 브랜치보다 뒤처지고 부분 복제 상태에서 diff와 blame 같은 이력 기능을 유지하기도 어려워졌습니다. 대부분의 클라이언트가 늘 온라인인 에이전트와 작업이라는 점에 착안해, 오프라인 사용을 우선하는 Git의 전제를 바꾸기로 했습니다.

서버가 연산하고 클라이언트는 필요한 데이터만 가져옵니다

Scion은 클라이언트가 온라인 상태라고 가정합니다. 클라이언트는 로컬 객체 캐시를 제한된 크기로 유지하고 파일을 디스크에 배치하며 파일 변경을 감지합니다. 이력 조회, blame, 커밋 생성, merge와 rebase 같은 작업은 서버가 처리합니다. 저장소를 묻는 기능은 API로도 제공해 CI나 자동화 도구가 소스 코드를 통째로 내려받지 않고 diff와 이력 정보를 요청할 수 있습니다.

Scion에서 작업 단위는 write-ahead log의 항목인 changeset입니다. Git 커밋처럼 트리 전체를 가리키는 대신 첫 번째 부모와 비교해 바뀐 파일 목록을 기록하고, 압축된 파일 내용은 content-addressed 방식으로 blob storage에 둡니다. changeset 생성에는 packfile이나 서버 간 조정, 전역 잠금이 필요하지 않습니다. 브랜치나 태그처럼 서버 간 합의가 필요한 ref 사용도 최소화합니다. ref를 옮길 때는 changeset 생성과 별도로 Spanner의 한 행에서 compare-and-swap을 수행합니다.

변경 기록만으로는 blame이나 경로별 이력을 빠르게 찾기 어려워 별도의 파생 데이터를 계산합니다. Scion은 changeset의 부모가 가진 값을 바탕으로 각 파생 데이터 값을 재귀적으로 구합니다. 데이터 종류마다 계산을 미리 하거나 요청이 올 때까지 미룰 수 있습니다. 클라이언트가 내부 자료 구조를 알 필요가 없어 서버 쪽에서 인덱스를 바꿔도 클라이언트는 그대로 쓸 수 있습니다. 회사는 경로 검색과 복사 감지를 위한 인덱스도 추가했다고 설명합니다.

계층형 캐시와 선택적 체크아웃

클라이언트의 데이터 요청은 특정 트리나 blob 객체를 대상으로 합니다. 클라이언트는 루트 트리부터 로컬 저장소에 없는 객체를 재귀적으로 요청합니다. 객체는 생성 뒤 바뀌지 않으므로 여러 캐시가 같은 요청에 응답할 수 있습니다. 큰 packfile 하나를 내려받는 방식이 아니라서 전송을 이어서 할 수 있고, sparse checkout이나 파일을 요청할 때만 가져오는 가상 체크아웃도 별도 협상 기능 없이 지원합니다.

각 노드의 scion-daemon은 주기적으로 갱신하는 스냅샷에서 시작하며 지역별 scion-cache와 통신합니다. 캐시는 객체를 클라이언트가 바로 쓸 수 있는 디스크 형식으로 메모리에서 전송합니다. 캐시에 없는 객체는 권한을 가진 scion-server가 Spanner나 클라우드 저장소에서 가져옵니다. 세 계층은 같은 RPC를 지원하지만 장애가 다른 계층으로 번지지 않도록 통신 경로를 제한합니다. 회사는 각 계층의 캐시 적중률이 99%를 넘고, 인프라의 CPU와 메모리 사용량은 기존 Git 미러링의 200분의 1이라고 밝혔습니다. CI와 연구 작업의 체크아웃은 분 단위에서 초 단위로 빨라졌고, CI에서 CPU 용량을 25% 절감했다고 합니다.

에이전트 규모에서 달라진 개발 방식

Anthropic은 Claude가 코드 작성과 최적화를 빠르게 했지만 시스템 설계와 제약 조건을 판단하는 엔지니어의 역할은 남았다고 설명합니다. 엔지니어는 모든 코드 줄을 읽기보다 변경 의도를 검토하고, 에이전트가 설계 원칙을 어기거나 가상적인 우려에 과도하게 대응하는 코드를 만들 때 방향을 바로잡았다고 합니다. 또 병합 대기열에서 전역 잠금을 유지하기 어려워 병합 뒤와 배포 전에 자동 테스트를 강화했습니다. 동시 변경으로 충돌이 생겨도 Claude가 사람이 충돌을 파악하는 시간보다 빨리 해결하는 경우가 있다고 덧붙였습니다.

Anthropic은 Scion을 일반적인 Git 대체재로 제시하지 않습니다. 수만 명 규모의 개발자나 다수의 에이전트가 코드를 자주 쓰는 거대한 모노레포에 맞춘 시스템이며, 도입하려면 코드 리뷰와 검색, CI까지 개발 생명주기 전반을 옮겨야 합니다. 대신 Git 서버의 아키텍처 개선과 서버 측 RPC, sparse 기능의 조합 등 Scion에서 얻은 아이디어를 기존 Git 생태계에 적용할 수 있다고 제안합니다.

Reddit 반응

• @u/cafepeaceandlove — 제 일은 원래도 매주 바뀌고 있었는데요.
  • @u/Majestic_Wrap_7006 — 2026년에 "적응하거나 도태되거나"라는 말이 더 실감 나네요.
  • @u/SloppyStone — 이제는 그냥 "도태되거나"네요.
• @u/ppooooooooopp — 놀랄 일은 아닙니다. 거대한 모노레포를 쓰는 대기업 대부분은 Git을 쓰지 않습니다. 놀라운 건 직원이 천 명 남짓한 회사가 벌써 그 규모에 도달했다는 점입니다.
  • @u/Key-Cranberry6537 — 자체 개발한 시스템을 씁니다. 글에서도 Google의 Piper와 Meta의 Sapling을 언급하네요.
• @u/GarboMcStevens — 해결책은 거대한 모노레포 하나를 만들지 않는 겁니다.
  • @u/Long_Corner_6857 — 많은 대형 기술 기업이 모노레포를 표준으로 삼는 데는 그럴 만한 이유가 있습니다.
• @u/Hot-Software-9396 — GitHub와 Git은 다릅니다. GitHub의 강점은 대부분의 사람이 이미 그곳에 있다는 점입니다. 누구나 Reddit을 복제할 수 있지만 대다수가 새 플랫폼으로 옮기지 않으면 달라지는 건 없습니다.
  • @u/Legitimate_Concern_5 — 대형 모노레포를 가진 대기업의 문제입니다. 글에서도 말하듯 Meta와 Google은 이미 자체 시스템을 씁니다. Anthropic이라 AI를 앞세웠지만 이 문제는 AI와 거의 상관없는 대형 모노레포 문제입니다. Git은 대부분에 적합하지만 모든 저장소에 맞지는 않습니다.
• @u/swizz — Scion은 Perforce와 꽤 비슷하게 들립니다. Perforce v2라고 부르겠습니다.
  • @u/Key-Cranberry6537 — 간단히 찾아보니 Perforce와 Scion의 기본 아키텍처는 상당히 다른 것 같습니다. 둘이 아주 비슷하다고 보기는 어렵습니다.
• @u/pseudonerv — Git을 중앙 집중식 버전 관리 시스템처럼 쓰지 말아야 한다는 생각은 안 해봤나요? 새 바퀴를 발명하는 대신에요. Claude가 그렇게 제안했나 봅니다.
  • @u/crusoe — Git이 분산형이라는 점이 문제였습니다.
• @u/sampaoli_negro_rojo — 공개해줘서 고맙네요. 오픈소스로도 공개하면 더 좋겠습니다. 사람들이 같은 걸 재현하려고 수백만 달러어치 토큰을 쓰게 하는 게 계획인가 봅니다.
• @u/cantgetthis — Meta의 소스 제어 시스템을 그대로 복사해서 이름만 붙였습니다. 파생 데이터 같은 고유한 개념도 일대일로 가져왔습니다. 지식재산권을 정말 함부로 다루네요.
  • @u/fsharpman — GPL 라이선스 도구를 복사하는 일이 왜 지식재산권 침해인지 설명해줄 수 있나요?

원문: Anthropic Engineering / 번역·요약: Trawling