무슨 일이 있었나
OpenAI 블로그에 ‘Scaling Git at OpenAI’라는 글이 올라왔어요. 조직과 코드가 빠르게 커지면서 Git이 점점 버거워지는 상황을 어떻게 다뤘는지에 대한 이야기예요. AI 회사라고 하면 보통 모델 이야기만 떠올리잖아요. 그런데 그 모델을 만드는 사람들도 매일 git pull, git status를 치면서 일하거든요. 이렇게 평범한 명령어가 느려지기 시작하면 수백, 수천 명의 하루가 조금씩 깎여 나가요.
OpenAI 내부의 구체적인 구성과 수치는 원문에 자세히 나와 있으니 같이 읽어보시면 좋겠어요. 여기서는 Git이 큰 규모에서 왜 느려지는지, 그리고 업계가 지금까지 어떤 해법을 써왔는지를 중심으로 풀어볼게요. 이 배경을 알고 원문을 읽으면 훨씬 잘 읽히거든요.
Git은 원래 거대 저장소용으로 만들어진 도구가 아니에요
Git은 리눅스 커널 개발을 위해 만들어졌어요. 커널도 작은 프로젝트는 아니에요. 하지만 대기업의 모노레포와 비교하면 규모가 완전히 달라요. 모노레포는 회사 코드를 거의 전부 저장소 하나에 넣는 방식이에요. Git의 기본 설계는 ‘모든 사람이 전체 히스토리와 전체 파일을 다 가진다’는 거예요. 저장소가 작을 때는 이게 장점인데, 커지면 그대로 부담이 돼요.
느려지는 지점은 크게 세 군데예요.
- 파일 개수:
git status는 작업 폴더의 파일을 하나하나 확인해서 바뀐 게 있는지 봐요. 파일이 수십만 개라면 이것만으로 몇 초씩 걸려요. - 히스토리 크기:
git clone은 기본적으로 첫 커밋부터 지금까지의 모든 기록을 내려받아요. 몇 년치가 쌓이면 클론 한 번에 수십 분이 걸리기도 해요. - 동시 작업량: 사람과 CI, 자동화 도구가 같은 브랜치에 한꺼번에 푸시하면 서로 충돌해요. 서버도 클론 요청을 처리하느라 바빠지고요.
클라이언트 쪽 해법: 필요한 것만 가져오기
다행히 최근 몇 년 동안 Git 자체에 이런 문제를 위한 기능이 꽤 많이 들어왔어요. 핵심 아이디어는 ‘다 가지지 말고 필요한 만큼만’이에요.
부분 클론(partial clone)은 커밋과 폴더 구조는 받되, 실제 파일 내용은 필요할 때 받아오는 방식이에요. git clone --filter=blob:none <url>처럼 쓰면 되고요. 책으로 치면 목차는 다 받아두고, 본문은 펼쳐볼 때 가져오는 거예요.
스파스 체크아웃(sparse-checkout)은 저장소 전체 대신 내가 작업하는 폴더만 꺼내놓는 기능이에요. git sparse-checkout set services/api libs/common처럼 쓰면 나머지 폴더는 디스크에 아예 펼쳐지지 않아요. 여기에 sparse index까지 켜면 인덱스 파일도 작아져서 git status가 확 가벼워져요.
fsmonitor는 운영체제가 보내주는 파일 변경 알림을 이용해서 바뀐 파일만 확인하게 해줘요. macOS와 Windows에서는 git config core.fsmonitor true 한 줄이면 Git에 내장된 데몬이 동작해요. 그 밖에 커밋 관계를 미리 계산해서 저장해두는 commit-graph도 있고, 백그라운드에서 미리 fetch하고 정리해주는 git maintenance도 있어요. Microsoft는 이런 설정을 한 번에 켜주는 Scalar를 만들었고, 지금은 Git 본체에 포함돼 있어요.
서버 쪽 해법: 병목은 사람보다 자동화에서 생겨요
규모가 커지면 서버 쪽 문제가 더 아파요. CI는 빌드할 때마다 저장소를 새로 클론하는 경우가 많아서, 개발자보다 훨씬 많은 트래픽을 만들거든요. 그래서 얕은 클론(--depth 1), 캐시용 미러 서버, 미리 만들어둔 저장소 스냅샷 같은 방법을 섞어 써요.
메인 브랜치에 푸시가 몰리는 문제는 머지 큐(merge queue)로 많이 풀어요. PR을 줄 세운 뒤, 하나씩 최신 main 위에서 테스트하고 합치는 방식이에요.
요즘은 여기에 AI 코딩 에이전트라는 변수가 새로 생겼어요. 에이전트가 작업마다 작업 공간을 만들고, 브랜치를 따고, PR을 올리잖아요. 그러면 Git 작업량이 사람만 일할 때보다 몇 배로 늘어나요. 코딩 에이전트를 직접 만들고 쓰는 회사가 Git 확장 이야기를 꺼냈다는 점이 그래서 흥미로운 거예요.
다른 빅테크는 어떻게 했을까
Microsoft는 Windows 소스(약 350만 개 파일, 300GB가량)를 Git으로 옮기면서 VFS for Git이라는 가상 파일 시스템을 만들었어요. 그 경험이 결국 Scalar와 Git 본체 개선으로 이어졌고요. Google은 Piper라는 자체 버전 관리 시스템을 써요. Meta는 Mercurial에서 출발한 Sapling을 만들어 오픈소스로 공개했어요. 정리하면 ‘Git을 고쳐 쓴다’와 ‘새로 만든다’ 두 갈래가 있는데, 요즘은 Git 생태계가 워낙 강해서 고쳐 쓰는 쪽이 늘어나는 흐름이에요.
한국 개발자에게 주는 시사점
우리 회사 저장소가 이만큼 크지 않아도 써먹을 게 많아요. 클론에 몇 분씩 걸린다면 CI에 --depth 1이나 --filter=blob:none만 적용해도 빌드 시간이 눈에 띄게 줄어요. 모노레포에서 git status가 굼뜨다면 core.fsmonitor와 core.untrackedCache를 켜보세요.
AI 에이전트를 도입하는 중이라면 PR과 CI 실행 횟수가 생각보다 빨리 늘어난다는 점도 미리 계산해 두세요. 저장소 구조와 CI 파이프라인을 한 번 점검해 볼 타이밍이에요.
마무리
한 줄 정리: Git은 ‘다 가지는’ 도구에서 ‘필요한 만큼만 가지는’ 도구로 진화하고 있고, AI 에이전트가 그 변화를 더 재촉하고 있어요.
여러분 팀은 모노레포와 멀티레포 중 어느 쪽인가요? 저장소가 커지면서 겪은 Git 성능 문제나 효과를 본 설정이 있다면 공유해 주세요.
🔗 출처: Hacker News