에이전트 시대를 위한 소스 컨트롤 재설계

메타데이터

• 원문 제목: Anthropic Rebuilt Git (yes really)
• URL: https://www.youtube.com/watch?v=hiI0Vk4NgeY
• 날짜: 2026-10-16
• 채널: t3dotgg
• 영상 ID: hiI0Vk4NgeY
• 발행일: 2026-10-16
• 핵심 주제: 에이전트 규모의 개발을 위한 Anthropic의 Scion 소스 컨트롤과 Antique 코드 리뷰 시스템

---

📌 핵심 질문 / 에이전트 시대의 소스 컨트롤 문제

==Git은 인간이 비싼 코드를 신중하게 검토하고, 오프라인에서도 전체 저장소를 보유한다는 전제 위에서 만들어졌다. 수백~수천 개의 에이전트가 온라인에서 동시에 코드를 생산하는 시대에는 그 전제가 병목이 되므로, 소스 컨트롤을 에이전트의 작업 방식에 맞춰 다시 설계해야 한다.==

• Anthropic은 코드 변경량이 2026년 5월 하루 약 2,500건에서 9월 하루 30,000건 이상으로 늘자 개발 인프라 자체가 가장 큰 병목이 됐다.
• Anthropic의 모노레포는 메인 브랜치 역사만 거의 100GB이고, CI가 하루 약 2,500만 번 코드를 체크아웃한다.
• Scion은 완전한 로컬 저장소 대신 온라인 서버·캐시·API를 중심에 두고, 불변 콘텐츠 주소 지정, 증분 변경 세트, 희소·가상 체크아웃으로 확장성을 확보한다.
• 목표는 나쁜 변경을 완전히 막는 것이 아니라, 변경을 빠르게 통과시키고 문제가 생겼을 때 작은 범위로 배포·되돌리기 하는 것이다.

Git은 일반적인 개발 환경에서 여전히 훌륭하지만, 거대한 모노레포와 에이전트 군집에는 분산 오프라인 저장소라는 장점이 오히려 비용이 된다. Anthropic은 Git을 범용적으로 대체하려는 것이 아니라, 자사의 특수한 규모에서 필요한 저장소·코드 리뷰·검색·CI의 결합체를 직접 만들며 소스 컨트롤의 기본 가정을 재검토했다.

1. Git이 만들어진 세계와 에이전트가 만드는 세계

1.1. Git의 전제와 남아 있는 거친 부분

Git은 코드가 비싸고 사람의 검토가 필수였던 시대에 최적화됐다. 잃어버린 코드나 잘못 합쳐진 코드의 비용이 컸기 때문에, 사람에게 승인권을 주고 코드가 어디로 흘러가는지 통제하는 구조가 합리적이었다.

1. 인간 중심의 안전 모델

   1. 비싼 변경: 코드 작성 자체가 큰 비용이었으므로 변경량을 제한하고 검토를 거치는 것이 자연스러웠다.
   2. 완전한 로컬 사본: 각 클라이언트가 이력·차이·비난(blame)을 직접 계산할 수 있도록 전체 저장소를 내려받는 방식이 강력했다.
   3. 명시적인 승인: 브랜치, 태그, 풀 리퀘스트, 머지 큐는 사람이 변경을 순서대로 확인한다는 가정 위에 있다.

2. Git이 산업 전반에 남긴 영향

   1. Git의 작동 방식은 팀 협업 방식과 GitHub의 제품 구조를 결정했다.
   2. 비밀 관리처럼 Git이 원래 해결하려던 문제가 아닌 영역도 커밋·저장·배포라는 사고방식의 영향을 받았다.
   3. 환경 변수도 안전하게 저장소에 커밋할 수 있어야 한다는 주장은 Git의 한계를 비꼬면서도, 개발자가 원하는 것은 실제로 소스와 설정을 함께 재현할 수 있는 환경이라는 점을 드러낸다.

3. GitHub가 만드는 운영상의 마찰

   1. 외부 추정치에 따르면 GitHub의 여러 기능은 합산 최대 약 7%의 다운타임을 보인다.
   2. GitHub Actions가 실패하거나 웹 페이지가 로드되지 않아 릴리스가 막히고, 중요한 변경을 머지하지 못하는 일이 반복된다.
   3. GitHub의 업타임 그래프가 안정적인 초록색 막대보다 크리스마스트리처럼 보인다는 비유는 플랫폼 장애가 개발 흐름에 직접 미치는 영향을 강조한다.

1.2. 병목의 중심이 코드 작성에서 개발 인프라로 이동하다

Anthropic은 Claude가 연구 루프를 자율적으로 반복하고, 복잡한 프로그램을 미세 최적화하고, 새로운 서비스를 처음부터 만드는 수준에 도달하면서 코딩 자체가 더 이상 가장 큰 병목이 아니라고 설명한다.

1. 폭증하는 변경량

   1. 2026년 5월 Anthropic의 하루 머지 변경량은 약 2,500건이었다.
   2. 2026년 9월에는 하루 30,000건을 넘었다.
   3. 변경을 머지할 잠재 수요는 사실상 무한하며, 병목 하나를 제거할 때마다 더 많은 코드가 생산된다.

2. 머지 버튼의 위험을 낮추는 두 방향

   1. 머지 시점에는 이미 코드가 안전할 가능성이 높도록 테스트·검토·자동화를 강화한다.
   2. 잘못 머지된 뒤에도 제한된 사용자에게 먼저 배포하고, 이상이 생기면 빠르게 되돌려 피해 범위를 줄인다.
   3. 이 구조가 자리 잡으면 사람이 한 번에 처리할 수 있는 변경량이 크게 늘고, 실패를 두려워해 머지 앞에 마찰을 계속 추가할 필요가 줄어든다.

