앤스로픽이 깃을 버린 이유: 병합 2,500건→3만 건

effidev·2026년 10월 14일

AI에게 코드를 맡기는 속도가 어느 선을 넘으면 막히는 곳은 모델이 아니라 코드를 합치는 창구가 된다. 앤스로픽이 2026년 10월 13일 공식 엔지니어링 블로그에서 자기들이 그 지점을 넘은 순간을 숫자로 공개했다.

5월에 하루 평균 약 2,500건이던 병합이 9월에는 하루 3만 건을 넘었다고 한다. 병합은 개발자가 따로 고친 코드를 본 줄기에 합치는 일이다. 앤스로픽은 이 속도를 깃(Git)이 감당하지 못해, 자체 개발한 Scion(사이언) 으로 갈아탔고 일곱 명이 5개월 만에 전부 옮겼다고 적었다.

숫자에는 단서가 둘 있다. 같은 글의 그래프에서 3만 건을 넘은 막대는 9월 9일 하루(30,401건)뿐이고, 7일 평균선은 끝에서 1만 8천 근처로 읽힌다. 그리고 Scion은 공개할 계획이 없다.

이 글은 깃·모노레포·체크아웃 같은 말을 처음 듣는 사람에게 맞췄다. “우리도 깃을 버려야 하나”를 묻는 글이 아니다. AI 에이전트가 늘면 깃의 어느 부분이 가장 먼저 느려지는지, 그리고 그 느려짐을 우리 규모에서 어떻게 확인하는지를 다룬다.

본 자료는 앤스로픽 엔지니어링 블로그 원문 Redesigning source control at Anthropic과 그 안의 그래프 5장, 해커뉴스 스레드(10월 14일 오전 기준 443점·댓글 442개)다. 글 속 성능 숫자는 전부 앤스로픽이 직접 잰 값이고 이 사이트가 Scion을 써 본 적은 없다. 대신 깃 쪽 숫자 두 가지는 우리 맥에서 직접 쟀다. 글 끝에는 원문에 없어서 확인하지 못한 것을 따로 모았다.

이 글에 나오는 말 여섯 개

이 여섯 개만 알면 나머지는 글에서 풀어 쓴다.

하루 병합이 5월 2,500건에서 9월 3만 건이 됐다

원문의 첫 문단은 이렇다. 코딩은 더 이상 시스템을 만드는 병목이 아니고, 병목은 사람 규모에 맞춰 만든 개발 인프라, 곧 소스 컨트롤(코드 기록 관리)·빌드·CI라는 것이다.

숫자로는 5월 평균 하루 약 2,500건에서 9월에 하루 3만 건 넘게다. 원문 요약은 “10배 넘게 늘었다”고 쓴다.

그래프를 보면 결이 다르다. 1월부터 5월까지는 파란 막대(풀 리퀘스트, 사람이 쓰던 검토 요청)가 하루 1천 건 안팎에서 3천 건 가까이로 천천히 오른다. 6월부터 주황 막대(Antique 변경 요청, 앤스로픽이 자체 개발한 코드 리뷰 도구)가 파랑을 밀어내고, 7월 말에는 ‘Quiet week’ 표시 아래로 막대가 1천 건 안팎까지 푹 꺼졌다가 8월에 다시 치솟는다.

3만을 넘는 막대는 9월 9일 하루뿐이다. 본문의 “하루 3만 건 넘게”는 그날을 가리키는 것으로 보인다. 7일 평균선은 그래프 끝에서 눈대중으로 1만 8천 근처이고, 이 값도 5월 평균의 7배쯤이다.

이 사이트는 병합 건수 자체가 늘어난 것은 맞다고 본다. 다만 제목에서 쓴 “3만 건”은 앤스로픽이 쓴 표현이고, 평균이 아니라 가장 높은 날이다.

깃이 막힌 곳: 저장소 100GB, 하루 체크아웃 2,500만 번

앤스로픽의 모노레포는 크다. 원문 숫자는 이렇다.

• main 줄기의 변경 기록만 100GB에 가깝다
• 압축한 작업 폴더가 25GB가 넘는다
• CI 하나만 세어도 하루 2,500만 번 체크아웃한다(개발자 환경·에이전트 샌드박스·연구 작업은 별도)

