대형 테크 기업이 Git을 바꾸는 이유, 우리도 바꿔야 할까

Anthropic이 소스 관리 시스템을 다시 만들었다는 글을 읽고 익숙한 질문이 떠올랐다. Google은 자체 시스템을 쓰고 Meta도 Git과 다른 도구를 발전시켜 왔다. AI 에이전트가 코드를 더 많이 만드는 지금, 우리도 Git을 바꿔야 할까.

나는 수십 개 프로젝트를 Git으로 관리한다. 직접 운영하는 애플리케이션에서는 GitHub Actions와 Blacksmith로 이미지를 빌드해 ECR·ECS로 보내고, 고객 환경에서는 GitLab과 CodeBuild를 거쳐 ECR·ECS·EKS로 배포하는 구성을 다룬다. 코드 리뷰와 배포 밖에도 GitHub에 연결된 도구가 많다. 이 연결을 옮길 만큼의 이익이 있는지가 궁금했다.

회사별 공식 자료를 읽어 보니 선택이 달랐다. 내부 모노레포, 개발자의 작업 도구, 자동화 서비스가 바뀐 사례를 구분해서 봐야 했다. 이 글의 확인 기준은 2026년 10월 14일이다. 과거 발표는 당시의 구성으로 다루며, 각 회사의 성능 수치는 자체 보고로 인용한다. 우리 파이프라인의 전환 효과를 측정한 벤치마크는 아니다.

회사마다 바꾼 계층이 다르다

Git은 버전 관리 시스템이고 GitHub·GitLab은 그 위에서 리뷰, 권한, 상태 검사와 도구 연동을 제공하는 플랫폼이다. 개발자가 쓰는 클라이언트를 바꿔도 서버와 PR은 유지할 수 있다. 저장 형식과 서버까지 바꾸는 이전은 범위가 훨씬 크다.

Google은 자체 중앙형 Piper를 만들었다

Google의 내부 시스템을 Git 개조판이라고 설명하면 정확하지 않다. Google 엔지니어들이 쓴 Software Engineering at Google은 Piper를 자체 개발한 중앙형 소스 관리 시스템으로 설명한다. 큰 내부 모노레포를 공유하며 Chromium·Android 같은 대형 오픈소스 프로젝트는 예외로 구분한다.¹

이 선택은 여러 제품에 걸친 변경을 하나의 개발 체계에서 처리하려는 방향과 연결된다. 책에서 설명하는 One Version 정책은 정상 상태에서 의존성의 한 버전을 공유하는 방식이다. 특정 제품만 오래된 공통 라이브러리를 계속 쓰는 상황을 줄이고 공동 변경을 관리한다. 저장소가 하나여도 소유자와 승인 책임까지 사라지는 것은 아니다. Piper는 경로별 OWNERS와 승인을 개발 체계에 통합했다.¹

Google이 개발에 참여하는 **Jujutsu(jj)**는 또 다른 이야기다. 공식 저장소는 Google을 주요 기여자로 명시하지만 지원되는 Google 제품은 아니라고 설명한다.² Git 호환 작업 도구의 개발 참여를 Piper의 전사 교체로 해석할 근거는 없다.

우리에게 적용할 때는 공통 코드를 함께 바꿔야 하는 필요가 얼마나 큰지부터 묻게 된다. 고객별 접근과 배포 일정이 분리돼 있다면 의존성을 공유하는 이익과 분리 운영의 이익을 비교한다. Google의 소스 관리 서버를 따라 만드는 판단보다 앞서는 질문이다.

Meta는 Mercurial 확장에서 Sapling까지 발전시켰다

Facebook의 2014년 글은 전환 배경을 구체적으로 설명한다. 당시 Subversion 서버와 Git 미러를 운영했지만 저장소의 성장 전망에 맞춰 다른 선택을 검토했다. 코드를 여러 저장소로 나누면 큰 변경을 한 번에 적용하기 어려워졌고, Git 내부를 확장하는 작업도 쉽지 않다고 판단했다. 그래서 확장하기 쉬운 Mercurial을 개선했다.³

