텍스트 비교 — 무엇이 바뀌었는지, 그리고 왜 안 바뀐 것도 바뀐 걸로 보이는지
두 글을 나란히 놓고 달라진 곳만 짚어 줍니다. 원고 두 판본, 코드 수정 전후, 번역과 원문, 명단 두 개. 눈으로 훑으면 놓치는 한 글자를 찾는 일이라, 정확히 세는 것이 전부입니다.
비교는 두 글에서 가장 길게 겹치는 부분을 찾고, 거기에 끼지 못한 것을 추가와 삭제로 표시하는 일입니다. 최장 공통 부분수열이라고 부르고, 문서 도구가 '변경 내용 추적' 으로 보여 주는 것과 같은 계산입니다.
이 도구는 줄 단위와 글자 단위를 모두 제공합니다. 줄 단위는 코드나 목록처럼 줄이 의미의 단위인 글에 맞고, 글자 단위는 문장 안에서 조사 하나가 바뀐 것을 찾을 때 맞습니다.
맥에서 쓴 글과 윈도우에서 쓴 글은 다르게 저장됩니다
같은 '안녕하세요' 인데 맥에서 온 것은 12개, 윈도우에서 온 것은 5개의 조각으로 저장됩니다. 맥은 한글을 자음과 모음으로 풀어서 저장하는 방식(NFD)을 쓰기 때문입니다. 화면에는 똑같이 보이고, 컴퓨터에게는 완전히 다른 값입니다.
이대로 비교하면 한글이 든 줄이 전부 '바뀜' 으로 표시됩니다. 실제로는 한 글자도 안 바뀌었는데 문서 전체가 빨갛고 파랗게 물듭니다. 이 도구는 양쪽을 NFC 로 모아 붙인 뒤에 비교하므로, 어느 컴퓨터에서 온 파일이든 같은 글은 같은 글로 봅니다.
맥에서 받은 파일과 윈도우에서 만든 파일을 비교할 일이 있다면 이 차이가 가장 먼저 부딪히는 문제입니다.
긴 글에서 브라우저가 멈추지 않는 이유
교과서에 나오는 비교 방법은 두 글의 길이를 곱한 크기의 표를 만듭니다. 1만 줄끼리 비교하면 1억 칸이고, 숫자 하나에 4바이트씩만 잡아도 382MB 입니다. 느려지는 것이 아니라 탭이 멈춥니다. PDF 에서 복사한, 줄바꿈 없는 긴 문단 하나만으로도 같은 일이 벌어집니다.
이 도구는 히르쉬베르크 알고리즘을 씁니다. 표를 통째로 들고 있는 대신 한 줄씩만 들고 문제를 반으로 갈라 들어가서, 같은 답을 훨씬 적은 메모리로 구합니다. 답을 포기하고 대충 비교하는 것이 아니라, 같은 최장 공통 부분수열을 그대로 찾습니다.
실제 측정값
가운데 열은 표 방식이었다면 필요했을 메모리입니다.
| 줄 수 | 표 방식 메모리 | 걸린 시간 |
|---|---|---|
| 1,000줄 | 4MB | 13밀리초 |
| 5,000줄 | 95MB | 182밀리초 |
| 10,000줄 | 382MB | 755밀리초 |
이런 때 씁니다
- •원고를 고쳐 받았는데 어디를 고쳤는지 안 알려 줄 때
- •번역문이 원문의 문단 수와 맞는지 확인할 때
- •명단 두 개를 대조해 빠진 사람을 찾을 때
- •설정 파일을 바꿨는데 무엇을 건드렸는지 기억이 안 날 때
- •복사해 붙이다 슬그머니 들어간 오타를 찾을 때
자주 묻는 질문
줄 단위와 글자 단위 중 무엇을 골라야 하나요?
줄이 의미의 단위이면 줄 단위입니다. 코드, 목록, 표. 줄바꿈이 문단 구분일 뿐인 산문이라면 글자 단위가 낫습니다. 다만 크게 고친 글에 글자 단위를 쓰면 알록달록해서 오히려 안 보입니다.
한 줄만 바꿨는데 여러 줄이 바뀐 걸로 나옵니다.
줄 하나를 둘로 나누거나 합치면 그 앞뒤가 전부 달라 보입니다. 계산이 틀린 것이 아니라, 줄 단위로 보면 실제로 그만큼 달라진 것입니다. 글자 단위로 바꿔 보면 무엇이 옮겨졌는지 보입니다.
공백이나 줄바꿈 차이도 잡히나요?
잡힙니다. 눈에 안 보이는 차이도 차이입니다. 탭과 공백, 문단 끝의 공백, 윈도우식 줄바꿈이 전부 여기 해당합니다. 공백만 정리하고 싶다면 여분 공백 제거 도구가 더 맞습니다.
붙여넣은 글이 저장되나요?
아니요. 비교는 전부 브라우저 안에서 일어납니다.