매일 하는 Diff 습관: 작은 Git 비교로 코드베이스를 제대로 이해하는 방법

모던한 코드베이스는 숨 가쁘게 변합니다. 기능은 매일 배포되고, 브랜치는 생겼다 사라지고, 심지어 일주일 전에 내가 쓴 코드조차 낯설게 느껴질 때가 있습니다. 시스템이 이론상 어떻게 동작해야 하는지가 아니라, 실제로 어떻게 움직이고 있는지를 이해하고 싶다면, 비율 대비 효과가 아주 큰 단 하나의 실천이 있습니다.

매일 작은 diff를 읽는 것.

거대한 PR도 아니고, 릴리스 노트도 아니고, 커밋 메시지만 보는 것도 아닙니다. 실제로 한 줄 한 줄 바뀐 diff 자체를 보는 겁니다.

이 글에서는 git diff를 매일 하는 습관으로 만드는 것이 왜 코드베이스를 이해하고, 문제를 일찍 발견하고, 더 나은 코드를 쓰는 데 있어 레버리지가 가장 큰 실천 중 하나인지 이야기해 보겠습니다.

Diff가 생각보다 훨씬 중요한 이유

본질적으로 diff는 아주 단순한 질문에 답합니다.

정확히 뭐가 바뀌었지?

git diff는 다음을 보여줍니다.

추가된 내용 (보통 초록색)
삭제된 내용 (보통 빨간색)
수정된 내용 (두 가지가 섞여서)

왜 바뀌었는지 전체 맥락을 다 알려주지는 않지만, 실제로 무엇이 바뀌었는지에 대해서는 가장 선명한 시야를 제공합니다. 이해는 대개 거기서부터 시작됩니다.

“이건 이미 알고 있는데?”라고 생각할 수 있습니다. 커밋 전에 git diff를 한 번 돌려보거나, PR을 승인하기 전에 대충 훑어보기도 하겠죠. 하지만 가끔 큰 diff를 대충 훑어보는 것과 매일 의도적으로 작은 diff를 꼼꼼히 들여다보는 것 사이에는 큰 차이가 있습니다.

아주 작고, 매일 하는 Diff의 힘

1. 코드베이스가 어떻게 진화하는지 몸으로 익히게 된다

대부분의 개발자는 시스템이 원래는 어떤 일을 하도록 설계되었는지 대략 알고 있습니다. 하지만 이번 주에 실제로 어떤 상태로 동작하고 있는지 정확하게 머릿속에 그리고 있는 사람은 훨씬 적습니다.

매일 diff를 보는 습관을 들이면:

모듈이 원래 설계에서 어떻게 조금씩 벗어나고 있는지 보이기 시작하고
어떤 파일들이 항상 같이 바뀌는지(결합도 신호)를 관찰하게 되고
시간이 지날수록 복잡도가 어디에 쌓이고 있는지 감이 생깁니다.

몇 주, 몇 달이 지나면 머릿속에 일종의 "코드베이스 타임랩스"가 쌓입니다. 더 이상 코드베이스를 정적인 파일 모음으로 보지 않고, 패턴과 습관, 실패 양상을 가진 살아 있는 시스템으로 보게 됩니다.

이 내부 지도가 진가를 발휘하는 순간은 대개 다음과 같습니다.

운영 장애를 디버깅할 때
새로운 기능을 설계할 때
오래된 코드 영역을 리팩터링할 때

2. 버그와 설계 문제를 훨씬 더 일찍 잡아낸다

대부분의 버그는 도입되는 순간에는 조용합니다. 바로 폭발하지 않습니다. (테스트가 있다면) 여전히 모두 통과합니다. 하지만 버그는 그 시점에 이미 숨어 있습니다.

작고 하나의 맥락을 가진 diff를 꾸준히 리뷰하면 이런 것들을 훨씬 쉽게 찾을 수 있습니다.

조건이 미묘하게 뒤집힌 경우 (>=가 >로 바뀌는 등)
예상치 못한 위치에서 상태 변경(state mutation) 이 추가된 경우
새 파라미터가 함수에 추가되었는데, 전체 호출 경로에 제대로 관통되지 않은 경우
기본값, 타임아웃, 에러 처리 경로 같은 것들이 살짝 조용히 바뀐 경우

diff가 작으면, 뇌가 더 까다롭게 굴 여유가 생깁니다. 그냥 “대충 봤을 때 괜찮은 것 같은데?” 수준에서 끝나지 않고, 이런 질문을 할 수 있습니다.

이 변경은 주변 설계와 일관적인가?
이걸로 숨은 의존성이 생기지 않았나?
의도치 않은 사이드 이펙트가 생기는 건 아닐까?

이걸 diff에서 발견하면 고치는 데 몇 분도 안 걸립니다. 프로덕션에서 발견하면 비용이 급격히 커집니다.

