코드 한 줄 안 읽고 Git 명령어 5개로 코드베이스 진단하기

• 코드를 한 줄도 안 열고 git 명령어 5개로 코드베이스 건강 상태를 진단하는 방법 — 커밋 히스토리만으로 "누가 만들었고, 어디가 아프고, 팀이 자신감 있게 배포하는지 아닌지"를 읽어낼 수 있음

가장 많이 바뀌는 파일 찾기 (Churn Hotspot)

• 최근 1년간 가장 많이 수정된 파일 Top 20을 뽑으면, 1등은 거의 항상 팀원들이 "아 그 파일... 아무도 건드리기 싫어하는 거"라고 하는 놈임
  • 높은 변경 빈도(churn) 자체가 나쁜 건 아님 — 활발한 개발일 수도 있음
  • 하지만 높은 churn + 아무도 오너십을 안 지려는 파일 = 코드베이스 드래그의 가장 확실한 신호
  • 패치 위에 패치를 쌓은 파일이라 작은 수정의 영향 범위가 예측 불가능하고, 팀이 이 파일 건드릴 때마다 일정을 뻥튀기함
• 2005년 Microsoft Research 연구에서 churn 기반 메트릭이 복잡도 메트릭 단독보다 결함 예측에 더 신뢰할 수 있다는 결과가 나옴
  • Top 5 파일을 아래 버그 핫스팟과 교차 대조하면 가장 위험한 파일 1개가 특정됨

누가 이걸 만들었나 (Bus Factor)

• 전체 커밋 기여자 순위를 뽑았을 때, 한 사람이 60% 이상이면 그게 버스 팩터(bus factor)임
  • 그 사람이 6개월 전에 떠났으면? 위기 상황
  • 전체 기간 Top 기여자가 최근 6개월 shortlog에 안 나타나면 즉시 플래그를 세움
• 꼬리 쪽도 봐야 함 — 기여자 30명인데 최근 1년 활동자가 3명이라면, 시스템을 만든 사람과 유지하는 사람이 완전히 다른 것
  • 주의: squash-merge 워크플로우를 쓰면 작성자가 아니라 머지한 사람으로 찍히니까, 머지 전략부터 확인 필요

버그가 어디에 몰려 있나

• churn 명령어와 같은 형태인데 커밋 메시지에 "bug", "fix" 등 키워드를 필터링한 버전
  • churn 핫스팟과 겹치는 파일 = 가장 고위험 코드 (계속 깨지고, 계속 패치하고, 제대로 고쳐지지 않는 파일)
• 커밋 메시지 습관에 크게 의존함 — 팀이 매번 "update stuff"로 커밋하면 아무것도 안 나옴
  • 그래도 대략적인 버그 밀도 맵이 맵 없는 것보단 훨씬 나음

프로젝트가 성장 중인가 죽어가는가

• 월별 커밋 수를 전체 히스토리로 뽑아서 패턴의 모양을 봄
  • 꾸준한 리듬 = 건강함
  • 한 달 만에 절반으로 뚝 떨어지면? → 보통 누군가 떠난 것
  • 6-12개월에 걸친 하락 커브 = 팀이 모멘텀을 잃고 있음
  • 주기적 스파이크 + 조용한 달 = 지속 배포가 아니라 릴리스 단위로 일감을 몰아서 하는 패턴
• 저자가 한 CTO에게 커밋 속도 차트를 보여줬더니 "그때 시니어 엔지니어 두 번째가 나간 때네요"라고 했다고 — 본인이 그 타임라인을 연결해본 적이 없었음. 코드 데이터가 아니라 팀 데이터

팀이 얼마나 자주 불 끄고 있나

• revert와 hotfix 빈도를 확인함
  • 1년에 몇 개 = 정상
  • 2주마다 revert = 배포 프로세스를 못 믿고 있다는 증거 (불안정한 테스트, 스테이징 미비, 롤백이 어려운 파이프라인)
  • 결과가 0개인 것도 신호 — 팀이 안정적이거나, 아무도 커밋 메시지를 안 쓰거나 둘 중 하나

---

기술 맥락

• git log 기반 코드베이스 분석은 "코드 품질 = 정적 분석"이라는 고정관념을 깨는 접근이에요. 정적 분석이 코드의 현재 상태를 보는 거라면, 커밋 히스토리 분석은 코드의 역사와 팀 다이나믹스를 보는 거거든요. 2005년 MS Research 논문이 이걸 뒷받침하는데, 복잡도(cyclomatic complexity 같은)보다 변경 빈도가 결함 예측에 더 효과적이었어요.
• churn + bug frequency 교차 분석은 "Technical Debt" 논의에서 자주 나오는 패턴이에요. 높은 churn인데 버그도 많다면, 그 파일은 리팩토링이 아니라 재설계가 필요한 경우가 많아요. 단순히 "이 파일 복잡도 높다"보다 훨씬 실행 가능한(actionable) 인사이트를 주는 거죠.
• bus factor 분석에서 squash-merge 워크플로우의 함정을 짚은 건 꽤 실용적이에요. GitHub에서 "Squash and merge"를 기본으로 쓰는 팀이 많은데, 이 경우 git shortlog로 보면 실제 작성자가 아닌 PR 머지한 사람만 나와요. 팀의 실제 기여도를 보려면 merge 전략부터 파악해야 하는 거예요.
• 월별 커밋 수 트렌드 분석은 엔지니어링 매니저 입장에서 팀 건강도 지표로도 쓸 수 있어요. 코드 리뷰 도구나 DORA 메트릭에서도 비슷한 시그널을 잡긴 하는데, git 명령어 하나로 빠르게 감을 잡을 수 있다는 게 이 접근의 장점이에요.