여기서 원문은 “순진하게 받으면 하루 깃 트래픽이 600PB가 넘는다“고 쓴다. 이 숫자는 실제로 흐른 양이 아니다. 해커뉴스에서 한 사용자가 바로 짚었고, 직접 곱해도 같다. 2,500만 번에 25GB를 곱하면 625PB다. 체크아웃할 때마다 통째로 받는다고 가정한 값이다.

깃에도 이런 상황을 줄이는 도구가 있다. 원문이 이름을 든 것은 얕은 복제(shallow clone, 최근 기록만 받기), 희소 체크아웃(sparse checkout, 필요한 폴더만 꺼내기), 부분 복제(promisor remote, 내용은 필요할 때 받기)다. 앤스로픽도 전부 써 봤다. 거기에 내부 깃 미러(복사본 서버)를 피크에는 수백 대 운영했고, 변경 기록이 필요한 작업(diff, blame)은 부분 복제 위에서 점점 다루기 어려워졌다고 적었다.

같은 저장소를 세 방식으로 받아 봤다

원문이 말한 “부분 복제 위에서는 기록을 묻는 일이 어렵다”를 작은 저장소로 확인했다. 아스트로(Astro) 저장소(커밋 15,249개, 파일 6,978개)를 맥 한 대에서 한 번씩 받았다. 2026년 10월 14일 오전, 네트워크 상태에 따라 달라질 수 있는 1회 측정이다.

얕은 복제는 시간이 6분의 1이고 기록 폴더는 11분의 1이다. 앤스로픽의 main 기록(약 100GB)은 이 저장소 기록(251MB)의 400배쯤이다.

문제는 그 다음이다. 파일 하나(packages/astro/src/core/build/index.ts)에 git blame(줄마다 누가 언제 고쳤는지 묻기)을 걸었다.

부분 복제는 처음 한 번만 102.8초를 썼다. 필요한 파일 내용을 그때그때 서버에서 받아 오기 때문이다. 얕은 복제는 빠르지만 기록이 1개뿐이라 “누가 고쳤나”에 답하지 못한다. 원문이 말한 “싸게 받는 방법은 기록을 묻는 일에서 무너진다”가 작은 저장소에서도 이렇게 나온다.

Scion의 출발점: 에이전트는 항상 온라인이다

원문의 출발점은 단순하다. 깃은 “인터넷이 끊겨도 일할 수 있는” 도구라서 컴퓨터마다 전체 사본을 가진다. 그런데 앤스로픽의 사용자는 거의 다 에이전트와 자동 작업이고, 이들은 정의상 항상 인터넷에 붙어 있다. 오프라인을 위한 설계가 규모를 막고 있다는 진단이다.

그래서 Scion은 깃과 반대로 다섯 가지를 골랐다.

이 설계의 부수 효과가 크다. 서버가 “이 줄을 마지막에 고친 사람은?”, “두 커밋의 공통 조상은?” 같은 질문에 API로 답하기 때문에, CI 작업은 저장소 사본 없이 서버에 묻기만 해도 된다. 자동 이분 탐색(어느 변경이 문제인지 찾기)과 자동 되돌리기 도구가 이 값싼 조회 덕에 가능했다고 원문은 쓴다.

변경 하나가 저장되는 모양: 체인지셋

깃의 커밋은 “이 시점의 전체 파일 목록(트리)“을 가리킨다. Scion의 기본 단위인 체인지셋(changeset) 은 다르다. 첫 부모와 비교해 바뀐 파일 목록과, 그 파일 내용이 저장된 주소(내용으로 만든 고유 번호)를 담는다. 쓰기 기록(write-ahead log)의 한 줄에 가깝다.

원문 그림에서는 메타데이터(작성자·날짜·메시지·부모·바뀐 파일 목록)가 스패너(Spanner)에, 파일 내용은 클라우드 스토리지에 따로 저장된다. 서버가 계산해야 하는 전체 트리 같은 값은 체인지셋에 넣지 않는다.

이렇게 하면 받아들이는 속도가 빨라진다. 팩 파일(깃이 묶음으로 압축한 파일)도, 잠금도, 서버끼리의 조율도, 옮겨야 할 브랜치 포인터도 없기 때문이다. 포인터를 옮기는 일이 필요할 때도 스패너 한 줄에 대한 비교-교체 하나로 끝난다.

