AI 에이전트 - 앤스로픽(Anthropic), 스시온(Scion): 코드 병목 해결

https://www.anthropic.com/research/redesigning-source-control

2026.10.13
[Redesigning source control at Anthropic]

인공지능의 발전으로 코드 작성 속도가 비약적으로 빨라지면서, 앤트로픽은 기존의 개발자 인프라와 버전 관리 시스템이 심각한 병목 현상에 직면하게 되었다. 이를 해결하기 위해 소수의 엔지니어들은 인공지능의 도움을 받아 클라이언트가 항상 온라인 상태라는 점을 전제한 맞춤형 버전 관리 시스템인 스시온(Scion)을 단 5개월 만에 성공적으로 개발했다. 이 새로운 시스템은 전통적인 분산형 도구와 달리 서버 중심의 구조를 채택하여 수평적 확장성을 극대화하고 저렴하고 점진적인 커밋 처리를 가능하게 했다. 결과적으로 이 사례는 다가올 AI 중심의 소프트웨어 개발 시대에 방대한 규모의 단일 저장소를 효율적으로 관리하고 운영할 수 있는 새로운 가능성을 제시하고 있다.

 

 

 

도입부 — 병목이 코드 작성에서 개발 인프라로 이동하다

원문 내용

Anthropic은 Claude의 코드 생성 능력이 향상되면서, 시스템 개발의 제약이 소스 관리·빌드·CI로 이동했다고 설명합니다. 2026년 5월에는 하루 평균 약 2,500건의 코드 변경을 병합했으며, 9월에는 하루 30,000건을 넘겼다고 제시합니다.[1]

다만 수치의 집계 기준을 구분해야 합니다.

수치	원문에서 확인되는 의미
하루 약 2,500건	5월의 일평균 병합량
하루 30,000건 초과	9월에 도달한 일일 병합 규모
30,401건	도표에 명시된 9월 9일의 병합량

따라서 이를 “9월 한 달의 일평균이 30,000건”이라고 읽을 근거는 부족합니다. 도표에는 일별 막대와 별도로 7일 이동평균선이 표시되어 있습니다.[1]

분석

이 도입부는 생산성의 정의를 바꿉니다. 코드 작성 속도만 높여서는 실제 개발 처리량이 늘어나지 않으며, 변경을 저장하고, 검토하고, 통합하고, 검증하는 경로 전체가 이를 감당해야 한다는 문제 제기입니다.

그러나 병합 건수는 처리량 지표이지, 기능 가치나 소프트웨어 품질 지표는 아닙니다. 변경 단위가 작아지거나 자동 수정이 늘어나도 병합량은 증가합니다. 따라서 이 자료가 직접 뒷받침하는 것은 개발 인프라의 부하 증가이며, 같은 비율의 사업 성과 증가까지는 아닙니다.

---

1. Growing our monorepo

모노레포가 커지면서 기존 Git 운영 방식이 한계에 도달하다

원문 내용

Anthropic의 저장소와 작업량은 다음과 같습니다.[1]

항목	원문 수치·상태
메인 브랜치 이력	약 100GB
압축한 작업 사본	25GB 초과
CI의 코드 체크아웃	하루 약 2,500만 회
단순한 방식으로 가져올 경우의 트래픽	하루 600PB 초과
기존 확장 대응	최대 수백 개의 내부 Git 미러 운영

여기서 600PB는 실제 관측 트래픽이 아니라, 단순하게 전체 데이터를 가져온다고 가정한 규모입니다.[1]

Anthropic은 shallow clone, sparse checkout, promisor remote뿐 아니라 내부 미러와 객체 스토리지의 저장소 스냅샷인 seed도 활용했습니다. 하지만 병합 속도가 빨라지면서 seed가 최신 메인 브랜치에서 더 빠르게 뒤처졌고, 부분 복제 환경에서 diff·blame 등 이력 의존 기능을 유지하는 운영 부담도 커졌습니다.[1]

