좋은 아침이에요! 오늘은 “코드 작성이 더 이상 병목이 아니면, 그다음엔 뭐가 막히나?”에 대한 답이에요.
뭔가요?
AI 에이전트가 사람보다 훨씬 많이 커밋하고 머지하는 상황을 전제로 버전 관리 시스템(VCS)을 다시 설계하는 접근이에요. 대표 사례가 Anthropic의 사내 VCS Scion이에요. git처럼 모든 클라이언트가 저장소 전체를 들고 있는 대신, 서버가 커밋·머지·리베이스·blame을 처리하고 클라이언트(에이전트, CI 작업)는 필요한 파일만 받아 써요. 많은 작업은 아예 체크아웃 없이 API로 끝내고요.
왜 지금 뜨나요?
Anthropic이 Redesigning source control at Anthropic에서 하루 머지 수가 2026년 5월 약 2,500건에서 9월 3만 건 이상으로 늘었고, 그래서 모노레포를 git에서 Scion으로 5개월 만에 옮겼다고 밝혔어요. 이어서 Claude Code 팀이 제품 코드의 약 90%를 Claude로 쓴다는 글(10월 15일)까지 나오면서, “AI 시대의 병목은 코드 작성이 아니라 머지·CI·리뷰”라는 얘기가 주말 내내 X에서 돌았어요.
시점 정리
– 아이디어 자체는 새롭지 않아요. 중앙 서버형 VCS는 CVS(1990), Perforce(1995), Subversion(2000)부터 있었고, 오히려 2005년에 나온 git이 분산형으로 판을 바꾼 쪽이에요. 초대형 모노레포용 중앙형 시스템도 Google Piper(2016년 논문으로 공개)와 Meta Sapling(2022년 11월 오픈소스)이라는 선례가 있고, Anthropic도 이 둘을 참고했다고 적었어요.
– 새로운 건 이유예요. “클라이언트 대부분이 항상 온라인인 에이전트”라는 전제로 처음부터 설계했다는 점이죠. 이번 화제의 출발점은 2026년 10월 13일(미국 기준) 블로그 글이에요. 즉 오래된 설계가 에이전트 때문에 다시 돌아온 경우예요.
– Scion은 공개되지 않았고, Anthropic도 일반적인 git 대체재로 쓸 물건은 아니라고 선을 그었어요.
Claude만 쓰던 개발자는 어떻게 쓰면 되나요?
Scion을 직접 쓸 일은 없지만, 같은 병목은 혼자 개발할 때도 작게 찾아와요. 에이전트를 여러 개 돌리기 시작하면 특히요.
- 역할 나누기: 코드 작성과 충돌 해결 초안은 Claude에게, 머지·bisect·revert 같은 정답이 정해진 작업은 git과 스크립트에게 맡기세요. “어느 커밋에서 깨졌지?”는 LLM에게 추측시키지 말고
git bisect run <테스트 명령>으로 찾은 뒤, 결과만 Claude에게 넘겨 원인을 설명하게 하면 돼요. - 병렬 에이전트는
git worktree로 작업 폴더를 나눠 서로의 파일을 밟지 않게 하고, 변경은 작게 쪼개 자주 머지하세요. 큰 PR 하나보다 작은 PR 여러 개가 충돌도 리뷰도 쉬워요. - 저장소가 커서 에이전트가 느려지면
git sparse-checkout으로 필요한 디렉터리만 꺼내 주세요. 컨텍스트 낭비도 줄어요. - 언제 LLM에 넘길지: 의도를 읽어야 하는 판단(이 충돌에서 어느 쪽 로직이 맞나, 이 변경이 위험한가)은 Claude에게, 계산으로 끝나는 일(diff, blame, 테스트 통과 여부)은 도구에게요.
연관 용어
– 머지 큐 (Merge Queue): PR을 줄 세워 최신 main 기준으로 테스트를 다시 돌린 뒤 순서대로 머지하는 방식이에요. GitHub에는 2023년에 정식 출시됐어요.
– 스파스·가상 체크아웃 (Sparse / Virtualized Checkout): 필요한 디렉터리나 실제로 읽는 파일만 내려받는 방식이에요. git의 sparse-checkout 명령은 2020년(git 2.25)에 들어왔어요.
– 모노레포 (Monorepo): 여러 프로젝트를 저장소 하나에서 관리하는 방식이에요. Google·Meta가 오래 써 왔고, Scion이 풀려던 규모 문제의 출발점이기도 해요.
오늘도 좋은 하루 보내세요!