"Git LFS 한도 초과." "?에셋이 몇 갠데" "없어"

오후에 긴급 회의가 있었다. Git LFS가 작동하지 않았던 것.
Git LFS 대역폭 한 달 제한인 10GB를 모두 써버려서 commit되고 있지 않았다.
문제는 Unreal Engine 프로젝트를 생성할 때 gitignore 설정 없이 올라갔던 것.
한 번 잘못 올라간 것으로 끝난 것이 아니라, 그런 프로젝트가 2개 있었고, 그 상태에서 한 번 더 업로드가 이어졌다.
결과적으로 Unreal Engine의 Intermediate가 포함된 업로드가 총 3번 발생했고, 그 과정에서 대역폭 제한을 넘어 버렸다.

갑자기 치솟은 사용량

---

문제 전파

더 큰 문제는 이 저장소들이 개인 공간이 아니라 Organizations 안에 있었다는 점이었다.
한 레포지토리에서만 문제가 끝나는 것이 아니라, Organizations 안의 다른 레포지토리들까지 Git LFS 업로드가 막혀 버렸다.

이 시점부터는 단순히 gitignore를 다시 맞추는 문제가 아니라, 앞으로 어떤 저장소 구조로 가야 같은 사고를 피할 수 있는지를 다시 정해야 했다.

---

회의에서 나온 방향

회의하면서 먼저 나온 건, 지금 Organizations 구조를 계속 유지할지부터 다시 보는 것이었다.
가장 먼저 방법은 모든 작업을 개인 레포지토리로 옮기는 것이었다.

다음으로는 Git LFS를 그대로 쓸 것이 아니라, 아예 다른 대용량 파일 관리 방법으로 바꾸는 방안도 같이 나왔다.

DVC

DVC를 쓰는 경우 가장 먼저 본 건 Google Drive를 백엔드로 사용하는 방식이었다.
이 방식은 현실적으로 저장소 비용 부담을 낮출 수 있다는 장점이 있었지만, 바로 실전 적용하기에는 준비할 것이 많았다.

Google OAuth 처리가 필요했고, 그에 맞춰 Google Cloud 쪽에서도 설정을 해 줘야 했다.
한두 명이 시험적으로 맞추는 건 가능해 보여도, 팀 전체가 빠르게 같은 설정을 맞춰야 하는 상황에서는 부담이 컸다.

다른 쪽으로는 Cloudflare R2 Storage를 DVC와 연결하는 방법도 같이 봤다.
작동 자체는 가능해 보였지만, 하루 안에 Organizations 구성원 전부에게 R2 계정을 만들게 하고 설정까지 맞추는 건 현실적으로 자신이 없었다.

Gitea, Perforce

Gitea, Perforce 같은 다른 도구도 후보로 생각했다.
다만 지금 상황에서는 기능보다 초기 진입 비용이 더 크게 보였다.

둘 다 별도 서버가 필요하거나, 초기 설정이 만만하지 않다는 점이 걸렸다.
지금 팀 상황에서는 저장소 운영 체계를 빨리 복구하는 것이 우선이었기 때문에, 새로운 도구를 도입하는 데 시간을 더 쓰는 방향은 맞지 않았다.

---

결

결국 최종적으로 정한 건 각자 개인 레포지토리를 만드는 방법을 택했다.
처음에는 Fork를 가져오는 쪽도 생각했지만, issue를 만들 수 없고 private 설정이 안되는 점 때문에 제외되었다.

급한 와중에 R2로 DVC연결이 성공되는 성과도 있었으니 뒷걸음 치다 쥐잡았다.