분석: 저장소 크기보다 ‘반복 복제하는 작업 모델’이 문제다

이 장의 논리는 다음과 같습니다.

1. Git의 분산 구조는 각 클라이언트가 독립적으로 이력과 파일을 다룰 수 있도록 설계되어 있습니다.

1. 그러나 Anthropic은 사실상 하나의 권위 있는 중앙 저장소를 운영합니다.

1. 주요 클라이언트인 에이전트와 CI 작업은 원래 온라인 상태입니다.

1. 그럼에도 각 작업에 저장소 데이터를 반복 공급하고 로컬 처리 기반을 갖추게 하면서 비용이 발생합니다.

즉, 분산·오프라인 작업을 위한 장점과 실제 사용 방식 사이에 불일치가 생긴 것입니다. 이는 Git 자체의 보편적 실패가 아니라, 특정 작업 규모와 접근 패턴에서의 부적합성에 가깝습니다.

적용 범위: 저장소가 크다는 사실만으로 같은 결론에 도달할 수는 없습니다. 체크아웃 빈도, 실제로 읽는 파일의 비율, 이력 조회량, 작업 환경의 수명까지 함께 살펴야 합니다.

---

2. Principles for agent-scale source control

에이전트 규모에 맞춰 여섯 가지 설계 전제를 바꾸다

원문 내용과 설계 의미

설계 원칙	원문의 구체적 선택	분석적 의미
클라이언트는 항상 온라인	필요한 데이터를 서버에서 그때그때 조회	오프라인 완결성보다 데이터 이동 최소화를 우선
클라이언트·서버의 비대칭	커밋·병합·리베이스·이력 계산은 서버, 작업 사본과 제한된 캐시는 클라이언트 담당	무거운 계산과 저장소 지식을 서버에 집중
소스 관리 기능의 API 제공	클라이언트가 사용하는 질의를 다른 도구에도 공개	저장소를 복제하지 않고도 자동화 도구 개발 가능
모든 구성요소의 수평 확장	서버를 포함해 전체 저장소를 완전히 실체화한 단일 사본을 두지 않음	단일 머신의 디스크·메모리 한계를 피함
저비용·증분·잠금 없는 커밋	처리 비용을 전체 저장소 크기가 아니라 변경 크기에 연동	변경량 증가를 직접 수용하는 쓰기 경로 구성
작업 사본은 선택적이며 희소하게 구성	API만으로 처리하거나 필요한 디렉터리·파일만 가져옴	파일을 디스크에 펼치는 과정 자체를 줄임

이 원칙들은 Google의 Piper와 Meta의 Sapling을 참고했습니다. 특히 각주는 Sapling의 서버 구성요소인 Mononoke와 Bonsai 데이터 모델이 여러 기술의 선행 사례임을 명시합니다.[1]

분석: 핵심은 중앙화 자체가 아니라 책임의 재배치다

Scion은 단순히 “Git 서버를 크게 만든 시스템”이 아닙니다. 클라이언트가 저장소를 소유하고 계산하는 구조에서, 서버가 저장소 기능을 서비스로 제공하는 구조로 이동합니다.

예를 들어 CI가 변경 파일 목록만 필요하다면, 저장소를 내려받고 로컬에서 diff를 계산하는 대신 API 응답만 받습니다. 코드 검색·자동 bisect·revert도 동일한 접근을 활용합니다.[1]

반대급부도 있습니다. 이 설계는 네트워크와 중앙 서비스에 대한 의존도를 높입니다. 따라서 로컬 자율성을 줄인 만큼 서비스 가용성, 접근 지연, 장애 격리가 중요해집니다.

해석상 주의: 원문의 “lock-free”를 시스템 어디에도 잠금이나 일관성 조정이 없다는 뜻으로 확대해서는 안 됩니다. 다음 장에서는 ref 갱신에 Spanner의 compare-and-swap을 사용한다고 설명합니다.[1]

