Anthropic기술 블로그
Anthropic의 소스 컨트롤 재설계
하루 머지 건수가 10배 넘게 늘면서 소스 컨트롤이 개발 속도를 가로막는 가장 큰 병목이 되었습니다. 이 글에서는 자체 버전 관리 시스템으로 5개월 만에 전환한 과정을 소개합니다.
Anthropic에서는 이제 코딩이 시스템 구축이나 연구의 병목이 아닙니다. Claude는 연구 루프를 자율적으로 반복하고, 복잡한 프로그램을 마이크로 최적화하며, 새로운 서비스를 처음부터 만들어 냅니다. 그 속도와 규모는 전에 본 적 없는 수준입니다. 이제 병목은 사람의 작업 규모에 맞춰 만들어진 개발자 인프라, 즉 소스 컨트롤과 빌드, CI입니다.
2026년 5월 Anthropic의 하루 평균 머지 건수는 약 2,500건이었습니다. 9월에는 하루 3만 건이 넘었습니다. 이 증가세가 가까운 시일 내에 꺾일 것으로 보지 않습니다. 코드를 머지하려는 잠재 수요는 사실상 무한하고, 병목을 하나 없앨 때마다 코드 생산량이 곧바로 더 늘어나기 때문입니다.
이 성장을 감당하기 위해 우리는 자체 버전 관리 시스템인 Scion을 만들었고, 5개월 만에 모노레포를 git에서 완전히 옮겼습니다. 같은 기간에 코드 리뷰 화면(Antique), 코드 검색, 세분화된 소스 컨트롤 IAM 시스템, 리뷰를 마친 대량의 코드를 관리하고 반영하는 새로운 방식 등도 함께 만들어 배포했습니다. 이 글에서는 그중 Scion을 만든 과정에 집중하겠습니다. Scion은 흥미로운 사례입니다. Claude의 코드 작성 능력이 애초에 이런 상황을 불러왔고 동시에 그 문제를 해결할 고품질의 확장 가능한 시스템을 빠르게 만들 수 있었던 비결이기도 하기 때문입니다.
모노레포의 성장
무엇을 만들었는지 살펴보기 전에, 우리의 워크로드가 매우 특이하다는 점부터 짚어야 합니다. Anthropic은 거의 모든 회사보다 훨씬 많이 Claude로 소프트웨어를 작성하므로, 사람의 작업 규모에 맞춘 도구가 어디서부터 한계를 드러내는지 가장 먼저 겪는 경우가 많습니다. 소스 컨트롤은 그 한 예일 뿐입니다. 가까운 시일 안에 많은 조직이 같은 문제를 겪지는 않겠지만, AI 코딩 도구를 쓰는 다른 조직도 머지않아 같은 문제에 부딪힐 것으로 봅니다. 그래서 우리가 만든 것과 배운 점을 공유하려 합니다.
git은 분산형 시스템입니다. 모든 클론이 그 자체로 완전한 저장소여서, 오프라인 상태에서도 diff를 계산하고, 히스토리와 blame을 조회하고, 어떤 리비전이든 체크아웃할 수 있습니다. 대부분의 저장소에는 이것이 올바른 설계이며, git이 표준이 된 큰 이유이기도 합니다.
하지만 모노레포가 커지면서 이 설계는 점점 맞지 않게 되었습니다. 메인 브랜치의 히스토리만 약 100GB이고, 압축한 작업 사본도 25GB가 넘습니다. 개발자 환경, 에이전트 샌드박스, 연구 작업은 제외하고 CI에서만 하루에 약 2,500만 번 코드를 체크아웃합니다. 이를 단순하게 fetch하면 git 트래픽이 하루 600PB를 넘습니다.
git에는 저장소의 일부만 다루는 도구로 shallow clone, sparse checkout, promisor remote가 있습니다. 이와 별도로 대형 모노레포를 위한 일반적인 우회책도 있습니다. 내부 git 미러, 블롭 스토리지에 보관하는 저장소 스냅샷(seed) 같은 것들입니다. 우리는 이 방법을 모두 썼고, 한창일 때는 부하를 감당하려고 내부 git 미러를 수백 대 운영했습니다. 덕분에 시간은 벌었지만, 머지 속도가 빨라지면서 운영이 점점 어려워졌습니다. seed는 갱신 주기 사이에 main의 최신 지점에서 점점 멀어졌고, 부분 클론에서 diff나 blame처럼 히스토리에 의존하는 작업을 계속 동작시키려면 갈수록 손이 많이 갔습니다.
한 걸음 물러서서 보니, 우리도 대부분의 회사처럼 git을 원본이 하나뿐인 중앙집중형 시스템으로 쓰고 있었고, 클라이언트는 거의 전부 항상 온라인일 수밖에 없는 에이전트와 작업이었습니다. git이 분산·오프라인 작업에 뛰어나게 만들어 주는 특성이, 저장소가 커질수록 오히려 확장을 가로막고 있었습니다. 그래서 질문을 바꿨습니다. 에이전트가 항상 온라인이라는 전제로 소스 컨트롤을 처음부터 설계한다면 어떤 모습일까요?
에이전트 규모를 위한 소스 컨트롤의 원칙
에이전트 기반 코딩이 보편화되면서 소프트웨어 개발에 관한 여러 통념이 바뀌고 있습니다. 우리는 Scion을 만들 때 이런 변화를 받아들였고, 그 덕분에 몇 가지 핵심 원칙에서 git과 근본적으로 다른 접근을 택할 수 있었습니다. 거대한 모노레포를 위한 소스 컨트롤에는 선행 사례가 있습니다. 대표적으로 Google의 Piper와 Meta의 Sapling이 있으며, 우리는 이들이 어렵게 얻은 교훈을 염두에 두고 Scion을 만들 수 있었습니다. 우리의 원칙은 다음과 같습니다.
클라이언트는 항상 온라인입니다. git은 클라이언트가 오프라인으로 작업하며 저장소 전체 사본이 필요하다고 가정합니다. 우리 클라이언트는 거의 전부 에이전트와 작업이므로, Scion의 클라이언트와 프로토콜은 언제든 접속할 수 있는 서버를 전제로 설계했고, 클라이언트는 필요할 때 데이터를 가져옵니다.
클라이언트와 서버는 역할이 비대칭입니다. git에서는 모든 클라이언트가 완전한 서버 역할을 할 수 있습니다. Scion에서는 서버가 파일 히스토리와 blame에 대한 질의에 답하고, 커밋을 만들고, 머지와 리베이스를 수행합니다. 클라이언트는 크기가 제한된 로컬 오브젝트 캐시를 유지하고, 작업 사본 파일을 디스크에 배치하고, 파일 시스템 변경을 감시하며, 사용자가 서버를 편하게 쓸 수 있게 해 줍니다. 클라이언트가 스스로 계산할 수 있는 일은 거의 없지만, 그 대신 로컬에 필요한 데이터가 훨씬 적습니다.
포괄적인 소스 컨트롤 서비스는 많은 새로운 애플리케이션의 기반이 될 수 있습니다. git에서는 마지막으로 한 줄을 수정한 사람이 누구인지, 두 커밋이 어떤 관계인지 같은 질문을 하려면 CI 작업이나 도구가 저장소 사본을 직접 유지하거나 특정 벤더의 API가 답을 주기를 기대해야 합니다. Scion에서는 클라이언트가 쓰는 모든 소스 컨트롤 질의를 API로도 제공하므로, 많은 경우 작업에 로컬 저장소가 아예 필요 없습니다. 자동 bisect와 revert 파이프라인 같은 여러 내부 도구는, 소스 컨트롤에 저렴하게 프로그래밍 방식으로 접근할 수 없었다면 대규모로 운영하기 어려웠을 것입니다.
모든 것은 수평 확장이 가능해야 합니다. 한창일 때 우리는 git 미러를 수백 대 운영했는데, 이는 용량에 큰 부담을 주었고 저장소가 미러의 디스크나 메모리 한계를 넘어서자 더는 확장되지 않았습니다. Scion에서는 저장소 데이터가 분산되어 있고 모든 구성 요소를 독립적으로 확장할 수 있습니다. 서버를 포함해 어디에도 저장소 전체를 완전히 펼쳐 놓은 사본이 없습니다. packfile(git이 오브젝트를 압축해 묶은 단위)에 해당하는 것도 없어서 저장소 유지보수가 필요 없습니다.
커밋은 저렴하고, 증분 방식이며, 락이 없어야 합니다. git에서는 로컬에서 커밋한 뒤 push해서 작업을 공유합니다. Scion에서는 모든 커밋, 리베이스, 머지가 서버에서 일어나므로 push할 것이 없지만, 각 작업이 빨라야 합니다. 커밋을 만들고 하위 데이터 구조를 갱신하는 비용은 저장소 전체 크기가 아니라 변경 크기에 비례해야 하며, 그렇지 않으면 서버가 감당하지 못합니다. Scion의 개발 수명 주기에서는 main ref나 릴리스 브랜치를 제외하고 ref(브랜치와 태그처럼 커밋을 가리키는 포인터)를 권장하지 않습니다. 모든 서버가 합의해야 하는 전역 상태는 앞으로 확장성 문제로 이어질 수 있기 때문입니다.
작업 사본은 선택 사항이며, 설계상 sparse합니다. 모노레포가 매우 크고 CI를 위해 하루에 수천만 번 코드를 체크아웃하므로, 가능하면 체크아웃을 피하고 싶었습니다. 예를 들어 Scion에서는 커밋과 머지 베이스 사이의 diff가 필요한 CI 작업이 서버에 직접 요청하면 됩니다. 쓰기도 마찬가지로, 많은 쓰기 워크로드가 체크아웃 없이 API만으로 동작할 수 있습니다. Scion의 프로토콜은 클라이언트가 요청한 디렉터리만 담는 sparse 체크아웃과, 파일을 필요할 때 만들어 내는 가상화 체크아웃을 중심으로 설계되었습니다. 그래서 작업에 디스크의 파일이 필요할 때도 클라이언트는 실제로 읽는 만큼만 비용을 냅니다.
Scion의 동작 방식
Scion을 만들 때 이 원칙들이 실제로 어떻게 구현되었는지 이해해 두면 도움이 됩니다. 여기서 얻은 통찰은 다른 소스 컨트롤 시스템에도, 더 넓게는 소프트웨어 개발 수명 주기의 다른 단계에도 적용할 수 있습니다.
데이터 구조
Scion의 작업 단위는 write-ahead log의 항목인 "changeset"입니다. changeset에는 git 커밋에 담기는 대부분의 정보가 들어 있습니다. 다만 git 커밋이 트리를 가리키는 포인터를 저장하는 반면, changeset은 첫 번째 부모를 기준으로 변경된 파일 목록과, 블롭 스토리지에 있는 압축된 파일 내용을 가리키는 콘텐츠 주소 기반 포인터를 저장합니다.1 changeset은 서버에서 생성되며 어디서든 즉시 사용할 수 있습니다.
이 구조 덕분에 처리량이 매우 높은 상태로 changeset을 받을 수 있습니다. 받아야 할 packfile도, 락이나 서버 간 조율도, 옮겨야 할 ref도 없기 때문입니다. Scion도 기술적으로는 ref를 지원하지만, 커밋을 만들 때나 가져올 때 ref가 관여하지 않으므로 ref 이동은 changeset 생성과 별개로 Spanner의 한 행에 대한 compare-and-swap으로 처리됩니다.
changeset은 변경된 내용만 기록하므로, 그것만으로는 한 줄을 마지막으로 수정한 사람이나 어떤 파일에 영향을 준 커밋 같은 질문에 빠르게 답할 수 없습니다. 이런 질문에 답하려고 Scion은 changeset으로부터 파일 blame과 경로 히스토리 전용 구조, 커밋 그래프용 스킵 리스트 같은 추가 데이터 구조를 만듭니다. changeset에 직접 속하지 않는 모든 것을 "파생 데이터"라 부르며, 이는 모두 하나의 범용 메커니즘으로 계산합니다. 파생 데이터는 종류마다 재귀적으로 정의되므로, 어떤 changeset의 값은 그 부모 changeset들의 값으로부터 계산됩니다.
이 메커니즘에는 세 가지 장점이 있습니다. 첫째, 새로운 데이터 구조가 어떤 작업을 빠르게 해 줄 수 있을 때 새로운 파생 데이터 유형을 쉽게 추가할 수 있습니다. 둘째, 유형별로 즉시 계산할지 나중으로 미룰지 선택할 수 있어서 필요 없는 데이터를 만들지 않습니다. 셋째, 클라이언트는 이 데이터 구조의 내부를 볼 수 없으므로 클라이언트를 바꾸지 않고도 최적화할 수 있습니다. 시스템이 커지면서 복사 감지나 경로 기반 파일 검색용 인덱스처럼 새로운 파생 데이터 유형을 여러 번 추가했습니다.
Scion 확장하기
소수의 Scion 서버가 changeset 조회, diff 계산, 머지 베이스 탐색, 블롭 fetch 등 클라이언트에 필요한 모든 작업에 소스 컨트롤 API를 제공합니다. 모든 소스 컨트롤 데이터는 콘텐츠 주소 기반이라 한 번 저장되면 바뀌지 않으며, 어느 서버든 다른 서버에 확인하지 않고 캐시할 수 있습니다. 그 결과 서버는 수평 확장이 가능하고 서로 거의 조율할 필요가 없습니다. 서버는 본질적으로 대형 캐시이며, 필요하면 파생 데이터를 즉석에서 계산해 결과를 Spanner에 다시 기록할 수도 있습니다.
Scion을 사용하는 여러 소비자는 더 이상 자체 로컬 저장소를 유지할 필요가 없습니다. 소스 컨트롤에 질의해야 하는 CI 작업이나 도구, 특히 커밋 계보와 blame을 묻는 경우에는 저장소를 가져와 유지하는 일이 상당한 운영 부담이었습니다. 마이그레이션 초기에는 자체 클라이언트도, 저장소 포맷도, 프로토콜도 없었기 때문에 Scion은 이런 "메타데이터" 질의에만 응답했습니다. 파일 내용을 가져오고 작업 사본을 만들어 내는 일은 데이터 집약도가 훨씬 높아서 별도의 설계가 필요했습니다.
Scion의 scn 클라이언트는 git의 fetch 프로토콜과 중요한 부분에서 다르며, 그 덕분에 git 서버보다 CPU를 훨씬 적게 쓰는 고도로 확장 가능한 아키텍처를 갖췄습니다. Scion의 negotiation은 클라이언트가 이미 가진 것을 서버에 알리지 않고, 클라이언트가 원하는 트리와 블롭에 대해서만 이루어집니다. 클라이언트는 루트 트리에서 시작해 로컬 저장소에 없는 트리를 확인하고 재귀적으로 요청한 다음, 블롭에 대해서도 같은 과정을 반복합니다. 모든 요청은 절대 바뀌지 않는 특정 오브젝트를 대상으로 하므로 어떤 캐시든 응답할 수 있고, 아키텍처는 전통적인 계층형 캐시와 매우 비슷합니다. 수 GB짜리 packfile 응답이 하나도 없으므로 과정도 효율적이고 중단 후 재개할 수 있습니다. sparse 체크아웃은 물론 가상화 체크아웃에도 별도 지원이 필요 없습니다. 클라이언트가 원하지 않는 트리를 요청하지 않으면 그만이기 때문입니다.
실제 운영 환경에서 클라이언트는 소켓을 통해 노드 전체의 오브젝트를 저장하는 데몬인 scion-daemon과 통신합니다. 대부분의 노드는 모노레포에 접근해야 하고, 같은 노드의 작업들은 대부분 같은 오브젝트를 재사용합니다. 각 데몬은 주기적으로 갱신되는 스냅샷에서 시작하며, 이후에는 같은 리전의 트리·블롭 캐시 서버인 scion-cache와만 통신합니다. 이 캐시 서버는 데몬이 그대로 소비할 수 있는 디스크 포맷으로 메모리에서 오브젝트를 바로 스트리밍하므로, 클라이언트에 없는 오브젝트를 계산하거나 delta 압축을 하는 데 시간을 쓰지 않습니다. 캐시에 오브젝트가 없으면 원본 데이터를 가진 scion-server에 요청하고, scion-server는 필요에 따라 Spanner나 클라우드 스토리지에서 읽어 옵니다.
scion-daemon, scion-cache, scion-server는 이 프로토콜에서 모두 동일한 RPC에 응답하므로 클라이언트는 캐시 토폴로지를 알 필요가 없습니다. 이론상 어떤 계층도 다른 계층과 통신할 수 있지만, 장애 도메인을 격리하기 위해 계층 구조를 엄격하게 강제합니다. 리전 scion-cache의 장애가 상위 scion-server에 과부하를 일으켜 시스템 전체가 중단되는 상황을 피하려는 것입니다.
이 시스템의 각 계층은 99%가 넘는 캐시 적중률을 유지하며 오래 유지되는 상태가 필요 없어서, 필요하면 쉽게 확장할 수 있습니다. 지금 Scion 인프라의 규모는 CPU와 메모리 요구량 기준으로 기존 git 미러링 인프라의 200분의 1입니다. CI와 연구 작업은 코드를 두 자릿수 배 빠르게(분 단위가 아니라 초 단위로) 체크아웃하며, 덕분에 전체 플릿에서 상당한 용량이 확보되었습니다. CI만 해도 CPU 용량을 25% 아꼈습니다. 클라이언트도 캐시도 저장소 유지보수를 할 필요가 없어서 작업의 수명 주기 관리도 단순해졌습니다.
Scion을 만들며 배운 것
Scion 개발은 Claude Mythos Preview와 Claude Tag가 내부에 공개된 시기와 비슷하게 시작했습니다. 이 두 릴리스는 Scion의 필요성을 동시에 키웠고 Scion을 만드는 속도도 눈에 띄게 높였습니다.
특히 인상 깊었던 사례가 있습니다. 올해 초 우리는 git에서 Scion으로 데이터를 가져오는 ingestion 파이프라인의 첫 버전을 프로토타입으로 대부분 손수 작성했습니다. 꽤 괜찮다고 생각했는데, 내부용 초기 Claude Mythos Preview 스냅샷을 손에 넣고 나서 생각이 바뀌었습니다. 전체를 다시 작성해 달라고 요청했더니, 추가 지시 없이도 메모리는 20배 적게 쓰고 속도는 4배 빠르면서 ingestion 순서와 데이터 구조에 걸친 암묵적 불변 조건을 모두 지킨 버전을 내놓았습니다.
Scion을 만들고 운영하며 배운 점은 에이전트 규모의 소프트웨어를 만드는 일이 어떤 모습일지에 대해 흥미로운 시사점을 줍니다.
소규모 팀의 빠른 개발이 더 흔해질 것입니다. 일곱 명으로 이루어진 팀이 Scion 과 Antique(코드 리뷰 도구로, 이것만으로도 블로그 글 한 편을 따로 쓸 수 있습니다)를 만들었고, 관련 시스템 여섯 개 안팎도 함께 개발해 5개월 만에 모두 완전히 전환했습니다. 이 모든 일을 하루 머지 코드량이 10배 늘어나는 와중에 해냈습니다. 예전 같았으면 이런 소스 컨트롤 시스템을 개발하고 배포하려면 훨씬 많은 엔지니어가 몇 년에 걸쳐 단계적으로 마이그레이션해야 했을 것입니다. 앞으로는 이렇게 빠르고 민첩한 마이그레이션이 더 흔해질 것으로 봅니다.
엔지니어의 가치는 줄지 않았지만, 하는 일은 달라지고 있습니다. 이 시스템을 만든 엔지니어는 모두 지금은 Claude가 자신들보다 코드를 더 잘 작성한다고 평가할 것입니다. 하지만 시스템 간 상위 수준의 구성 요소와 설계 수준의 트레이드오프를 이해하는 일, 해결하려는 문제와 달성해야 할 규모를 판단해 근거 있는 선택을 하는 일은 여전히 엔지니어의 몫이었고 대체할 수 없는 가치였습니다. 엔지니어의 역할이 Claude에게 "안 돼"라고 말하는 것일 때도 아주 많았습니다. 에이전트는 애초에 허용되어서는 안 되는 패턴을 충족하려고 시스템의 핵심 제약을 어기기도 합니다. 마이그레이션 과정에서 특히 흔했습니다. 예를 들어 여러 시스템이 변경이 main에 머지된 시점을 코드 리뷰 도구에 묻지 않고, 커밋 로그를 처음부터 선형으로 읽는 무식한 방법으로 찾으려 했습니다. Anthropic은 적대적 리뷰도 폭넓게 활용하는데, 여러모로 매우 효과적이지만 시야가 좁아질 수도 있습니다. 그래서 숙련된 엔지니어가 가상의 우려에 대응하느라 시스템 일부를 과하게 설계하는 쪽으로 Claude가 가지 않도록 방향을 잡아야 했습니다. 예를 들어 한 리뷰가 다른 내부 서비스를 신뢰하는 데 지나치게 방어적이었고, 그 결과 Claude가 과도한 검증과 복잡성을 추가했습니다. 팀원들은 지금도 이 시스템의 모든 변경 요청을 리뷰하지만, 이제는 모든 코드를 한 줄씩 읽기보다 변경의 의도를 살펴봅니다.
최적화와 품질을 크게 끌어올릴 수 있었습니다. Claude는 방대한 양의 코드를 우리보다 훨씬 빠르게 작성할 수 있어서, Scion은 우리가 다뤄 본 코드베이스 중 가장 테스트가 잘 되어 있고 방어가 탄탄한 편입니다. 빠듯한 일정이었는데도 지금까지 마주친 모든 비자명한 인프라 및 소스 컨트롤 상호작용에 대한 밀폐형(hermetic) 시뮬레이션을 만들었고, fuzzing과 정교한 rate limiting도 갖췄습니다. Claude는 전문가가 며칠, 길게는 몇 주에 걸쳐 분석하고 튜닝해야 찾을 만한 중요한 최적화도 대수롭지 않게 찾아냈습니다. 인덱스 하나를 놓치고 있던 계보 질의의 알고리즘 최적화가 한 예입니다. 그러고는 다음 날 같은 일을 또 해냈습니다.
모노레포 보안의 새로운 방식을 위한 토대를 닦았습니다. 거대한 모노레포에서 안전성과 보안, 컴플라이언스를 관리하는 일은 크기와 규모를 관리하는 일만큼 중요합니다. 우리는 처음부터 이를 염두에 두고 Scion을 만들었습니다. Scion은 저장소 단위의 세분화된 접근 제어를 지원하고, 개별 디렉터리에도 권한을 적용할 수 있습니다. 그래서 가장 민감한 코드를 보호하면서도 모노레포의 이점을 잃지 않습니다. 또한 우리가 만든 코드 리뷰 도구는 승인에 대한 복잡한 의미 기반 제약을 표현할 수 있습니다. 덕분에 주석만 바꾼 변경과 민감한 로직 변경을 구분할 수 있고, 사람 리뷰어는 가장 중요한 변경에 집중할 수 있습니다.
새로운 수준의 운영 우수성이 가능합니다. 우리 팀은 Claude Tag를 적극적으로 활용하며, 이는 시스템의 각 구성 요소를 모니터링하는 데 도움이 되었습니다. 예를 들어 Slack 채널을 만들어 Claude에게 단일 구성 요소의 상태에 집요하게 집중하는 임무를 맡겼습니다. 우리는 이런 Claude를 "슈퍼팬"이라고 부릅니다. 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) 간에 표준화된 방식으로 제공할 수도 있습니다. negotiation 프로토콜도 지금과 똑같을 필요가 없고, git의 여러 sparse·shallow 기능이 서로 잘 조합되도록 만들 수 있습니다.
마지막으로, git 커뮤니티가 거의 20년 동안 수백만 개발자를 위해 이 플랫폼을 확장해 왔다는 점을 인정하고자 합니다. 우리의 기여는 훨씬 좁습니다. 에이전트 기반 소프트웨어 개발이 이런 시스템과 어떻게 맞물리는지에 대한 초기 관찰을 공유하여, GitHub, GitLab, 오픈소스 커뮤니티와 협력해 달라지는 개발자의 요구를 지원하려는 것입니다. 소프트웨어 개발 수명 주기가 AI의 기하급수적 성장과 만나는 지금, 우리는 모두 같은 배를 타고 있습니다.
감사의 글
글: Nick G.와 소스 컨트롤 팀(S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P.). 이 야심찬 여정에서 소스 컨트롤 팀을 지원해 준 Vilas J.와 Sergiu D., Antique 초기 개발에 기여한 Amir O.에게 감사드립니다.