3. 높은 변경 속도가 이미 현실이 된 사례

   1. T3 Code에서는 밤 12시부터 새벽 3~4시까지 약 4시간 동안 세 페이지에 달하는 GitHub 머지 이력을 만들었다.
   2. 6시간마다 나오는 나이틀리 릴리스에 최대한 많은 변경을 넣고, 다운로드해 테스트한 뒤 문제가 있으면 빌드를 취소하는 흐름이 가능했다.
   3. 한 번에 50개가 넘는 PR을 자신 있게 머지하는 경험은 1년 전만 해도 상상하기 어려웠던 속도다.

2. Anthropic이 Git을 대체한 배경과 범위

2.1. Scion과 Antique의 탄생

Anthropic은 자체 버전 컨트롤 시스템 Scion을 만들고, 코드 리뷰 화면 Antique, 코드 검색, 풍부한 소스 컨트롤 API, 대량의 검토된 변경을 착륙시키는 새로운 흐름을 함께 구축했다.

1. 5개월 마이그레이션

   1. 거대한 모노레포를 Git에서 Scion으로 완전히 옮겼다.
   2. 저장소·리뷰·검색·CI에 걸친 관련 시스템을 같은 5개월 안에 만들고 마이그레이션했다.
   3. 변경량이 10배로 증가하는 동안 시스템을 옮겼다는 점이 핵심이다.

2. 기존 사례와의 연결

   1. Meta는 대규모 체크아웃에서 Git이 제대로 동작하지 않아 Mercurial을 크게 확장하고, 스택드 디프(stacked diff)를 중심으로 한 흐름을 만들었다.
   2. Graphite는 Meta식 소스 컨트롤을 GitHub 사용자에게 제공하기 위해 만들어진 제품이며, 이후 Cursor는 Graphite를 인수하고 Origin이라는 GitHub 대안을 만들고 있다.
   3. Google의 Piper와 Meta의 Sapling도 거대한 모노레포를 위한 선행 사례다.
   4. 표준 도구가 자신의 워크플로에 맞지 않는다면 산업 표준을 억지로 맞추기보다 필요한 시스템을 직접 만드는 편이 합리적이다.

3. 모노레포라는 조직적 전제

   1. Anthropic과 OpenAI는 대부분의 프로젝트를 하나의 거대한 모노레포 안에 둔다.
   2. Anthropic의 모든 개발 작업은 사실상 하나의 저장소 안 여러 프로젝트와 디렉터리에서 일어난다.
   3. 이런 조직에서는 프로젝트 하나를 다루는 일반적인 팀보다 저장소 이력, 검색, 체크아웃, 권한 관리가 훨씬 큰 규모로 발생한다.

2.2. Git의 분산 오프라인 모델이 만든 비용

Git의 각 클론은 완전한 독립 저장소이므로 오프라인에서도 이력·차이·blame·체크아웃을 계산할 수 있다. 일반적인 저장소에는 훌륭한 설계지만, Anthropic의 모노레포에서는 필요한 데이터와 작업량이 지나치게 커졌다.

1. 저장소 크기와 체크아웃 수

   1. 메인 브랜치의 역사는 거의 100GB다.
   2. 압축된 작업 사본은 25GB를 넘는다.
   3. CI는 개발자 환경·에이전트 샌드박스·연구 작업을 제외하고도 하루 약 2,500만 번 코드를 체크아웃한다.
   4. 이 데이터를 Git 방식으로 직접 전송하면 하루 약 600PB 규모의 트래픽이 필요해진다.

2. 기존 우회책의 한계

   1. 얕은 클론, 희소 체크아웃, 프로미저 리모트 같은 Git 기능을 사용했다.
   2. 내부 Git 미러와 블롭 스토리지의 저장소 스냅샷·시드도 운영했다.
   3. 최대 수백 개의 내부 Git 미러를 유지했지만, 머지 속도가 높아질수록 운영 부담이 커졌다.
   4. 부분 클론은 메인 브랜치 끝에서 점점 멀어졌고, diff와 blame처럼 이력에 의존하는 기능을 계속 정상화하려면 더 많은 관리가 필요했다.

3. 온라인 에이전트라는 새로운 클라이언트

   1. Claude를 사용하는 작업은 클라우드의 GPU와 연결되어야 하므로 사실상 항상 온라인이다.
   2. 모든 클라이언트가 언제든 완전한 저장소를 보유하고 동기화해야 한다는 가정은 에이전트 작업에 불필요한 비용을 만든다.
   3. Git을 훌륭하게 만든 오프라인·분산 속성이 저장소가 커지자 오히려 확장성을 방해했다.

3. Scion의 핵심 설계 원칙

3.1. 서버 중심, 클라이언트 비대칭

Scion은 항상 접근 가능한 서버가 질문에 답하고, 클라이언트는 필요한 데이터만 가져오는 구조다.

1. 항상 온라인인 클라이언트

   1. 클라이언트는 필요할 때 서버에서 데이터를 가져온다.
   2. GitHub의 가용성을 전제로 하지 않으므로 온라인 상태에서도 특정 SaaS가 반드시 살아 있어야 한다는 의존을 줄인다.
   3. 개발자 머신, CI, 에이전트 샌드박스가 같은 데이터 모델을 사용하되 필요한 부분만 요청한다.

2. 역할의 분리

   1. 서버는 파일 이력·blame에 답하고, 커밋·머지·리베이스를 만들며, 소스 컨트롤의 핵심 연산을 수행한다.
   2. 클라이언트는 제한된 로컬 객체 캐시를 유지하고, 디스크에 작업 사본을 배치하고, 파일 시스템 변경을 감시하고, 사용하기 쉬운 인터페이스를 제공한다.
   3. 클라이언트는 혼자 계산하는 능력이 적지만 로컬에 유지해야 할 데이터가 훨씬 적다.

