---
title: "코드 한 줄 안 읽고 Git 명령어 5개로 코드베이스 진단하기"
published: 2026-04-08T08:53:42.000Z
canonical: https://jeff.news/article/1626
---
# 코드 한 줄 안 읽고 Git 명령어 5개로 코드베이스 진단하기

새 코드베이스를 맡았을 때 코드를 열기 전에 git 명령어 5개만으로 변경 빈도 핫스팟, 버스 팩터, 버그 집중 파일, 프로젝트 활력도, 핫픽스/리버트 빈도를 파악하는 방법을 소개함. 2005년 MS Research 연구를 근거로 churn 기반 메트릭의 결함 예측력을 뒷받침하고, 실제 CTO에게 커밋 속도 차트를 보여줬던 사례도 공유함.

- **코드를 한 줄도 안 열고 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개인 것도 신호** — 팀이 안정적이거나, 아무도 커밋 메시지를 안 쓰거나 둘 중 하나

> [!TIP]
> 이 5개 명령어는 2-3분이면 돌릴 수 있고, 새 코드베이스에서 "첫 날을 체계적으로 읽는 것"과 "그냥 헤매는 것"의 차이를 만들어줌

---

## 기술 맥락

- 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 명령어 하나로 빠르게 감을 잡을 수 있다는 게 이 접근의 장점이에요.

## 핵심 포인트

- 최근 1년간 가장 많이 수정된 파일 Top 20으로 코드베이스 드래그 지점을 찾음
- 한 사람이 커밋의 60% 이상이면 버스 팩터 위험 — 최근 6개월 활동 여부도 체크
- churn 핫스팟과 버그 핫스팟이 겹치는 파일이 가장 위험한 코드
- 월별 커밋 수 트렌드로 팀 모멘텀과 인력 이탈 시점을 파악
- revert/hotfix 빈도로 배포 프로세스 신뢰도를 판단

## 인사이트

코드 품질을 정적 분석이 아니라 커밋 히스토리의 패턴으로 진단하는 접근법. 새 프로젝트 온보딩이나 코드베이스 감사 시 첫 2-3분에 쓸 수 있는 실용적인 방법론이라 바로 써먹기 좋음.