# Scion: 클론 없이 서버에서 커밋하고 합치기 # Scion: committing and landing on the server, with no clone - Site: https://select1.dev/2026-10-16 (English), https://select1.dev/ko/2026-10-16 (Korean) - Entry: 006 - Published: 2026-10-16 (KST). Launch date: 2026-10-15 - Pick: Scion (source: GitHub) - Verified: ran - What: Scion 은 서버 중심 버전 관리 시스템이자 오픈소스 프로덕트다. Anthropic 의 공개 설계 글만 참고해 Rust 로 구현했고, 클라이언트는 필요한 파일만 받으며 커밋과 병합은 서버가 수행한다. - What (en): Scion is an open-source version control product that runs commits and merges on the server. It was implemented in Rust from Anthropic’s public design article alone. Clients fetch only the files they need. - Why: 오늘의 픽으로 선정한 이유는 Anthropic 의 글이 나온 지 사흘 만에 작동하는 구현이 나왔고, Git 과의 비교를 재현할 수 있어서다. - Why (en): It is today's pick because a working implementation of Anthropic’s design appeared within three days of the article, and you can reproduce its comparison with Git. - Verdict: 작동한다. 파일 1,000개의 부분 체크아웃이 Git 보다 6배 빨랐다. - Verdict (en): It works. A 1,000-file sparse checkout was 6 times faster than with Git. - Tags: agent, version-control, rust, server-centric, benchmark, ai-built ## Checked against the README - [pass] 부분 체크아웃은 요청한 디렉토리의 파일 수만큼의 blob 과 트리 2개만 받는다 — benchmark.rs 가 fetched_objects 의 수가 files_per_dir + 2 와 같은지 단언한다. 파일 1,000개와 10,000개 모두 exit 0 - [pass] 체크아웃 결과를 원본과 바이트 단위로 대조한다 — benchmark.rs 의 verify() 가 전체·부분 체크아웃의 파일 내용을 원본과 비교하고 불일치면 content mismatch 로 중단한다. 두 크기 모두 통과 - [pass] 기본 테스트와 벤치마크는 데이터베이스나 Docker 없이 작동한다 — Docker 데몬이 없는 컨테이너에서 Backend::Memory 인프로세스 서버로 실행 - [fail] Git 이 커밋에서 두 크기 모두 더 빠르고, 10,000개 부분 체크아웃도 약간 더 빠르다 — 리눅스 4코어 컴퓨터에서는 커밋 27.2 vs 35.5 ms, 198.9 vs 233.8 ms 로 Scion 이 빨랐고, 10,000개 부분 체크아웃도 100.0 vs 221.3 ms 로 Scion 이 빨랐다. README 수치는 M4 Pro ## Measured - 파일 1,000개 부분 체크아웃(5회 중앙값): Git 139.4 ms, Scion 21.7 ms (scion-conformance 의 benchmark 예제, 리눅스 4코어, 메모리 백엔드, release 빌드) ## Progress (days after launch; full history https://select1.dev/2026-10-16/progress) - day 3 (checked 2026-10-18) [active] commits since launch 13, stars 218, releases 0, contributors 1, last commit 2026-10-16 - Object transfers and checkout file writes are faster. Landing a change on a branch now batches its tree reads and writes. - It now rejects requests to copy a blob by id when the caller cannot read it. - A design document for a Git gateway was added. The gateway would let Git clients read Scion history. - The daemon fills its cache faster, and its metrics can now be queried from outside. - History and merge-base queries skip first-parent spans that contain no merge. - day 7 (checked 2026-10-22) [quiet] commits since launch 13, stars 234, releases 0, contributors 1, last commit 2026-10-16 ## 한국어 ## 무엇이 문제인가 코딩 에이전트가 많아지면 저장소에 변경을 합치는 속도가 병목이 된다. 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 헤더가 없어서 중단됐다. ### 용어 - 코딩 에이전트: 개발자 대신 코드를 읽고 고치고 명령을 실행하는 AI 프로그램. Claude Code, Codex 등이 있다. - 풀 리퀘스트: 한 브랜치의 변경을 다른 브랜치에 병합해 달라는 요청. 다른 개발자가 검토하고 승인한다. ## English ## The problem Once there are many coding agents, the rate at which changes merge into a repository becomes the bottleneck. Anthropic published “Redesigning source control at Anthropic” on its engineering blog on October 13, 2026. According to that article, merges per day went from about 2,500 in May 2026 to over 30,000 in September. Full clones and the merge queue broke down under tens of thousands of changes to the same branches. According to the Git documentation, clone copies the whole repository into a new directory, and the `--depth`, `--filter` and `--sparse` options reduce how much it copies. GitHub offers a feature called the merge queue. According to its documentation, a repository administrator can require the queue in a branch protection rule. Then pull requests join the queue instead of merging directly. GitHub creates a temporary branch for each queued pull request. The branch combines the latest target branch with the requests ahead of it. GitHub runs the required checks and merges only what passes. That keeps incompatible changes from being merged together even on a branch that receives changes constantly. In exchange, merges happen in queue order, one group at a time. The same article says this does not fit agent scale. Hundreds or even thousands of changes can merge while tests are still running, so the state that was tested soon differs from the actual branch. The industry standard is a global repository lock on the merge queue. Anthropic could not make it work at that scale either. Anthropic instead invested in post-merge and pre-deploy automated testing. The trade-off is that concurrently merged changes can conflict, and the article says Claude can typically fix these conflicts faster than humans can even identify them. ## How it solves it Three public implementations of that design appeared within three days of Anthropic’s article. Today’s pick is Scion, which Carter Tran wrote from scratch in Rust. The client does not clone the repository. It fetches only the files under the paths it needs. Server APIs handle commit, rebase and merge. They also handle the final step that puts a change on the branch, so there is no push step. Scion calls that final step land, and it uses no merge queue for it. A change is first rebased onto the latest commit on the branch. The server then moves the branch to the new commit with a compare-and-swap. It moves the branch only if the branch is still at the version it had at rebase time. It leaves the branch alone if another job got there first. The job that lost waits briefly and retries. The client also asks the server for history, blame and merge bases without a clone. Jobs on the same node share objects through a daemon cache. A one-way importer moves Git repositories into Scion. ## What is different The storage format makes this possible. A changeset records a root-tree pointer and only the file deltas against its first parent. Objects are identified by BLAKE3 hashes and compressed with zstd. Blame and path history are looked up in separate derived indexes. Scion uses CockroachDB and S3-compatible storage instead of Anthropic’s Spanner. The README puts offline work, Git protocol compatibility and two-way Git sync out of scope. It says v1 covers one monorepo and Unix clients only. Regional cache servers and virtualized checkouts are not implemented yet, and throughput at Anthropic’s scale has not been established. ## How it was built - 206 commits over three days from 2026-10-13, all by the maker, Carter Tran. Three of them carry Claude in a Co-authored-by trailer. - 129,266 lines of Rust in 23 crates. The project has four executables (scion, scion-server, scion-daemon and scion-import) and 1,002 test functions. - SPEC.md is the design specification. It states that the only external input is Anthropic’s article, and requires contributors not to add material derived from non-public implementations. - The README reports benchmarks measured on an M4 Pro on 2026-10-14 and includes commands to reproduce them. Other implementations of the same design are open_scion and openscion, both in Go. ## Running it 1. Build. rustup downloaded Rust 1.98.0, and the first build stopped for lack of protoc. I used pip’s grpcio-tools in place of protoc. The release build finished in 3 minutes 24 seconds, and the benchmark executable is 35.5 MB. 2. Smoke run. I ran all four scenarios once with 20 files to check that they complete. Git ran clone and sparse-checkout commands. Scion connected to an in-process server on in-memory storage. 3. 1,000 files, 5 runs. Medians, Git → Scion: import 352.4 → 111.9 ms, full checkout 594.8 → 336.6 ms, sparse checkout 139.4 → 21.7 ms, one-file commit 35.5 → 27.2 ms. 4. 10,000 files, 3 runs. Import 4,254.8 → 1,324.7 ms, full checkout 5,245.2 → 770.8 ms, sparse checkout 221.3 → 100.0 ms, commit 233.8 → 198.9 ms. 5. Difference from the README. The README says that on the M4 Pro, Git committed faster at both sizes and was slightly faster on the 10,000-file sparse checkout. On today’s 4-core Linux machine, Scion was faster in all four scenarios. The commit gap is under 25%, and the result can reverse on a different machine. 6. Verification. The benchmark code compares the checked-out file contents with the originals byte for byte, and asserts that the sparse checkout fetched exactly two more objects than the file count. The checks passed at both sizes. ``` $ 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 | ``` ## Not checked - A server on production storage. I had no Docker, so I ran the server only on the in-memory backend instead of CockroachDB and S3-compatible storage. - Concurrent landing, when several jobs put changes on the same branch at once. The compare-and-swap retry is not in this benchmark. Next time, run scripts/benchmark-scaling.py against a server. - The 1,002 tests. I did not run them because of the compile time. ## Verdict It works. A 1,000-file sparse checkout was 6 times faster than with Git. The server ran on in-memory storage, though, so these are not production numbers. It is worth a try when you want to experiment with many agents committing to one repository at once and need neither Git compatibility nor offline work. If access must go through the Git protocol, or there is more than one repository, this product is not the right choice. The README puts both outside the v1 scope. ## What to take away - A design article alone can be enough to build a working implementation in three days. Anthropic’s article came out on October 13, and I ran Scion’s benchmark today. - Re-measure performance comparisons on your own machine. Git was faster at committing on the README’s M4 Pro. Scion was faster on this 4-core Linux box. - Verify the results inside the benchmark code. This one compares checkout contents byte for byte and asserts the number of fetched objects. - Put build dependencies on the first line of the README. Today the first Scion build stopped without protoc, and the first open_scion build stopped without libcurl headers. ### Terms - coding agent: An AI program that reads and edits code and runs commands for a developer. Claude Code and Codex are examples. - pull request: A request to merge the changes on one branch into another. Other developers review and approve it. ## Launches the same day - Openlume (Show HN, 16): 설명 생성기. 기술 질문을 하면 애니메이션 설명을 만들고, 보다가 끼어들어 다시 물을 수 있다. - Pi subagents Lite (Show HN, 5): Pi 에이전트용 하위 에이전트. 시스템 프롬프트를 깨끗하게 유지한다. - server-noonien (Show HN, 3): 에이전트 기억 동기화 도구. 서버 없이 여러 기기의 기억을 충돌 없이 합친다. - arcKode (Show HN, 3): 코드베이스 문맥 도구. SQLite 로 작은 로컬 모델에 저장소 전체의 문맥을 준다. - handwired (GitHub, 892): 실험 라이브러리. 보통의 JavaScript 코드를 신경망으로 바꾼다. - open_scion (GitHub, 677): Scion 의 Go 구현. GitLab 의 Gitaly 를 확장했고, 변경은 병합 대기열 없이 compare-and-swap 으로 브랜치에 반영한다. - cc-stretch (GitHub, 284): Claude Code 플러그인. 답변을 짧게 보여 주고, 누른 구절만 길게 펼친다. - Scion (GitHub, 186): 서버 중심 버전 관리 시스템. 클론 없이 서버에서 커밋하고 병합한다. Anthropic 의 공개 설계 글을 Rust 로 구현했다. - Navige (Product Hunt, 200): AI 에이전트 비용 관리 도구. 폭주하는 지출을 막는다고 소개한다. - OpenMuse (Product Hunt, 143): 개인 비서. 오픈소스이고 자체 호스팅하며, 어떤 하네스에도 붙는다고 소개한다. - 마루비 (MARUVI) (Disquiet): 윈도우·맥용 AI 비서. 질문마다 클로드·챗GPT·제미나이를 고르고, 기억은 내 컴퓨터에 파일로 남긴다. - 딸깍 (Disquiet): 두뇌 퍼즐 사이트. 매일 자정에 10문제를 열고, 문제는 프로그램이 만들고 검증한다. ## Getting started - Steps: git clone https://github.com/CarterT27/scion && cd scion ; cargo build --release -p scion-conformance --example benchmark ; target/release/examples/benchmark 100 5 - Needs: Rust 1.98.0 (rust-toolchain.toml 에 고정, rustup 이 내려받는다), protoc (Protocol Buffers 컴파일러), Git (벤치마크의 비교 대상), 실제 운영에는 CockroachDB, S3 호환 저장소, TLS 인증서, Ed25519 서명 키 - Cost: Apache-2.0, 무료. 가격 페이지는 없다. - Note: 서버와 CLI 전체는 cargo build --workspace --all-targets 로 빌드한다. protoc 이 없으면 pip install grpcio-tools 뒤 python -m grpc_tools.protoc 을 감싼 스크립트를 PROTOC 으로 지정하면 된다.