3. 소스 컨트롤을 API로 노출

   1. Git 기반 CI 작업은 저장소 질문 하나를 하려 해도 전체 로컬 복사본을 유지하거나 특정 공급자의 API를 사용해야 한다.
   2. Scion은 클라이언트가 사용하는 모든 소스 컨트롤 질의를 API로 노출한다.
   3. 자동 bisect, 자동 revert처럼 대규모 저장소 전체를 내려받아야 했다면 실용적이지 않았을 도구도 API만으로 운영할 수 있다.

3.2. 전역 상태를 없애고 변경을 싸게 만들기

수백 개의 에이전트가 동시에 커밋하는 환경에서는 전역 포인터와 잠금이 병목이 된다.

1. 수평 확장 가능한 구성

   1. 저장소 데이터는 여러 구성 요소에 분산되고, 각 구성 요소는 독립적으로 확장된다.
   2. 서버 어디에도 저장소의 완전한 물질화 사본을 두지 않는다.
   3. Git의 pack file에 해당하는 유지보수 부담을 없애고, 객체를 압축 번들로 관리한다.

2. 값싼 증분 커밋

   1. 커밋·리베이스·머지는 서버에서 수행하므로 별도의 push 단계가 없다.
   2. 커밋과 그에 따른 데이터 구조 갱신 비용은 저장소 전체 크기가 아니라 변경 크기에 비례해야 한다.
   3. 한 사람이 커밋할 때 다른 사람을 막지 않아야 하며, 현실적으로는 500개 에이전트가 커밋하는 동안 또 다른 500개 에이전트가 막히지 않아야 한다.

3. 브랜치·태그 포인터의 절제

   1. Scion은 메인 ref와 릴리스 브랜치를 제외하면 커밋을 가리키는 전역 ref를 되도록 사용하지 않는다.
   2. 모든 서버가 합의해야 하는 전역 상태는 이 속도에서 확장성 문제를 만든다.
   3. 데이터셋에 변경 세트를 append하는 방식이 포인터를 이동하거나 전체 트리를 재구성하는 방식보다 단순하고 병렬화하기 쉽다.

3.3. 희소·가상 작업 사본

작업 사본은 선택 사항이며 기본적으로 희소(sparse)하다. 필요한 디렉터리와 파일만 가져오고, 실제로 읽는 순간까지 파일을 물질화하지 않을 수 있다.

1. 체크아웃을 건너뛰는 작업

   1. CI가 커밋과 머지 베이스 사이의 diff만 필요하다면 서버에 해당 질문을 직접 보낸다.
   2. 많은 쓰기 작업도 작업 사본 없이 API만으로 처리한다.
   3. 이 방식은 수천만 번의 불필요한 전체 체크아웃을 줄인다.

2. 희소 체크아웃과 가상 체크아웃

   1. 희소 체크아웃은 클라이언트가 요청한 디렉터리만 담는다.
   2. 가상 체크아웃은 파일을 디스크에 미리 만들지 않고 필요할 때 materialize한다.
   3. 작업은 실제로 읽은 데이터에 대해서만 비용을 지불한다.

4. Scion의 데이터 구조와 서버 아키텍처

4.1. 변경 세트와 블롭 스토리지

Scion의 기본 단위는 **변경 세트(change set)**이며, 변경 세트는 write-ahead log의 항목으로 생성된다.

1. Git 커밋과 다른 저장 단위

   1. Git 커밋이 트리를 가리키는 포인터를 저장한다면, 변경 세트는 첫 번째 부모 대비 바뀐 파일 목록을 저장한다.
   2. 각 바뀐 파일에는 콘텐츠 주소(content address) 포인터가 붙고, 압축된 파일의 전체 내용은 블롭 스토리지에 둔다.
   3. 소스 코드 자체가 메타데이터 데이터베이스 안에 전부 들어 있는 것이 아니라, 요청할 때 블롭 스토리지에서 가져오는 구조다.

2. 변경 세트의 주요 필드

   1. 작성자(author)와 커미터(committer)를 분리한다.
   2. 작성 시각, 커미터 시각, 메시지, 부모 변경 세트를 기록한다.
   3. 바뀐 파일 목록과 각 파일 내용이 있는 블롭을 가리키는 포인터를 기록한다.
   4. 작성자는 변경을 촉발한 사람이나 시스템이고, 커미터는 실제로 변경을 수행한 에이전트 또는 실행 환경이 될 수 있다.

3. append-only의 이점

   1. 새로운 변경 세트와 블롭을 추가하면 되므로 기존 이력을 훑거나 포인터를 이동할 필요가 없다.
   2. 파일의 diff 자체가 아니라 변경 후 파일의 전체 상태를 저장하면 이력을 다시 계산할 때 연쇄적인 diff 재생성 비용을 피할 수 있다.
   3. pack file, 잠금, 교차 조정, ref 이동이 없어 높은 처리량을 유지한다.

4.2. 파생 데이터와 불변성

변경 세트만으로는 특정 줄을 누가 수정했는지, 파일이 어떤 커밋에서 바뀌었는지 빠르게 답할 수 없다. Scion은 필요한 질의를 위해 변경 세트 위에 파생 데이터(derived data)를 만든다.

1. 파생 데이터의 종류

   1. 파일 blame 전용 구조를 만든다.
   2. 경로 이력(path history)과 커밋 그래프용 skip list를 만든다.
   3. 복사 감지와 경로 기반 파일 검색을 위한 인덱스를 시스템이 성장하는 동안 추가했다.

