Anthropic이 Git 사용을 중단한 이유: Scion 설명

지구상의 거의 모든 소프트웨어 회사가 Git을 사용합니다. Claude의 개발사인 Anthropic은 2026년 10월, 이를 중단했다고 밝혔습니다.

2026년 5월, Anthropic은 하루에 약 2,500개의 코드 변경 사항을 병합했습니다. 9월에는 이 숫자가 하루 30,000개 이상으로 늘어났으며, 그 코드의 상당 부분은 AI가 작성했습니다. Git이 병목 현상을 일으킨 것입니다. 이에 7명으로 구성된 팀이 새로운 소스 제어 시스템인 Scion을 구축하고, 회사 메인 저장소를 5개월 만에 Git에서 옮겼습니다.

본 게시물에서는 아주 작은 예제 앱 하나를 통해 처음부터 설명할 것이므로, Git 전문가일 필요는 없습니다.

🎥 비디오가 더 좋으신가요? 5분짜리 애니메이션 버전을 만들었습니다: (

)

먼저, Git이 어떻게 작동하는지 (60초 만에)

login.py, cart.py, payment.py 세 개의 파일을 가진 ShopApp이라는 작은 앱을 상상해 보세요.

개발자가 무언가를 변경하고 Git에 저장할 때마다, Git은 무엇이 변경되었는지, 누가 변경했는지, 그리고 언제 변경했는지를 정확하게 기록합니다. 이 기록을 **커밋(commit)**이라고 합니다. 커밋이 쌓일수록 프로젝트의 전체 역사를 얻게 되며, 어떤 이전 시점으로든 돌아갈 수 있습니다.

Git에는 또 하나의 초능력이 있습니다: 모든 개발자가 프로젝트 전체 역사와 함께 완전한 사본을 자신의 노트북에 갖게 됩니다. 트레인 안이든, 오프라인 상태든 어디서든 작업할 수 있고, 준비가 되면 공유된 사본으로 변경 사항을 푸시(push)할 수 있습니다.

이러한 설계 덕분에 Git은 세상을 장악했습니다. 그리고 우리가 보게 될 것처럼, 이것이 Anthropic의 문제의 근원이기도 합니다.

두 개발자, Priya와 Arun이 동시에 작업합니다. Priya는 login.py를 변경하고, Arun은 payment.py를 변경합니다. 파일이 다릅니다.

Priya가 먼저 푸시(push)합니다. 그러고 나서 Arun이 푸시하는데, Git이 거부합니다:

! [rejected]  main -> main (fetch first)

Git은 단지 한 가지를 확인합니다: 최신 버전에서 시작했는지 여부입니다. Arun이 최신 버전에서 시작하지 않았기 때문에, Priya의 변경 사항이 먼저 반영된 것입니다. 그래서 Arun이 풀(pull)을 하고, Git이 두 변경 사항을 자동으로 병합합니다 (서로 다른 파일을 건드렸으므로), 그리고 Arun이 다시 푸시합니다.

만약 그들 둘 다 cart.py의 같은 줄을 변경했다면, Git은 누가 맞는지 추측할 수 없습니다. 이것을 **충돌(conflict)**이라고 표시하며, 사람이 결정해야 합니다:

사람들로 이루어진 팀에게는 이것이 아주 잘 작동합니다.

Anthropic에서 잘못된 점은 무엇인가요

이제 엔지니어링 게시물에 나온 수치를 사용하여 Anthropic의 환경을 상상해 보세요:

• 모든 코드가 **하나의 거대한 저장소(repository)**에 존재합니다. 메인 브랜치(main branch)의 히스토리는 거의 100GB이며, 압축된 작업 사본은 25GB가 넘습니다.
• 대부분의 작업은 노트북을 사용하는 사람들에 의해 이루어지지 않습니다. 항상 온라인 상태인 AI 에이전트(AI agents), CI 작업 및 연구 작업에 의해 수행됩니다.
• 모든 테스트에는 코드 사본이 필요합니다: 하루에 약 **2,500만 건의 체크아웃(checkouts)**입니다. 일반적인 Git 방식으로 가져오려면 하루 600 페타바이트가 넘는 트래픽이 발생할 것입니다. 이는 초당 약 1,200개의 풀 HD 영화 분량입니다 (제가 임의로 계산해 본 비교: 하루 600 PB는 초당 약 6.9 TB에 해당합니다).

