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를 구축함
- 1,000명의 작성자가 각각 커밋 10개를 푸시하는 시각화는 구조 차이를 보여주는
단순화된 모델이지 벤치마크가 아님. 전통적인 서버의 저장소 단위 대기열과 Aspen의 브랜치별 처리 및 저장 팩 재사용을 비교함
두 가지 보장을 포기한 구조
- Aspen은
HTTPS와 SSH를 통한 일반 Git 프로토콜을 사용함. 클라이언트의 git push
, git clone
사용 방식은 그대로이며 변경은 서버에 집중됨
- 모든 브랜치를 한 시점의 스냅샷으로 보는 보장 대신
브랜치별 버전 체인을 Postgres에 유지함
- 푸시는 팩을 업로드한 뒤 단일 행에 비교 후 교체를 수행해, 브랜치가 여전히 커밋 A를 가리킬 때만 B로 옮김
- 서로 다른 브랜치의 푸시는 기다리지 않음. 같은 브랜치에 대한 두 푸시는 경쟁하며 하나만 성공하고, 나머지는 Git의 일반적인
fetch first
응답을 받아 리베이스함
-
여러 브랜치를 읽는 클라이언트는 각각 조금씩 다른 시점의 상태를 볼 수 있음
-
클라이언트마다 맞춤 팩을 생성하는 대신
업로드된 팩을 저장하고 재사용함
-
푸시를 객체별로 풀지 않고 팩을 검사하며, 서버에 이미 있어 Git이 생략한 객체를 보충한 뒤 객체 스토리지에 저장함
-
저장소로 S3, GCS, Azure Blob 또는 일반 디렉터리를 사용할 수 있음
-
fetch에서는 클라이언트에 없는 객체가 담긴 저장 팩을 찾아 재압축 없이 스트리밍함. 서명된 URL로
CDN에서 직접 다운로드하게 할 수도 있음
-
기본 구성은 일반 Git 클라이언트와 Postgres 및 객체 스토리지 사이에 놓인
무상태 서버임. 푸시는 팩 하나를 쓰고 브랜치 행을 교체하며, fetch는 브랜치 행을 읽고 기존 팩을 전송함
누구나 푸시할 수 있는 캔버스 데모
- 공유 캔버스는 로그인 없이 사용하는
64 × 64 픽셀 데모임. 각 픽셀은 Git 저장소의 파일이고, 타일을 클릭할 때마다 커밋 하나와 Aspen으로의 푸시 하나가 발생함
- 푸시는
paint/
브랜치로 들어가며 봇이 이를 main
에 병합함
main
은 GitHub 저장소에 미러링되고 README에서 캔버스를 보여줌
- 캔버스 이미지는 2초마다 갱신되며, 규칙과 팔레트는
TILES.md
에 있음
- 터미널에서 클론한 뒤 타일 파일을 수정해 푸시할 수도 있음. 페이지의
Copy prompt
를 Claude Code, Codex 등 코딩 에이전트에 전달하면 에이전트가 그림과 위치를 묻고 미리보기를 보여준 뒤 승인받아 푸시함
trunk만 광고하는 푸시
- 일반 서버는 푸시 시작 시 모든 브랜치를 나열해 클라이언트가 서버에 이미 있는 객체를 생략하게 함. 브랜치가 100만 개라면
브랜치 목록 자체가 거대해지고, 생성되는 팩도 당시 광고된 브랜치에 의존해 다른 클라이언트가 재사용하기 어려워짐
- Aspen은
trunk 브랜치만 광고하므로 푸시 팩에 trunk 이후의 모든 변경이 담김. trunk를 가진 클라이언트는 그 팩 하나로 해당 브랜치를 가져올 수 있음
- 푸시 크기는 조금 커지지만
협상 규모는 브랜치 수와 무관하게 유지됨. 사용자에게 보이는 차이로 git push --force
와 --delete
에는 추가로 -o force
가 필요함
팩 압축 병합과 얕은 클론
-
푸시마다 작은 팩 하나를 저장하면 하루 뒤처진 클라이언트가 수만 개 팩을 받아야 할 수 있음. Aspen은
LSM 트리 방식의 압축 병합(compaction) 으로 팩을 백그라운드에서 16개씩 계층적으로 합침
-
새 클론에는 소수의 큰 팩을, 거의 최신인 클라이언트에는 소수의 작은 팩을 전송함
-
시각화는 네 가지 크기의 팩을 유지하고, 클라이언트와 trunk 사이에서 각 단계에 맞는
가장 큰 팩을 선택함
-
클라이언트가 v1,300이고 trunk가 v5,000인 예에서는 다운로드가
3,700개에서 55개로 줄어듦
-
긴 중간 구간에는 큰 팩을, 양 끝에는 작은 팩을 사용함
-
CI의 기본적인
--depth=1
fetch를 위한 얕은 클론 전용 경로도 있음. 브랜치 끝 커밋의 depth-1 팩을 한 번 생성해 요청하는 모든 CI 작업에 재사용함
처리량 측정과 비교의 한계
- 에이전트 환경의 핵심 지표는 하나의 저장소에서
안전하게 저장을 마친 초당 푸시 수임
- Aspen 자체 측정은
초당 567회를 5분간 오류 없이 유지함
- 8코어 서버 1대, S3 Standard, 4코어 Postgres를 사용하고 브랜치 전용 URL로 git.git에 푸시함
- git.git의 규모는 약 4,500개 파일과 75,000개 커밋임
- Git이
ok
를 출력하기 전에 S3와 Postgres에 저장을 마쳤으며, 푸시 지연 중앙값은 208ms, 99백분위는 314ms였음
-
다른 클라이언트가 승인된 푸시를 확인하기까지의 지연 중앙값은 30ms였음
-
Cursor의 Origin 공개 수치는 S3 Standard에서 최대
초당 120회, S3 Express One Zone에서 초당 300회 초과임
-
Origin은 저장소별 단일 로그를 거치며, 선행 기록 로그에 저장한 뒤 푸시를 승인함
-
Cursor는 복제된 클러스터와 크기를 공개하지 않은 자체 모노레포를 사용했으므로 Aspen 측정과 조건이 다름
-
Aspen은 같은 브랜치의 푸시만 순서대로 처리하므로
저장소 전체를 단일 순서로 처리할 때의 상한은 없음. 다만 저장소가 커지면 푸시당 비용도 증가해, 매우 큰 모노레포에서는 현재 처리율이 낮아지며 이 부분을 개선 중임
-
OpenAI는 Pando의 푸시 처리율을 공개하지 않았으며, 기존 시스템 대비
푸시 지연 중앙값 약 80% 감소, 소수 코어로 하루 1PB의 Git 데이터 제공, 10Gbps 링크를 채우는 클론 성능을 공개함
-
Aspen과 비교할 수 있는 것은 푸시 간 대기를 없애고 저장된 팩으로 fetch를 처리하는
설계상의 특성이며, Pando의 수치를 Aspen 성능으로 볼 수는 없음
main 반영은 별도의 직렬 작업
main에 반영하는 작업은 직전 반영 결과에 의존하므로 개별 반영을 순차 실행해야 함. Aspen은 이 방식에서 초당 약 4회를 처리하며, 부하보다 왕복 통신 지연의 제약을 받음
- 서버 측
병합 큐는 여러 PR을 각각 별도 커밋으로 유지하면서 main을 한 번 갱신해 반영할 수 있음. 처리량은 아직 측정하지 않았으며 측정 후 공개할 예정임
- 푸시 처리량과 main 반영 수치 모두
CI 실행을 포함하지 않음
실행 환경, 검증, 현재 지원 범위
- Aspen 코드는 공개되어 있으며,
aspen dev
로 SQLite와 로컬 디렉터리를 사용하는 서버를 노트북에서 실행할 수 있음
-
팀 배포용 Docker Compose 구성과 Helm 차트가 있음
-
AWS, Google Cloud, Azure, Hetzner용 Terraform을 제공함
-
호환성 검증은
일반 Git 서버와 결과가 일치하는지를 기준으로 함
-
차등 테스트가 무작위 푸시, 삭제, 경쟁 상황을 Aspen과 Git 서버에 재현하고 동일한 결과를 요구함
-
매일 밤 Git 2.30부터 최신 버전 및 JGit으로 테스트함
-
퍼저와 푸시 도중 서버를 종료하는 카오스 테스트도 실행함
-
개발은 Pando처럼 대부분 에이전트가 수행함.
Reason 하나가 4일 동안 151개 PR을 병합하며 첫 커밋부터 공개까지 진행함
-
현재는
프리알파 Git 서버이며 웹 UI는 없음. 부분 클론, SHA-256 저장소, RSA SSH 키도 아직 지원하지 않으며, 단일 저장소에서 에이전트를 운영하는 사용자의 테스트와 GitHub 피드백을 받고 있음
댓글과 토론