2. 재귀적 계산 메커니즘

   1. 각 파생 데이터의 변경 세트 값은 부모 변경 세트의 값으로부터 재귀적으로 계산된다.
   2. 어떤 파생 데이터는 즉시 계산하고, 어떤 파생 데이터는 실제 요청이 있을 때까지 미룬다.
   3. 클라이언트가 내부 구조를 보지 않으므로 서버는 클라이언트 변경 없이 인덱스와 계산법을 최적화할 수 있다.

3. API 경계의 효과

   1. Git은 전체 데이터를 클라이언트에 주므로 새로운 질의를 추가하거나 기존 작업을 빠르게 만들 때 모든 사용자의 저장소 구조를 흔들어야 한다.
   2. Scion은 서버의 캐시·CPU·데이터 구조를 이용해 필요한 질의를 서버에 추가할 수 있다.
   3. Claude가 내부 구조에 직접 접근하면 목적을 달성하기 위해 새롭지만 지나치게 느리고 CPU를 많이 쓰는 우회법을 만들 수 있으므로, 강한 API 경계가 이런 행동을 제한한다.

4. 콘텐츠 주소 지정과 불변성

   1. 저장된 데이터는 콘텐츠 주소로 식별되고 한 번 저장되면 바뀌지 않는다.
   2. 특정 해시가 가리키는 내용을 나중에 바꿀 수 있다면 버전 관리의 핵심 보장이 깨진다.
   3. 고정된 변경 세트와 그 위에서 계산되는 유연한 파생 데이터를 분리하면 서버들이 서로 확인하지 않고도 캐시할 수 있다.

4.3. 트리·블롭 요청과 다층 캐시

Scion의 클라이언트 프로토콜은 클라이언트가 무엇을 이미 갖고 있는지 서버에 거대한 목록으로 협상하는 대신, 필요한 불변 객체를 하나씩 요청한다.

1. 재귀적 객체 수집

   1. 클라이언트는 먼저 필요한 변경 세트를 찾는다.
   2. 루트 트리부터 시작해 로컬 저장소에 없는 트리를 재귀적으로 요청한다.
   3. 필요한 트리를 확보한 뒤 파일을 구성하는 블롭을 같은 방식으로 수집한다.
   4. 특정 객체를 요청하므로 응답은 여러 캐시 계층에서 처리할 수 있고, 대용량 단일 pack file보다 중단·재개가 쉽다.

2. 권위 서버와 캐시 계층

   1. 권위 있는 Scion 서버는 변경 세트 메타데이터를 Spanner에서 읽고, 파일 내용은 클라우드 스토리지에서 가져온다.
   2. 지역 Scion 캐시는 개발자 머신의 반복 요청을 가까운 곳에서 처리한다.
   3. CI에는 최신 스냅샷을 주기적으로 유지하는 데몬이 있어 작업 시작 시 필요한 객체를 빠르게 제공한다.
   4. 캐시 데몬은 최신 스냅샷을 기준으로 재설정되고, 최근에 바뀐 부분만 추가로 해석하므로 오래된 이력을 매번 처음부터 재계산하지 않는다.

3. 통일된 RPC와 장애 격리

   1. Scion 데몬·Scion 캐시·Scion 서버는 동일한 RPC에 응답하므로 클라이언트는 캐시 토폴로지를 알 필요가 없다.
   2. 실제 운영에서는 계층을 엄격히 나눠 지역 캐시 장애가 상위 권위 서버를 압도하지 않게 한다.
   3. 각 계층의 캐시 적중률은 99%를 넘고 장기 상태를 요구하지 않아 필요할 때 쉽게 수평 확장할 수 있다.

4. 규모 효과

   1. Scion의 인프라가 요구하는 CPU와 메모리는 기존 Git 미러링 인프라보다 200배 작다.
   2. CI와 연구 작업의 체크아웃은 분 단위에서 초 단위로 줄어 두 자릿수 배 이상의 속도 향상을 얻었다.
   3. 클라이언트와 캐시가 저장소 유지보수를 수행하지 않게 되면서 CI 용량의 25%를 되찾았다.

5. AI가 바꾼 구축 방식과 맞춤형 도구의 경제성

5.1. 일곱 명이 5개월에 만든 시스템

Scion 개발은 Mythos Preview와 Claude Tag가 내부에서 사용 가능해진 시점과 겹쳤다. 두 시스템은 Scion의 필요성을 키우는 동시에 구현 속도를 높였다.

1. Git-to-Scion 파이프라인 재작성

   1. 초기 Git-to-Scion 수집 파이프라인은 엔지니어들이 직접 작성한 프로토타입이었다.
   2. 초기 내부 Mythos Preview에 전체 재작성을 요청하자 추가 지시 없이 메모리 사용량을 20분의 1로 줄이고 네 배 빠른 구현을 만들었다.
   3. 수집 순서, 데이터 구조, 암묵적인 불변 조건을 보존한 채 성능을 개선했다.

2. 작은 팀의 높은 레버리지

   1. 일곱 명의 팀이 Scion과 Antique를 모두 만들었다.
   2. 두 시스템 외에도 관련 시스템 여섯 개 정도를 5개월 안에 완전히 마이그레이션했다.
   3. 과거라면 수년의 단계적 마이그레이션과 훨씬 많은 엔지니어가 필요했을 작업이다.

3. 변경 속도의 역전

   1. Scion과 Antique의 아키텍처에 지금까지 들어간 변경은 약 12,250건이다.
   2. Anthropic의 전체 코드 변경량은 하루 30,000건 이상이므로, 하루 처리량이 이 아키텍처 전체에 들어간 변경량의 두 배를 넘는다.
   3. 에이전트 시대에는 개발 속도보다 인프라가 더 빨리 확장돼야 한다.

