Anthropic의 소스 컨트롤 재설계: git에서 Scion으로

Who Should Read

에이전트가 쏟아내는 코드 때문에 CI 체크아웃과 모노레포 규모 문제를 겪기 시작한 인프라·플랫폼 개발자

Core Mechanics

• 병합량이 5개월 만에 10배 넘게 늘었다
  • 2026년 5월 하루 약 2,500건이던 병합이 9월에는 하루 30,000건을 넘었다.
  • 이제 병목은 코드 작성이 아니라 소스 컨트롤·빌드·CI 같은 사람 규모용 인프라라고 한다.
• git이 모노레포에서 한계에 부딪혔다
  • main 브랜치 히스토리만 약 100GB, 압축한 작업 사본은 25GB가 넘는다.
  • CI용 체크아웃이 하루 약 2,500만 번이라 그대로 가져오면 git 트래픽이 하루 600PB가 넘는다.
  • 한창일 때 내부 git 미러를 수백 대 운영했지만 병합 속도가 오르자 관리가 어려워졌다.
• 클라이언트는 항상 온라인이라는 전제로 다시 설계했다
  • 클라이언트 대부분이 에이전트와 잡이라 오프라인용 전체 복제가 오히려 확장을 막았다.
  • Scion은 커밋·리베이스·병합·blame 계산을 서버가 맡고, 클라이언트는 제한된 로컬 캐시와 작업 사본 배치만 한다.
• 커밋은 서버에서 만들고 push가 없다
  • 변경셋(changeset)은 write-ahead log의 한 항목으로, 부모 대비 바뀐 파일 목록과 blob 저장소 내용 포인터를 담는다.
  • packfile·락·ref 이동이 필요 없어 처리량이 높다.
  • blame·경로 히스토리 같은 파생 데이터는 변경셋에서 따로 계산한다.

Community Reactions

• 병합 속도에 의문을 던지는 의견
  • Claude 코드 리뷰를 멈출 때마다 나중에 엉성한 코드가 나왔다는 경험이 있고, 이 속도에서 어떻게 그걸 피하는지 모르겠다는 의견이 있었다.
  • 하루 3만 건을 의도만 보고 리뷰하면 모델이 몰래 편법을 쓰는 걸 어떻게 알아채느냐는 질문도 나왔다.
• git을 꼭 버려야 했느냐는 반론
  • 글만으로는 git이 이 작업량을 기술적으로 못 감당한다는 설득이 부족하다는 의견이 있었다.
  • 모노레포 자체를 재고하지 않았느냐는 질문과 함께, 5개 저장소를 한 디렉터리에 받아 에이전트를 돌려도 된다는 의견이 있었다.
  • 체크아웃이 병합 1건당 약 833번이라 이상하다는 지적도 있었다.
• 도메인 전문성이 여전히 중요하다는 의견
  • 에이전트에게 "안 돼"라고 한 경험이 보여주듯, 소스 컨트롤 경력자 없이 일반 개발자만으로는 이 규모에 쓸 만한 결과가 안 나왔을 것이라는 의견이 있었다.
  • AI로 코드 비용이 싸지면 작은 스타트업도 바퀴를 재발명할 텐데 유지보수 비용이 같이 싸질지는 별개라는 의견도 있었다.
• 비슷한 선행 사례와 개방성 우려
  • Oracle과 Google도 자체 소스 컨트롤을 만들었다는 경험담이 있었다.
  • Meta의 EdenFS와 Sapling, Cloudflare의 artifact-fs가 온디맨드 체크아웃에서 비슷하다는 언급이 있었다.
  • git이 만든 누구나 전체 히스토리를 가지는 개방성에서 후퇴라는 의견도 있었다.

How to Apply

• CI 체크아웃 비용부터 숫자로 뽑기
  • 오늘 CI 로그에서 하루 체크아웃 횟수, 잡당 클론 시간, 받는 데이터량을 집계하라.
  • 병합 수 대비 체크아웃 비율을 계산해 이 글의 수치와 비교하라.