개선 대상은 일상적인 작업이었다. Watchman으로 변경된 파일을 찾아 전체 파일을 다시 살피는 비용을 줄였고, remotefilelog는 필요한 파일 내용을 요청할 때 받아 오도록 했다. 데이터가 큰 클라이언트마다 같은 이력을 내려받는 비용을 줄이려는 설계였다.³

2022년 공개한 Sapling은 이 작업이 독자적인 저장 형식과 프로토콜, 알고리즘으로 발전한 결과다. 개발 경험도 바꿨다. 작은 변경을 차례로 쌓아 각각 리뷰하고, 앞선 변경을 수정하면 뒤의 변경을 다시 정렬하는 작업을 지원한다. 공개 클라이언트는 Git 저장소와 GitHub에도 연결된다.⁴

모노레포 운영은 이후에도 추가 설계를 요구했다. Meta의 2025년 설명에는 저장소 전체를 분기하면 무관한 프로젝트까지 과거 상태로 고정되는 문제가 나온다. 필요한 디렉터리를 복사하고 변경 관계를 추적하는 디렉터리 분기로 제품의 여러 버전을 관리했다. 빌드와 코드 검색에도 이를 연결했다.⁵

작은 PR을 쌓아 리뷰하는 방식은 우리도 실험할 만하다. 다만 공개 클라이언트를 설치하는 일과 Meta의 내부 체계를 도입하는 일은 다르다. 공식 문서에는 .git·.sl 모드의 기능 차이와 EdenFS·Mononoke 지원 코드의 공개 범위가 별도로 적혀 있다.⁶ 내부 서버의 성능을 GitHub에 연결한 클라이언트에서도 그대로 얻는다고 가정하지 않는다.

Anthropic은 온라인 에이전트를 기준으로 Scion을 설계했다

Anthropic은 내부 모노레포를 Git에서 Scion으로 이전했다. 클라이언트가 온라인이라는 조건을 두고 커밋·병합·리베이스와 이력 조회를 서버에서 처리한다. 필요한 파일만 가져오고, 조회만 하는 작업은 작업 트리 없이 API로 처리한다.⁷

이 구조라면 자동화 작업마다 저장소를 준비하는 중복을 줄일 여지가 생긴다. 서버가 계산을 맡는 만큼 서버 접근성과 권한 체계가 개발 환경의 중요한 의존성이 된다. 오프라인 작업, 장애 시 복구와 외부 도구 연결도 함께 검토할 대상이다.

Anthropic은 별도 리뷰 도구 Antique와 검색·권한·CI도 만들었다. 원문은 Scion을 일반적인 Git 대체재로 권하지 않으며, 이 도구들을 함께 이전해야 하는 부담을 명시한다.⁷ 중소 팀이 검토할 비용에는 서버 구현뿐 아니라 이 주변 체계도 들어간다.

OpenAI의 공개 사례는 PR 운영을 자동화한 쪽에 가깝다

OpenAI를 Git을 쓰지 않는 회사로 묶을 근거는 이번 조사에서 찾지 못했다. 2026년 Symphony 글은 내부 대형 모노레포에서 CI를 확인하고 리베이스와 충돌 해결을 거쳐 PR을 병합하는 흐름을 설명한다. 이슈마다 작업 공간과 에이전트를 배정하고, 사람이 결과를 검토하는 방식이다.⁸

공개 저장소의 근거도 있다. OpenAI Agents SDK 유지보수 글은 GitHub Actions, AGENTS.md와 저장소 안의 스킬을 사용한다고 설명한다.⁹ 두 자료만으로 회사 전체의 유일한 소스 관리 시스템을 확정할 수는 없다. 적어도 AI 개발의 확대가 곧 GitHub 중심 작업의 폐기를 뜻하지는 않는다.

우리처럼 여러 프로젝트를 오가는 환경에서는 이 접근이 더 가깝다. 작업 배정, 검증 결과 수집과 리뷰 대응을 정리하면 기존 저장소와 연동 도구를 유지하면서도 사람의 반복 작업을 줄이는 실험이 가능하다. 무엇을 맡기고 언제 완료로 판단할지 정하는 일은 여전히 남는다.