5.2. 맞춤형 시스템의 진입장벽이 낮아지다

AI는 특정 회사의 병목을 위해 범용 제품을 포기하고 맞춤형 대안을 만드는 비용을 급격히 낮춘다.

1. Theo가 든 사례

   1. 한 분석 공급자의 데이터를 직접 복제·미러링·백필해 R2 위의 관리형 ClickHouse에 저장하는 시스템을 부업처럼 구축했다.
   2. 기존 방식보다 10배 이상 저렴했고 에이전트가 다루기도 쉬웠다.
   3. TypeScript 컴파일러를 직접 다시 만든 결과물이 T3 Code에서 하루 수천 번 실행되고, 주간 다운로드 40,000건을 넘었다.

2. Lust와 TS Rust 실험

   1. Rust의 장점을 대부분 유지하면서 빌드 속도를 100배 빠르게 하려는 Rust 부분집합 언어 Lust를 실험 중이다.
   2. TS Rust 파일의 40% 이상을 이미 컴파일할 수 있고, 범용 Rust 생태계를 위한 언어가 아니라 특정 코드베이스의 느린 컴파일을 해결하기 위한 맞춤형 실험이다.
   3. Rust 빌드 시간이 느린 주된 원인은 borrow checker가 아니라 복잡한 LLVM 단계라는 관찰도 덧붙였다.

3. 기술 선택의 기준 변화

   1. 범용 소프트웨어는 많은 사용자의 요구를 만족시키기 위해 불필요한 일반성을 품는다.
   2. 하나의 회사가 자신의 규모와 병목만을 위해 시스템을 만들 수 있다면, 전체 산업에 최적인 도구보다 자신의 경우에 200배 작은 도구가 더 가치 있다.
   3. AI는 과거에는 불합리했던 내부 대체품의 제작·운영·전환 비용을 낮춘다.

6. 성능, 보안, 운영에서 나타난 결과

6.1. 개발자 환경과 에이전트 환경의 속도

Scion과 Git의 일상적인 소스 컨트롤 명령을 비교하면 작업 종류에 따라 큰 차이가 난다.

1. 개발자 환경의 비교

   1. pull은 25배 빨라졌다.
   2. checkout은 14배 빨라졌다.
   3. rebase는 5배 빨라졌다.
   4. status는 207배 빨라졌다.
   5. diff는 6배 빨라졌다.
   6. 새 worktree 생성은 84배 빨라졌다.
   7. 최신 변경을 가져오는 작업은 20배 빨라졌다.
   8. 커밋은 약 24배 빨라졌다는 측정과 일반 커밋 30% 향상이라는 설명이 함께 제시되며, 모든 작업이 같은 정도로 빨라지는 것은 아니다.

2. 에이전트 환경의 비교

   1. 에이전트 환경의 status는 20배 빨라졌다.
   2. 작업 트리 생성과 최신 상태 확보가 빠르므로 새 에이전트와 CI 작업을 더 신속하게 시작할 수 있다.
   3. 수천 개의 짧은 작업이 반복되는 환경에서는 한 번의 큰 속도 향상보다 체크아웃·상태 확인의 누적 비용 제거가 중요하다.

3. 작은 팀에서도 드러나는 Git 비용

   1. T3 Code의 CI는 Git 체크아웃을 기다리는 데 거의 1,000시간을 썼다.
   2. 이는 약 42일 동안 Git pull을 기다린 시간이며, 로컬 개발자의 대기 시간은 포함하지 않는다.
   3. CPU 임대 비용만 계산해도 이 작은 프로젝트가 Git pull에 쓴 비용은 약 350~600달러다.

6.2. 모노레포 보안과 코드 리뷰

대규모 모노레포에서는 속도만큼 안전성·보안·컴플라이언스가 중요하므로 Scion은 권한 모델을 처음부터 포함한다.

1. 세밀한 접근 제어

   1. 저장소 전체에 대한 풍부한 접근 제어를 제공한다.
   2. 개별 디렉터리에도 권한을 적용해 민감한 코드를 보호한다.
   3. 모노레포의 통합 이점을 유지하면서 모든 사람이 모든 코드를 볼 수밖에 없는 문제를 줄인다.

2. 의미 기반 승인

   1. Antique는 승인 규칙에 복잡한 의미 제약을 표현할 수 있다.
   2. 단순한 주석 전용 변경과 민감한 논리 변경을 구분한다.
   3. 사람은 모든 줄을 읽는 대신 결과에 큰 영향을 미치는 변경의 의도와 위험에 집중한다.

3. AI를 어디에 쓸 것인가에 대한 이견

   1. 변경 세트를 프로그램 규칙으로 분류하는 대신 Claude에게 diff를 요약하고 필터링하게 할 수도 있다.
   2. Anthropic이 계산 비용을 아끼기 위해 이런 분류 로직을 직접 만들었다면, 에이전트 활용 규모에 비해 계산 자원이 부족하다는 신호일 수 있다는 비판이 제기된다.
   3. 반대로 운영 상태를 감시하는 데는 계산을 아끼지 않고 Claude를 적극적으로 투입한다.

6.3. 운영 우수성과 Claude 슈퍼팬

Scion을 도입한 뒤 Anthropic은 과거보다 높은 업타임과 운영 안정성을 얻었다고 보고한다.

