핵심 요약: Anthropic Scion은 코딩 에이전트의 도입으로 모노레포(monorepo)의 일일 머지(merge) 건수가 2026년 5월 약 2,500건에서 9월 30,000건 이상으로 급증하자, Anthropic이 자체 개발한 사내 버전 관리 시스템입니다. Scion은 커밋, 머지, 리베이스(rebase)를 서버에서 직접 처리합니다. 사내 전용 시스템이며, Anthropic 측은 Scion이 Git을 완전히 대체하기 위한 범용 시스템은 아니라고 밝혔습니다.
Anthropic이 Scion을 만든 이유와 주요 변화
2026년 10월 13일, Anthropic 엔지니어링 팀은 Anthropic의 소스 코드 관리 재설계(Redesigning source control at Anthropic)라는 글을 발표했습니다. 도입부의 주장은 단도직입적입니다. “시스템을 구축하고 연구를 수행하는 데 있어 코딩은 더 이상 병목이 아닙니다.” 그들이 지목한 진짜 병목은 바로 “소스 코드 관리, 빌드, CI 등 인간의 작업 규모에 맞춰 구축된 모든 개발자 인프라”였습니다.
수치를 보면 그 이유를 알 수 있습니다. 2026년 5월만 해도 하루 약 2,500건이던 코드 변경 머지 수가 9월에는 30,000건을 넘어섰습니다. 불과 4개월 만에 12배나 급증한 것으로, Anthropic은 코딩 에이전트의 활용을 그 원인으로 꼽았습니다.
Git은 인간 작업자의 규모에서는 잘 버텼지만, 에이전트 규모의 작업량 앞에서는 무너졌습니다. Anthropic에 따르면 하루 CI 체크아웃 수만 약 2,500만 건에 달했고, main 브랜치 히스토리는 100GB에 육박했으며, 피크 시점에는 사내 Git 미러만 수백 개에 달했습니다. 단순한 fetch 방식이었다면 하루 Git 트래픽만 600PB를 넘어섰을 것입니다.
이에 7명으로 구성된 팀이 Scion과 함께 Antique라는 코드 리뷰 툴, 코드 검색 기능, 디렉터리별 접근 제어 시스템을 구축했습니다. 그리고 5개월 만에 모노레포를 Git에서 성공적으로 이전했습니다. 심지어 Git에서 Scion으로 데이터를 수집하는 파이프라인을 Claude Mythos Preview로 재작성했는데, 그 결과 메모리 사용량은 20배 줄어들고 속도는 4배 빨라졌습니다.
팀 전체에서 Claude Code, Codex 또는 여타 코딩 에이전트를 운영 중이라면, 이 글은 머지않아 여러분의 팀이 맞닥뜨릴 병목 현상을 미리 보여주는 예고편과 같습니다. Sharkly는 바로 이 문제를 해결하기 위해 설계되었습니다. 여러 터미널에 흩어져 있던 에이전트의 작업, 결과물, 코드 리뷰를 공유 태스크(Tasks) 내에서 통합 관리할 수 있도록 지원합니다.
Scion은 Git과 어떻게 다른가
Git은 모든 클론이 오프라인에서도 작동 가능한 온전하고 독립적인 히스토리 사본이라고 가정합니다. 반면 Scion은 정반대의 전제를 둡니다. 클라이언트는 항상 온라인 상태이며, 자체적인 연산은 최소화한다는 점입니다.
| Git | Anthropic Scion | |
|---|---|---|
| 커밋, 머지, 리베이스 실행 위치 | 로컬(노트북) | 서버 |
| 로컬 데이터 | 전체 히스토리 | 제한된 객체 캐시, sparse 또는 가상화된 체크아웃 |
| 작업 단위 | 트리를 가리키는 커밋 | WAL(Write-Ahead Log) 기반 변경 셋(수정된 파일 목록) |
| 브랜치 및 레퍼런스(ref) | 가볍고 사용 권장 | main 및 release 브랜치 외 사용 지양 |
| Fetch 방식 | 팩파일(Packfile) | 객체 단위(트리 후 블롭), 저장소 유지보수 불필요 |
| 오프라인 작업 | 가능 | 불가 |
| 주요 클라이언트 | 사람 | 에이전트, CI, 연구용 잡(Job) |
아키텍처는 세 가지 계층으로 이루어져 있습니다. 각 노드에 위치한 scion-daemon, 리전별 scion-cache, 그리고 신뢰할 수 있는 단일 소스 역할을 하는 scion-server입니다. 클라이언트 CLI는 scn입니다. 각 계층의 캐시 적중률(hit rate)은 99% 이상을 유지합니다.
도입 효과는 엄청났습니다. CPU 및 메모리 사용량이 기존 Git 미러링 환경 대비 200배 감소했습니다. CI 및 연구용 체크아웃 시간은 몇 분에서 몇 초 수준으로 단축되었고, CI의 CPU 가용 용량은 25% 늘어났습니다.
서버 측 커밋 방식이 포기한 것들
서버 측 커밋 방식을 택하면 비행기 안에서도 작업할 수 있게 해주는 전체 로컬 히스토리라는, Git을 성공으로 이끈 핵심 특성을 포기해야 합니다. Anthropic 역시 이를 분명히 인정합니다. Scion은 “범용적인 측면에서 Git을 대체하기에 전혀 적합하지 않으며”, 다른 조직에서 사용할 수 있는 형태로 제공하기도 어렵다고 밝혔습니다. 외부에 공개된 제품도 아니며, 블로그 글에서도 오픈소스로 언급되지 않았습니다.
동시성(concurrency) 제어 방식도 일반적인 예상과는 다릅니다. Anthropic은 글로벌 락(lock)을 걸어 모든 머지를 직렬화하지 않습니다. 동시 변경 작업 간에 충돌이 발생할 수 있으며, 팀은 머지 후 테스트(post-merge testing)와 배포 전 테스트(pre-deploy testing)를 통해 이를 잡아냅니다.
AI 에이전트를 위한 Git: Scion 없는 팀을 위한 시사점
우리는 Scion을 쓸 수도 없고, 사실 쓸 필요도 없습니다. 저장소 크기가 100GB에 달하지도 않고, 하루에 2,500만 건의 체크아웃을 실행하지도 않기 때문입니다. 하지만 이 글에서 주목해야 할 유용한 부분은 문제의 본질입니다. 이는 규모와 상관없이 어디서나 나타나기 때문입니다.
에이전트가 코드를 작성하기 시작하면 병목 지점은 다운스트림(후속 작업 단계)으로 이동합니다. 처음에는 머지 단계로, 다음에는 리뷰 단계로 옮겨갑니다. DevOps.com의 보도와 TechSpot의 분석 기사 모두 Scion을 에이전트의 생산량을 따라잡기 위해 인프라를 혁신한 사례로 평가했습니다. 5명 규모의 팀이 에이전트 10대를 돌릴 때도 규모만 다를 뿐 똑같은 장벽에 부딪히게 됩니다.
다음과 같은 징후들이 익숙하게 느껴지실 겁니다:
- 같은 날 오후 두 에이전트가 동일한 파일을 수정해 충돌을 직접 손으로 해결해야 한다.
- 누군가 읽기도 전에 풀 리퀘스트(PR)가 계속 쌓여만 간다.
- 에이전트의 작업 속도는 여전히 빠른데, CI 큐(대기열)는 매주 길어진다.
- 어떤 에이전트가 무엇을 왜 변경했는지 아무도 설명하지 못한다.
- 화요일에 딴 브랜치를 금요일에 리베이스하려다 엉망진창이 된다.
Anthropic은 새로운 인프라를 구축해 1번과 3번 문제를 해결했습니다. 하지만 여러분은 이미 보유하고 있는 프로세스와 Git 도구만으로도 이 다섯 가지 문제를 모두 해결할 수 있습니다.
코딩 에이전트의 머지 충돌: 왜 기하급수적으로 늘어나는가
머지 충돌은 작업자의 수가 아니라 작업의 중복도에 비례해 발생합니다. 하나의 광범위한 목표를 두고 작업하는 10대의 에이전트는 끊임없이 같은 파일을 건드립니다. 반면 10개의 명확하고 좁은 태스크를 수행하는 10대의 에이전트는 거의 충돌하지 않습니다. 즉, 에이전트의 수보다 각 태스크의 범위(scope)가 훨씬 중요합니다.
브랜치가 오래 유지될수록 상황은 더욱 악화됩니다. 브랜치가 열려 있는 매 순간 main 브랜치는 계속 전진하기 때문입니다. 에이전트는 사람이 닫는(머지하는) 속도보다 훨씬 빠르게 브랜치를 생성하기 때문에 이 격차는 더욱 벌어집니다. 이 간극을 수치로 분석한 내용은 앞서 다룬 사람의 하루 작업 시간으로 리뷰 가능한 에이전트 작업량을 참고하시기 바랍니다.
Scion 없이 지금 당장 실천할 수 있는 해결책
다음 다섯 가지 습관만 잘 들여도 일반적인 팀에서 겪는 문제의 대부분을 해결할 수 있습니다. 새로운 버전 관리 시스템을 도입할 필요도 없습니다.
각 태스크마다 독립된 워크트리(worktree)를 부여하라
Git 워크트리(worktree)는 동일한 저장소에 연결된 별도의 작업 디렉터리입니다. 태스크마다 워크트리를 하나씩 할당하면 두 에이전트가 동시에 같은 디렉터리에 쓰는 일을 원천 차단할 수 있습니다.
git worktree add ../tasks/COIN-212 -b agent/COIN-212 origin/main
cd ../tasks/COIN-212
# run the agent here, commit, push, open a PR
git worktree remove ../tasks/COIN-212
구체적인 설정 방법은 AI 코딩 에이전트를 위한 Git 워크트리 활용법에서, 정리 작업과 관련된 내용은 골치 아픈 정리 작업 없이 코딩 에이전트용 워크트리 관리하기에서 확인하실 수 있습니다.
태스크 범위를 작고 명확하게 제한하라
각 태스크를 작성할 때는 건드릴 수 있는 파일이나 모듈을 명시하고, 완료 여부를 검증할 수 있는 확인 절차를 포함해야 합니다. 한 번에 리뷰하기 적당한 크기의 diff로 끝나는 태스크는 깔끔하게 머지됩니다. 하지만 “인증 모듈 리팩토링”처럼 모호하고 거대한 태스크는 충돌을 부를 뿐입니다.
main 브랜치 앞에 머지 큐(merge queue)를 도입하라
머지 큐는 최신 main 브랜치 및 큐 앞단에 먼저 대기 중인 모든 변경 사항을 반영한 상태에서 각 풀 리퀘스트를 테스트한 후, 순서대로 머지합니다. GitHub의 머지 큐가 보호된 브랜치(protected branch)를 대상으로 이 역할을 수행합니다. 이는 Anthropic이 머지 후 테스트로 해결하는 방식을 소규모 팀 환경에 맞춘 것으로, 코드가 main에 반영된 뒤에야 결합 오류를 발견하는 불상사를 막아줍니다.
수행 근거와 함께 코드 리뷰를 태스크에 연계하라
diff 하나만으로는 에이전트가 어떤 요청을 받았는지, 어떤 항목을 검증했는지 리뷰어가 파악하기 어렵습니다. 요청 내용, 실행 로그, 테스트 결과, diff가 한곳에 모여 있을 때 리뷰 속도가 훨씬 빨라집니다. 자세한 내용은 태스크 수준의 근거를 바탕으로 AI 생성 코드를 리뷰하는 방법 및 병렬 개발 환경에서 인간의 리뷰가 병목이 되는 이유를 참고하세요.
에이전트가 승인을 거치도록 하라
조사, 코드 작성, 테스트, 결과 보고는 에이전트에게 맡기되 방향 설정, 위험한 단계 승인, 최종 결과물 수락은 사람이 담당해야 합니다. 머지 전 작업을 멈추고 사람의 확인을 기다리는 에이전트는 기껏해야 몇 분의 지연을 일으키지만, 검토되지 않은 코드를 main에 곧바로 머지하는 에이전트는 하루 전체를 날려버릴 수 있습니다. 에이전트의 제동 지점을 어디에 두어야 하는지는 코딩 에이전트를 위한 승인 게이트 설정 가이드에서 확인할 수 있습니다.
Sharkly의 역할
Sharkly는 Git을 대체하지 않으며, 머지 충돌을 대신 해결해주지도 않습니다. 에이전트는 여전히 기존 Git 호스트를 통해 저장소에 커밋합니다. Sharkly가 하는 일은 이러한 커밋을 둘러싼 일련의 작업 흐름을 체계적으로 조율하는 것입니다.
에이전트의 각 작업은 담당자(Assignee), 상태(status), 실행 기록(execution record)을 갖춘 하나의 태스크(Task)로 관리됩니다. 에이전트는 사용자가 이미 구독 중인 Claude Code, Codex 등의 런타임을 활용해 자체 컴퓨터(Computer)에서 실행됩니다. Temporary 모드에서는 각 태스크에 격리된 디렉터리가 할당되며, 저장소 기반 실행 시 별도의 워크트리를 준비하므로 동시에 실행되는 태스크들이 하나의 공유 폴더에 코드를 덮어쓰지 않습니다.
에이전트가 작업을 마치면 태스크를 사람의 리뷰 대기 상태로 둘 수 있습니다. 이 알림은 수신함(Inbox)에 표시되며, 담당자는 해당 태스크를 열어 전체 맥락 속에서 결과를 확인한 뒤 승인, 재시도, 재할당 여부를 결정합니다. 태스크 실행 내용과 이후의 논의 내역은 태스크 타임라인에 기록되므로, 작업 보드 자체가 그대로 리뷰 큐 역할을 하게 됩니다.
즉, 앞서 소개한 Git 활용 습관들에 더해 요청 사항, 실행 과정, 근거 자료, 최종 결정을 한곳에 모아 관리할 수 있는 단일 공유 공간을 제공하는 것입니다. 여러 솔루션을 비교 중이시라면 병렬 AI 코딩 에이전트 관리를 위한 최고의 도구 모음을 참고해보시기 바랍니다.
지금 당장 조치를 취해야 할 대상
매일 3대 이상의 에이전트를 가동하는 팀. 머지 병목이라는 장벽에 이미 가까워진 상태입니다. 이번 주 안으로 워크트리와 머지 큐를 도입하세요.
에이전트를 병렬로 가동하는 1인 개발자. 여러분의 병목은 머지가 아니라 리뷰입니다. diff 하나를 읽는 데 10분도 채 걸리지 않을 때까지 태스크의 크기를 줄이세요.
플랫폼 및 인프라 리드. CI 대기 시간과 PR 체류 시간을 주의 깊게 살펴보세요. Anthropic의 글에서도 소스 코드 관리와 CI가 다른 무엇보다 먼저 한계에 부딪혔다고 언급했듯, 여러분의 시스템도 같은 순서로 무너질 가능성이 큽니다. 격리된 워크트리를 활용한 병렬 에이전트 구성은 소중한 시간을 벌어줄 것입니다.
마치며
Anthropic Scion은 도입할 수 있는 제품이 아니라, 시대의 변화를 알리는 신호탄입니다. Anthropic의 머지 볼륨은 4개월 만에 12배나 증가했고, Git의 오프라인 우선 설계는 한계에 봉착했으며, 7명의 엔지니어가 에이전트 중심의 클라이언트를 위해 버전 관리 시스템을 밑바닥부터 새로 만들었습니다. 하지만 대다수의 팀에게는 이 정도 수준의 시스템까지는 필요하지 않습니다.
하지만 코딩 에이전트를 도입한 팀이라면 누구나 동일한 변화를 경험하게 됩니다. 코드를 작성하는 비용은 극적으로 저렴해지는 반면, 코드를 머지하고 리뷰하는 비용은 매우 비싸집니다. 각 태스크를 격리하고, 태스크 범위를 작게 유지하며, 머지를 큐에 등록하고, 명확한 근거를 바탕으로 리뷰하세요.
리뷰 과정을 한곳에서 깔끔하게 관리하고 싶다면, 먼저 컴퓨터 한 대를 Sharkly에 연결하고 에이전트를 하나 생성한 뒤, 위험 부담이 적은 작은 태스크를 하나 할당해 보세요. 결과가 어떻게 정리되어 들어오는지 직접 확인한 후 다음 단계를 결정하시면 됩니다.
자주 묻는 질문 (FAQ)
Anthropic Scion이란 무엇인가요?
Scion은 Anthropic이 자체 개발한 사내 버전 관리 시스템입니다. 2026년 회사의 모노레포에서 Git을 대체했습니다. 커밋, 머지, 리베이스를 서버에서 직접 수행하며, 클라이언트는 크기가 제한된 로컬 캐시만 유지합니다.
Anthropic은 왜 Git을 교체했나요?
코딩 에이전트 도입으로 일일 머지 건수가 2026년 5월 약 2,500건에서 9월 30,000건 이상으로 폭증했습니다. 이 엄청난 규모 앞에서는 Git 미러링, 체크아웃, CI가 속도를 감당하지 못했고, 결국 소스 코드 관리가 주된 병목이 되었기 때문입니다.
Scion은 오픈소스인가요? 외부에서도 사용할 수 있나요?
외부에 공개된 버전은 없습니다. Anthropic은 Scion이 일반적인 Git 대체재로 적합하지 않으며 다른 조직에 제공하기도 어렵다고 밝혔습니다. 다만 그 설계 아이디어를 기존 Git 환경에 적용해볼 수 있도록 아키텍처를 공유한 것입니다.
코딩 에이전트 간의 머지 충돌을 줄이려면 어떻게 해야 하나요?
태스크마다 독립된 워크트리를 부여하고, 태스크 범위를 한 번에 리뷰 가능한 diff 크기로 좁게 유지하며, 자주 머지하고, main 브랜치 앞에 머지 큐를 두세요. 충돌은 파일의 중복 수정 때문에 발생하는 것이므로, 에이전트의 수보다 작업 범위를 잘 설정하는 것이 핵심입니다.
소규모 팀도 새로운 버전 관리 시스템이 필요한가요?
거의 필요하지 않습니다. Anthropic이 겪은 문제는 100GB에 달하는 히스토리와 일일 2,500만 건의 체크아웃에서 비롯된 것입니다. 일반적인 규모라면 워크트리, 머지 큐, 태스크 단위 리뷰만으로도 작업 부하를 충분히 감당할 수 있습니다.
