앤트로픽 사이언(Scion): 깃 대신 만든 이유와 장단점, 따라 할 것

사이언(Scion)은 앤트로픽이 사내 모노레포를 깃(Git)에서 옮기려고 직접 만든 버전 관리 시스템이다. 2026년 10월 13일 엔지니어링 블로그에 소개됐다. 하루 병합이 9월에 3만건을 넘어서자, 전체 이력은 서버에만 두고 커밋·병합·리베이스까지 서버가 처리하는 "항상 온라인" 구조로 갈아탔다. 앤트로픽 스스로 엔지니어 수만 명이나 에이전트 무리가 쓰는 초대형 모노레포에서만 맞는 설계라고 선을 긋고 코드도 내놓지 않았다. 그러니 일반 팀이 지금 가져갈 것은 깃의 partial clone·sparse checkout 같은 기존 기능이다.

01 하루 병합 3만건 앞에서 깃 미러 수백 대가 버티지 못했다

원문은 병목이 코드 작성에서 개발 인프라로 옮겨 갔다는 진단에서 출발한다. Claude 가 코드를 쓰는 속도가 붙자, 사람 규모에 맞춰 만든 소스 관리·빌드·CI 가 먼저 막혔다는 것이다. 모노레포(monorepo, 회사 코드를 저장소 하나에 모아 두는 방식)의 덩치는 원문 기준으로 이렇다.

깃은 클라이언트마다 전체 이력을 가진 독립 저장소로 일하는 분산 모델이고, 오프라인 작업을 전제로 한다. 그런데 앤트로픽의 클라이언트는 거의 전부가 늘 네트워크에 붙어 있는 에이전트와 자동 작업이었다. 원문은 오프라인을 위한 설계가 오히려 확장을 가로막았다고 본다.

미러가 무너진 경위도 구체적이다. 저장소가 미러 서버의 디스크·메모리 한계를 넘어섰고, 블롭 스토리지에 둔 저장소 스냅숏(seed)은 갱신과 갱신 사이에 main 끝에서 점점 멀어졌다. partial clone 위에서 diff·blame 처럼 이력이 필요한 작업을 계속 돌리는 데도 손이 더 갔다. 병합 속도가 오를수록 미러 운영은 버거워졌다.

02 사이언은 저장소를 받아 오는 대상에서 질의하는 서비스로 바꿨다

원문이 밝힌 설계 원칙은 여섯 가지다.

1. 클라이언트는 항상 온라인이다. 전체 사본을 들고 있지 않고, 필요할 때 서버에서 가져온다.
2. 서버와 클라이언트의 일이 비대칭이다. 이력·blame·커밋 생성·병합·리베이스는 서버가 하고, 클라이언트는 크기가 제한된 객체 캐시와 작업 사본 배치, 파일 변경 감시, 서버를 편하게 다루는 사용자 쪽 도구만 맡는다.
3. 모든 질의를 API 로 연다. 로컬 저장소가 아예 필요 없는 작업이 늘었고, 자동 bisect(문제를 낸 변경을 이분 탐색으로 찾는 작업)·revert 파이프라인이 그 위에서 돈다.
4. 모든 구성 요소가 수평 확장된다. 데이터가 흩어져 있어 서버에도 전체 사본이 없고, packfile(깃이 객체를 묶어 주고받는 파일)이 없으니 저장소 유지보수 작업도 없다.
5. 커밋은 싸고, 증분이고, 잠금이 없다. 커밋·리베이스·병합이 서버에서 일어나므로 push 할 것이 없다. main 과 릴리스 브랜치 말고는 ref(브랜치·태그처럼 커밋을 가리키는 이름)를 쓰지 않도록 권한다.
6. 작업 사본은 선택이고 기본이 희소(sparse)다. CI 는 서버에 diff 를 달라고 하면 되고, 가상화 체크아웃은 실제로 읽은 파일만 디스크에 펼친다.