1. 구성 요소별 감시 에이전트

   1. Slack에서 Claude Tag를 사용해 시스템 구성 요소별 건강 상태를 감시한다.
   2. Scion 데몬, Scion 캐시, Antique 머지 큐 등에 각각 전담 에이전트를 둔다.
   3. 이 에이전트들은 텔레메트리와 로그를 읽으며 경험 많은 엔지니어처럼 이상 징후를 찾는다.

2. 전통적인 알림과 다른 역할

   1. 기존 알림은 미리 정의한 임계값을 넘었을 때 작동한다.
   2. 전담 에이전트는 한 구성 요소를 집요하게 관찰하며 새롭고 미묘한 이상을 찾아낸다.
   3. 전통적인 알림을 대체하기보다 두 방식을 결합해 일차원적인 모니터링의 한계를 보완한다.

7. 에이전트 시대의 엔지니어 역할과 개발 흐름

7.1. 엔지니어의 가치는 사라지지 않고 이동한다

Scion을 만든 엔지니어들은 Claude가 코드 작성에서는 자신들보다 낫다고 평가하지만, 시스템 수준의 판단을 Claude에 넘기지 않는다.

1. 사람이 제공하는 판단

   1. 여러 시스템의 상호작용을 이해한다.
   2. 설계 수준의 트레이드오프와 해결해야 할 문제의 범위를 정한다.
   3. 목표 규모와 핵심 제약을 알고, 에이전트가 더 쉬운 우회로를 택하지 못하게 한다.

2. 엔지니어가 Claude에게 말해야 하는 가장 중요한 단어

   1. Claude는 주어진 패턴을 만족하기 위해 핵심 시스템 제약을 위반할 수 있다.
   2. 마이그레이션 중 일부 시스템은 코드 리뷰 도구에 물어보지 않고 커밋 로그를 선형으로 읽어 머지 시점을 찾으려 했다.
   3. 엔지니어의 역할은 이런 구현을 발견하고 “안 된다”고 말하며 올바른 API와 설계 제약으로 되돌리는 것이다.

3. 적대적 리뷰의 양면성

   1. Anthropic은 adversarial review를 폭넓게 사용하며, 누락된 문제를 찾는 데 매우 효과적이다.
   2. 그러나 다른 모델 계열이 서로를 설득하려는 과정에서 가상의 위험에 과잉 대응하고 복잡도를 키울 수 있다.
   3. 내부 서비스를 신뢰하면 되는 부분에 과도한 검증을 추가한 사례처럼, 숙련된 엔지니어는 과잉 설계와 범위 확장을 제어해야 한다.

7.2. 테스트와 최적화의 자동화

빠른 구현은 검증을 약화시키는 대신, 에이전트가 대규모 검증 코드를 함께 작성하도록 만들었다.

1. 방어적인 코드베이스

   1. 모든 비자명한 인프라·소스 컨트롤 상호작용을 hermetic simulation으로 재현했다.
   2. 퍼징(fuzzing)과 정교한 rate limiting을 적용했다.
   3. 짧은 개발 일정에도 Scion은 가장 많이 테스트되고 방어된 코드베이스 중 하나가 됐다.

2. 알고리즘 개선

   1. Claude는 ancestry 질의에서 인덱스 하나를 놓친 경로를 찾아 알고리즘을 최적화했다.
   2. 사람이 며칠에서 몇 주 동안 분석하고 튜닝해야 할 작업을 에이전트가 반복해서 수행했다.
   3. AI가 코드만 빠르게 작성하는 것이 아니라 데이터 구조와 알고리즘의 병목을 발견하는 도구가 될 수 있음을 보여준다.

7.3. 머지 큐 대신 빠른 복구

수백~수천 개의 변경이 테스트가 진행되는 동안에도 머지될 수 있으므로, 인간 규모의 전역 머지 큐 잠금은 에이전트 규모에서 복제하기 어렵다.

1. Anthropic의 선택

   1. 전역 저장소 잠금으로 모든 변경을 순서대로 세우기보다 머지 후·배포 전 자동 테스트에 투자한다.
   2. 동시 변경이 충돌할 수 있다는 사실을 받아들이고, 충돌을 에이전트가 사람이 찾는 것보다 빠르게 해결하게 한다.
   3. 잘못된 변경을 완벽히 차단하는 것보다 빠른 탐지·제한적 배포·즉시 되돌리기가 전체 처리량에 유리하다.

2. 머지에 대한 일반화된 대안

   1. 머지 큐를 PR 하나씩 순서대로 넣는 목록이 아니라, 함께 들어가도 되는 변경 묶음으로 볼 수 있다.
   2. 승인된 변경 묶음을 Claude가 가능한 한 큰 그룹으로 결합해 메인에 넣는다.
   3. 결합 과정에서 충돌을 처리하고, 실패하면 해당 묶음만 되돌리거나 다시 조정한다.

3. 마찰의 방향 전환

   1. 전통적인 엔지니어링은 문제가 발생할 확률을 낮추기 위해 변경 앞에 마찰을 계속 추가했다.
   2. 에이전트 시대에는 결함이 완전히 사라지지 않으므로, 문제가 생겼을 때 피해를 줄이고 복구하는 경로를 짧게 만드는 편이 중요하다.
   3. 가장 엄격한 프로세스도 깨진 코드를 배포할 수 있다는 현실을 받아들여야 한다.

8. 범위의 한계와 생태계에 주는 제안

8.1. Scion은 범용 Git 대체품이 아니다

Anthropic은 Scion이 일반적인 개발자를 위한 Git 대체품이라고 주장하지 않는다.

