텍스트 비교 (Diff)

비교 단위를 바꿔 가며 보세요

같은 두 텍스트라도 어느 단위로 비교하느냐에 따라 결과가 전혀 다르게 보입니다.

줄 단위는 코드나 설정 파일처럼 줄이 의미 단위인 문서에 적합합니다. Git이 기본으로 쓰는 방식이기도 합니다.

단어 단위는 문장 안에서 몇 단어만 바뀐 경우에 유용합니다. 줄 단위로 보면 그 줄 전체가 통째로 바뀐 것처럼 보여 실제 변경점을 찾기 어렵습니다. 계약서나 약관 개정본을 비교할 때 특히 그렇습니다.

글자 단위는 가장 세밀합니다. 오탈자 수정이나 띄어쓰기 변경처럼 한두 글자만 달라진 경우를 찾을 때 씁니다. 대신 변경이 많으면 화면이 알록달록해져 오히려 읽기 어렵습니다.

결과 읽는 법

결과는 두 텍스트를 하나로 합친 인라인 형식으로 나옵니다. 빨간 취소선은 원본에만 있던 부분이고, 초록 바탕은 수정본에서 새로 들어온 부분입니다. 색이 없는 부분은 양쪽에 그대로 있는 내용입니다.

"바뀐" 부분은 삭제와 추가가 나란히 붙은 쌍으로 표시됩니다. 예를 들어 "3월 15일"이 "3월 20일"로 바뀌면 단어 단위에서는 15일에 취소선이 가고 바로 뒤에 20일이 초록으로 붙습니다. 결과 위의 +와 − 숫자는 추가되고 삭제된 단위(줄·단어·글자)의 개수입니다. 두 숫자가 모두 0이면 두 텍스트가 완전히 같다는 뜻입니다.

이 도구가 잡아내지 못하는 것

비교는 두 텍스트 사이에서 가장 적은 삭제·추가로 설명되는 경로를 찾는 방식(Myers 알고리즘)으로 이루어집니다. Git이 쓰는 것과 같은 계열입니다. 이 방식에는 알아 두면 좋은 한계가 있습니다.

문단 이동은 삭제 + 추가로 보입니다. 문단을 아래로 옮기기만 해도 원래 자리에서 삭제되고 새 자리에 추가된 것으로 나옵니다. 내용이 바뀐 것이 아니라 순서만 바뀐 것인지는 사람이 판단해야 합니다.

한글 조사는 어절 통째로 바뀝니다. 단어 단위는 공백을 기준으로 나누는데, 한글은 조사가 단어에 붙어 있습니다. "계약서를"이 "계약서는"으로 바뀌면 계약서를 전체가 삭제되고 계약서는 전체가 추가된 것으로 표시됩니다. 조사 하나만 바뀐 것을 정확히 보려면 글자 단위로 바꾸면 됩니다.

문장부호는 따로 셉니다. 단어 단위는 공백뿐 아니라 마침표·쉼표 같은 문장부호도 경계로 봅니다. 문장 끝에 마침표만 붙였다면 마침표 하나만 초록으로 표시되고 앞 단어는 건드리지 않습니다. 반대로 "1,000"처럼 숫자 안의 쉼표도 경계가 되어 1, ,, 000으로 나뉘어 표시될 수 있습니다.

변경이 많으면 짝이 어긋납니다. 절반 이상 다시 쓴 문서는 알고리즘이 엉뚱한 부분끼리 같다고 짝지어 결과가 읽기 어려워집니다. 이럴 때는 문단 단위로 잘라 따로 비교하는 편이 낫습니다.

내용이 같은데 전부 다르다고 나올 때

눈에 보이지 않는 차이가 원인입니다.

줄바꿈 문자

윈도우는 CRLF(\r\n), 맥과 리눅스는 LF(\n)를 씁니다. 같은 내용이라도 이 차이 때문에 모든 줄이 다르게 잡힙니다.

이 도구는 비교 전에 줄바꿈을 통일하므로 이 문제로 인한 오탐은 없습니다. Git에서 같은 문제를 겪는다면 core.autocrlf 설정을 확인해 보세요.

탭과 공백

들여쓰기에 탭을 쓴 줄과 공백 4칸을 쓴 줄은 화면에서 똑같아 보이지만 다른 문자입니다. 에디터에서 공백 표시를 켜면 바로 확인할 수 있습니다.

줄 끝 공백

줄 끝에 붙은 공백은 화면에 보이지 않습니다. 많은 에디터가 저장할 때 자동으로 제거하는데, 그 설정이 다른 사람과 협업하면 diff가 지저분해집니다.

