코드 읽기 전에 먼저 보는 깃 명령 5가지, 새 프로젝트 상태를 가장 빨리 읽는 법

한눈에 보기

• 출발점: 새 프로젝트는 파일보다 깃 기록부터 보면 훨씬 빠름
• 먼저 볼 것: 자주 바뀐 파일, 오류가 몰린 파일, 많이 손댄 사람, 월별 흐름, 긴급 복구 흔적
• 가장 위험한 조합: 자주 바뀌고 자주 고쳐진 파일
• 팀 신호: 한 사람 의존, 최근 담당자 이탈, 되돌리기 반복은 모두 경고등
• 실무 장점: 첫날 읽을 파일과 물어볼 질문이 빠르게 정리됨
• 읽는 태도: 이 다섯 명령은 정답이 아니라 현장 점검표

서론

새 프로젝트를 맡거나 오래된 서비스를 넘겨받으면 많은 개발자가 곧바로 파일부터 연다. 하지만 2026년 4월 8일 앨리 피에호프스키가 공개한 글은 순서를 바꿔 보라고 말한다. 코드를 읽기 전에 먼저 깃 기록을 보면, 어디가 자주 흔들렸고 팀이 어떤 방식으로 버텨 왔는지 더 빨리 보인다는 뜻이다.

이 글이 눈에 띄는 이유는 명령어를 나열하는 데서 멈추지 않기 때문이다. 작성자는 다섯 개의 명령만으로 위험 파일, 특정 사람 의존, 오류 집중 구간, 팀 속도, 긴급 대응 습관을 짧은 시간 안에 읽을 수 있다고 본다. 깃 로그를 단순 기록이 아니라 프로젝트 건강검진 자료처럼 쓰자는 제안이다.

이번 글은 원문을 길게 옮기기보다, 무엇을 보여 주는지, 왜 중요한지, 실제로 어떻게 읽으면 되는지를 중심으로 다시 풀어 썼다. 중고등학생도 이해할 수 있도록 어려운 말은 줄이고, 현장에서 바로 써먹을 수 있는 뜻만 남겼다.

1. 왜 코드를 열기 전에 깃부터 볼까

• 먼저 보이는 것: 파일보다 변화의 흔적
• 바로 잡히는 질문: 어디가 자주 흔들리는지, 누가 많이 손댔는지
• 실무 효과: 첫날 읽을 파일 순서가 달라짐
• 원문 시선: 깃 기록은 프로젝트의 진단 사진

코드는 지금 모습을 보여 준다. 반면 깃 기록은 어떻게 여기까지 왔는지를 보여 준다. 같은 서비스라도 지난 1년 동안 수십 번 뜯어고친 파일과 거의 손대지 않은 파일은 읽는 우선순위가 다를 수밖에 없다.

이 차이는 새 팀에 들어간 첫날 특히 크게 느껴진다. 아무 준비 없이 파일을 열면 구조를 넓게 훑는 데 시간이 다 가기 쉽다. 하지만 기록을 먼저 보면, 어디를 먼저 보고 누구에게 먼저 물어봐야 할지가 잡힌다.

쉽게 말해 처음 가 보는 동네에서 모든 골목을 같은 비중으로 걷는 대신, 사람들이 자주 몰리는 길과 사고가 잦은 교차로를 먼저 보는 셈이다. 깃 로그는 프로젝트 안의 그런 붐비는 길과 위험 구간을 보여 준다.

2. 가장 많이 손댄 파일부터 찾는다

• 확인 명령: git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
• 읽는 뜻: 지난 1년 동안 가장 자주 수정된 파일 20개
• 진짜 포인트: 자주 바뀌는지보다 다들 피하는 파일인지가 더 중요
• 실무 해석: 작은 수정도 크게 번질 수 있는 파일

첫 번째 명령은 지난 1년 동안 가장 많이 바뀐 파일을 세는 방식이다. 겉으로 보면 단순한 집계지만, 현장에서는 의외로 강한 신호를 준다. 팀에서 "그 파일은 조심해서 봐야 한다"고 말하는 대상이 이 목록 위쪽에 올라오는 경우가 많기 때문이다.

물론 자주 바뀐 파일이 모두 나쁜 것은 아니다. 한창 새 기능을 붙이는 화면이나 설정 파일은 당연히 수정이 많다. 문제는 변경 횟수는 많은데 누구도 맡고 싶어 하지 않는 파일이다.

