텍스트 비교 도구
1. "뭘 바꿨는지 눈으로 찾다가 하루가 갑니다"
코드 리뷰 도중 동료가 "이번 PR에서 로직 약간 수정했어요"라고 말하면, 200줄짜리 파일에서 정확히 어디가 달라졌는지 찾아야 합니다. Git diff가 있으면 편하지만, 실무에서는 Git으로 관리되지 않는 텍스트를 비교해야 하는 상황이 훨씬 많습니다. 클라이언트가 보내준 수정 계약서, 기획자가 업데이트한 기획서, 디자이너가 변경한 카피라이팅 — 이런 텍스트의 변경점을 눈으로 일일이 대조하는 건 오래 걸릴 뿐 아니라 누락이 발생합니다.
특히 위험한 건 **"미세한 차이를 놓치는 것"**입니다. 계약서에서 "~할 수 있다"가 "~해야 한다"로 바뀌는 한 글자 차이, 설정 파일에서 true가 false로 바뀌는 것, 이런 작은 변경이 큰 문제를 만듭니다. 두 텍스트를 붙여넣으면 추가·삭제·수정된 부분을 색상으로 즉시 시각화해주는 도구가 필요했고, 글자 단위와 단어 단위 비교를 모두 지원하도록 만들었습니다.
a. 이런 상황에서 활용할 수 있습니다
- 코드 리뷰: Git 외부에서 두 버전의 소스 코드 차이를 빠르게 확인
- 계약서·법률 문서 검토: 원본과 수정본 사이의 조항 변경, 단어 교체 탐지
- 설정 파일 비교: 서버 설정, 환경 변수, config 파일의 변경 사항 추적
- 원고 퇴고 확인: 초고와 최종본 사이의 문장 구조 변화·오탈자 수정 내역 대조
- 데이터 유실 검사: 백업 파일과 현재 파일을 비교하여 누락된 항목 탐지
2. 도구 사용법 가이드
텍스트 입력값의 차이를 라인별로 정렬하고 추가된 부분(초록색), 삭제된 부분(빨간색), 수정된 부분(갈색)을 구분하여 표시합니다.

a. 텍스트 입력 및 파일 업로드
- 화면 상단의 두 입력 창에 원본(왼쪽)과 비교 대상(오른쪽) 텍스트를 각각 붙여넣습니다. 직접 타이핑하는 방법 외에도, 우측 상단의 파일 업로드 아이콘을 클릭하거나 드래그 앤 드롭으로 텍스트 파일(.txt, .md, .js 등)을 직접 불러올 수 있습니다.