깃을 떼어 내면 리뷰·검색·CI 까지 개발 흐름 전체를 옮겨야 한다. 그래서 같은 기간에 코드 리뷰 도구 Antique(앤티크), 코드 검색, 소스 관리 전용 권한(IAM) 시스템을 함께 만들었다. 권한은 저장소 단위뿐 아니라 디렉터리 단위로도 걸린다. Antique 는 주석만 고친 변경과 민감한 로직 변경을 가려 승인 조건을 다르게 둔다.

03 커밋은 바뀐 파일 목록이 되고, 체크아웃은 세 겹 캐시를 지난다

체인지셋은 트리 대신 바뀐 파일만 적는다

사이언의 작업 단위는 체인지셋(changeset)이다. 선행 기록 로그(write-ahead log)의 한 항목인데, 깃 커밋과 견주면 차이가 분명하다.

ref 는 지원하지만 커밋을 만들거나 가져오는 경로에는 끼지 않는다. ref 를 옮기는 일은 구글 클라우드의 대규모 데이터베이스 Spanner 에서 행 하나를 compare-and-swap(값이 예상과 같을 때만 바꾸는 원자적 연산)으로 고치면 끝난다. 모든 서버가 합의해야 하는 전역 상태는 언젠가 확장의 걸림돌이 된다고 봤기 때문이다.

blame·경로 이력, 커밋 그래프를 건너뛰며 훑는 스킵 리스트 같은 파생 데이터는 체인지셋에서 하나의 재귀 방식으로 계산한다. 종류마다 미리 만들지 나중에 만들지 고를 수 있어서, 클라이언트를 건드리지 않고 서버 안쪽만 바꿀 수 있다. 원문은 이 모델이 메타 Sapling 의 서버 Mononoke 가 먼저 쓴 Bonsai 데이터 모델에서 왔다고 각주로 밝힌다. 초대형 모노레포 소스 관리의 선행 사례로는 구글 Piper 와 메타 Sapling 을 꼽았다.

체크아웃은 데몬, 리전 캐시, 서버 순으로 내려간다

세 계층이 같은 RPC 에 답하므로 클라이언트는 구성을 몰라도 된다. 계층 순서는 엄격히 지켜서, 리전 캐시가 죽더라도 원본 서버로 요청이 쏟아지지 않게 했다. 내용 기반 주소를 쓰니 어느 서버든 서로 조율하지 않고 캐시할 수 있다.

클라이언트 프로토콜 scn 은 루트 트리에서 출발해 없는 트리를 재귀로 요청하고, 그다음 파일 내용을 받는다. 협상 대상은 클라이언트가 원하는 트리와 blob 뿐이다. 요청을 중간에서 이어받을 수 있어서 수 GB 짜리 packfile 을 통째로 받는 일도 없다.

인프라는 200분의 1, 체크아웃은 초 단위가 됐다

원문이 글로 밝힌 효과는 네 가지다.

• 인프라(CPU·메모리)가 이전 깃 미러 구성의 200분의 1로 줄었다.
• CI·연구 작업의 체크아웃이 분 단위에서 초 단위로, 두 자릿수 배 빨라졌다.
• CI 에서만 CPU 용량 25%를 되찾았다.
• 계층마다 캐시 적중률이 99%를 넘는다.

명령별 수치는 원문에 그래프로 실렸고, 국내 개발 뉴스 모음 사이트 GeekNews 가 이를 명령별 중앙값 표로 옮겼다. 아래는 그중 일부다. 앤트로픽 사내 모노레포에서 잰 값이라 일반 깃 저장소의 기대치로 읽으면 안 된다.

04 7명이 5개월 만에 옮겼고, 사람은 거절하는 쪽을 맡았다

이전은 7명이 5개월 만에 끝냈다. 그 사이 사이언·Antique 와 관련 시스템 여섯 개 남짓을 만들었는데, 같은 기간 병합되는 코드 양은 10배로 불었다. 이전 초기의 사이언은 자체 클라이언트·저장소 형식·프로토콜이 생기기 전이라 메타데이터 질의에만 답하는 서비스였다.

