코드를 읽기 전에 실행하는 Git 명령들

4 days ago 2

새로운 코드베이스를 접할 때 Git 이력 분석으로 프로젝트의 구조와 위험 구역을 파악해 효율적인 탐색 방향을 설정
최근 1년간 가장 자주 변경된 파일을 찾아 변경 빈도와 버그 집중도를 교차 분석해 고위험 코드를 식별
기여자 분포와 활동 추세를 통해 버스 팩터, 유지보수 공백, 지식 단절 가능성을 점검
월별 커밋 수로 팀의 개발 속도와 동력 변화를 추적하고, Revert·Hotfix 빈도로 배포 안정성을 평가
이 다섯 가지 명령은 코드 한 줄을 열기 전 프로젝트 건강 상태를 빠르게 진단하는 실질적 도구로 활용 가능

코드 읽기 전 실행하는 다섯 가지 Git 명령

새로운 코드베이스를 분석할 때, 파일을 열기 전에 Git 이력으로 프로젝트의 건강 상태를 진단하는 접근
- 커밋 히스토리를 통해 누가 만들었는지, 문제가 어디에 집중되는지, 팀이 얼마나 안정적으로 배포하는지를 파악
무엇이 가장 자주 변경되는가
- 명령: git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
- 최근 1년간 가장 많이 수정된 상위 20개 파일을 표시
- 상위 파일은 종종 팀이 “건드리기 두려워하는” 파일로, 높은 변경 빈도(churn) 와 소유 회피가 결합될 경우 코드베이스의 가장 큰 부담 요인
- Microsoft Research(2005) 연구에 따르면 변경 빈도 기반 지표가 복잡도 지표보다 결함 예측력이 높음
- 상위 5개 파일을 버그 집중도 명령과 교차 분석해 변경 많고 버그도 많은 파일을 최대 위험 요소로 식별
누가 이 코드를 만들었는가
- 명령: git shortlog -sn --no-merges
- 커밋 수 기준으로 기여자를 순위화
- 한 사람이 60% 이상을 차지하면 버스 팩터(bus factor) 위험 존재
- 상위 기여자가 최근 6개월 내 활동하지 않았다면 유지보수 공백 가능성
- 30명의 기여자 중 최근 1년간 3명만 활동 중이라면 개발자 교체로 인한 지식 단절 발생
- 단, squash-merge 전략을 사용하는 팀은 작성자 정보가 병합자 중심으로 왜곡될 수 있어 병합 전략 확인 필요
버그는 어디에 집중되는가
- 명령: git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
- 버그 관련 키워드가 포함된 커밋을 기반으로 버그 발생 파일 상위 20개를 추출
- 이 목록을 변경 빈도 목록과 비교해 자주 수정되고 자주 고장나는 파일을 고위험 코드로 식별
- 커밋 메시지 품질에 따라 결과 정확도가 달라지지만 대략적인 버그 밀도 지도로도 충분히 유용
프로젝트가 가속 중인가, 정체 중인가
- 명령: git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
- 월별 커밋 수를 통해 활동 추세를 시각적으로 파악
- 일정한 리듬은 건강한 프로젝트를 의미
- 한 달 만에 커밋 수가 절반으로 줄면 핵심 인력 이탈 가능성
- 6~12개월간 지속적인 감소는 팀 동력 저하, 주기적 급증 후 정체는 배치형 릴리스 패턴을 시사
- 실제 사례로, 커밋 속도 차트를 통해 CTO가 “그 시점이 시니어 엔지니어가 떠난 때”임을 인식한 경우 존재
- 이 데이터는 코드 데이터가 아닌 팀 데이터로서 의미
팀이 얼마나 자주 긴급 대응 중인가
- 명령: git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
- Revert·Hotfix 빈도를 측정
- 1년에 몇 건은 정상이나, 2주마다 발생한다면 배포 프로세스 불신 신호
- 이는 테스트 불안정, 스테이징 부재, 복잡한 롤백 절차 등 더 깊은 문제의 징후
- 결과가 0이라면 팀이 안정적이거나 커밋 메시지가 부정확한 경우
- 위기 패턴은 명확히 드러나며, 존재 여부만으로도 신뢰도 판단 가능