요약
GitHub이 에이전트 수천 개가 저장소 하나에 동시에 푸시해도 버티도록 Git 저장 구조를 새로 짰습니다.
GitHub 엔지니어 카르티크 라만과 브라이언 셀렌자가 쓴 글입니다. AI 에이전트 탓에 한 저장소의 하루 요청이 3월 평균 4,400만 건에서 5월 평균 1억 8,100만 건으로 늘자, 저장소 하나의 처리 한계를 100배 이상 키우는 Project Rubicon을 시작했습니다.
왜 중요한가
- 저장과 계산을 떼어 내서, 요청을 받는 서버는 언제든 버리고 새로 띄울 수 있게 됐습니다.
- 지금은 가장 바쁜 저장소도 초당 쓰기가 수십 건 수준이지만, 에이전트 시대에는 이런 부하가 일상이 될 것으로 봤습니다.
- 아직은 일부 저장소만 쓰는 비공개 미리보기 단계이고, 내년 초에 더 넓게 적용할 예정입니다.
핵심 내용
- 내부 시험에서 에이전트 5,000개가 한 저장소에 초당 7,200건을 푸시해도 읽기 지연이 낮게 유지됐습니다.
- Git 객체 묶음(팩)은 Azure Blob Storage에 두고, 서버의 로컬 디스크는 다시 채울 수 있는 캐시로만 씁니다.
- 브랜치 같은 참조는 Ref-CAS라는 전용 로그 서비스가 비교 후 교체(CAS) 방식과 다수결로 확정합니다.
- 잠금은 건드린 참조에만 걸리므로, 서로 다른 브랜치로 가는 푸시는 서로 기다리지 않습니다.
- 팩 병합과 불필요한 객체 정리는 요청을 받는 서버가 아니라 별도의 압축 노드가 뒤에서 맡습니다.
HN 반응
- 이번 개편은 저장소 하나 안의 확장용이라 최근 장애를 바로 줄이지 못한다는 지적과, 장애는 Actions 탓이 크다는 의견이 나왔습니다.
- Enroute와 Cursor가 이미 비슷한 구조를 썼다는 비교가 나왔고, Git보다 에이전트 남용이 문제라며 과금이나 차단을 요구하는 반론도 있었습니다.
제가 제대로 이해한 거라면, 이건 (정말 탄탄한) 미래 대비 계획이지 지금의 장애를 해결해 주지는 않는 거죠?
제목과 도입부만 보면 그럴 줄 알았는데, 글에서는 수평 확장 기법이 기존 아키텍처에서 사실상 그대로 이어지고(문제가 있는 곳이 여기인 것 같은데 말이죠), 이번 작업은 주로 그들이 "수직 확장"(저장소 내부 확장성)이라 부르는 부분을 돕기 위한 것이라고 합니다. 바로 뒤에서는 오늘날 가장 활발한 저장소도 기껏해야 수십 건 정도의 쓰기가 짧게 몰리는 수준이라고 인정하고요.
그러니 이건 더 많은 문제를 막는 데 도움이 될 가까운 미래를 위한 아주 유용한 계획이지만, 현재의 문제를 해결하려는 것은 아닌 듯합니다. 제가 제대로 읽은 건가요?
물론 이런 개선은 어느 쪽으로든 늘 유용합니다. 깎아내리려는 의도는 전혀 없습니다.
개인적으로는 푸시보다 Actions 쪽에서 문제가 더 많이 보입니다.
뭐라고요? 초당 CI 7.2k건 실행쯤은 식은 죽 먹기죠! ;-)
비활성 저장소를 더 이상 디스크에 실제로 올려 둘 필요가 없어지니, 유지해야 하는 컴퓨팅/디스크 용량이 줄어들어서 수평 확장 문제도 해결될 것 같습니다.
이 글의 내용 대부분은 https://enroute.sh 가 Git을 확장하면서 이미 했던 것과 비슷합니다. https://enroute.sh/blog/everyone-is-doing-git-on-s3-wrong
참고로 스크롤하면 언덕들이 시차를 두고 움직이면서 해가 천천히 떠오르는 연출은 2000년대 스타일 CSS의 멋진 한 수예요.
요즘은 Firewatch에 바치는 오마주에 더 가까울지도 모르겠네요: https://www.firewatchgame.com/
그래도 저는 2008년의 총아였던, 창 크기를 조절하면 움직이는 시차 효과를 누군가 되살려 주기를 아직도 기다리고 있어요: https://web.archive.org/web/20080302013806/https://www.thinkvitamin.com/features/design/how-to-recreate-silverbacks-parallax
CSS로 만든 언덕 위 일출이 마음에 드신다면, 제 친구의 웹사이트 [1]와 거기 쓴 글 [2]도 아마 좋아하실 거예요.
[1] https://grady.dev/
[2] https://grady.dev/projects/sunrise/
멋져 보이네요. 직접 써 본 경험을 공유해 주실 분 계신가요?
이쯤 되면 GitHub가 Enroute 팀을 그냥 데려가 보는 게 좋겠네요 :)
이건 Cursor의 Continuity와 꽤 비슷해 보입니다. 다만 GitHub는 쓰기 처리량이 10배 가까이 높다고 보고하고 있습니다.
https://cursor.com/blog/git-at-any-scale
git 클라이언트 자체에 대역폭을 고려한 업데이트를 밀어붙이면 트래픽을 얼마나 줄일 수 있을지 궁금합니다.
예를 들면 기본값을 shallow clone으로 하거나, 커밋 양이 많은 저장소에는 지연 평가(lazy evaluation)를 적용하는 식입니다(브랜치로 전환하기 전까지는 원격 관련 작업을 브랜치 단위로 부분적으로만 처리하는 등).
이렇게 과부하가 걸린 그래프를 읽는 게 문제라면, 대부분의 읽는 쪽(요즘은 자동화된 소비가 많죠)은 프로젝트 코드의 현재 스냅숏만 필요로 합니다. 그것도 아마 main 브랜치만요.
GitHub가 git 메인테이너들이 이걸 구현하도록 밀어붙일 수도 있을 것 같습니다. 최소한 시도해 볼 가치는 있어 보입니다.
에이전트 규모는 업계 전반에서 확실히 화두인데, GitHub 쪽 사람들은 https://www.anthropic.com/research/redesigning-source-control 에 어떻게 답할지 궁금합니다. 소스 관리를 첫 원칙부터 한 발 물러서 생각해 보고, 이 새로운 체제에서 어떤 특성이 중요한지에 맞춰 트레이드오프를 다시 조정해 본다는 점에서 흥미로운 글입니다.
하루에 수천 건씩 변경이 생긴다는 건 그걸 전부 읽을 수 있는 사람이 없다는 뜻입니다.
보안 문제도 분명히 있고, 블랙박스는 또 다른 블랙박스를 낳습니다.
사람도 블랙박스인데요.
아니에요. 이 비유에서 사람은 빛이 뿜어져 나오는 쪽이거든요.
왜 이 댓글이 마음에 드는지는 모르겠는데, 마음에 드네요.
사람을 만나 보신 적은 있나요? 사람이 완전히 제멋대로던가요? 아니라면 블랙박스가 아니죠. 이런 얼버무리기(equivocation)는 슬슬 지겨워요. 우리는 99.999% 똑같다고요.
이제 "업계"라는 건 없고, "Claude 프롬프터"는 직업명이 아니에요.
이번 주에 푸시할 때 500 에러가 줄줄이 뜬 게 이것 때문이었군요 :)
안정성이 나아지는 데 도움이 되면 좋겠습니다. 최근 장애가 워낙 많아서 GitHub를 옹호하기가 점점 힘들어지고 있었거든요.
스팸을 보내서 서버 시간을 엄청나게 잡아먹는 사람들을 그냥 차단하면 되잖아요. 아니면 서버 시간에 대한 비용을 내게 하든가요.
에이전트를 염두에 둔, git이 아닌 버전도 만들고 있을지 궁금하네요.
에이전트에게는 git과 다른, 더 나은 무언가가 필요하다는 이 기막힌 새 발상은 그냥 말도 안 돼요.
우리가 부딪히는 규모 문제는 형편없는 개발자들이 형편없는 양의 형편없는 에이전트를 형편없는 저장소에 풀어놓고 있기 때문이에요.
바이브 코딩한 저장소가 GB 단위로 공간을 차지하고, 쓸모없는 PR이 열렸다가 다른 쓸모없는 PR과 충돌해서 닫히는데, 알고 보니 문제는 git이래요!
틀린 말은 아니지만, GitHub가 할 수 있는 건 자기들이 통제할 수 있는 것뿐이에요. 총을 겨누고 다들 바이브 코딩을 못 하게 만들 수는 없잖아요. 앤트로픽이나 OpenAI를 문 닫게 할 수도 없고요. 그건 앤트로픽과 OpenAI의 빚을 갚을 때가 올 때까지 기다리는 수밖에 없죠.
GitHub 무료 플랜에도 실제 사용량 제한이 생길지 모릅니다. 솔직히 무료 플랜에서 비공개 저장소를 무제한으로 허용한 결정을 지금쯤 적어도 조금은 후회하고 있을 것 같아요.
제가 알기로는 문제는 전부 공개 저장소 때문이고, 비공개 저장소는 비용이 그리 크지 않아요.
사람에게 git보다 나은 게 필요하다고 생각해요 :)
사람이 그걸 손에 넣으면 에이전트도 따라 쓰게 될 거예요! 예를 들어 저라면 git에 견줄 만한 성능에, 무엇보다 견줄 만한 보급률까지 갖춘 bazaar/breezy가 있다면 당장 갈아탈 거예요.
주범은 Actions(무료 저장소 기준)라고 생각했는데, 아닌가요?
수직으로 너무 커지고 있었다는 저장소가 어느 저장소를 말하는 건가요?
제가 아는 가장 크고 아주 활발한 저장소는 nixpkgs인데, 이미 GitHub에는 스트레스 테스트나 다름없다고 들었습니다.
나중에 알게 된다면 아마 괴담 수준일 거예요.
GitHub가 하는 이런저런 이야기에서 늘 성능 레이더에 올라 있는 저장소로 자주 언급되는 걸 보면, 제 직감으로는 윈도 모노레포일 것 같아요.