48시간에서 41분으로! GitLab 저장소 백업 속도 혁신 이야기

https://about.gitlab.com/blog/2025/06/05/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/

대형 Git 저장소 백업, 왜 이렇게 오래 걸릴까?

대용량 Git 저장소를 사용하는 기업이라면 누구나 한번쯤 이런 고민을 해봤을 겁니다.
"백업만 하루 이틀 걸리니, 도대체 언제 개발하라는 거야?"

GitLab도 같은 문제를 겪었습니다. 자사 최대 규모 저장소를 백업하는 데 무려 48시간이 걸렸던 것인데요.
하지만 이번에 GitLab은 백업 시간을 41분까지 줄이는 데 성공했습니다.

이번 블로그에서는 어떤 문제가 있었고, 어떻게 해결했으며, 그 결과 사용자에게 어떤 변화가 생겼는지 자세히 풀어보겠습니다.
GitLab 사용자라면 이번 개선 사항이 어떤 의미를 갖는지도 함께 확인해 보세요.

반응형

---

저장소 백업, 왜 중요할까?

백업은 단순한 보조 작업이 아닙니다.
비상 복구 전략의 핵심이자, 예상치 못한 장애에 대비하는 가장 중요한 방어선입니다.

그런데 저장소 크기가 커질수록 문제가 복잡해집니다.

• 시간이 너무 오래 걸림
• 시스템 리소스 사용량 폭증
• 백업 중 오류나 실패 위험 증가
• 예약 백업이 어려워짐

GitLab도 비슷한 상황이었습니다. 자사 Rails 저장소 백업만 하는 데 48시간이 소요돼 백업 빈도와 시스템 성능 사이에서 늘 고민해야 했습니다.
백업을 자주 돌릴 수 없어 재해 발생 시 데이터 손실 위험도 컸죠.

---

병목의 원인은 오래된 Git 코드

GitLab의 백업 기능은 git bundle create 명령어를 통해 저장소 스냅샷을 만듭니다.
문제는 이 명령어 내부에 있었습니다.

GitLab 엔지니어들은 Flame Graph 분석을 통해 병목을 찾아냈는데요:

• 저장소에 **수백만 개 레퍼런스(reference)**가 있을 경우
• 실행 시간의 80%가 object_array_remove_duplicates() 함수에서 소비됨
• 해당 함수는 중복 레퍼런스 제거를 위해 2009년에 도입된 코드였는데
• 내부 동작 방식이 **중첩 for 루프(O(N²))**로 구성되어 있어 레퍼런스가 많아질수록 성능이 급격히 저하됨

결국 이 오래된 코드가 대규모 저장소 백업의 최대 병목으로 확인됐습니다.

---

O(N²)에서 효율적인 매핑으로 전환

GitLab은 이 문제를 해결하기 위해 Git 자체에 패치를 기여했습니다.
핵심 전략은 간단했습니다:

• 중첩 루프 대신 맵(map) 자료구조 사용
• 각 레퍼런스를 맵에 추가 → 자동으로 중복 제거 → 효율적 처리
• 결과적으로 git bundle create 성능이 대폭 향상됨

벤치마크 결과:
레퍼런스 10만 개 기준 6배 이상의 성능 개선이 확인됐습니다.

---

결과: 48시간 → 41분, 1.4% 수준으로 단축

가장 큰 저장소 기준으로 백업 시간이 48시간에서 41분으로 감소했습니다.
이는 전체 시간의 1.4% 수준입니다.

뿐만 아니라:

• 저장소 크기와 무관하게 일관된 성능 제공 가능
• 서버 부하 감소
• Git 관련 명령 전반의 성능 개선
• 백업 실패 위험 감소

이 패치는 업스트림 Git 프로젝트에도 반영됐으며, GitLab에서는 버전 18.0부터 모든 사용자가 추가 설정 없이 바로 이점을 누릴 수 있습니다.

---

GitLab 사용자에게 어떤 변화가 있을까?

이번 개선으로 GitLab 사용자, 특히 대규모 저장소를 운영하는 기업은 다음과 같은 변화를 체감할 수 있습니다:

• 연속된 밤샘 백업을 개발 워크플로와 충돌 없이 실행 가능
• 재해 복구 시 데이터 손실 위험 대폭 감소
• 리소스 소비, 유지보수 시간, 클라우드 비용 절감
• 저장소가 커져도 백업 빈도와 성능 사이에서 더 이상 고민할 필요 없음

GitLab 사용자 입장에서는 백업이 안정적이고 빠른 일상적인 작업으로 자리잡게 됩니다.

---

728x90

이번 성능 개선은 단순한 코드 최적화 이상의 의미를 가집니다.
GitLab은 확장성 높은 엔터프라이즈급 Git 인프라 구축을 지속적으로 추진하고 있으며, 이번 사례는 그 노력의 일환입니다.

특히 GitLab이 기여한 개선 사항이 Git 자체에도 반영됨으로써 전 세계 Git 사용자와 오픈소스 커뮤니티 전체에 긍정적 영향을 미쳤다는 점이 주목할 만합니다.

앞으로도 GitLab은 이런 근본적이고 실질적인 성능 개선 작업을 통해 사용자 경험을 꾸준히 개선해 나갈 예정입니다.
GitLab의 성능 접근 방식과 더 깊은 이야기는 GitLab 18 버추얼 런치 이벤트에서도 확인할 수 있습니다.

https://about.gitlab.com/blog/2025/06/05/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/

How we decreased GitLab repo backup times from 48 hours to 41 minutes