Anthropic이 자체 Git 대안을 만든 이유: 코드 양이 인간 리뷰를 앞지를 때

인간의 속도를 위해 만든 도구가 기계의 속도를 만날 때

Simon Willison이 이 변화를 기록한 데서 비롯된 보도에 따르면, Anthropic은 Git을 대체할 자체 시스템을 만들었다. 방아쇠는 버그도 보안 사고도 아니었다. 양이었다. 회사 코드베이스에 유입되는 변경의 속도가 가파르게 치솟았고, 2026년 5월에는 한 주기당 평균 약 2,500건의 요청에 이르렀다. 기존 버전 관리가 감당하도록 설계되지 않은 부하다.

이 일을 사내 도구 문제로 분류하고 넘어가기는 쉽다. 하지만 그건 실수다. Git은 지금까지 작성된 소프트웨어 가운데 가장 영향력이 큰 것 중 하나이며, 코드가 어떻게 바뀌는지에 관한 일련의 가정 위에 세워져 있다. 그 가정은 이제 실무에서 깨지고 있다.

Git이 세워진 가정

Git의 설계에는 인간 행동에 관한 하나의 믿음이 새겨져 있다. 변경은 사람이 눈으로 좇을 수 있는 속도로 도착한다. 브랜치는 이름을 붙일 만큼 오래 지속되는 의도를 나타낸다. 역사는 소중하므로 아무것도 버리지 않는다. 메인테이너는 diff를 읽고 병합하기 전에 판단을 세울 수 있다.

에이전트가 코드를 작성하면 이 가정은 하나같이 약해진다.

에이전트는 지치지 않으므로 하루치 단위가 아니라 끊임없이 변경을 만들어낸다. 며칠씩 의도를 붙들지 않으므로 브랜치는 이름을 붙이는 것 자체가 부담일 만큼 단명해진다. 사람 리뷰어가 의미 있게 읽어낼 수 있는 양을 훨씬 넘는 diff를 쏟아내므로, Git의 워크플로 전체가 그 둘레에 짜인 리뷰 단계는 안전장치에서 병목으로 바뀐다.

그 결과 설계 범위를 한참 벗어나 작동하는 시스템이 된다. 그런데도 모두가 아무것도 달라지지 않았다고 우긴다. 저장소는 여전히 돌아간다. 하지만 그를 둘러싼 프로세스는 예전의 의미를 잃는다.

실제로 가장 먼저 무너지는 것

순진한 걱정은 저장 공간이다. 알고 보면 그게 가장 사소하다. 디스크는 싸고 Git은 압축을 잘한다.

첫 번째 진짜 희생자는 리뷰다. 에이전트가 생성한 4,000줄짜리 diff를 가진 풀 리퀘스트는 이론상 리뷰 가능하고 실제로는 불가능하다. 리뷰어는 인간이 과부하 상태에서 늘 그렇듯 행동한다. 훑어보고, 요약을 믿고, 승인한다. 리뷰는 의식으로 살아남고 기능을 잃는다. 이는 리뷰를 없애는 것보다 나쁘다. 의식이 거짓된 확신을 낳기 때문이다.

두 번째 희생자는 정체성이다. Git 역사는 누가 언제 무엇을 결정했는지의 기록이다. 대부분의 커밋이 프롬프트에 반응하는 모델에 의해 작성될 때, 역사에는 여전히 이름이 남지만 그 이름은 더 이상 역사가 존재하는 이유인 질문에 답하지 못한다. 6주 전에 에이전트가 왜 어떤 방식을 택했는지 물을 수 없다. 기억하지 못하고, 커밋 메시지는 그 선택을 한 바로 그 시스템이 생성한 것이기 때문이다.

세 번째 희생자는 브랜치 자체다. 브랜치를 만드는 일은 Git에서는 싸지만 인간의 주의력에서는 비싸다. 아무도 돌볼 수 없는 속도로 브랜치가 늘어나면 아무도 붙들지 않는 의도의 적체가 생긴다. 이는 병합 충돌과는 다른 종류의 실패이며 더 보기 어렵다.

대체가 더 빠른 Git 이상인 이유

문제가 처리량이라면 해법은 더 빠른 서버일 것이다. Anthropic이 새로 무언가를 만들었다는 사실은 문제가 구조적임을 시사한다.