BOM

파일 맨 앞에 붙는 눈에 보이지 않는 바이트입니다. 윈도우 메모장이 UTF-8로 저장할 때 붙이는 경우가 있습니다. 첫 줄만 다르게 나온다면 이것을 의심해 보세요.

유니코드 정규화

한글은 완성형(한)과 조합형(ᄒ+ᅡ+ᆫ)으로 표현될 수 있습니다. macOS가 파일명에 조합형을 쓰기 때문에, 맥에서 만든 파일과 윈도우에서 만든 파일의 한글이 다르게 잡히는 일이 있습니다.

실무에서 쓸 만한 곳

계약서·약관 개정본 비교 — 어디가 바뀌었는지 상대가 알려 주지 않아도 직접 찾을 수 있습니다. 단어 단위로 보는 것을 권합니다.

설정 파일 비교 — 개발 환경과 운영 환경의 설정이 어떻게 다른지 확인할 때. 줄 단위가 적합합니다.

API 응답 비교 — 요청 전후 응답이 어떻게 달라졌는지. JSON 포맷터로 양쪽을 같은 형식으로 정렬한 뒤 비교하면 훨씬 읽기 좋습니다.

번역본 검수 — 원문 수정본과 이전 버전을 비교해 번역이 필요한 부분만 추려낼 때.

비교하기 전에 정리하면 결과가 깨끗해집니다

순서가 의미 없는 목록은 먼저 정렬하세요. 이메일 주소 목록, 설정 항목, 태그 목록처럼 순서가 상관없는 자료는 양쪽을 같은 기준으로 정렬한 뒤 비교해야 실제로 추가·삭제된 항목만 남습니다.

엑셀에서 복사한 표는 탭으로 구분됩니다. 셀 사이가 탭 문자라 화면에서는 간격이 달라 보여도 내용이 같으면 같다고 나옵니다. 열을 하나 지운 표와 원본을 비교하면 모든 줄이 바뀐 것으로 나오는데, 이 경우는 지운 열을 빼고 다시 붙여 넣어야 합니다.

대소문자와 전각·반각. Apple과 apple, 반각 A와 전각 Ａ는 다른 글자입니다. 이 도구는 이런 차이를 그대로 표시합니다. 일부러 구분하지 않고 보고 싶다면 양쪽을 모두 소문자로 바꿔 넣으면 됩니다.

JSON을 비교할 때는 키를 먼저 정렬하세요

두 JSON이 내용은 같은데 키 순서만 다르면 diff가 전부 다른 것으로 표시합니다. JSON 객체에서 키 순서는 의미가 없는데도 그렇습니다.

JSON 포맷터의 "키 정렬" 기능으로 양쪽을 정렬한 뒤 비교하면 실제로 달라진 값만 남습니다.

Git diff와 무엇이 다른가

git diff는 바뀐 줄 앞뒤로 몇 줄의 문맥을 붙여 -와 + 기호로 보여 주는 유니파이드 형식입니다. 코드 리뷰 도구와 패치 파일이 이 형식을 씁니다. 이 도구는 두 텍스트를 한 흐름으로 합쳐 색으로 구분하는 인라인 형식이라, 문장 한가운데의 작은 변화를 보는 데 유리하고 긴 코드의 구조 변화를 보는 데는 불리합니다.

Git이 없는 환경에서 파일 두 개를 급히 비교하거나, 커밋하기 전에 수정한 문장이 정확히 무엇인지 확인하거나, 코드가 아닌 문서를 비교할 때 이 도구가 맞습니다. 저장소에 들어 있는 파일의 이력을 보는 일은 Git에 맡기는 편이 낫습니다.

붙여넣은 내용은 어디로도 가지 않습니다

비교는 전적으로 브라우저 안에서 이루어집니다. 네트워크 요청이 없으므로 계약서 초안, 사내 설정 파일, 미공개 원고처럼 외부로 나가면 곤란한 문서도 안심하고 붙여넣을 수 있습니다.

인터넷 연결을 끊은 상태에서도 동작합니다. 결과를 남겨야 한다면 화면을 캡처하거나, 결과 위의 추가·삭제 개수를 함께 적어 두면 나중에 어느 버전을 비교했는지 확인하기 좋습니다.

함께 확인하면 좋은 것

JSON을 정리한 뒤 비교하려면 JSON 포맷터를, 형식을 바꿔 비교하려면 JSON ↔ YAML ↔ CSV 변환기를 이용하세요.