코드를 쓰는 속도가 더는 개발의 병목이 아니게 되면, 그다음 병목은 어디로 옮겨갈까. 앤트로픽은 그 질문에 대한 답을 자사 사례로 내놓았다. 사람이 코드를 짜던 시절에 맞춰 설계된 소스 관리, 빌드, CI 같은 개발 인프라가 이제 가장 큰 제약이 됐다는 것이다. 회사가 공개한 수치는 변화의 규모를 분명하게 보여준다. 2026년 5월 하루 평균 약 2,500건이던 코드 병합이 9월에는 하루 3만 건을 넘어섰다. 1년도 아닌 몇 달 사이에 열 배 이상 늘어난 셈이고, 앤트로픽은 이 증가세가 당분간 꺾이지 않을 것으로 본다. 병목을 하나 제거할 때마다 생산되는 코드량이 곧바로 늘어나기 때문이다.
이 폭증의 원인이자 해결 수단은 모두 클로드였다. 클로드가 연구 루프를 자율적으로 반복하고 서비스를 처음부터 구축하면서 병합량이 폭발했고, 동시에 그 속도 덕분에 앤트로픽은 자체 버전 관리 시스템 '사이언(Scion)'을 만들어 다섯 달 만에 모노레포 전체를 깃에서 이전할 수 있었다. 같은 기간에 코드 리뷰 도구 '앤틱(Antique)', 코드 검색, 소스 관리용 IAM 체계 등도 함께 구축했다. 회사는 대부분의 조직이 당장 이런 문제를 겪지는 않겠지만, AI 코딩 도구를 쓰는 곳이라면 머지않아 같은 압박점에 도달할 것이라고 전망한다.
깃의 장점이 오히려 발목을 잡았다
깃은 분산형 시스템이다. 복제본 하나하나가 완전한 저장소여서 오프라인에서도 diff와 이력 조회, 임의 리비전 체크아웃이 가능하다. 대다수 저장소에는 이것이 올바른 설계이고, 깃이 표준이 된 이유이기도 하다. 그러나 앤트로픽의 모노레포는 이 설계 공간을 벗어났다. 메인 브랜치 이력만 약 100GB에 달하고 압축한 작업 복사본도 25GB를 넘는다. CI를 위한 코드 체크아웃만 하루 약 2,500만 건이며, 개발 환경과 에이전트 샌드박스, 연구 작업은 아직 세지도 않은 수치다. 이를 순진하게 전부 받아오면 하루 600PB가 넘는 깃 트래픽이 발생한다. 얕은 복제, 희소 체크아웃, 내부 미러 등 알려진 모든 우회책을 동원해 한때 수백 개의 내부 깃 미러를 운영했지만, 병합 속도가 오르면서 운영 부담만 커졌다.
핵심 통찰은 여기에 있었다. 앤트로픽의 클라이언트는 사람이 아니라 거의 전부가 상시 온라인 상태인 에이전트와 작업들인데, 정작 깃을 하나의 권위 있는 복사본을 두는 중앙집중형처럼 쓰고 있었다는 것이다. 오프라인과 분산 작업을 뛰어나게 만들어 주던 깃의 특성이, 저장소가 커질수록 확장성을 오히려 갉아먹고 있었다. 그래서 '에이전트는 항상 온라인'이라는 전제에서 처음부터 다시 설계하면 어떤 모습일까를 물었고, 그 답이 사이언이다. 구글의 파이퍼(Piper)와 메타의 새플링(Sapling) 같은 선행 사례의 교훈도 반영됐다.
클라이언트는 묻고, 서버가 계산한다
사이언의 설계 원칙은 몇 가지로 요약된다. 클라이언트는 항상 온라인이므로 필요한 데이터만 그때그때 가져온다. 클라이언트와 서버의 역할은 비대칭이다. 커밋 생성, 병합, 리베이스, 파일 이력과 blame 계산은 모두 서버가 맡고, 클라이언트는 제한된 로컬 캐시와 작업 복사본 배치, 파일 변경 감시 정도만 담당한다. 로컬에서 계산하는 것은 거의 없지만 그만큼 필요한 데이터도 적다. 모든 소스 관리 질의가 API로도 노출되기 때문에, 다수의 CI 작업과 도구는 로컬 저장소 없이도 돌아간다. 자동 bisect나 revert 파이프라인 같은 내부 도구가 대규모로 실용화된 것도 이 값싼 프로그래밍 접근 덕분이다.
확장성 측면에서는 모든 구성 요소가 수평 확장 가능하도록 설계됐다. 저장소 데이터는 분산되어 있으며, 서버에조차 완전히 구체화된 복사본이 존재하지 않는다. 깃의 팩파일에 해당하는 것이 없어 저장소 유지보수 작업도 필요 없다. 커밋은 값싸고 점진적이며 잠금이 없어야 한다는 원칙에 따라, 모든 커밋과 병합이 서버에서 일어나므로 push 과정 자체가 사라진다. 커밋 생성 비용은 저장소 전체 크기가 아니라 변경 크기에 비례하도록 맞췄다. 작업 복사본은 선택 사항이며 기본적으로 희소하다. 필요한 디렉터리만 담는 희소 체크아웃과 요청 시점에 파일을 구체화하는 가상 체크아웃을 중심으로 프로토콜이 짜여, 작업이 실제로 읽은 만큼만 비용을 치른다.
내부 구조에서 작업 단위는 '체인지셋(changeset)'으로, 쓰기 선행 로그의 한 항목이다. 깃 커밋이 트리 포인터를 저장하는 것과 달리, 체인지셋은 첫 부모를 기준으로 바뀐 파일 목록과 블롭 저장소 내 압축 콘텐츠를 가리키는 콘텐츠 주소 지정 포인터를 담는다. 팩파일도 잠금도 ref 이동도 없어 매우 높은 처리량으로 체인지셋을 받아들일 수 있다. 누가 어느 줄을 마지막으로 고쳤는지 같은 질문에 답하기 위한 blame, 경로 이력, 커밋 그래프용 스킵 리스트 등은 체인지셋에서 파생해 만드는 '파생 데이터'로, 부모의 값으로부터 재귀적으로 계산하는 단일 메커니즘으로 처리한다. 덕분에 새로운 데이터 구조를 쉽게 추가하고, 즉시 계산할지 미룰지 고를 수 있으며, 클라이언트를 건드리지 않고 내부를 최적화할 수 있다.
실제 배포 구조는 계층형 캐시를 닮았다. 모든 소스 관리 데이터가 콘텐츠 주소 지정 방식이어서 한 번 저장된 데이터는 바뀌지 않고, 어떤 서버든 다른 서버와 확인 없이 캐싱할 수 있다. 노드 안에서는 scn 클라이언트가 소켓으로 노드 전체 객체를 보관하는 scion-daemon과 대화하고, 데몬은 지역 내 트리·블롭 캐시 서버인 scion-cache와만 통신한다. 캐시 서버는 데몬이 그대로 소비할 디스크 포맷으로 메모리에서 객체를 스트리밍해, 델타 압축이나 누락 객체 계산에 시간을 쓰지 않는다. 캐시에 없는 객체는 권위 서버인 scion-servers가 Spanner나 클라우드 스토리지에서 읽어 채운다.
한국 실무자 입장에서 이 사례의 함의는 분명하되 한계도 뚜렷하다. 앤트로픽은 자신들의 워크로드가 극단적으로 이례적임을 거듭 강조한다. 100GB 이력에 하루 수천만 건의 체크아웃이라는 규모는 대부분의 조직과 무관하고, 대다수 저장소에는 여전히 분산형 깃이 정답이다. 다만 '클라이언트가 사람인가 에이전트인가'라는 전제를 다시 묻는 접근 방식 자체는 되새길 만하다. 당장 자체 VCS를 만들 일은 없더라도, 오프라인·완전 복제를 가정한 기존 도구가 상시 온라인 자동화 앞에서 어디서부터 삐걱대는지를 미리 점검해 두는 것은 의미가 있다. 소스 관리는 그 압박이 가장 먼저 드러난 한 지점일 뿐이기 때문이다.