Anthropic의 하루 머지가 5월 2,500건쯤에서 9월 3만 건 이상으로 늘면서 가장 큰 병목은 버전 관리, 곧 git이 됐어요. 일곱 명의 팀이 다섯 달 만에 모노레포를 git에서 자체 버전 관리 시스템 Scion으로 옮겼어요. 10월 13일 Anthropic 엔지니어링 블로그에 올라온 「Redesigning source control at Anthropic」은 ‘Anthropic에서 코드를 쓰는 일은 더 이상 시스템을 만들거나 연구하는 데 병목이 아니다’라는 문장으로 시작해요. 무엇을 바꿨는지 따라가 보고 Hacker News 댓글이 어떤 점을 걸고넘어졌는지, 우리 같은 작은 팀은 무엇을 가져다 쓸 수 있는지도 정리했어요.
코드를 쓰는 일이 병목에서 빠지자
원문에 따르면 Claude는 연구 루프를 혼자 돌리고 복잡한 프로그램을 세밀하게 최적화하며 새 서비스를 처음부터 만들어요. 그러자 병목은 사람의 속도에 맞춰 만든 개발 인프라로 옮겨 갔어요. 버전 관리, 빌드, CI예요. Anthropic은 코드 머지 수요가 ‘사실상 끝이 없다’고 봐요. 병목 하나를 걷어 낼 때마다 코드가 곧바로 더 늘어난다는 거예요.
git이 왜 버거웠는지는 모노레포의 크기에서 드러나요. main 브랜치의 히스토리만 100GB 가까이 되고 작업 트리는 압축해도 25GB가 넘어요. CI가 코드를 체크아웃하는 횟수만 하루 2,500만 번쯤이에요. 개발 환경, 에이전트 샌드박스, 연구 작업은 빼고 센 수예요. 이걸 git으로 곧이곧대로 받으면 하루 600PB가 넘는 트래픽이 된다고 해요.
물론 git에도 저장소의 일부만 다루는 도구가 있어요. 얕은 클론(shallow clone), 원하는 디렉터리만 펼치는 sparse checkout, 빠진 객체를 그때그때 받아 오는 promisor remote가 그래요. 큰 모노레포에서 흔히 쓰는 우회로도 있어요. 사내 git 미러를 두거나 저장소 스냅샷(seed)을 블롭 저장소에 넣어 두는 방법이에요. Anthropic도 이 도구와 우회로를 모두 썼어요. 가장 많을 때는 사내 git 미러를 수백 대 돌렸어요. 그래도 머지가 빨라질수록 스냅샷은 새로 만들 때까지 main의 최신 커밋보다 더 멀리 뒤처졌어요. 부분 클론에서 diff나 blame처럼 히스토리가 필요한 작업이 제대로 돌게 하는 데도 갈수록 손이 많이 갔어요.
늘 온라인인 클라이언트를 위한 버전 관리
git은 분산 시스템이에요. 클론 하나하나가 완전한 저장소라서 오프라인에서도 diff를 보고 히스토리와 blame을 읽고 아무 리비전이나 체크아웃할 수 있어요. 대부분의 저장소에는 이게 맞는 설계이고 git이 표준이 된 큰 이유이기도 해요. 그런데 돌아보니 Anthropic도 여느 회사처럼 git을 정본 하나를 둔 중앙 집중식으로 쓰고 있었어요. 클라이언트는 거의 다 늘 온라인일 수밖에 없는 에이전트와 작업이었어요. 오프라인 분산 작업에서 git을 빛나게 한 성질이 저장소가 커질수록 오히려 발목을 잡았어요.
에이전트가 늘 온라인이라는 사실을 처음부터 염두에 두고 버전 관리를 설계한다면 어떤 모습일까?
Anthropic, 「Redesigning source control at Anthropic」
거대한 모노레포를 위한 버전 관리에는 선례가 있어요. Google의 Piper와 Meta의 Sapling이에요. Anthropic은 특히 Sapling의 서버인 Mononoke와 그 데이터 모델(Bonsai)에서 기법을 많이 가져왔다고 밝혔어요. 그 위에 세운 원칙은 여섯 가지예요.
클라이언트는 늘 온라인이에요. 저장소 전체를 들고 다니지 않고 필요할 때 서버에서 받아 와요.
서버와 클라이언트가 비대칭이에요. 파일 기록과 blame 질의에 답하고 커밋 · 머지 · 리베이스를 만드는 일은 서버가 해요. 클라이언트는 크기가 정해진 로컬 캐시와 작업 트리, 파일 변경 감시만 맡아요.
버전 관리가 곧 API예요. 클라이언트가 쓰는 질의를 모두 API로도 열었어요. CI 작업은 로컬 저장소 없이 ‘이 줄을 마지막으로 누가 바꿨나’를 물어요. 자동 bisect와 자동 revert 파이프라인도 이 덕에 돌아가요.
모든 것을 수평으로 확장해요. 저장소 데이터는 흩어져 있고 서버에도 완전한 사본이 없어요. packfile(git이 객체를 압축해 묶은 파일)이 없으니 저장소 정비도 필요 없어요.
커밋은 싸고 잠금이 없어요. 커밋 비용은 저장소 크기와 상관없이 바뀐 양에만 비례해야 해요. 모든 서버가 합의해야 하는 전역 상태를 줄이려고 ref(브랜치 · 태그)도 main과 릴리스 브랜치 말고는 되도록 쓰지 않아요.
작업 트리는 필수가 아니에요. 있더라도 기본은 일부만 펼쳐요. diff 하나가 필요한 CI 작업은 체크아웃 없이 서버에 물어요. 파일이 필요해도 요청한 디렉터리만 받거나 읽는 순간에 파일을 채우는 방식이라 실제로 읽은 만큼만 받아요.
커밋 대신 체인지셋
Scion에서 일의 단위는 ‘체인지셋’이에요. 데이터베이스의 WAL(write-ahead log)처럼 차례로 쌓이는 기록의 한 항목이에요. git 커밋이 트리 전체를 가리킨다면 체인지셋은 첫 번째 부모와 비교해 바뀐 파일 목록과 그 파일 내용을 해시로 가리키는 주소만 담아요. 처리할 packfile도 잡을 잠금도 옮길 ref도 없어서 체인지셋을 아주 빠르게 받을 수 있어요. ref를 옮기는 일은 Spanner 행 하나에 대한 compare-and-swap으로 따로 해요. 바뀐 것만 적으니 ‘이 줄을 마지막으로 누가 바꿨나’ 같은 질문에는 바로 답하지 못해요. 그래서 blame · 경로 기록 · 커밋 그래프용 skip list 같은 ‘파생 데이터’를 체인지셋에서 만들어요. 파생 데이터는 모두 재귀로 정의해서 어떤 체인지셋의 값을 부모의 값에서 계산해요. 덕분에 세 가지가 쉬워졌다고 해요. 파생 데이터의 새 종류를 더하는 일, 종류마다 미리 계산할지 미룰지 고르는 일, 클라이언트를 건드리지 않고 최적화하는 일이에요.
git 커밋은 루트 트리를 가리키고 트리는 모든 파일로 이어져요.
그래서 커밋 하나만 있으면 그때의 저장소 전체를 다시 만들 수 있어요.
Scion의 체인지셋은 첫 번째 부모와 비교해 바뀐 파일만 적어요.
내용은 블롭 저장소에 있고 체인지셋은 그 주소만 들고 있어요. ref를 옮기는 일은 따로 해요.
‘이 줄을 누가 고쳤나’에 답하는 데이터는 따로 만들어요.
파생 데이터마다 부모의 값에 이번 변경을 더해 재귀로 계산해요.
가진 것을 알리지 않고 원하는 것을 묻는다
체크아웃 방식도 git과 달라요. git의 협상은 클라이언트가 이미 가진 것을 서버에 알리면 서버가 빠진 것을 계산해 packfile 하나로 묶어 보내는 식이에요. Scion의 클라이언트 scn은 원하는 것만 물어요. 루트 트리에서 시작해 로컬에 없는 트리를 차례로 요청하고 같은 식으로 블롭을 받아요. 요청마다 결코 바뀌지 않는 객체 하나를 가리키니 어느 캐시든 답할 수 있어요. 노드마다 scion-daemon이 객체를 모아 둬요. 지역마다 있는 scion-cache는 객체를 메모리에서 바로 내보내요. 그래도 없으면 scion-server가 Spanner나 클라우드 저장소에서 읽어요. 세 계층이 같은 RPC에 답하지만 한 지역 캐시의 장애가 서버까지 번지지 않도록 계층을 건너뛰지 못하게 막아 뒀어요.
원문이 내세운 결과는 이래요. 계층마다 캐시 적중률이 99%를 넘고 오래 유지해야 하는 상태가 없어서 늘리기 쉬워요. CPU와 메모리로 따지면 인프라 규모가 예전 git 미러의 200분의 1로 줄었어요. CI와 연구 작업의 체크아웃은 100배쯤 빨라져 분 단위에서 초 단위가 됐어요. CI에서만 CPU 용량 25%를 되찾았다고 해요.
일곱 명, 다섯 달
Scion과 코드 리뷰 도구 Antique를 만든 팀은 일곱 명이었어요. 관련 시스템 여섯 개쯤을 더 만들고 이전까지 마치는 데 다섯 달이 걸렸어요. 그사이 하루 머지 양은 10배로 늘었어요. 원문이 꼽은 장면이 하나 있어요. git에서 Scion으로 데이터를 옮기는 파이프라인의 첫 판은 사람이 거의 손으로 짰고 팀은 잘 만들었다고 생각했어요. Claude Mythos Preview의 사내 초기 버전에게 전부 다시 써 보라고 하자 다른 지시 없이도 메모리는 20분의 1만 쓰고 속도는 4배인 판이 나왔어요. 데이터를 받아들이는 순서와 데이터 구조에 걸린 암묵적인 조건도 그대로 지켰다고 해요.
그렇다고 엔지니어의 일이 사라진 건 아니에요. 원문에 따르면 이 시스템을 만든 엔지니어 모두가 이제 코드 작성은 Claude가 자기보다 낫다고 평가해요. 대신 사람은 시스템과 시스템이 어떻게 맞물리는지에 대한 큰 그림과 설계상의 득실 판단을 보탰어요. 에이전트는 애초에 허용되지 말았어야 할 패턴에 맞추려고 핵심 제약을 어기기도 했어요. 머지 시각을 코드 리뷰 도구에 묻지 않고 커밋 로그를 처음부터 읽어 찾으려던 시스템이 여럿 있었어요. 적대적 리뷰가 다른 사내 서비스를 지나치게 의심하는 바람에 Claude가 쓸데없는 검증을 덧붙여 코드를 복잡하게 만든 일도 있었어요. 팀은 지금도 모든 변경을 리뷰하지만 한 줄씩 읽기보다 변경의 의도를 봐요.
엔지니어의 역할은 Claude에게 ‘안 돼’라고 말하는 것일 때가 아주 많았다.
Anthropic, 「Redesigning source control at Anthropic」
사람 속도에 맞춘 다른 관행도 다시 보게 됐다고 해요. 테스트가 도는 동안 변경이 수백, 수천 개씩 머지되는 곳에서 CI는 무슨 뜻이냐는 질문이에요. 머지 큐에 저장소 전역 잠금을 거는 업계 표준은 이 규모에서 그대로 따를 수 없었어요. 대신 머지 뒤 · 배포 전 테스트에 투자했어요. 동시에 들어온 변경끼리 충돌할 수는 있지만 사람이 알아채기도 전에 Claude가 대개 고친다고 해요. 구성 요소마다 그것 하나만 지켜보는 Claude를 Slack 채널에 두고 ‘슈퍼팬’이라고 부른다는 대목도 있어요.
댓글 1,012개가 걸고넘어진 곳
Hacker News에서 이 글은 894점을 받았고 댓글이 1,012개 달렸어요. 답글이 가장 많이 달린 스레드(199개)는 Scion이 아니라 리뷰 이야기였어요. 첫 댓글은 ‘Claude의 코드를 리뷰하지 않고 넘어갈 때마다 나중에 꼭 엉성한 코드가 나온다’며 이 속도로 그걸 어떻게 피하느냐고 물었어요. 다른 댓글은 하루 3만 건을 의도만 보고 리뷰한다면 모델이 지름길을 택한 걸 코드를 읽지 않고 어떻게 알아채느냐고 되물었어요.
모노레포부터 의심했어야 하지 않느냐는 댓글도 있었어요. ‘모노레포로 하면 머지가 쉬워진다’에서 ‘머지가 너무 어려우니 버전 관리를 다시 설계하자’로 넘어가는 사이에 ‘정말 모노레포여야 하나’라는 중간 질문을 건너뛰었다는 지적이에요. 선례를 꼽는 사람도 많았어요. SVN이나 Perforce 같은 서버 중심 버전 관리를 요즘 식으로 다시 만든 것이라는 평이 있었어요. Oracle과 Google을 거친 한 개발자는 Oracle의 사내 버전 관리 프로젝트 책임자가 자기 이름을 붙여 부르던 ‘법칙’을 떠올렸어요. 큰 회사는 언젠가 모두 자기 버전 관리 시스템을 만든다는 거예요. East River Source Control의 Steve Klabnik은 자기 회사가 옳았다는 증거라며 반겼어요. 큰 팀과 에이전트가 함께 일하는 모노레포는 결국 git의 한계에 다다른다는 거예요. Google과 Meta는 10년도 더 전에 그 벽에 부딪혔고 이제는 많은 회사가 같은 일을 겪고 있다고 했어요.
Anthropic 스스로도 선을 그었어요. 원문은 ‘Scion은 결코 범용 git 대체물이 아니다’라고 적었어요. 이 방식은 엔지니어가 수만 명이거나 에이전트 무리가 코드를 쏟아 내는 거대한 모노레포에서만 말이 된다고 해요. Anthropic이 내부에서 쓰는 토큰의 양도 다른 회사가 현실적으로 쓰려 할 수준을 훨씬 넘는다고 했어요. 한 댓글은 다들 따라 해야 한다며 조바심 내다가 자기가 Anthropic이나 Google이 아님을 깨닫는 ‘보기 흉한 시기’가 올 거라고 내다봤어요.
작은 팀이 가져다 쓸 것
Scion이 필요한 팀은 거의 없어요. Anthropic도 앞으로 6~12개월 사이에 이런 문제가 흔해질 거라고 봐요. 그래도 권하는 길은 git의 큰 틀을 지키면서 Scion에서 잘된 부분만 git에 들여오는 쪽이에요. git에는 이미 그런 조각이 있어요. 필요한 객체만 나중에 받는 부분 클론, 원하는 디렉터리만 펼치는 sparse checkout, 백그라운드에서 저장소를 정비하는 git maintenance예요. Git 2.38부터는 Microsoft가 만든 scalar가 기본으로 들어 있어서 이 설정을 한 번에 켜 줘요. 이 블로그에서 AI 수학 원고 글을 쓸 때도 원고 저장소를 블롭 없이 받아 필요한 파일만 열었어요. 대가도 있어요. GitHub의 Derrick Stolee는 블롭 없이 받은 클론에서 git diff나 git blame을 처음 돌리면 그때 파일 내용을 내려받는다고 설명했어요. git 문서에는 더 근본적인 조건이 적혀 있어요. 부분 클론을 쓰려면 사용자가 온라인이어야 한다는 거예요. ‘클라이언트는 늘 온라인’이라는 Scion의 첫 원칙이 git 안에도 이미 조금 들어와 있는 셈이에요.
# 블롭(파일 내용) 없이 받고 작업 트리에는 최상위 파일만 펼친다
git clone --filter=blob:none --sparse https://example.com/big/monorepo.git
cd monorepo
git sparse-checkout set apps/web lib # 필요한 디렉터리만 펼친다
git maintenance start # 백그라운드 정비
git config core.fsmonitor true # macOS · Windows 파일 감시
# 위 설정을 한 번에(작업 트리는 monorepo/src)
scalar clone https://example.com/big/monorepo.gitAnthropic이 git 생태계에 건넨 제안도 같은 쪽을 가리켜요. git 서버가 git 클라이언트와 똑같이 동작할 필요는 없다는 거예요. GitHub · GitLab 같은 호스팅 서비스가 Scion처럼 풍부한 서버 쪽 RPC를 열고 그 모양을 서로 맞추면 git 클라이언트도 그 RPC를 쓰도록 바뀔 수 있어요. 협상 프로토콜도 지금 모양 그대로일 필요가 없고 sparse와 shallow 기능이 서로 잘 맞물리게 다듬을 수 있다고 했어요.
코드를 쓰는 비용이 내려가자 그 코드를 받아들이는 인프라와 리뷰, ‘안 돼’라고 말하는 판단이 비싸졌어요. 하루 3만 건은 남의 이야기지만 같은 흐름이 작은 팀에도 밀려와요. 에이전트가 PR을 늘릴수록 CI는 더 자주 돌고 리뷰는 더 쌓여요. 무엇을 서버에 묻고 무엇을 사람이 볼지 미리 정해 두는 편이 git을 떠나는 것보다 훨씬 싸요.