Scion에서 사용하는 여러 기법을 개척한 프로젝트들에 대한 더 자세한 내용을 포함하여 10월 15일에 업데이트되었습니다.
Anthropic에서는 코딩이 더 이상 시스템 구축이나 연구 수행의 병목이 아닙니다. Claude는 연구 루프를 자율적으로 반복하고, 복잡한 프로그램을 미세 최적화하며, 새로운 서비스를 처음부터 구축할 수 있습니다. 이제 병목은 사람 규모를 위해 구축된 개발자 인프라, 즉 소스 관리, 빌드, CI 전반에 있습니다.
2026년 5월, Anthropic은 하루 평균 약 2,500건의 코드 변경 사항을 병합했습니다. 9월 기준으로는 하루 30,000건 이상을 병합하고 있습니다. 우리는 이러한 성장률이 당분간 둔화되리라 기대하지 않습니다. 코드를 병합하려는 잠재적 수요는 사실상 무한하며, 우리가 병목을 하나 제거할 때마다 즉시 우리가 생산하는 코드의 양이 더욱 증가합니다.
이러한 성장을 지원하기 위해 우리는 Scion이라는 사내 버전 관리 시스템을 구축했고, 5개월 만에 모노레포를 git에서 완전히 마이그레이션했습니다. 또한 같은 기간 동안 코드 리뷰 인터페이스(Antique라고 함), 코드 검색, 풍부한 소스 관리 IAM 시스템, 검토된 코드를 대량으로 관리하고 병합하는 새로운 방식 등을 구축하여 출시했습니다. 이 글에서는 특히 Scion을 어떻게 구축했는지에 초점을 맞추겠습니다. 이는 흥미로운 사례 연구가 됩니다. Claude의 코드 작성 능력이 애초에 우리를 이 상황에 놓이게 만든 원인이기도 했지만 그리고 당시 고품질의 확장 가능한 시스템을 어떻게 빠르게 구축할 수 있었는지에 관한 내용입니다.
우리의 모노레포 키우기
우리가 만든 것을 살펴보기 전에, 우리의 워크로드가 얼마나 특이한지 인정할 필요가 있습니다. 놀랍지 않게도 Anthropic은 거의 어떤 회사보다도 Claude를 사용해 소프트웨어를 작성하기 때문에, 인간 규모를 위해 만들어진 도구들이 한계에 다다르는 지점을 가장 먼저 목격하는 경우가 많습니다. 소스 컨트롤은 그 한 예일 뿐입니다. 당분간 많은 조직이 이런 문제를 겪을 것으로 예상하지는 않지만, AI 코딩 도구를 사용하는 다른 이들도 머지않아 같은 압박 지점을 경험하게 될 것으로 생각하며, 그래서 우리가 무엇을 만들었고 무엇을 배웠는지 공유하고자 했습니다.
Git은 분산형 시스템입니다. 모든 클론은 완전하고 독립적인 저장소로, 오프라인 상태에서도 diff 계산, 히스토리 및 blame 조회,任意 리비전 체크아웃을 수행할 수 있습니다... wait—no. Correct: 임의 리비전 체크아웃을 수행할 수 있습니다. 대다수의 저장소에서 이것이 올바른 설계이며, git이 표준이 된 큰 이유 중 하나이기도 합니다.
모노레포가 성장함에 따라 점점 더 그 설계 공간에 맞지 않게 되었습니다. 메인 브랜치의 히스토리만 거의 100 GB에 달하며, 그리고 압축됨 작업 복사본이 25 GB를 넘습니다. 우리는 개발자 환경, 에이전트 샌드박스, 연구 작업을 제외하고도 CI를 위해 하루 약 2,500만 회의 코드 체크아웃을 수행합니다. 단순히 가져온다면 하루에 600 PB가 넘는 git 트래픽이 발생할 것입니다.
Git은 얕은 클론(shallow clone), 스파스 체크아웃(sparse checkout), 프로미서 리모트(promisor remote) 같은 리포지토리의 일부를 다루기 위한 도구를 제공합니다. 이 외에도 대규모 모노레포를 위한 표준 우회 방법들이 있는데, 내부 git 미러와 블롭 스토리지에 보관되는 리포지토리 스냅샷(시드) 등이 그것입니다. 우리는 이 모든 방법을 사용해 왔습니다—최전성기에는 부하를 감당하기 위해 수백 개의 내부 git 미러를 운영했습니다. 이는 시간을 벌어주었지만, 머지 비율이 증가함에 따라 운영이 점점 어려워졌습니다. 갱신 사이에 시드는 main 브랜치의 최신 위치에서 점점 멀어졌고, diff와 blame 같이 히스토리에 의존하는 작업이 부분 클론에서 계속 작동하도록 유지하는 데 점점 더 많은 주의가 필요했습니다.
한 걸음 물러나서 살펴보니, 우리는 대부분의 회사처럼 git을 하나의 신뢰할 수 있는 사본을 가진 중앙화된 시스템으로 사용하고 있었지만, 우리 클라이언트의 거의 전부는 정의상 항상 온라인 상태인 에이전트와 잡들이었습니다. git이 분산 및 오프라인 작업에 탁월하게 만드는 특성들이 오히려 저장소가 커짐에 따라 우리의 확장 능력을 적극적으로 저해하고 있었습니다. 그래서 우리 스스로에게 물었습니다. 에이전트가 항상 온라인이라는 사실을 처음부터 염두에 두고 소스 컨트롤을 설계한다면, 그것은 어떤 모습일까?
에이전트 규모 소스 관리를 위한 원칙
에이전트 코딩이 등장하면서 소프트웨어 개발 방식에 대한 많은 통념이 변화하고 있습니다. 우리는 Scion을 구축하면서 이러한 변화를 수용했고, 이를 통해 여러 핵심 원칙에서 git과는 근본적으로 다른 접근 방식을 취할 수 있었습니다. 거대한 모노레포를 위한 소스 컨트롤에는 선행 사례가 있으며, 특히 Google의 사례가 있습니다. Piper 및 Meta의 Sapling,2 그래서 우리는 그들이 값비싼 대가로 얻은 교훈을 염두에 두고 Scion을 만들 수 있었습니다. 우리의 원칙은 다음과 같습니다:
고객들은 항상 온라인 상태입니다. Git은 클라이언트가 오프라인으로 작업하며 저장소의 전체 복사본이 필요하다고 가정합니다. 우리의 클라이언트 거의 대부분이 에이전트와 잡이므로, 우리는 항상 접근 가능한 서버를 중심으로 Scion의 클라이언트와 프로토콜을 설계했으며, 클라이언트가 필요할 때 데이터를 가져오도록 했습니다.
클라이언트-서버 비대칭성. Git에서는 모든 클라이언트가 완전한 기능을 갖춘 서버가 될 수 있습니다. Scion에서는 서버가 파일 이력 및 blame에 대한 질문에 답하고, 커밋을 생성하며, 병합과 리베이스를 수행하는 등의 작업을 담당합니다. 클라이언트는 크기가 제한된 로컬 객체 캐시를 유지하고, 작업 복사본 파일을 디스크에 배치하며, 파일시스템 변경을 모니터링하고, 사용자가 서버와 함께 작업할 수 있는 인체공학적인 방법을 제공합니다. 클라이언트는 스스로 거의 아무것도 계산할 수 없지만, 그 대신 로컬에 필요한 데이터가 훨씬 적습니다.
포괄적인 소스 컨트롤 서비스는 수많은 새로운 애플리케이션의 기반이 될 수 있습니다. git에서는 라인을 마지막으로 누가 수정했는지, 두 커밋이 어떻게 연관되어 있는지 같은 저장소에 대한 질문이 필요한 CI 작업이나 도구는 저장소의 로컬 복사본을 유지하거나 벤더 고유의 API가 답을 제공해주기를 바랄 수밖에 없습니다. Scion에서는 클라이언트가 사용하는 모든 소스 컨트롤 쿼리가 API를 통해서도 노출되므로, 많은 경우 작업에 로컬 저장소가 전혀 필요하지 않습니다. 자동화된 bisect 및 revert 파이프라인과 같은 많은 내부 도구는 이러한 값싼 프로그래밍 방식의 소스 컨트롤 접근이 없다면 대규모로는 실용적이지 않을 것입니다.
모든 것은 수평적으로 확장 가능해야 합니다. 최전성기에는 수백 개의 git 미러를 운영했는데, 이는 용량에 상당한 부담을 주었고 저장소가 미러의 디스크나 메모리 한도를 초과하자 더 이상 확장되지 않았습니다. Scion에서는 저장소의 데이터가 분산되어 있고 모든 구성 요소가 독립적으로 확장 가능합니다. 서버를 포함해 어디에도 저장소의 완전히 실체화된 복사본이 존재하지 않습니다. packfile(git의 압축된 객체 묶음)에 해당하는 것이 없으므로 저장소 유지 관리가 필요하지 않습니다.
커밋은 값싸고, 증분적이며, 락 프리여야 합니다. git에서는 로컬에서 커밋한 후 push하여 작업을 공유합니다. Scion에서는 모든 커밋, rebase, 병합이 서버에서 발생하므로 push할 것이 없지만, 이러한 각 작업은 빨라야 합니다. 커밋을 생성하고 그 하위 데이터 구조를 갱신하는 비용은 저장소 전체 크기가 아니라 변경 크기에 비례해야 하며, 그렇지 않으면 서버가 따라갈 수 없습니다. Scion의 개발 라이프사이클은 main ref나 릴리스 브랜치를 제외하고는 ref(브랜치와 태그 같은 커밋에 대한 포인터)를 지양합니다. 왜냐하면 모든 서버가 합의해야 하는 전역 상태는 잠재적인 확장성 문제이기 때문입니다.
작업 복사본은 선택 사항이며, 설계상 스파스(sparse)입니다. 모노레포가 매우 크고 하루에 수천만 번 CI용 코드를 체크아웃하기 때문에, 가능한 한 체크아웃을 피하고 싶었습니다. Scion에서는 예를 들어 커밋과 그 병합 베이스(merge base) 간의 diff가 필요한 CI 작업이 서버에 요청할 수 있습니다. 쓰기도 마찬가지입니다. 많은 쓰기 워크로드도 체크아웃을 생략하고 전적으로 API를 통해 수행될 수 있습니다. Scion의 프로토콜은 클라이언트가 요청한 디렉터리만 포함하는 스파스 체크아웃과 요청 시 파일을 실체화하는 가상화 체크아웃을 중심으로 하므로, 작업이 디스크상의 파일을 실제로 필요로 할 때 클라이언트는 실제로 읽는 것에 대해서만 비용을 지불합니다.
Scion의 작동 방식
Scion을 구축하면서 이러한 원칙이 실제로 어떻게 결합되었는지 이해하는 것이 도움이 됩니다. 이러한 통찰은 다른 소스 컨트롤 시스템, 더 넓게는 소프트웨어 개발 라이프사이클의 다른 단계에도 적용될 수 있습니다.
데이터 구조
Scion에서 작업 단위는 선행 기록 로그(write-ahead log)의 항목인 "changeset"입니다. changeset은 git의 커밋에서 기대할 수 있는 대부분의 것을 저장합니다. 하지만 git 커밋이 트리에 대한 포인터를 저장하는 곳에서, changeset은 첫 번째 부모를 기준으로 변경된 파일 목록을1 저장하고, blob 저장소에 있는 압축된 파일 내용에 대한 내용 주소 기반 포인터를 함께 저장합니다. changeset은 서버 측에서 생성되며 즉시 어디서나 사용할 수 있습니다.
이 구조 덕분에 수용할 packfile이 없고, 락킹이나 서버 간 조율이 없으며, 옮길 ref도 없기 때문에 매우 높은 처리량으로 changeset을 수용할 수 있습니다. Scion은 기술적으로 ref를 지원하지만, 커밋 생성이나 가져오기에는 ref가 관여하지 않으므로 ref를 옮기는 것은 changeset 생성과 별도로 발생하는 단일 Spanner 행에 대한 compare-and-swap입니다.
changeset은 변경된 내용만 기록하므로, 그 자체만으로는 어떤 라인을 마지막으로 누가 편집했는지 또는 어떤 커밋이 파일에 영향을 미쳤는지 같은 질문에 빠르게 답할 수 없습니다. 이에 답하기 위해 Scion은 changeset으로부터 추가 데이터 구조를 구축하는데, 여기에는 파일 blame과 경로 이력을 위한 전용 구조 및 커밋 그래프를 위한 skip list가 포함됩니다. 우리는 changeset의 직접적인 일부가 아닌 모든 것을 "파생 데이터"라고 부르며, 이를 하나의 일반적인 메커니즘을 통해 계산합니다. 각 파생 데이터 유형은 재귀적으로 정의되어, 어떤 changeset에 대한 값은 그 changeset의 부모들에 대한 값으로부터 계산됩니다.
이 메커니즘에는 세 가지 이점이 있습니다. 첫째, 새로운 데이터 구조가 어떤 작업을 더 빠르게 할 수 있을 때 새로운 유형의 파생 데이터를 쉽게 추가할 수 있습니다. 둘째, 각 유형에 대해 즉시 계산할지 작업을 미룰지 선택할 수 있어 필요 없는 데이터를 실체화하는 것을 피할 수 있습니다. 셋째, 클라이언트는 이러한 데이터 구조의 내부를 결코 볼 수 없으므로 클라이언트를 변경하지 않고도 최적화할 수 있습니다. 시스템이 성장함에 따라 복사 감지(copy detection)나 경로 기반 파일 검색을 수행하기 위한 새로운 인덱스와 같이 새로운 유형의 파생 데이터를 여러 번 추가했습니다.
Scion 확장하기
소규모 Scion 서버 플릿이 클라이언트에 필요한 모든 작업, 즉 changeset 가져오기, diff 계산, 병합 베이스 찾기, blob 가져오기 같은 소스 컨트롤 API를 제공합니다. 모든 소스 컨트롤 데이터는 내용 주소 기반이므로, 데이터는 한 번 저장되면 절대 변경되지 않으며 어떤 서버든 다른 서버와 확인할 필요 없이 캐시할 수 있습니다. 그 결과 서버들은 수평적으로 확장 가능하며 조율이 거의 필요 없습니다. 이들은 본질적으로 파생 데이터를 즉석에서 계산하고 그 결과를 Spanner에 다시 쓸 수도 있는 대규모 캐시입니다.
Scion의 수많은 사용자는 더 이상 자체 로컬 저장소를 유지할 필요가 없습니다. 저장소를 가져오고 유지하는 일은 예전에는 커밋 계보나 blame 같은 소스 컨트롤 질문을 해야 했던 CI 작업이나 도구들에게 상당한 유지 관리 부담이었습니다. 마이그레이션 초기에는 자체 클라이언트, 저장소 포맷, 프로토콜이 없었기 때문에 Scion은 이러한 “메타데이터” 질의만 처리했습니다. 파일 내용을 가져오고 작업 복사본을 생성하는 작업은 훨씬 더 데이터 집약적인 작업이며, 그에 맞는 별도의 설계가 필요했습니다.
Scion의 scn 클라이언트는 여러 중요한 측면에서 git의 fetch 프로토콜과 다르며, 그 결과 git 서버보다 훨씬 적은 CPU를 요구하는 고도로 확장 가능한 아키텍처에 적합합니다. Scion의 협상(negotiation)은 클라이언트가 이미 가지고 있는 것을 서버에 알려주지 않고, 대신 클라이언트가 원하는 트리와 blob만을 대상으로 동작합니다. 클라이언트는 루트 트리에서 시작해 로컬 스토어에서 누락된 트리를 확인하고 이를 재귀적으로 요청한 다음, blob에 대해서도 같은 과정을 반복합니다. 모든 요청은 절대 변경되지 않는 특정 객체에 대한 것이므로 어떤 캐시든 응답할 수 있으며, 아키텍처는 전통적인 계층형 캐시와 매우 유사합니다. 단일한 수 기가바이트 packfile 응답이 없기 때문에 이 과정은 효율적이고 재개 가능합니다. 스파스 체크아웃이나 가상화된 체크아웃조차도 클라이언트가 원하지 않는 트리를 단순히 요청하지 않기 때문에 특별한 지원이 필요하지 않습니다.
플릿에서 클라이언트는 노드 전체의 객체를 저장하는 데몬인 scion-daemon과 소켓을 통해 통신합니다. 우리 노드 대부분은 모노레포에 대한 접근이 필요하며, 같은 노드의 작업들은 대부분 동일한 객체를 재사용합니다. 각 데몬은 주기적으로 갱신되는 스냅샷에서 시작한 다음, 자기 지역의 트리 및 blob 캐시 서버인 scion-cache와만 통신합니다. 이 캐시 서버들은 데몬이 소비할 디스크 포맷 그대로 메모리에서 직접 객체를 스트리밍하므로, 클라이언트의 누락된 객체를 계산하거나 델타 압축을 수행하는 데 시간을 쓸 필요가 없습니다. 캐시에 객체가 없으면 Spanner나 클라우드 스토리지에서 필요에 따라 읽어오는 권위 있는 scion-server에 요청합니다.
scion-daemon, scion-cache, scion-server는 모두 이 프로토콜에 대해 동일한 RPC에 응답하므로, 클라이언트는 캐시 토폴로지를 알 필요가 없습니다. 이론상 어떤 계층이든 다른 계층과 통신할 수 있지만, 장애 영역을 격리하기 위해 계층 구조를 엄격하게 강제합니다. 우리는 지역 scion-cache의 장애가 업스트림 scion-server를 압도하여 전체 시스템을 다운시키는 상황을 피하고자 합니다.
이 시스템의 각 계층은 99%를 넘는 캐시 적중률을 유지하며 장기 상태를 필요로 하지 않으므로, 필요시 손쉽게 확장할 수 있습니다. 우리의 Scion 인프라 발자국은 현재 CPU 및 메모리 요구 사항 기준으로 이전 git 미러링 인프라보다 200배 작습니다. CI와 연구 작업은 코드를 두 자릿수 더 빠르게(분이 아닌 초 단위로) 체크아웃하며, 이는 플릿 전체에서 상당한 용량을 확보해 줍니다. CI만으로도 25%의 CPU 용량 이득을 실현했습니다. 클라이언트나 캐시 모두 저장소 유지 관리를 수행할 필요가 없어 작업의 수명 주기 관리가 단순해집니다.
Scion을 구축하며 배운 것들
우리는 Claude Mythos Preview 와 Claude Tag 가 내부적으로 사용 가능해진 것과 거의 같은 시기에 Scion 구축을 시작했습니다. 이 두 릴리스는 Scion에 대한 필요성을 동시에 증폭시켰으며 구축 속도도 크게 가속화해 주었습니다.
특히 인상적인 예가 있습니다. 올해 초, 우리는 git-to-Scion 수집 파이프라인의 첫 버전을 프로토타입으로 거의 손으로 직접 작성했습니다. 우리는 그것이 훌륭하다고 생각했습니다—Claude Mythos Preview의 초기 내부 스냅샷을 손에 넣기 전까지는. 우리에게 전체를 다시 작성해 달라고 요청했고, 별도의 지시 없이도 수집 순서와 데이터 구조와 관련된 모든 암묵적 불변성을 유지하면서 메모리를 20배 덜 소비하고 4배 빠른 버전을 만들어 냈습니다.
Scion을 구축하고 운영하며 배운 것들은 에이전트 규모의 소프트웨어 구축이 어떤 모습일 수 있는지에 대한 흥미로운 교훈을 제공합니다.
소규모 팀을 통한 빠른 개발이 더 흔해질 것입니다. 일곱 명의 팀이 Scion과 Antique(우리의 코드 리뷰 도구로, 이것만으로도 블로그 포스트를 하나 더 쓸 수 있습니다) 두 가지 모두를, 관련 시스템 여러 개는 물론이고, 5개월 만에 완전히 마이그레이션까지 마쳤습니다. 우리는 하루에 병합되는 코드량이 10배 증가하는 동안 이 모든 것을 해냈습니다. 과거에는 이런 소스 컨트롤 시스템을 개발하고 배포하려면 훨씬 더 많은 엔지니어와 함께 수년간의 반복적인 마이그레이션이 필요했을 것입니다. 우리는 이러한 빠르고 민첩한 마이그레이션이 앞으로 더 흔해질 것이라고 생각합니다.
엔지니어의 가치가 덜해진 것이 아니라, 그들의 일하는 방식이 변하고 있습니다. 이 시스템을 작업한 모든 엔지니어들은 이제 Claude가 자신보다 코드 작성 능력이 뛰어나다고 평가합니다. 하지만 우리 엔지니어들은 여전히 상위 수준의 시스템 간 컴포넌트와 설계 수준의 트레이드오프에 대한 소중한 이해를 제공했고, 우리가 해결하고자 하는 문제와 달성해야 한다고 알고 있던 규모를 고려한 정보에 기반한 선택을 내렸습니다. 매우 자주, 엔지니어의 역할은 Claude에게 “아니오”라고 말하는 것이었습니다. 에이전트는 때때로 애초에 허용되어서는 안 되는 패턴을 만족시키기 위해 핵심 시스템 제약 조건을 위반하기도 합니다. 이는 우리의 마이그레이션에서 특히 흔했습니다. 예를 들어, 코드 리뷰 도구에 물어보는 대신 커밋 로그를 선형으로 읽어서 변경 사항이 main에 병합된 시점을 찾으려 브루트 포스 방식을 시도한 시스템이 여럿 있었습니다. Anthropic은 또한 적대적 리뷰를 광범위하게 활용하는데, 이는 여러 면에서 놀랍도록 효과적이지만 근시안적일 수도 있어서, 숙련된 엔지니어들은 가상의 우려에 대응해 시스템의 일부를 과도하게 엔지니어링하지 않도록 Claude를 이끌어야 했습니다. 예를 들어, 어떤 리뷰는 다른 내부 서비스를 신뢰하는 문제에서 지나치게 방어적이어서, Claude가 과도한 검증과 복잡성을 추가하게 만들었습니다. 우리 팀원들은 여전히 시스템의 모든 변경 요청을 검토하지만, 이제는 코드의 모든 줄을 읽는 대신 변경 사항의 의도 를 살펴봅니다.
우리는 최적화와 품질을 상당히 개선할 수 있었습니다. Claude가 우리 자신이 할 수 있는 것보다 훨씬 빠르게 방대한 양의 코드를 작성할 수 있는 덕분에, Scion은 우리가 지금까지 작업해 본 코드베이스 중 가장 철저히 테스트되고 가장 잘 방어된 코드베이스에 속합니다. 촉박한 일정에도 불구하고, 우리는 지금까지 겪어 본 모든 사소하지 않은 인프라 및 소스 컨트롤 상호작용에 대한 밀폐형(hermetic) 시뮬레이션은 물론, 퍼징(fuzzing)과 정교한 레이트 리미팅까지 구축할 수 있었습니다. Claude는 또한 전문가라면 며칠 또는 몇 주의 분석과 튜닝이 필요했을 만한 중대한 최적화—예를 들어, 우리 인덱스 중 하나를 놓치게 만든 ancestry 쿼리에 대한 알고리즘 최적화—를 아무렇지 않게 찾아냈고… 그리고 다음 날 그 일을 다시 해냈습니다.
우리는 새로운 형태의 모노레포 보안을 위한 기반을 마련했습니다. 거대한 모노레포에서 안전, 보안, 컴플라이언스를 관리하는 것은 규모를 관리하는 것만큼이나 중요합니다. 우리는 이를 처음부터 염두에 두고 Scion을 구축했습니다. Scion은 저장소에 대한 풍부한 접근 제어를 지원하며, 모노레포의 이점을 잃지 않으면서 가장 민감한 코드를 보호하기 위해 개별 디렉터리에 권한을 적용할 수 있습니다. 나아가 우리가 구축한 코드 리뷰 도구는 승인에 대한 복잡한 의미적 제약 조건을 표현할 수 있어, 주석만 변경하는 간단한 사안과 민감한 논리적 변경을 구분할 수 있으며, 이를 통해 인간 리뷰어가 가장 중대한 변경에 집중할 수 있게 됩니다.
새로운 수준의 운영 우수성이 가능해집니다. 우리 팀은 Claude Tag를 많이 활용하는데, 이는 시스템의 각 컴포넌트를 모니터링하는 데 도움이 되었습니다. 예를 들어, 우리는 Claude에게 단일 컴포넌트의 상태에 집착적으로 집중하도록 임무를 부여한 Slack 채널을 만들었습니다. 우리는 이런 Claude들을 “슈퍼팬(superfans)”이라고 부릅니다. 우리에게는 scion-daemon 슈퍼팬, scion-cache 슈퍼팬, Antique 머지 큐 슈퍼팬 등이 있습니다. 이들은 우리의 텔레메트리와 로그에 접근할 수 있으며, 차트를 새로 고치고 이상한 점을 찾는 것 외에는 할 일이 없는 숙련된 엔지니어처럼 행동합니다. 우리는 모든 시스템에 전통적인 알림도 갖추고 있지만, 슈퍼팬들은 이런 알림들이 상대적으로 단편적으로 보이게 만드는 미묘하고 새로운 문제들을 감지할 수 있습니다.
우리는 기존의 전제를 완전히 다시 생각하고 있습니다. 이 프로젝트는 인간의 규모를 위해 설계된 다른 워크플로우들을 매우 진지하게 재검토하게 만들었습니다. 예를 들어, 제대로 된 머지 큐는 에이전트 규모에서는 크게 의미가 없습니다. 테스트가 실행되는 동안 수백, 심지어 수천 개의 변경 사항이 병합될 수 있다면 CI는 대체 무엇을 의미할까요? 우리는 머지 큐에 대한 전역 저장소 락이라는 업계 표준을 효과적으로 재현하지 못했기에, 대신 병합 후 및 배포 전 자동화 테스트에 투자했습니다. 이는 동시에 진행되는 변경 사항들이 충돌할 수 있음을 의미하지만, Claude는 대개 인간이 충돌을 인식하기도 전에 더 빨리 이를 수정할 수 있습니다.
더 넓은 생태계에 기여하기
우리는 Scion을 점점 더 유능해지는 AI 에이전트들이 제기한 확장성 문제에 대한 답의 한 부분으로 봅니다. 우리는 팀들이 유사한 과제에 어떻게 접근할 수 있는지에 대한 예로 이러한 세부 사항을 공유하는 것이지만, 우리의 해결책이나 고려 사항이 모든 경우에 적합할 것이라고는 기대하지 않습니다.
Scion은 일반적인 용도로 git을 대체하기에 결코 적합하지 않습니다. 우리가 여기서 설명한 개념들은 수만 명의 엔지니어가 있거나 에이전트 무리가 활발히 코드를 작성하는 등 정말로 방대한 모노레포에서만 의미가 있습니다. 게다가 Anthropic은 내부 사용을 위해 토큰을 지출할 수 있는 능력이 다른 어떤 비즈니스가 현실적으로 지출하고자 하는 수준을 훨씬 초과한다는 점에서 독특합니다. 우리는 이를 자체 소프트웨어 개발 필요성을 충족하고, Claude의 역량을 시험하기 위해 수행합니다.
실용적인 관점에서, Scion을 다른 조직들에 폭넓게 유용한 형태로 제공하기는 어렵습니다. Scion은 git과 크게 다르므로 기업들은 개발 수명 주기의 모든 부분을 마이그레이션해야 하며, 자체 코드 리뷰, 코드 검색, CI가 필요합니다. 이러한 컴포넌트들의 우리 내부 버전은 매우 맞춤형이라 다른 조직들이 채택하기 어려울 것이며, 모두를 만족시키려는 공개 버전을 만드는 시도가 실제로는 그다지 유용하지 않을 것이라고 우려합니다.
다만, 이러한 유형의 문제가 앞으로 6개월에서 12개월 사이에 더욱 보편화될 것으로 예상하며, git을 사용하는 모든 회사가 유사한 과제에 각자 혼자 직면하는 것은 엔지니어링 자원의 비효율적인 사용일 것입니다. 이를 고려할 때, 우리가 가장 영향력 있는 일은 우리의 생각을 공유하는 것이라고 생각합니다. 그래야 다른 개발자들이 전체 모델을 벗어나지 않으면서 Scion의 가장 성공적인 부분들을 git에 적용할 수 있기 때문입니다. git 서버가 git 클라이언트와 똑같은 방식으로 작동할 필요는 없습니다. 상당한 확장성 개선을 제공하는 새로운 서버 아키텍처들이 존재합니다. git 플랫폼은 Scion처럼 포괄적인 서버 측 RPC를 제공할 수 있고, 어쩌면 git 클라이언트가 통신 방법을 배울 수 있도록 포지(forge)들 간의 표준화된 방식으로 제공할 수도 있습니다. 협상 프로토콜 역시 오늘날과 정확히 같은 모습일 필요는 없으며, git의 다양한 sparse 및 shallow 기능들도 서로 잘 조합되도록 만들 수 있습니다.
마지막으로, git 커뮤니티가 거의 20년 동안 수백만 명의 개발자를 위한 플랫폼 확장에 힘써왔음을 인정하고 싶습니다. 우리의 기여는 훨씬 좁은 범위의 것입니다. 에이전트 기반 소프트웨어 개발이 이러한 시스템과 어떻게 상호작용하는지에 대한 초기 관점을 공유함으로써, GitHub, GitLab, OSS 커뮤니티와 협력하여 개발자들의 변화하는 요구를 지원할 수 있도록 하는 것입니다. 소프트웨어 개발 수명 주기가 AI의 지수적 성장과 교차하는 이 시점에서 우리 모두는 같은 여정에 함께 있습니다.
각주
01병합(merge)의 첫 번째 부모를 기준으로 변경된 파일을 저장하는 것은 스타일적인 선택입니다. 실제로 우리는 모노레포의 트렁크 기반 개발에서 사람들이 메인 라인에 있는 커밋의 히스토리나 blame에만 관심을 갖는다는 것을 발견했습니다.
02구체적으로, Sapling의 서버 컴포넌트인 Mononoke입니다. 이는 우리가 Scion에서 사용하는 많은 기법들, 특히 Bonsai 데이터 모델을 개척했습니다.
저자 및 감사의 말씀
감사의 말씀
Nick G.와 소스 컨트롤 팀(S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P.)이 집필했습니다. 이 야심 찬 여정에서 소스 컨트롤 팀을 지원해 주신 Vilas J.와 Sergiu D., 그리고 Antique에 초기 기여를 해주신 Amir O.께 감사를 전합니다.