Git이 모자랐던 이유? Anthropic Scion · 모노레포 · AI 에이전트

하루에 병합되는 코드 변경이 5개월 만에 12배 넘게 늘었다면, 여러분의 개발 인프라는 어디부터 무너질까요? Anthropic은 2026년 5월에 하루 평균 약 2,500건이던 병합이 9월에는 하루 3만 건을 넘었다고 밝혔어요. 그리고 그 답으로 Git을 버리고 Scion이라는 자체 버전 관리 시스템을 만들었어요.

이 글은 Anthropic 엔지니어링 블로그 원문과 Simon Willison의 소개글, 그리고 이에 대한 반응을 확인한 내용을 바탕으로 해요. 사실은 원문에서 확인한 것만 적고, 제 해석은 따로 표시했어요.

왜 Git이 문제가 됐을까요

Git은 분산 시스템이에요. 클론하면 저장소 전체가 내 컴퓨터에 들어오고, 그래서 diff, 히스토리, blame, 체크아웃을 인터넷 없이 다 할 수 있어요. 대부분의 저장소에는 이게 정답이고, Git이 표준이 된 큰 이유이기도 해요.

문제는 규모예요. Anthropic이 밝힌 숫자를 보면 이렇게 돼요.

• main 브랜치 히스토리만 거의 100GB
• 압축한 작업 사본만 25GB 이상
• CI용 코드 체크아웃이 하루 약 2,500만 번 (개발자 환경, 에이전트 샌드박스, 연구 작업은 제외한 수)
• 그대로 Git으로 받으면 하루 600PB가 넘는 트래픽

AI · DEV · SCALEGit으로 그대로 받으면모노레포 규모가 만든 문제THE ROVER

100GBmain 히스토리작업 사본은 25GB 이상

2,500만CI 체크아웃/일

600PB+하루 트래픽Git으로 그대로 받을 때

기존 우회책의 한계

Git에도 대형 저장소를 위한 도구가 있어요. 얕은 클론(shallow clone), 스파스 체크아웃, 프로미서 리모트 같은 것들이에요. 사내 Git 미러를 두거나, 저장소 스냅샷(시드)을 블롭 스토리지에 두는 방법도 흔해요.

Anthropic도 이걸 다 써봤고, 피크 때는 사내 Git 미러만 수백 대를 운영했다고 해요. 시간은 벌었지만 병합 속도가 올라갈수록 운영이 어려워졌어요. 시드는 refresh 사이에 main의 최신 지점에서 점점 멀어졌고, 부분 클론에서 diff나 blame처럼 히스토리에 의존하는 작업을 유지하려면 점점 더 많은 공이 들었어요.

질문을 바꾸다

여기서 Anthropic이 한 발 물러서서 본 지점이 흥미로워요. 대부분의 회사처럼 Git을 "권위 있는 사본이 하나 있는 중앙집중형"으로 쓰고 있는데, 클라이언트 거의 전부가 에이전트와 작업(job)이고 이들은 정의상 항상 온라인이라는 거예요. 오프라인과 분산에 최적화된 성질이 오히려 확장을 막고 있었던 거죠.

그래서 질문을 이렇게 바꿨어요. "에이전트가 항상 온라인이라는 전제로 처음부터 설계한다면 소스 컨트롤은 어떤 모습일까?"

Scion의 설계 원칙

원문은 원칙 여섯 가지를 들어요. 표로 Git과 비교해 볼게요. 비교 열은 원문 설명을 제가 줄여 정리한 거예요.

몇 가지를 풀어서 볼게요.

서버가 똑똑하고 클라이언트는 가볍게

Git에서는 모든 클라이언트가 완전한 서버가 될 수 있어요. Scion은 반대로 가요. 파일 히스토리와 blame에 답하고, 커밋을 만들고, 병합과 리베이스를 하는 건 서버예요. 클라이언트는 제한된 로컬 객체 캐시를 두고, 디스크에 파일을 배치하고, 파일시스템 변경을 감시하는 정도예요. 혼자 계산할 수 있는 건 거의 없지만, 그 대가로 로컬에 필요한 데이터가 훨씬 적어요.

소스 컨트롤을 API로