Microsoft는 Windows 저장소에서 Git을 확장했다

Microsoft의 2017년 GVFS 발표는 Git을 유지한 사례다. 당시 Windows 코드베이스에는 350만 개 이상의 파일이 있었다. GVFS는 전체 파일이 있는 것처럼 보이게 하면서 실제 파일은 처음 읽을 때 내려받았고, Git이 살펴볼 작업 범위도 줄였다.¹⁰

Microsoft는 대형 저장소의 문제에 Git 확장으로 대응했다. 파일 수 때문에 상태 확인이나 작업 트리 준비가 느려진다면 필요한 파일만 펼치는 방식부터 검토할 수 있다. 2017년의 도구와 관측값을 현재 모든 Microsoft 팀의 구성이나 신규 도입의 기본값으로 읽지는 않는다.

Uber는 Git 명령을 서비스로 제공했다

Uber가 2026년에 설명한 GitFarm은 소스 관리 서버 자체가 아니다. 기존 Git 서버를 유지하고 준비된 저장소와 격리된 작업 공간에서 다른 서비스의 Git 명령을 대신 실행한다. 호출 서비스가 단순 조회나 짧은 변경을 처리하려고 매번 전체 복제본을 준비하는 비용을 줄인다.¹¹

모든 자동화가 빌드 작업일 필요는 없다. 변경 파일이나 소유자를 확인하는 일과 실제 코드를 빌드하는 일은 요구하는 데이터가 다르다. 반복 조회가 많다면 호스팅 플랫폼의 API로 끝낼 수 있는 작업부터 분리하는 편이 가볍다. 필요한 경우에만 공유 실행 서비스를 검토한다. 이 경우에도 인증, 격리, 저장소 상태의 최신성은 서비스 운영 범위에 포함된다.

Dropbox는 GitHub와 저장 방식을 개선했다

Dropbox는 2026년 서버 모노레포가 87GB에서 20GB로 줄었다고 보고했다. 국제화 파일의 경로 구조와 Git 압축 방식이 맞지 않아 저장공간이 과도하게 커졌고, GitHub와 서버 측 압축 설정을 조정했다.¹²

문제를 찾는 과정이 참고할 만하다. 코드와 큰 파일의 양만 볼 것이 아니라 실제 저장과 전송 방식을 확인했다. 로컬에서 재압축한 저장소를 올리는 것만으로는 서버의 전송 방식이 바뀌지 않으므로 관리형 플랫폼과 함께 해결했다.¹² 우리 저장소에서도 같은 원인이 발생했다고 추정할 수는 없다. 도구를 교체하기 전에 문제의 원인을 좁혀야 한다는 교훈은 적용된다.

Anthropic이 해결한 것은 어떤 규모의 문제였나

Anthropic은 2026년 5월 하루 약 2,500건이던 병합이 9월에는 30,000건 이상으로 늘었고, CI에서 하루 약 2,500만 번 코드를 체크아웃했다고 밝혔다.⁷ 이 정도의 반복 작업에서는 복제 한 번의 비용도 전체 작업량과 곱해진다.

우리가 볼 축은 저장소의 수, 저장소 하나의 크기, 변경 빈도, 코드를 읽는 작업의 수다. 에이전트가 늘어도 이 축이 모두 같은 속도로 커지지는 않는다. 프로젝트가 많다는 이유만으로 Scion과 같은 설계를 고를 수는 없다.

서버에서 조회하고 필요한 파일만 받는 원리는 참고할 만하다. 이를 옮겨 오려면 저장소를 준비하는 비용이 실제로 큰지, 기존 API와 캐시로 줄일 수 있는지부터 확인한다. 회사가 발표한 절감률을 우리 환경의 예상 절감률로 쓰지는 않는다.

수십 개 프로젝트는 하나의 거대 저장소와 다르다

고객별 저장소는 코드 보관 장소이면서 접근과 납품의 경계다. 배포 승인, 비밀정보와 릴리스 일정이 다르다면 분리해 둔 이유가 있다. 공통 라이브러리와 배포 양식을 공유하는 일은 그 경계를 합치는 일과 별개다.

