Diff 체커

두 텍스트나 코드를 줄 단위와 단어 단위 하이라이트로 비교합니다. 나란히 보기 또는 통합 보기, 공백 무시, 대소문자 무시 — 모두 브라우저 안에서 처리됩니다.

아니요. 도구 전체는 이 페이지 안에서 실행되는 JavaScript입니다. diff 알고리즘(LCS, 최장 공통 부분 수열)은 사용자의 CPU에서 실행되며 결과는 곧바로 DOM에 렌더링됩니다. DevTools → Network를 열어 두고 확인해 보시면 diff 처리 중에 어떠한 요청도 발생하지 않습니다. 내부 코드, 고객 데이터, 계약서 초안 등 서버 도구에 기록되기를 원치 않는 어떤 내용이든 안심하고 붙여넣으실 수 있습니다.

먼저 두 입력을 줄 단위로 분리하고 LCS(최장 공통 부분 수열) 알고리즘을 실행합니다. 양쪽에서 모두 일치하는 줄은 동일한 줄로 표시됩니다. 일치하지 않는 줄은 추가 옆에 삭제가 나타날 때 '변경(change)' 행으로 짝지어집니다. 짝지어진 각 변경에 대해 줄 안의 단어(공백 기준 분리)에 다시 한 번 LCS를 실행하므로, 줄 전체가 아니라 실제로 편집된 단어만 빨강·초록으로 강조됩니다.

원본

수정본

공백 무시 대소문자 무시

iKit Diff 체커를 선택해야 하는 이유

광고, 팝업, 외부 트래커가 없는 깔끔하고 빠른 텍스트 diff 환경입니다. 개발자, 작가, 그리고 변경 사항을 빠르게 찾아야 하는 모든 분을 위해 만들어졌습니다.

나란히 보기 + 통합 보기

분할 보기(두 칼럼, 전형적인 IDE 느낌)와 통합 보기(한 칼럼에 +/− 마커 표시)를 한 번의 클릭으로 전환할 수 있습니다. 두 보기 모두 줄 번호를 표시하고 변경 사항을 인라인으로 강조합니다.

단어 단위 하이라이트

두 줄이 변경되면 두 번째 단어 단위 diff를 실행해 실제로 다른 부분만 강조 표시합니다. 줄 전체가 아니라 변경된 단어만 빛나므로 200자짜리 줄에서 오타 하나도 쉽게 찾을 수 있습니다.

공백 무시 + 대소문자 무시

공백과 대소문자 옵션을 켜고 꺼서 외형적인 변경(들여쓰기 재정렬, 대소문자 변경)을 걸러내고 실제 편집에만 집중할 수 있습니다.

설계 단계부터 프라이버시

두 텍스트는 모두 브라우저 탭 안에 머무릅니다. diff 알고리즘은 JavaScript로 로컬에서 실행되며, DevTools → Network에서 확인할 수 있듯이 입력하는 동안 어떠한 요청도 발생하지 않습니다.

통계 + 복사

추가, 삭제, 수정된 줄 수를 한눈에 확인할 수 있습니다. 한 번의 클릭으로 diff를 클립보드에 복사해 코드 리뷰나 커밋 메시지에 바로 붙여넣을 수 있습니다.

오프라인에서도 작동

페이지가 한 번 로드된 뒤에는 모든 처리가 로컬에서 이루어집니다. 비행기 안, 회사 방화벽 뒤, 또는 네트워크가 전혀 없는 환경에서도 동작하므로 기밀 코드 리뷰에 유용합니다.

diff 체커는 실제로 어떻게 동작할까요

그 뒤에 숨은 수학은 웹보다도 오래되었습니다. 1965년에 등장한 LCS 알고리즘과 1986년 Eugene Myers가 개선한 알고리즘이 그 핵심입니다.

1

줄 단위로 분리

두 입력은 \n(또는 \r\n)을 기준으로 나누어집니다. 각 줄이 하나의 토큰이 됩니다. 실제 코드나 문서에서 일어나는 대부분의 편집이 줄 단위로 추가·삭제·수정되기 때문에, 문자 단위가 아닌 토큰 단위로 비교합니다.
2

LCS 계산

최장 공통 부분 수열은 두 입력에 같은 순서로 등장하는 줄들의 가장 큰 집합입니다. 오른쪽 아래에서부터 거슬러 올라가며 DP 표를 채우고, 각 셀에는 그 위치에서 끝까지의 LCS 길이가 저장됩니다. 시간과 메모리 모두 O(m × n)이 소요됩니다.
3

역추적으로 편집 연산 도출

표의 왼쪽 위에서 시작해 앞으로 진행합니다. 현재 양쪽 줄이 일치하면 equal을, 그렇지 않으면 LCS 길이를 유지하는 방향(오른쪽 또는 아래)을 골라 delete 또는 insert를 출력합니다. 그 결과로 원본을 수정본으로 바꾸는 연산의 시퀀스가 만들어집니다.
4

변경된 짝 안의 단어 단위 diff

삭제 다음에 삽입이 이어지면 두 줄을 하나의 변경 행으로 묶습니다. 줄 안에서 실제로 다른 부분만 강조하기 위해, 공백을 기준으로 나눈 각 줄의 단어들에 같은 LCS 알고리즘을 한 번 더 실행합니다.

흔한 diff 작업

diff 체커가 실제로 필요해지는 상황들입니다.

코멘트를 달기 전 PR 검토

GitHub의 diff 화면도 훌륭하지만, 때로는 포매터가 만든 잡음 없이 실질적인 변경만 보고 싶을 때가 있습니다. 두 버전을 붙여넣고 공백 무시를 켜면 외형적인 재정렬은 사라지고 로직 변경만 남습니다.

두 계약서 초안 비교

법무 담당자나 운영 팀은 종종 계약서 v1과 v2 사이의 변경 사항을 알아야 합니다. 두 문서를 붙여넣으면 단어 단위 하이라이트가 적용된 색상 diff를 즉시 확인할 수 있습니다. Word도, 변경 내용 추적도, 외부 서버에 기밀 조항을 업로드할 필요도 없습니다.

스크립트 편집이 무엇을 바꿨는지 확인

설정 파일에 sed, awk, 또는 Python regex를 적용하셨나요? 원본과 결과를 여기에 붙여넣어 스크립트가 의도한 부분만 수정했는지 확인하실 수 있습니다. 문자 단위 하이라이트가 빠르게 훑어보면 놓치기 쉬운 의도치 않은 편집까지 잡아냅니다.

번역된 텍스트의 오타 찾기

번역 쌍(원문 대 번역, 또는 같은 원문에 대한 두 번역)을 비교할 때 단어 단위 diff를 사용하면 빠진 단어, 중복된 표현, 교정자가 놓친 문장 부호 변경을 손쉽게 찾을 수 있습니다.

왜 로컬 diff가 중요한가요

비교하려는 텍스트는 대개 비공개입니다. 내부 저장소의 코드, 계약서 초안, 고객 데이터 내보내기, 출시 전 제품 카피 등이 그렇습니다. 그것들을 모르는 서버에 붙여넣는 순간 사용자가 통제할 수 없는 기록이 남습니다. iKit의 diff 체커는 이미 브라우저 탭에 로드되어 있는 JavaScript이며, 비교는 사용자의 CPU에서 실행될 뿐 네트워크 소켓을 거치지 않습니다.

diff 처리 중 네트워크 요청이 전혀 발생하지 않으며, DevTools → Network에서 직접 확인하실 수 있습니다.
입력은 브라우저 메모리에만 머물고, 지우기를 누르거나 페이지를 새로 고치면 함께 사라집니다.
내부 코드, NDA가 적용된 문서, 고객 지원 기록, 데이터 거주성 정책의 적용을 받는 모든 자료에 안전하게 사용하실 수 있습니다.

Related guides

Deep-dive tutorials and tool comparisons from the iKit blog.

자주 묻는 질문

안전한가요? 입력한 텍스트가 업로드되나요?

줄 단위와 단어 단위 하이라이트는 어떻게 동작하나요?

분할 보기와 통합 보기의 차이는 무엇인가요?

분할 보기는 두 텍스트를 짝지어진 줄 번호와 함께 나란히 보여 줍니다. IDE(VS Code, JetBrains)에서 보던 diff 모습과 비슷합니다. 통합 보기는 한 칼럼에 +/− 접두사가 붙은 줄로 표시되며 `git diff` 출력과 비슷합니다. 작업 흐름에 맞는 쪽을 선택하시면 되며, 두 보기 모두 동일한 데이터를 보여 줍니다.

'공백 무시' 기능은 왜 도움이 되나요?

코드 재정렬(Prettier 실행, 탭/스페이스 전환, 줄 끝 정규화)은 시각적 잡음을 만들어 실제 변경 사항을 가립니다. '공백 무시'를 켜면 diff 처리 전에 연속된 공백이나 탭이 한 칸으로 줄어들고 줄 양 끝의 공백이 정리되므로, 외형적인 변화가 아닌 의미 있는 편집만 보이게 됩니다.

브라우저에서 비교할 수 있는 입력 크기 한계는 어떻게 되나요?

LCS 알고리즘은 양쪽 줄 수 m, n에 대해 O(m × n)의 메모리를 사용합니다. iKit는 비교를 약 400만 셀(약 16 MB)로 제한하므로 양쪽 모두 수천 줄 수준은 무리 없이 처리할 수 있습니다. 그보다 큰 diff(전체 데이터베이스 덤프, 전체 파일 로그 등)는 `diff`나 `git diff --no-index` 같은 CLI 도구를 사용하시는 것이 좋습니다. 이들은 수백만 줄까지 확장되는 더 영리한 알고리즘(Myers diff)을 사용합니다.