“이 줄은 누가 고쳤나” 같은 질문은 체인지셋만으로는 못 푼다. 그래서 서버는 파생 데이터(blame용 구조, 파일 경로별 이력, 커밋 그래프의 건너뛰기 목록 등)를 따로 만든다. 모든 파생 데이터는 “부모의 값에서 나의 값을 계산한다”는 하나의 방식으로 정의돼서, 새 구조를 추가해도 클라이언트를 고칠 필요가 없고 계산을 미룰 수도 있다. 앤스로픽은 복사 탐지나 경로 검색 같은 구조를 운영 중에 여러 번 더했다고 한다.

요청이 지나가는 길: 서버, 캐시, 데몬

원문이 그린 체크아웃 구조는 세 층이다.

클라이언트 scn은 “내가 가진 것”을 서버에 말하지 않는다. 루트 트리부터 내려가며 자기에게 없는 트리와 블롭만 요청한다. 요청 대상이 모두 바뀌지 않는 데이터라 어느 캐시든 답할 수 있고, 거대한 팩 파일 하나를 받는 방식이 아니라서 이어받기도 된다. 희소·가상 체크아웃에 특별한 기능이 필요 없는 이유도 같다. 원하지 않는 트리를 그냥 요청하지 않으면 된다.

세 층은 같은 RPC를 쓰지만, 실제로는 층을 건너뛰지 못하게 강제한다. 지역 캐시 하나가 죽어도 정본 서버가 같이 죽지 않게 하려는 것이다.

원문이 밝힌 결과는 이렇다.

• 각 층의 캐시 적중률이 99%를 넘는다
• Scion 인프라는 이전 깃 미러 인프라보다 CPU·메모리 기준 200배 작다
• CI 하나만으로 CPU 용량의 25% 를 되찾았다

명령 열세 개를 재 보면: 가장 큰 폭과 거의 없는 폭

원문 마지막 그래프는 자주 쓰는 명령을 깃과 scn으로 나란히 잰 중앙값이다. 그래프의 숫자를 그대로 표로 옮겼다.

읽을 곳이 둘이다. 첫째, 가장 큰 폭은 새 작업 폴더(에이전트 환경, 7.1분이 5.1초)와 상태 확인(개발자 환경, ×207)이다. 에이전트가 일을 시작할 때마다 7분을 기다렸다면 그만큼의 사람 몫 비용이다.

둘째, 개발자 환경의 커밋은 1.4초가 1.1초로 거의 줄지 않았다. 원문은 이유를 밝히지 않았다. 이 사이트의 추정으로는 Scion에서 커밋이 서버 왕복으로 처리되기 때문이다. 확인한 사실이 아니라 추정이다.

그래프 옆에는 “하루 약 1만 1천 에이전트 시간”, “하루 약 8만 5천 머신 시간”, “하루 약 19만 5천 머신 시간”이라는 값도 적혀 있다. 무슨 시간인지는 풀어 쓰지 않았다. 하루 2,500만 번 체크아웃에 한 번당 줄어든 27.5초를 곱하면 약 19만 1천 시간이라 그래프 값과 거의 맞는다. 절약된 시간으로 읽는 게 맞아 보인다.

글 안의 숫자 두 개가 어긋난다

본문은 이렇게 쓴다. “CI와 연구 작업이 코드를 자릿수 두 개(two orders of magnitude) 만큼 빨리 체크아웃한다. 분이 아니라 초 단위로.” 영어 표현 ’two orders of magnitude’는 보통 100배를 뜻한다.

같은 글의 그래프에서 CI 작업 체크아웃의 중앙값은 31초에서 3.5초(×8.8), 연산 작업 시작 체크아웃은 175초에서 22초(×8.0)다. 100배에 가까운 건 에이전트 환경의 새 작업 폴더(×84)뿐이다.

둘 다 맞을 수는 있다. 본문은 평균이나 가장 큰 작업을, 그래프는 중앙값을 말하고 있을 수 있다. 그런데 글이 어느 쪽인지 밝히지 않았다. 이 글은 표에 그래프 값을 쓰고 “100배”라는 본문 문장은 근거를 확인하지 못한 값으로 남긴다.

일곱 명이 5개월: 클로드가 한 일과 사람이 한 일

원문에 따르면 일곱 명이 Scion과 코드 리뷰 도구 Antique, 그 밖의 관련 시스템 여섯 개 안팎을 5개월 안에 만들고 모노레포를 옮겼다. 그동안에도 하루 병합량은 늘었다. 그래프에는 Scion·Antique 코드가 있는 두 디렉터리에 1월부터 12,257건의 변경이 쌓였다고 적혀 있다.

