앤스로픽, 사내 버전 관리 시스템 Scion 공개

AI 기업 앤스로픽이 10월 13일 엔지니어링 블로그에서 사내 버전 관리 시스템 Scion을 공개했다. 회사는 하나의 저장소에 코드 전체를 담는 모노레포를 깃(git)에서 Scion으로 다섯 달 만에 완전히 옮겼다고 밝혔다. 계기는 병합량이다. 앤스로픽에 따르면 하루에 병합되는 코드 변경은 2026년 5월 평균 약 2500건이었는데 9월에는 3만 건을 넘었다. 회사가 공개한 그래프에서 9월 9일 하루 병합 건수는 3만401건이었다. 앤스로픽 소스 관리 팀은 글에서 "코딩은 더 이상 시스템을 만들거나 연구하는 데 병목이 아니다"라며 이제 병목은 소스 관리와 빌드, CI처럼 사람 규모에 맞춰 만든 개발 인프라라고 진단했다.

저장소의 덩치가 먼저 깃의 설계 범위를 넘었다. 앤스로픽에 따르면 메인 브랜치 히스토리만 100GB에 가깝고 압축한 작업 사본은 25GB를 넘는다. CI를 위한 코드 체크아웃은 하루 약 2500만 번으로, 개발 환경과 에이전트 샌드박스, 연구 작업은 여기서 빠진 숫자다. 이를 그대로 받으면 하루 깃 트래픽이 600PB를 넘는다. 회사는 얕은 클론과 희소 체크아웃, 내부 깃 미러, 블롭 저장소에 둔 저장소 스냅샷을 모두 썼고 가장 많을 때는 내부 깃 미러 수백 개를 돌렸다. 병합 속도가 오를수록 스냅샷은 메인 브랜치 끝에서 더 멀어졌고 부분 클론에서 변경 이력과 줄별 작성자 추적을 유지하는 일도 까다로워졌다.

방향을 바꾼 것은 사용 방식에 대한 관찰이었다. 깃은 모든 클론이 오프라인에서도 히스토리를 읽고 어떤 리비전이든 꺼낼 수 있는 분산형 시스템이다. 앤스로픽은 자신들도 대부분의 회사처럼 권위 있는 사본 하나를 둔 중앙집중형으로 깃을 써 왔고, 클라이언트 대부분이 정의상 늘 온라인인 에이전트와 작업이었다고 짚었다. 팀은 에이전트가 항상 온라인이라는 사실을 처음부터 전제로 소스 관리를 설계하면 어떤 모습이 되는지를 물었고, 구글의 Piper와 메타의 Sapling이 남긴 교훈을 참고했다.

Scion에서는 서버가 일을 대부분 맡는다. 파일 히스토리와 줄별 작성자 조회, 커밋 생성, 병합과 리베이스를 서버가 처리하고 클라이언트는 크기가 제한된 로컬 객체 캐시와 작업 파일만 관리한다. 작업 단위는 선행 기록 로그의 항목인 변경 묶음(changeset)이다. 변경 묶음은 첫 부모 대비 바뀐 파일 목록과 블롭 저장소에 압축해 둔 파일 내용을 가리키는 콘텐츠 주소만 담는다. 깃의 팩파일이 없고 잠금이나 서버 간 조율도 없어 처리량이 높다. 브랜치 같은 참조를 옮기는 일은 구글 스패너의 행 하나를 비교 후 교체하는 작업으로 분리됐다. 저장소 전체가 펼쳐진 사본은 서버에도 없다.

체크아웃은 3단 캐시로 돈다. 노드마다 있는 scion-daemon이 지역 단위의 scion-cache에 객체를 묻고, 캐시에 없으면 스패너와 클라우드 스토리지를 읽는 scion-server로 올라간다. 앤스로픽에 따르면 각 단의 캐시 적중률은 99%를 넘는다. Scion 인프라는 CPU와 메모리 기준으로 이전 깃 미러 인프라보다 200배 작아졌다. CI와 연구 작업의 체크아웃은 분 단위에서 초 단위로 약 100배 빨라졌고, CI에서만 CPU 용량의 25%가 풀려났다.