b. 글자 및 단어 단위 비교 옵션 설정
- 결과 영역 상단에서 비교 알고리즘 방식을 선택합니다.
- 글자 단위 비교: 미세한 오탈자 확인이나 정밀한 문자열 차이 분석에 적합합니다.
- 단어 단위 비교: 문장 내 단어 배열 변화 파악에 적합하며, 일반 문서·블로그 글 비교에 추천합니다.
- 다른 부분만 보기: 동일한 줄을 숨기고 실제 변경이 발생한 행만 모아서 표시합니다.
c. 문서 유사도 계산 및 변경점 확인
- 두 텍스트를 입력하면 실시간으로 문서 유사도 퍼센트가 자동 계산됩니다. 결과 화면에서 각 줄의 컬러 바로 변경 유형을 확인합니다.
- 🔴 빨간색: 원본에서 삭제된 줄
- 🟢 초록색: 대상에 새로 추가된 줄
- 🟤 갈색: 수정된 줄 (변경된 단어가 하이라이트 처리)
3. 텍스트 비교의 핵심: Diff 알고리즘
텍스트 비교 도구의 핵심에는 Diff 알고리즘이 있습니다. "두 텍스트 사이의 최소한의 변경 사항을 찾는 것"이 이 알고리즘의 목표입니다.
a. Diff 알고리즘이란
Diff는 두 텍스트 시퀀스 사이의 **최장 공통 부분 수열(LCS, Longest Common Subsequence)**을 기반으로, 최소한의 편집 연산(추가, 삭제, 수정)으로 하나를 다른 하나로 변환하는 방법을 찾는 알고리즘입니다.
// 개념적 비유: 두 문장의 차이를 찾는 과정
const original = "오늘 날씨가 좋습니다";
const modified = "오늘 날씨가 매우 좋습니다";
// Diff 결과:
// "오늘 날씨가 " → 공통 (유지)
// "" → "매우 " (추가)
// "좋습니다" → 공통 (유지)
b. 비교 단위별 차이
| 비교 단위 | 장점 | 단점 | 적합한 상황 |
|---|---|---|---|
| 글자 단위 | 1글자 차이도 정밀하게 탐지 | 노이즈가 많을 수 있음 | 오탈자 검출, 설정값 변경 확인 |
| 단어 단위 | 의미 단위로 직관적 파악 | 1글자 차이가 단어 전체로 표시 | 문서 비교, 원고 퇴고, 코드 리뷰 |
| 줄 단위 | 전체 구조 변화 빠르게 파악 | 줄 내부 변경 상세 불가 | 대용량 파일, 로그 비교 |
c. 유사도 계산 방식
문서 유사도는 두 텍스트 간의 공통 부분과 전체 길이를 비교하여 산출합니다.
// 유사도 계산의 기본 원리
const similarity = (공통부분길이 * 2) / (텍스트A길이 + 텍스트B길이) * 100;
// 예시:
// 텍스트A: "안녕하세요 오늘 날씨가 좋습니다" (14자)
// 텍스트B: "안녕하세요 오늘 날씨가 매우 좋습니다" (17자)
// 공통부분: "안녕하세요 오늘 날씨가 " + "좋습니다" (12자)
// 유사도 ≈ (12 * 2) / (14 + 17) * 100 ≈ 77.4%
Note
유사도 100%는 두 텍스트가 완전히 동일함을 의미합니다. 일반적으로 90% 이상이면 미세한 수정, 50~90%면 상당한 변경, 50% 미만이면 거의 다른 문서로 판단할 수 있습니다.
4. 실무에서 텍스트 비교가 필요한 순간들
a. 코드 리뷰 및 버전 비교
Git을 사용하지 않는 환경이거나, 특정 두 버전의 코드를 빠르게 비교하고 싶을 때 활용합니다. 함수 로직 변경, 변수명 수정, 조건문 추가/삭제 등을 색상으로 즉시 파악할 수 있습니다.
// 원본 (왼쪽)
function getPrice(item) {
return item.price;
}
// 수정본 (오른쪽)
function getPrice(item) {
const discount = item.isMember ? 0.1 : 0;
return item.price * (1 - discount);
}
// → 2줄 추가(초록), 1줄 수정(갈색)으로 표시됨
b. 계약서·약관 변경 사항 추적
법률 문서에서 한 단어의 변경이 전혀 다른 의미를 만들 수 있습니다. "~할 수 있다"와 "~해야 한다"의 차이, 금액이나 날짜의 변경 등을 글자 단위 비교로 정밀하게 탐지합니다.
c. 서버 설정 파일 변경 추적
운영 서버의 설정 파일(nginx.conf, .env, docker-compose.yml 등)이 변경되었을 때, 백업본과 현재 파일을 비교하여 의도치 않은 변경이나 누락된 설정을 찾아냅니다.
# 원본 (.env 백업)
DATABASE_HOST=db.production.internal
MAX_CONNECTIONS=100
LOG_LEVEL=warn
# 현재 (.env)
DATABASE_HOST=db.staging.internal # ← 수정됨 (갈색)
MAX_CONNECTIONS=50 # ← 수정됨 (갈색)
LOG_LEVEL=warn
# DEBUG_MODE=true # ← 추가됨 (초록)
d. 번역 원문·역문 대조
영문 원본과 한글 번역본의 구조적 대응을 확인하거나, 번역 수정 전후를 비교할 때 활용합니다. 단락 수와 문장 배치가 일치하는지 빠르게 검증할 수 있습니다.
5. 텍스트 비교에서 실수하기 쉬운 부분들
"분명 같은 텍스트인데 차이가 있다고 나온다"는 상황이 자주 발생합니다.
a. 보이지 않는 공백 문자로 인한 false diff
원인: 눈에는 동일해 보이지만, 한쪽에 탭 문자가 있고 다른 쪽에 스페이스 4칸이 있으면 "다름"으로 판정됩니다. 줄 끝의 trailing space도 마찬가지입니다.
// ❌ 눈에는 같아 보이지만 diff에서 "다름"으로 표시
" indent" // 스페이스 4칸
"\tindent" // 탭 1개
// → 비교 결과: 수정됨(갈색)으로 표시
// ✅ 비교 전 공백을 통일하거나, 공백 무시 옵션 활용
// → 의미 있는 변경만 확인 가능
b. 줄바꿈 문자 차이 (CRLF vs LF)
원인: Windows에서 작성한 텍스트(\r\n)와 Mac/Linux에서 작성한 텍스트(\n)를 비교하면, 내용은 동일한데 모든 줄이 "다름"으로 표시될 수 있습니다.
// ❌ Windows 텍스트 vs Unix 텍스트
"첫째 줄\r\n둘째 줄" // Windows (CRLF)
"첫째 줄\n둘째 줄" // Unix (LF)
// → 눈에는 같지만 모든 줄이 "수정됨"으로 표시
// ✅ 비교 전 줄바꿈 문자를 통일
text.replace(/\r\n/g, '\n');
c. 복사·붙여넣기 시 서식 정보가 딸려오는 경우
원인: 웹페이지나 워드 문서에서 텍스트를 복사하면 보이지 않는 서식 문자(논브레이킹 스페이스, 특수 대시 등)가 함께 복사될 수 있습니다. 눈에는 같은 하이픈이지만 일반 하이픈(-)과 엠 대시(—)는 다른 문자입니다.
// ❌ 워드에서 복사한 텍스트
"2024–2025" // 엔 대시 (U+2013)
// ✅ 직접 타이핑한 텍스트
"2024-2025" // 일반 하이픈 (U+002D)
// → 눈에는 같지만 diff에서 "다름"으로 탐지됨
Important
"내용이 같은데 차이가 표시된다"면, 대부분 **보이지 않는 문자(공백, 줄바꿈, 특수 유니코드)**가 원인입니다. 글자 단위 비교 모드로 전환하면 정확히 어떤 문자가 다른지 확인할 수 있습니다.
d. 공통 패턴: 의도치 않은 diff 해결법
- 글자 단위로 전환하여 원인 확인 — 어떤 문자가 다른지 정밀하게 파악
- 공백·줄바꿈 정규화 후 재비교 — 공백 제거 도구로 전처리
- Plain text로 붙여넣기 — Ctrl+Shift+V로 서식 제거 후 붙여넣기
6. 생각해볼 거리
Git diff와 이 도구의 차이는 무엇인가요?
Git diff는 버전 관리 시스템에 커밋된 파일 간의 차이를 보여주는 도구로, 커밋 히스토리·브랜치 간 비교가 가능합니다. 반면 이 도구는 Git과 무관하게 임의의 두 텍스트를 즉시 비교할 수 있습니다. 클라이언트가 이메일로 보낸 수정 문서, 메모장에 적어둔 메모, 채팅으로 받은 코드 조각 등 Git 관리 밖의 텍스트를 비교할 때 이 도구가 유용합니다. 또한 터미널 명령어 없이 브라우저에서 시각적으로 확인할 수 있어 비개발자도 쉽게 사용할 수 있습니다.
"최소 편집 거리"는 어떻게 계산하나요?
최소 편집 거리(Levenshtein Distance)는 한 문자열을 다른 문자열로 바꾸기 위해 필요한 최소 삽입·삭제·치환 횟수입니다. 예를 들어 "kitten"을 "sitting"으로 바꾸려면 k→s(치환), e→i(치환), →g(삽입)으로 편집 거리 3입니다. 이 계산은 동적 프로그래밍(DP)으로 수행하며, 두 문자열 길이의 곱에 비례하는 시간 복잡도를 가집니다. 실제 diff 도구들은 이를 최적화한 Myers diff 알고리즘 등을 사용하여 효율적으로 차이를 계산합니다.
AI가 "의미적 차이"까지 비교해줄 수 있을까요?
현재의 diff 알고리즘은 문자열 수준의 차이만 탐지합니다. "사용자를 삭제한다"와 "유저를 제거한다"는 글자가 완전히 다르므로 100% 변경으로 표시되지만, 의미적으로는 동일한 내용입니다. AI 기반 시맨틱 diff는 이런 한계를 넘어 "문장의 뜻이 바뀌었는가"를 판단할 수 있지만, 아직은 연산 비용이 높고 정확도가 완벽하지 않습니다. 현실적으로는 문자열 diff로 변경 위치를 찾고, 의미 해석은 사람이 판단하는 조합이 가장 효율적입니다.
브라우저 탭 하나로 두 텍스트의 변경 사항을 색상별로 즉시 시각화할 수 있습니다 — 수백 줄을 눈으로 대조하며 미세한 차이를 놓칠 불안이 사라집니다. 그것만으로도 이 도구의 역할은 충분하다고 생각합니다.