Anthropic Scion 정리, 범용 Git 대체재가 아닌 사내 모노레포 전용 시스템

Anthropic이 Git을 대체하는 버전 관리 시스템 Scion을 공개했다는 소식이 퍼지고 있는데, 원문을 읽어 보니 다른 부분이 많았습니다. 10월 13일에 올라온 Redesigning source control at Anthropic은 제품이나 소스 코드를 내놓은 글이 아니라 회사 안에서 쓸 버전 관리 시스템을 직접 만들어 옮겨 간 사정을 설명한 글이고, Anthropic 스스로 Scion은 일반 용도로 Git을 대체하기에 적합하지 않다고 써 놨기 때문입니다.

Scion은 Anthropic이 자기네 모노레포(회사 코드를 저장소 하나에 전부 모아 둔 방식)를 5개월 만에 Git에서 완전히 옮겨 간 사내 전용 버전 관리 시스템입니다. 참고로 Google이 4월에 공개한 같은 이름의 Scion은 에이전트 여럿을 묶어 관리하는 실험용 도구(InfoQ 기사)로, 이 글의 Scion과는 관계가 없습니다.

하루 머지가 2,500건에서 3만 건으로

올해 5월 Anthropic은 하루 평균 약 2,500건의 코드 변경을 머지, 그러니까 각자 고친 코드를 본 줄기(main)에 합치고 있었는데 9월에는 하루 3만 건을 넘었고, 이 증가세가 곧 느려질 것으로는 보지 않는다고 합니다. 머지하려는 수요는 사실상 무한하고 병목을 하나 없앨 때마다 코드 생산량이 바로 더 늘어난다는 이유입니다.

원문은 이제 코드를 짜는 일 자체는 병목이 아니라고 합니다. Claude가 연구 작업을 스스로 되풀이해 돌리고 새 서비스도 처음부터 만든다는 건데, 이렇게 사람이 시킨 일을 스스로 계획해 코드를 쓰고 올리는 AI를 에이전트라고 부릅니다. 그러다 보니 정작 막히는 건 사람이 짜던 양에 맞춰 만들어 둔 소스 관리와 빌드, 그리고 CI(코드를 합칠 때마다 자동으로 도는 테스트와 빌드) 쪽이라는 거죠.

Git은 저장소를 받으면 이력까지 통째로 내 컴퓨터에 복사되는 분산형이고, Anthropic도 대부분의 저장소에는 이 설계가 맞다고 인정했습니다. 다만 자기네 모노레포는 그 범위를 벗어났다는 건데, 규모는 이렇습니다.

하루 2,500만 건은 하루 머지 3만 건과 견주면 머지 하나당 800번이 넘는 셈인데, 원문은 이 체크아웃이 어떻게 구성되는지는 설명하지 않습니다.

Git에도 큰 저장소를 위한 우회책이 있고 Anthropic은 최근 이력만 받기, 필요한 폴더만 받기, 미러, 저장소 스냅샷까지 전부 써 봤는데, 시간은 벌었어도 머지 속도가 올라갈수록 운영이 어려워졌다고 합니다.

그러다 나온 깨달음이 글의 핵심으로 보입니다. 저장소를 쓰는 쪽 대부분이 항상 인터넷에 연결된 에이전트와 CI 같은 자동 작업이었다는 겁니다. 인터넷이 끊겨도 일할 수 있다는 Git의 강점이 저장소가 커질수록 오히려 확장을 방해하게 된 거죠. 그래서 에이전트가 항상 온라인이라는 전제로 소스 관리를 처음부터 설계하면 어떤 모습일지를 물었다고 합니다.

Scion은 Git과 어떻게 다른가

Git이 모든 컴퓨터가 전체 사본을 갖는 방식이라면 Scion은 서버가 대답하고 클라이언트는 필요한 것만 받습니다. 이력이나 비교 같은 계산을 내 컴퓨터가 아니라 서버가 해서 결과만 준다는 뜻입니다. 자주 쓰는 파일은 가까운 곳에 임시로 복사해 두는데(캐시), 서버에도 저장소 전체를 합친 사본은 없다고 합니다. 그리고 커밋과 머지도 내 컴퓨터가 아니라 서버에서 일어나서 따로 올릴 것이 없습니다.

