사람보다 에이전트가 더 많이 커밋하는 시대
Anthropic이 엔지니어링 블로그에 사내 소스 컨트롤(버전 관리) 시스템을 다시 설계한 이야기를 공개했어요. 소스 컨트롤이 뭐냐면, 코드 변경 이력을 기록하고 여러 사람이 동시에 작업한 내용을 합쳐주는 시스템이에요. 대부분의 개발자에게는 그냥 'Git'이죠.
이 주제가 특히 흥미로운 건 Anthropic이 AI 코딩 에이전트를 가장 적극적으로 쓰는 회사 중 하나이기 때문이에요. Anthropic은 사내 코드의 상당 부분을 Claude가 작성한다고 여러 차례 밝혀왔어요. 사람이 하루에 몇 번 커밋하던 환경이, 에이전트 수십 개가 동시에 브랜치를 만들고 코드를 고치고 PR을 올리는 환경으로 바뀌면 기존 도구와 워크플로는 어떤 압박을 받을까요? 이 글은 그 질문에 대한 한 회사의 실전 답안이라는 점에서 의미가 커요. 구체적인 설계 결정과 수치는 원문에서 직접 확인하시길 권해요. 여기서는 그 글을 제대로 읽기 위한 배경과 관점을 정리해볼게요.
에이전트가 늘면 Git에서 무슨 일이 생길까
Git은 2005년에 리눅스 커널 개발을 위해 만들어졌어요. 수많은 개발자가 이메일로 패치를 주고받는 환경에 맞춘 도구죠. 그런데 에이전트 중심 개발에서는 몇 군데가 병목이 되기 쉬워요.
첫째, 작업 공간 문제. 에이전트 여러 개가 같은 저장소에서 동시에 일하려면 서로의 파일을 덮어쓰지 않도록 각자 독립된 작업 공간이 있어야 해요. 가장 쉬운 방법은 git worktree예요. 저장소 하나에서 브랜치별 작업 폴더를 여러 개 꺼내 쓰는 기능이죠.
git worktree add ../agent-task-a -b agent/task-a
git worktree add ../agent-task-b -b agent/task-b
git worktree list
하지만 저장소가 거대해지면 작업 공간 하나 만드는 데도 시간과 디스크가 꽤 들어요. 에이전트를 수십, 수백 개 띄우면 이게 곧바로 비용이 되죠.
둘째, 머지 충돌과 병합 대기열. 변경이 많아질수록 같은 파일을 건드릴 확률도 높아져요. 그래서 큰 조직들은 변경을 한 줄로 세워서 하나씩 테스트하고 합치는 머지 큐(merge queue)를 써요. 놀이공원 줄 서기처럼 앞사람이 통과해야 다음 사람이 들어가는 구조예요. 에이전트가 PR을 쏟아내면 이 줄이 금방 길어지죠.
셋째, CI 비용과 리뷰 병목. 코드를 쓰는 속도가 빨라져도 테스트를 돌리고 사람이 리뷰하는 속도가 그대로면 결국 거기서 막혀요. 코드 생산이 싸지면 검증이 가장 비싼 단계가 되는 셈이에요.
업계는 어떻게 풀어왔나
사실 거대 저장소에서 Git이 버거워지는 문제는 빅테크가 먼저 겪었어요. 구글은 사내 전용 버전 관리 시스템 Piper로 거대한 모노레포(회사 전체 코드를 저장소 하나에 두는 방식)를 운영해요. 메타는 Mercurial을 개조해 쓰다가 Sapling이라는 자체 도구를 만들어 오픈소스로 공개했고요. 마이크로소프트는 윈도우 저장소를 Git으로 옮기면서 필요한 파일만 내려받는 가상 파일 시스템을 만들었고, 그 성과 일부는 Git 본체에도 반영됐어요.
최근에는 Jujutsu(jj) 같은 차세대 도구도 주목받고 있어요. Git 저장소와 호환되면서도 작업 중인 내용을 항상 커밋으로 다루고, 충돌을 '나중에 해결할 수 있는 상태'로 저장해둘 수 있어요. 그래서 여러 갈래의 작업을 자주 오가는 흐름에 잘 맞아요. 큰 변경을 작은 PR 여러 개로 쌓아 올리는 스택 디프(stacked diffs) 워크플로가 인기를 얻는 것도 같은 맥락이에요.
Anthropic의 글은 이 흐름 위에 '사람이 아니라 에이전트가 주 사용자가 될 때'라는 새 변수를 얹었다는 점에서 읽어볼 가치가 있어요.
한국 개발자에게 주는 시사점
우리 팀이 Anthropic 규모가 아니더라도 바로 써먹을 수 있는 교훈이 있어요.
- 에이전트를 여러 개 돌린다면 worktree부터 익히세요. 브랜치를 오가다 서로의 작업을 덮어쓰는 사고를 확 줄여줘요.
- PR은 작게, 자주. 에이전트가 만든 거대한 PR은 사람이 리뷰하기 어려워요. 작은 단위로 쪼개면 리뷰도 롤백도 쉬워져요.
- 테스트를 에이전트용 안전망으로 생각하세요. 코드를 쓰는 주체가 사람이든 AI든, 빠르고 믿을 만한 테스트가 있어야 자동화 속도를 감당할 수 있어요.
마무리
한줄 정리: 코드 작성이 싸지면 버전 관리와 검증이 개발 생산성의 새 병목이 돼요.
여러분 팀은 AI 코딩 도구를 쓰면서 Git 워크플로를 바꾼 게 있나요? 브랜치 전략이나 리뷰 방식에서 생긴 변화가 있다면 공유해주세요!
🔗 출처: Hacker News