기타 Hacker News · 2026-10-14

배포할 때마다 깃 태그 만들다가 저장소 터뜨릴 뻔한 썰

핵심 요약
  • 배포할 때마다 메타데이터를 담은 깃 태그를 만들다 보니 수천 개가 쌓여 깃 명령어와 서버 속도가 크게 느려지는 문제가 발생했습니다.
  • 깃은 커밋 처리에는 강하지만 수천 개의 ref 검색에는 취약해 packed-refs 조회 지연 및 명령어 출력 공해를 유발했습니다.
  • 태그 이름에만 의존하는 배포 이력 관리의 한계를 짚고 깃 내부 히스토리 메커니즘을 활용한 대안 설계를 제안했습니다.
요약 개발자 마크 도미너스(Mark Dominus)가 ZipRecruiter 근무 시절 경험했던 대규모 모노레포(Monorepo)의 깃(Git) 성능 저하 문제와 이에 대한 개선 제안을 공유했습니다. 당시 회사 모노레포에서는 애플리케이션을 스테이징이나 프로덕션 환경에 배포할 때마다 배포 도구가 배포 티어, 앱 이름, 호스트 클래스, 배포 시각, 배포된 트리 해시를 포함한 긴 이름의 태그 오브젝트(ref)를 생성했습니다. 배포 이력을 상세히 기록하기 위한 조치였으나, 시간이 흐르며 저장소 내에 수천 개의 태그가 쌓이게 되었습니다. 깃은 수천 개의 커밋을 다루는 데는 능숙하지만, 수천 개의 ref를 처리하는 구조에는 최적화되어 있지 않았습니다. 당시 깃은 ref 목록을 packed-refs 파일에 저장했고, ref 이름을 오브젝트로 변환할 때마다 해당 파일을 검색해야 해 일상적인 깃 작업과 서버 처리 속도가 눈에 띄게 느려졌습니다. 또한 git fetch나 git branch 명령 실행 시 출력 결과가 온갖 배포 태그들로 뒤덮여 가독성을 심각하게 해쳤습니다. 여기에 더해 태그 방식 자체의 구조적 한계도 지적되었습니다. 배포 메타데이터가 단지 태그 이름 규칙에만 의존해 깃 자체로는 유효성을 검증할 수 없었고, 태그는 언제든 삭제나 변경이 가능해 불변 기록이라는 목적에도 맞지 않았습니다. 특정 앱이 프로덕션에 마지막으로 배포된 시점이나 이전 배포 버전으로의 롤백 대상 커밋을 찾으려면 수천 개의 태그를 전부 불러와 필터링하고 정렬해야 하는 비효율이 발생했습니다. 작성자는 수천 개의 ref를 남발하는 대신 깃 자체의 히스토리 메커니즘을 활용해 이름 없는 관련 오브젝트들의 연결로 배포 기록을 남기는 대안을 2019년에 제안했었다고 밝혔습니다.
Sponsored · 광고