이런 파일은 대개 덧댄 수정이 또 다른 수정을 부르는 구조가 된다. 작은 손질 하나가 어디까지 퍼질지 예측하기 어렵고, 팀은 같은 작업에도 일정을 넉넉하게 잡게 된다. 원문이 이 목록을 첫 번째로 보는 이유도 여기에 있다.

글쓴이는 2005년 마이크로소프트 연구도 함께 떠올린다. 이 연구는 코드 변경량을 바탕으로 한 지표가 결함 예측에 도움이 될 수 있다고 봤다. 그래서 이 목록의 상위 파일은 뒤에 나오는 오류 집중 파일 목록과 꼭 겹쳐 보는 편이 좋다.

3. 누가 이 시스템의 메인인지 본다

• 확인 명령: git shortlog -sn --no-merges
• 읽는 뜻: 병합 기록을 빼고 사람별 커밋 수를 순서대로 확인
• 핵심 질문: 이 시스템은 몇 사람이 사실상 떠받치고 있나
• 가장 위험한 신호: 한 사람이 절반 이상을 차지하는데 최근에는 보이지 않는 경우

두 번째 명령은 코드를 만든 사람 흐름을 보여 준다. 이 명령을 보면, 어떤 저장소가 한두 명의 머릿속에 너무 많이 기대고 있는지 감이 온다. 특정 한 사람이 전체 기록의 큰 비중을 차지한다면, 그 사람은 단순한 기여자가 아니라 사실상 시스템 기억창고에 가깝다.

더 중요한 것은 지금도 그 사람이 있는가다. 전체 기록에서는 1위 기여자인데 최근 6개월 기록에는 거의 없다면 이야기가 달라진다. 시스템을 가장 잘 아는 사람이 이미 떠났거나, 다른 일로 빠졌을 가능성이 크기 때문이다.

반대로 아래쪽도 같이 봐야 한다. 이름은 많지만 최근에 실제로 움직인 사람은 몇 명 안 될 수 있다. 그런 프로젝트는 "만든 사람"과 "지금 관리하는 사람"이 완전히 달라져 있는 경우가 많다.

이 명령도 해석할 때 조심할 점이 있다.

• 커밋을 하나로 합쳐 병합하는 팀: 실제 작성자보다 병합한 사람이 더 많이 보일 수 있음
• 자동 기록이 많은 저장소: 봇 계정이 통계를 흔들 수 있음
• 대량 정리 작업이 잦은 팀: 설계 기여보다 한 번의 큰 수정이 더 크게 잡힐 수 있음

그래서 이 결과는 판정표가 아니라 질문표에 가깝다. 누가 실제 구조를 알고 있는지, 최근에는 누가 유지보수를 맡는지, 기록 방식은 어떤지부터 같이 확인해야 한다.

4. 오류가 몰린 파일을 찾는다

• 확인 명령: git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
• 읽는 뜻: 오류 수정 관련 커밋에서 자주 등장한 파일
• 가장 중요한 비교: 많이 바뀐 파일 목록과 겹치는지 확인
• 실무 해석: 계속 깨지고 계속 때우는 파일 찾기

세 번째 명령은 오류 흔적을 따라간다. 커밋 메시지 안에 오류 수정 뜻의 영어 단어가 들어간 기록만 모아, 어떤 파일 이름이 자주 나오는지 보는 방식이다. 아주 정밀한 통계는 아니지만, 프로젝트의 상처 자국이 어느 부분에 몰려 있는지 빠르게 읽는 데는 꽤 실용적이다.

이 명령의 진짜 힘은 앞선 목록과 겹쳐 볼 때 나온다. 많이 바뀐 파일이면서 오류 수정 기록에도 자주 들어간다면, 그곳은 단순히 바쁜 구간이 아니라 위험 중심지일 가능성이 높다. 원문이 가장 큰 위험이라고 짚은 것도 바로 이런 겹침 구간이다.

쉽게 말하면 계속 고장 나고 계속 덧대어 고치는 곳이다. 기능 요청은 처리하지만 뿌리 문제는 그대로 남아 있어서, 시간이 갈수록 작은 수정조차 무거워진다.

물론 이 명령도 한계는 있다.

• 커밋 메시지가 너무 짧은 팀: 어떤 이유로 고쳤는지 기록이 남지 않음
• 이슈 번호만 적는 팀: 오류 수정 흔적을 글자로 잡기 어려움
• 큰 정리 작업 직후: 실제 오류보다 정리 흔적이 더 많이 보일 수 있음