가장 눈에 띄는 일화는 이전 파이프라인이다. 깃의 기록을 Scion으로 옮기는 첫 도구를 사람이 직접 짰는데, 내부 시험판 Claude Mythos Preview에게 아무 지시 없이 다시 쓰게 했더니 메모리를 20배 덜 쓰고 4배 빠른 버전이 나왔다고 한다. 이 수치는 앤스로픽 자체 측정이다. 해커뉴스에서는 “한 번 옮기고 마는 도구 아니냐”는 반박도 달렸다.

사람의 일은 원문 표현으로 “클로드에게 ’아니오’라고 말하는 것”이었다.

• 여러 시스템이 “언제 main에 합쳐졌나”를 코드 리뷰 도구에 묻지 않고 커밋 기록을 처음부터 읽어 찾으려 했다
• 서로의 작업을 비판하게 하는 ’적대적 검토’가 다른 내부 서비스를 믿지 않는 쪽으로 지나치게 방어적이어서, 클로드가 검증 코드와 복잡성을 과하게 덧붙였다

팀은 이 시스템의 모든 변경 요청을 지금도 검토하지만 한 줄씩 읽는 대신 변경의 의도를 본다. 원문은 Scion이 자기들이 다뤄 본 코드베이스 중 가장 잘 시험되고 잘 방어된 축에 든다고 적었다. 인프라와 소스 컨트롤의 상호작용 전부를 흉내 내는 시험 환경, 퍼징, 속도 제한을 짧은 일정 안에 갖췄다는 설명이다. 구성 요소마다 클로드 하나를 붙여 지표를 계속 보게 하는 ’슈퍼팬’도 운영한다.

병합 대기열을 없앤 대가

병합 대기열(merge queue)은 변경을 줄 세워 한 번에 하나씩 합치고, 합치기 전에 시험하는 장치다. 앤스로픽은 이 전역 잠금을 에이전트 규모에서는 재현하지 못했다고 쓴다. 수백~수천 건이 시험이 도는 동안 합쳐지기 때문이다.

대신 합친 뒤와 배포 직전 자동 시험에 투자했다. 그래서 동시에 올라온 변경끼리 충돌할 수 있다. 원문은 “클로드가 사람이 알아보기도 전에 충돌을 고친다”고 쓴다. 합치기 전 안전장치를 합친 뒤 시험으로 바꿨다는 뜻이다. 얼마나 자주 깨지는지, 되돌림 비율이 얼마인지는 쓰지 않았다.

공개하지 않는다: Scion은 깃의 대체품이 아니다

원문 결론은 의외로 낮은 목소리다. “Scion은 일반적인 용도로 깃을 대체할 시스템이 결코 아니다.” 이유를 셋 들었다.

• 이 개념은 수만 명의 엔지니어나 코드를 쏟아내는 에이전트 떼가 있는 거대한 모노레포에서만 의미가 있다
• 깃과 크게 달라서 코드 리뷰·검색·CI까지 전부 새로 만들어야 하고, 앤스로픽의 내부 구현은 너무 맞춤형이다
• 앤스로픽은 내부 용도로 쓰는 토큰이 다른 어떤 회사도 쓰지 않을 만큼 많다

그래서 제품으로 내놓는 대신 아이디어를 공유한다. 깃 서버가 깃 클라이언트와 같은 방식일 필요는 없고, 깃 플랫폼이 Scion처럼 서버 쪽 RPC를 제공하거나 협상 프로토콜을 바꾸거나 희소·얕은 복제를 매끄럽게 합치면 깃을 떠나지 않고도 이득을 얻을 수 있다는 제안이다. 깃허브·깃랩·오픈소스 커뮤니티와 협력하겠다는 말로 글을 맺는다.

앞서 이 사이트가 다룬 코딩 에이전트 7종이 폴더만 열어도 뚫린 사건에서도 에이전트와 깃의 접점이 어떤 구멍을 만드는지 봤다. 에이전트가 깃을 쓰는 방식은 속도만이 아니라 보안에서도 설계가 따라가야 한다.

해커뉴스에서 갈린 네 가지 질문

스레드는 방대했고 질문이 네 갈래로 모였다.