우리의 두 경로는 GitHub → GitHub Actions·Blacksmith → ECR·ECS와 GitLab → CodeBuild → ECR·ECS·EKS다. 먼저 이 경로에서 어디에 시간이 드는지 나눠 본다. 러너 배정, 소스 준비, 의존성 설치, 이미지 빌드, 테스트와 배포 안정화는 다른 문제다.

소스 준비가 짧고 이미지 빌드가 길다면 소스 관리 서버를 바꿔도 남는 대기 시간이 많다. 리뷰 대기가 길다면 빠른 체크아웃만으로 배포가 빨라지지 않는다. 병렬로 실행하는 단계는 시간을 단순 합산하지 않고 마지막 완료를 늦추는 경로를 살핀다.

실행 계층과 Docker 캐시를 고르는 기준은 Blacksmith와 GitHub Actions 운영 기록에 따로 정리했다. 이 글에서는 그 선택보다 앞에 있는 소스 관리와 연동 체계의 전환 여부를 판단한다.

GitHub 연동을 유지하는 이익도 계산한다

GitHub에 연결된 도구는 커밋만 읽지 않는다. PR 번호, 승인 상태, 검사 결과와 웹훅을 사용한다. AWS 배포 권한도 실행 환경과 연결된다. 자체 소스 관리 시스템을 선택할 때는 기존 기능을 어떤 방식으로 이어 갈지 목록으로 확인한다.

GitHub Actions의 OIDC는 AWS의 신뢰 조건에 연결된다. 실행 플랫폼이 바뀌면 발급자와 작업 식별 조건도 확인한다.¹³ ECR·ECS·EKS를 계속 쓴다고 해서 그 앞의 인증과 승인 체계까지 자동으로 유지되지는 않는다.

모노레포로 합칠 때도 권한을 따로 본다. CODEOWNERS는 리뷰 책임을 지정하는 기능이고 저장소 역할은 저장소의 접근 권한을 정한다.¹⁴¹⁵ 서로 다른 고객의 코드를 읽지 못하게 분리해야 한다면 리뷰 소유자만 지정해서는 그 경계를 대신할 수 없다.

작게 도입할 수 있는 개선부터 고른다

처음부터 선택지를 Git 유지와 자체 서버 구축으로만 좁힐 필요는 없다. 기존 서버를 유지하면서 바꿀 범위도 있다.

소스 준비가 병목이면 받는 데이터와 펼치는 파일을 줄인다. 얕은 복제(shallow clone)는 이력 깊이를, 부분 복제(partial clone)는 내려받는 객체를 제한한다. 희소 체크아웃(sparse-checkout)은 작업 트리에 펼치는 경로를 줄인다.¹⁶¹⁷ 세 설정은 같은 최적화가 아니다. 버전 계산이나 merge-base·bisect처럼 이력을 읽는 작업에 필요한 범위를 확인한다.

여러 프로젝트의 설정 관리가 부담이면 재사용할 CI와 배포 계약부터 정리한다. 공통 설정을 공유하되 고객별 권한과 환경은 별도로 유지한다. 여러 저장소를 같은 방식으로 관리하려고 하나의 저장소에 합칠 필요는 없다.

작은 변경을 쌓고 수정하는 일이 불편하면 Jujutsu나 Sapling 같은 Git 호환 작업 도구를 한 저장소에서 실험한다. 서버와 PR을 유지하므로 실험 범위를 줄이기 쉽다. 다만 Git 호환성이 모든 기능의 동등성을 뜻하지는 않는다. 확인일의 Jujutsu 공식 문서에는 Git hooks, Git LFS와 git-worktree 제한이 명시돼 있고, Sapling도 모드별 지원이 다르다.¹⁸⁶ 사용하는 IDE·에이전트, 서명·태그·서브모듈과 기존 검사를 실제로 확인한다.

자동화가 같은 데이터를 반복 조회하면 필요한 질문을 API로 처리할 수 있는지 검토한다. 조회 하나에 전체 빌드를 시작하는 비용을 줄이는 방식이다. 공용 캐시나 실행 서비스를 만들 때는 그 서비스의 운영비도 함께 계산한다.