Git에서 CI 작업이 "이 줄을 마지막으로 바꾼 사람이 누구야?" 같은 질문을 하려면 저장소를 로컬에 받아두거나 호스팅 업체의 API에 기대야 해요. Scion은 클라이언트가 쓰는 쿼리를 전부 API로도 열어두기 때문에 많은 경우 작업이 로컬 저장소 없이도 돼요. 원문은 자동 bisect와 revert 파이프라인 같은 내부 도구가 이렇게 싸고 프로그래밍하기 쉬운 접근 없이는 대규모에서 현실적이지 않았을 거라고 말해요.

브랜치와 락을 줄이기

Scion 개발 흐름은 main이나 릴리스 브랜치를 제외한 ref(브랜치, 태그 같은 커밋 포인터)를 권장하지 않아요. 모든 서버가 합의해야 하는 전역 상태는 확장 문제를 부르기 때문이에요. 커밋 비용은 저장소 전체 크기가 아니라 변경 크기에 비례해야 하고, 락도 없어야 한다는 게 원칙이에요.

Scion은 어떻게 동작할까요

변경셋과 파생 데이터

Scion의 작업 단위는 "변경셋(changeset)"이고, 쓰기 선행 로그(write-ahead log)의 한 항목이에요. Git 커밋이 트리 포인터를 저장한다면, 변경셋은 첫 번째 부모 대비 바뀐 파일 목록과, 블롭 스토리지에 있는 압축된 파일 내용을 가리키는 콘텐츠 주소 포인터를 저장해요. 서버가 만들고, 만들자마자 어디서나 쓸 수 있어요.

이 구조 덕에 packfile도, 락도, 서버 간 조정도, 옮길 ref도 없이 높은 처리량으로 변경셋을 받을 수 있어요. ref는 기술적으로 지원하지만, 이동은 Spanner의 한 행에 대한 compare-and-swap이고 변경셋 생성과는 따로 일어나요.

변경셋은 "바뀐 것"만 기록하기 때문에 "누가 이 줄을 마지막에 수정했지?" 같은 질문에는 바로 답하지 못해요. 그래서 변경셋에서 추가 자료구조를 만들어요. 파일 blame, 경로 히스토리, 커밋 그래프용 skip list 같은 것들이에요. 변경셋 자체가 아닌 모든 것을 원문은 "파생 데이터(derived data)"라고 불러요. 각 종류는 재귀적으로 정의돼서, 한 변경셋의 값은 그 부모들의 값으로부터 계산돼요.

원문이 꼽은 장점은 세 가지예요.

1. 새 자료구조가 필요하면 새 파생 데이터 종류를 쉽게 추가할 수 있어요.
2. 종류별로 미리 계산할지 미룰지 고를 수 있어요.
3. 내부 구조를 클라이언트가 보지 않기 때문에 클라이언트를 바꾸지 않고 최적화할 수 있어요.

체크아웃 구조

Scion 서버는 소스 컨트롤 API를 제공하는 작은 서버군이에요. 모든 데이터가 콘텐츠 주소 방식이라 한 번 저장되면 바뀌지 않고, 어느 서버든 다른 서버에 확인하지 않고 캐시할 수 있어요. 그래서 서버는 사실상 "파생 데이터를 즉석에서 계산해 Spanner에 다시 써주는 큰 캐시"에 가까워요.

scn 클라이언트는 Git의 fetch 프로토콜과 다르게 움직여요. 협상 단계에서 "내가 이미 가진 것"을 서버에 알리지 않고, 원하는 트리와 블롭만 요청해요. 루트 트리에서 시작해 로컬에 없는 트리를 재귀적으로 요청하고, 그다음 블롭도 같은 식으로 받아요. 모든 요청이 변하지 않는 특정 객체에 대한 것이라 어떤 캐시든 답할 수 있고, 계층형 캐시와 매우 닮은 구조가 돼요. 거대한 packfile 응답이 없으니 재개도 쉬워요. 스파스나 가상화 체크아웃도 클라이언트가 원하지 않는 트리를 그냥 요청하지 않으면 되니까 특별한 지원이 필요 없어요.