3. 짧고 잦은 리뷰로 인지 부하를 줄인다

큰 diff 리뷰는 진을 뺍니다.

만약 1,000줄짜리 PR이 올라왔을 때만 diff를 본다면, 당신의 뇌는 다음을 한 번에 다 처리해야 합니다.

여러 관심사가 뒤섞인 변경을 파싱하고
큰 규모의 정신적 모델을 한 번에 재구성하고
수십 개의 작은 디테일을 작업 기억에 동시에 붙들어두는 것

결국 사람은 대충 훑어버립니다. 그리고 대충 보면, 놓치는 게 생깁니다.

작은 diff를 매일 리뷰하는 패턴은 이 흐름을 완전히 뒤집습니다.

짧게: 5–15분 집중해서 diff를 읽는 건 꾸준히 하기 좋습니다.
자주: 매일 맥락을 조금씩 업데이트하니, 오늘 리뷰는 어제의 이해를 자연스럽게 이어받습니다.
일관된 맥락: 작은 변경은 보통 하나의 명확한 의도를 가지고 있습니다.

이건 학습의 간격 반복(spaced repetition) 원리와 같습니다. 한 번에 몰아서 벼락치기하는 것보다, 작게 나눠서 반복해서 보는 게 훨씬 효과적입니다.

4. 자연스럽게 커밋이 더 깔끔해진다

diff를 매일 챙겨 보기 시작하면 흥미로운 변화가 하나 생깁니다. 지저분한 diff가 거슬리기 시작합니다.

거대하고 서로 상관없는 변경들이 한 커밋에 뒤섞여 있으면, 그게 설령 내가 쓴 것이라도 읽기가 괴롭습니다. 그 괴로움은 일종의 기능입니다. 우리를 다음과 같은 방향으로 밀어줍니다.

더 작고 집중된 커밋을 만들고
diff의 의도를 설명하는 더 좋은 커밋 메시지를 쓰게 되고
코드 이동과 동작 변경을 명확히 분리하려고 하게 됩니다. (예: 리포맷·이동용 커밋 vs 동작 변경 커밋)

깔끔한 diff는 곧 이해하기 쉬운 프로젝트 히스토리로 이어집니다. 미래의 나(혹은 다른 개발자)가 git log -p를 돌리거나 특정 변경을 살펴볼 때, 이야기가 명료하게 보입니다.

무엇이 바뀌었는가? — diff
왜 바뀌었는가? — 커밋 메시지

읽는 사람 입장에서 diff를 존중하면 할수록, 작성자로서도 diff를 더 잘 다듬게 됩니다.

5. 코드 리뷰가 더 날카롭고 유용해진다

좋은 코드 리뷰 피드백은 다음과 같습니다.

구체적이고
실제 변경 사항에 기반하며
모호하지 않습니다.

diff 중심의 리뷰를 꾸준히 연습하면 피드백이 자연스럽게 개선됩니다.

예전에는 이런 식으로 말했다면:

"여기 조금만 더 단순하게 만들 수 있지 않을까요?"

이제는 이렇게 말하게 됩니다.

"이 새 파라미터 때문에 캐시 키 구성 방식은 바뀌었는데, cache_manager.rb의 제거(eviction) 로직은 아직 이전 키 형태를 쓰고 있어요. 그래서 오래된 엔트리가 계속 남을 수 있을 것 같습니다."

이렇게 되면 당신은:

파일 간 불일치를 더 잘 잡아내고
diff가 드러내는 결합도와 중복을 더 빨리 포착하고
diff에서 악취(smell)가 나면, 테스트가 초록불이어도 설계 자체의 수정을 요청할 자신감이 생깁니다.

또한 diff 중심의 연습은 리뷰 시간 예측 가능성도 높여 줍니다. 맥락이 분명한 50줄짜리 diff를 리뷰하는 건 효율적이지만, 2,000줄짜리 잡탕 diff를 리뷰하는 건 그렇지 않습니다.

매일 Diff 보는 습관 만드는 방법

복잡한 프로세스나 의식이 필요하지 않습니다. 현실적으로 당장 시작할 수 있는 방법을 정리해 보겠습니다.

1. 커밋 전에 항상 내 변경부터 리뷰한다

이건 비타협 원칙으로 두면 좋습니다.

git diff
# 혹은, 먼저 stage 했다면
git diff --cached

이걸 보면서 스스로에게 물어보세요.

내가 리뷰어라면, 어디를 지적하고 싶을까?
나조차 보기에도 의외인 변경이 있는가?
이 커밋은 정말로 한 가지 일만 하고 있는가?

diff가 탁하고 애매하게 느껴진다면, 커밋을 둘이나 셋으로 나누는 걸 고려해 보세요.

2. 메인 브랜치의 최근 변경을 훑어본다

