Git “error: object file … is empty” 해결 방법

Git “error: object file … is empty”란?

이 오류는 Git 저장소의 내부 데이터베이스에 있는 객체(object) 파일 중 하나가 비어 있거나 손상되었음을 의미합니다. Git은 모든 데이터를 .git/objects 디렉터리 내에 “객체”(커밋, 트리, 블롭 등)로 저장합니다. 어떤 이유로든 이 파일들 중 하나가 0바이트 크기의 빈 파일이 되면, Git은 해당 객체를 읽을 수 없으므로 이 오류를 보고합니다.

이 오류는 git status, git pull, git checkout 등 저장소의 데이터를 읽어야 하는 거의 모든 Git 명령어에서 발생할 수 있습니다.

오류의 일반적인 원인

1. 비정상적인 시스템 종료: Git이 객체 파일을 디스크에 쓰는 도중에 컴퓨터가 갑자기 꺼지거나 충돌하는 경우 파일이 불완전하게 쓰여 빈 파일로 남을 수 있습니다.
2. 디스크 공간 부족: 디스크 공간이 꽉 찬 상태에서 Git이 새 객체를 쓰려고 하면 실패하여 0바이트 파일이 생성될 수 있습니다.
3. 파일 시스템 오류: 하드 드라이브의 물리적 또는 논리적 오류로 인해 파일 내용이 손상될 수 있습니다.
4. 외부 프로그램의 간섭: 바이러스 백신이나 파일 동기화 프로그램(예: Dropbox, Google Drive)이 .git 디렉터리의 파일을 잘못 처리하여 손상을 유발할 수 있습니다.

오류 해결 방법

경고: 아래의 해결 방법들은 .git 디렉터리를 직접 조작할 수 있습니다. 진행하기 전에 반드시 저장소 전체를 백업하세요.

방법 1: 손상된 객체 파일 제거 후 git fsck 실행

가장 간단한 방법은 오류 메시지에 명시된 빈 객체 파일을 직접 삭제하는 것입니다.

1. 오류 메시지에서 파일 경로 확인: 오류 메시지는 보통 다음과 같은 형식을 가집니다: error: object file .git/objects/ab/cdef... is empty 여기서 ab/cdef...가 객체 파일의 경로와 이름입니다.

2. 해당 파일 삭제: 터미널에서 다음 명령을 실행하여 빈 객체 파일을 삭제합니다.

   # Linux/macOS
   rm .git/objects/ab/cdef...
   
   # Windows
   del .git\objects\ab\cdef...
   

3. 저장소 상태 확인: git fsck (file system check) 명령을 실행하여 저장소에 다른 문제가 있는지 확인합니다.

   git fsck --full
   

   dangling blob이나 dangling commit 같은 메시지가 나올 수 있지만, 이는 보통 심각한 문제가 아닙니다. 하지만 missing 관련 오류가 나타난다면 다른 객체도 손상되었을 수 있습니다.

4. 원격 저장소에서 다시 가져오기 (가능한 경우): 만약 손상된 객체가 원격 저장소(예: GitHub)에 존재한다면, git fetch를 통해 복구할 수 있습니다.

   git fetch origin
   

방법 2: 로컬 저장소를 새로 복제(Clone)

원격 저장소에 최신 변경 사항이 모두 푸시되어 있다면, 가장 안전하고 확실한 방법은 로컬 저장소를 삭제하고 원격 저장소에서 새로 복제하는 것입니다.

1. 현재 로컬 저장소의 이름을 변경하거나 삭제합니다.

   # 현재 디렉터리 밖으로 이동
   cd ..
   
   # 폴더 이름 변경 (백업용)
   mv your-repo-name your-repo-name-backup
   

2. 원격 저장소에서 다시 복제합니다.

   git clone <your-remote-repository-url>
   

이 방법은 커밋하지 않은 로컬 변경 사항이나 스태시(stash)가 없는 경우에 가장 이상적입니다.

방법 3: 다른 개발자의 저장소에서 객체 복사

팀 프로젝트를 진행 중이고 원격 저장소에 푸시되지 않은 커밋이 로컬에 있는 경우, 다른 팀원의 정상적인 저장소에서 손상된 객체 파일을 복사해올 수 있습니다.

1. 손상된 객체 파일의 경로(.git/objects/ab/cdef...)를 확인합니다.
2. 다른 팀원의 컴퓨터에서 해당 경로의 파일을 찾아 복사합니다.
3. 내 로컬 저장소의 동일한 위치에 붙여넣습니다.
4. git fsck로 저장소 상태를 다시 확인합니다.