표준 개선 후에도 서버가 병목이면 자체 시스템의 검토 범위를 정한다. 전용 리뷰·검색·권한·복구까지 운영할 사람이 있고, 기존 연동을 옮긴 뒤에도 이익이 남는지가 조건이다. 도구의 기능 목록보다 우리의 측정 결과가 이 결정을 뒷받침해야 한다.

전환 판단은 병목과 총운영비로 한다

아래는 이번 글에서 제안하는 측정표다. 실제 관측 결과를 채운 표는 아니다. 대표 저장소와 작업을 고르고 같은 커밋, 자원 조건과 캐시 상태를 기록해 비교한다. 중앙값과 p95를 함께 보며 실패와 재시도도 남긴다.

같은 기간을 두고 계산할 식은 다음과 같다.

전환 순효과 = 회피 가능한 지출 + 중복 없이 계산한 시간의 가치 − 전환·연동 비용 − 추가 운영·장애·교육 비용.

줄어든 대기 시간은 현금 절감과 구분한다. 다른 일을 할 수 있는 비동기 대기에 전체 개발자의 인건비를 곱하면 효과가 커 보인다. 전용 서버뿐 아니라 캐시, 리뷰·검색, 백업, 장애 대응과 AI 토큰 비용도 포함한다. 보수적인 조건에서 이익이 사라지면 더 작은 변경을 선택한다.

파일럿의 성공 조건도 실험 전에 적는다. 필요한 도구가 동작하고 기존 통제를 지키면서 병목과 총비용이 줄어야 한다. 새 클라이언트 때문에 검사가 빠지거나 운영 부담이 절감 효과를 넘으면 범위를 줄인다. 소스와 이력, 리뷰 기록을 기존 방식으로 이어 갈 경로도 확인한다.

AI 시대에도 배포 완료의 기준은 남는다

Anthropic 사례를 작은 팀에 적용할 때도 에이전트의 변경이 늘면 검사를 기다리는 동안 대상 코드가 달라지는 문제를 검토한다. 그래서 검증 결과를 어떤 변경과 산출물에 연결할지 명확해야 한다. 병합량이 많다는 이유만으로 작은 팀의 배포 전 검사를 없애는 결론은 성립하지 않는다.

GitHub 병합 큐도 실제 사용 조건을 확인한다. 요금제와 저장소 조건에 맞아야 하며 merge_group 이벤트에서 필수 CI가 실행돼야 한다.¹⁹ 작은 PR의 성공 결과와 실제 병합할 조합의 성공 결과는 다를 수 있다.

우리가 배포할 때 남겨야 할 연결은 변경한 커밋, 검사한 결과, ECR 이미지 다이제스트와 실제 실행 중인 버전이다. CI 성공, ECS·EKS 반영과 사용자 동작 확인은 각각의 근거로 기록한다. ECS 배포 완료 신호를 다룬 글은 이 구분을 실제 배포 경로에서 설명한다.

에이전트를 운영 유지보수에 넣는 준비 조건은 AI-DLC 도입과 파일럿 판단에 정리했다. 코드가 많아질수록 무엇을 검증했고 어디까지 완료됐는지 설명할 수 있는 개발 체계가 필요하다.

지금 우리의 선택은 Git과 기존 연결을 유지하며 병목을 측정하는 쪽이다. Git 호환 작업 도구는 작게 시험하고, 자체 서버는 기존 방식의 한계와 운영할 책임이 확인됐을 때 검토한다. 대형 테크 기업의 사례에서 가져올 것은 우리 조건에 맞는 설계와 판단 기준이다.

소스 관리, 빌드와 배포 중 어디부터 바꿔야 할지 판단하려면 현재 작업 경로와 비용을 함께 살펴야 한다. 801플래닛의 클라우드 & 인프라와 AX 컨설팅은 이 진단과 단계별 실행을 지원한다.

참고 자료

아래는 공식 기술 자료와 도구 문서다. 외부 회사의 운영 효과를 직접 재현하지 않았으며 사용자 저장소의 성능과 비용을 이번 조사에서 측정하지 않았다.