구현 속도는 Claude 가 끌어올렸다. 사람이 손으로 쓴 깃→사이언 수집 파이프라인 시제품을 Claude Mythos Preview 가 별다른 지시 없이 다시 썼다. 순서 불변식은 지키면서 메모리는 20분의 1로 줄고 속도는 4배가 됐다. 인덱스를 타지 못하던 조상(ancestry) 질의의 알고리즘 개선점도 Claude 가 찾아냈다.

운영 감시는 사내 도구 Claude Tag 로 띄운 'superfan' 에이전트 몫이다. scion-daemon·scion-cache·Antique 병합 큐처럼 구성 요소 하나씩을 슬랙 채널에서 맡고, 텔레메트리와 로그를 보며 상태를 지킨다. 기존 알림을 없앤 것은 아니다. 알림은 그대로 두고, 알림이 놓치는 미묘한 이상을 에이전트가 잡게 했다.

사람의 역할은 판단으로 좁혀졌다. Claude 가 시스템 제약을 어기거나 가정뿐인 걱정으로 과하게 설계하면 거절하는 일이다. 리뷰도 모든 줄을 읽는 대신 변경의 의도를 본다. 원문은 적대적 리뷰(adversarial review)가 잘 먹히지만 시야가 좁아져 과설계로 흐를 수 있다고도 적었다.

검증은 외부 의존을 끊은 밀폐(hermetic) 시뮬레이션과 퍼징, 요청 속도 제한으로 했다. 병합 큐에서는 저장소 전역 잠금을 쓰지 않기로 하고, 대신 병합 뒤·배포 전 자동 테스트에 투자했다. 동시 변경끼리 충돌할 수는 있지만, 보통은 사람이 알아차리는 것보다 Claude 가 고치는 쪽이 빠르다는 게 원문의 설명이다.

05 장점과 단점은 같은 선택의 앞뒷면이다

GeekNews 댓글에서도 비슷한 지점이 반론으로 나왔다. 긴 기술 글만 쓰고 결과물은 내놓지 않으니 홍보에 가깝다는 지적이 있었고, Perforce 같은 기존 제품과 견준 흔적이 없다는 지적도 있었다. 하루 3만건 병합 자체가 에이전트가 같은 줄을 거듭 고치는 낭비가 아니냐는 의문, 충돌을 막지 않는 병합 모델이 안정성에 위험하다는 우려도 달렸다.

코드 공개를 두고 자주 비교된 대상은 메타 Sapling 이다. 메타는 2022년 11월 Sapling 클라이언트를 오픈소스로 내놓았고, 이 클라이언트는 기존 깃 저장소를 그대로 클론할 수 있다. 다만 그때도 Sapling 전용 서버와 가상 파일 시스템은 나중에 공개하겠다는 계획에 머물렀다.

06 '깃이 졌다'가 아니라 '병목이 옮겨 갔다'로 읽는다

이 사례에는 흔치 않은 조건 셋이 겹쳐 있다. 초대형 모노레포, 늘 온라인인 에이전트가 대부분인 클라이언트, 그리고 사내 토큰 지출이다. 토큰 지출은 다른 회사가 현실적으로 쓰려는 수준을 크게 넘는다고 원문이 스스로 밝혔다. 원문은 사이언이 범용 깃 대체재가 전혀 아니라고 못 박고, 깃 커뮤니티가 20년 가까이 해 온 확장 작업에 비하면 자기 기여는 훨씬 좁다고 적었다.

읽어 둘 신호는 병목의 이동이다. 에이전트가 코드를 쏟아내면 그다음 막히는 곳은 체크아웃·CI·병합이다. 앤트로픽은 이런 문제가 앞으로 6~12개월 사이 흔해질 것으로 본다. 어디까지나 회사의 전망이지만, 에이전트를 여럿 돌리는 팀이라면 자기 저장소에서 같은 징후가 보이는지 재 볼 만하다.

깃 쪽의 변화도 지켜볼 지점이다. 앤트로픽은 사이언을 공개하는 대신 GitHub·GitLab·오픈소스 커뮤니티와 손잡고, 깃의 전체 모델은 지키면서 사이언에서 잘 된 부분 몇 가지를 깃에 옮기고 싶다고 했다. 원문이 든 예는 포지 사이에 표준화할 수 있는 서버 쪽 RPC, 클라이언트와 다르게 동작해도 되는 깃 서버 구조, 지금과 다른 협상 프로토콜, 서로 잘 맞물리는 sparse·shallow 기능이다.