---

3. How Scion works

변경 기록과 조회 구조를 분리하고, 불변 객체를 계층적으로 공급하다

3.1 Data structures — 변경은 작게 기록하고, 조회 구조는 파생시킨다

원문 내용

Scion의 기본 작업 단위인 changeset은 write-ahead log의 항목입니다. Git 커밋이 트리의 포인터를 저장하는 것과 달리, changeset은 다음을 기록합니다.[1]

• 작성자·부모 changeset 등 메타데이터
• 첫 번째 부모를 기준으로 변경된 파일 목록
• 압축된 파일 내용에 대한 콘텐츠 주소 기반 포인터

그림에서는 메타데이터를 Spanner, 파일 내용을 Cloud Storage에 저장합니다. 파일 내용은 불변이며 해시를 기준으로 중복 제거됩니다. 루트 트리와 하위 트리는 changeset 내부에 직접 저장하는 항목이 아니라 서버가 파생시키는 구조로 표시되어 있습니다.[1]

변경 목록만으로는 blame이나 파일 이력을 빠르게 조회하기 어렵기 때문에 별도 구조를 만듭니다.

파생 데이터	지원하는 질의·기능
파일 blame 구조	특정 줄의 변경 주체 추적
경로 이력 구조	특정 파일·경로의 변경 이력 조회
커밋 그래프의 skip list	커밋 관계·조상 탐색 지원
추가 인덱스	복사 감지, 경로 기반 파일 검색

각 파생 데이터는 부모 changeset의 값을 바탕으로 재귀적으로 계산됩니다. 종류에 따라 미리 계산하거나 필요할 때 계산할 수 있으며, 클라이언트에 내부 구조를 노출하지 않아 서버 측 최적화도 독립적으로 수행할 수 있습니다.[1]

분석: 쓰기 형식과 읽기 형식을 분리한 설계다

여기서 중요한 것은 “트리를 없앴다”가 아니라 “원본 변경 기록과 조회용 구조를 분리했다”는 점입니다.

• 쓰기 경로는 변경 내용을 빠르게 받아들이는 데 집중합니다.
• 읽기 경로는 질의에 맞는 파생 구조를 활용합니다.
• 새로운 질의가 중요해지면 원본 기록 방식을 바꾸기보다 인덱스를 추가할 수 있습니다.

이는 쓰기 처리량과 조회 성능을 각각 최적화할 여지를 줍니다. 다만 지연 계산을 선택하면 최초 조회 비용이 커질 수 있습니다. 파생 데이터의 생성 지연, 재구축 시간, 실패 복구 절차는 원문에서 정량적으로 제시하지 않습니다.

또한 첫 번째 부모 기준의 변경 기록은 Anthropic의 trunk-based 개발과 메인라인 이력 중심 사용 방식에 맞춘 선택입니다. 모든 브랜치 운영 방식에 대한 보편적 최적해로 제시된 것은 아닙니다.[1]

3.2 Scaling Scion — 서버 계산을 줄이고 캐시가 직접 응답하게 한다

원문 내용

Scion의 가져오기 프로토콜은 클라이언트가 이미 가진 데이터를 서버에 알려주고 차이를 계산하게 하는 방식보다, 클라이언트가 필요한 불변 객체를 직접 요청하는 방식을 채택합니다. 클라이언트는 로컬 캐시를 확인하고 없는 트리와 blob을 요청합니다.[1]

아키텍처는 제어 경로와 객체 공급 경로를 구분합니다.

구분	주요 경로
제어 경로	클라이언트 → scion-server
CI·클러스터의 객체 공급	scn → 노드별 scion-daemon → 지역별 scion-cache → scion-server
개발자 머신의 객체 공급	개발자 머신 → 지역별 scion-cache
최종 저장소	Spanner와 Cloud Storage

