앤트로픽 사이언, 하루 병합 3만 건에 깃을 바꾼 이유

앤트로픽 모노레포는 왜 깃으로 버티지 못했나

깃은 분산형이다. 모든 복제본이 저장소 전체를 들고 있어 인터넷이 끊겨도 이력·blame(줄별 마지막 수정자)·diff를 혼자 계산한다. 대부분의 저장소에는 이 설계가 맞다. 앤트로픽은 이 전제가 자기 모노레포에서는 거꾸로 짐이 됐다고 설명한다.

결정적인 관찰은 따로 있었다. 깃을 쓰면서도 실제로는 권위 있는 사본 하나를 두는 중앙집중식으로 쓰고 있었고, 클라이언트 대부분은 정의상 늘 온라인인 에이전트와 작업이었다. 오프라인 작업을 위한 깃의 장점이 오히려 확장을 막고 있었다는 것이다.

아래 환산기로 숫자 감각을 잡아 볼 수 있다. 체크아웃 횟수와 사본 크기를 바꾸면 "통째로 받는" 방식의 하루 트래픽이 어떻게 커지는지 보인다.

체크아웃마다 작업 사본 전체를 새로 받는다고 가정한 단순 어림이다. 캐시·부분 체크아웃·압축 차이를 반영하지 않은 추정치다. 기본값은 앤트로픽이 밝힌 CI 체크아웃 하루 2,500만 회와 압축 작업 사본 25GB다.

사이언은 깃과 무엇이 다른가

사이언의 기본 단위는 쓰기 선행 로그(write-ahead log)에 쌓이는 체인지셋이다. 깃 커밋이 트리 전체를 가리키는 것과 달리, 체인지셋은 첫째 부모 대비 바뀐 파일 목록과 그 내용의 주소만 담는다. 그래서 받아들일 팩파일도, 서버끼리 맞출 잠금도, 옮길 ref(브랜치·태그 포인터)도 없이 아주 빠르게 쌓인다.

blame이나 경로 이력처럼 체인지셋만으로는 바로 답하기 어려운 질문은 "파생 데이터"로 따로 계산한다. 부모의 값에서 자식의 값을 구하는 재귀 방식 하나로 모든 종류를 만들고, 필요하면 미리 계산하거나 미뤄 둔다.

체크아웃 경로도 다르다. 클라이언트는 "내가 무엇을 가졌는지" 서버에 알리지 않고, 뿌리 트리부터 자기에게 없는 트리와 블롭만 하나씩 요청한다. 요청 대상이 바뀌지 않는 객체라 어느 캐시든 답할 수 있다. 수 기가바이트짜리 팩파일 응답이 없으니 끊겨도 이어 받을 수 있다.

사이언 이전 뒤 숫자로 보면 얼마나 달라졌나

각 캐시 층은 적중률 99% 이상을 유지하고 오래 쥐고 있는 상태가 없어 필요하면 그대로 늘릴 수 있다고 앤트로픽은 밝혔다. 클라이언트도 캐시도 저장소 정리 작업(gc·repack)을 할 필요가 없다.

효과의 상당 부분은 체크아웃을 아예 하지 않는 것에서 나왔다. 커밋과 병합 기준점 사이의 diff가 필요한 CI 작업은 서버에 물어보면 되고, 쓰기 작업도 상당수는 API만으로 끝난다. 자동 bisect(문제 커밋 찾기)와 자동 되돌리기 파이프라인은 이런 값싼 조회가 없었다면 규모 있게 돌리기 어려웠다고 설명한다.

7명과 클로드는 사이언을 어떻게 나눠 만들었나

팀은 7명이다. 이들이 5개월 동안 사이언과 리뷰 도구 안티크, 코드 검색, 소스 권한 관리 시스템까지 만들고 이전을 마쳤다. 그사이 하루 병합량은 10배로 늘었다. 앤트로픽은 "예전이라면 훨씬 많은 엔지니어가 몇 년에 걸쳐 옮겼을 일"이라고 적었다.

작업 분담에 대한 원문의 표현은 이렇다. 이 시스템을 만든 엔지니어 모두가 코드 작성은 클로드가 자신보다 낫다고 평가한다. 사람은 시스템 사이의 큰 구조와 설계상의 맞교환을 정했다. 리뷰는 지금도 사람이 모든 변경에 하지만, 한 줄씩 읽기보다 변경의 의도를 본다.