예방 조치

• .git 디렉터리를 파일 동기화 서비스의 동기화 대상에서 제외합니다.
• 중요한 작업을 마친 후에는 주기적으로 원격 저장소에 푸시합니다.
• 디스크 공간을 정기적으로 확인합니다.

결론

error: object file ... is empty 오류는 Git의 내부 데이터베이스 손상으로 인해 발생하며, 보통 시스템의 비정상적인 종료나 외부 요인에 의해 유발됩니다. 가장 간단한 해결책은 손상된 객체를 제거하고 원격 저장소에서 다시 가져오는 것이며, 문제가 심각하거나 원격 저장소가 최신 상태일 경우 새로 복제하는 것이 가장 안전합니다. 작업 전에는 항상 저장소를 백업하는 습관을 들이는 것이 중요합니다.

전문 보완 체크

Git “error: object file … is empty” 해결 방법에서 중요한 기준은 독자가 한 번 따라 해서 성공했는지가 아닙니다. 이 주제는 재현 가능한 디버깅 절차로 다루는 편이 안전합니다. 결론을 내리기 전에 실행 환경, 정확한 오류 경계, 최소 재현 예제, 되돌릴 수 있는 경로를 확인해야 합니다. 또한 나중에 같은 문제가 반복될 수 있으므로, 관찰한 사실과 사용한 가정, 결론이 바뀔 조건을 짧은 결정 기록으로 남기는 것이 좋습니다.

신뢰도를 높이는 증거

작업을 바꾸기 전에는 객관적인 증거를 먼저 확인해야 합니다. 쓸 만한 증거에는 전체 명령 출력, 버전 번호, 변경된 파일, 기대 동작과 실제 동작가 포함됩니다. 증거가 서로 맞지 않으면 억지로 하나의 이야기로 합치지 말고 충돌 자체를 남겨야 합니다. 빠른 해결이 한 번 성공했더라도 같은 입력, 계정, 의존성, 기기 상태에서 다시 확인하지 않았다면 아직 확정된 해결책이라고 보기 어렵습니다.

검토 표

검토 항목	확인할 내용	중요한 이유
범위	이 글이 다루는 정확한 사례	조언을 과도하게 적용하지 않게 합니다
기준 상태	변경 전 상태	되돌리기와 비교를 가능하게 합니다
변경	실제로 수행한 가장 작은 조치	숨은 부작용을 줄입니다
결과	변경 뒤 관찰한 출력 또는 반응	기대와 증거를 구분합니다
재확인	결론을 다시 볼 시점	글의 정확도를 유지합니다

예외 상황과 실패 모드

주요 위험은 증상만 고치고 원인을 남기는 상황, 서로 무관한 변경을 같은 테스트에 섞는 상황입니다. 생산 데이터, 개인정보, 돈, 건강, 법적 권리, 보안 복구가 관련되어 있다면 넓은 해결책을 바로 적용하기보다 먼저 증거를 모으는 보수적인 접근이 낫습니다. 같은 제목의 문제라도 환경이 다르면 원인이 달라질 수 있으므로, 독자는 명령이나 결정을 복사하기 전에 자신의 조건이 글의 가정과 맞는지 비교해야 합니다.

유지보수 기준

이 안내는 의존성, 운영체제, 빌드 도구가 바뀐 뒤 다시 확인해야 합니다. 좋은 업데이트는 글 전체를 다시 쓰는 것이 아니라 예시, 링크, 명령, 화면, 판단 기준이 현재 동작과 여전히 맞는지 확인하는 일입니다. 기존 결론이 유효하면 확인 날짜를 남기고, 바뀌었다면 무엇이 바뀌었고 왜 이전 조언만으로 부족한지 설명해야 합니다.

실행 전 질문

• 문제나 판단이 실제임을 보여 주는 가장 작은 관찰 신호는 무엇인가?
• 공식 출처는 무엇이고, 내부 판단은 어느 부분인가?
• 변경 전에 반드시 캡처해야 할 기록은 무엇인가?
• 어떤 결과가 나오면 이 글의 조언이 맞지 않는다고 볼 것인가?
• 같은 문제가 반복될 때 누가 이 기록을 다시 봐야 하는가?

함께 보면 좋은 글

같은 주제 흐름에서 이어서 읽기 좋은 글입니다.

• SSL: CERTIFICATE_VERIFY_FAILED 오류 해결 방법 (Windows Python)
• Permission denied (publickey) 오류 해결 방법 (Windows Git SSH)