Cursor로 대규모 Git 저장소 다루기: Git at any scale 살펴보기

팀 저장소 수가 늘어날수록 Git 호스팅 인프라를 운영하는 부담도 함께 커진다. 대형 모노레포 하나를 안정적으로 유지하는 것과, 에이전트가 자동으로 만들어내는 수많은 소규모 임시 저장소를 동시에 감당하는 것은 서로 다른 종류의 문제인데, 기존 방식으로는 두 요구를 함께 만족시키기가 쉽지 않았다. Cursor가 공개한 바에 따르면, 자체 Git 호스팅 구조를 처음부터 다시 설계하면서 이 두 상황을 함께 풀어내려 했다고 한다.

기존 방식이 겪던 한계

복제본을 늘릴수록 느려지는 구조

기존에 쓰던 합의 알고리즘 기반 구조는 복제본을 늘릴수록 오히려 푸시 처리 성능이 나빠지는 특성이 있었다고 한다. 저장소마다 안정성을 위해 복제본을 여러 개 두고 싶어도, 복제본이 늘어날수록 쓰기 성능이 떨어지는 딜레마 때문에 확장에 제약이 있었던 셈이다.

저장소를 개별적으로 돌봐야 하는 부담

저장소 하나하나를 마치 애완동물처럼 세심하게 관리해야 하는 방식도 문제였다. 대형 모노레포처럼 안정성이 중요한 저장소와, 자동화 파이프라인이 잠깐 쓰고 버리는 임시 저장소를 같은 방식으로 관리하려다 보니 운영 복잡도가 계속 쌓이는 구조였다.

새 구조가 바꾼 것

객체 저장소를 진실의 원천으로 삼기

새 구조는 로컬 드라이브의 일반 Git 저장소와, S3 호환 객체 저장소에 남기는 기록을 함께 조합하는 방식을 쓴다. 모든 푸시는 이 기록이 객체 저장소에 완전히 저장된 뒤에야 성공으로 처리되기 때문에, 저장소가 어느 서버에 있는지 별도로 추적할 필요 없이 객체 저장소 자체가 정답을 담고 있는 구조가 된다.

저장소 성격에 맞게 복제본 수를 유연하게 조절

이 구조 덕분에 대형 모노레포는 복제본을 넉넉하게 두어 안정성을 높이고, 자동화가 만들어내는 소규모 임시 저장소는 복제본을 최소한으로 줄여 자원을 아끼는 식으로 저장소 성격에 맞게 조절할 수 있게 됐다. 신뢰할 수 없는 전송 방식을 쓰면서도 모든 읽기 작업이 객체 저장소 검증을 거치도록 설계해, 복제본 수와 관계없이 일관된 결과를 보장한다는 점도 특징이다.

실무에서 참고할 점

저장소 유형별로 백업·복제 정책을 나누기

사내에서 Git 호스팅을 직접 운영하고 있다면, 이번 사례처럼 저장소 성격에 따라 복제 정책을 다르게 가져가는 접근을 참고할 만하다. 핵심 서비스 저장소와 실험용·임시 저장소를 같은 기준으로 백업하기보다, 중요도에 따라 자원 배분을 달리하는 편이 효율적이다.

객체 저장소 기반 아키텍처의 장단점 이해하기

객체 저장소를 진실의 원천으로 삼는 구조는 확장성 면에서 유리하지만, 객체 저장소 자체의 가용성과 지연 시간에 전체 시스템 성능이 좌우된다는 특징도 함께 따라온다. 이런 아키텍처를 검토할 때는 처리량 수치만 보지 말고, 객체 저장소 장애 시 어떤 방식으로 복구되는지도 함께 확인하는 것이 좋다.

대규모 자동화 워크플로우를 염두에 둔 설계

에이전트나 CI 파이프라인이 저장소를 자동으로 대량 생성하는 워크플로우를 쓰고 있다면, 이런 임시 저장소가 팀의 핵심 Git 인프라에 부담을 주지 않는지 점검해볼 필요가 있다. 임시 저장소와 영구 저장소를 애초에 다른 정책으로 다루는 구조를 갖추면 이후 확장이 한결 수월해진다.

주의할 점

새로운 아키텍처가 발표됐다고 해서 곧바로 사내 인프라에 동일한 구조를 도입하려 하기보다는, 우리 팀의 저장소 규모와 자동화 패턴이 실제로 이런 구조의 이점을 필요로 하는지 먼저 따져보는 편이 낫다. 저장소 수가 많지 않은 팀이라면 복잡한 아키텍처 전환보다 기존 방식을 유지하는 것이 오히려 관리 부담을 줄이는 선택일 수 있다.

정리

이번 사례는 대형 모노레포와 수많은 임시 저장소라는 서로 다른 요구를 하나의 구조로 함께 풀어내려 한 시도로 볼 수 있다. 사내 Git 인프라를 직접 운영하는 팀이라면, 저장소 성격에 따라 복제·백업 정책을 다르게 가져가는 접근과 객체 저장소 기반 설계의 장단점을 참고 사례로 살펴볼 만하다. 특히 AI 코딩 에이전트를 팀 전체에 도입해 자동화된 브랜치·저장소 생성이 늘어나는 추세라면, 지금 당장은 문제가 없더라도 저장소 수가 앞으로 얼마나 늘어날지 미리 가늠해보고 인프라 확장 계획을 세워두는 편이 나중에 급하게 구조를 바꾸는 상황을 피하는 데 도움이 된다.