노드에서는 scion-daemon이 노드 전체의 객체를 저장하고, 지역 단위의 scion-cache와만 통신해요. 캐시에 없으면 권위 있는 scion-server에 묻고, 서버는 필요에 따라 Spanner나 클라우드 스토리지에서 읽어요. 세 계층은 같은 RPC에 응답하지만 계층 구조를 엄격히 강제해서, 지역 캐시 장애가 상위 서버까지 번지지 않게 장애 영역을 분리했어요.

AI · DEV · CHECKOUT체크아웃 3계층없으면 한 단계 위에 묻는다THE ROVER

노드scion-daemon

지역scion-cache

권위scion-server

계층마다 캐시 적중률 99% 이상

결과

원문이 밝힌 수치는 이래요.

• 각 계층의 캐시 적중률은 99% 이상
• Scion 인프라는 기존 Git 미러링 인프라보다 CPU와 메모리 요구량이 200배 작음
• CI와 연구 작업의 체크아웃이 두 자릿수 배 빨라짐 (분 단위에서 초 단위로)
• CI만으로 CPU 용량 25% 절감

5개월, 7명, 그리고 Claude

더 눈길이 가는 건 만든 방식이에요. 원문에 따르면 7명이 Scion과 코드 리뷰 도구 Antique, 그리고 관련 시스템 여섯 개 정도를 만들고 5개월 만에 전환을 마쳤어요. 그 사이 하루 병합량은 10배 늘었어요. 과거 같으면 훨씬 많은 인원과 몇 년의 점진적 이전이 필요했을 거라고 Anthropic은 말해요.

사람의 역할은 "아니요"라고 말하는 것

원문에서 가장 현실적인 대목이에요. 참여 엔지니어 모두 Claude가 자신들보다 코드를 더 잘 쓴다고 평가하지만, 시스템 간 구조와 설계 상의 트레이드오프를 판단하는 건 사람이었다고 해요. 그리고 종종 사람의 일은 Claude에게 "안 돼"라고 말하는 것이었다고 해요.

예를 들어 여러 시스템이 "언제 main에 병합됐는지"를 코드 리뷰 도구에 묻지 않고 커밋 로그를 선형으로 읽어서 찾으려 했어요. 에이전트가 핵심 제약을 어기고 패턴을 맞추려는 사례예요.

적대적 리뷰(adversarial review)도 비슷해요. 효과는 크지만 근시안적일 수 있어서, 가상의 우려에 과잉 대응해 시스템을 복잡하게 만들지 않도록 숙련 엔지니어가 방향을 잡아줘야 했다고 해요. 원문 예시로는 다른 내부 서비스를 신뢰하는 데 지나치게 방어적인 리뷰 때문에 Claude가 불필요한 검증을 잔뜩 넣었다는 사례가 나와요. Simon Willison도 자신의 프로젝트에서 모델끼리 교차 리뷰를 시켜보면서 같은 경험을 했다고 적었어요.

팀원은 여전히 모든 변경 요청을 리뷰하지만, 이제는 모든 줄을 읽기보다 변경의 의도를 본다고 해요.

품질과 운영

Claude가 많은 코드를 빠르게 쓸 수 있어서 Scion은 "가장 잘 테스트되고 방어된 코드베이스"가 됐다고 원문은 말해요. 사람이 만났던 인프라와 소스 컨트롤 상호작용을 재현하는 격리 시뮬레이션, 퍼징, 정교한 속도 제한까지 짧은 일정 안에 넣었다는 거예요. 조상(ancestry) 쿼리의 알고리즘을 개선하다 인덱스 하나를 놓친 것도 Claude가 찾아냈는데, 전문가라면 며칠에서 몇 주가 걸렸을 일이라고 해요.

운영에서는 Claude를 구성요소 하나의 상태에만 집착하게 하는 "superfan"을 슬랙 채널에 두었어요. scion-daemon superfan, scion-cache superfan, Antique 머지 큐 superfan 같은 식이에요. 텔레메트리와 로그를 보면서, 차트를 계속 새로고침하며 이상한 점을 찾는 경력 엔지니어 역할을 해요. 전통적 알림도 있지만 superfan은 미묘하고 새로운 이상을 잡는다고 해요.

머지 큐가 의미를 잃을 때

