Git 시니어 기술면접

blob 객체는 파일 내용 자체를 저장하고, tree 객체는 디렉토리 구조와 blob/subtree에 대한 포인터를 저장하며, commit 객체는 최상위 tree, 부모 커밋, 메타데이터를 저장합니다. 커밋 생성 시 먼저 변경된 파일들의 blob이 생성되고, 하위 디렉토리부터 상위로 올라가며 tree 객체들이 생성된 후, 마지막으로 commit 객체가 생성됩니다. 대규모 프로젝트에서는 변경되지 않은 객체는 재사용되므로 중복 저장이 방지되며, pack file을 통해 delta compression으로 저장 공간을 최적화하고, index 파일을 활용하여 staging 시 불필요한 객체 생성을 방지합니다.

Git-flow는 명확한 릴리즈 관리가 가능하지만 브랜치가 복잡하고 병합 오버헤드가 크며, GitHub-flow는 단순하지만 릴리즈 타이밍 제어가 어렵고, Trunk-based development는 CI/CD에 최적이지만 feature flag 관리가 필요합니다. 대규모 프로젝트에서는 short-lived feature branch + trunk-based 하이브리드 방식을 권장하며, main 브랜치는 항상 배포 가능 상태를 유지하고 feature flag로 릴리즈를 제어합니다. 병목 지점은 main 브랜치로의 병합 대기 시간인데, 이는 자동화된 테스트, 병렬 CI 파이프라인, merge queue 시스템으로 해결할 수 있습니다.

client-side hooks(pre-commit, commit-msg 등)는 로컬에서 빠른 피드백을 제공하지만 --no-verify로 우회 가능하고, server-side hooks(pre-receive, update)는 강제성이 있지만 네트워크 왕복으로 피드백이 느립니다. 효과적인 전략은 client-side에서 빠른 검사(포맷팅, 린팅)를 수행하고, server-side에서 필수 정책(커밋 서명, 브랜치 보호)을 강제하는 이중 검증 구조입니다. hooks 배포는 저장소 내 .githooks 디렉토리에 스크립트를 관리하고 git config core.hooksPath로 경로를 설정하거나, husky 같은 도구로 package.json에서 자동 설치하는 방식을 사용합니다.

Git LFS는 대용량 파일을 별도 저장소에 저장하고 Git에는 작은 pointer file(텍스트)만 커밋합니다. clean filter는 add/commit 시 실제 파일을 LFS 저장소로 업로드하고 pointer로 치환하며, smudge filter는 checkout 시 pointer를 읽어 실제 파일을 다운로드합니다. 기존 히스토리 마이그레이션은 git lfs migrate를 사용하여 과거 커밋을 재작성하되, 이는 SHA가 변경되므로 팀 전체가 force-push 후 re-clone해야 합니다. 주의사항으로는 LFS 저장소 용량 관리, 네트워크 대역폭 비용, CI/CD 환경에서의 LFS 인증 설정이 필요합니다.

commit signing은 개발자의 private key로 커밋 객체에 서명하고, public key로 검증하여 커밋 작성자의 신원을 보장합니다. 이는 이메일 스푸핑을 방지하고 공급망 공격을 완화하지만, 키 관리 복잡도와 CI/CD 환경에서의 자동화가 과제입니다. signed commit 강제 시 server-side hook으로 미서명 커밋을 거부하고, 팀원들의 public key를 중앙 관리하며, CI 봇 계정의 서명 전략도 수립해야 합니다. 브랜치 보호는 main/release 브랜치에 direct push 금지, required reviews 설정, CODEOWNERS로 특정 경로의 변경은 해당 팀 승인 필수로 구성하며, 권한은 역할 기반(RBAC)으로 관리합니다.