코드를 더 빨리 작성해도 테스트할 코드를 내려받는 데 몇 분씩 걸리면 개발은 그만큼 빨라지지 않는다. Anthropic이 10월 13일 공개한 사례에서는 변경사항을 저장하고 여러 작업을 합치는 버전 관리 인프라가 병목이 됐다. 회사는 Git으로 운영하던 대형 통합 저장소를 자체 시스템 Scion으로 옮겼다. 코드 검토 도구 Antique와 관련 시스템의 구축, 전환까지 7명이 5개월에 끝냈다.
달라진 것은 작업량이다. Anthropic의 하루 평균 코드 변경 병합은 2026년 5월 약 2,500건에서 9월에는 3만 건 이상으로 늘었다. 회사는 Claude가 연구용 코드를 반복 수정하고 새 서비스를 만드는 속도가 빨라지면서, 사람의 작업량을 전제로 만든 저장소와 빌드·테스트 인프라가 이를 따라가지 못했다고 설명한다.
저장소를 내려받는 작업이 왜 이렇게 커졌나
Git은 네트워크가 끊겨도 변경 이력을 확인하고 작업할 수 있도록 설계됐다. 일반적인 전체 복제본은 그 자체로 독립된 저장소다. 여러 사람이 각자 작업한 뒤 변경사항을 공유하기에 편리하지만, 거대한 저장소를 짧게 실행되는 자동 작업들이 반복해서 가져갈 때는 비용이 커진다.
Anthropic의 main 브랜치 이력은 거의 100GB였고, 압축한 작업용 사본도 25GB가 넘었다. CI, 즉 코드 변경을 자동으로 빌드하고 시험하는 작업에서만 하루 약 2,500만 번 코드를 체크아웃했다. 개발 환경과 연구 작업은 이 수에 들어가지 않는다. 회사가 제시한 하루 600PB 이상의 전송량은 매번 단순하게 전체를 가져온다고 가정한 계산이지, 실제로 그만큼 전송했다는 뜻은 아니다.
이미 필요한 이력이나 디렉터리만 받는 Git 기능, 내부 미러 서버, 미리 저장한 저장소 사본을 사용하고 있었다. 내부 미러는 한때 수백 대에 달했다. 그러나 병합이 빨라질수록 미리 만든 사본은 최신 코드에서 더 멀어졌다. 부분 복제본에서 변경 비교나 줄별 수정 이력을 정확하게 제공하는 운영도 까다로워졌다.
각 작업이 이력을 들고 있지 않으면 무엇이 달라지나
Scion은 대부분의 사용자가 항상 온라인인 에이전트와 자동 작업이라는 조건에서 출발했다. 파일의 수정 이력 조회, 변경 비교, 커밋 생성과 병합은 서버가 맡는다. 클라이언트는 제한된 크기의 캐시와 실제 작업할 파일을 관리한다. 커밋도 서버에서 만들기 때문에 로컬 커밋을 별도로 push해 공유하는 단계가 없다.
파일이 필요하지 않은 작업은 체크아웃 자체를 건너뛴다. 예를 들어 두 변경 사이의 차이만 검사하려는 작업은 서버 API에 답을 요청할 수 있다. 파일을 읽어야 할 때도 지정한 디렉터리만 받거나, 실제로 접근하는 파일만 그때 가져온다. 작업마다 저장소를 갖추는 대신 작업이 물어보는 질문에 서버가 답하는 방식이다.
변경 기록의 단위인 changeset에는 첫 번째 부모 변경을 기준으로 바뀐 파일 목록과 파일 내용의 저장 위치가 들어간다. 수정자 추적이나 파일별 이력처럼 추가 계산이 필요한 정보는 별도 파생 데이터로 만든다. 필요한 정보는 미리 계산하고, 당장 쓰지 않는 정보는 계산을 미룰 수 있다.
캐시는 무엇을 공유하고, 실패는 어디서 멈추나
파일 내용과 디렉터리 구조를 가져오는 경로는 여러 층으로 나뉜다. 같은 머신의 CI 작업들은 scion-daemon의 캐시를 공유한다. 여기에 없는 데이터는 지역별 scion-cache에 요청하고, 지역 캐시에도 없을 때 scion-server가 원본 저장소에서 읽는다. 이력 조회나 커밋 같은 제어 요청은 서버로 가므로, 모든 요청이 동일한 캐시 경로를 통과하는 것은 아니다.
각 파일 객체는 내용으로 식별하며, 저장된 객체는 변하지 않는다. 캐시가 최신 상태인지 서버끼리 매번 합의할 필요가 줄어든다. 회사는 각 계층의 캐시 적중률이 99%를 넘는다고 밝혔다. 지역 캐시 장애가 원본 서버로 요청 폭주를 일으키지 않도록 계층 사이의 접근도 엄격히 제한했다.
Anthropic이 비교한 Scion 인프라의 CPU·메모리 요구량은 이전 Git 미러 인프라의 약 200분의 1이었다. CI와 연구 작업의 체크아웃은 분 단위에서 초 단위로 줄었고, CI에서는 CPU 처리 여력 25%를 확보했다고 설명했다. 이는 저장소 운영과 코드 준비 단계의 수치이며, 제품 개발 전체가 200배 빨라졌다는 측정은 아니다.
병합을 기다리지 않으면 검사는 언제 하나
테스트가 돌아가는 동안 수백, 수천 개의 변경이 합쳐지면 시험한 코드와 현재 코드가 달라진다. Anthropic은 병합 대기열에서 저장소 전체를 잠그는 표준적인 방식을 이 규모에서 효과적으로 구현하지 못했다고 적었다. 대신 병합 후 검사와 배포 전 자동 테스트에 투자했다. 동시에 들어온 변경끼리 충돌할 수 있다는 비용도 함께 남는다.
그 과정에서 엔지니어가 맡은 일은 시스템 사이의 관계와 제약을 정하는 것이었다. 에이전트가 병합 시점을 찾으려고 코드 검토 도구에 묻지 않고 커밋 로그를 처음부터 읽는 구현을 만들면 사람이 이를 막았다. 가상의 위험에 대응하느라 검증 코드를 지나치게 늘리는 작업도 조정했다. 팀은 시스템의 모든 변경 요청을 계속 검토하되, 줄마다 읽기보다 변경의 의도를 살핀다고 설명했다.
이 사례를 작은 팀의 Git 교체 권고로 읽을 필요는 없다. Scion은 초대형 통합 저장소와 대규모 에이전트 작업에 맞춘 내부 시스템이다. 도입하려면 버전 관리뿐 아니라 코드 검토, 검색, CI까지 옮겨야 한다. 일반 팀이라면 먼저 코드 작성 시간과 저장소 복제·테스트 대기 시간을 따로 재는 편이 낫다. 파일 없이 처리할 수 있는 작업이 매번 저장소를 복제하는지, 같은 머신의 작업들이 동일한 파일을 반복 다운로드하는지부터 확인할 수 있다.
출처: Anthropic, Redesigning source control at Anthropic (2026년 10월 13일)