Anthropic이 Git을 버리고 자체 소스 컨트롤 Scion을 만든 이유 (번역)
원문: https://simonwillison.net/2026/Oct/13/redesigning-source-control-at-anthropic/
하루 머지 건수가 10배 넘게 늘면서 소스 컨트롤이 개발의 가장 큰 병목이 됐다. 여기서는 5개월 만에 자체 버전 컨트롤 시스템으로 이전한 과정을 공유한다.
Anthropic에서 코딩은 더 이상 시스템을 만들거나 연구를 하는 데 병목이 아니다. Claude는 연구 루프를 독자적으로 반복하고, 복잡한 프로그램을 미세 최적화하고, 새 서비스를 처음부터 다시 만들어낸다. 그 속도와 규모는 이전에 본 적이 없는 수준이다. 이제 병목은 사람 규모를 위해 만들어진 개발자 인프라, 그러니까 소스 컨트롤, 빌드, CI다.
2026년 5월 Anthropic은 하루 평균 2,500건 안팎의 코드 변경을 머지했다. 9월에는 하루 30,000건을 넘겼다. 이 성장세가 곧 둔화되리라고 기대하지 않는다. 코드를 머지하고 싶은 잠재 수요는 사실상 무한하고, 병목을 하나 걷어낼 때마다 생산하는 코드의 양이 다시 늘어난다.
2026년 1월부터 9월까지 모노레포에 하루 머지된 변경 건수.
이 성장을 뒷받침하기 위해 자체 버전 컨트롤 시스템 Scion을 만들었고, 5개월 만에 모노레포를 git에서 완전히 옮겼다. 같은 기간에 코드 리뷰 화면(Antique), 코드 검색, 소스 컨트롤 IAM 체계, 검토를 마친 대량의 코드를 관리하고 랜딩하는 새로운 방법들도 함께 만들어 출시했다. 이 글에서는 특히 Scion을 어떻게 만들었는지에 초점을 맞춘다. 좋은 사례 연구가 된다. Claude의 코드 작성 능력이 이 상황을 만든 원인이면서 동시에, 대응할 고품질의 확장 가능한 시스템을 빠르게 짓게 해준 수단이었기 때문이다.
커지는 모노레포
만든 것을 살펴보기 전에, 우리 워크로드가 얼마나 특이한지 인정할 필요가 있다. 예상대로 Anthropic은 거의 어떤 회사보다 Claude로 소프트웨어를 많이 작성하기 때문에, 사람 규모를 위해 만든 도구가 어디서 한계에 다다르는지 가장 먼저 마주하는 경우가 많다. 소스 컨트롤은 그 사례 중 하나다. 근시기에 이런 문제를 겪을 조직이 많지는 않을 것으로 보지만, AI 코딩 도구를 쓰는 회사들이 같은 압력 지점에 도달하기까지 오래 걸리지 않을 거라고 본다. 그래서 우리가 만든 것과 배운 것을 공유하고 싶었다.
Git은 분산 시스템이다. 모든 클론은 완결된 독립 저장소라서 완전히 오프라인에서도 diff를 계산하고, 히스토리와 blame을 읽고, 아무 리비전이나 체크아웃할 수 있다. 대다수 저장소에서는 이것이 옳은 설계다. git이 표준이 된 큰 이유이기도 하다.
모노레포가 커지면서 이 설계 공간에 점점 맞지 않게 됐다. 메인 브랜치 히스토리만 거의 100GB고, 압축된 작업 사본도 25GB를 넘는다. CI를 위해 하루 약 2,500만 건의 코드 체크아웃을 수행한다. 개발자 환경, 에이전트 샌드박스, 연구 작업은 여기에 더해진다. 순진하게 fetch하면 하루 600PB가 넘는 git 트래픽이 된다.
Git은 저장소의 일부만 다루는 도구를 제공한다. shallow clone, sparse checkout, promisor remote 같은 것들이다. 그 밖에 큰 모노레포를 위한 표준적인 우회책도 있다. 내부 git 미러, blob 스토리지에 보관하는 저장소 스냅샷(seed) 같은 것들. 우리는 전부 써봤다. 최성기에는 이 부하를 감당하려고 내부 git 미러를 수백 대 운영했다. 시간은 벌어줬지만 머지 속도가 붙을수록 운영이 어려워졌다. 갱신 사이에 seed는 main 최신 커밋에서 멀어졌고, diff와 blame처럼 히스토리에 의존하는 작업을 부분 클론에서 계속 동작하게 유지하려면 점점 더 많은 신경이 필요했다.
git 체크아웃을 스케일링하는 전형적인 구성.
물러나서 전체를 보니, 대부분 회사처럼 우리도 git을 하나의 권위 있는 사본을 둔 중앙집중식 시스템으로 쓰고 있었다. 그런데 클라이언트 대부분은 정의상 항상 온라인인 에이전트와 작업이었다. 분산·오프라인 작업에 git을 뛰어나게 만드는 성질들이, 저장소가 커질수록 오히려 우리의 확장을 거듭 막았다. 그래서 스스로에게 물었다. 에이전트가 항상 온라인이라는 사실을 처음부터 전제에 넣고 소스 컨트롤을 설계한다면, 어떤 모습일까.
에이전트 규모 소스 컨트롤의 원칙
에이전틱 코딩은 소프트웨어 개발에 관한 여러 통상의 가정을 바꾸고 있다. Scion을 만들 때 이 변화를 그대로 받아들였고, 그 덕분에 몇 가지 핵심 원칙에서 git과 근본적으로 다른 접근이 가능했다. 거대 모노레포를 위한 소스 컨트롤에는 선례가 있다. 구글의 Piper와 메타의 Sapling이 대표적이다. 그들이 값비싼 대가로 얻은 교훈을 참고해 Scion을 지었다. 원칙은 다음과 같다.
클라이언트는 항상 온라인이다. Git은 클라이언트가 오프라인으로 일하고 저장소의 완전한 사본을 필요로 한다고 가정한다. 우리 클라이언트 대부분은 에이전트와 작업이기 때문에, Scion은 언제나 접근 가능한 서버를 전제로 클라이언트와 프로토콜을 설계했고, 클라이언트는 필요할 때 데이터를 가져온다.
클라이언트와 서버의 비대칭. Git에서 모든 클라이언트는 온전한 서버가 될 수 있다. Scion에서는 서버가 파일 히스토리와 blame에 대한 질문에 답하고, 커밋을 만들고, 머지와 리베이스를 수행한다. 클라이언트는 크기가 제한된 로컬 오브젝트 캐시를 유지하고, 작업 사본 파일을 디스크에 배치하고, 파일시스템 변화를 감시하고, 서버와 일하기 좋은 인터페이스를 제공한다. 클라이언트가 혼자 계산할 수 있는 것은 거의 없지만, 그 대가로 로컬에 필요한 데이터도 훨씬 적다.
포괄적인 소스 컨트롤 서비스는 새로운 응용을 여럿 떠받친다. Git에서는 저장소에 관한 질문, 예컨대 어떤 줄을 마지막으로 누가 바꿨는지, 두 커밋이 어떻게 연결되는지를 묻는 CI 잡이나 도구는 로컬 저장소 사본을 유지하거나 벤더 고유의 API가 답을 주기를 바랄 수밖에 없었다. Scion에서는 클라이언트가 쓰는 소스 컨트롤 질의를 전부 API로도 노출하기 때문에, 많은 경우 잡이 로컬 저장소를 아예 갖지 않아도 된다. 자동 bisect와 revert 파이프라인 같은 내부 도구 다수는 이 값싼 프로그래밍 방식 접근이 없으면 규모 면에서 현실성이 없었을 것이다.
모든 것은 수평 확장이 가능해야 한다. 최성기에 git 미러를 수백 대 운영했는데, 이는 용량을 크게 압박했고 저장소가 미러의 디스크나 메모리 한계를 넘어서면 더 이상 확장되지 않았다. Scion에서는 저장소 데이터가 분산돼 있고 모든 컴포넌트가 독립적으로 확장된다. 서버 위에서조차 저장소가 완전히 구체화된 사본은 어디에도 없다. packfile(git의 오브젝트 압축 묶음)에 해당하는 것도 없어서 저장소 유지보수가 필요 없다.
커밋은 값싸고, 점증적이고, 락 프리여야 한다. Git에서는 로컬에서 커밋한 뒤 push로 작업을 공유한다. Scion에서는 모든 커밋, 리베이스, 머지가 서버에서 일어난다. push할 것이 없다. 대신 각 작업이 빨라야 한다. 커밋을 만들고 그 하위 데이터 구조를 갱신하는 비용은 저장소 전체 크기가 아니라 변경의 크기에 비례해야 한다. 그렇지 않으면 서버가 속도를 따라가지 못한다. Scion의 개발 수명주기는 ref(브랜치와 태그 같은 커밋 포인터)를 자제하도록 설계됐다. main ref나 릴리스 브랜치는 예외다. 모든 서버가 합의해야 하는 전역 상태는 결국 확장 문제로 다가오기 때문이다.
작업 사본은 선택 사항이고, 설계상 sparse하다. 모노레포가 너무 크고 CI를 위해 하루 수천만 번 코드를 체크아웃하기 때문에, 체크아웃은 가능한 한 피하고 싶었다. Scion에서는 예컨대 커밋과 머지 베이스 사이의 diff가 필요한 CI 잡이 서버에 그 diff를 요청할 수 있다. 쓰기도 마찬가지다. 많은 쓰기 워크로드가 체크아웃을 건너뛰고 API만으로 동작할 수 있다. Scion 프로토콜은 sparse checkout(클라이언트가 요청한 디렉터리만 담는다)과 virtualized checkout(파일을 필요할 때 구체화한다)을 중심에 둔다. 잡이 디스크의 파일을 정말 필요로 할 때, 클라이언트는 실제로 읽은 것만 비용을 낸다.
Scion의 동작 방식
이 원칙들이 실제 구축에서 어떻게 모였는지를 이해하면 도움이 된다. 여기서 얻은 통찰은 다른 소스 컨트롤 시스템에도, 더 넓게는 개발 수명주기의 다른 단계에도 적용될 수 있다.
데이터 구조
Scion에서 작업의 단위는 changeset이고, write-ahead log의 한 항목이다. Changeset은 git 커밋에서 기대하는 대부분의 정보를 담는다. Git 커밋이 트리를 가리키는 포인터를 저장하는 것과 달리, changeset은 첫 부모를 기준으로 변경된 파일의 목록[1]을, blob 스토리지의 압축된 파일 내용을 가리키는 content-addressed 포인터와 함께 저장한다. Changeset은 서버 쪽에서 생성되며 즉시 모든 곳에서 사용할 수 있다.
Scion에서 changeset의 구조.
이 구조 덕분에 매우 높은 처리량으로 changeset을 받아들일 수 있다. 받아들일 packfile이 없고, 락이나 서버 간 조정도 없고, 움직일 ref도 없기 때문이다. Scion은 기술적으로 ref를 지원한다. 다만 커밋을 만들거나 가져오는 일에 ref가 개입하지 않아서, ref를 움직이는 것은 changeset 생성과 별도로 단일 Spanner 행에 대한 compare-and-swap으로 처리된다.
Changeset은 변경된 것만 기록하기 때문에, 그것만으로는 어떤 줄을 마지막으로 누가 고쳤는지, 어떤 커밋이 파일에 영향을 줬는지 같은 질문에 빠르게 답할 수 없다. 그래서 Scion은 changeset에서 추가 데이터 구조를 만든다. 파일 blame과 경로 히스토리를 위한 전용 구조, 커밋 그래프의 skip list 등이다. Changeset에 직접 속하지 않는 모든 것을 derived data라고 부르고, 하나의 범용 메커니즘으로 전부 계산한다. 각 derived data 유형은 재귀적으로 정의된다. 어떤 changeset에서의 값은 그 부모들에서의 값으로부터 계산된다.
이 메커니즘의 이점은 세 가지다. 첫째, 새 데이터 구조가 어떤 작업을 빠르게 해준다면 새 유형의 derived data를 쉽게 추가할 수 있다. 둘째, 유형마다 즉시 계산할지 작업을 미룰지 고를 수 있어서, 필요 없는 데이터는 구체화하지 않는다. 셋째, 클라이언트는 이 데이터 구조의 내부를 전혀 보지 않기 때문에, 클라이언트를 바꾸지 않고도 최적화할 수 있다. 시스템이 커지는 동안 새 derived data를 여러 번 추가했다. 복사 감지(copy detection)나 경로 기반 파일 검색을 위한 새 인덱스 같은 것들이다.
Scion의 스케일링
소수의 Scion 서버 페릿이 클라이언트가 필요로 하는 모든 작업의 소스 컨트롤 API를 제공한다. changeset 가져오기, diff 계산, 머지 베이스 찾기, blob fetch 같은 것들이다. 모든 소스 컨트롤 데이터는 content-addressed라서, 일단 저장되면 절대 변하지 않고 어떤 서버든 다른 서버와 확인할 필요 없이 캐시할 수 있다. 덕분에 서버들은 수평 확장이 가능하고 조정이 거의 필요 없다. 사실상 큰 캐시이면서, derived data를 즉석에서 계산해 결과를 Spanner에 다시 쓸 수 있는 존재들이다.
Scion의 수많은 소비자는 더 이상 자체 로컬 저장소를 유지할 필요가 없다. 저장소를 fetch하고 유지보수하는 일은 CI 잡이나 소스 컨트롤 질문, 특히 커밋 조상 관계와 blame에 대한 질문이 필요한 도구들에게 상당한 유지보수 부담이었다. 이전 초기에는 자체 클라이언트, 저장소 포맷, 프로토콜이 없었기 때문에 Scion은 이런 메타데이터 질의만 답했다. 파일 내용을 가져오고 작업 사본을 구체화하는 일은 훨씬 데이터 집약적이라 별도의 설계가 필요했다.
Scion의 scn 클라이언트는 git의 fetch 프로토콜에서 중요한 부분에서 벗어나 있다. 덕분에 git 서버보다 훨씬 적은 CPU를 요구하는 고확장 아키텍처에 자연스럽게 맞는다. Scion의 협상(negotiation)은 클라이언트가 이미 무엇을 갖고 있는지 서버에 알려주지 않는다. 오로지 클라이언트가 원하는 트리와 blob만을 대상으로 동작한다. 루트 트리에서 시작해 클라이언트는 로컬 저장소에 없는 트리를 찾아 재귀적으로 요청하고, blob에 대해 같은 과정을 반복한다. 모든 요청은 한 번 저장되면 변하지 않는 특정 오브젝트를 대상으로 하므로 어떤 캐시든 답할 수 있고, 아키텍처는 전통적인 계층형 캐시와 매우 닮았다. 과정은 효율적이고 재개 가능하다. 수기가바이트짜리 단일 packfile 응답이 없기 때문이다. Sparse 체크아웃과 virtualized 체크아웃은 특별한 지원이 필요 없다. 클라이언트가 원하지 않는 트리를 그냥 요청하지 않기 때문이다.
페릿에서 클라이언트는 소켓으로 scion-daemon과 통신한다. 이 데몬은 노드 전체의 오브젝트를 저장한다. 우리 노드 대부분은 모노레포에 접근해야 하고, 같은 노드의 잡들은 대부분 같은 오브젝트를 재사용한다. 각 데몬은 주기적으로 갱신되는 스냅샷에서 출발해, 같은 리전의 트리·blob 캐시 서버인 scion-cache와만 통신한다. 이 캐시 서버는 오브젝트를 메모리에서, 데몬이 소비할 디스크 포맷 그대로 스트리밍한다. 클라이언트의 누락 오브젝트를 계산하거나 delta 압축을 수행할 필요가 없다. 캐시에 없는 오브젝트는 권위 있는 scion-servers에 요청하고, 이들은 필요에 따라 Spanner나 클라우드 스토리지를 읽는다.
scion-daemon, scion-cache, scion-server는 이 프로토콜에 대해 동일한 RPC에 응답한다. 그래서 클라이언트는 캐시 토폴로지를 알 필요가 없다. 이론상 어느 계층이든 다른 계층과 통신할 수 있지만, 장애 영역을 분리하려고 계층 구조를 엄격하게 강제한다. 한 리전의 scion-cache 장애가 업스트림 scion-servers를 압도해 시스템 전체를 끌어내리는 상황은 피하고 싶다.
Scion의 체크아웃 아키텍처.
이 시스템의 각 계층은 99%가 넘는 캐시 적중률을 유지하고 오래 살아있는 상태를 요구하지 않으므로, 필요하면 확장하는 일이 쉽다. Scion 인프라의 발자국은 이전의 git 미러링 인프라 대비 CPU와 메모리 요구량 기준 200분의 1이다. CI와 연구 잡은 코드를 두 자릿수 배 빠르게(분 단위가 아니라 초 단위로) 체크아웃한다. 페릿 전체에서 상당한 용량이 확보됐고, CI만으로 CPU 용량이 25% 절약됐다. 클라이언트와 캐시 모두 저장소 유지보수를 할 필요가 없어서 잡의 수명주기 관리도 단순해졌다.
Scion을 만들며 배운 것
Scion 구축을 시작한 시점은 Claude Mythos Preview와 Claude Tag가 사내에서 쓰이게 된 시기와 거의 같았다. 두 릴리스는 Scion의 필요성을 동시에 키우고, Scion을 만드는 속도를 눈에 띄게 끌어올렸다.
특히 인상적인 사례가 있다. 연초에 우리는 git에서 Scion으로 데이터를 받아들이는 파이프라인의 첫 버전을 대부분 손으로 직접 작성해 프로토타입으로 삼았다. 괜찮다고 생각했다. Claude Mythos Preview의 초기 내부 스냅샷을 손에 넣을 때까지는. 전체를 다시 쓰라고 했더니, 추가 지시 하나 없이 메모리를 20분의 1로 줄이고 4배 빠른 버전을 만들어냈다. 인게스천 순서와 데이터 구조를 둘러싼 암묵적 불변식을 모두 지키면서였다.
2026년 1월부터 9월까지 Scion과 Antique 코드베이스에 주간 머지된 변경 건수.
Scion을 만들고 운영하며 배운 것은 에이전트 규모의 소프트웨어 개발이 어떤 모습일지에 대한 흥미로운 교훈을 준다.
작은 팀의 빠른 개발이 더 흔해질 것이다. 일곱 명의 팀이 Scion과 Antique(코드 리뷰 도구. 이것만으로 블로그 글 하나가 더 나올 법하다)를 만들었고, 거기에 관련 시스템 여섯 개를 더했으며, 5개월 만에 완전히 이전했다. 그 기간 동안 하루 머지되는 코드의 양은 10배 늘었다. 과거라면 이런 소스 컨트롤 시스템의 개발과 배포는 훨씬 많은 엔지니어가 몇 년에 걸친 반복적 이전으로 이뤄졌을 것이다. 이런 빠르고 민첩한 이전이 앞으로 더 흔해질 거라고 본다.
엔지니어의 가치가 줄어든 것이 아니라, 엔지니어의 일이 바뀌고 있다. 이 시스템을 만든 엔지니어 전원이 지금은 Claude가 코드 작성 면에서 자신보다 낫다고 평가한다. 그러나 엔지니어들은 여전히 시스템 간 상위 구성요소와 설계 수준의 트레이드오프에 대한 귀중한 이해를 공급했다. 풀고 싶은 문제와 달성해야 할 규모를 알고 정보에 기반해 선택을 만들었다. 아주 자주, 엔지니어의 역할은 Claude에게 “아니오”라고 말하는 것이었다. 에이전트는 애초에 허용돼서는 안 되는 패턴을 만족시키려다 시스템의 핵심 제약을 어기기도 한다. 이전 작업에서 특히 흔했다. 여러 시스템이 코드 리뷰 도구에 묻는 대신 커밋 로그를 선형으로 읽어가며 어떤 변경이 main에 머지됐는지 무식하게 찾으려 들었다. Anthropic은 적대적 리뷰(adversarial review)도 광범위하게 쓴다. 여러 면에서 놀랍게 효과적이지만 근시가 될 수도 있다. 숙련된 엔지니어가 가설적 우려에 대한 과잉 엔지니어링으로 Claude를 되돌려 놓아야 했다. 어떤 리뷰는 다른 내부 서비스를 신뢰하는 데 지나치게 방어적이어서, Claude가 과도한 검증과 복잡성을 추가하게 만들었다. 팀원은 여전히 이 시스템의 모든 변경 요청을 검토한다. 다만 이제는 코드 한 줄 한 줄을 읽는 대신 변경의 의도(intent)를 검토한다.
최적화와 품질을 실질적으로 끌어올릴 수 있었다. Claude가 우리보다 훨씬 빠르게 방대한 양의 코드를 작성할 수 있었기 때문에, Scion은 우리가 경험한 코드베이스 중 가장 충실하게 테스트되고 방어된 코드베이스 중 하나다. 촉박한 일정에도 우리가 만난 특이한(non-trivial) 인프라 및 소스 컨트롤 상호작용 전부를 커버하는 밀폐된(hermetic) 시뮬레이션을 만들었고, fuzzing과 정교한 레이트 리밋도 갖췄다. Claude는 상당한 최적화도 수더럽게 찾아냈다. 예컨대 우리 인덱스 하나를 놓치던 조상 질의의 알고리즘적 최적화 같은 것이다. 전문가가 며칠 혹은 몇 주의 분석과 튜닝을 필요로 했을 작업이다. 그리고 그 다음 날 같은 일을 또 했다.
네이티브 Scion 저장소에서 관측된 성능 개선.
모노레포 보안의 새로운 형태를 위한 토대를 놓았다. 거대 모노레포에서 안전, 보안, 컴플라이언스를 관리하는 일은 크기와 규모를 관리하는 일만큼 중요하다. 우리는 Scion을 처음부터 이를 염두에 두고 만들었다. 저장소에 풍부한 접근 제어를 지원하고, 개별 디렉터리에 권한을 적용해 모노레포의 이점을 잃지 않으면서 가장 민감한 코드를 보호할 수 있다. 더 나아가 만든 코드 리뷰 도구는 승인에 복잡한 의미적 제약을 표현할 수 있다. 주석만 바꾼 변경과 민감한 논리적 변경을 구분할 수 있어서, 사람 리뷰어는 가장 영향이 큰 변경에 집중할 수 있다.
운영 우수성의 새로운 수준이 가능하다. 우리 팀은 Claude Tag를 적극적으로 쓰는데, 시스템 각 컴포넌트의 상태를 감시하는 데 도움이 됐다. 예컨대 Claude에게 단일 컴포넌트의 건강에 집착하도록 맡긴 Slack 채널을 만들었다. 이 Claude들을 superfan이라고 부른다. scion-daemon superfan, scion-cache superfan, Antique 머지 큐 superfan 등이 있다. 이들은 텔레메트리와 로그에 접근하고, 차트를 새로 고치고 이상한 것을 찾는 일 말고는 할 일이 없는 숙련된 엔지니어처럼 행동한다. 모든 시스템에 전통적인 알럿도 갖춰 있지만, superfan은 이 알럿이 한 차원 낮아 보이게 만드는 미묘하고 새로운 문제들을 잡아낸다.
우리는 선입견을 완전히 다시 검토하고 있다. 이 프로젝트는 사람 규모를 위해 설계된 다른 워크플로를 뼈아프게 들여다보게 만들었다. 예컨대 제대로 된 머지 큐는 에이전트 규모에서 별 의미가 없다. 테스트가 돌고 있는 동안 수백, 수천 건의 변경이 머지될 수 있다면 CI란 무슨 뜻일까. 머지 큐에 대한 전역 저장소 락이라는 업계 표준을 효과적으로 재현하지 못했기 때문에, 대신 머지 후(post-merge)와 배포 전(pre-deploy) 자동 테스트에 투자했다. 동시에 진행되는 변경이 충돌할 수 있다는 뜻이기도 하다. 다만 Claude는 보통 이런 충돌을 사람이 충돌을 알아차리기보다 빠르게 고친다.
더 넓은 생태계에 기여하기
우리는 Scion을 점점 강해지는 AI 에이전트가 불러온 확장 우려에 대한 답의 한 부분으로 본다. 비슷한 문제를 팀이 어떻게 다룰 수 있는지 보여주는 사례로 이 세부사항을 공유한다. 우리 해법이나 고려사항이 모든 경우에 맞으리라고는 기대하지 않는다.
Scion은 일반적인 용도에서 git의 적합한 대체제가 결코 아니다. 여기서 개괄한 개념은 정말로 거대한 모노레포, 즉 수만 명의 엔지니어나 코드를 왕성하게 쓰는 에이전트 무리가 있는 경우에만 의미가 있다. 게다가 Anthropic은 독특한 곳이다. 내부 사용을 위해 토큰에 쓸 수 있는 능력이 다른 어떤 비즈니스가 현실적으로 쓰고 싶어 할 금액을 훨씬 넘는다. 우리는 이를 자체 소프트웨어 개발 수요를 해결하기 위해서이자 Claude의 능력을 시험하기 위해 한다.
현실적으로는 Scion을 다른 조직에 널리 유용한 형태로 제공하기가 어렵다. Git과 크게 다르기 때문에 회사는 개발 수명주기의 모든 조각을 이전해야 하고, 자체 코드 리뷰, 코드 검색, CI가 필요하다. 이 구성요소들의 사내 버전은 매우 특화돼 있어 다른 조직이 채택하기 어렵다. 모두를 만족시키려는 공개 버전을 만드는 시도가 실제로 유용하지 않으리라고 걱정한다.
다만 이 부류의 문제가 앞으로 6개월에서 12개월 사이에 더 흔해질 거라고 예상한다. git을 쓰는 모든 회사가 비슷한 문제를 홀로 맞대는 것은 엔지니어링 자원의 비효율적 사용이다. 그래서 가장 영향력 있는 일은 우리의 사고를 공유하는 것이라고 본다. 다른 개발자들이 Scion의 가장 성공적인 부분 중 일부를 전체 모델에서 벗어나지 않으면서 git에 적용할 수 있도록. Git 서버가 git 클라이언트와 같은 방식으로 동작할 필요는 없다. 상당한 확장 개선을 제공하는 새로운 서버 아키텍처가 존재한다. Git 플랫폼은 Scion처럼 포괄적인 서버 측 RPC를 제공할 수 있고, 어쩌면 git 클라이언트가 통신하는 법을 배울 수 있도록 포지(forge) 간 표준화된 방식으로조차 가능하다. 협상 프로토콜이 오늘날과 똑같은 모습일 필요도 없고, git의 여러 sparse·shallow 기능들은 서로 잘 조합되도록 만들 수 있다.
마지막으로, git 커뮤니티가 수백만 개발자를 위해 플랫폼을 확장하는 데 거의 20년을 보냈다는 점을 밝힌다. 우리의 기여는 훨씬 좁다. 에이전틱 소프트웨어 개발이 이런 시스템과 어떻게 상호작용하는지에 대한 초기 시각을 공유하고, GitHub, GitLab, OSS 커뮤니티와 협력해 개발자의 변화하는 요구를 지원하는 것이다. 소프트웨어 개발 수명주기가 AI 지수곡선과 교차하는 지금, 우리는 모두 같은 여정에 있다.
감사의 말
Nick G.와 소스 컨트롤 팀(S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P.)이 썼다. 이 야심 찬 여정에서 소스 컨트롤 팀을 지원해 준 Vilas J.와 Sergiu D., Antique에 초기 기여를 한 Amir O.에게 감사를 전한다.
각주
- 머지의 첫 부모를 기준으로 변경된 파일을 저장하는 것은 취향의 문제다. 실제로 우리는 모노레포의 트렁크 기반 개발에서 사람들이 main 라인 커밋의 히스토리와 blame에만 관심을 갖는다는 것을 발견했다.