텍스트 비교 (diff) 도구

‘같은 줄 번호끼리 비교’는 왜 실패하는가

두 글을 비교하는 가장 단순한 방법은 첫 줄은 첫 줄끼리, 둘째 줄은 둘째 줄끼리 맞대 보는 것입니다. 이 방법은 글의 앞부분이 그대로일 때만 통합니다. 맨 위에 줄 하나만 새로 추가돼도, 그 아래 모든 줄이 한 칸씩 밀려서 전부 ‘바뀐 줄’로 보입니다.

A            B(맨 위에 한 줄 추가)
─────────────────────────────
사과         포도   ← 다름?
바나나       사과   ← 다름?
딸기         바나나 ← 다름?
             딸기   ← 다름?

사람 눈에는 “포도” 한 줄이 위에 붙었을 뿐, 사과·바나나·딸기는 그대로입니다. 그런데 줄 번호로만 비교하면 네 줄이 전부 다르다고 나옵니다. 실제로 바뀐 건 한 줄인데 결과는 온통 빨강과 초록이 되어, 정작 무엇이 달라졌는지 알아볼 수 없습니다.

LCS — ‘가장 많이 겹치게 짝짓기’

올바른 접근은 순서를 바꾸지 않으면서 양쪽에서 가장 길게 이어지는 공통 부분을 먼저 찾는 것입니다. 이걸 최장 공통 부분수열(Longest Common Subsequence, LCS)이라고 합니다. 위 예에서 LCS 는 “사과 → 바나나 → 딸기”이고, 이 세 줄을 ‘그대로’로 고정한 뒤 나머지만 설명합니다 — B 에만 있는 “포도”는 추가된 줄.

  + 포도      (B 에만 있음 → 추가)
    사과      (공통)
    바나나    (공통)
    딸기      (공통)

빨강·초록이 한 줄로 줄었습니다. 이 도구는 두 글을 이 방식으로 정렬한 뒤, 공통 줄은 회색(그대로), A 에만 있는 줄은 빨강(삭제), B 에만 있는 줄은 초록(추가)으로 표시합니다. Git 을 비롯한 거의 모든 버전 관리 도구가 내부에서 쓰는 것과 같은 원리입니다.

‘이동’은 삭제와 추가로 보인다

LCS 는 순서를 지키는 짝짓기라, 줄의 위치를 서로 맞바꾼 경우는 이동으로 인식하지 못합니다. 두 문단의 순서를 바꾸면, 한쪽에서 삭제되고 다른 위치에서 다시 추가된 것으로 나옵니다. 이건 한계라기보다 정의입니다 — 대부분의 diff 도구가 같은 방식으로 동작하고, 이동을 따로 표시하려면 훨씬 복잡한 알고리즘이 필요합니다.

줄 단위 비교의 경계 — 알고 쓰면 유용하다

이 도구는 줄을 최소 단위로 봅니다. 그래서 한 줄 안에서 글자 하나만 바뀌어도 그 줄은 통째로 ‘삭제된 옛 줄’과 ‘추가된 새 줄’로 나뉩니다. 어느 글자가 바뀌었는지는 두 줄을 나란히 두고 직접 봐야 합니다.

이게 단점처럼 들리지만, 줄이 의미 단위인 텍스트에서는 오히려 정확합니다. 코드는 한 줄이 한 문장이고, 로그는 한 줄이 한 이벤트이며, 목록은 한 줄이 한 항목입니다. 이런 글에서 “줄 3이 바뀌었다”는 정보는 그 자체로 충분합니다. 반대로 긴 산문처럼 한 문단이 한 줄인 글은, 문단을 문장 단위로 줄바꿈해 두고 비교하면 훨씬 세밀하게 볼 수 있습니다.

옵션을 언제 켜는가

• 공백 무시 — 들여쓰기만 바꿨거나, 탭을 스페이스로 치환했거나, 문장 사이 공백 칸 수만 다를 때. 서식 변경을 실제 내용 변경에서 걸러 냅니다.
• 대소문자 무시 — 제목의 대소문자 표기만 통일한 경우처럼, 의미가 같은 변경을 무시하고 싶을 때.

두 옵션 모두 비교할 때만적용되고, 화면에 보여 주는 글자는 언제나 원본입니다. 공백을 무시하고 ‘같다’고 판정한 줄도, 표시는 원래 들여쓰기 그대로 나옵니다.

정리하면

• 줄 번호로 맞대는 비교는 줄 하나만 밀려도 무너집니다. 이 도구는 LCS 로 가장 많이 겹치게 정렬한 뒤 나머지만 추가·삭제로 표시합니다.
• 줄 단위 비교입니다. 한 줄 안의 변경은 줄 전체의 교체로 나옵니다. 줄이 의미 단위인 코드·로그·목록에 가장 잘 맞습니다.
• 서식만 바뀐 경우는 옵션으로 걸러 내세요. 공백·대소문자 무시는 비교에만 적용되고 표시는 원본을 지킵니다.