제어 경로는 이력·diff·커밋 등의 기능을 담당하고, 객체 경로는 트리와 파일 내용을 전달합니다. 노드별 daemon은 주기적으로 갱신되는 스냅샷에서 시작하며, 같은 노드의 여러 작업이 객체를 재사용합니다.[1]

서버가 요청마다 거대한 packfile을 생성하거나 델타 압축을 수행하지 않아도 됩니다. 동일한 불변 객체 요청은 캐시가 처리할 수 있고, 중단된 가져오기도 객체 단위로 재개할 수 있습니다.[1]

분석: 불변 데이터로 캐시의 일관성 부담을 낮춘다

콘텐츠 주소가 같은 객체는 내용이 변하지 않으므로, 각 캐시는 객체가 갱신됐는지 다른 서버와 계속 확인할 필요가 없습니다. 불변성은 저장 형식의 특성이면서 동시에 수평 확장을 가능하게 하는 운영 조건입니다.

단, 브랜치 포인터인 ref처럼 변경 가능한 상태는 별도로 다뤄집니다. “모든 상태가 불변”인 시스템은 아닙니다.

또 하나의 중요한 선택은 캐시 계층의 우회를 엄격히 제한하는 것입니다. 지역 캐시가 실패했을 때 모든 요청이 중앙 서버로 몰려 전체 장애로 확산되는 상황을 피하려는 설계입니다.[1]

보고된 인프라 효과와 해석 범위

• 각 계층의 캐시 적중률은 99% 초과입니다.
• 기존 Git 미러 인프라 대비 CPU·메모리 요구량 기준 규모가 200분의 1 수준이라고 보고합니다.
• CI에서는 25%의 CPU 용량 여유 확보 효과를 제시합니다.[1]

이 수치들은 각각 캐시 효율, 소스 관리 인프라 자원, CI 자원에 관한 것입니다. 총운영비가 200분의 1이 되었다거나, 전체 개발 생산성이 25% 증가했다는 뜻은 아닙니다. 스토리지·네트워크·관리형 데이터베이스·모델 사용 비용을 합친 총비용 비교는 공개되지 않았습니다.

---

4. What we learned building Scion

개발자의 역할·품질 확보·운영·CI 방식을 재정의하다

이 장은 구현 구조보다 Scion을 만들고 운영하는 과정에서 무엇이 달라졌는가를 다룹니다.

4.1 소규모 팀의 개발 범위가 확대되다

Anthropic은 7명의 팀이 Scion과 코드 리뷰 도구 Antique, 약 6개의 관련 시스템을 만들고 5개월 안에 전환했다고 설명합니다. 기존 Git→Scion 수집 파이프라인을 초기 내부 Claude Mythos Preview로 재작성한 사례에서는 메모리 사용량이 20분의 1, 속도가 4배로 개선됐다고 보고합니다.[1]

분석: 개발 속도 향상뿐 아니라, 기존 구현을 전면 재작성하고 최적화하는 비용이 낮아졌다는 사례입니다. 다만 특정 내부 작업의 결과이며, 동일 과제에 대한 독립 평가나 일반 조직의 재현 결과는 제시되지 않습니다.

4.2 엔지니어의 역할이 코드 작성에서 설계 제약 관리로 이동하다

저자들은 엔지니어의 핵심 역할을 시스템 간 관계 이해, 설계상의 절충, 해결할 문제의 선택으로 설명합니다. 에이전트가 부적절한 구현 방향으로 나아갈 때 “아니오”라고 제동하는 일이 중요해졌다고 합니다.[1]

구체적인 실패 유형도 제시합니다.

• 병합 시점을 알아내면서 코드 리뷰 도구에 질의하지 않고 커밋 로그를 선형 탐색
• 내부 서비스에 대한 과도한 불신으로 불필요한 검증과 복잡성 추가

팀은 여전히 모든 변경 요청을 검토하지만, 모든 코드 줄을 읽기보다 변경 의도를 검토한다고 설명합니다.[1]

