Aspen - Git의 설계 범위를 넘어 에이전트 커밋을 확장하는 오픈소스 서버

Aspen은 수백 개 에이전트가 하나의 저장소에 동시에 푸시하는 환경을 위한 오픈소스 Git 서버로, OpenAI의 내부 백엔드 Pando 설계를 독립적으로 구현함 저장소 전체가 아닌 브랜치별 비교 후 교체(compare-and-swap) 로 푸시를 처리하고, 저장된 팩(pack)을 재사용해 클라이언트마다 같은 이력을 다시 압축하는 작업을 없앰 확장성을 위해 모든 브랜치의 일관된 단일 스냅샷과 클라이언트별 맞춤 팩을 포기함 자체 측정에서 S3 Standard를 사용해 단일 저장소에 초당 567회 푸시를 5분간 오류 없이 유지함. 다만 브랜치 전용 URL을 사용한 git.git 테스트이며, 매우 큰 모노레포에서는 현재 처리율이 낮아짐 일반 Git 클라이언트의 HTTPS/SSH 접속을 지원하지만 프리알파 단계임. 웹 UI, 부분 클론, SHA-256 저장소, RSA SSH 키는 아직 지원하지 않음 에이전트의 푸시가 만드는 서버 병목 사람은 하루 몇 차례 푸시하지만 에이전트는 몇 분마다 푸시함. 수백 개 에이전트가 함께 작업하면 수백 개 브랜치가 동시에 바뀌고, 푸시마다 CI fetch가 뒤따름 전통적인 Git 서버는 저장소의 모든 푸시를 하나의 큐로 처리하므로 서로 다른 브랜치의 푸시도 대기하게 됨 클론과 fetch마다 새 팩을 만들면서 같은 이력을 반복 압축함. 팩은 파일, 디렉터리, 커밋 객체를 묶어 전송하는 Git 형식이며, 이 구조에서는 서버 작업량이 새 코드의 양보다 클라이언트 수에 따라 늘어남 OpenAI는 모노레포에서 이 문제를 겪고 내부 Git 백엔드 Pando를 구축함 Scaling Git at OpenAI의 설계를 바탕으로 만든 Aspen은 OpenAI와 제휴하지 않은 독립 구현이며, Apache License 2.0으로 공개됨 1,000명의 작성자가 각각 커밋 10개를 푸시하는 시각화는 구조 차이를 보여주는 단순화된 모델이지 벤치마크가 아님. 전통적인 서버의 저장소 단위 대기열과 Aspen의 브랜치별 처리 및 저장 팩 재사용을 비교함 두 가지 보장을 포기한 구조 Aspen은 HTTPS와 SSH를 통한 일반 Git 프로토콜을 사용함. 클라이언트의 git push, git clone 사용 방식은 그대로이며 변경은 서버에 집중됨 모든 브랜치를 한 시점의 스냅샷으로 보는 보장 대신 브랜치별 버전 체인을 Postgres에 유지함 푸시는 팩을 업로드한 뒤 단일 행에 비교 후 교체를 수행해, 브랜치가 여전히...