국내 기사는 원문과 함께 읽는 편이 낫다. 지디넷코리아 제목의 '공개'는 블로그 글을 공개했다는 뜻이지 소프트웨어를 배포했다는 뜻이 아니다. 이름도 '사이언'(지디넷코리아)과 '사이온'(디지털투데이)으로 갈렸지만 둘 다 영문 Scion 을 옮긴 것이다.

07 큰 저장소라면 사이언 대신 깃의 부분 복제부터 켠다

클론과 체크아웃이 몇 초 안에 끝나는 팀이라면 할 일이 없다. 사이언은 받을 수도 없고, 원문이 꼽은 문제는 그 규모에서 생기지 않는다.

저장소가 커서 클론·체크아웃이 느리다면, 사이언이 서버 쪽에서 한 일의 일부를 깃 설정으로 흉내 낼 수 있다. partial clone(--filter)은 파일 내용(blob)을 필요할 때까지 받지 않는다. --sparse 는 최상위 디렉터리의 파일만 펼친 채 시작하고, 필요한 디렉터리는 git sparse-checkout set 으로 늘린다.

# 파일 내용은 필요할 때 받고, 작업 사본은 최상위만 펼친다
git clone --filter=blob:none --sparse https://example.com/org/big-repo.git
cd big-repo

# 필요한 디렉터리만 더 펼친다(cone 모드가 기본)
git sparse-checkout set services/api libs/common

설정을 한 번에 맞추고 싶다면 깃에 딸린 대형 저장소 도구 Scalar 가 있다. scalar clone 은 기본으로 커밋·트리 객체만 받고, sparse checkout 과 백그라운드 유지보수를 켠다. 작업 트리는 기본으로 <디렉터리>/src 아래에 놓이며, --no-src 를 주면 그 디렉터리에 바로 놓인다.

scalar clone --branch main https://example.com/org/big-repo.git big-repo

2026년 10월 공식 문서 기준으로 한계도 적혀 있다. partial clone 은 빠진 객체를 그때그때 하나씩 받아 오는 경로가 느리다. checkout 은 필요한 blob 을 한 번에 미리 받지만 모든 명령이 그렇지는 않다. 원문도 미러 시절 partial clone 위에서 diff·blame 을 유지하기가 까다로웠다고 적었다. git sparse-checkout 은 실험 단계로 표시돼 있고, 패턴을 직접 쓰는 non-cone 모드는 폐기 예정이니 디렉터리 단위 cone 모드를 쓰면 된다.

에이전트를 여럿 돌린다면 위 표의 마지막 줄, 변경 하나가 소스 관리에 쓰는 시간 합계를 우리 팀 지표로 빌려 올 만하다. 원문은 이 합계가 어떤 작업으로 이뤄졌는지 글로 풀지 않았으니, 가져오기·체크아웃·리베이스·CI 체크아웃처럼 소스 관리를 기다리는 시간을 직접 골라 더하면 된다. 코드 생성이 빨라졌는데 이 합계가 그대로라면, 다음에 손볼 곳은 모델이 아니라 저장소와 CI 쪽이다.

08 자주 묻는 질문

사이언을 내려받아 써 볼 수 있나?

아니오. 원문 기준 공개 계획이 없고, 대신 설계 아이디어를 GitHub·GitLab·오픈소스 커뮤니티와 나누겠다고 했다.

기존 깃 저장소나 깃 명령과 호환되나?

원문에는 깃 호환 계층 언급이 없고, 깃과 크게 갈라진 맞춤형 시스템이라고만 밝힌다. 기존 깃 저장소를 그대로 클론하는 클라이언트를 공개한 메타 Sapling 과는 이 점이 다르다.

'사이온'이라고 쓴 기사와 같은 시스템인가?

예. 영문 이름 Scion 을 매체마다 '사이언'과 '사이온'으로 다르게 옮겼다.