텍스트 비교 (Diff)

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

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

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

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

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

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

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

줄바꿈 문자

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

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

탭과 공백

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

줄 끝 공백

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

BOM

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

유니코드 정규화

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

실무에서 쓸 만한 곳

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

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

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

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

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

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

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

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

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

인터넷 연결을 끊은 상태에서도 동작합니다.

함께 확인하면 좋은 것

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