코딩 에이전트 열 개에게 각자 다른 작업을 동시에 맡겼다고 해 보자. 에이전트마다 자기만의 작업 폴더가 하나씩 필요하다. 저장소가 작을 때는 아무 문제가 없다. 하지만 저장소 크기가 수십 GB를 넘어가는 순간 얘기가 달라진다. 에이전트가 코딩을 시작하기도 전에 저장소를 통째로 내려받느라 몇 분씩 허비하게 된다.
에이전트가 코드를 빨리 짜면 짤수록 이 대기 시간은 더 뼈아프게 다가온다. 정작 코드를 작성하는 시간은 확 줄었는데 코드를 내려받고 합치고 테스트하는 길목이 예전 그대로이기 때문이다. 이 병목을 세상에서 가장 먼저, 가장 격하게 맞닥뜨린 회사가 바로 Anthropic이다.
2026년 10월 13일 Anthropic은 엔지니어링 블로그에 Redesigning source control at Anthropic이라는 글을 올렸다. 회사 전체 코드를 담아 둔 거대한 모노레포를 Git에서 빼내 자체 제작한 버전 관리 시스템 ‘Scion’으로 완전히 옮겼다는 소식이다. 대체 왜 Git으로는 버틸 수 없었는지, 새로 만든 Scion은 무엇이 다른지 하나씩 짚어 본다.
하루 2,500건이 3만 건이 됐다
규모부터 살펴보자. 2026년 5월만 해도 Anthropic의 모노레포에는 하루 평균 약 2,500건의 변경이 머지됐다. 그런데 불과 넉 달 뒤인 9월에는 하루 머지 수가 3만 건을 넘어섰다. 석 달 남짓한 사이에 커밋 속도가 열 배 이상 뛴 것이다. 사내에서 Claude에게 맡기는 코딩 작업이 그만큼 폭발적으로 늘어난 결과다.
게다가 저장소 덩치 자체가 엄청나게 크다. main 브랜치 이력만 100GB에 육박하고 압축된 작업 사본 하나도 25GB가 넘는다. 여기에 CI(자동 빌드·테스트 시스템)가 하루에 코드를 내려받는 횟수만 2,500만 번에 달한다. 개발자 개인 장비나 에이전트 샌드박스, 연구용 작업은 아예 뺀 숫자가 이렇다. 만약 이 요청을 아무런 요령 없이 곧이곧대로 다 내려받는다면 하루에 600PB가 넘는 Git 트래픽이 터져 나온다.
물론 그동안 손을 놓고 있었던 건 아니다. 최근 이력만 얇게 복제하는 얕은 클론(shallow clone), 필요한 폴더만 골라 받는 체크아웃(sparse checkout), 사내 미러 서버 같은 우회책을 총동원했다. 한창때는 사내에 Git 미러 서버를 수백 대나 띄워 놓고 돌렸다. 하지만 머지 속도가 가팔라질수록 미러 서버들이 그 속도를 따라잡지 못했다. 미리 만들어 둔 기본 사본은 순식간에 main 브랜치와 수천 커밋씩 벌어졌고 일부 파일만 내려받은 저장소에서는 diff나 blame(이 줄을 누가 언제 고쳤는지 추적하는 기능) 같은 기본 명령조차 제대로 돌아가지 않았다. 당시 사정을 원문은 이렇게 요약한다.
As our merges per day grew more than tenfold, source control became our biggest development bottleneck.
Git은 오프라인 세상을 위해 만들어졌다
Anthropic 팀이 찾아낸 근본 원인은 Git의 설계 철학 그 자체에 있었다. Git은 철저한 분산형 시스템이다. 모든 개발자가 자기 컴퓨터에 저장소 전체 사본을 통째로 복사해 두고 비행기 안처럼 인터넷이 끊긴 곳에서도 혼자 커밋하고 이력을 뒤져볼 수 있게 설계됐다. 사람 개발자에게는 더할 나위 없이 든든한 구조다.
하지만 Anthropic의 실제 작업 환경은 이와 정반대였다. 저장소에 붙는 클라이언트 대다수는 사람이 아니라 데이터센터 안에서 24시간 네트워크에 연결된 에이전트와 CI 작업이었다. 이들에게는 100GB짜리 과거 이력 전체가 필요하지 않다. 당장 고쳐야 할 파일 몇 개만 눈앞에 있으면 충분하다. 역설적이게도 Git의 강점이었던 오프라인 우선 설계가 에이전트 시대에는 가장 큰 족쇄가 된 셈이다.
그래서 팀은 Google의 내부 시스템인 Piper와 Meta의 Sapling을 참고해 판을 아예 새로 짰다. 전제는 단순하다. 모든 클라이언트는 늘 온라인 상태라고 가정하는 것이다. 이력 조회나 blame, 커밋, 머지, 리베이스처럼 무거운 계산은 전부 중앙 서버가 도맡는다. 클라이언트는 지금 당장 필요한 파일만 요청해서 화면에 펼친다. 커밋 자체가 서버에서 곧바로 만들어지니 로컬에서 작업한 뒤 서버로 밀어 올리는 push 단계도 아예 사라졌다.
심지어 작업 폴더를 만드는 일조차 선택 사항이 됐다. CI 서버는 굳이 기가바이트 단위의 코드를 내려받지 않고도 API를 호출해 “이번에 바뀐 파일이 뭐야?”라고 물어볼 수 있다. 버그가 처음 들어온 커밋을 이진 탐색으로 찾아내는 자동 bisect나 문제 생긴 커밋을 되돌리는 작업도 로컬 저장소 없이 서버 API만으로 가볍게 돌아간다.
Scion은 어떻게 200배 가벼워졌나
Scion이 다루는 기본 단위는 ‘체인지셋(changeset)’이다. Git 커밋이 저장소 전체 디렉터리 트리의 스냅샷을 가리키는 것과 달리 체인지셋은 직전 버전에서 실제로 바뀐 파일 목록만 담는다. 덕분에 커밋 한 번을 만드는 비용이 저장소 전체 크기가 아니라 내가 고친 파일 크기에만 비례한다. 데이터를 쓸 때 전역 잠금(lock)을 걸지도 않고 서버끼리 복잡한 합의를 거치지도 않는다.
blame이나 파일별 변경 이력처럼 계산이 필요한 정보는 체인지셋 안에 넣어 두지 않는다. 대신 이를 ‘파생 데이터’로 분류해 서버가 정해진 규칙에 따라 따로 계산한다. 자주 쓰이는 건 미리 계산해 두고 나머지는 요청이 들어올 때 즉석에서 계산하는 식이다. 클라이언트는 서버가 이 데이터를 어떻게 저장하고 계산하는지 전혀 몰라도 된다. 서버 내부 구조를 뜯어고쳐도 클라이언트 프로그램을 일일이 업데이트할 필요가 없다는 뜻이다. 파일 복사를 감지하거나 경로로 파일을 빠르게 찾는 기능도 나중에 서버 쪽에만 조용히 덧붙일 수 있었다.
데이터가 흘러가는 길은 네 겹의 캐시로 이뤄져 있다. 개별 작업은 먼저 자기 컴퓨터에 떠 있는 scion-daemon에 파일을 요청한다. 데몬에 없으면 같은 리전의 scion-cache에 묻고 거기에도 없으면 중앙의 scion-server를 거쳐 맨 아래의 Spanner 데이터베이스와 클라우드 스토리지까지 내려간다. 오가는 데이터는 모두 내용 자체가 곧 주소가 되는 방식(content-addressed)이라 한 번 만들어지면 영원히 내용이 바뀌지 않는다. 어느 층에서든 유효기간 걱정 없이 마음껏 캐시할 수 있는 이유다.
효과는 숫자로 바로 나타났다. 네 층 모두에서 캐시 적중률이 99%를 넘겼고 전체 서버 인프라는 예전 Git 미러 서버 시절보다 200배나 줄어들었다. 몇 분씩 걸리던 CI와 연구 작업의 코드 체크아웃은 몇 초 만에 끝나 약 100배 빨라졌다. 순수하게 코드 내려받는 데만 쓰이던 CI 서버의 CPU 자원도 25%나 아꼈다.
일곱 명이 다섯 달 만에 끝낸 비결
이 거대한 공사를 해낸 팀원은 고작 일곱 명이었다. 이 일곱 명이 다섯 달 만에 핵심 시스템인 Scion은 물론이고 자체 코드 리뷰 도구인 Antique와 주변 시스템 대여섯 개를 새로 만들어 이전을 마쳤다. 그 다섯 달 동안에도 사내의 하루 머지 횟수는 열 배로 불어나고 있었다.
팀원들의 회고가 흥미롭다. 순수하게 코드를 짜는 실력만 놓고 보면 이미 Claude가 자기들보다 낫다는 것이다. 대신 사람 엔지니어들은 시스템 전체의 밑그림을 그리고 설계상의 득실을 저울질하는 데 집중했다. 실제로 엔지니어가 가장 많이 한 일은 Claude에게 “그렇게 하면 안 돼”라고 제동을 거는 것이었다고 한다. 예를 들어 코드 리뷰 도구의 API를 한 번 부르면 끝날 일을 두고 Claude가 커밋 이력 전체를 처음부터 다 훑는 코드를 짜려 할 때 이를 막아서는 식이다. 이제 엔지니어는 코드 한 줄 한 줄의 문법을 고치는 대신 변경의 의도와 구조가 맞는지 검토한다.
Claude가 사람이 짠 코드를 압도한 순간도 있었다. 엔지니어가 직접 손으로 짠 Git→Scion 데이터 이전 파이프라인을 두고 Claude Mythos Preview 모델에게 처음부터 다시 짜 보라고 시켰다. 별다른 힌트도 주지 않았는데 새로 나온 코드는 기존 코드보다 메모리를 20분의 1만 쓰면서 속도는 4배나 빨랐다. 까다로운 데이터 순서와 자료구조의 불변 조건도 하나도 깨뜨리지 않았다.
물론 빨리 만들었다고 해서 안정성을 대충 타협한 건 아니다. 버전 관리 시스템이 한 번 꼬이면 회사 전체가 멈추기 때문에 Scion은 사내에서 가장 혹독하게 테스트된 코드베이스 중 하나가 됐다. 외부 네트워크와 완전히 격리된 결정론적 시뮬레이션을 돌리고 무작위 입력을 끝없이 밀어 넣는 퍼징(fuzzing) 테스트로 버그를 털어냈다. 운영 단계에서도 구성 요소마다 전담 Claude 에이전트를 하나씩 붙여 놓고 로그와 지표를 실시간으로 감시하게 했다. 일반적인 임계치 알람으로는 잡히지 않는 미묘한 이상 징후를 이 에이전트들이 먼저 알아채고 경고를 보낸다.
일하는 문화도 함께 바뀌었다. 줄을 세워 한 번에 하나씩만 합치는 전통적인 머지 큐(merge queue)는 하루 3만 번 머지 앞에서는 그 자체가 병목이 되어 버렸다. 그래서 일단 빠르게 머지한 뒤 배포 직전에 자동 테스트로 검증하는 방식으로 무게중심을 옮겼다. 동시에 들어온 변경끼리 충돌이 날 수도 있지만 사람이 눈치채기도 전에 백그라운드의 Claude가 알아서 고쳐 놓는 경우가 대부분이다.
우리 팀의 길목은 안녕한가
Anthropic은 Scion을 외부에 공개해 Git의 대체재로 만들 생각은 없다고 선을 그었다. 수만 명의 개발자나 수천 개의 에이전트가 하나의 거대한 모노레포에 매달리는 극단적인 환경이 아니라면 굳이 이런 시스템이 필요 없기 때문이다. 게다가 Git과 작동 방식이 완전히 달라서 이를 도입하려면 코드 리뷰부터 검색, CI까지 개발 도구 전체를 새로 짜야 한다.
그렇다고 강 건너 불구경만 할 이야기는 아니다. Anthropic은 자기들이 겪은 이 병목이 앞으로 6개월에서 1년 안에 에이전트를 적극적으로 쓰는 다른 기술 기업들에도 똑같이 닥칠 것으로 내다본다. 그래서 Git 자체를 버리지 않고도 적용할 수 있는 설계 아이디어들을 오픈소스 커뮤니티와 GitHub, GitLab 등에 공유하고 협력하겠다고 밝혔다.
결국 이 글이 던지는 질문은 하나로 모인다. 지금 우리 팀의 개발 인프라는 사람 수십 명이 손으로 타이핑하던 시절의 속도에 맞춰져 있는가 아니면 에이전트 수백 개가 쉼 없이 코드를 쏟아내는 속도에 맞춰져 있는가. 만약 에이전트에게 일을 시켜 놓고 환경 세팅과 테스트 대기열에서 몇 분씩 발이 묶여 있다면 진짜 병목은 더 똑똑한 AI 모델이 아니라 그 앞을 가로막은 낡은 길목에 있을지도 모른다.