Git의 커밋에 해당하는 Scion의 기본 단위는 변경 묶음(changeset)인데, 폴더 전체 구조를 가리키는 대신 바뀐 파일 목록과 각 파일 내용의 지문(해시)을 담습니다. 내용으로 만든 지문을 이름으로 붙여 두니 한 번 저장된 건 바뀔 일이 없고, 그래서 어느 서버든 다른 서버에 물어보지 않고 그냥 복사해 둬도 되는 거죠. 실제로도 작업을 돌리는 컴퓨터, 지역별 중간 저장소, 원본 서버까지 세 단계로 캐시를 두고 돌아간다고 합니다.

결과 숫자, 그리고 사람이 한 일

Anthropic이 밝힌 결과는 아래 네 가지입니다. 전부 Anthropic이 직접 밝힌 숫자이고 독립적으로 검증된 바는 없습니다.

앞서 본 100GB와 방금 본 99%는 서로 다른 자리의 숫자입니다. 100GB는 메인 브랜치 이력의 크기, 99%는 각 단계 캐시의 적중률이라 하나로 묶어 읽을 수 없습니다.

7명이 Scion과 코드 리뷰 도구 Antique를 함께 만들고 Git에서 옮겨 오는 일까지 5개월 만에 끝냈고, 그 사이 하루 머지량은 10배 넘게 늘었습니다. 과거였다면 더 많은 인원이 여러 해에 걸쳐 옮겼을 일이라고 씁니다. 올해 초 Git의 데이터를 Scion으로 옮겨 담는 도구는 첫 버전이 거의 사람이 짠 시험판이었습니다. 그러다 내부에서 쓰던 Claude Mythos Preview 초기 버전을 구해 통째로 다시 써 보라고 시켰더니, 다른 지시는 더하지 않았는데도 수집 순서와 자료구조에 숨어 있던 규칙은 그대로 지키면서 메모리는 20배 덜 쓰고 속도는 4배 빠른 버전이 나왔다고 Anthropic이 소개했습니다.

사람의 역할에 대해서는 이렇게 씁니다. 만든 엔지니어 전원이 지금은 Claude가 자기보다 코드를 더 잘 쓴다고 평가하지만, 시스템 전체 구조와 무엇을 얻고 무엇을 포기할지는 사람이 판단하고, 자주 한 일은 Claude에게 "안 돼"라고 말하는 것이었다고 합니다. 에이전트가 시스템의 핵심 제약을 어기는 일이 이전 과정에서 특히 잦았다는 건데, 예를 들어 어떤 시스템들은 변경이 main에 언제 머지됐는지를 코드 리뷰 도구에 묻지 않고 커밋 로그를 처음부터 읽어서 찾으려 했다고 합니다. 이 시스템의 변경 요청은 지금도 전부 리뷰하는데, 다만 모든 줄을 읽기보다는 이 변경이 뭘 하려는 건지를 본다고 하고요. 그게 실제로 코드를 어디까지 읽는다는 뜻인지는 원문만 봐서는 잘 모르겠습니다.

일하는 방식도 달라졌는데, 합칠 순서대로 변경을 줄 세우는 머지 큐는 에이전트가 쏟아내는 양에는 맞지 않는다고 봤습니다. 업계에서 표준처럼 쓰는 방식은 합치는 동안 저장소 전체를 잠그는 건데, 이걸 효과적으로 재현하지 못했다고 하고요. 그 대신 머지가 끝난 뒤 배포 전에 도는 자동 테스트에 힘을 실었습니다. 그래서 동시에 들어온 변경끼리 충돌할 수 있지만 Claude가 대체로 사람이 알아채기 전에 고친다는 설명입니다.

그래서 내 Git은 달라지나

먼저 답부터 말하면 지금 당장 내 Git 사용법이 바뀔 일은 없어 보입니다. Anthropic이 스스로 선을 그어 놨기 때문인데, Scion은 수만 명의 엔지니어나 코드를 쏟아내는 에이전트 떼가 있는 정말 거대한 모노레포에서만 의미가 있고, 자기네는 토큰을 쓸 수 있는 규모가 다른 기업이 현실적으로 쓸 수준을 훨씬 넘는 특별한 회사라고도 썼습니다.

그렇다고 다른 회사가 쓸 수 있게 내놓겠다는 얘기도 없습니다. 내놓기 어렵다는 이유는 이렇습니다. Git과 워낙 달라서 코드 리뷰, 코드 검색, CI까지 개발 과정 전체를 같이 옮겨야 하고, 사내 구성요소도 아주 맞춤형이라 다른 조직이 쓸 만한 형태로 만들기는 현실적으로 어렵다는 겁니다. 글에는 소스 코드 저장소 링크도, 설치나 다운로드 안내도 없습니다. 14일 오전에 Anthropic GitHub의 최근 저장소 100개를 확인해 보니 Scion은 없었고, 그보다 오래된 것까지 다 본 건 아니지만 어쨌든 지금 공개된 건 코드가 아니라 설계 설명인 셈입니다.