기계의 속도에 맞춘 변경을 위해 최적화된 버전 관리 시스템은 몇 가지 구체적인 면에서 달라 보일 것이다. 대부분의 변경이 일시적이라 만들기도 버리기도 싸야 한다고 가정할 것이다. diff를 산출물이 아니라 요약으로 취급하고, 각 변경에 기계가 읽을 수 있는 의도를 붙여 에이전트가 나중에 코드를 읽지 않고도 찾을 수 있게 할 것이다. 고고학이 아니라 검색을 위해 만들어질 것이다.

또한 Git이 답할 필요가 없었던 질문에도 답해야 한다. Git은 가치 있는 산출물이 코드의 최종 상태라고 가정한다. 에이전트 주도 워크플로에서는 가치 있는 산출물이 흔히 어떤 변경을 낳은 추론과 그것을 검증한 점검들이다. 그것들이 버전 관리 밖에 있다면 버전 관리는 역사의 절반만 기록하는 셈이다.

아무도 신경 쓰지 않다가 필요할 때 비로소 드러나는 기록

버전 관리는 단지 문서 정리 체계가 아니다. 청구, 컴플라이언스, 사고 대응의 토대다. 감사자는 누가 언제 무엇을 바꿨는지 알고 싶어 한다. 규제 산업은 리뷰를 견뎌내는 방어 가능한 기록을 원한다. 보안 팀은 커밋에서 타임라인을 재구성한다.

그 질문들에 대한 정직한 답이 에이전트가 더 이상 존재하지 않는 브랜치에서 했고 그 추론은 그 뒤 버려진 컨텍스트 윈도에 있었다는 것이 된다면 기록에는 구멍이 생긴다. 기록의 구멍은 바로 감사가 찾아내도록 만들어진 것이며, 아무도 눈치채지 못한 채 그런 구멍을 만들어내는 도구는 스캔들이 되기 훨씬 전에 이미 심각한 문제다.

더 넓은 신호

이 압박은 Anthropic만 느끼는 것이 아니다. 같은 이야기의 축소판은 이미 다른 곳에서도 보인다. GitHub는 최근 저장소 star 이력 API를 다시 만들어, 추세 데이터가 약 2,500건이 아니라 24번의 요청으로 돌아오게 했다. 무한히 늘어나는 데이터베이스 작업도, 개별 star 사용자의 노출도 필요로 하지 않는다. GitHub는 또한 맥락을 인식하는 시크릿 탐지 분류기를 출시해 실제 발견의 수용률을 11.5퍼센트 높이면서 스캔 시간 중앙값을 86퍼센트 줄였다.

둘 다 같은 근본 상황에 대한 대응이다. 세계의 코드 양이 늘고 있고, 인간이 유일한 저자이던 시절에 만들어진 도구가 늙어가기 시작했다. 시크릿 탐지는 좋은 예시다. 자격 증명 유출 위험은 작성되는 코드의 양에 비례해 커지므로, 인간의 산출 속도에서는 충분했던 시스템이 에이전트의 산출 속도에서는 불충분해진다. 설계가 전혀 바뀌지 않았는데도.

아무도 소리 내어 말하려 하지 않는 부분

이 이야기에는 AI가 소프트웨어 팀의 생산성을 극적으로 높이고 도구가 따라잡아 모두가 괜찮은 버전이 있다.

또 다른 버전에서는 생성되는 코드의 양이 그것을 이해하는 인간의 역량을 앞지르고, 업계는 결국 어느 한 사람도 전체를 파악하지 못하는 저장소를 안게 된다. 그것을 붙잡아 두는 것은 아무도 작성하지 않은 테스트와 아무도 수행하지 않은 리뷰다. 그 버전의 징후는 붕괴가 아니다. 느린 표류다. 코드베이스는 계속 돌아가고, 왜 그런지 이해하는 사람의 수는 계속 줄어든다.

그런 관점에서 Git을 교체하는 일은 주목할 만한 증상이다. 업계에서 가장 신중한 회사 중 하나가 표준 도구가 바로 정확성을 추적하는 층에서 부채가 되었다고 판단했다는 뜻이다. 이것은 작은 고백이 아니다. 소프트웨어의 인프라가 그 가정이 따라잡을 수 있는 속도보다 빠르게 바뀌도록 요구받고 있다는 신호다.

나머지 모두에게 실무적인 대응은 낭만적이지 않다. 당신의 코드 중 얼마나 많은 부분이 기계가 작성했는지 측정하라. 리뷰 단계가 여전히 무언가를 바꾸고 있는지 지켜보라. 당신의 역사가 여전히 왜에 답할 수 있는지 살펴보라. 이것들은 값싼 질문이며, 그 답은 당신에게 새 도구가 필요한지 아니면 새 습관만 필요한지를 알려줄 것이다.