분석: 이는 검토의 폐지가 아니라 초점의 이동입니다. 다만 의도가 타당하다고 해서 구현이 정확한 것은 아니므로, 의도 중심 리뷰의 신뢰성은 테스트·정적 검사·권한 통제 등 별도의 검증 장치에 달려 있습니다.

4.3 테스트와 최적화를 더 넓게 수행하다

원문은 외부 의존성을 통제한 시뮬레이션, 퍼징, 정교한 요청량 제한을 구축했다고 설명합니다. 또한 Claude가 조상 관계 조회에서 기존 인덱스를 활용하지 못하던 알고리즘을 최적화한 사례를 제시합니다.[1]

성능 도표의 대표 수치는 다음과 같습니다. 시간은 중앙값이며, 배수는 원문 도표 표기를 그대로 옮겼습니다.[1]

환경·작업	Git	Scion	도표의 개선 배수
개발자: 최신 변경 가져오기	87초	3.5초	25배
개발자: 상태 확인	3.9초	19ms	207배
개발자: 커밋	1.4초	1.1초	1.3배
에이전트: 새 worktree 생성	7.1분	5.1초	84배
에이전트: 변경 요청당 소스 관리 총시간	34분	3.7분	9.2배
연산 작업 시작 시 체크아웃	175초	22초	8.0배
CI 작업의 체크아웃	31초	3.5초	8.8배

분석: 개선 폭은 작업별로 크게 다릅니다. 반복적인 작업 공간 구성과 상태 조회에서 특히 큰 효과가 나타나며, 이를 모든 명령의 일률적인 가속으로 표현해서는 안 됩니다.

[확인 필요: 본문과 도표의 측정 범위]
앞 장 본문은 CI·연구 작업 체크아웃이 “두 자릿수 규모 차이”, 즉 약 100배 빨라졌다고 서술하지만, 도표의 대응 항목은 8.0배·8.8배입니다. 비교 환경이나 작업 범위가 다른 것인지 설명이 없어, 대표 체크아웃 성능은 도표 수치를 사용하고 본문 표현은 별도로 유보하는 것이 타당합니다.[1]

또한 테스트를 많이 구축했다는 설명은 품질 확보 활동의 증거이지, 결함률·장애율이 얼마나 감소했는지를 보여주는 결과는 아닙니다.

4.4 모노레포 내부의 접근권한과 승인 규칙을 세분화하다

Scion은 저장소뿐 아니라 개별 디렉터리에 권한을 적용할 수 있습니다. 코드 리뷰 도구는 주석만 바꾼 변경과 민감한 로직 변경을 구분하는 등 복잡한 의미 기반 승인 조건을 표현할 수 있다고 설명합니다.[1]

분석: 저장소를 나누지 않고도 민감한 코드의 접근을 제한하며, 변경 위험도에 따라 검토 자원을 배분하려는 방향입니다.

다만 의미 기반 분류의 오류율, 승인 규칙 우회 방지, 권한 변경의 캐시 반영 방식은 공개되지 않습니다. 권한·승인 기능의 존재와 통제 효과의 검증은 구분해야 합니다.

4.5 구성요소별 관측을 담당하는 에이전트를 운영하다

팀은 Claude Tag를 활용해 scion-daemon, scion-cache, Antique 병합 큐 등의 상태를 집중적으로 관찰하는 에이전트를 배치하고 이를 “superfans”라고 부릅니다. 이들은 로그와 텔레메트리를 살피며, 기존 경보도 함께 유지합니다.[1]

분석: 고정된 임계치 경보를 대체하기보다, 미리 규칙화하지 못한 이상 징후를 탐색하는 보완 계층으로 보는 것이 정확합니다. 원문은 정량적인 탐지율·오탐률·장애 복구 시간 개선을 제시하지 않으며, 자율 복구의 권한 범위도 명확히 설명하지 않습니다.