그 대신 Anthropic은 생각을 나누는 쪽을 택했습니다. Git 서버가 Git 클라이언트와 똑같이 동작할 필요는 없고 GitHub 같은 Git 플랫폼이 Scion처럼 서버 쪽 호출을 폭넓게 제공할 수 있다는 식의 제안을 하고, GitHub, GitLab, 오픈소스 커뮤니티와 협력하고 싶다고 맺었습니다. Git을 갈아엎자는 이야기보다는 Scion의 아이디어를 Git에 적용해 보자는 제안으로 읽힙니다.

Anthropic은 이런 문제가 앞으로 6~12개월 안에 더 흔해질 것으로 예상하고, 모든 Git 사용 회사가 혼자 같은 문제를 겪는 것은 비효율이라고 봅니다. 달라질 수 있는 건 GitHub나 GitLab 같은 Git 서버 쪽이 이 제안을 받아들이느냐인데, 어떻게 응답할지는 아직 모릅니다.

밖에서는 어떻게 봤나

이런 길을 간 큰 회사는 Anthropic이 처음이 아닙니다. Anthropic도 Google의 Piper와 Meta의 Sapling을 참고했다고 썼고, Google은 2016년 논문에서 약 10억 개 파일이 든 저장소를 감당할 시스템을 찾지 못해 Piper를 만들었다고 밝혔습니다.

Hacker News의 원문 스레드에는 14일 오전 기준 535점에 댓글이 약 520개 달렸습니다. 눈에 띈 몇몇 댓글만 보면 의문은 두 갈래였고, 전체 여론은 아닙니다.

하나는 설계 자체에 대한 것입니다. 한 댓글은 커밋과 머지를 전부 서버에서 하면 로컬에서 작은 커밋을 쌓고 다듬는 Git의 장점이 사라지고, AI 모델 API 없이는 아무것도 못 하는 Anthropic 같은 곳에서나 통할 방식이라고 했습니다. 다른 댓글은 버전 관리를 다시 짜기 전에 정말 모노레포여야 하는지부터 물었어야 한다고 지적했습니다. 구조가 대형 게임이나 3D 에셋의 버전 관리와 닮았다는 반응도 있었습니다. Perforce를 두고는 구조가 비슷하다는 말과, Perforce는 규모를 못 감당해서 Piper가 나온 것이라는 반박이 오갔지만 결론은 나지 않았습니다.

다른 하나는 AI가 코드를 쏟아내는 상황에 대한 것입니다. 한 댓글은 하루 3만 건을 의도만 보고 리뷰하는 게 가능한지, 모델이 지름길로 구현한 것을 어떻게 알아채는지 물었습니다. 가볍게는 프롬프트를 소스 코드로 커밋하고 AI가 만든 코드는 빌드 결과물처럼 두면 좋겠다는 상상도 있었습니다.

리뷰 쪽 의문과 닿는 연구가 하나 있습니다. Ars Technica가 9일에 소개한 하버드대 연구에 따르면, 700곳이 넘는 회사에 AI 코딩 에이전트가 들어온 뒤 코드 줄 수는 평균 30% 늘었지만 이슈와 기능 단위 작업의 해결률은 통계적으로 의미 있게 달라지지 않았고, 풀 리퀘스트(고친 코드를 합쳐 달라는 요청)가 머지되기까지 리뷰에 걸리는 시간은 평균 49% 늘었습니다. 막힌 곳이 소스 관리가 아니라 사람의 코드 리뷰라서 Anthropic의 이야기와 같지는 않지만, 코드가 늘면 뒤쪽이 막힌다는 방향은 닮았습니다. 데이터가 2026년 3월에서 끊기고 저도 논문이 아니라 기사로만 봤으니 참고로만 보세요.

나머지 이야기도 결국 같은 곳을 가리킵니다. AI 시대에는 기존의 Git 관리 방식 그대로가 아니라 새로운 형태의 소스 관리(형상 관리)가 필요하다는 이야기가 나오고 있다는 점입니다. 그런데 원칙은 같습니다. 결국 더 효율적인 관리 방법을 찾는 일이죠.

불만도 많습니다. 하지만 Anthropic의 이런 새로운 시도가 또 다른 가치를 만들어내지 않을까 기대해 봅니다.