Anthropic이 AI 에이전트가 코드를 너무 빨리 작성해서 Git을 대체했습니다
2020년의 개발자에게 어느 날 AI 회사가 자체 버전 관리 시스템(version control system)을 구축해야 할 정도로 AI 에이전트가 많은 양의 코드를 생산할 것이라고 말한다고 상상해 보세요.
아마도 비웃을 겁니다.
하지만 지금 여기에 있습니다.
2026년 10월 13일, Anthropic은 제가 다른 AI 모델 발표보다 더 흥미롭다고 생각한 무언가를 공개했습니다.
그들은 왜 내부 모노레포(monorepo)를 Git에서 옮기고 Scion이라는 완전히 새로운 소스 제어 시스템을 구축했는지 설명했습니다.
Git이 갑자기 나빠져서가 아닙니다.
Git이 구식이 되어서도 아닙니다.
단지 그들의 개발 워크로드(development workload)가 너무 극적으로 변화하여 기존 인프라의 근간을 이루는 가정이 깨지기 시작했기 때문입니다.
그리고 수치는 꽤 놀랍습니다.
하루 평균 2,500건에서 30,000건 이상의 병합(merge)으로 증가
2026년 5월에 Anthropic은 하루 평균 약 2,500건의 코드 변경 사항이 병합되었습니다.
9월까지 이 수치는 30,000건을 넘어섰습니다.
이는 불과 네 달 만에 이전 볼륨보다 12배가 넘는 증가폭입니다.
이것이 코드 주변 시스템에 어떤 의미인지 생각해 보세요.
모든 변경 사항에는 저장소 작업(repository operations), 테스트, 검토(review), 병합, 배포가 수반될 수 있습니다.
이제 이 작업을 수천 개의 에이전트와 자동화된 작업들이 동시에 작동하는 것에 걸쳐 곱해 보세요.
그런 규모에서는 코드를 생성하는 것이 반드시 더 비싼 부분이 아닙니다.
코드 _주변_에서 발생하는 모든 것이 문제가 되기 시작합니다.
Anthropic의 엔지니어링 팀은 정확히 그러한 상황을 설명했습니다.
그리고 그것은 우리 대부분이 당연하게 여기는 무언가에 의문을 갖게 했습니다.
모든 개발자가 정말로 로컬 Git 저장소(local Git repository)를 필요로 할까요?
Git은 이런 종류의 개발자를 위해 설계되지 않았습니다
Git은 자신이 설계된 일에는 탁월합니다.
개발자는 저장소를 클론하고, 로컬에서 작업하며, 커밋을 하고, 기록을 확인하고, 브랜치를 만들고, 변경 사항을 푸시합니다.
오프라인에서도 작업할 수 있습니다. 로컬 히스토리를 검사하기 위해 서버가 필요하지 않습니다. 저장소에는 광범위한 작업을 수행하는 데 필요한 정보가 포함되어 있습니다.
일반 크기의 프로젝트를 다루는 사람들에게는 이것이 엄청나게 유용합니다.
하지만 자동화된 클라우드 환경 내에서 실행되는 AI 코딩 에이전트에 대해 생각해 보세요.
파일 세 개를 수정하고, 테스트를 실행하고, 변경 사항을 제출한 다음 사라져야 할 수도 있습니다.
과연 거대한 저장소 히스토리에 접근할 필요가 있을까요?
단지 diff(차이점)만 계산하려는 CI 작업이 저장소의 큰 부분을 재구성해야 할까요?
반드시 그렇지 않습니다.
Anthropic에서는 이러한 질문들이 매우 현실적이 되었습니다.
그들의 메인 브랜치 히스토리는 100 GB에 육박하고 있었습니다.
압축된 작업 복사본은 25 GB가 넘었습니다.
그리고 그들의 CI 인프라는 매일 약 **2,500만 건의 체크아웃(checkout)**을 수행하고 있었습니다.
그들은 이미 일반적인 확장 기술들을 시도해 보았습니다:
- Shallow clones (얕은 복제)
- Sparse checkouts (희소 체크아웃)
- Repository snapshots (저장소 스냅샷)
- Internal Git mirrors (내부 Git 미러)
한때 Anthropic은 수백 개의 Git 미러를 운영했습니다.
이러한 접근 방식들이 도움이 되었지만, 병합(merge) 볼륨과 함께 유지보수 비용도 계속 증가했습니다.
결국 회사는 동일한 아키텍처를 계속 최적화하는 것만으로는 충분하지 않다고 결정했습니다.
그들은 다른 가정들을 기반으로 구축된 무언가가 필요했습니다.
Scion 등장
Scion은 Anthropic의 내부 소스 제어 시스템(source control system)이며, 에이전트 중심 개발을 염두에 두고 설계되었습니다.
핵심 아이디어는 놀라울 정도로 간단합니다.
대부분의 에이전트는 항상 온라인입니다. 그렇다면 왜 그들의 소스 제어를 오프라인 독립성을 중심으로 설계할까요?
모든 클라이언트가 복잡한 저장소 작업을 로컬에서 수행하도록 요구하는 대신, Scion은 그 작업의 상당 부분을 서버로 옮깁니다.
간단하게 비교해 보겠습니다:
| 작업 | Git | Scion |
|---|
| 저장소 히스토리 | 로컬 클론에 저장됨 | 주로 서버 측 |
| ... | | |
차이점은 Scion이 경량 클라이언트(lightweight clients)와 서버 측 작업(server-side operations)을 근본적인 설계 선택으로 다룬다는 것입니다.
이는 몇 가지 흥미로운 가능성을 열어줍니다.
예를 들어, 두 변경 사항을 비교해야 하는 CI(지속적 통합) 작업은 API를 통해 diff를 요청할 수 있습니다. 이 경우 전체 작업 트리(working tree)를 먼저 체크아웃할 필요가 없습니다. 단지 몇 개의 디렉터리만 필요한 에이전트는 모든 것을 구현(materializing everything)하는 대신 해당 디렉터리들을 가져올 수 있습니다.
그리고 수천 개의 작업이 유사한 파일에 반복적으로 접근할 때, 계층적 캐싱 시스템(layered caching system)은 이러한 읽기 작업을 훨씬 저렴하게 만들 수 있습니다.
아키텍처가 흥미로운 부분입니다
Scion은 단순히 더 빠른 서버를 가진 Git이 아닙니다. Anthropic은 몇 가지 중요한 데이터 구조를 재설계했습니다. 그 작업 단위(unit of work)는 **변경 세트(changeset)**입니다.
변경 세트는 첫 번째 부모(first parent)에 비해 수정된 파일들과, 별도로 저장된 파일 내용에 대한 포인터들을 기록합니다. 이는 Git의 익숙한 커밋-및-트리 표현(commit-and-tree representation)과는 다릅니다.
Scion은 또한 파일 히스토리(file history), 블레임(blame), 그리고 커밋 계보(commit ancestry)와 같은 작업을 위해 파생된 데이터 구조도 유지합니다. 이들은 필요에 따라 계산되거나 사전에 준비될 수 있습니다. 시스템은 커밋을 추가하는 것이 전체 리포지토리(repository)에 비례하는 작업량을 요구하지 않도록 설계되었습니다.
이것은 중요한 세부 사항입니다. 모노레포(monorepo)가 엄청난 히스토리를 포함할 때, 작은 변경의 비용이 작게 유지되기를 원합니다. Scion의 저장소 및 캐싱 아키텍처는 또한 불변하고 콘텐츠 주소 지정된 객체(immutable, content-addressed objects)에 크게 의존합니다. 여러 서버가 지속적으로 이 객체들의 변경 사항을 조정할 필요 없이 동일한 객체를 안전하게 캐시할 수 있습니다.
그 결과는 다양한 구성 요소들이 독립적으로 확장될 수 있는 시스템입니다. 이는 특히 작업 부하가 상대적으로 작은 엄청난 수의 작업으로 구성되어 있을 때 유용합니다. Anthropic은 그 이점이 상당했다고 말합니다.
200배 작아진 인프라. 100배 빨라진 체크아웃.
Anthropic의 내부 측정에 따르면, Scion은 다음을 제공했습니다:
- 이전 Git 미러링 설정 대비 소스 제어 인프라의 CPU 및 메모리 요구 사항을 200배 낮춤.
- CI(지속적 통합) 및 연구 작업에 대한 체크아웃 속도가 약 100배 빨라져, 분 단위가 몇 초로 단축됨.
- CI만으로도 CPU 용량을 25% 절감함.
- 캐싱 계층 전반에서 **99%**를 넘는 캐시 적중률을 기록함.
이러한 결과는 Anthropic의 인프라에 국한된 것이므로, 보편적인 Scion 대 Git 벤치마크로 해석해서는 안 됩니다.
하지만 주목할 만한 무언가를 보여줍니다.
가장 큰 성능 개선은 기존 작업을 더 빠르게 만드는 데서 오는 것이 아닐 때가 많습니다.
그것은 그 작업을 불필요하게 수행하는 것을 방지하는 시스템을 설계하는 것에서 옵니다.
7명의 엔지니어가 5개월 만에 이 모든 것을 구축했습니다
이 부분이 이야기 전체에서 가장 놀라운 부분일 수 있습니다.
Anthropic에 따르면, 7명의 엔지니어 팀이 코드 리뷰 도구인 Antique와 여러 지원 시스템을 포함한 Scion을 구축했습니다.
그리고 모노레포를 마이그레이션했습니다.
단 5개월 만에요.
인프라 분야에서 일해 본 사람이라면 얼마나 야심 찬 일인지 알 것입니다.
소스 제어는 극도로 신뢰할 수 있어야 합니다. 코드 이력의 일부를 잃거나 미묘한 일관성 문제를 초래하는 것은 속도를 위한 용납 가능한 트레이드오프가 아닙니다.
게다가 워크로드가 빠르게 증가하는 동안 활성화된 모노레포를 마이그레이션하는 것은 문제를 더욱 어렵게 만듭니다.
그렇다면 그들은 어떻게 그렇게 빨리 움직일 수 있었을까요?
놀랍지 않게도, Claude가 주요 역할을 했습니다.
Anthropic은 Git-to-Scion 수집 파이프라인과 관련된 예를 공유했습니다.
엔지니어들은 처음에 프로토타입을 직접 작성했습니다.
그런 다음 초기 내부 버전인 Claude Mythos Preview에 그것을 재작성하도록 요청했습니다.
Anthropic은 재작성된 버전이 필요한 정확성 제약 조건을 유지하면서 20배 적은 메모리를 사용하고 4배 더 빠르다고 보고합니다.
정말 인상적인 결과입니다.
하지만 동시에 이상한 피드백 루프도 드러냅니다.
Claude의 성장하는 코딩 능력이 소스 제어 병목 현상을 만드는 데 도움을 준 것입니다.
그러자 Claude는 엔지니어들이 이를 제거하는 인프라를 구축하는 데 도움을 주었습니다.
그리고 이러한 병목 현상을 제거하면 훨씬 더 많은 코드를 생산하는 것이 가능해집니다.
저는 우리가 이 패턴을 다시 보게 될 것이라고 생각합니다.
엔지니어의 역할이 변화하고 있다
Anthropic의 기사에서 나온 한 가지 세부 사항이 제 마음에 남았습니다.
팀은 그들의 작업 중 상당 부분이 Claude에게 **'아니오'**라고 말하는 것을 포함한다고 설명했습니다.
Claude가 코드를 작성할 수 없어서가 아닙니다.
기술적으로 유효한 코드를 작성하는 것은 엔지니어링의 한 부분일 뿐이기 때문입니다.
에이전트는 로컬에서는 작동하지만 더 큰 아키텍처 제약 조건을 깨뜨리는 솔루션을 도입할 수 있습니다.
최적화가 필요하지 않은 경로를 최적화할 수도 있습니다.
가상의 엣지 케이스를 처리하기 위해 불필요한 복잡성을 추가할 수도 있습니다.
또는 대규모로 유지보수가 불가능하게 되는 방식으로 문제를 해결할 수도 있습니다.
인간 엔지니어들은 여전히 아키텍처를 이해하고, 트레이드오프(trade-offs)를 평가하며, 시스템 전반의 일관성을 유지해야 합니다.
Anthropic에 따르면 그들의 엔지니어들은 모든 변경 요청을 계속 검토하지만, 모든 줄을 읽는 것보다 변화의 **'의도(intent)'**에 더 초점을 맞추고 있습니다.
이것은 흥미로운 질문을 제기합니다.
만약 AI가 우리가 읽을 수 있는 속도보다 빠르게 코드를 작성할 수 있다면, 효과적인 코드 리뷰란 무엇일까요?
저는 아무도 아직 그것을 완전히 해결했다고 생각하지 않습니다.
그리고 시스템이 하루에 수만 개의 변경 사항을 병합할 때 이 도전 과제는 더 커집니다.
CI가 우리가 다시 생각해 봐야 할 다음 것일 수 있다
익숙한 개발 워크플로우를 생각해 봅시다.
풀 리퀘스트(pull request)를 엽니다.
CI가 실행됩니다.
테스트가 통과합니다.
변경 사항이 병합됩니다.
간단합니다.
하지만 우리의 테스트가 실행되는 동안 수백 또는 수천 개의 다른 변경 사항이 병합되면 어떻게 될까요?
테스트가 시작된 순간부터 그 결과가 이용 가능해지는 순간까지 코드베이스는 상당히 진화할 수 있습니다.
전통적인 병합 큐(merge queues)는 병합 전에 무엇을 테스트했는지에 대한 더 강력한 보장을 유지하기 위해 변경 사항을 직렬화(serialize)할 수 있습니다.
하지만 모든 것을 직렬화하는 것은 엄청난 처리량에서는 비용이 많이 들게 될 수 있습니다.
Anthropic은 전역 병합 큐(global merge-queue lock)에 의존하기보다는 병합 후 및 배포 전 테스트에 투자해 왔다고 말합니다.
이는 다른 엔지니어링 트레이드오프를 도입합니다.
동시 변경 사항은 충돌할 수 있습니다. 실패는 신속하게 감지하고 처리되어야 합니다. 저장소의 지속적인 변경에도 불구하고 테스트는 의미를 유지해야 합니다.
그리고 이 모든 것 아래에는 더 큰 문제가 있습니다.
30,000개의 변경 사항을 생성하는 것이 30,000개 변경 사항이 올바르다는 것을 증명하는 것과는 같지 않습니다.
AI는 우리가 생산할 수 있는 코드의 양을 극적으로 늘릴 수 있습니다.
하지만 신뢰성(confidence), 안정성(reliability), 보안(security), 그리고 유지보수성은 여전히 심각한 엔지니어링을 필요로 합니다.
우리가 코드를 더 빨리 생성할수록, 이러한 시스템들의 중요성은 더욱 커집니다.
우리 모두 Git 사용을 멈춰야 할까요?
절대 그렇지 않습니다.
Anthropic은 Scion이 범용 Git 대체재로 의도되지 않았다는 점을 매우 분명히 합니다.
대부분의 팀은 하루에 2,500만 건의 체크아웃(checkout)을 처리하지 않습니다.
대부분의 저장소는 수백 기가바이트 규모가 아닙니다.
그리고 대부분의 개발자는 여전히 로컬 히스토리, 오프라인 커밋, 그리고 Git의 성숙한 생태계로부터 큰 이점을 얻습니다.
Scion의 아키텍처에는 트레이드오프도 있습니다.
서버 중심 시스템은 네트워크 가용성과 중앙 인프라에 더 강한 의존성을 도입합니다.
새로운 소스 제어 시스템을 구축한다는 것은 코드 검토(code review), CI, 권한, 그리고 개발자 도구(developer tooling)를 위한 호환 가능한 워크플로우를 유지하는 것을 의미하기도 합니다.
대부분의 회사에게는 감당하기에 엄청난 복잡성입니다.
그리고 기존 Git을 넘어서 확장 가능한 소스 제어 시스템은 새로운 것이 아닙니다. Google에는 Piper가 있고, Meta는 Sapling에 투자했습니다.
따라서 Scion은 Git이 구식이 되었다는 증거가 아닙니다.
이는 에이전트 규모의 개발(agent-scale development)이 다른 아키텍처가 매력적인 워크로드를 생성할 수 있다는 증거입니다.
그것이 훨씬 더 유용한 시사점입니다.
이것이 우리에게 의미하는 바는 무엇인가요?
여러분은 새로운 버전 관리 시스템을 구축할 필요는 없을 것입니다.
하지만 저는 우리의 자체 개발 워크플로우에 가져갈 만한 몇 가지 교훈이 있다고 생각합니다.
먼저, 코드 생성뿐만 아니라 전체 개발 프로세스를 최적화해야 합니다.
더 빠른 코딩 어시스턴트가 아무런 도움이 되지 않을 수 있습니다. 모든 변경 사항이 테스트나 검토를 위해 한 시간씩 기다려야 한다면 말이죠.
다음으로, 에이전트 워크로드를 적절한 경우 인간의 워크로드와 다르게 취급해야 합니다.
작은 작업을 수행하는 일시적인(ephemeral) 에이전트가 하루 종일 리포지토리를 작업하는 개발자와 반드시 동일한 환경을 필요로 하지는 않습니다.
세 번째로, 정확성을 검증하기 쉽게 만드는 시스템을 구축해야 합니다.
생성되는 코드가 많다는 것은 미묘한 통합 문제(subtle integration problems)가 발생할 기회가 더 많다는 것을 의미합니다. 더 나은 테스트, 관측 가능성(observability), 그리고 아키텍처 제약 조건이 점점 더 중요해집니다.
그리고 마지막으로, 코드 출력을 엔지니어링 진척도와 혼동해서는 안 됩니다.
병합된 변경 사항의 수는 처리량(throughput)을 측정하는 흥미로운 지표입니다.
하지만 그것 자체가 제품 품질이나 고객 가치를 측정하는 것은 아닙니다.
이러한 구분은 기계가 엄청난 속도로 변경 사항을 생성할 수 있게 되었을 때 더욱 중요합니다.
더 큰 그림