저는 이 부분이 가장 시사점이 크다고 봤어요. 원문은 "머지 큐는 에이전트 규모에서는 맞지 않는다"고 말해요. 수백, 수천 건이 테스트가 도는 동안 병합될 수 있으면 CI가 무슨 의미인지 되묻는 거예요. 업계 표준인 머지 큐의 전역 저장소 락을 효과적으로 재현하지 못했다고 해요. 그래서 대신 병합 후, 배포 전 자동 테스트에 투자했어요.

원문은 이 방식이 동시 변경 간 충돌을 허용하게 된다고 인정해요. 다만 Claude가 대체로 사람이 알아차리기도 전에 충돌을 고친다고 말해요. 이게 모든 조직에 통하는 전략이라는 얘기는 아니에요. 같은 원문이 Anthropic은 내부에서 쓸 수 있는 토큰 예산이 다른 기업이 현실적으로 쓰고 싶어 할 수준을 훨씬 넘는다고 스스로 단서를 달았어요.

선행 사례와 논쟁

Scion이 아무것도 없는 곳에서 나온 건 아니에요. 원문은 Google의 Piper와 Meta의 Sapling을 대형 모노레포 소스 컨트롤의 선행 사례로 들어요. 10월 15일 수정에서는 Sapling의 서버 구성요소인 Mononoke가 Scion이 쓰는 기법 상당수를 개척했고, 특히 Bonsai 데이터 모델이 그렇다는 각주를 추가했어요.

이 수정은 이유가 있어요. Mononoke 개발에 참여했던 sunshowers는 블로그 글에서 "파생 데이터" 개념이 Mononoke 설명과 매우 비슷하다고 짚으며, 초기 글에서 Mononoke가 언급되지 않은 건 표절에 가깝다고 비판했어요. 동시에 설계를 가져다 쓰는 것 자체에는 문제가 없다고도 했고, LLM이 설계를 도울수록 학습 데이터에 있는 기존 설계에 기대기 쉬워지니 출처를 밝히는 게 더 중요해진다고 주장했어요. 이건 한 개인의 평가이고 Anthropic의 입장은 아니니, 둘을 구분해서 읽으면 돼요.

개인적으로는 이 논쟁에서 기술적으로 얻을 점이 하나 있다고 봐요. 에이전트가 만든 설계가 새로워 보여도 이미 알려진 설계의 재발견일 수 있어요. 그래서 "선행 사례를 찾아라"를 프롬프트와 리뷰 절차에 넣어둘 만해요.

우리 팀에 주는 시사점

Anthropic 본인들이 가장 먼저 못 박은 게 있어요. Scion은 Git의 범용 대체재가 아니에요. 개념이 의미를 가지려면 엔지니어가 수만 명이거나 에이전트 무리가 코드를 쏟아내는 정말 거대한 모노레포여야 하고, Scion은 자체 코드 리뷰, 검색, CI가 필요해서 다른 조직이 가져다 쓰기도 어렵다고 해요. 그러니 "우리도 Git을 버리자"가 결론은 아니에요.

대신 원문이 제안한 방향이 실용적이에요. Git 서버가 Git 클라이언트와 똑같이 동작할 필요는 없고, 확장성이 좋은 새 서버 구조가 있을 수 있다는 거예요. 포지(forge) 플랫폼이 Scion처럼 포괄적인 서버 측 RPC를 제공하고, 협상 프로토콜을 바꾸고, 스파스와 얕은 기능을 잘 조합되게 만들 수 있다고 말해요. 또 GitHub, GitLab, 오픈소스 커뮤니티와 협력하고 싶다고 했어요.

제가 읽은 실무적 교훈을 체크리스트로 정리해 볼게요. 원문의 주장을 일반 팀 상황에 옮긴 제 해석이에요.

마지막으로 한 가지만 덧붙일게요. 이 글에서 가장 오래 남은 문장은 숫자가 아니라 "코딩이 더 이상 병목이 아니다"라는 첫 문단이었어요. 코드를 쓰는 속도가 올라가면 병목은 소스 컨트롤, 빌드, CI 같은 사람 규모에 맞춰진 인프라로 옮겨가요. 지금 우리 팀의 병목이 어디인지 한 번 그려 보는 것만으로도 이 글을 읽은 값은 충분하다고 생각해요.