그럼에도 이 목록은 꽤 쓸모 있다. 새 프로젝트를 처음 볼 때 완벽한 결함 통계를 바로 얻는 경우는 드물기 때문이다. 그럴 때 깃 기록은 거칠지만 솔직한 힌트를 준다.

5. 팀 속도가 살아 있는지 본다

• 확인 명령: git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
• 읽는 뜻: 달마다 쌓인 커밋 수 흐름
• 볼 모양: 꾸준한 리듬, 갑작스러운 급감, 큰 파동 뒤 긴 정체
• 실무 해석: 코드 기록이면서 동시에 팀 기록

네 번째 명령은 파일이 아니라 시간을 본다. 저장소 전체 기록에서 월별 커밋 수를 세면, 프로젝트가 어떤 호흡으로 움직였는지가 드러난다. 원문은 여기서 숫자 하나보다 흐름의 모양을 읽으라고 말한다.

매달 비슷한 수준으로 쌓이면 팀이 일정한 속도로 움직이는 편이라고 볼 수 있다. 반대로 한 달 만에 절반 이하로 떨어지면 인력 이탈이나 우선순위 변화 같은 사건이 있었을 가능성이 크다. 6개월에서 12개월 동안 완만하게 내려가면, 팀 전체가 힘을 잃는 중일 수도 있다.

또 어떤 프로젝트는 몇 달 조용하다가 특정 달에만 기록이 몰린다. 이런 모습은 조금씩 자주 배포하기보다, 한 번에 모아서 내보내는 문화와 연결될 수 있다. 그래서 이 그래프는 코드 양보다 사람과 조직의 리듬을 더 잘 보여 주는 경우가 많다.

글쓴이는 실제로 이 흐름표를 보여 주자, 한 최고기술책임자가 "그때 두 번째 시니어 개발자가 떠났다"고 말했다는 사례도 소개한다. 팀 안에서 막연히 느끼던 일이, 시간축 위에 올라가면서 또렷해지는 순간이다.

6. 얼마나 자주 급한 불을 끄는지 본다

• 확인 명령: git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
• 읽는 뜻: 되돌리기, 긴급 수정, 롤백 같은 기록 빈도
• 정상 범위: 1년에 몇 번 정도는 자연스러울 수 있음
• 경고 신호: 몇 주마다 되돌리기가 반복되는 흐름

다섯 번째 명령은 프로젝트의 긴장 상태를 읽는다. 원문은 되돌리기와 긴급 수정 기록이 자주 보이면, 팀이 배포 과정을 충분히 믿지 못하고 있을 가능성이 크다고 본다. 문제가 생길 때마다 빠르게 원상복구하는 문화가 습관처럼 굳었는지를 살펴보는 셈이다.

여기서 중요한 점은 긴급 대응 자체를 탓하는 것이 아니라는 데 있다. 운영 서비스라면 가끔은 되돌리기와 긴급 수정이 꼭 필요하다. 문제는 그 빈도다. 몇 주 간격으로 비슷한 기록이 반복되면, 뒤에는 더 깊은 원인이 숨어 있을 가능성이 크다.

• 시험 자동화 부족: 배포 전에 놓치는 문제가 많음
• 점검 환경 약함: 실제 운영과 비슷한 사전 확인이 부족함
• 배포 절차 복잡함: 실패했을 때 안전하게 물러서기 어려움
• 책임 정리 부족: 급한 수정은 빠른데 근본 원인 정리는 늦음

결과가 0건이어도 안심만 할 일은 아니다. 정말 안정적인 팀일 수도 있지만, 반대로 커밋 메시지를 너무 짧게 써서 단서가 남지 않았을 수도 있기 때문이다. 그래서 이 명령도 다른 목록과 함께 보는 편이 안전하다.

7. 핵심은 읽는 순서를 정하는 데 있다

• 목표: 모든 것을 다 아는 것보다 어디를 먼저 읽을지 정하기
• 가장 좋은 조합: 많이 바뀐 파일 목록 + 오류 집중 목록
• 사람 관점 보강: 핵심 담당자와 최근 활동 흐름 함께 보기
• 운영 관점 보강: 월별 속도와 긴급 대응 흔적 함께 보기

앨리 피에호프스키의 글은 이 다섯 명령이 모든 진실을 알려 준다고 말하지 않는다. 대신 몇 분 안에 읽기 순서를 잡게 도와준다고 본다. 이 차이는 생각보다 크다.

