거래처에서 "조금만 고쳤어요" 하고 계약서 수정본을 보내 왔는데, 어디를 고쳤는지는 안 알려 줄 때가 있어요. 자소서도 마찬가지예요. 친구가 첨삭해 준 파일과 내 원본을 나란히 띄워 놓고 눈으로 한 줄씩 대조하다 보면, 숫자 하나 바뀐 건 놓치고 엉뚱한 곳에서 시간을 다 씁니다. 결론부터 말하면 텍스트 비교(diff)는 두 글에서 "그대로 남은 부분"을 가장 길게 찾아 맞춰 놓고, 거기에 들어가지 못한 나머지를 삭제·추가로 표시하는 방식이에요. 그래서 비교 단위(줄·단어·글자)를 무엇으로 고르느냐, 그리고 공백·줄바꿈을 미리 맞춰 두느냐에 따라 결과가 크게 달라집니다.
이 글에서는 비교 도구가 실제로 어떤 순서로 차이를 찾는지, 줄 단위와 단어 단위와 글자 단위가 같은 수정본을 어떻게 다르게 보여 주는지, 그리고 내용은 같은데 "다르다"고 나오는 가짜 차이를 어떻게 없애는지 예시로 정리했어요. 직접 해 보려면 텍스트 비교 도구에 두 글을 붙여 넣으면 됩니다.
핵심 요약
diff는 두 글의 공통 부분(최장 공통 부분열, LCS)을 먼저 찾고, 남은 것을 삭제와 추가로 표시해요.
같은 수정본도 줄 단위는 4줄 중 3줄을, 단어 단위는 3개 어절을, 글자 단위는 5글자만 바뀌었다고 보여 줘요.
줄 끝 공백, 연속 공백, 윈도우 줄바꿈(CRLF), 다른 폭의 줄바꿈은 내용이 같아도 차이로 잡히니 먼저 정리하세요.
계약서처럼 숫자·조건이 중요한 문서는 글자 단위로 한 번 더 보고, 워드의 문서 비교로 변경 이력을 남기는 게 안전해요.
텍스트 비교는 "같은 부분"부터 찾는다
사람은 두 글을 볼 때 "어디가 다르지?"부터 찾는데, 비교 프로그램은 반대로 움직여요. 두 글에 공통으로, 같은 순서로 들어 있는 부분을 최대한 길게 찾는 게 먼저예요. 이걸 최장 공통 부분열(LCS, Longest Common Subsequence)이라고 부릅니다. 부분열이라는 말이 어렵게 들리지만, "순서는 지키되 중간을 건너뛰어도 되는 공통 부분"이라고 생각하면 돼요.
아주 짧은 예로 보면 바로 이해가 됩니다. 원본이 "가나다라마"이고 수정본이 "가다라바마"라고 해 볼게요.
- 두 글에 같은 순서로 들어 있는 가장 긴 조각은 "가다라마" 4글자예요.
- 원본에서 이 조각에 못 들어간 "나"는 삭제로 표시됩니다.
- 수정본에서 못 들어간 "바"는 추가로 표시됩니다.
- 결과: 가 [-나-] 다 라 [+바+] 마
이렇게 공통 부분을 기준으로 맞춰 놓으면 나머지는 자동으로 "바뀐 곳"이 돼요. 수정(교체)이라는 별도 동작은 사실 없고, 같은 자리에서 삭제와 추가가 연달아 일어나면 도구가 보기 좋게 "변경"으로 묶어 보여 주는 거예요. 그래서 비교 결과의 빨간색(삭제)과 초록색(추가)이 짝을 이뤄 나란히 나오는 겁니다.
LCS를 구하는 표, 그리고 속도 문제
LCS는 원본 길이 × 수정본 길이 크기의 표를 채워서 구하는 게 교과서적인 방법이에요. 표의 각 칸에 "여기까지 비교했을 때 공통 부분이 몇 개인지"를 적어 나가고, 마지막 칸에서 거꾸로 따라가면 어떤 글자를 지우고 더했는지가 나옵니다. 문제는 표의 크기예요. 비교 단위가 작을수록 개수가 늘고, 칸 수는 그 제곱으로 늘어나거든요.
그래서 실제 프로그램들은 표를 통째로 채우지 않아요. git이 기본으로 쓰는 마이어스(Myers) 알고리즘은 "차이가 적을수록 빨리 끝나는" 방식이라, 거의 같은 두 문서는 순식간에 비교합니다. 웹 비교 도구 대부분은 여기에 한 가지 요령을 더해요. 먼저 줄 단위로 맞춰서 바뀐 줄을 찾고, 그 바뀐 줄 안에서만 단어나 글자 단위로 다시 비교하는 거죠. 화면에서 바뀐 줄 전체는 연한 색, 그 안의 바뀐 글자는 진한 색으로 표시되는 게 바로 이 2단계 비교 때문이에요.
줄 단위·단어 단위·글자 단위 비교 차이
비교 단위를 무엇으로 고르느냐가 결과를 가장 크게 바꿔요. 자소서 한 문단을 첨삭받았다고 해 볼게요.
[원본]
저는 대학 시절 교내 봉사 동아리에서 3년간 활동했습니다.
매주 토요일 지역 아동센터에서 수학을 가르쳤습니다.
이 경험을 통해 상대의 눈높이에서 설명하는 법을 배웠습니다.
귀사에 입사한다면 고객의 입장에서 생각하는 직원이 되겠습니다.
[수정본]
저는 대학 시절 교내 봉사 동아리에서 4년간 활동했습니다.
매주 토요일 지역 아동센터에서 수학을 가르쳤습니다.
이 경험을 통해 상대의 눈높이에서 설명하는 방법을 배웠습니다.
귀사에 입사한다면 고객의 입장에서 먼저 생각하는 직원이 되겠습니다.
실제로 바뀐 건 세 군데예요. 3년간이 4년간으로, 법을이 방법을로 바뀌었고, "먼저"라는 단어가 하나 들어갔어요. 이걸 세 가지 단위로 비교하면 이렇게 나옵니다.
| 비교 단위 | 바뀌었다고 표시되는 것 | 수정본에서 강조되는 글자 |
|---|---|---|
| 줄 단위 | 4줄 중 1·3·4번째 줄 전체 | 103자 (공백 포함) |
| 단어(어절) 단위 | 4년간, 방법을, 먼저 | 8자 |
| 글자 단위 | 4, 방, "먼저 " | 5자 (공백 포함) |
언제 어떤 단위를 써야 할까
- 줄 단위: 코드, 설정 파일, 엑셀에서 복사한 목록처럼 한 줄이 한 덩어리인 글에 맞아요. 어느 항목이 추가·삭제됐는지 한눈에 보입니다. 반대로 긴 문단으로 된 글에서는 쉼표 하나만 바뀌어도 문단 전체가 빨갛게 칠해져서 쓸모가 떨어져요.
- 단어(어절) 단위: 자소서, 기사, 보고서처럼 문장으로 된 글에 가장 무난해요. 한국어는 띄어쓰기 단위인 어절로 쪼개기 때문에 "법을 → 방법을"처럼 조사가 붙은 덩어리 전체가 바뀐 것으로 나와요. 어떤 말을 고쳤는지 읽기 쉬운 대신, 정확히 어느 글자가 바뀌었는지는 한 번 더 봐야 합니다.
- 글자 단위: 계약서 금액, 날짜, 계좌번호, 조항 번호처럼 한 글자가 결과를 바꾸는 곳에 꼭 필요해요. "30일"이 "3일"로, "1,000,000원"이 "10,000,000원"으로 바뀐 건 단어 단위로 보면 그냥 "바뀐 어절"이지만 글자 단위로 보면 빠진 0이 정확히 보여요. 대신 문장을 많이 고친 글에서는 조각조각 색칠돼서 오히려 읽기 어렵습니다.
제가 계약서를 볼 때 쓰는 순서는 "단어 단위로 전체를 훑어 어디를 고쳤는지 파악 → 숫자·날짜·금액이 들어간 줄만 글자 단위로 다시 확인"이에요. 이렇게 하면 문장 수정은 읽기 좋게, 숫자 수정은 놓치지 않게 볼 수 있어요.
내용은 같은데 다르다고 나오는 가짜 차이
비교 도구를 처음 쓰면 가장 당황스러운 게 이거예요. 분명 한 글자도 안 바꿨는데 줄마다 빨간색이 뜹니다. 대부분 눈에 안 보이는 문자 때문이에요. 위 자소서 수정본에서 내용은 그대로 두고 줄 끝에 공백 하나와 윈도우식 줄바꿈(CRLF)을 넣고, 둘째 줄의 띄어쓰기를 두 칸으로 바꾼 뒤 비교하면 4줄 중 3줄이 바뀌었다고 나와요. 공백을 정리하고 다시 비교하면 차이는 0개가 됩니다.
| 가짜 차이의 원인 | 어디서 생기나 | 해결 |
|---|---|---|
| 줄 끝 공백 | 워드·한글에서 복사, 편집기 자동 들여쓰기 | 줄 앞뒤 공백 제거 |
| 연속 공백·탭 | 정렬하려고 스페이스 여러 번, 표 복사 | 연속 공백을 1칸으로 |
| CRLF vs LF | 윈도우 파일과 맥·웹 텍스트 비교 | 줄바꿈 종류 통일 |
| 다른 위치의 줄바꿈 | PDF 복사, 창 폭이 다른 편집기 | 줄바꿈을 공백으로 바꾼 뒤 비교 |
| NBSP·전각 공백 | 웹페이지, 한글(HWP) 문서 | 일반 공백으로 바꾸기 |
| 한글 자모 분리(NFD) | 맥 파일명, 일부 맥 앱에서 복사 | 정규화(NFC) 후 비교 |
| 둥근 따옴표·대시 | 워드 자동 고침 | 따옴표 종류 통일 |
줄바꿈 위치가 다르면 줄 단위 비교가 무너진다
특히 조심해야 하는 게 PDF에서 복사한 글이에요. 원본 PDF와 수정본 PDF는 글자 하나만 달라져도 그 뒤로 줄이 끝나는 위치가 한 칸씩 밀려요. 그러면 문단 전체의 줄바꿈 위치가 달라져서, 줄 단위로 비교하면 문단 통째로 바뀐 것처럼 나옵니다. 이럴 땐 비교하기 전에 줄바꿈 제거기로 "공백으로 바꾸기 + 문단 유지"를 해서 문단 하나를 한 줄로 만든 다음 단어 단위로 비교하면 실제 수정만 남아요. PDF 복사 텍스트가 왜 그렇게 되는지는 PDF·카톡 복사 텍스트 줄바꿈 공백 정리법에 자세히 정리해 두었어요.
공백 문제는 공백 제거기에서 "연속 공백 1칸 + 줄 앞뒤 공백 제거"를 켜고, NBSP·전각 공백 옵션까지 켠 뒤 두 글에 똑같이 적용하면 됩니다. 중요한 건 두 글 모두 같은 규칙으로 정리해야 한다는 점이에요. 한쪽만 정리하면 이번엔 정리한 쪽이 다 바뀐 것으로 나와요.
맥에서 온 한글이 다르다고 나올 때
화면에서 완전히 같은 "계약서"라는 단어가 비교에서 다르게 나오는 경우가 있어요. 한글은 "계"를 한 글자로 저장하는 방식(NFC)과 ㄱ+ㅖ 자모로 나눠 저장하는 방식(NFD)이 있는데, 맥의 파일명이나 일부 앱에서 복사한 글은 NFD로 오기도 하거든요. 눈에는 똑같지만 글자 수부터 달라서, 글자 수 세기에 넣어 보면 같은 단어인데 글자 수가 2~3배로 나오는 걸로 알아챌 수 있어요. 이 경우 비교 도구의 "유니코드 정규화" 옵션을 켜거나, 메모장 같은 일반 텍스트 편집기에 한 번 붙여 넣었다 복사하면 대개 해결됩니다.
계약서 수정본 비교, 이렇게 하면 놓치지 않는다
계약서는 몇 글자 차이가 돈과 책임을 바꾸는 문서라, 순서를 정해 두고 보는 게 좋아요.
- 두 파일을 모두 텍스트로 꺼낸다. 워드·한글 파일이면 전체 선택 후 복사, PDF면 복사 후 줄바꿈 정리까지 해요.
- 공백과 줄바꿈을 같은 규칙으로 정리한다. 연속 공백 1칸, 줄 앞뒤 공백 제거, 문단당 한 줄로 맞춥니다.
- 단어 단위로 전체 비교한다. 어느 조항을 고쳤는지 목록을 만들어요.
- 숫자가 있는 조항은 글자 단위로 다시 본다. 금액, 기간, 날짜, 지연 이자율, 위약금 비율, 조항 번호를 한 글자씩 확인합니다.
- 삭제된 부분을 따로 읽는다. 추가된 문장은 눈에 잘 띄지만, 빠진 단서 조항("다만, ~한 경우는 제외한다")은 놓치기 쉬워요.
5번이 정말 중요해요. 사람은 새로 생긴 문장에 눈이 가는데, 계약서에서 위험한 건 오히려 조용히 사라진 문장인 경우가 많거든요. 비교 결과에서 삭제(빨간색)만 모아서 한 번 따로 읽어 보세요.
조항 순서를 바꾼 문서는 비교가 이상해진다
LCS는 "순서를 지키는" 공통 부분을 찾기 때문에, 상대가 제5조와 제7조의 위치를 바꾸면 한쪽은 통째로 삭제, 다른 쪽은 통째로 추가로 나와요. 내용이 그대로인데도 말이죠. 이럴 때는 삭제된 덩어리와 추가된 덩어리를 따로 복사해서 둘끼리 다시 비교하면, 위치만 옮긴 건지 옮기면서 내용도 고친 건지 확인할 수 있어요. 조항 번호가 전부 하나씩 밀린 경우(제3조가 생기면서 원래 제3조가 제4조가 된 경우)도 비슷하게 번호 줄마다 차이가 생기니 놀라지 마세요.
워드·한글의 변경 내용 추적과 문서 비교
웹 비교 도구와 별개로, 워드와 한글에는 이미 비슷한 기능이 들어 있어요. 다만 두 기능의 성격이 다릅니다.
| 기능 | 하는 일 | 장점 | 한계 |
|---|---|---|---|
| 변경 내용 추적 (워드·한글) | 고치는 순간부터 수정 이력을 기록 | 누가 언제 고쳤는지까지 남음 | 상대가 켜고 고쳐야만 의미가 있음 |
| 문서 비교 (워드·한글) | 이미 따로 저장된 두 파일을 비교 | 서식·표까지 비교, 결과를 추적 문서로 저장 | 같은 프로그램 파일끼리만, 버전마다 메뉴가 다름 |
| 웹 텍스트 비교 | 붙여 넣은 두 글을 비교 | 어떤 출처든 텍스트면 가능, 단위 선택 가능 | 서식(굵게, 표 구조)은 비교 안 함 |
| git diff | 버전 관리 중인 파일의 차이 | 이력 전체 추적, 공백 무시 옵션 | 개발 도구라 문서 작업엔 낯섦 |
워드에서는 검토 탭의 "비교" 메뉴로 원본과 수정본을 고르면 차이가 변경 내용 추적 형태로 표시된 새 문서가 만들어져요. 한글(HWP)에도 검토 메뉴 쪽에 문서 비교와 변경 내용 추적 기능이 있는데, 버전에 따라 메뉴 이름과 위치가 조금씩 달라요.
변경 내용 추적만 믿으면 안 되는 이유
상대가 변경 내용 추적을 켜고 고쳐서 보냈더라도, 추적을 잠깐 끄고 고친 부분이나 이미 "적용"해 버린 수정은 표시되지 않아요. 악의가 없어도 실수로 이런 일이 생깁니다. 그래서 중요한 문서라면 추적 표시를 보는 것과 별개로, 내가 마지막으로 보낸 파일과 받은 파일을 직접 비교하는 게 안전해요. 이력은 상대가 남기는 것이고, 비교는 내가 확인하는 것이니까요.
서식까지 확인해야 하는 문서(표 안 숫자, 각주, 머리글)는 워드나 한글의 문서 비교가 낫고, 출처가 다른 두 글(메일 본문과 PDF, 카톡으로 받은 문장과 내 원고)을 빠르게 보는 건 웹 비교 도구가 편해요. 개발자라면 텍스트 파일로 관리하면서 git diff --word-diff 로 단어 단위 차이를, git diff -w 로 공백을 무시한 차이를 볼 수 있어요.
자소서·과제 수정본 비교할 때 팁
자소서는 계약서와 달리 문장을 크게 다듬는 경우가 많아서, 비교 결과가 너무 알록달록해지기 쉬워요. 몇 가지 요령이 있어요.
- 문항별로 나눠 비교한다. 문항 1~4를 한꺼번에 넣으면 문항 하나에서 생긴 큰 수정 때문에 다른 문항의 작은 수정이 묻혀요.
- 첨삭 전후 글자 수를 같이 본다. 첨삭을 받으면 글이 늘어나기 쉬워서, 비교한 뒤 바로 글자 수 제한을 다시 확인하세요. 사이트마다 공백·줄바꿈을 세는 기준이 다르니 자소서 글자 수와 NEIS 바이트 기준도 함께 보면 좋아요.
- 두 번 이상 고친 경우 최신 두 개만 비교한다. 1차와 3차를 비교하면 2차에서 고쳤다가 3차에서 되돌린 부분은 아예 안 보여요. 어느 쪽이 맞는지 기억해야 한다면 1→2, 2→3을 따로 비교하세요.
- 글자 단위는 마지막 맞춤법 확인용으로. 문장을 다듬는 단계에서는 단어 단위, 오탈자와 띄어쓰기만 확인하는 마지막 단계에서는 글자 단위가 잘 맞아요.
자주 묻는 질문
두 문서에서 바뀐 부분만 빠르게 찾으려면 어떻게 하나요?
두 글을 텍스트로 복사해서 비교 도구에 붙여 넣는 게 가장 빨라요. 문장으로 된 글은 단어 단위, 숫자가 중요한 곳은 글자 단위로 보세요. 결과가 너무 많이 다르게 나오면 공백과 줄바꿈부터 같은 규칙으로 정리하고 다시 비교하면 됩니다.
아무것도 안 바꿨는데 줄마다 다르다고 나와요.
대부분 줄 끝 공백, 윈도우 줄바꿈(CRLF), 연속 공백, NBSP 같은 보이지 않는 문자 때문이에요. 두 글 모두에 줄 앞뒤 공백 제거와 연속 공백 1칸 정리를 똑같이 적용하거나, 비교 도구의 "공백 무시" 옵션을 켜 보세요. 맥에서 온 한글이라면 자모 분리(NFD) 문제일 수도 있어요.
줄 단위와 단어 단위 중 무엇이 더 정확한가요?
정확도는 같고 보여 주는 크기가 달라요. 줄 단위는 코드나 목록처럼 한 줄이 한 항목인 글에, 단어 단위는 문장으로 된 글에 맞아요. 금액·날짜처럼 한 글자가 중요한 곳은 글자 단위로 보는 게 가장 확실합니다.
워드 변경 내용 추적이 있으면 따로 비교할 필요가 없나요?
추적을 끄고 고친 부분이나 이미 적용된 수정은 표시되지 않아서, 중요한 문서라면 내가 보낸 파일과 받은 파일을 직접 비교해 보는 게 안전해요. 워드의 검토 탭 "비교" 기능이나 웹 비교 도구를 쓰면 됩니다.
문단 순서를 바꾼 것도 찾아 주나요?
일반적인 diff는 순서를 지키는 공통 부분을 찾기 때문에, 문단을 옮기면 한쪽은 삭제, 다른 쪽은 추가로 나와요. 삭제된 덩어리와 추가된 덩어리를 따로 복사해 서로 비교하면 위치만 옮긴 건지, 내용까지 고친 건지 확인할 수 있어요.
정리
텍스트 비교는 두 글의 공통 부분을 가장 길게 맞춰 놓고 나머지를 삭제와 추가로 보여 주는 방식이에요. 같은 수정이라도 줄 단위로는 문단 전체가, 단어 단위로는 어절 몇 개가, 글자 단위로는 몇 글자만 바뀐 것으로 보이니 글의 종류에 맞춰 단위를 고르면 됩니다. 결과가 이상하게 많이 다르면 내용보다 공백·줄바꿈을 먼저 의심하세요. 그리고 계약서라면 추가된 문장보다 사라진 문장을 한 번 더 읽는 게 핵심이에요.
두 글은 텍스트 비교에서 바로 비교할 수 있고, 비교 전 정리는 공백 제거기와 줄바꿈 제거기로 하면 가짜 차이가 사라져요. 복사한 글이 왜 지저분해지는지 궁금하다면 복사 텍스트 줄바꿈·공백 정리법도 함께 읽어 보세요.