"안 된다"가 필요했던 장면도 적었다. 변경이 언제 main에 병합됐는지 알아내려고 리뷰 도구에 묻는 대신 커밋 로그를 처음부터 훑는 시스템이 여럿 있었고, 적대적 리뷰(adversarial review)가 가상의 우려를 키워 다른 사내 서비스를 과하게 의심하는 검증 코드가 붙기도 했다. 이런 과잉 설계를 걷어 내는 것이 사람의 몫이었다.

반대로 클로드 덕에 더 잘된 것도 있다. 사람이 손으로 쓴 깃 → 사이언 취입 파이프라인 첫 판을 내부 초기판 클로드 미토스 프리뷰에게 "다시 써 달라"고만 하자 메모리는 20배 적게, 속도는 4배 빠른 판이 나왔다. 앤트로픽은 사이언이 "가장 잘 시험된 코드베이스 중 하나"라며, 빠듯한 일정에도 인프라 상호작용 전부를 밀폐된 시뮬레이션으로 재현하고 퍼징까지 붙였다고 했다.

운영에서는 사내 슬랙용 클로드 태그를 썼다. 부품 하나의 건강만 들여다보는 채널을 만들어 클로드에게 맡기고 이를 "슈퍼팬"이라 부른다. scion-daemon 슈퍼팬, scion-cache 슈퍼팬, 안티크 병합 큐 슈퍼팬이 텔레메트리와 로그를 보며 일반 경보가 놓치는 이상을 잡는다는 설명이다.

병합 큐도 다시 생각했다. 테스트가 도는 사이 수백, 수천 건이 병합되는 규모에서는 업계 표준인 저장소 전역 잠금을 재현하지 못했고, 대신 병합 뒤 · 배포 전 자동 테스트에 투자했다. 동시 변경이 충돌할 수 있지만 클로드가 사람이 알아채기도 전에 고친다는 것이 앤트로픽의 설명이다.

사이언 발표 뒤 "AI가 코드를 늘렸나, 소프트웨어를 늘렸나" 논쟁

사이언 글은 해커뉴스에서 245점 · 댓글 216개를 받았다. 같은 날 해커뉴스 상위에는 "AI는 도구이고 잘 쓰려면 기술이 필요하다"는 글이, 로브스터스에는 "새롭고 좋은 소프트웨어는 다 어디 있나"가 함께 올랐다.

점수와 댓글 수는 이 글을 요청받은 시점에 수집된 값이고 계속 바뀐다. 직접 다시 확인하지는 못했다.

Huahai의 글은 리치 히키가 10월 11일 쓴 "AI는 도구가 아니다"에 대한 반론이다. 사람이 설명을 요구하고, 검증하고, 거부하고, 다시 시키는 되먹임을 이끌 수 있으니 LLM은 여전히 도구이고 그래서 쓰는 기술이 중요하다는 주장이다. "통제하기 어렵거나 오용하기 쉽다고 도구가 도구 아닌 것이 되지는 않는다"는 문장이 대표적이다.

메이비스의 글은 반대쪽 질문을 던진다. 버그가 줄고 성능이 좋아지는 식의 개선은 이미 나타나지만, 상당수는 개인용 비공개 소프트웨어로 흩어져 밖에서 보이지 않고, "소프트웨어를 더 좋게 만들기보다 더 많이 만들고 있다"는 것이다.

사이언은 두 질문 사이에 놓인다. 하루 병합이 12배로 늘었다는 숫자는 "코드가 늘었다"의 증거다. 다만 그 코드를 감당하려고 새로 만든 것이 버전 관리 · 리뷰 · CI 같은 개발 기반이었고, 앤트로픽 스스로 "병목을 하나 없앨 때마다 코드 양이 곧바로 더 늘어난다"고 적었다.

깃을 쓰는 팀은 사이언에서 무엇을 가져가면 되나

앤트로픽은 이런 문제가 앞으로 6~12개월 안에 더 흔해질 것으로 본다. 깃허브 · 깃랩 · 오픈소스 공동체와 함께 풀겠다며, 깃 모델을 떠나지 않고도 서버 쪽에서 가져갈 수 있는 생각을 제시했다.

우리 팀 저장소에서 같은 압력이 오고 있는지 보는 신호를 골랐다. 체크 상태는 이 브라우저에만 남는다.