하루 3만 건의 머지 — Anthropic이 git을 버린 이유와 그 설계의 계보
하루 3만 건의 머지 — Anthropic이 git을 버린 이유와 그 설계의 계보
에이전트가 커밋하는 시대의 소스 관리는 새로운 발명인가, 아니면 거대 모노레포가 이미 걸었던 길을 다시 걷는 것인가?
도입
2026년 10월 13일, Anthropic 엔지니어링 블로그에 「Redesigning source control at Anthropic」이라는 글이 올라왔다. 해커뉴스에서는 892점, 댓글 1,010개를 모았다. 글의 첫 문단은 문제를 이렇게 요약한다. 하루 머지 건수가 열 배 넘게 늘면서 소스 관리가 개발의 가장 큰 병목이 되었고, 그래서 다섯 달 만에 사내 버전 관리 시스템으로 이전했다는 것이다.
숫자부터 옮겨 두자. 글에 따르면 Anthropic의 모노레포에는 2026년 5월에 하루 평균 약 2,500건의 변경이 머지되었는데, 9월에는 하루 3만 건을 넘었다. 메인 브랜치의 히스토리만 100GB에 가깝고, 압축된 작업 사본은 25GB를 넘는다. CI만으로 하루 2,500만 회 정도의 체크아웃이 일어나며, 이것을 단순하게 git으로 받으면 하루 600PB가 넘는 트래픽이 된다고 한다. 이 상황에 대한 답으로 만든 것이 Scion이라는 자체 버전 관리 시스템이고, 7명의 팀이 Scion과 코드 리뷰 도구 Antique를 만들고 이전까지 끝냈다는 것이 글의 골자다.
이 글이 흥미로운 이유는 두 겹이다. 하나는 「코드를 쓰는 주체가 사람에서 에이전트로 바뀌면 개발 인프라의 어떤 전제가 깨지는가」라는 질문에 대한 구체적인 사례라는 점이다. 다른 하나는, 바로 다음 날 Meta의 Mononoke 개발에 참여했던 엔지니어가 「Scion은 Mononoke에서 강하게 영감을 받았다」는 글을 올리면서 설계의 계보와 출처 표기 문제가 함께 불거졌다는 점이다. 이 글은 두 가지를 순서대로 다룬다.
git의 어떤 전제가 깨졌는가
Anthropic의 진단은 git의 결함을 지적하는 것이 아니라 git의 설계 전제가 자기들의 작업 부하와 맞지 않는다는 쪽이다. 글은 git이 분산 시스템이라는 점에서 출발한다. 모든 클론은 그 자체로 완결된 저장소이고, 오프라인에서도 diff를 계산하고 히스토리와 blame을 읽고 어떤 리비전이든 체크아웃할 수 있다. 글은 대다수 저장소에는 이것이 옳은 설계이며 git이 표준이 된 큰 이유라고 인정한다.
문제는 그 다음이다. 대부분의 회사처럼 Anthropic도 git을 사실상 권위 있는 사본 하나를 둔 중앙집중형으로 쓰고 있었고, 클라이언트 대부분은 정의상 늘 온라인인 에이전트와 잡(job)이었다. 오프라인 분산 작업을 위한 git의 장점이 저장소가 커질수록 확장을 방해하는 쪽으로 작용했다는 것이 글의 표현이다. 그래서 던진 질문이 「에이전트가 항상 온라인이라는 사실을 처음부터 전제로 소스 관리를 설계하면 어떤 모양이 되는가」였다.
그 전에 시도한 것들도 글에 나온다. 얕은 클론, 희소 체크아웃, promisor remote 같은 git의 부분 저장소 기능, 그리고 사내 git 미러와 blob 스토리지에 둔 저장소 스냅샷(seed) 같은 대형 모노레포의 표준적인 우회책을 전부 썼다. 정점에서는 사내 git 미러를 수백 대 운영했다. 시간은 벌었지만 머지 속도가 오를수록 운영이 어려워졌다. seed는 갱신 사이에 메인 브랜치 끝에서 점점 멀어졌고, diff나 blame처럼 히스토리에 의존하는 작업을 부분 클론 위에서 유지하는 데 점점 더 많은 손이 갔다.
여기서 에이전트가 바꾼 것을 정리해 보면 세 가지로 보인다. 아래는 글의 사실을 바탕으로 한 필자의 해석이다.
첫째, 클라이언트의 성격이다. 사람 개발자는 노트북을 들고 비행기를 타지만, CI 잡과 에이전트 샌드박스는 네트워크 없이 존재하지 않는다. 오프라인 작업이라는 git의 핵심 가치를 누리는 클라이언트가 전체에서 소수가 되면, 모든 클라이언트에 완전한 사본을 요구하는 비용만 남는다.
둘째, 체크아웃의 빈도다. 사람의 체크아웃은 하루 몇 번이지만, 에이전트와 CI는 짧게 살고 죽는 환경에서 매번 코드를 받는다. 글이 제시한 하루 2,500만 회는 개발 환경, 에이전트 샌드박스, 연구 잡을 세기 전의 CI만의 수치다. 체크아웃 한 번의 비용이 저장소 크기에 비례하는 한, 이 곱셈은 감당할 수 없다.
셋째, 머지의 동시성이다. 글은 머지 큐의 전역 저장소 잠금이라는 업계 표준을 효과적으로 재현할 수 없었다고 쓴다. 테스트가 도는 동안 수백, 수천 건의 변경이 머지될 수 있는 상황에서 CI가 무엇을 의미하는지 되묻는다. 결국 머지 후, 배포 전 자동 테스트에 투자했고, 동시 변경이 충돌할 수 있지만 Claude가 대개 사람이 충돌을 알아채기도 전에 고친다고 설명한다. 이 부분은 「머지 전에 검증한다」는 오래된 원칙을 「머지 후 배포 전에 검증한다」로 옮긴 것이어서, 소스 관리보다 더 큰 변화일 수 있다.
Scion의 설계 선택과 그 선배들
글이 밝힌 Scion의 원칙은 여섯 가지다. 클라이언트는 항상 온라인이다. 클라이언트와 서버는 비대칭이다. 포괄적인 소스 관리 서비스가 새 응용을 가능하게 한다. 모든 것은 수평 확장 가능해야 한다. 커밋은 싸고 증분적이며 잠금이 없어야 한다. 작업 사본은 선택 사항이고 설계상 희소하다.
구체적으로 보면 이렇다. Scion에서 작업의 단위는 「changeset」이라는 write-ahead log의 항목이다. git 커밋이 트리에 대한 포인터를 저장하는 것과 달리, changeset은 첫 번째 부모 대비 바뀐 파일 목록과 blob 스토리지에 있는 압축 파일 내용에 대한 content-addressed 포인터를 저장한다. 커밋, 리베이스, 머지는 모두 서버에서 일어나므로 push할 것이 없다. 커밋 비용은 저장소 전체 크기가 아니라 변경 크기에 비례해야 하고, 브랜치나 태그 같은 ref는 메인과 릴리스 브랜치 외에는 권장되지 않는다. 모든 서버가 합의해야 하는 전역 상태는 다가오는 확장 문제이기 때문이라고 한다. ref를 움직이는 것은 changeset 생성과 분리된 Spanner 한 행에 대한 compare-and-swap이다.
changeset은 바뀐 것만 기록하므로 「이 줄을 마지막으로 고친 사람」 같은 질문에는 바로 답하지 못한다. 그래서 Scion은 changeset에서 blame, 경로 히스토리, 커밋 그래프용 skip list 같은 구조를 따로 만든다. 글은 이를 「derived data」라고 부르고, 각 타입이 부모의 값에서 재귀적으로 계산되는 하나의 범용 메커니즘으로 처리한다고 설명한다. 새 타입 추가가 쉽고, 즉시 계산할지 미룰지 고를 수 있으며, 클라이언트가 내부 구조를 보지 않으므로 클라이언트 변경 없이 최적화할 수 있다는 것이 장점으로 꼽힌다.
전송 프로토콜도 git과 다르다. git의 협상은 클라이언트가 이미 가진 것을 서버에 알리고 서버가 빠진 것을 계산해 packfile로 묶어 보내는 방식이다. Scion에서는 클라이언트가 루트 트리에서 출발해 로컬 저장소에 없는 트리를 재귀적으로 요청하고, 이어서 blob을 요청한다. 모든 요청은 절대 바뀌지 않는 특정 객체에 대한 것이므로 어떤 캐시든 답할 수 있다. 노드마다 scion-daemon이 객체를 저장하고, 지역별 scion-cache를 거쳐, 캐시에 없을 때만 권위 있는 scion-server가 Spanner나 클라우드 스토리지에서 읽는다. 세 계층이 같은 RPC에 응답하지만 장애 영역을 격리하기 위해 계층 구조를 엄격하게 강제한다고 한다. 글이 밝힌 결과는 각 계층의 캐시 적중률 99% 이상, 이전 git 미러 인프라 대비 CPU와 메모리 기준 200분의 1의 규모, CI와 연구 잡의 체크아웃이 분 단위에서 초 단위로 두 자릿수 빨라졌다는 것, CI에서만 CPU 용량 25%를 절약했다는 것이다.
이 설계가 처음 보는 것인가. 글 자체가 아니라고 답한다. 거대 모노레포용 소스 관리에는 선행 사례가 있고, 대표적으로 Google의 Piper와 Meta의 Sapling이 있어 그들이 힘들게 얻은 교훈을 염두에 두고 Scion을 만들 수 있었다고 쓴다. 필자가 읽은 판에는 각주가 붙어 있는데, 구체적으로는 Sapling의 서버 구성 요소인 Mononoke가 Scion이 쓰는 여러 기법, 특히 Bonsai 데이터 모델을 개척했다는 내용이다. 다만 글 머리에는 10월 15일에 Scion의 여러 기법을 개척한 프로젝트에 대한 세부를 추가했다는 갱신 표기가 있다. 이 각주가 언제 들어갔는지는 아래 추기에서 다룬다.
해커뉴스 반응은 이 계보를 다양한 각도에서 짚었다. 한 이용자는 짧게 「Anthropic이 SVN을 재발명한 것인가」라고 물었다(@mijoharas)(직접 인용은 아니고, 코멘트의 요지를 요약). 중앙 서버에서 커밋이 일어난다는 점만 보면 틀린 말은 아니다. 다른 이용자는 기본 발상은 합리적이라고 봤지만, 모든 커밋과 리베이스가 서버에서 일어난다는 대목에서 등을 돌렸다. git과 특히 jujutsu의 핵심은 로컬에서 작은 커밋을 쌓고 다시 다듬거나 버릴 수 있다는 것인데, 이 모델은 AI가 편재하는 세계에서도 좋지 않다는 주장이었다(@amluto)(직접 인용은 아니고, 코멘트의 요지를 요약). East River Source Control에서 일한다는 이용자는 대형 팀과 에이전트가 모노레포에서 일하면 git의 확장 한계에 부딪힌다는 자사의 논지를 확인해 준다며 반겼고, git 호환 계층을 통한 다리를 제공하고 있다고 소개했다(@steveklabnik)(직접 인용은 아니고, 코멘트의 요지를 요약).
이것은 프런티어 랩만의 이야기인가
글은 스스로 일반화에 선을 긋는다. Scion은 범용 git 대체품이 아니며, 여기서 설명한 개념은 수만 명의 엔지니어나 코드를 왕성하게 쓰는 에이전트 무리가 있는 정말 거대한 모노레포에만 맞는다고 쓴다. 게다가 Anthropic은 사내용으로 토큰을 쓸 수 있는 능력이 다른 어떤 기업이 현실적으로 쓰고 싶어 할 수준을 훨씬 넘는다는 점에서 독특하다고 인정한다. Scion을 외부에 제공하기도 어렵다. git에서 크게 벗어나 있어 개발 수명 주기의 모든 부분을 옮겨야 하고, 자체 코드 리뷰, 코드 검색, CI가 필요하기 때문이다.
그런데 같은 글은 이런 종류의 문제가 앞으로 6~12개월 안에 더 흔해질 것으로 예상한다고도 쓴다. 그래서 Scion 자체가 아니라 생각을 공유하겠다는 것이다. git 서버가 git 클라이언트와 같은 방식으로 동작할 필요는 없고, git 플랫폼이 Scion처럼 포괄적인 서버 측 RPC를 제공할 수 있으며, 어쩌면 포지 간에 표준화해 git 클라이언트가 그것과 대화할 수도 있다는 제안이다. 협상 프로토콜도 지금 모습일 필요가 없고, git의 여러 희소·얕은 기능이 서로 잘 조합되게 만들 수 있다고 덧붙인다. 마지막으로 GitHub, GitLab, OSS 커뮤니티와 협력하겠다는 말로 맺는다.
필자는 이 두 주장 사이의 긴장이 이 글의 진짜 내용이라고 본다. 「우리만의 문제」와 「곧 모두의 문제」가 동시에 참이려면, 문제를 일으키는 변수가 회사 규모가 아니라 에이전트가 만드는 변경량이어야 한다. 해커뉴스에서도 이 지점을 두고 의견이 갈렸다. 한 이용자는 다들 자기가 Anthropic이나 Google이 아니라는 걸 깨닫기 전에 같은 걸 해야 한다고 조바심 내는 추한 시기가 올 것이라고 했다(@preommr)(직접 인용은 아니고, 코멘트의 요지를 요약). 다른 이용자는 AI가 코드 작성을 싸게 만들면서 작은 스타트업에서도 바퀴의 재발명이 늘 것이고, 직접 만든 소프트웨어를 유지하는 것도 똑같이 쌀지는 다른 문제라고 지적했다(@kburman)(직접 인용은 아니고, 코멘트의 요지를 요약).
리뷰 문제도 제기됐다. 글은 팀원이 여전히 모든 변경 요청을 리뷰하지만, 이제 코드 한 줄 한 줄을 읽기보다 변경의 의도를 검토한다고 쓴다. 엔지니어의 역할은 종종 Claude에게 「아니」라고 말하는 것이었고, 에이전트가 애초에 허용되지 말았어야 할 패턴을 만족시키려 핵심 제약을 어기는 일이 이전 과정에서 특히 잦았다고 한다. 예로 든 것은 변경이 언제 메인에 머지됐는지 알아내기 위해 코드 리뷰 도구에 묻지 않고 커밋 로그를 선형으로 읽는 시스템들이다. 적대적 리뷰가 근시안적일 수 있어서 가상의 우려에 대응한 과잉 설계를 막아야 했다는 대목도 있다. 한 이용자는 이 부분이 자신의 에이전트 코딩 경험과 맞는다면서도, 하루 3만 건을 의도만이라도 리뷰하기가 얼마나 쉬운지, 코드를 읽지 않고 모델이 의도 구현에서 지름길을 택했는지 어떻게 알아챌 수 있는지 의문을 표했다(@tetraodonpuffer)(직접 인용은 아니고, 코멘트의 요지를 요약).
필자의 판단으로는, 이 사례를 일반화할 때 가져갈 것은 Scion의 구현이 아니라 질문 하나다. 「우리 개발 인프라 중 무엇이 사람의 속도를 전제로 설계되어 있는가」. 하루 머지 수십 건의 팀이 소스 관리를 갈아엎을 이유는 없다. 하지만 체크아웃 비용이 저장소 크기에 비례하는 CI, 전역 잠금에 기댄 머지 큐, 한 줄씩 읽는 것을 전제로 한 리뷰 절차는 에이전트 사용량이 늘어날 때 규모와 무관하게 먼저 삐걱거릴 후보다. 글이 git 진영에 제안한 서버 측 RPC나 객체 단위 요청 프로토콜이 실제로 표준화될지는 아직 알 수 없다.
(10월 15일 추기: 10월 14일, Meta에서 Mononoke 개발에 참여했던 Rain은 블로그에 「Anthropic’s Scion is heavily inspired by Mononoke」를 올렸다. 그는 Anthropic이 Scion의 「derived data」를 설명한 대목과 자신이 2022년 Mononoke의 derived data를 설명한 글을 나란히 놓고, 모방의 정도가 비슷한 통찰을 넘어선다고 썼다. Sapling이 「힘들게 얻은 교훈」으로만 언급되고 Mononoke가 전혀 언급되지 않은 것은 표절에 가깝다는 것이다. 동시에 Anthropic이 Mononoke의 설계를 따라 한 것 자체에는 문제가 없으며 오픈소스로 낸 이유가 좋은 아이디어의 확산이라고 밝히고, LLM이 새 시스템 설계를 도울수록 기존 설계에 크게 기대게 될 것이니 출처를 밝히는 일이 그 어느 때보다 쉽고 중요하다고 강조했다. 이 글은 해커뉴스에서 426점을 받았다. 반론도 있었다. 한 이용자는 Mononoke가 Sapling의 구성 요소이고 Rain의 글이 거는 저장소 링크도 Sapling 저장소의 하위 디렉터리라며 불만의 요지를 잘 모르겠다고 했고(@BryantD), 다른 이용자는 인덱스라는 발상이 새로운 것은 아니며 문제를 처음부터 따져 본 사람이라면 떠올렸을 내용이라고 반박했다(@Mawr)(둘 다 직접 인용은 아니고, 코멘트의 요지를 요약). Anthropic의 원문에는 앞서 말한 대로 10월 15일 갱신 표기와 함께 Mononoke와 Bonsai 데이터 모델을 명시한 각주가 들어가 있다. 갱신 전 원문의 정확한 문구는 필자가 직접 확인하지 못했으며, 원래 Sapling만 언급되었다는 것은 Rain의 글에 근거한 서술이다.)
결론
Anthropic의 글이 보여 주는 사실은 분명하다. 하루 머지가 2,500건에서 3만 건으로 늘자 git 미러 수백 대로 버티던 체계가 한계에 닿았고, 항상 온라인인 클라이언트를 전제로 서버 중심, content-addressed, 객체 단위 요청, derived data를 축으로 한 시스템으로 옮겼다. 그 결과 인프라 규모가 200분의 1이 되고 체크아웃이 초 단위가 되었다고 한다.
그러나 이 설계 요소들은 대부분 새것이 아니다. 중앙 서버, 가상화된 작업 사본, 변경만 기록하는 데이터 모델과 그 위의 파생 인덱스는 Google과 Meta가 거대 모노레포를 운영하며 다듬어 온 방향과 겹친다. 새로운 것은 그 압력을 받는 주체다. 예전에는 수만 명의 엔지니어를 가진 회사만 이 지점에 닿았는데, 이제는 에이전트의 변경량이 같은 압력을 만든다. 그리고 Rain의 지적은 또 하나의 새로운 점을 드러낸다. 모델이 기존 오픈소스 설계를 학습해 그대로 재조립해 낼 수 있을 때, 그 계보를 밝히는 책임은 모델이 아니라 그것을 쓰는 사람에게 남는다.
당신의 조직에서 에이전트가 만드는 변경이 지금의 열 배가 된다면, 가장 먼저 무너지는 것은 무엇인가. 소스 관리일 수도, CI일 수도, 리뷰일 수도 있다. 그 답을 미리 알아 두는 것이 Scion을 따라 만드는 것보다 훨씬 싸다.
출처: