텍스트 비교

A text diff takes two snapshots of the same content — an "old" version and a "new" version — and renders the differences between them so a human can verify what changed. It does not understand the meaning of the text; it operates strictly on lines (or characters), marking which ones are present in one side but not the other. That neutrality is its biggest strength: anything that can be written down as text can be diffed the same way, whether it is documentation, configuration, prompts for an LLM, copy for a marketing page, or a transcript of a chat.

Why eyeballing two versions side by side is not enough

Manual comparison breaks down once the documents are more than a few dozen lines, or once the edits include reordered sections, deleted blocks, or whitespace cleanup. The eye is good at noticing wording differences in adjacent lines and very bad at noticing a missing line in the middle of a long block. A diff tool levels the field by marking every line that is not present on both sides, so you stop trusting your peripheral attention and start trusting a checklist.

How a line-based diff decides what "changed" means

A line-based diff treats each line as an atomic unit. It looks for the longest sequence of lines that appears in both sides in the same relative order, calls that the unchanged backbone, and reports everything else as additions or removals. That is why two visually similar files can produce very different diffs: small changes in line structure can shift what the algorithm treats as the common backbone.

• A line that exists on both sides at corresponding positions is unchanged.
• A line that exists only on the right (new) side is an addition.
• A line that exists only on the left (old) side is a removal.
• A "modified" line is conceptually one removal plus one addition placed next to each other — the algorithm does not have a special "change" verb of its own.
• Reordering one block to another position usually shows up as a delete in one place plus an add in another — not as a move.

Rule of thumb: a diff tells you what the algorithm believes changed line-by-line. It cannot tell you whether the change is meaningful — that is still your job.

이 도구 사용 방법

1. Prepare representative two versions of plain text, config fragments, notes, or generated output in 텍스트 비교 instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate a visible diff showing added and removed lines, and review line breaks, whitespace-only changes, reordered sections, and whether the diff should be reviewed as text rather than structured data before deciding the result is ready.
3. Only copy or download the result after it fits copy review, release-note checks, config comparisons, prompt revisions, and support-ticket evidence and no longer conflicts with this constraint: For structured formats such as JSON, use the matching structured diff tool when key-level changes matter.

텍스트 비교 예시

이 예시는 텍스트 비교가 처리하도록 설계된 대표 입력 형태와, 자신의 작업 흐름에 복사하기 전에 기대할 수 있는 결과 모양을 보여 줍니다.

예시 입력

Before: timeout=30
After: timeout=45

예상 출력

- timeout=30
+ timeout=45

A copy edit, shown as a line-level diff

# old
Welcome to the launch.
Doors open at 6 PM.
Please bring a printed invitation.
Refreshments will be served.

# new
Welcome to the product launch.
Doors open at 6:30 PM.
Refreshments and drinks will be served.

# diff
- Welcome to the launch.
+ Welcome to the product launch.
- Doors open at 6 PM.
+ Doors open at 6:30 PM.
- Please bring a printed invitation.
- Refreshments will be served.
+ Refreshments and drinks will be served.

Notice that "removed: please bring a printed invitation" is an isolated delete — there is no matching addition. The diff highlights it precisely because that single line is easy to miss visually.

Where a text diff is the right tool

Text diff is at its best when the content does not have to follow a strict structure but still needs careful review. The list below is where a quick paste-and-compare almost always saves time.

• Reviewing a copy edit on a landing page, email, or press release where every word matters.
• Confirming a colleague's edits in a config file or environment template before merging.
• Comparing two prompts (or two prompt revisions) for an LLM to understand why outputs differ.
• Verifying that a search-and-replace really only touched the intended occurrences, not their neighbours.
• Auditing what changed between two versions of a transcript, meeting note, or audit log.

Pitfalls that make a diff misleading

A diff is only as useful as the input you give it. The most common cause of a confusing diff is not a bug in the algorithm but a mismatch between what you wanted to compare and what the tool actually compared.

• Trailing whitespace and invisible characters: lines that look identical can differ by a single space or a BOM and show up as changed.
• Different line endings: CRLF (Windows) vs LF (Unix) will mark every line as changed if the tool does not normalise them.
• Reflowed paragraphs: when an editor wraps long lines into shorter ones, a line diff explodes even though the wording is identical.
• Encoding differences: UTF-8 vs UTF-8 with BOM, or different normalisation forms for accented characters, can cause silent mismatches.
• Comparing a fragment against a full document: if you accidentally include or exclude a header, the entire backbone shifts and the diff becomes unreadable.

Text diff vs other comparison strategies

실무 참고

• 텍스트 비교는 기본적으로 브라우저 안에서 처리되므로 별도 도구 체인을 준비하지 않고도 빠르게 로컬 확인을 할 수 있습니다.
• 실제 입력이 크거나 민감하거나 업무상 중요하다면, 먼저 대표 샘플로 시험하세요.
• 운영, 고객 노출, 법무, 재무, 안전과 관련된 작업에 사용하기 전에는 최종 결과를 다시 확인하세요.

텍스트 비교 참고 정보

텍스트 비교는 입력 정리, 반복 가능한 변환, 게시 준비가 된 출력을 설명합니다.

• 긴 텍스트를 처리하기 전에 공백, 줄바꿈, 문장 부호, 보이지 않는 문자를 확인하세요.
• 중요한 문구를 바꾸기, 정렬, 중복 제거, 비교할 때는 먼저 작은 샘플로 규칙을 테스트하세요.
• 생성된 slug, HTML 또는 비교 결과는 게시 전에 검토하세요.

참고 자료

• Unicode Standard Annex #15: Unicode Normalization Forms
• MDN: String