앤트로픽 Scion, 에이전트 시대에 맞춘 사내 버전 관리 시스템
AI에게 코드를 맡기는 일이 늘면, 코드를 짜는 것보다 저장하고 합치는 도구가 먼저 막힐 수 있습니다. 앤트로픽은 이 문제를 풀려고 사내 버전 관리 시스템 Scion(사이언)을 직접 만들었고, 사내 모노레포(Monorepo)를 Git에서 5개월 만에 완전히 옮겼습니다.
모노레포는 여러 프로젝트의 코드를 한곳에 모은 거대한 저장소입니다. 앤트로픽이 2026년 10월 13일 엔지니어링 블로그에 올린 글을 바탕으로 정리했습니다.
목차
1. 하루 2,500건이던 병합이 3만 건을 넘었습니다
2026년 5월 앤트로픽은 하루 평균 약 2,500건의 코드 변경을 병합했는데, 9월에는 하루 3만 건 이상을 병합했습니다.
저장소 규모도 큽니다. 메인 브랜치 기록만 거의 100GB이고, CI(Continuous Integration, 자동 빌드·테스트)용 체크아웃이 하루 약 2,500만 회 규모입니다. 아무 최적화 없이 Git으로 받으면 하루 600PB가 넘는 트래픽이 된다고 계산했습니다.
얕은 클론 같은 우회책은 없었을까요? 모두 썼고, 사내 Git 미러를 수백 대까지 돌렸지만 병합 속도가 오를수록 감당하기 어려워졌습니다.
Git은 모든 사본이 완전한 저장소인 분산형이라 오프라인에서도 일할 수 있습니다. 그런데 앤트로픽의 클라이언트는 거의 전부 항상 온라인인 에이전트와 작업(job)이었습니다. 오프라인에 강한 이 성질이 오히려 확장을 가로막고 있었습니다.
2. Scion은 Git과 설계가 어떻게 다를까요?
앤트로픽은 Google의 Piper, Meta의 Sapling을 선행 사례로 참고했다고 밝혔습니다. 핵심 설계 원칙은 이렇습니다.
가. 클라이언트는 항상 온라인입니다
항상 연결되는 서버를 전제로 설계했고, 클라이언트는 필요할 때 데이터를 받아옵니다.
나. 무거운 일은 서버가 맡습니다
파일 이력·blame 질의, 커밋 생성, 병합·리베이스를 서버가 처리합니다. 커밋이 서버에서 일어나니 Git처럼 push할 것도 없습니다.
다. 모든 기능을 API로 엽니다
클라이언트가 쓰는 소스 관리 질의가 모두 API로 열려 있어, 많은 작업에 로컬 저장소가 아예 필요 없습니다.
라. 작업 사본은 처음부터 희소합니다
요청한 디렉터리만 담는 희소 체크아웃이 기본이라, 실제로 읽은 만큼만 비용이 듭니다.
3. Scion으로 바꾼 뒤 얼마나 빨라졌을까요?
Scion 인프라는 이전 Git 미러링 인프라보다 CPU·메모리 요구량 기준으로 200배 작습니다. CI와 연구 작업의 코드 체크아웃은 100배 정도 빨라져 분 단위가 초 단위가 됐고, CI만 해도 CPU 용량 25%를 확보했습니다.
아래 표는 개발·에이전트 환경 측정값입니다
일상 명령별 Git과 Scion 소요 시간
| 환경·명령 | Git | Scion | 배수 |
|---|---|---|---|
| 개발 환경 최신 내려받기 | 87초 | 3.5초 | 25배 |
| 개발 환경 상태 확인 | 3.9초 | 19ms | 207배 |
| 개발 환경 커밋 | 1.4초 | 1.1초 | 1.3배 |
| 에이전트 새 작업 공간(워크트리) 만들기 | 7.1분 | 5.1초 | 84배 |
| 에이전트 최신 내려받기 | 3.0분 | 9.0초 | 20배 |
| 변경 요청 1건당 소스 관리 시간(에이전트) | 34분 | 3.7분 | 9.2배 |
4. 7명이 5개월 만에 해낸 일, Claude의 역할은?
7명 팀이 Scion과 코드 리뷰 도구 Antique 그리고 관련 시스템 6개 정도를 같이 만들었고, 5개월 만에 이전을 끝냈습니다. 그동안 하루 병합 코드 양은 10배로 늘었습니다.
Claude의 몫도 컸습니다. Git에서 Scion으로 데이터를 들여오는 파이프라인 첫 버전은 대부분 손으로 짰는데, Claude Mythos Preview 초기 사내 스냅샷에 전체를 다시 쓰게 하자 추가 지시 없이 메모리를 20배 적게 쓰고 4배 빠른 버전을 내놓았습니다.
그럼 엔지니어는 무엇을 했을까요? 시스템 간 큰 구조와 설계상 절충은 여전히 엔지니어가 판단했습니다. 원문은 그 역할이 “Claude에게 ‘아니’라고 말하는 것”인 경우가 매우 많았다고 적었습니다. 변경 요청은 모두 검토하되, 코드를 한 줄씩 읽는 대신 변경의 의도를 봅니다.
에이전트에게 일을 나눠 맡기는 방식이 궁금하다면 클로드 코드 모델, 서브 에이전트에 Opus·Sonnet으로 구분 적용해 보니 글을 참고하기 바랍니다.
5. 일반 개발자도 Scion을 쓸 수 있나요?
어렵습니다. 원문은 “Scion은 결코 범용 Git 대체재로 적합하지 않다”고 적었습니다. 수만 명의 엔지니어나 에이전트 무리가 코드를 대량으로 쓰는 진짜 거대한 모노레포에서만 의미가 있는 개념이라는 설명입니다.
외부 제공도 “다른 조직이 폭넓게 쓸 수 있는 형태로 Scion을 제공하기는 어렵다”고 했습니다. 개발 주기 전체를 옮겨야 하고 자체 코드 리뷰·코드 검색·CI까지 필요해서입니다. 모두를 만족시키려는 공개 버전은 그다지 쓸모없을까 걱정된다고도 밝혔습니다.
대신 이런 문제가 6~12개월 안에 더 흔해질 것으로 보고, Scion에서 잘 된 부분을 Git에 적용할 수 있도록 생각을 공유하는 데 무게를 뒀습니다. 원문은 GitHub, GitLab, 오픈소스 커뮤니티와 협력하고 싶다는 말로 끝납니다.
클로드 코드를 쓰는 분이라면 클로드 코드 작업 완료 알림, 카톡 대신 디스코드 봇으로 받아봤습니다 (1) 글도 참고하기 바랍니다.
이제 AI가 모든 것의 기준이 되는 시대가 되고 있습니다.