① 그렇게 바뀌면 소스 컨트롤이 왜 필요한가. 한 사용자가 코드가 계속 흘러가는데 기록을 둘 이유가 있느냐고 물었다. 답글은 “에이전트도 기록을 읽는다. 에이전트가 같은 변경을 되풀이하는 고리에 빠지는 걸 막는 데 기록이 필요하다”였다.

② 그 많은 코드는 어디에 쓰이나. “병합이 하루 3만 건인데 앤스로픽 웹사이트와 CLI는 그대로 같아 보인다”, “커밋 건수는 코드 줄 수만큼 좋은 지표가 아니다”라는 댓글이 달렸다. 병합 한 건의 크기를 원문이 밝히지 않아 이 반박에는 답이 없다.

③ 사람은 무슨 일을 하나, 검토 없이 나가나. 원문의 “모든 변경 요청을 팀이 검토한다”는 문장이 이 질문에 대한 답이다. 다만 이 문장은 소스 컨트롤 시스템 변경에 한정된 것이다. 앤스로픽 전체 코드의 검토 방식은 글에 없다.

④ 설계에 대한 반발. “로컬에서 작은 커밋을 쌓고 다듬은 뒤 올리는 게 깃의 핵심인데 온라인 전용은 거부한다”, “서브버전·퍼포스 시절로 돌아간 것 아니냐”는 의견이 나왔다. 필자 이름(‘Nick G.’)과 같은 이름의 계정(nickg-anthropic, 본인인지는 확인하지 못했다)이 “바로 올려 두면 연구 작업·CI·여러 개발 환경에서 같은 커밋 번호가 그대로 통한다”고 답했다.

우리 팀 규모에서 지금 확인할 수 있는 것

원문이 말하듯 대부분의 팀에 Scion은 필요 없다. 그래도 에이전트를 돌리는 팀이면 확인해 볼 만한 것이 세 가지다.

1. CI에서 체크아웃이 차지하는 시간. 작업 로그에서 git clone·fetch가 몇 초인지 본다. 이 사이트의 측정에서 얕은 복제(--depth 1)는 전체 복제보다 6배 빨랐다.
2. 얕은·부분 복제의 부작용. 기록을 묻는 도구(blame, 변경 이력 분석, 자동 되돌리기)를 같은 CI에서 쓰는지 확인한다. 부분 복제에서 git blame 처음 한 번이 102.8초였다.
3. 에이전트 작업 폴더 만드는 시간. 에이전트마다 새 폴더가 필요하면 git worktree(저장소 하나에서 작업 폴더를 여러 개 펼치기) 시간을 재 본다. 앤스로픽의 모노레포는 7.1분이었지만 작은 저장소는 초 단위일 것이다.

원문이 제시한 규모 기준은 “수만 명의 엔지니어나 에이전트 떼”다. 우리 팀 저장소의 하루 병합 수와 기록 크기가 그 근처가 아니라면, 깃을 바꾸기 전에 위 세 가지가 먼저다.

같은 앤스로픽 모델을 코딩 에이전트로 쓰는 팀이라면 클로드 오퍼스 5.5 출시 글과 클로드 코드 팀 워크플로 글도 같이 볼 만하다.

빈칸으로 남은 것들: 비용, 품질 지표, 외부 검증

• 비용. Scion 인프라가 CPU·메모리로 200배 작아졌다고만 있고, 스패너·스토리지·개발 인력 비용은 없다.
• 병합 한 건의 크기. 하루 3만 건이 몇 줄짜리 변경인지, 에이전트가 쪼갠 작은 변경이 얼마나 되는지 알 수 없다.
• 품질 지표. 되돌림 비율, 병합 후 장애 건수, 대기열을 없앤 뒤 깨진 횟수는 없다.
• 중앙값 밖의 값. 그래프는 중앙값만 쓴다. 꼬리(가장 느린 요청)나 실패율은 없다.
• 본문 “자릿수 두 개”의 근거. 앞서 짚은 대로 그래프의 CI 값과 맞지 않는다.
• 공개 계획과 외부 검증. 코드도 문서도 없고, 앤스로픽 밖에서 재 본 사람이 없다.

원문 자체가 “다른 조직이 그대로 쓸 수 있는 해법은 아니다”라고 말한다. 이 글도 같은 위치에서 끝낸다. 앤스로픽의 숫자는 에이전트가 코드를 얼마나 빨리 쌓을 수 있는지를 보여 주는 한 회사의 실측이고, 우리에게 필요한 일은 내 저장소에서 어디가 먼저 느려지는지 재 보는 것이다.