4.6 병합 전의 전역 직렬화 대신 병합 후·배포 전 검증에 투자하다

테스트가 실행되는 동안 수백~수천 건의 변경이 병합될 수 있는 환경에서는, 병합 큐에 저장소 전체 잠금을 적용하는 방식이 잘 맞지 않았다고 설명합니다. 이에 병합 후와 배포 전 자동 테스트에 투자했으며, 동시 변경 간 충돌은 Claude가 빠르게 수정할 수 있다고 주장합니다.[1]

분석: 이는 “테스트 없이 배포한다”는 의미가 아닙니다. 검증을 없애는 것이 아니라 검증 시점과 결함 처리 방식을 바꾸는 것입니다.

다만 빠른 수정 능력만으로 안전한 운영이 보장되지는 않습니다. 실제 적용 시에는 메인 브랜치의 일시적 불안정 허용 범위, 배포 차단 기준, 되돌리기 절차, 충돌 원인 추적을 별도로 정의해야 합니다. 이는 원문에서 상세히 입증한 운영 통제가 아니라 적용 시 필요한 검토 사항입니다.

---

5. Contributing to the wider ecosystem

Scion의 보급보다 검증된 설계 요소를 Git 생태계로 확산하다

원문 내용

Anthropic은 Scion이 일반적인 Git 대체재가 아니라고 명시합니다. 적용 대상은 수만 명의 개발자 또는 대규모 에이전트가 코드를 생산하는 초대형 모노레포에 가깝습니다.[1]

도입 제약도 솔직하게 밝힙니다.

• Git과 크게 달라 개발 생애주기 전반의 전환이 필요합니다.
• 자체 코드 리뷰·검색·CI 도구가 필요합니다.
• Anthropic 내부 도구는 조직 특화도가 높습니다.
• 내부에서 사용할 수 있는 토큰 규모는 일반 기업이 현실적으로 지출하려는 수준을 크게 넘어섭니다.[1]

따라서 범용 Scion 제품을 제공하기보다, 다음과 같은 아이디어가 Git 생태계에 반영되기를 제안합니다.[1]

제안 영역	취지
서버 내부 아키텍처	서버가 클라이언트와 동일한 구조로 동작해야 한다는 제약 완화
풍부한 서버 측 RPC	이력·관계·변경 조회를 저장소 복제 없이 처리
가져오기 협상 프로토콜	대규모 작업과 캐시 활용에 적합하게 개선
sparse·shallow 기능의 조합	부분 접근 기능을 함께 사용할 때의 복잡성 완화

분석: ‘새 도구로 전면 교체’보다 ‘병목별 기능 도입’이 현실적인 결론이다

이 장은 앞선 성공 사례를 그대로 일반화하지 못하도록 경계를 설정합니다. 특히 모델 사용 비용의 특수성은 7명·5개월이라는 개발 사례의 경제성을 평가할 때 빠뜨릴 수 없는 조건입니다.

일반 조직이 가져갈 수 있는 것은 제품 자체보다 다음과 같은 판단 순서입니다.

• 로컬 저장소 없이 API로 끝낼 수 있는 작업이 있는가?
• 동일 노드의 작업들이 같은 파일을 반복 다운로드하는가?
• 전체 체크아웃이 실제 작업에 필요한가?
• 병합 병목이 데이터 이동·계산·검토·테스트 중 어디에 있는가?

이 질문으로 확인한 병목부터 개선하는 접근이 원문의 취지에 더 가깝습니다. 또한 향후 6~12개월 안에 유사 문제가 확산될 것이라는 문장은 저자의 전망이지, 업계 전체에서 확인된 사실은 아닙니다.[1]

---

출처

[1] https://www.anthropic.com/research/redesigning-source-control — Redesigning source control at Anthropic
분석 기준: 원문 본문·각주와 삽입 도표. 페이지에는 10월 15일 보완 안내가 표시되어 있습니다.