AI가 코드를 너무 많이 써서, 결국 그 코드를 보관하는 도구까지 새로 만들었다고 합니다. 익숙한 Git을 갈아엎었다니 “이제 Git도 끝인가?”라는 반응이 나올 만합니다. 그런데 정작 만든 회사는 일반적인 Git 대체재로 적합하지 않다고 선을 긋습니다.
이 이야기의 주인공은 Claude 자체가 아니라 Anthropic의 사내 버전 관리 시스템 Scion입니다. 회사는 Claude를 활용해 개발했고 사내 통합 저장소를 옮겼다고 공식 엔지니어링 글에서 밝혔습니다. 버전 관리란 코드의 변경 이력을 남기고 여러 작업을 합치는 일입니다. Git은 그 도구이고, GitHub는 Git 저장소를 중심으로 협업하는 서비스이므로 둘을 한 제품처럼 읽으면 이야기부터 꼬입니다.
사내에서는 대체했는데, 우리에게는 대체재가 아니라는 말. 모순처럼 보이는 이 문장이 이번 사건의 핵심입니다. Scion을 이해하려면 AI가 얼마나 빨리 쓰는지에 앞서, 작은 수정 하나를 처리하기 위해 주변 시스템이 얼마나 많은 일을 반복하는지를 봐야 합니다.
하루 3만 건이라는 숫자에서 빠지기 쉬운 것
Anthropic의 집계는 5월 하루 약 2,500건에서 9월 3만 건 이상으로 늘어난 병합된 코드 변경입니다. 코드 줄 수나 제품 배포 횟수가 아닙니다. 공식 글은 CI의 코드 체크아웃도 하루 약 2,500만 회라고 설명합니다. CI는 변경을 자동으로 빌드하고 검사하는 과정이고, 체크아웃은 검사할 버전의 파일을 작업 공간에 준비하는 일입니다. 공식 집계와 배경
커밋은 변경을 기록한 단위이고, 병합은 그 작업을 다른 흐름에 합치는 일입니다. 작업자가 임시로 남긴 기록의 수, 최종적으로 합쳐진 변경의 수, 사용자에게 출시한 기능의 수는 서로 다릅니다. “하루 3만 커밋”이라는 짧은 제목만 읽고 하루 3만 개의 기능을 완성했다고 받아들이면 과장됩니다.
한 번의 주문 화면 수정도 생각해 볼 수 있습니다. 버튼 문구를 바꾸고, 계산 오류를 고치고, 검사를 추가하는 작업을 하나로 묶을 수도 있고 여러 변경으로 나눌 수도 있습니다. 따라서 변경 수가 늘었다는 사실만으로 가치 있는 기능이 같은 비율로 늘었다거나, 코드가 그만큼 나빠졌다고 결론 내릴 수는 없습니다. 이 수치가 직접 보여 주는 것은 저장·검사·협업 시스템에 들어오는 작업량입니다.
또 하나의 자극적인 숫자는 하루 600PB 이상입니다. 원문은 최적화 없이 단순하게 가져올 경우의 가정으로 제시합니다. 실제로 매일 그만큼 전송했다는 실측값으로 인용하면 틀립니다. 회사는 미러와 부분 복제 같은 방법도 이미 사용했다고 설명합니다. 원문의 조건
숫자의 무서움은 단위와 조건을 떼었을 때 커집니다. 이번에는 그 조건을 붙였을 때 문제가 더 선명해집니다. 작은 작업을 아주 많이 시작하는 환경에서는, 작업 자체보다 준비를 반복하는 비용이 커질 수 있습니다.
버튼 하나 고치는데 창고가 따라오는 문제
주문 화면의 “결제하기” 문구만 수정하는 AI 작업을 가정해 보겠습니다. 작업에 필요한 것은 관련 파일과 검사입니다. 그런데 자동 작업이 시작될 때마다 큰 저장소를 받고, 파일을 펼치고, 이력을 준비한 뒤에야 수정한다면 어떨까요. 수정 시간을 줄여도 앞단의 대기는 그대로 남습니다.
Git의 장점은 내 컴퓨터에 이력이 있으면 서버와 계속 통신하지 않고도 많은 작업을 할 수 있다는 것입니다. Git 공식 설명은 대부분의 작업이 로컬에서 이루어진다는 점을 강조합니다. 네트워크가 불안정해도 이미 가진 이력을 살피고 변경을 기록할 수 있는 성질은, 사람이 노트북으로 일할 때 실용적입니다.
여기서 “Git은 매번 모든 파일과 역사를 통째로 받아야 한다”로 단순화하면 안 됩니다. 공식 clone 문서에는 과거 이력의 범위를 줄이는 shallow clone과 필요한 객체만 받는 partial clone이 있습니다. sparse checkout은 작업 공간에 펼칠 파일 범위를 줄이는 기능입니다. 내려받는 데이터와 디스크에 펼치는 파일은 관련되지만 같은 조절 손잡이는 아닙니다.
앞의 주문 화면 예시로 돌아가면, 먼저 물을 것은 “Git을 무엇으로 바꿀까”가 아닙니다. 새 작업이 기존 자료를 재사용하는지, 검사에 필요하지 않은 폴더까지 받는지, 과거 이력을 어디까지 요구하는지입니다. 문구 한 줄을 바꿀 때 생기는 지연과 서버 전체를 바꿀 때 생기는 지연도 구분해야 합니다.
이 관점은 비개발자에게도 낯설지 않습니다. 문서 한 장의 오탈자를 고치려고 매번 회사 자료실 전체를 복사한다면, 타이핑 속도를 높이는 것만으로는 해결되지 않습니다. 다만 실제 Git은 이미 복사량을 줄이는 수단을 갖고 있으므로, 이 비유를 Git의 필수 동작으로 받아들이지는 않아야 합니다.
Scion의 답은 서버에 더 많이 맡기기
Scion은 커밋·병합·이력 조회를 서버에서 처리하고, 필요한 파일은 요청해서 받는 쪽으로 설계했습니다. 파일이 필요 없는 작업은 API로 질문할 수 있습니다. 클라이언트가 항상 온라인이라는 전제입니다. Scion의 설계 원칙
주문 화면 예시에서는 두 요청을 나눠 보면 이해하기 쉽습니다. “버튼 문구를 바꿔 줘”에는 실제 수정할 파일이 필요합니다. 반면 “이 문구를 마지막으로 바꾼 변경을 찾아 줘”에는 이력 정보가 필요합니다. 두 번째 요청을 처리하는 도구까지 매번 별도의 작업용 저장소를 준비해야 하는지 되묻는 것입니다. 아래 그림은 같은 요청을 처리하는 과정을 위쪽 Git과 아래쪽 Scion의 세 단계로 정리한 개념 예시입니다. 파일을 수정하는 일과 그 변경을 기록·조회하는 일이 어디에서 이루어지는지 구분해서 보면 됩니다.
changeset에는 무엇을 남길까
Scion이 한 번의 변경을 기록하는 단위는 changeset입니다. 아래 공식 그림에서는 위쪽의 변경 기록과 아래쪽의 파일 내용이 나뉘어 있습니다. 먼저 가운데의 file_changes와 그 아래로 내려가는 주황색 선을 보면 됩니다. 공식 자료의 데이터 구조 설명
그림은 세 부분으로 읽을 수 있습니다.
- 누가, 어떤 변경 다음에 작성했는가: 위쪽
author는 작성자,parents는 앞선 변경을 가리킵니다. 파일 내용과 구분되는 기록 정보입니다. - 어떤 파일이 달라졌는가:
file_changes에는 파일 경로와 내용의 식별자가 있습니다. 그림의docs/guide.md는 아래쪽에 따로 보관된 내용을 가리키고,src/legacy.rs의Deleted는 삭제를 뜻합니다. 이 목록은 첫 번째 부모 변경과 비교해 달라진 파일을 기록합니다. - 실제 내용은 어디에 있는가: 아래쪽
Cloud Storage에 압축된 파일 내용이 있습니다. 내용을 바탕으로 만든 식별자, 즉 해시로 구분하며 같은 내용은 중복 저장을 줄일 수 있습니다.
주문 화면의 버튼 문구를 바꾸는 예시라면, 변경 기록에는 바뀐 파일과 새 내용의 참조를 남긴다고 이해할 수 있습니다. 다만 이를 “Git은 수정할 때마다 모든 파일을 다시 복사하고, Scion만 바뀐 파일을 저장한다”로 읽으면 틀립니다. Git도 바뀌지 않은 파일은 기존 내용을 재사용합니다. 비교할 지점은 매번 전체를 복사하느냐가 아니라, 변경 기록을 구성하고 필요한 조회 자료를 만드는 방식입니다.
아래쪽 점선의 Root tree도 중요한 단서입니다. 원문은 디렉터리 구조와 파일 이력처럼 변경 목록만으로 바로 답하기 어려운 정보를 서버가 파생해 만든다고 설명합니다. 버튼 문구를 고친 기록을 남기는 일과 “누가 마지막으로 바꿨나”를 빠르게 찾는 일은 같은 작업이 아닙니다. 기록을 작게 만든다고 모든 조회가 저절로 빨라지는 것은 아니므로, 조회에 맞는 자료도 별도로 설계한 것입니다.
checkout은 가까운 캐시부터 찾는다
변경 기록이 작아도 검사할 파일을 받아 오는 비용은 남습니다. 다음 공식 구조도는 그 파일을 가져오는 경로를 보여 줍니다. 위쪽 회색 선과 가운데 주황색 선을 구분해 보면 복잡한 그림이 조금 단순해집니다. 공식 checkout 구조 설명
회색 경로는 변경을 관리하는 일입니다. 브랜치·이력 조회나 커밋 같은 요청이 scion-server로 갑니다. 오른쪽 Spanner는 변경 기록 등을, Cloud Storage는 파일 내용을 보관하는 쪽입니다.
주황색 경로는 작업에 쓸 파일을 받는 일입니다. 왼쪽 아래 CI 작업에서 시작해 따라가면, 먼저 같은 컴퓨터 안의 요청을 모아 처리하는 scion-daemon을 만납니다. 그곳에 없는 데이터는 지역 단위의 scion-cache에 요청하고, 거기에도 없을 때 상위 서버를 찾습니다. 그림의 Misses가 바로 이 ‘없는 경우’입니다. 개발자 컴퓨터의 경로는 그림처럼 지역 캐시로 직접 이어집니다.
주문 화면 검사가 같은 코드 버전으로 여러 번 실행되는 상황을 떠올려 보겠습니다. 각 작업이 필요한 파일을 요청하더라도, 가까운 곳에 이미 같은 내용이 있다면 그 사본을 재사용할 수 있습니다. 이 경로에서 중요한 것은 AI가 파일을 더 빨리 읽는 마법이 아니라, 같은 내용을 먼 저장소에서 반복해서 가져오는 일을 줄이는 구조입니다. 그림 아래의 주기적 스냅샷은 새 노드의 초기 자료를 채우는 역할을 합니다.
따라서 중앙에서 처리한다는 말과 물리적 서버 한 대가 모든 요청을 처리한다는 말은 다릅니다. 관리 기능은 서버에 맡기면서 파일 전송은 여러 캐시 계층으로 나눌 수 있습니다. 반대로 이런 구조를 갖추려면 서버와 캐시의 장애도 다뤄야 합니다. Scion은 클라이언트가 항상 온라인이라는 전제를 받아들이는 대신 각 작업 공간의 부담을 줄이는 선택입니다. 노트북의 독립성과 대량 자동 작업의 가벼움이 언제나 같은 방향은 아닙니다.
“복잡해진 SVN 아닌가요?”라는 반응의 절반
커뮤니티에서는 서버 중심의 작업 방식을 두고 **“단계가 더 붙은 SVN 같다”**는 취지의 농담도 나왔습니다. Subversion, 흔히 SVN이라고 부르는 중앙집중식 버전 관리 도구를 떠올린 것입니다. 흥미로운 이유는 간단합니다. 오랫동안 로컬·분산의 장점을 배워 왔는데, AI 시대의 새 설계는 다시 서버에 일을 모으는 것처럼 보이기 때문입니다.
그렇다고 “AI가 오래된 도구를 다시 발명했을 뿐”이라고 끝내면 중요한 맥락을 놓칩니다. Google은 2016년 논문에서 자체 대형 통합 저장소의 운영을 다뤘습니다. Meta의 Sapling 공식 문서 역시 대형 저장소를 위한 설계와, 기업의 상시 온라인 환경에 맞춘 선택을 설명합니다. 큰 조직이 자기 규모에 맞는 버전 관리 체계를 만든 일 자체는 처음이 아닙니다.
새 도구 자체보다 얼마나 빨리 만들고 전환했는지가 흥미롭다는 의견도 있었습니다. 이 관점이라면 기사의 질문도 달라집니다. “Git을 이겼는가”보다 “맞춤형 기반 시스템을 만들고 옮기는 비용이 얼마나 바뀌었는가”를 봐야 합니다. 새 도구를 만들기 쉬워져도, 기존 작업을 안전하게 옮기는 어려움까지 자동으로 사라지는 것은 아닙니다.
더 날카로운 반론도 있었습니다. **“왜 그렇게 많은 체크아웃이 필요한가. 이미 코드가 있는 곳에서 검사하면 안 되나?”**라는 질문입니다. 이 질문은 일반 팀이 바로 가져갈 만합니다. 병목을 없애는 방법에는 더 빠른 도구로 교체하는 것뿐 아니라, 같은 일을 덜 반복하는 방법도 있습니다. 이런 반응만으로 특정 설계의 승패를 가릴 수는 없지만, 발표에서 다시 따져 볼 지점은 찾을 수 있습니다.
‘아직 못 만든다’와 ‘범용으로 맞지 않는다’의 차이
공식 설명은 Scion이 일반적인 용도의 Git 대체재로 적합하지 않다고 명시합니다. 조금만 더 기다리면 모두가 갈아탈 미완성 Git 후계자라는 의미와는 다릅니다. 공식 설명의 마지막 절
회사는 코드 리뷰·검색·CI까지 함께 맞춰야 한다고 설명합니다. 개발에는 7명으로 이뤄진 팀이 참여했고, 관련 시스템 구축과 전환에 5개월이 걸렸다고 밝혔습니다. 이를 “Claude가 혼자 Git을 없앴다”로 줄이면 사람이 정한 목표와 전환 작업이 사라집니다. 이 글은 공개 설치법을 안내하는 제품 출시문보다 사내 전환 사례로 읽어야 합니다. 개발 과정과 적용 범위
주문 도구를 만드는 작은 팀이 같은 선택을 한다면 비교 대상은 새 버전 관리 도구의 속도 하나가 아닙니다. 지금 쓰는 코드 리뷰, 자동 검사, 권한 설정, 장애 대응, 다른 사람의 참여 방식까지 옮기는 비용을 합쳐야 합니다. 버튼 수정이 몇 초 빨라져도 그 대가로 운영할 기반 시스템이 크게 늘어난다면 전체적으로는 손해일 수 있습니다.
또 3만 건이 합쳐졌다는 기록은 그 변경들이 사용자에게 좋은 결과를 냈다는 품질 평가가 아닙니다. 무엇을 만들었는지, 검사가 무엇을 놓치는지, 문제가 생겼을 때 어떻게 되돌리는지가 별도로 필요합니다. “AI가 많이 작성한다”와 “그대로 많이 받아도 된다” 사이에는 사람과 조직이 정해야 할 기준이 남습니다.
내 프로젝트에서는 무엇부터 볼까
앞의 주문 화면 수정으로 돌아가 보겠습니다. 문구를 고치는 데 오래 걸렸다면, 작업 기록을 세 구간으로 나눠 볼 수 있습니다. 코드를 준비한 시간, 수정하고 검사한 시간, 검토를 기다린 시간입니다. 이 구분은 도구를 교체하기 전에 원인을 찾기 위한 방법입니다. 병합 건수만으로 어느 구간이 문제인지는 알 수 없습니다.
파일을 준비하는 시간이 길면 복제 범위와 재사용을, 수정 뒤 검사에 오래 머물면 검사 대상을, 사람이 판단을 못 내려 대기하면 요구사항과 승인 기준을 먼저 봅니다. Git 교체는 이 중 첫 번째 문제의 일부를 겨냥하는 큰 선택입니다. 다른 구간이 느린데 도구 이름부터 바꾸면, 대기하는 장소만 옮길 수 있습니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 작은 프로젝트 | Git을 유지하고 작업을 작게 나누기 | 작업 공간 준비가 병목이 아니라면, 되돌릴 수 있는 변경과 이해할 수 있는 검토 단위를 먼저 만듭니다. | 버튼 문구 수정과 결제 계산 변경을 구분합니다. |
| 자동 작업이 많은 팀 | 받는 양과 반복 횟수부터 보기 | 저장소 준비에 시간이 몰린다면 shallow·partial clone, sparse checkout, 캐시 재사용의 적용 조건을 검토합니다. | 이미 가진 자료를 새 작업마다 다시 받는지 확인합니다. |
| 대형 사내 기반 시스템 | 전환 뒤 운영할 것까지 계산하기 | 새 체계를 검토할 때는 리뷰·검색·CI·권한·복구를 포함한 전체 비용과 온라인 의존을 비교합니다. | 빠른 병합 외에 장애와 잘못된 변경을 어떻게 다룰지도 정합니다. |
Scion이 흥미로운 이유는 Git을 당장 버릴 이유를 줘서가 아닙니다. 코드 작성이 빨라졌을 때 무엇이 다음 병목이 되는지를 드러내기 때문입니다. Anthropic은 자기 환경에서 교체를 택했습니다. 우리의 판단은 자기 작업이 실제로 어디서 기다리는지에서 시작해야 합니다. 이번 이야기에서 가장 가져갈 만한 습관은 새 도구의 이름을 외우는 것보다, 작은 수정 하나가 통과하는 전체 경로를 보는 일입니다.
VIEW—