• 불필요한 전체 클론을 API 조회로 바꾸기
  • diff, merge base, blame만 필요한 잡을 골라라.
  • 호스팅 서비스 API로 대체하거나 shallow·sparse checkout으로 바꿔라.
• 에이전트 작업 사본은 sparse로 제한하기
  • 에이전트 샌드박스가 필요한 디렉터리만 받도록 sparse checkout을 기본값으로 정하라.
  • 읽은 파일만 비용을 내는 구조로 가는 첫걸음이다.
• 머지 큐 가정을 점검하고 사후 테스트 추가하기
  • 병합 중 테스트가 도는 시간 동안 쌓이는 변경 수를 세어 보라.
  • 전역 락 큐가 막히면 병합 후·배포 전 자동 테스트를 추가하고 충돌 수정은 에이전트에게 맡겨라.

Try It

# Claude나 ChatGPT에 그대로 붙여넣기 (논문 방법의 간이 버전: 우리 CI의 소스 컨트롤 병목 진단)

나는 에이전트가 만드는 코드 변경이 빠르게 늘어나는 모노레포를 운영한다.
- 하루 병합 수: {{하루 병합 수}}
- 하루 CI 체크아웃 수: {{하루 체크아웃 수}}
- 저장소 히스토리 크기와 작업 사본 크기: {{크기}}
- 현재 쓰는 방식(shallow clone, 미러, 시드 등): {{현재 방식}}

아래 원칙에 비추어 병목을 진단해 줘.
1. 클라이언트는 항상 온라인이다. 전체 복제가 정말 필요한가
2. diff, merge base, blame은 서버 API로 대신할 수 있는가
3. 체크아웃은 sparse나 필요한 파일만 받는 방식으로 줄일 수 있는가
4. 캐시 가능한 불변 객체 기반으로 바꿀 수 있는가

지금 당장 30분 안에 할 수 있는 개선 3가지를 우선순위로 알려줘.

이어서 해 볼 것: 가장 큰 잡 하나를 골라 체크아웃 전후 시간을 재는 스크립트를 짜 달라고 해 보세요.

Terminology

관련 논문

• Mercury 3: 규모를 키운 diffusion LLM, 초당 1,000토큰 이상

  Diffusion LLM을 40배 키웠더니 속도 4~8배, 품질은 속도 특화 모델 수준

• Timestral: Mistral의 시계열 파운데이션 모델

  209M 파라미터 시계열 모델이 3대 벤치마크 1위, CPU에서도 돌아간다

• DeepSeek V4.1 Flash 1017 (Max) 성능·속도·가격 분석

  DeepSeek V4.1 Flash 1017 Max는 지능 지수 45에 211 tok/s, 입력 $0.30

• LLM 프록시를 직접 안 돌리면 무슨 일이 벌어지는지 어떻게 아나

  자체 LLM 프록시를 세웠더니 키·모델·캐시 미스를 직접 볼 수 있다

• DeepSeek V4.1 Flash 1017: 싼 가격에 1M 컨텍스트를 주는 에이전트용 모델

  DeepSeek V4.1 Flash 1017은 입력 $0.05/M, 1M 컨텍스트의 에이전트용 모델

• DeepSeek-V4.1-Flash-1017 공개: 더 짧게 생각하고 더 빠르게 일하는 에이전트용 모델

  DeepSeek V4.1 Flash 마이너 업데이트로 코딩·에이전트 벤치 점수↑, 실행 시간·출력 길이↓

• Llmspeed: 로컬 LLM 속도를 하드웨어 구매 전에 체감해 보는 시뮬레이터

  GPU·모델을 고르면 로컬 LLM 속도를 미리 체감하게 해 주는 시뮬레이터

Related Resources

• https://www.anthropic.com/engineering/redesigning-source-control
• https://github.com/facebook/sapling
• https://github.com/cloudflare/artifact-fs
• https://github.com/rektide/jj-workfuse