git push가 실패한다고 바로 원격 저장소나 인터넷 문제로 단정하면 안 됩니다. 제 저장소는 파일 수정과 일부 커밋 작업은 가능했지만, 오브젝트를 묶어 보내는 단계에서 inflate: data stream error가 발생했습니다.
2026년 8월 21일 읽기 전용 무결성 검사를 실행하자 손상되거나 누락된 오브젝트 3개와 잘못된 HEAD reflog 항목이 나왔습니다. 이 글에서는 삭제부터 하지 않고 상태를 확인한 뒤, 복구 가능한 원본을 확보하는 순서를 설명합니다.
3줄 결론
- 먼저 git fsck로 저장소 내부 문제인지 확인합니다
- 손상 저장소에서 gc, prune, 강제 초기화를 먼저 실행하지 않습니다
- 원격의 정상 복제본과 현재 작업 파일을 따로 확보한 뒤 필요한 변경만 옮기는 방식이 안전합니다
확인일 2026-08-21 · 대상: 실제 작업 중 손상 오류가 발생한 로컬 Git 저장소 1개
push 오류와 저장소 손상을 구분하는 첫 검사
네트워크 오류, 인증 실패, 브랜치 보호 오류는 메시지가 서로 다릅니다. inflate, unable to unpack header, object corrupt or missing이 보인다면 로컬 .git/objects 내부를 의심해야 합니다.
상태를 바꾸지 않는 첫 명령은 다음입니다.
git fsck --no-progress --no-dangling
Git 공식 문서에 따르면 git fsck는 오브젝트 데이터베이스의 연결성과 유효성을 검사합니다. 제 저장소에서는 다음 종류의 결과가 나왔습니다.
object corrupt or missing: 466a742c...
object corrupt or missing: 6ab4e079...
missing commit e5188f32...
HEAD: invalid reflog entry e5188f32...
종료코드는 3이었습니다. 단순히 참조되지 않는 dangling 오브젝트가 있다는 수준이 아니라 실제 오브젝트를 읽지 못했다는 뜻입니다.
왜 커밋은 되는데 push에서 터질 수 있나
Git 저장소는 작업 파일만 보관하지 않습니다. 커밋, 트리, 파일 내용, 참조 기록을 오브젝트로 저장합니다. 새 파일을 수정하고 인덱스에 올리는 작업은 손상된 과거 오브젝트를 즉시 읽지 않을 수 있습니다. 반면 push는 원격과 차이를 계산하고 필요한 오브젝트를 압축하는 과정에서 과거 연결을 따라갑니다.
그래서 겉으로는 최근 파일이 멀쩡하고 git status도 보이지만, push나 log 탐색에서 갑자기 실패할 수 있습니다. “지금 커밋이 만들어졌으니 저장소도 정상”이라는 판단이 위험한 이유입니다.
오브젝트 수치도 확인했습니다.
git count-objects -v
검사 당시 느슨한 오브젝트 625개, 팩 내부 오브젝트 486개, 팩 1개가 있었습니다. 이 숫자 자체가 손상을 의미하지는 않습니다. fsck 오류와 함께 보면서 어떤 저장 형태에 문제가 있는지 범위를 좁히는 보조 자료입니다.
먼저 하면 위험한 명령
문제가 보이면 저장 공간을 정리하려고 git gc나 git prune부터 실행하기 쉽습니다. 하지만 복구 전에는 피하는 편이 안전합니다. Git 공식 문서도 git gc가 불필요한 파일을 정리하고 오브젝트를 압축하는 저장소 관리 명령이라고 설명합니다.
이미 손상된 저장소에서 정리 명령을 먼저 실행하면 복구 단서가 줄어들 수 있습니다. 특히 다음 작업은 원본 보존 전에 실행하지 않는 것이 좋습니다.
git gc --prune=now
git prune
git reset --hard
.git/objects 직접 삭제
제 저장소는 gc.auto=0으로 자동 gc가 꺼져 있었습니다. 이것이 손상의 원인이라는 뜻은 아닙니다. 다만 조사 중 자동 정리가 추가로 실행되지 않는 상태라는 점은 확인할 수 있었습니다.
가장 안전한 복구 순서
첫째, 손상 저장소 폴더를 그대로 보존합니다. 둘째, 원격 저장소를 새 경로에 다시 clone합니다. 셋째, 손상 저장소의 작업 파일과 새 복제본을 비교합니다. 넷째, 필요한 파일 변경만 새 복제본으로 옮기고 테스트한 뒤 새 커밋을 만듭니다.
git clone 원격주소 새폴더
손상 저장소에만 있고 원격에는 없는 커밋이 있다면 난도가 올라갑니다. 다른 컴퓨터의 복제본, CI 체크아웃, 백업, 동료 저장소에서 같은 오브젝트를 구할 수 있는지 확인해야 합니다. 오브젝트 해시가 정확히 같다는 검증 없이 임의 파일을 .git/objects에 넣어서는 안 됩니다.
이 글에서는 손상 저장소를 실제로 삭제하거나 재작성하지 않았습니다. 현재 확인된 사실은 오브젝트 3개와 reflog 항목의 오류까지입니다. 복구 방식은 원격과 백업에 남은 데이터에 따라 달라집니다.
재발을 줄이는 운영 방법
중요 작업은 원격에 자주 push하고, 한 저장소만 유일한 원본이 되지 않게 해야 합니다. 디스크 오류나 강제 종료가 의심된다면 Git만 고치고 끝내지 말고 저장장치 상태와 파일 시스템도 점검해야 합니다.
복구 뒤에는 새 복제본에서 다시 git fsck를 실행하고, 필요한 브랜치의 log와 build가 정상인지 확인합니다. push 성공만으로 모든 과거 참조가 정상이라고 단정하지 않습니다.
자주 묻는 질문 FAQ
Q. git fsck의 dangling 메시지도 손상인가요?
반드시 그렇지는 않습니다. 참조되지 않는 오브젝트가 남았다는 의미일 수 있습니다. corrupt, missing, unable to unpack 같은 메시지는 더 직접적인 이상 신호입니다.
Q. .git 폴더만 지우고 다시 init하면 되나요?
작업 파일만 살리는 데는 도움이 될 수 있지만 기존 커밋 이력과 브랜치 정보를 잃습니다. 원본 보존과 새 clone을 먼저 권합니다.
Q. 손상 오브젝트 파일만 삭제하면 되나요?
그 오브젝트를 가리키는 커밋과 reflog가 남아 있을 수 있습니다. 관계를 모른 채 삭제하면 손상이 확대될 수 있습니다.
Q. 이 방법으로 모든 저장소를 복구할 수 있나요?
아닙니다. 정상 원격·백업·다른 복제본이 있는지에 따라 복구 가능 범위가 결정됩니다.
실행 체크리스트
- 오류 전문과 실패 명령을 보존한다
git fsck --no-progress --no-dangling로 읽기 전용 검사한다- 저장소 원본 폴더를 그대로 보존한다
- 별도 경로에 원격 저장소를 새로 clone한다
- 작업 파일 차이만 새 복제본으로 옮긴다
- 새 복제본에서 테스트, log, fsck, push를 차례로 확인한다
참고 자료
출처 확인일: 2026-08-21
댓글