계약서의 수정 표시 찾기
공급 계약서 V1을 왼쪽에, 수정 표시가 된 V2를 오른쪽에 붙여 넣으세요. 면책, 결제, 해지 조항 중 조용히 바뀐 부분이 곧바로 드러납니다. 상대방이 변경 내용 추적을 끈 채로 깨끗한 사본을 보냈을 때 유용합니다.
입력
출력
텍스트 비교란?
텍스트 비교는 두 텍스트를 받아 둘 사이에서 무엇이 바뀌었는지 정확하게 보여주는 온라인 도구입니다. 한쪽에 이전 버전을, 반대쪽에 새 버전을 붙여넣으면 차이가 색깔로 표시됩니다. 초록은 추가, 빨강은 삭제입니다.
일반 텍스트라면 무엇이든 사용할 수 있습니다. 문단, 코드 조각, 설정 파일, 계약 조항, 번역 등. 일치하는 줄은 그대로 두기 때문에 눈이 바뀐 부분으로 바로 향합니다.
데스크톱 도구를 열기 싫지만 한 번의 클릭으로 정확한 결과가 필요할 때 쓰세요. 가입, 업로드, 비교 기록 모두 없습니다.
하는 일
Compare Text는 두 개의 텍스트를 받아 추가된 부분을 초록색, 삭제된 부분을 빨간색으로 하이라이트합니다. 문자 단위로 처리하므로 빠진 쉼표 하나나 이름이 바뀐 변수도 분명히 드러납니다. 엔진은 Google의 diff-match-patch 라이브러리(Apache 2.0)입니다. 이 일반적인 기법을 diff라고 부르며, 그 바탕에 있는 문제(두 문자열 사이의 최소 편집 집합 찾기)는 고전적인 최장 공통 부분 수열 문제로 환원됩니다.
엔진은 자연어와 코드를 모두 잘 다룹니다. 문서 편집기의 변경 기록을 지탱하는 것과 같은 종류의 접근 방식입니다. 산문이 아니라 구조화된 데이터를 비교한다면, 우리의 JSON diff 도구를 사용하세요. 양쪽을 먼저 파싱하고 키 순서를 무시합니다. 다른 문제에는 다른 도구가 필요합니다.
서버는 사용하지 않습니다. JavaScript가 FileReader API로 텍스트를 읽고, 비교하고, 결과를 페이지에 그립니다. 탭을 닫으면 사라집니다.
두 텍스트 비교 방법
세 단계입니다. 입력하는 동안 diff가 자동으로 갱신되므로 비교 버튼은 없습니다.
- 1
원본 입력
왼쪽 패널에 붙여넣거나 업로드로 .txt 또는 .md 파일을 엽니다. 예시를 누르면 짧은 샘플이 입력됩니다.
- 2
수정본 입력
오른쪽에 붙여넣거나 업로드합니다. 두 패널에 모두 내용이 들어오면, 왼쪽의 삭제는 빨간색, 오른쪽의 추가는 초록색으로 표시됩니다.
- 3
변경 확인
한쪽을 스크롤하면 양쪽이 동기화됩니다. 헤더에 감지된 변경 개수가 나옵니다. 복사나 다운로드로 어느 쪽 텍스트든 저장할 수 있습니다.
이럴 때 유용해요
초안과 교정본 검토
초안과 편집자의 수정본을 비교하거나, 블로그 글을 교정 전후로 비교해 보세요. 바뀐 단어가 모두 표시되므로 빠진 문장을 찾으려고 글 전체를 다시 읽을 필요가 없습니다.
번역 검수 라운드 검토
한쪽에 원문, 다른 쪽에 번역가의 수정 사항. 어떤 관용 표현이 다시 쓰였는지, 검수자가 어디서 직역을 바로잡았는지 확인할 수 있습니다. 검수자를 신뢰한다면 문서 전체를 두 번 읽지 않아도 됩니다.
설정 파일 비교
nginx.conf, systemd 유닛 파일, .env 템플릿. 두 버전을 나란히 두고 몇 초 만에 확인. 두 파일이 이미 채팅에서 클립보드에 들어와 있다면, 터미널에서 diff를 띄우는 것보다 빠릅니다.
로그 파일 스냅샷 비교
어제 배포 로그와 오늘 로그, 또는 같은 작업의 두 CI 실행 출력. 동일한 줄은 배경으로 가라앉고 새로운 오류 패턴이 두드러집니다. 수 메가바이트 로그라면 먼저 grep으로 관련 부분만 좁혀 두세요.
텍스트 diff 빠른 참조
이 도구가 가장 자주 드러내는 경계 사례와 그 이유.
| 주제 | 이 도구가 하는 일 |
|---|---|
| 줄바꿈 문자 | LF, CRLF, CR은 서로 다른 문자입니다. Windows 파일(CRLF)을 Unix 파일(LF)과 비교하면 모든 줄이 다르게 보입니다. 양쪽 소스를 LF로 통일하거나 비교 전에 캐리지 리턴을 제거하세요. |
| 줄 끝 공백 | 실제 차이로 표시되어, 보이는 문자 너머까지 하이라이트가 이어집니다. YAML이나 CSV에서 파서를 조용히 깨뜨리는 후행 공백을 잡는 데 유용합니다. |
| 유니코드 정규화 | 미리 합성된 é(U+00E9)가 들어간 café는 한 글자지만, 분해형 e + 결합 악센트(U+0301)는 두 글자입니다. 화면에는 똑같이 보여도 diff에서는 다르게 처리됩니다. Unicode 정규화 형식 C를 String.prototype.normalize()로 적용하면 일치하게 만들 수 있습니다. |
| 매칭 단위 | 내부적으로는 문자 단위이며, 가능한 경우 단어 경계에서 변경을 묶는 의미적 정리 단계가 들어갑니다. 그래서 서로 무관한 텍스트에서도 짧은 공통 단어가 맞춰진 것처럼 보일 때가 있습니다. |
| 파일 인코딩 | 업로드된 파일은 FileReader API를 통해 UTF-8로 읽힙니다. 다른 인코딩은 깨져 보입니다. 미리 변환하거나, 이미 파일을 디코딩한 도구에서 붙여 넣으세요. |
| 큰 입력 | 수백 KB까지는 1초 미만입니다. 1~2MB는 눈에 띄게 느려집니다. 5MB를 넘으면 병목은 diff 알고리즘이 아니라 렌더링입니다. 붙여 넣기 전에 좁혀 두세요. |
| 한쪽이 비었을 때 | 한쪽 창이 비어 있으면 다른 쪽이 통째로 추가(또는 삭제)로 표시됩니다. 이는 diff가 올바르게 동작한 결과이지 버그가 아닙니다. |
| 동일한 입력 | 양쪽이 정확히 일치하면(공백, 줄바꿈, 유니코드 형식 포함) 변경이 0이고 헤더에는 개수가 표시되지 않습니다. |
자주 묻는 질문
입력한 텍스트가 저장되나요?
아니요. 비교는 모두 브라우저 안에서 이루어집니다. 서버로 전송하거나 기록하거나 저장하지 않습니다. DevTools를 열고 Network 탭을 보면 비교할 때 외부로 나가는 요청이 없습니다. 탭을 닫으면 텍스트는 사라집니다.
이 도구와 JSON diff의 차이는 무엇인가요?
텍스트 diff는 문자를 순서대로 비교하기 때문에 JSON에서 키 순서를 바꾸거나 공백을 다시 정렬하면 데이터가 동일해도 차이로 표시됩니다. JSON을 구체적으로 비교하려면 Compare JSON 도구를 사용하세요. 양쪽을 먼저 파싱하고 순서를 인식합니다. 산문, 설정 파일, 일반 코드 등 구조화되지 않은 데이터에는 텍스트 diff가 적합합니다.
Windows와 Unix의 줄바꿈(CRLF vs LF)을 처리하나요?
있는 그대로 비교하므로 Windows 파일(CRLF)을 Unix 파일(LF)과 붙여 넣으면 내용이 같아도 모든 줄이 다른 것처럼 보입니다. 이는 diff가 올바르게 동작한 결과로, 입력이 실제로 다릅니다. 해결하려면 양쪽 소스의 줄바꿈을 통일하거나, 붙여 넣기 전에 캐리지 리턴을 제거하세요.
크기 제한이 있나요?
실질적인 한계는 기기의 메모리입니다. 수백 KB까지의 텍스트는 1초 안에 비교됩니다. 1MB를 넘어가면 브라우저가 무거워지기 시작하는데, 주로 하이라이트를 그리는 비용 때문입니다. 거대한 로그 파일이나 단행본 분량의 원고는 먼저 관심 있는 부분으로 좁혀 주세요.
diff가 가끔 토막난 것처럼 보이는 이유는?
문자 단위 diff는 짧은 공통 부분 문자열(관사, 단일 글자, 문장 부호)을 가능한 곳마다 정렬합니다. 의미적 정리 단계에서 가능한 한 단어 단위 덩어리로 묶지만, 서로 무관한 두 문단은 여전히 토막난 결과를 만듭니다. 알고리즘은 두 텍스트가 애초에 비교 대상이 아닐 수 있다는 사실을 알 방법이 없습니다.
서로 다른 인코딩의 파일을 비교할 수 있나요?
업로드 버튼으로 올린 파일은 UTF-8로 읽힙니다(FileReader 기본값). Latin-1, Shift-JIS, Windows-1252 같은 다른 인코딩 파일은 깨져 보이므로 먼저 UTF-8로 변환하세요. 클립보드에 이미 있는 텍스트라면 OS가 붙여 넣기 전에 인코딩을 처리해 두기 때문에 대체로 문제없이 작동합니다.