이 시스템을 만든 손도 대부분 클로드였다. 앤스로픽에 따르면 7명으로 이뤄진 팀이 Scion과 코드 리뷰 도구 Antique, 관련 시스템 여섯 개 남짓을 만들고 다섯 달 만에 이전을 끝냈다. 그사이 하루 병합량은 10배로 늘었다. 팀이 Scion을 만들기 시작한 시점은 Claude Mythos Preview와 Claude Tag가 사내에 풀린 때와 겹친다. 연초에 사람이 거의 손으로 짠 깃에서 Scion으로의 데이터 수집 파이프라인 시제품을 Claude Mythos Preview 초기 내부 버전에 다시 쓰게 하자, 추가 지시 없이 메모리를 20배 적게 쓰고 4배 빠른 판이 나왔다. 수집 순서와 자료 구조에 걸린 암묵적 조건도 그대로 지켰다고 회사는 밝혔다.

사람의 몫은 설계와 거절로 옮겨 갔다. 이 시스템을 만든 엔지니어 전원이 이제 클로드가 자신보다 코드를 더 잘 쓴다고 평가했지만, 시스템 사이의 구조와 설계상 절충은 여전히 엔지니어가 정했다. 팀은 "엔지니어의 역할이 클로드에게 안 된다고 말하는 것인 경우가 아주 많았다"고 썼다. 메인 브랜치에 병합된 시점을 리뷰 도구에 묻지 않고 커밋 로그를 처음부터 읽어 찾으려 한 시스템이 여럿 있었고, 적대적 리뷰가 다른 내부 서비스를 지나치게 의심하는 바람에 클로드가 불필요한 검증과 복잡도를 덧붙인 일도 있었다. 팀원은 지금도 모든 변경 요청을 리뷰하지만 코드를 한 줄씩 읽기보다 변경의 의도를 본다. 운영에서는 컴포넌트 하나의 상태만 집요하게 감시하도록 슬랙 채널에 배치한 클로드를 슈퍼팬이라 부르며 쓰고 있다.

작업 방식의 전제도 바뀌고 있다. 앤스로픽은 테스트가 도는 동안 수백, 수천 건의 변경이 병합될 수 있는 환경에서 저장소 전체를 잠그는 병합 대기열을 재현하지 못했고, 대신 병합 후와 배포 전 자동 테스트에 투자했다. 동시 변경이 충돌할 수는 있지만 클로드가 사람이 충돌을 알아차리기도 전에 고친다는 설명이다. 메탈은 앤스로픽이 클로드 코드 프로젝트를 대기자 전원에게 열었다고 보도한 바 있으며, 이번 글은 그 코딩 에이전트를 가장 많이 쓰는 회사 안쪽에서 무엇이 먼저 막히는지를 보여 준다. 메탈이 확인한 앤스로픽 공식 X 게시물은 병목의 원인을 사람이 아닌 에이전트 규모를 감당하지 못한 개발 인프라로 요약했고, 게시 반나절 만에 조회 140만 회를 넘겼다.

앤스로픽은 Scion을 외부에 내놓을 계획은 밝히지 않았다. 회사는 "Scion은 일반 용도로 깃을 대체하기에 결코 적합하지 않다"며 수만 명의 엔지니어나 코드를 쏟아 내는 에이전트 무리를 둔 거대 모노레포에서만 의미가 있다고 선을 그었다. 도입하려면 코드 리뷰와 코드 검색, CI까지 개발 주기 전체를 옮겨야 한다는 이유도 들었다. 대신 회사는 같은 부류의 문제가 앞으로 6~12개월 안에 흔해질 것으로 보고, 깃 서버가 Scion처럼 포괄적인 서버 측 원격 호출을 제공하고 협상 프로토콜과 희소 기능을 다듬는 방향으로 깃허브와 깃랩, 오픈소스 커뮤니티와 협력하겠다고 밝혔다. 에이전트가 하루 3만 건의 변경을 밀어 넣는 시대에는 코드를 쓰는 속도보다 코드를 담고 옮기는 인프라의 설계가 생산성의 상한을 정한다.