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

Git commands I run before reading any code

📅 2026-04-08 📰 Hacker News (Top) ⬆ 1.7k

요약

새로운 코드베이스를 분석할 때 코드를 열기 전에 실행해야 할 5가지 Git 명령어를 소개하여 프로젝트의 건강도와 위험 요소를 빠르게 파악한다.

핵심 포인트

변경이 많은 파일 추출으로 고위험 코드 영역 식별 - 높은 변경 빈도와 높은 버그 빈도를 모두 가진 파일이 최대 위험 요소
커미터 분석으로 버스 팩터 파악 - 한 명의 개발자가 60% 이상의 커밋을 담당하면 위기 상황
월별 커밋 수로 프로젝트 진행 상황 파악 - 커밋 속도 급락은 팀원 이탈이나 모멘텀 감소를 의미
버그 관련 커밋 로그로 문제 영역 추출 - 반복해서 패치되는 파일은 근본적인 해결이 필요한 신호
리버트/핫픽스 빈도로 팀의 안정성 평가 - 빈번한 리버트는 배포 프로세스나 테스트 신뢰도 문제를 시사

왜 중요한가

새로운 코드베이스를 분석할 때 어느 부분부터 살펴봐야 할지 우선순위를 정하고 숨은 기술 부채를 조기에 발견할 수 있다.

📄 전문 번역

새로운 코드베이스를 읽을 때 먼저 하는 5가지

새로운 프로젝트를 시작할 때 저는 코드부터 보지 않습니다. 먼저 터미널을 열고 몇 가지 git 명령어를 실행합니다. 커밋 히스토리를 보면 누가 만들었는지, 어디서 문제가 많이 발생하는지, 팀이 자신감 있게 배포하는지 아니면 조심스럽게 움직이는지 한눈에 파악할 수 있거든요.

1. 가장 자주 수정되는 파일들

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

지난 1년간 가장 많이 변경된 상위 20개 파일을 볼 수 있습니다. 맨 위에 있는 파일이 팀원들 사이에서 악명 높은 경우가 많아요. "아, 그 파일 말이군요. 다들 건드리기 무서워하는 파일이죠."

파일의 변경 빈도가 높다고 해서 반드시 나쁜 코드는 아닙니다. 활발한 개발이 진행 중일 수도 있으니까요. 하지만 아무도 책임지고 싶어 하지 않는 파일의 변경 빈도가 높다면? 그것만큼 명확한 코드베이스 부채의 신호는 없습니다. 그런 파일은 패치 위에 패치를 얹는 악순환에 빠져있거든요. 작은 수정 하나도 어떤 부작용을 일으킬지 예측할 수 없고, 팀원들은 이 파일을 건드릴 때마다 일정을 넉넉하게 잡게 됩니다.

마이크로소프트 리서치의 2005년 연구에 따르면, 변경 빈도 기반 지표가 복잡도 지표만으로는 버그를 예측하는 것보다 더 정확하다고 합니다. 저는 이 목록에서 상위 5개 파일을 다음 명령어와 비교해 봅니다. 변경도 많고 버그도 많은 파일이 당신이 가장 먼저 살펴봐야 할 위험 지역입니다.

2. 누가 이 코드를 만들었나

git shortlog -sn --no-merges

모든 기여자를 커밋 수 기준으로 순위 매긴 목록입니다. 한 사람이 전체의 60% 이상을 차지한다면 그건 위험 신호예요. 그 사람이 6개월 전에 떠났다면 위기 상황입니다. 또 한 가지 더 확인할 점이 있습니다.

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

이 명령어에서 과거 6개월 내 상위 기여자가 전체 순위와 다르다면 바로 클라이언트에 알립니다. 시스템을 처음 만든 사람과 지금 유지보수하는 사람이 다르다는 뜻이니까요.

다만 한 가지 주의할 점이 있습니다. 만약 팀이 squash-merge 워크플로우를 사용한다면, 실제 기여자 대신 머지한 사람의 이름만 기록될 수 있어요. 결론을 내리기 전에 팀의 머지 전략에 대해 먼저 물어보는 게 좋습니다.

3. 버그가 많이 발생하는 영역

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

버그 관련 키워드가 포함된 커밋들만 필터링한 결과입니다. 이 목록을 변경 빈도가 높은 파일 목록과 비교해 보세요. 두 목록 모두에 나타나는 파일들이 당신의 최우선 위험 지역입니다. 계속 버그가 발생하고 계속 패치되지만, 근본적으로는 고쳐지지 않는 코드들이거든요.

이 명령어의 신뢰도는 팀의 커밋 메시지 품질에 달려있습니다. 모든 커밋에 "업데이트"라고만 적혀있다면 결과를 기대하기 어렵지만, 대략적인 버그 밀도 지도라도 없는 것보다는 낫습니다.

4. 프로젝트가 성장 중인가, 쇠퇴 중인가

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

저장소 전체 히스토리에서 월별 커밋 수입니다. 출력 결과의 패턴을 살펴보세요. 일정한 리듬이 유지되면 건강한 상태입니다. 하지만 한 달 사이에 커밋 수가 절반으로 떨어졌다면? 보통 누군가 떠났다는 뜻이에요.

6~12개월에 걸친 지속적인 하락세는 팀이 추진력을 잃고 있다는 신호입니다. 간헐적인 스파이크 다음에 조용한 기간이 반복된다면 팀이 연속 배포가 아닌 릴리스 기반으로 일하고 있다는 뜻이죠.

한 번은 CTO에게 이 차트를 보여줬는데 "그때가 시니어 엔지니어가 떠난 시점이군요"라고 했어요. 팀은 데이터를 통해서야 비로소 인과관계를 알아차렸습니다. 이건 코드 데이터가 아니라 팀 데이터거든요.

5. 팀이 얼마나 자주 비상 상황에 대응하나

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

revert와 hotfix의 빈도를 봅니다. 연간 몇 건 정도면 정상입니다. 하지만 2주마다 revert가 발생한다면? 그건 팀이 배포 프로세스를 신뢰하지 못한다는 뜻입니다. 더 깊은 문제의 신호죠. 불안정한 테스트, 부족한 스테이징 환경, 롤백이 어려운 배포 파이프라인 같은 것들이 숨어있을 가능성이 높습니다.

결과가 0이어도 신호가 될 수 있어요. 팀이 정말 안정적이거나, 아니면 커밋 메시지를 제대로 안 쓰는 것일 수 있으니까요. 위기 패턴은 읽기가 쉽습니다. 있거나 없거나 둘 중 하나니까요.

시작이 끝이 아닙니다

이 5개 명령어는 몇 분이면 실행할 수 있습니다. 이것만으로 모든 걸 알 수는 없지만, 어떤 코드부터 읽어야 할지, 그 코드를 읽을 때 뭘 봐야 할지는 명확해집니다. 이것이 첫날을 체계적으로 코드베이스를 읽으며 보내는 것과 정처 없이 헤매며 보내는 것의 차이입니다.

이것이 제가 코드베이스 감사를 시작할 때 하는 첫 1시간입니다. 남은 일주일은 또 다른 방식으로 진행되죠.

🔗 원문 보기 👍 유용해요