코드 열기 전에 Git으로 먼저 진단하는 법 — 신규 프로젝트 파악하는 5가지 명령어

 

안녕하세요! WoodyCode입니다. 🚀

 

"나 이번에 새 프로젝트 투입됐는데... 코드가 너무 많아서 어디서부터 봐야 할지 모르겠어."

 

신규 프로젝트에 투입되거나 레거시 코드를 넘겨받았을 때, 막막함 느껴보신 적 있으시죠? 파일 수백 개, 커밋 수천 개 — 어디서부터 시작해야 할지 감도 안 잡히는 그 느낌.

 

사실 코드를 열기 전에 Git 히스토리가 이미 다 말해주고 있어요. 어느 파일이 가장 위험한지, 버스 팩터는 얼마인지, 팀이 지금 위기인지 아닌지까지. 오늘은 코드 한 줄 안 읽고도 코드베이스를 진단하는 Git 명령어 5가지를 정리해봤습니다.

---

왜 코드보다 Git 히스토리를 먼저 봐야 할까요?

코드는 현재 상태만 보여줍니다. 하지만 Git 히스토리는 어떻게 여기까지 왔는지를 보여줘요.

어떤 파일이 계속 문제를 일으켰는지, 팀 멤버가 어느 시점에 이탈했는지, 배포 직전마다 핫픽스가 터졌는지 — 이런 맥락을 알고 코드를 읽는 것과 모르고 읽는 건 완전히 다른 경험이에요.

명령어 5개, 실행하는 데 2분도 안 걸립니다.

 

1️⃣ 가장 많이 바뀐 파일 — 여기가 지뢰밭입니다

git log --format=format: --name-only --since="1 year ago" \
  | sort | uniq -c | sort -nr | head -20

 

최근 1년간 가장 많이 변경된 파일 TOP 20을 뽑아줍니다. 이 목록 1위 파일은 거의 항상 팀에서 "그 파일 건드리지 마" 소리 듣는 파일이에요.

변경이 잦다고 무조건 나쁜 건 아니에요. 활발하게 개발 중인 파일일 수도 있으니까요. 문제는 잦은 변경 + 아무도 책임 안 지는 파일의 조합입니다. 작은 수정 하나가 예상치 못한 곳을 터뜨리는 파일이 바로 이런 경우예요.

💡 이 목록 상위 5개 파일을 아래 3번 명령어(버그 클러스터)와 교차 비교해보세요. 둘 다 걸리는 파일이 프로젝트 최대 리스크입니다.

 

2️⃣ 버스 팩터 확인 — 이 사람 나가면 어떻게 되지?

git shortlog -sn --no-merges

기여자별 커밋 수를 순위로 보여줍니다. 한 사람이 전체의 60% 이상을 차지하고 있다면 — 그게 버스 팩터 1입니다. 그 사람이 퇴사하면 프로젝트가 흔들려요.

더 무서운 건 상위 기여자가 최근 6개월 목록에서 사라진 경우예요.

git shortlog -sn --no-merges --since="6 months ago"

이 두 결과를 비교해서 핵심 기여자가 이미 팀을 떠난 상태라면, 그 코드는 사실상 고아 코드예요.

⚠️ squash merge 전략을 쓰는 팀이라면 커밋 수가 실제 기여도를 반영하지 않을 수 있어요. 팀의 merge 전략을 먼저 확인하세요.

 

3️⃣ 버그 클러스터 — 어디가 계속 터지나

git log -i -E --grep="fix|bug|broken" \
  --name-only --format='' \
  | sort | uniq -c | sort -nr | head -20

fix, bug, broken 키워드가 포함된 커밋에서 어떤 파일이 자주 등장하는지 집계합니다. 1번 명령어와 교차 분석하면 "자주 바뀌고 + 자주 버그 나는 파일"이 보여요. 이게 진짜 위험 구역이에요.

💬 단, 이 명령어는 커밋 메시지 품질에 달려있어요. 팀이 "update stuff", "minor fix" 같은 메시지를 쓴다면 결과가 부정확할 수 있습니다. 그것 자체가 팀 문화에 대한 신호이기도 하고요.

 

4️⃣ 커밋 속도 추이 — 팀이 살아있나요?

git log --format='%ad' --date=format:'%Y-%m' \
  | sort | uniq -c

월별 커밋 수를 전체 히스토리 기준으로 뽑아줍니다. 숫자보다 패턴을 봐야 해요.

꾸준한 리듬 → 건강한 팀. 특정 달에 갑자기 반토막 → 그 시점에 누군가 나갔을 가능성. 6~12개월 지속 하락 → 팀 모멘텀 상실. 주기적 폭증 후 침묵 → 배치 릴리즈 방식.

💡 이 데이터를 팀 히스토리(입퇴사, 조직 개편)와 맞춰보면 생각보다 많은 게 보여요. 코드 데이터가 아니라 팀 데이터입니다.

 

 

5️⃣ 핫픽스 빈도 — 배포가 두렵지 않은 팀인가

git log --oneline --since="1 year ago" \
  | grep -iE 'revert|hotfix|emergency|rollback'

revert, hotfix, emergency, rollback 키워드가 담긴 커밋을 찾아줍니다. 1년에 몇 번 나오는 건 정상이에요. 격주로 나온다면 — 팀이 배포를 두려워하고 있다는 신호입니다.

이 패턴 뒤에는 보통 세 가지 중 하나가 있어요. 신뢰할 수 없는 테스트, 스테이징 환경 부재, 롤백이 배포보다 어려운 파이프라인.

💬 결과가 0개라도 안심하면 안 돼요. 팀이 커밋 메시지를 성의 없이 쓰는 것일 수도 있으니까요.

---

개발자 인사이트 — 이걸 언제 써먹어야 할까요?

이 5개 명령어가 특히 빛나는 상황은 세 가지예요.

신규 프로젝트 투입 첫날	코드 읽기 전에 30초만 투자하면, 어디부터 봐야 할지 지도가 생겨요. 무작정 파일 열고 방황하는 것과 차원이 다른 온보딩 경험입니다.
레거시 인수인계받을 때	전임자가 남긴 코드의 위험 지점을 인수인계 문서보다 Git이 더 정직하게 말해줘요.
코드 리뷰 전 사전 조사	리뷰 요청받은 파일이 버그 클러스터 상위권이라면, 더 꼼꼼하게 볼 이유가 생기는 거죠. 주니어 때는 코드 자체에 집중하게 되지만, 시니어로 갈수록 "이 코드가 왜 이렇게 됐는가"를 읽는 능력이 중요해져요. Git 히스토리는 그 맥락을 가장 솔직하게 보여주는 도구입니다.

 

---

[3줄 요약]

✅ 코드 열기 전 Git 명령어 5개로 위험 파일, 버스 팩터, 버그 클러스터, 팀 상태를 2분 안에 파악할 수 있어요.

✅ 자주 바뀌고 + 버그도 자주 나는 파일 = 프로젝트 최대 리스크, 여기부터 집중 리뷰.

✅ Git 히스토리는 코드 데이터가 아니라 팀 데이터 — 맥락을 알고 코드를 읽는 것과 모르고 읽는 건 완전히 다릅니다.

 

 

[참고 출처]

※ 이 글은 Ally Piechowski의 아티클을 참고하여 WoodyCode 관점에서 재구성한 내용입니다.

 

검색 유입형 #Git #Git명령어 #코드리뷰 #레거시코드 #코드베이스분석 #버스팩터 #개발생산성

트렌드 강조형 #신규입사 #개발자팁 #클린코드 #DevOps

브랜딩형 #WoodyCode #개발자일상 #기술인사이트