[

대응하기 위해 그들은 **수백 개의 내부 Git 미러(Git mirrors)**를 운영했습니다. 그러나 저장소의 규모가 미러 디스크와 메모리를 초과했고, 복사본들이 최신 코드보다 뒤처졌으며, diff나 blame 같은 히스토리 작업들을 유지하기가 점점 어려워졌습니다.

Anthropic이 직접 말한 바에 따르면, Git을 분산형(distributed)이고 오프라인 환경에서 사용하기에 탁월하게 만드는 속성들이 "우리의 확장 능력 자체를 적극적으로 훼손하고 있었다"고 합니다.

문제의 본질은 아니라는 점에 주목해야 합니다. Git이 변경 사항 저장에 실패한 것이 아닙니다. Git은 전체 복사본을 가진 오프라인 노트북 환경을 위해 구축되었으며, Anthropic의 세계는 매일 수백만 번씩 최신 코드가 필요한 항상 온라인(always-online) 장치로 변모했습니다.

Scion이 다르게 하는 방식

핵심 아이디어: 모두에게 전체 복사본을 제공하는 것을 멈추고, 서버에 하나의 메인 복사본을 유지하며, 작업을 서버가 수행하도록 하는 것입니다.

1. 푸시할 것이 없다 (Nothing to push). 커밋(Commits), 리베이스(Rebases), 병합(merges)은 서버에서 발생합니다. 에이전트가 변경 사항을 제출하면 서버가 이를 메인 코드에 저장합니다.
2. 스냅샷이 아닌 체인지셋(Changesets). 각 변경 사항은 실제로 바뀐 내용만을 기록하며, 히스토리나 블레임(blame) 같은 요소들은 파생 데이터(derived data)로 별도로 구축됩니다.
3. 필요한 것만 가져오기 (Fetch only what you need). 희소 및 가상 체크아웃(Sparse and virtual checkouts)을 사용하면 작업이 필요한 저장소의 부분만을 받게 됩니다. 파일은 여전히 목록에 나타나지만, 무언가가 파일을 열 때 그 내용물이 도착합니다.
4. 더 적은 브랜치. 전역 상태(global state)를 모든 서버가 합의해야 하므로 확장성이 떨어지기 때문에, 주로 하나의 메인 라인과 릴리스 브랜치만 존재합니다.

다시 Priya와 Arun 이야기로 돌아가겠습니다. 원리적으로 서버 측 병합(server-side merge)이 어떻게 작동하는지 설명드립니다 (제 자체적인 일러스트레이션이며, Anthropic의 게시물은 개별 사례 규칙을 나열하지 않습니다):

그들이 보고하는 결과: CI 및 리서치 체크아웃 속도가 100배 빨라졌으며 (분 단위 대신 초 단위), Scion 인프라는 이전 Git 미러링 설정보다 CPU와 메모리 면에서 약 200배 작습니다.

왜 작은 레포지토리들을 많이 사용하지 않을까요?

좋은 질문입니다. Git은 작은 레포지토리를 쉽게 처리하며, 대부분의 회사들이 실제로 그렇게 합니다. Anthropic의 게시물에는 왜 하나의 큰 레포지토리를 유지하는지에 대한 설명이 없으므로, Google이나 Meta 같은 회사들이 제시하는 일반적인 이유를 알려드립니다:

• 하나의 변경 사항, 여러 프로젝트. 만약 20개의 앱이 동일한 로그인 코드를 공유한다면, 20개의 레포지토리는 20번의 개별 업데이트를 의미하며, 일부 앱은 며칠 동안 여전히 이전 버전을 실행할 수 있습니다. 하나의 레포지토리로는 단일 변경 사항만으로 20개를 모두 함께 업데이트할 수 있습니다.
• 오래된 버전이 쌓이는 대신, 공유 코드의 단일 버전.
• 모든 것을 한곳에, 이는 AI 에이전트가 회사 전체의 코드를 보고 수정해야 할 때 더욱 중요합니다.

단점은 크기(size)이며, 이것이 바로 Scion이 해결하는 정확한 문제입니다.

Git 사용을 중단해야 할까요?

아닙니다. Anthropic 자체도 Scion이 일반적인 Git의 대체재는 아니라고 말하며, 현재 배포되지 않고 있습니다. 대부분의 팀에게 Git은 여전히 올바른 도구이며, 오늘날에도 스파스 체크아웃(sparse checkout), 부분 클론(partial clone), 그리고 GitHub 및 GitLab의 **병합 큐(merge queues)**와 같은 동일한 아이디어들이 사용 가능합니다.

하지만 더 큰 교훈은 주목할 가치가 있습니다. AI 에이전트가 이 속도로 코드를 작성한다면, 가장 신뢰하는 도구들조차 변화해야 합니다.

AI 에이전트가 하루에 3만 건의 변경 사항을 병합하도록 허용하시겠습니까? 댓글에서 여러분의 의견을 듣고 싶습니다.

출처(Sources)

• Anthropic Engineering, "Anthropic에서의 소스 제어 재설계" (2026년 10월 13일): https://www.anthropic.com/engineering/redesigning-source-control
• 본 게시물의 모든 숫자에 대한 사실 확인: https://github.com/kannajune/kdblueprints-sources/blob/main/2026-10-15-scion/SOURCES.md

ShopApp 예시, Priya와 Arun, 세 가지 경우의 표, 그리고 영화 비교는 Anthropic의 것이 아니라 제가 직접 설명한 것입니다.