Anthropic은 왜 Git을 버리고 Scion을 만들었을까?
송찬우 5분 분량
10월 13일(미국 시간) Anthropic이 사내 모노레포를 Git에서 직접 만든 소스 관리 시스템 Scion으로 옮겼다고 밝혔습니다. 5월에 하루 약 2,500건이던 코드 병합이 9월에는 하루 30,000건을 넘었고, Git으로는 더 버틸 수 없었다는 이야기입니다. 이 글은 해커뉴스에서 898점, 댓글 1,013개가 달렸어요.
Claude가 코드를 대신 짜 주니 개발이 빨라졌다는 이야기는 많이 나왔습니다. 그런데 코드가 빨리 나오면 그 코드를 받아 주는 쪽에는 무슨 일이 생길까요? Anthropic 글은 그 답을 숫자로 보여 줍니다.
결론부터 말하면, 병목이 코드 작성에서 코드를 받아 주는 시스템으로 옮겨 갔습니다.
Anthropic은 글 첫 문단에서 이제 코드를 짜는 일은 병목이 아니라고 썼습니다. 병목은 사람 속도에 맞춰 만든 개발 인프라, 그러니까 소스 관리, 빌드, CI라는 겁니다.
숫자를 보면 이해가 됩니다. 모노레포 main 브랜치의 기록만 약 100GB이고, 압축한 작업 사본도 25GB가 넘습니다. 그런데 CI가 코드를 받아 가는 체크아웃이 하루 약 2,500만 번입니다. 개발자 환경과 에이전트 샌드박스, 연구 작업은 뺀 숫자예요. 이걸 Git 방식 그대로 받으면 하루 600PB가 넘는 트래픽이 생긴다고 합니다.
그래서 얕은 복제, 부분 체크아웃, 사내 Git 미러처럼 큰 저장소를 다루는 표준 방법을 다 썼습니다. 미러만 한때 수백 대를 돌렸어요. 그래도 병합 속도가 올라갈수록 운영이 더 어려워졌다고 합니다.
Git의 장점이 에이전트에게는 짐이었습니다.
Git은 분산형입니다. 복제본 하나하나가 완전한 저장소라서 인터넷이 끊겨도 기록을 보고, 비교하고, 아무 버전으로나 돌아갈 수 있습니다. 사람이 노트북으로 일하던 시절에는 이게 Git이 표준이 된 이유였죠.
그런데 Anthropic에서 저장소를 받아 가는 쪽은 대부분 에이전트와 CI 작업입니다. 이들은 늘 온라인이고, 저장소 전체가 필요하지도 않습니다. Anthropic은 다른 회사들처럼 Git을 사실상 중앙 서버 하나에 묶어 쓰고 있었고, 오프라인 작업을 위한 Git의 설계가 오히려 규모를 키우는 데 발목을 잡았다고 봤습니다.
그래서 Scion은 반대로 설계했습니다.
- 클라이언트는 늘 온라인이라고 가정합니다. 필요한 파일만 그때그때 서버에서 받아 옵니다.
- 기록 조회, 커밋, 병합, 리베이스는 서버가 합니다. 클라이언트는 작은 캐시와 작업 폴더만 관리합니다.
- “이 줄을 마지막에 누가 고쳤나” 같은 질문을 API로 열어 둬서, CI 작업은 저장소를 아예 내려받지 않아도 됩니다.
- 커밋 비용이 저장소 크기가 아니라 바뀐 파일 수에 비례하도록 만들었습니다. 커밋 하나는 바뀐 파일 목록과 파일 내용 주소만 담습니다.
결과는 에이전트 시간으로 돌아왔습니다.
Anthropic이 공개한 측정값을 보면 차이가 큽니다. 에이전트 환경에서 새 작업 트리를 만드는 데 Git은 7.1분, Scion은 5.1초가 걸렸습니다. 약 84배예요. 변경 요청 하나에 드는 소스 관리 시간은 34분에서 3.7분으로 줄었고, Anthropic은 이걸 하루 약 1만 1천 에이전트 시간으로 계산했습니다. CI 체크아웃도 31초에서 3.5초가 됐습니다.
인프라는 더 작아졌습니다. 캐시 서버마다 적중률이 99%를 넘고, 전체 규모는 예전 Git 미러 인프라보다 CPU와 메모리 기준으로 200분의 1이라고 합니다. CI에서만 CPU 용량의 25%를 다시 쓸 수 있게 됐어요.
만든 사람은 7명이었습니다.
Scion과 코드 리뷰 도구 Antique, 그리고 관련 시스템 여섯 개 정도를 7명이 만들었고, 5개월 만에 이전까지 끝냈습니다. 그 사이 하루 병합량은 10배가 됐습니다. 예전 같으면 회사 하나가 몇 년에 걸쳐 많은 엔지니어를 들여 했을 일이라고 Anthropic은 썼습니다.
Claude가 실제로 한 일도 적혀 있습니다. Git에서 Scion으로 데이터를 옮기는 파이프라인 첫 버전은 사람이 거의 직접 짰는데, 내부 모델 Claude Mythos Preview에게 통째로 다시 쓰게 했더니 메모리는 20분의 1, 속도는 4배가 됐다고 합니다. 팀원 모두 이제 코드는 Claude가 자기보다 잘 쓴다고 평가한다고 해요.
그렇다고 엔지니어가 필요 없어진 건 아닙니다. 원문은 엔지니어의 역할이 Claude에게 “안 된다”고 말하는 일인 경우가 많았다고 썼습니다. 에이전트가 시스템의 기본 규칙을 어기면서 익숙한 패턴을 따라가거나, 적대적 리뷰에 휘둘려 쓸데없는 검증 코드를 덧붙일 때 멈추게 하는 일입니다. 팀은 여전히 모든 변경을 리뷰하지만, 코드를 한 줄씩 읽기보다 변경의 의도를 봅니다. 지난달 ‘AI 시대, 코드 리뷰는 어떻게 해야 할까’에서 이야기했던, 줄 단위로는 다 읽을 수 없게 된 리뷰의 다음 모습입니다.
운영도 바뀌었습니다. 팀은 Slack 채널마다 Claude 하나에게 시스템 부품 하나의 건강만 지켜보게 하고, 이들을 superfan이라고 부릅니다. 머지 큐에 전역 잠금을 거는 업계 표준도 포기했습니다. 테스트가 도는 사이에 수백, 수천 건이 병합되니 잠금이 의미가 없어진 겁니다. 대신 병합 뒤와 배포 전에 자동 테스트를 돌리고, 동시에 들어온 변경이 충돌하면 Claude가 사람보다 빨리 고친다고 합니다.
다만 처음부터 혼자 떠올린 설계는 아니었습니다.
글이 나온 다음 날, Meta에서 소스 관리 서버 Mononoke를 만든 개발자 Rain이 “Anthropic의 Scion은 Mononoke에서 크게 영향을 받았다”는 글을 올렸습니다. Scion의 핵심인 derived data 개념이 2017~2018년 Mononoke 팀이 만든 설계와 거의 같은데, 원문은 Meta의 Sapling을 짧게 언급했을 뿐 Mononoke는 이름도 없었다는 지적입니다. Rain은 설계를 가져다 쓴 건 문제 삼지 않는다고 하면서도, 출처를 밝히지 않으면 Claude가 다 설계한 것처럼 읽힌다고 했습니다. 이 글도 해커뉴스에서 429점을 받았어요.
Anthropic은 10월 15일 글을 고쳐 Mononoke가 Scion의 여러 기법, 특히 Bonsai 데이터 모델을 먼저 만들었다는 각주를 달았습니다. AI가 오픈소스 설계를 학습해서 빠르게 다시 만드는 시대일수록, 누구의 아이디어였는지 밝히는 일이 더 중요해졌다는 걸 보여 준 일 같습니다.
대부분의 회사에 Scion이 필요한 건 아닙니다.
Anthropic도 이 점을 분명히 했습니다. Scion은 일반적인 Git 대체품이 아니고, 엔지니어가 수만 명이거나 에이전트 무리가 코드를 쏟아 내는 거대 모노레포에서만 의미가 있다고 썼습니다. Anthropic은 내부에서 쓰는 토큰 양이 다른 회사가 현실적으로 쓸 수준을 훨씬 넘는다는 점도 인정했어요. Scion을 공개할 계획도 없습니다. 코드 리뷰, 코드 검색, CI까지 함께 바꿔야 해서 다른 회사가 가져다 쓰기 어렵다는 이유입니다.
대신 이런 문제가 앞으로 6~12개월 안에 흔해질 거라고 내다봤습니다. 그래서 깃허브, GitLab, 오픈소스 커뮤니티와 함께 Git 서버 쪽을 바꾸는 방향을 제안했습니다. Git 클라이언트는 그대로 두고, 서버가 기록 조회 같은 기능을 API로 제공하고, 부분 체크아웃 기능들이 서로 잘 맞물리게 하자는 겁니다.
회사 업무에 에이전트를 붙일 때도 같은 구조가 생길 수 있습니다. 에이전트가 만든 결과물은 금방 쌓이는데, 그걸 검토하고 반영하는 사람과 시스템은 예전 속도 그대로이기 때문입니다. 대부분의 팀에 필요한 건 Git을 버리는 일이 아니라, 리뷰 대기 시간이나 CI 시간처럼 다음 병목이 어디인지 먼저 재 보는 일일 것 같습니다.
코드를 쓰는 속도가 10배가 되자 Anthropic은 5개월 만에 소스 관리를 다시 만들었습니다. 다음으로 사람 속도에 맞춰진 채 남아 있는 건 CI와 배포일 듯싶습니다.
https://www.anthropic.com/research/redesigning-source-control