Scion: 클론 없이 서버에서 커밋하고 합치기

무엇이 문제인가

코딩 에이전트코딩 에이전트개발자 대신 코드를 읽고 고치고 명령을 실행하는 AI 프로그램. Claude Code, Codex 등이 있다.가 많아지면 저장소에 변경을 합치는 속도가 병목이 된다. Anthropic 은 2026년 10월 13일 엔지니어링 블로그에 「Redesigning source control at Anthropic」이라는 글을 올렸다. 이 글에 따르면 2026년 5월 하루 약 2,500건이던 병합이 9월에는 30,000건을 넘었고, 수만 건의 변경이 같은 브랜치에 몰리자 전체 복제와 병합 대기열이 막혔다.

Git 과 GitHub 은 이 일을 다음과 같이 처리한다. Git 공식 문서에 따르면 clone 은 저장소 전체를 새 디렉토리에 복제하고, 양을 줄이려면 --depth, --filter, --sparse 옵션을 사용한다. GitHub 은 병합 대기열(merge queue)이라는 기능을 제공한다. 공식 문서에 따르면 저장소 관리자가 브랜치 보호 규칙에서 이 기능을 필수로 설정하면, 풀 리퀘스트풀 리퀘스트한 브랜치의 변경을 다른 브랜치에 병합해 달라는 요청. 다른 개발자가 검토하고 승인한다.는 바로 병합되지 않고 대기열에 들어간다. GitHub 은 대기열의 풀 리퀘스트마다 임시 브랜치를 만들어 대상 브랜치의 최신 상태와 앞선 대기 건을 합친 뒤 필수 검사를 실행하고, 검사를 통과한 것만 병합한다. 그래서 변경이 자주 들어오는 브랜치에서도 서로 충돌하는 변경이 함께 병합되지 않는다. 대신 병합은 대기열 순서대로 한 번에 한 묶음씩 진행된다. Anthropic 은 같은 글에서 이 방식이 에이전트 규모에는 적합하지 않다고 설명한다. 테스트가 실행되는 동안에도 변경이 수백에서 수천 건씩 병합되므로, 검사한 상태와 실제 브랜치가 금세 달라진다. 업계 표준인 저장소 전체 잠금 방식의 대기열도 그 규모로는 재현할 수 없었다. 그래서 Anthropic 은 병합 전 검사 대신 병합 뒤와 배포 전의 자동 테스트에 투자했다. 트레이드오프는 동시에 병합된 변경끼리 충돌할 수 있다는 점인데, 글에는 그런 충돌을 엔지니어가 알아채기도 전에 Claude 가 대개 고친다고 적혀 있다.

어떻게 해결했나

Anthropic 의 글이 나온 뒤 사흘 안에 그 설계의 공개 구현이 세 개 올라왔다. 오늘은 그중 Carter Tran 이 Rust 로 처음부터 작성한 Scion 을 골랐다. 클라이언트는 저장소를 복제하지 않는다. 필요한 경로의 파일만 서버에서 받는다. 커밋, 리베이스, 병합은 전부 서버 API 가 수행하고, 변경을 브랜치에 최종으로 반영할 때도 서버가 처리하므로 push 단계가 없다. Scion 은 이 반영 단계를 land 라고 부르고, 병합 대기열 없이 처리한다. 먼저 변경을 브랜치의 최신 커밋 위로 리베이스한다. 이어서 브랜치가 가리키는 커밋을 compare-and-swap 으로 바꾼다. 서버는 리베이스 시점의 브랜치 버전과 지금 버전이 같을 때만 바꾸고, 그사이 다른 작업이 먼저 반영했으면 바꾸지 않는다. 이렇게 밀린 작업은 잠시 대기한 뒤 다시 시도한다. 기록, blame, 공통 조상 같은 질문도 복제 없이 서버에 질의한다. 같은 노드의 작업들은 데몬의 캐시를 통해 객체를 공유한다. Git 저장소는 단방향 가져오기 도구로 옮긴다.

무엇이 다른가

이것이 가능한 이유는 저장 형식에 있다. 변경 집합은 첫 부모와의 파일 차이와 루트 트리 포인터만 기록하고, 객체는 BLAKE3 해시로 식별해 zstd 로 압축한다. blame 과 경로 기록은 별도의 파생 색인에서 조회한다. 저장소는 Anthropic 의 Spanner 대신 CockroachDB 와 S3 호환 저장소다. 트레이드오프도 README 에 적혀 있다. 오프라인 작업, Git 프로토콜 호환, 양방향 Git 동기화는 범위 밖이고, v1 은 모노레포 하나와 Unix 클라이언트만 다룬다. 지역 캐시 서버와 가상 체크아웃은 미구현 상태이고, Anthropic 규모의 처리량은 확인되지 않았다.

어떻게 만들었나