1. 적용 대상

   1. 수만 명의 엔지니어가 하나의 모노레포를 사용하거나, 수많은 에이전트가 끊임없이 코드를 작성하는 환경을 겨냥한다.
   2. 작은 팀과 일반적인 저장소에는 Git의 단순성·생태계·오프라인 기능이 훨씬 적합할 수 있다.
   3. Scion을 도입하려면 코드 리뷰·코드 검색·CI까지 개발 생명주기 전체를 바꿔야 한다.

2. 토큰 비용이라는 특수성

   1. Anthropic은 내부 사용을 위해 다른 기업보다 훨씬 많은 모델 토큰을 지출할 수 있다.
   2. 범용 기업이 Scion 수준의 시스템을 그대로 운영하기에는 계산 비용이 비현실적일 수 있다.
   3. 다만 일정한 지능을 얻는 토큰 가격은 계속 내려가고 있다.

3. 비용 하락의 전망

   1. Bun을 Rust로 다시 쓴 사례에는 300,000달러 이상에 해당하는 Fable 토큰이 들었다.
   2. TypeScript를 Rust로 다시 쓰는 작업은 Opus 5.5 토큰 약 20,000~25,000달러 규모로 수행됐다.
   3. 가격 하락이 이어지면 1년 뒤에는 기업별 Git 대안을 수천 달러의 토큰 비용으로 구축할 가능성도 있다.

8.2. 공개 제품 대신 아이디어를 공유하는 이유

Scion을 다른 조직에 그대로 제공하기 어려운 이유는 기능 하나가 아니라 생태계 전체의 결합 때문이다.

1. 도입 비용

   1. Git과 상당히 다른 시스템이므로 모든 개발 생명주기 구성 요소를 함께 마이그레이션해야 한다.
   2. Anthropic의 코드 리뷰와 코드 검색은 내부 요구에 맞춘 매우 특수한 구현이다.
   3. 모두를 만족시키는 공개 버전을 만들면 오히려 아무 조직에도 충분히 유용하지 않을 수 있다.

2. Git 생태계에 적용할 수 있는 부분

   1. Git 서버가 Git 클라이언트와 같은 방식으로 동작해야 한다는 법은 없다.
   2. 새로운 서버 아키텍처와 수평 확장 가능한 RPC가 Git 플랫폼의 성능을 크게 높일 수 있다.
   3. 여러 포지(forge)가 공통 서버 측 RPC를 제공하고, Git 클라이언트가 이를 호출하도록 표준화할 수 있다.
   4. 협상 프로토콜도 현재 방식에 고정될 필요가 없으며, 희소·얕은 기능을 더 잘 조합할 수 있다.

3. 공동체와의 관계

   1. Git 공동체는 거의 20년 동안 수백만 개발자를 위해 플랫폼을 확장해 왔다.
   2. Scion의 경험은 에이전트형 소프트웨어 개발이 기존 시스템과 만날 때 생기는 좁은 문제 영역에 대한 초기 관찰이다.
   3. GitHub·GitLab·오픈소스 공동체가 에이전트 시대의 요구를 함께 반영할 수 있다.

주요 발언 모음

“Git은 지금 세상이 움직이는 방식에 맞는 올바른 기본 단위가 아니다.”

“커밋·리베이스·머지는 서버에서 일어나므로 push할 것이 없다.”

“엔지니어의 역할은 Claude에게 ‘안 된다’고 말하는 일이 되는 경우가 많았다.”

“문제가 생겼을 때 복구하는 일을 쉽게 만드는 것이, 문제가 절대 생기지 않도록 변경 앞에 수천 겹의 장벽을 세우는 것보다 중요하다.”

“Scion은 일반적인 사용에서 Git을 대체하기 위한 것이 아니다.”

핵심 데이터 & 수치

• 변경량 증가: Anthropic의 하루 머지 변경량은 2026년 5월 약 2,500건에서 9월 30,000건 이상으로 증가했다.
• 마이그레이션 기간: Scion, Antique와 관련 시스템의 Git 탈피 및 마이그레이션은 5개월에 진행됐다.
• 저장소 규모: 메인 브랜치 이력은 거의 100GB이고, 압축 작업 사본은 25GB를 넘는다.
• CI 체크아웃: CI만 하루 약 2,500만 번 체크아웃을 수행하며, Git 방식으로 전송하면 약 600PB의 일일 트래픽이 필요하다.
• 캐시 적중률: Scion의 각 캐시 계층은 99%가 넘는 적중률을 유지한다.
• 인프라 축소: 기존 Git 미러링 인프라 대비 CPU·메모리 요구량이 200배 작다.
• CI 용량 회수: 저장소 유지보수 부담을 없애 CI 용량의 25%를 되찾았다.
• 명령 성능: pull 25배, checkout 14배, rebase 5배, status 207배, diff 6배, 새 worktree 84배, 최신 pull 20배 향상됐다.
• T3 Code의 대기 비용: Git 체크아웃 대기만 거의 1,000시간, 약 42일이며 CPU 임대 비용은 350~600달러로 추산됐다.
• AI 구축 사례: Mythos Preview가 Git-to-Scion 파이프라인의 메모리 사용량을 20분의 1로 줄이고 속도를 4배 높였다.
• 팀 규모: 일곱 명이 Scion과 Antique를 만들고 관련 시스템 여섯 개 정도를 5개월에 마이그레이션했다.

결론 및 시사점

