서버 백업 데이터가 git에 올라가는 문제 해결

최근 한 작업은 git 저장소의 정본성(canonical structure)을 되찾는 것이었다. 서버의 /opt/stats 디렉토리—실제 운영 중인 통계 백업과 크론 작업의 결과물들—이 버전 관리 대상에서 빠져야 한다는 걸 명확히 했고, 동시에 그 감시 체계를 개선했다.

문제의 뿌리: 데이터와 코드의 혼재

팀이 커질수록 이런 문제가 자주 나타난다. 보통은 다음 중 하나 때문이다:

1. 초기 설정 미흡: 프로젝트 초반 .gitignore을 충분히 신경 쓰지 않거나, 나중에 생긴 디렉토리를 제외하는 걸 깜빡함
2. 운영 작업의 누적: 크론 작업이 매일 /opt/stats에 통계 파일을 쌓으면서, "일단 여기 있는데 추적하지 말아야지" 라는 점이 코드 수준으로는 문서화되지 않은 채 관례로만 남음
3. onboarding 약화: 신입이 로컬 환경 설정할 때 "이 파일 깔 필요 없어" 같은 말이 README에 명확하게 안 적혀 있음

이번 작업은 이 세 가지를 한 번에 처리했다.

무엇을 바꿨는가

핵심은 수동 관례를 명시적 구조로 바꾼 것이다. 단순히 .gitignore에 한 줄 추가하는 게 아니라:

• 왜 이 디렉토리를 git에서 제외하는지를 README에 적음
• 그 디렉토리의 상태를 자동으로 감시하는 pv-watchdog 추가
• 감시 도구가 크론으로 정기적으로 실행되도록 함

이렇게 하면 향후 팀원이나 새 환경에서 "아, 저건 버전 관리 대상이 아니고, 대신 이 감시 도구로 체크하는 거구나" 하는 게 명백해진다.

팀 차원에서 배운 점

이런 "정본화" 작업은 번무해 보이지만, 실제로는 배포와 운영의 안정성에 영향을 미친다.

첫째, 무분별한 데이터 누적 방지. .gitignore을 명확히 하지 않으면, git 저장소 크기가 자꾸 커진다. 대량의 로그나 캐시 파일이 커밋되고 나면, git clone 속도가 느려지고, CI/CD 파이프라인도 무거워진다. 특히 팀의 첫 온보딩 시 "왜 이 repo가 이렇게 크지?" 하는 불만이 생긴다.

둘째, 감시 도구의 추가는 운영 신뢰도를 높인다. pv-watchdog이 정기적으로 백업 상태를 체크하면, 운영자가 매번 직접 확인할 필요가 없다. "뭔가 백업이 안 되고 있을 수도 있겠지?" 하는 모호함이 제거된다.

셋째, 문서화는 turnover를 준비하는 것. README에 명시하면, 6개월 뒤에 누군가 "이 디렉토리는 뭐지?" 하고 물을 때 답장할 수 있다.

다음 관점

비슷한 상황을 만났을 때 고려할 체크리스트:

• 서버에서 생성되는 데이터(로그, 백업, 임시 파일)가 git에 들어가 있지는 않은가?
• .gitignore에는 있지만 README에는 설명이 없는 규칙이 있는가?
• 제외된 디렉토리의 상태를 누군가 주기적으로 확인하는가, 아니면 "언젠가 문제가 생기겠지" 상태인가?

이번 작업을 통해 "git은 코드와 설정만"이라는 원칙을 팀 전체가 다시 한 번 인식하게 되었다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.