아무 준비 없이 파일을 열면 첫날은 넓게 훑다가 끝나기 쉽다. 반대로 기록을 먼저 보면, 어느 파일부터 읽고 어느 사람에게 물어봐야 할지 방향이 선다. 실제로는 이 순서 차이가 첫 주 업무 밀도를 크게 바꾼다.

원문이 특히 강조하는 묶음은 분명하다.

• 가장 많이 바뀐 파일 상위 몇 개 추리기
• 오류 수정 기록이 많이 몰린 파일과 겹쳐 보기
• 그 파일을 주로 만진 사람이 최근에도 있는지 확인하기
• 최근 몇 달 동안 팀 속도가 흔들렸는지 시간 흐름으로 보기

이렇게 보면 "왜 이 코드가 읽기 어려운가"라는 질문도 훨씬 현실적으로 바뀐다. 단순히 문법이 복잡해서가 아니라, 책임이 끊겼거나, 고장과 수정이 반복됐거나, 배포를 두려워하는 문화가 자리 잡았을 수 있기 때문이다.

8.  이렇게 써먹으면 된다

• 인수인계 직후: 먼저 읽을 파일 순서를 정할 때 유용
• 오래된 시스템 점검: 기술 부채가 쌓인 구간을 짚을 때 유용
• 코드 리뷰 준비: 작성자 의존과 변경 위험도를 빨리 볼 수 있음
• 팀 회고: 사람 문제를 기록 데이터와 연결해 볼 수 있음

국내 개발팀에서도 이 다섯 명령은 현실적이다. 담당자가 자주 바뀌거나, 오래된 서비스가 여러 번 손바뀜을 겪은 조직일수록 현재 코드만 봐서는 배경이 잘 보이지 않는다. 누가 만들었는지, 언제부터 흔들렸는지, 어느 파일이 위험한지부터 보는 편이 훨씬 실무적이다.

초보 개발자에게도 장점이 있다. 처음부터 설계 전체를 이해하려고 하면 부담이 크지만, 가장 자주 바뀐 파일, 오류가 자주 난 파일, 최근 핵심 담당자처럼 질문을 잘게 나누면 프로젝트가 덜 막막해진다. 중고등학생이 학교 발표 자료 기록을 볼 때도 비슷하다. 누가 많이 고쳤는지, 마지막에 급히 손본 부분이 어디인지부터 보면 팀의 흐름이 금방 읽힌다.

다만 이 명령을 만능 잣대로 쓰면 안 된다.

• 기록 문화가 느슨한 팀: 커밋 메시지 품질이 낮아 해석 한계가 큼
• 저장소 구조가 자주 바뀐 팀: 파일 이름 변경 이력이 결과를 흔들 수 있음
• 자동 생성 파일이 많은 저장소: 통계가 왜곡될 수 있음
• 외부 저장소를 자주 가져오는 구조: 실제 작업보다 가져온 기록이 더 많을 수 있음

그래서 가장 좋은 태도는 첫 진단 도구로 쓰는 것이다. 깃 기록으로 위험 구간을 잡고, 그다음 실제 코드와 문서, 팀 대화로 사실을 확인하는 순서가 가장 안정적이다.

결론

2026년 4월 8일 공개된 앨리 피에호프스키의 글은 아주 단순한 질문을 던진다. 새 프로젝트를 받았을 때 정말 먼저 열어야 하는 것은 소스 파일일까, 아니면 그 파일이 걸어온 기록일까. 원문은 후자에 더 무게를 둔다.

핵심은 다섯 개의 깃 명령으로 프로젝트 상태를 빠르게 읽는 데 있다. 어떤 파일이 자주 흔들렸는지, 누가 시스템을 사실상 떠받쳤는지, 오류는 어디에 몰렸는지, 팀 속도는 살아 있는지, 긴급 대응이 반복되는지부터 보면 첫날 읽을 코드가 달라진다.

그래서 이 글의 메시지는 명령어 암기가 아니다. 코드를 읽기 전에 변화를 읽으라는 것이다. 새 프로젝트가 막막하게 느껴질수록, 이 다섯 명령은 좋은 출발점이 될 수 있다.

참고 자료

• The Git Commands I Run Before Reading Any Code - Ally Piechowski, 2026년 4월 8일
• git-log Documentation - Git 공식 문서, 2026년 4월 10일 확인
• git-shortlog Documentation - Git 공식 문서, 2026년 4월 10일 확인
• Use of Relative Code Churn Measures to Predict System Defect Density - Microsoft Research, 2005년