1. Git의 핵심 문제는 명령어 하나의 느림이 아니라, 완전한 로컬 복제·오프라인 계산·전역 ref·인간 순차 검토라는 설계 전제다.
2. 에이전트가 항상 온라인이라면 서버가 이력·머지·blame을 계산하고 클라이언트는 필요한 객체만 받는 비대칭 구조가 더 적합하다.
3. 불변 콘텐츠 주소와 append-only 변경 세트는 잠금과 전역 합의를 줄이고, 캐시·수평 확장·재시도를 쉽게 만든다.
4. 희소·가상 체크아웃은 에이전트와 CI가 거대한 모노레포 전체를 매번 복제하지 않도록 한다.
5. 높은 변경 속도에서는 머지 전 장벽을 계속 추가하기보다, 머지 후 테스트·제한적 배포·빠른 되돌리기로 실패의 blast radius를 줄여야 한다.
6. AI가 코드를 쓰는 속도가 빨라질수록 엔지니어의 가치는 줄어들지 않고, 시스템 경계·트레이드오프·금지해야 할 구현을 판단하는 쪽으로 이동한다.
7. Scion은 일반적인 Git 대체품이 아니지만, Git 서버의 API화·캐시 계층화·희소 기능 조합이라는 아이디어는 기존 생태계에도 적용할 수 있다.
8. AI로 맞춤형 대체품을 만드는 비용이 내려가면서, 기업은 범용 제품의 불편을 영원히 감수하기보다 자신의 병목을 해결하는 작은 시스템을 직접 만들 수 있게 됐다.

핵심 요약 (20줄)

1. Git은 비싼 코드를 사람이 검토하고 각 클라이언트가 전체 저장소를 보유하던 시대의 설계다.

2. Claude가 코드를 자율적으로 생산하면서 Anthropic의 하루 머지 변경량은 2,500건에서 30,000건 이상으로 늘었다.

3. 변경량이 폭증하자 코딩보다 인간 규모에 맞춘 소스 컨트롤과 CI가 더 큰 병목이 됐다.

4. Anthropic은 모노레포를 Git에서 Scion으로 옮기고 코드 리뷰 도구 Antique를 함께 만들었다.

5. 전체 마이그레이션과 관련 시스템 구축은 5개월 동안 진행됐다.

6. Anthropic의 메인 브랜치 이력은 거의 100GB이고 압축 작업 사본은 25GB를 넘는다.

7. CI는 하루 약 2,500만 번 체크아웃하므로 전체 저장소를 복제하는 방식은 막대한 비용을 만든다.

8. Scion은 항상 온라인인 에이전트를 전제로 서버가 이력·머지·blame을 계산한다.

9. 클라이언트는 제한된 객체 캐시와 필요한 작업 사본만 유지한다.

10. 변경 세트는 부모 대비 바뀐 파일과 블롭 스토리지의 불변 콘텐츠 포인터를 기록한다.

11. blame·경로 이력·커밋 그래프 같은 파생 데이터는 서버가 필요에 따라 계산한다.

12. 불변 콘텐츠 주소 지정은 서버 간 조정 없이 캐시하고 수평 확장할 수 있게 한다.

13. 희소·가상 체크아웃은 실제로 읽는 디렉터리와 파일에만 비용을 부과한다.

14. 지역 캐시와 권위 서버를 분리한 계층 구조는 99%가 넘는 캐시 적중률과 장애 격리를 제공한다.

15. Scion의 CPU·메모리 인프라는 기존 Git 미러링보다 200배 작고 CI 용량의 25%를 회수했다.

16. pull은 25배, status는 207배, 새 worktree 생성은 84배 빨라졌다.

17. 일곱 명의 팀은 AI를 활용해 Scion과 Antique 및 관련 시스템을 빠르게 구축했다.

18. 엔지니어는 코드 작성보다 시스템 제약과 설계 트레이드오프를 판단하고 Claude를 제어하는 역할을 맡는다.

19. 에이전트 규모에서는 전역 머지 잠금보다 머지 후 테스트와 빠른 되돌리기가 중요하다.

20. Scion은 범용 Git 대체품이 아니지만 서버 측 RPC·캐시·희소 체크아웃이라는 방향을 Git 생태계에 제안한다.

부록. AI 시대 모바일 개발에서 전문 컨설팅이 맡는 역할

AI가 현대 웹 개발의 상당 부분을 해결했어도 모바일 앱을 실제 출시하는 과정은 여전히 어렵다. 앱을 처음 띄우거나 작은 변경을 만드는 일은 쉬워졌지만, 실제 버그 수정, Apple 심사 대응, 빌드·배포 파이프라인 구성, 다양한 기기에서의 검증은 모델과 계속 씨름해야 하는 영역으로 남아 있다.

1. Infinite Red의 전문성

   1. Infinite Red는 React Native와 Expo를 중심으로 모바일 개발을 다루며 Swift와 Kotlin에도 전문성을 갖춘 컨설팅 회사다.
   2. Domino’s와 Microsoft 같은 기업이 이들을 부르는 이유는 코드를 조금 작성하는 능력이 아니라 실제로 앱을 출시하는 경험 때문이다.
   3. AI로 모바일 앱 개발을 시작하는 비용이 내려갈수록, 출시 단계의 전문 지식과 운영 경험의 가치가 커진다.

2. AI 이후 컨설팅의 역할 변화

   1. 컨설턴트가 단순 반복 코드를 대신 작성하는 역할은 에이전트가 상당 부분 맡는다.
   2. 컨설턴트는 잘못된 설계와 흔한 실수를 미리 막고, 앱을 빌드·배포할 수 있는 파이프라인을 세우고, 에이전트가 자신의 변경을 검증할 수 있는 환경을 만든다.
   3. 팀 전체를 정비하거나 새 앱을 처음부터 만들거나, 개발을 넘겨받거나, 고객 팀이 직접 개발하도록 필요한 파이프라인만 제공하는 방식으로 범위가 나뉜다.
   4. 더 빠른 배송과 더 적은 버그를 동시에 원한다면 도구 사용보다 출시 전후의 전문적인 검증 체계가 중요하다.