git diff는 어떻게 화면에 그려질까? 코드 리뷰 도구의 숨은 고민

매일 보는 diff, 그런데 어떻게 만들어지는 걸까

개발자라면 하루에도 몇 번씩 보는 화면이 있죠. 빨간색은 지운 줄, 초록색은 추가한 줄. 코드 리뷰할 때, PR 볼 때 늘 마주치는 그 diff(차이 비교) 화면이에요. 너무 당연하게 써서 그렇지, 사실 "두 버전의 코드 차이를 보기 좋게 그려내는 일"은 생각보다 까다로운 엔지니어링이거든요. 이번 글은 코드 리뷰 도구를 만드는 입장에서 "diff를 어떻게 렌더링할 것인가"를 깊이 파고든 이야기예요.

1단계: 무엇이 바뀌었는지 '계산'하기

먼저 두 텍스트의 차이를 알아내야 해요. 여기서 고전 알고리즘이 등장하는데, 바로 Myers diff 알고리즘이에요. 이게 뭐냐면, 두 파일을 비교해서 "가장 적게 추가/삭제해서 A를 B로 만드는 방법"을 찾아주는 알고리즘이에요. 우리가 보는 대부분의 git diff가 이걸 기반으로 돌아가요.

그런데 문제가 있어요. Myers는 기본적으로 "줄 단위" 로 비교하거든요. 예를 들어 한 줄에서 변수 이름 하나만 바꿨는데도, diff는 "그 줄 전체를 지우고 → 새 줄을 추가했다"고 표시해요. 사람 눈엔 답답하죠. 어디가 진짜 바뀐 건지 한눈에 안 들어오니까요.

그래서 좋은 도구는 "단어 단위(word-level)" 또는 "문자 단위" diff를 한 번 더 돌려요. 바뀐 줄 안에서 또 한 번 비교해서, "이 줄에서 실제로 달라진 건 이 단어다"라고 하이라이트해주는 거죠. 우리가 종종 보는 "줄 안의 특정 부분만 빨강/초록으로 강조된" 화면이 바로 이거예요.

2단계: 보기 좋게 '그리기'

차이를 계산했으면 이제 화면에 그려야 하는데, 여기서 또 고민이 쏟아져요.

첫째는 문법 강조(syntax highlighting)와의 충돌이에요. 코드는 보통 색깔로 키워드, 문자열, 주석을 구분하잖아요? 그런데 diff도 빨강/초록으로 색을 쓰니, 둘이 겹치면 화면이 엉망이 돼요. 이 둘을 자연스럽게 합치는 게 의외로 어려운 부분이에요.

둘째는 레이아웃 이에요. 한 화면에 위아래로 보여주는 통합(unified) 뷰가 좋을까, 아니면 좌우로 나란히 놓는 분할(side-by-side) 뷰가 좋을까? 긴 줄이 화면을 넘어가면 줄바꿈(wrap)을 할까 가로 스크롤을 둘까? 이런 결정 하나하나가 리뷰 경험을 좌우해요.

셋째는 성능 이에요. 수천 줄짜리 파일, 혹은 자동 생성된 거대한 파일의 diff를 그릴 때 브라우저가 버벅이지 않게 하는 것도 큰 숙제예요.

업계에서는 어떻게 풀고 있나

비교해보면 재밌어요. GitHub과 GitLab의 diff는 우리에게 가장 익숙한 "줄 단위 + 단어 강조" 방식이고요. 터미널에서 쓰는 delta 같은 도구는 여기에 예쁜 문법 강조와 줄 번호를 더해 보기 좋게 만들어줘요.

그리고 한 발 더 나간 게 difftastic 이에요. 이건 아예 접근이 달라요. 텍스트를 줄 단위로 비교하는 게 아니라, 코드를 구문 트리(AST, 코드의 문법 구조를 나무 모양으로 표현한 것) 로 파싱한 다음 "구조적으로" 비교하거든요. 그래서 들여쓰기만 바뀌거나 코드 블록을 통째로 옮긴 경우에, "실제로 의미가 바뀐 건 없다"는 걸 훨씬 똑똑하게 잡아내요. 이번 글이 다루는 "diff를 더 잘 보여주려는 노력"의 연장선에 있는 흐름이죠.

한국 개발자에게 주는 시사점

두 가지로 와닿아요. 첫째, 코드 리뷰 도구를 직접 만들거나 커스터마이징할 일이 있다면, diff는 단순히 "두 문자열 비교"가 아니라 계산·강조·렌더링·성능이 얽힌 복합 문제라는 걸 알고 들어가야 해요. 막연히 라이브러리 하나 붙이면 끝일 것 같지만, 사용자 경험은 이 디테일에서 갈리거든요.

둘째, 당장 실무에서 difftastic이나 delta를 git에 연결해서 써보는 것만으로도 리뷰 효율이 확 올라가요. git config로 외부 diff 도구를 지정하면 되니 진입 장벽도 낮고요. 변수명 한 줄 바뀐 걸 찾느라 눈 빠지게 보던 시간이 줄어들어요.