모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.
왼쪽에 원본 텍스트, 오른쪽에 변경된 텍스트를 붙여 넣으세요. 단위는 코드나 산문에는 Line, 문단 수준의 산문에서 단어 교체를 보고 싶을 때는 Word, 짧은 문자열의 오타나 한 글자 설정 차이를 찾을 때는 Character로 고릅니다. 뷰는 Split(두 텍스트를 나란히 두고 삭제와 추가를 따로 색칠) 또는 Unified(`git diff`에서 익숙한 `+`/`-` 형식) 중에 선택합니다.
버전 관리에 올라 있지 않은 비교 대상에 사용하세요. 서로 같아 보이지만 숨겨진 문자 때문에 다른 두 로그 줄, 스테이징과 운영에서 받은 JSON 응답, 동료가 보낸 YAML 설정과 현재 가진 설정을 비교할 때 유용합니다. 차분 라이브러리(`jsdiff`)는 Myers 알고리즘을 브라우저 안에서 실행합니다. 업로드하지 않으므로 PII나 스테이징 시크릿이 든 로그도 기기 밖으로 나가지 않습니다. Git 저장소 안의 파일 비교는 터미널 `git diff`가 더 빠릅니다. 이 도구는 단발성 텍스트 대 텍스트 비교의 빈자리를 채웁니다.
Original: port: 8080 host: localhost retries: 3 Changed: port: 8080 host: localhost retries: 5 timeout: 30
port: 8080 host: localhost - retries: 3 + retries: 5 + timeout: 30
Line 단위가 기본이며 대부분의 코드 리뷰가 이 단위로 이루어집니다. 공통 줄은 그대로 두고, 변경된 줄은 변경 전·후를 나란히 보여 주며, 새 줄은 순수 추가로 나타납니다. YAML이나 JSON에서는 보통 이걸로 충분합니다.
Original: The quick brown fox jumps over the lazy dog. Changed: The quick brown fox jumped over the lazy dog.
The quick brown fox [jumps → jumped] over the lazy dog.
Line 단위에서는 문장 전체가 "변경됨"으로 표시되지만, Word 단위에서는 `jumps` → `jumped`만 강조되고 다른 단어는 그대로 남습니다. 원고 교정, 번역 비교, 릴리스 간 에러 메시지 수정 추적에 유용합니다.
Original: api.example.com Changed: api.exаmple.com
api.ex[a → а]mple.com (Cyrillic а, U+0430)
두 번째 `a`는 라틴 a(U+0061)가 아니라 키릴 а(U+0430)로, 전형적인 동형 공격 패턴입니다. Line·Word diff에서는 "문자열이 다릅니다"만 알려 줄 뿐 어디가 다른지 보이지 않습니다. Character 단위는 문제의 코드 포인트 하나만 분리하므로 실제로 무엇이 다른지 확인할 수 있습니다.
둘 다 거의 같은 알고리즘(Myers diff)을 쓰지만, `git diff`는 저장소 안에서 동작하며 파일 이력, 3-way 머지, 이름 변경 감지를 다루고 다른 곳에 적용 가능한 패치 파일을 출력합니다. 이 도구는 붙여 넣은 임의의 두 텍스트를 받아 브라우저 안에서 차분을 계산해 시각화할 뿐입니다. 버전 관리 중인 것은 `git diff`로, 저장소가 없는 단발 비교(로그·API 응답·두 통의 이메일 등)에는 이 도구를 쓰세요.
거의 항상 보이지 않는 문자입니다. 줄 끝 공백, 일반 공백 대신 들어간 비줄바꿈 공백(U+00A0), CRLF와 LF 줄바꿈 차이, 채팅에서 붙여 넣은 폭 0 결합자(U+200D) 등이 전형입니다. Character 단위로 전환하면 어떤 바이트가 다른지 정확히 보입니다. 산문이라면 둘 다 붙여 넣고 Character 모드에서 확인하는 편이 확실합니다.
이 도구에는 빌트인 토글이 없습니다. 줄 끝 공백을 무시하려면 입력을 먼저 정규화하세요. 각각을 별도 페인에 붙여 넣고 줄마다 `String.prototype.trim()`을 적용하거나 `sed 's/[ \t]*$//'`로 잘라 내세요. Python이나 YAML처럼 공백에 의미가 있는 포맷에서는 공백 차이가 보이는 편이 낫습니다. 산문 비교라면 Word 단위가 공백 잡음을 자연스럽게 가려 줍니다.
Myers의 차분 계산량은 O(N × D)로, N은 텍스트 총 길이, D는 편집 스크립트 크기입니다. 텍스트가 비슷할 때는 빠르고, 크게 다른 최악의 경우 이차가 됩니다. 99% 내용이 공통인 10000줄 파일 두 개의 차분은 즉시 끝나지만, 전혀 무관한 10000줄 파일 두 개를 붙이면 브라우저가 몇 초 멈출 수 있습니다. 매우 크거나 매우 다른 입력에는 스트리밍 CLI(`diff -u`·`delta` 등)를 쓰세요.
안 됩니다. 이 도구는 원시 텍스트 차분이라 같은 키를 다른 순서로 둔 JSON은 다른 것으로 표시됩니다. 두 입력을 JSON Formatter로 같은 정렬 규칙으로 정형하거나, CLI에서 `jq --sort-keys`를 거친 뒤 붙여 넣으세요. 구조적 차분 도구(`jd`·`dyff`·`deep-object-diff`)는 바이트가 아닌 타입을 이해하는 다른 레이어에 있습니다.
변경이 국소적일 때는 Split이 훑기 좋습니다. 시선이 좌우로 이동하고 변경되지 않은 컨텍스트가 닻처럼 남습니다. Unified는 밀도가 높고 많은 개발자가 익숙한 `git diff` 형식과 맞아서 결과를 채팅이나 문서에 복사하는 경우에 적합합니다. 한 화면을 넘는 변경에서는 Split이 시선을 잃기 쉽고 Unified가 이깁니다.
텍스트 차분은 한 문자열을 다른 문자열로 바꾸는 최단 편집 스크립트를 찾는 문제입니다. 주류 알고리즘인 **Myers diff**는 1986년에 발표되었고 `git diff`·`jsdiff`·현대 대부분의 차분 도구가 채택합니다. 문제를 그래프 탐색으로 정식화하며 계산량은 O(N × D). 텍스트가 비슷할 때는 빠르고 악조건에서는 이차가 됩니다. **Patience diff**(Bazaar와 `git diff --patience`에서 사용)는 고유 행을 먼저 정렬해 크게 편집된 파일에서도 가독성 좋은 출력을 만듭니다. **Histogram diff**(Git 2.0 이후 기본)는 동일 행 연속을 다루기 위해 Patience를 개선한 방식으로, 현대 개발자가 일상적으로 보는 형식입니다.
단위는 무엇을 1 단위로 셀지를 결정합니다. **줄 단위**는 각 줄을 불가분으로 다룹니다. 줄 경계가 구조와 일치하는 코드·설정에 잘 맞습니다. **단어 단위**는 공백으로 나누므로 단어 한 개의 교체로 문장 전체를 붉게 표시하고 싶지 않은 산문에 최적입니다. **문자 단위**는 바이트마다 비교해 줄·단어 단위로는 보이지 않는 비가시 문자 문제(CRLF와 LF, 비줄바꿈 공백, 동형 공격 등)를 드러냅니다.
인접한 개념이 3가지 있습니다. **구조 차분**(`jd`·`dyff`·`deep-object-diff`)은 입력을 JSON·YAML로 파싱해 트리를 비교하므로 키 순서 재배치는 변경으로 잡히지 않습니다 — 본질적으로 다른 작업입니다. **패치 파일**(`diff -u`의 `+`/`-` 텍스트 출력)은 사실상의 교환 형식이며 `patch` 같은 도구가 이를 적용해 변경 후 텍스트를 재현합니다. **3-way 머지**(`diff3`, Git의 브랜치 머지에서 사용)는 두 버전을 공통 조상과 대조해 충돌을 감지합니다. 이는 입력 2개짜리 뷰어의 범위 밖입니다. 이 도구는 그중 가장 단순한 자리에 있습니다. 텍스트 블롭 두 개를 받아 무엇이 바뀌었는지를 보여 줄 뿐입니다.
양쪽에 텍스트를 붙여넣으면 차이를 표시합니다.
