하루 3만 건 병합에 git이 버티지 못하자 Anthropic은 자체 버전 관리 시스템 Scion을 만들었습니다 | DAKER 커뮤니티

Anthropic이 사내 모노레포를 git에서 자체 버전 관리 시스템 Scion으로 옮겼다고 공개했습니다. 2026년 5월 하루 평균 약 2,500건이던 코드 병합이 9월에는 하루 3만 건을 넘기면서 소스 관리가 가장 큰 개발 병목이 됐기 때문입니다. Anthropic 엔지니어링 블로그 글은 10월 13일 처음 게시됐고 10월 15일 내용이 보강됐으며, Claude 블로그 목록에는 10월 19일 소개됐습니다. 이 글은 10월 20일 기준 원문을 확인해, AI 코딩 도구를 많이 쓰는 국내 개발팀이 미리 알아 둘 내용을 정리합니다.

수많은 가지가 하나의 줄기로 모이는 나무를 크레용으로 그린 설명용 생성 이미지 모션 미리보기 — 설명을 돕기 위해 만든 생성 이미지입니다.

수많은 가지가 하나의 줄기로 모이는 나무를 크레용으로 그린 설명용 생성 이미지 — 설명을 돕기 위해 만든 생성 이미지입니다.

git이 병목이 된 숫자

원문에 따르면 Anthropic 메인 브랜치의 이력만 100GB에 가깝고, 압축한 작업 사본도 25GB를 넘습니다. CI를 위한 코드 체크아웃은 하루 2,500만 회 수준이며, 개발 환경과 에이전트 샌드박스, 연구 작업은 여기에 포함되지 않은 숫자입니다. 이를 그대로 git으로 받아 오면 하루 600PB가 넘는 트래픽이 된다고 Anthropic은 계산했습니다. 얕은 클론, 희소 체크아웃, 내부 미러를 모두 써 봤고 한때는 git 미러를 수백 대 운영했지만, 병합 속도가 오를수록 운영이 어려워졌다고 설명합니다.

Anthropic은 클라이언트 대부분이 항상 온라인인 에이전트와 작업이라는 점에 주목해, 처음부터 그 사실을 전제로 소스 관리를 다시 설계했다고 밝혔습니다.

Scion이 git과 다르게 만든 원칙

Scion은 서버 중심 구조입니다. 파일 이력과 blame 계산, 커밋 생성, 병합과 리베이스는 모두 서버가 처리하고, 클라이언트는 크기가 제한된 로컬 객체 캐시와 작업 파일 배치만 맡습니다. 클라이언트가 쓰는 소스 관리 질의는 모두 API로도 열려 있어, 많은 CI 작업은 로컬 저장소 없이 서버에 바로 diff나 병합 기준점을 묻습니다. 작업 사본은 선택 사항이며, 요청한 디렉터리만 받는 희소 체크아웃과 읽을 때 파일을 채우는 가상 체크아웃이 기본입니다.

데이터 구조도 다릅니다. 작업 단위는 쓰기 선행 로그에 기록되는 changeset이며, 첫 번째 부모 대비 바뀐 파일 목록과 내용 주소 기반 포인터를 담습니다. 커밋 비용이 저장소 전체 크기가 아니라 변경 크기에 비례하도록 만든 것이 핵심입니다. 캐시 계층마다 적중률이 99%를 넘고, 인프라 규모는 이전 git 미러링 대비 CPU와 메모리 기준으로 200분의 1이 됐습니다. CI와 연구 작업의 체크아웃은 분 단위에서 초 단위로 줄었고, CI만 따져도 CPU 용량의 25%를 아꼈다고 합니다.

7명이 5개월 만에 옮긴 방법

Scion과 코드 리뷰 도구 Antique는 7명으로 구성된 팀이 만들었고, 마이그레이션까지 5개월이 걸렸습니다. 원문은 Claude가 이 속도를 가능하게 했다고 설명합니다. 사람이 손으로 짠 git-to-Scion 수집 파이프라인 시제품을 Claude Mythos Preview의 내부 초기 버전에게 다시 작성하게 했더니, 메모리는 20분의 1만 쓰고 속도는 4배 빨라졌다는 사례도 소개됩니다. 다만 엔지니어의 역할이 사라진 것은 아니라고 강조합니다. 시스템 제약을 어기려는 에이전트를 멈추는 판단, 과도한 방어 코드를 걷어 내는 판단은 여전히 사람이 했고, 리뷰는 모든 줄을 읽기보다 변경 의도를 확인하는 방식으로 바뀌었습니다.

국내 개발팀이 지금 확인할 것

Anthropic은 Scion이 일반적인 git 대체재가 아니며 외부에 그대로 제공하기도 어렵다고 분명히 했습니다. 대신 이런 문제가 앞으로 6~12개월 안에 더 흔해질 것으로 보고, GitHub, GitLab, 오픈소스 커뮤니티와 함께 git 서버 쪽 개선을 논의하고 싶다고 밝혔습니다. 코딩 에이전트로 PR을 많이 만드는 팀이라면 하루 병합 건수, CI 체크아웃 시간, 저장소 크기 추이를 먼저 기록해 두는 편이 좋습니다. 체크아웃이 길어진다면 희소 체크아웃이나 부분 클론처럼 git이 이미 제공하는 기능부터 점검할 수 있습니다. 해커톤처럼 짧은 기간에 여러 에이전트가 같은 저장소를 고치는 상황이라면, 병합 충돌을 누가 어떤 기준으로 정리할지 미리 정해 두는 것도 같은 교훈입니다.

원문은 Anthropic 엔지니어링 블로그 https://www.anthropic.com/engineering/redesigning-source-control에서 읽을 수 있습니다. 같은 회사가 코드 리뷰 자동화를 정식 출시한 소식은 DAKER 커뮤니티 정리 글에서 함께 볼 수 있습니다.

여러분의 팀은 에이전트가 만든 변경을 하루에 몇 건이나 병합하고 있습니까? 저장소나 CI 가운데 어느 쪽이 먼저 느려졌습니까?