• 커밋 206개가 2026-10-13 부터 사흘 동안 쌓였고 전부 제작자 Carter Tran 이다. 그중 3개에 Claude 가 Co-authored-by 로 적혀 있다.
• Rust 129,266줄, 크레이트 23개다. 실행 파일은 scion, scion-server, scion-daemon, scion-import 네 개이고, 테스트 함수는 1,002개다.
• SPEC.md 가 설계 명세다. 외부 입력은 Anthropic 의 글뿐이라고 밝히고, 비공개 구현에서 유래한 내용을 넣지 말라는 규칙을 컨트리뷰터에게 요구한다.
• README 의 벤치마크는 2026-10-14 에 M4 Pro 에서 측정한 수치이고, 재현 명령이 함께 적혀 있다. 같은 설계의 다른 구현으로 Go 의 open_scion 과 openscion 이 있다.

실행해 보니

빌드한 뒤 아래 순서로 시험했다.

1. 빌드. rustup 이 Rust 1.98.0 을 내려받았고, protoc 이 없어 첫 빌드가 중단됐다. pip 의 grpcio-tools 를 protoc 대신 지정하자 release 빌드가 3분 24초에 끝났고, 벤치마크 실행 파일은 35.5 MB 다.
2. 확인 실행. 파일 20개로 1회 실행해 네 시나리오가 모두 끝나는지 확인했다. Git 은 clone 과 sparse-checkout 명령을 실행했고, Scion 은 메모리 저장소를 쓰는 인프로세스 서버에 접속했다.
3. 파일 1,000개, 5회. 중앙값으로 가져오기 352.4 → 111.9 ms, 전체 체크아웃 594.8 → 336.6 ms, 부분 체크아웃 139.4 → 21.7 ms, 파일 하나 커밋 35.5 → 27.2 ms 였다.
4. 파일 10,000개, 3회. 가져오기 4,254.8 → 1,324.7 ms, 전체 체크아웃 5,245.2 → 770.8 ms, 부분 체크아웃 221.3 → 100.0 ms, 커밋 233.8 → 198.9 ms 였다.
5. README 와의 차이. README 에는 M4 Pro 에서 Git 이 커밋에서 두 크기 모두 빨랐고 10,000개 부분 체크아웃도 약간 빨랐다고 적혀 있다. 오늘 측정한 리눅스 4코어 컴퓨터에서는 네 시나리오 모두 Scion 이 빨랐다. 커밋의 차이는 25% 안쪽이라 환경에 따라 뒤집힐 수 있는 폭이다.
6. 검증. 벤치마크 코드는 체크아웃한 파일의 내용을 원본과 바이트 단위로 대조하고, 부분 체크아웃이 받은 객체 수가 파일 수 더하기 2 인지 단언한다. 두 크기 모두 그대로 통과했다.

$ benchmark 100 5
1000 files, 4096 bytes/file, 5 runs; medians:
| Scenario        | Git (ms) | Scion (ms) |
| import          |    352.4 |      111.9 |
| commit-one-file |     35.5 |       27.2 |
| full-clone      |    594.8 |      336.6 |
| sparse-clone    |    139.4 |       21.7 |

확인하지 못한 것

• 운영 저장소를 붙인 서버. Docker 가 없어 CockroachDB 와 S3 호환 저장소 대신 메모리 백엔드로만 실행했다.
• 동시 반영. 여러 작업이 같은 브랜치에 동시에 반영할 때의 compare-and-swap 재시도는 이 벤치마크에 없다. 다음에는 scripts/benchmark-scaling.py 를 서버와 함께 실행해 보자.
• 테스트 1,002개. 컴파일 시간 때문에 실행하지 않았다.

판정

작동한다. 파일 1,000개의 부분 체크아웃이 Git 보다 6배 빨랐다. 다만 서버가 메모리 저장소라 운영 환경의 수치는 아니다. 에이전트 여러 개가 한 저장소에 동시에 커밋하는 구조를 실험하고 싶고, Git 호환이나 오프라인 작업이 필요 없는 경우에 써 볼 만하다. Git 프로토콜로 접근해야 하거나 저장소가 여러 개라면 이 프로덕트는 적합하지 않다. 둘 다 v1 의 범위 밖이라고 README 에 적혀 있다.

얻어갈 것

• 설계 글만으로도 사흘이면 작동하는 구현이 나온다고 가정하고 계획하자. Anthropic 의 글은 10월 13일에 나왔고, 오늘 그 구현의 벤치마크까지 실행했다.
• 성능 비교는 자신의 환경에서 다시 측정하자. README 의 M4 Pro 에서 Git 이 빨랐던 커밋이 이 리눅스 4코어에서는 Scion 이 빨랐다.
• 벤치마크 코드에 결과 검증을 넣어 두자. 이 벤치마크는 체크아웃 내용을 바이트 단위로 대조하고 받은 객체 수를 단언한다.
• 빌드 의존성은 README 의 첫 줄에 명시하자. 오늘 Scion 의 첫 빌드는 protoc 이 없어서, open_scion 의 첫 빌드는 libcurl 헤더가 없어서 중단됐다.