하루에 한 번(혹은 주 몇 회 정도), 이런 식으로 해볼 수 있습니다.

git fetch origin
# 어제 이후 main에서 뭐가 바뀌었는지 보기
git log --oneline --since="1 day ago" origin/main

그중 흥미로워 보이는 커밋 몇 개를 골라서 diff를 살펴봅니다.

git show <commit-hash>

시간이 지나면 이 습관을 통해:

평소에 손대지 않던 코드 경로들을 자연스럽게 접하게 되고
팀 동료들이 문제를 어떻게 풀고 있는지 배우게 되고
코딩 컨벤션과 패턴이 어떻게 변화하고 있는지 보게 됩니다.

3. PR/MR을 작고 집중되게 유지한다

Pull Request나 Merge Request를 올릴 때는 이런 기준을 가져보세요.

PR 하나에는 하나의 일관된 변경만: 기능 추가, 리팩터링, 버그 수정 등
diff를 작게: 너무 크다면, 나눌 수 있는지 먼저 고민해 보기

그리고 다른 사람에게 리뷰를 요청하기 전에, 웹 UI에서 내 PR을 내가 먼저 리뷰해 보세요. 팀원이 보게 될 diff를 그대로 보면서, 남이 지적할 만한 부분을 미리 다듬을 수 있습니다.

4. 단순한 데일리 루틴을 만든다

예를 들어, 이런 식으로 할 수 있습니다.

하루 시작(5–10분):
- 최신 변경 pull 받기
- 메인 브랜치에 대해 git log --since="yesterday"를 가볍게 훑기
- 관심 있는 영역을 건드린 커밋 몇 개를 git show로 보기
점심 전 또는 퇴근 전(5–10분):
- 아직 커밋이나 PR로 정리하지 않은 내 변경 diff를 리뷰
- 커밋 단위, 메시지, 눈에 보이는 문제점 정리

이 정도면 충분합니다. 하루 10–20분이면 되지만, 매일 하는 게 중요합니다.

Diff를 읽기 쉽게 만드는 요령

diff 읽기가 편해야 이 습관을 오래 유지할 수 있습니다.

몇 가지 팁을 소개합니다.

텍스트 위주의 변경에는 단어 단위 diff를 활용하기
```
git diff --word-diff
```
의미 없는 공백 차이는 무시하기
```
git diff -w
```
눈이 편하다면 GUI diff 툴 사용하기 (예: gitk, VS Code의 Git 뷰, 기타 전용 diff 툴)
코드 리뷰 도구에서 문법 하이라이트와 인라인 코멘트 기능 적극 활용하기

시각적으로 diff를 해석하는 데 드는 에너지를 줄일수록, 이해와 비판적 사고에 더 많은 정신력을 쓸 수 있습니다.

장기적인 보상

매일 diff를 보는 습관은 화려하지 않습니다. 당장 도파민을 뿜어내는 것도 아니고, 눈에 띄는 대시보드가 생기는 것도 아닙니다. 아주 조용하고, 어찌 보면 지루할 수도 있는 일입니다.

하지만 몇 달이 지나면 효과가 복리처럼 쌓입니다.

코드베이스에서 길을 잃는 일이 줄어들고
문제가 배포되기 전에 미리 감지하게 되고
더 작고 명료하며 리뷰하기 좋은 변경을 작성하게 되고
피드백은 더 날카로워지고, 팀에서 더 신뢰받게 되고
팀 전체의 프로젝트 히스토리가 더 깨끗하고 이해하기 쉬워집니다.

이 모든 게, 꾸준히 이런 질문을 던지는 데서 시작합니다. "정확히 뭐가 바뀐 거지?" 그리고 그 답을 몇 분만 시간을 들여 제대로 들여다보는 것에서요.

마무리

코드베이스를 깊이 이해하고 싶다면, 기억에만 기대지 말고 진짜 소스 오브 트루스(source of truth) 인 diff를 활용해야 합니다.

git diff를 매일의 습관으로 만들고 — 내 변경을 리뷰하고, 최근 커밋을 훑어보고, 작고 일관된 diff를 고집하는 것만으로도 — 다음을 이룰 수 있습니다.

시스템이 어떻게 진화하는지 몸으로 익히고
버그와 설계 문제를 초기에 잡아내고
리뷰에서 드는 인지 부하를 줄이고
내 커밋과 남에게 주는 피드백의 질을 모두 끌어올리는 것

더 많은 도구나 복잡한 프로세스가 꼭 필요한 건 아닙니다. 필요한 건 단 하나, 단순하지만 반복 가능한 실천입니다.

매일, 작은 diff 몇 개를 보는 것.

이걸 꾸준히 해나가면, 코드베이스를 "안다" 수준을 넘어, 그 히스토리와 실제 동작, 그리고 앞으로 어디서 깨질 가능성이 높은지까지 감각적으로 이해하게 될 것입니다.