Rust 기반 콘텐츠 인식 diff 도구 OmniDiff의 성능과 활용법

함수의 위치만 옮겼는데 리뷰 화면에는 삭제와 추가가 길게 늘어서고, 이미지 변경은 파일이 달라졌다는 한 줄로 끝나기도 합니다. 이럴 때는 변경된 줄 수보다 무엇이 바뀌었는지를 빨리 파악하는 편이 중요합니다.

Rust로 만든 OmniDiff는 코드의 구문 구조를 비교하고, 이미지·폰트·PDF에는 각 형식에 맞는 비교 방식을 적용합니다. 공식 문서와 공개 데모를 바탕으로, 기존 Git 작업 흐름에서 어떻게 활용할 수 있는지 살펴보겠습니다. ¹

OmniDiff의 핵심 기술: Rust 기반 구조 인식과 비텍스트 파일 지원

코드 비교의 구조적 인식 OmniDiff는 C, C++, Go, Python, Rust, TypeScript 등 총 25개 언어의 소스 코드를 Tree-sitter 파서를 통해 구문 트리로 파싱합니다 ², ¹. 여기서 핵심적인 기술은 APTED(Advanced Post-order Traversal Edit Distance) 트리 diff 알고리즘의 효율적인 구현입니다 ³. 기존의 텍스트 기반 diff가 이동된 코드를 '삭제 후 삽입'으로 인식하는 반면, OmniDiff는 구문 트리의 구조적 변화를 분석하여 코드가 실제로 이동(Moved)된 것을 식별할 수 있습니다 ³.

소스 코드의 언어는 확장자로 감지합니다. 반면 비텍스트 파일은 이름이 아닌 실제 바이트로 형식을 식별합니다. 두 경로를 구분해야 지원 범위를 정확하게 이해할 수 있습니다. ¹

비텍스트 파일의 콘텐츠 단위 분석 텍스트 코드를 제외한 바이너리 파일에 대해서는 콘텐츠의 특성에 맞춰 다음과 같이 비교합니다 ², ¹, ⁴.

• 이미지: PNG, JPEG, GIF 등 이미지를 픽셀 단위로 비교합니다. 특히 애니메이션 GIF의 경우 프레임 수의 증가(예: 5개에서 7개로 증가)나 프레임별 변경 사항을 구체적으로 보고합니다 ², ⁴.
• 폰트: TrueType, OpenType, WOFF2 등의 폰트 파일에서 글리프를 렌더링하여 특정 아이콘(예: U+0021)의 픽셀 변경률과 메트릭 변화를 추적합니다 ¹, ⁴.
• 아카이브: ZIP, JAR, EPUB, Office 문서(ODT) 등 컨테이너 형식의 파일 내부 구조를 열어 변경된 구성 요소만 추출하여 분석합니다. 중첩된 압축 파일도 구성 요소별로 비교합니다 ², ⁴.
• PDF: 페이지를 렌더링하여 시각적인 변경 사항을 식별하며, 메타데이터 변경과 페이지 렌더링 차이를 구분하여 기록합니다 ², ⁴.

실측 성능 벤치마크: 처리 속도와 정밀도

아래 수치는 프로젝트 개발자가 공개한 측정 결과입니다. 이 글에서 별도로 성능을 재측정한 것은 아닙니다. 비교 대상과 데이터셋이 달라지면 결과도 달라집니다.

Hacker News 토론에서 개발자는 Difftastic과 공통으로 지원하는 코드 사례의 비교 수치를 공유했습니다. 이 데이터에 따르면 OmniDiff의 중앙값(p50) 처리 속도는 4ms로, Difftastic의 35ms보다 약 8배 이상 빠릅니다 ³.

Difftastic과 지원 범위가 겹치는 코드 변경 사항에 한해 비교할 경우, OmniDiff는 사람이 판단한 기준과 '완벽하게 일치(perfect)'하는 비율이 90%로, Difftastic의 64%보다 높은 정밀도를 보였습니다 ³.

위 90%는 Difftastic과 지원 범위가 겹치는 비교에 한정된 수치입니다. GeekNews에 정리된 별도의 전체 코드 정확도 평가에서는 --minimal 기준 완전 일치율이 69.6%로 제시됩니다. 두 수치를 같은 평가 결과로 읽으면 안 됩니다. ²

현재의 오차는 매칭 알고리즘 자체보다는 화면에 변경 사항을 어떻게 강조 표시할지에 대한 렌더링 규칙에서 주로 발생하고 있습니다 ².

개발자 워크플로우 통합: TUI, CLI 및 에디터 연동

OmniDiff는 대화형 터미널 UI(TUI)와 스크립트용 일반 텍스트 출력을 모두 지원하여 다양한 개발 환경에 유연하게 적용할 수 있습니다.

버전 관리 시스템(Git, Jujutsu) 연동 대화형 Git 뷰어는 omnidiff git configure로 설정한 뒤 git difftool로 엽니다. GIT_EXTERNAL_DIFF=omnidiff git diff는 일반 텍스트 출력용 연동입니다 ², ¹. 단순히 git diff를 입력할 경우 페이저 환경에서는 대화형 TUI가 실행되지 않고 일반 텍스트 모드(headless mode)로 결과가 출력됩니다 ², ¹. Jujutsu(jj)의 경우 전용 설정 마법사를 통해 파일별 호출(file-by-file) 모드로 구성하여 언어 감지 기능을 온전히 사용할 수 있습니다 ², ¹.

설치 후 두 파일을 직접 비교하거나, Git 설정 마법사를 실행할 수 있습니다. 마법사에서 현재 저장소와 전역 적용 범위를 선택합니다. ¹

omnidiff BEFORE AFTER
omnidiff git configure
git difftool

출력 형식 및 리뷰 도구

• 터미널 뷰어(TUI): 밝은 테마와 어두운 테마를 지원하며, 24비트 색상이나 터미널 그래픽 프로토콜(kitty, sixel 등)을 통해 이미지를 실제 이미지 형태로 화면에 출력합니다 ², ¹.
• 자동화/스크립트: --headless는 일반 텍스트를 출력하며, 표준 출력이 터미널이 아닐 때도 이 모드로 전환됩니다. JSON 출력은 별도로 omnidiff --mode json BEFORE AFTER를 사용합니다 ², ¹.
• 브라우저 리뷰: 아직 v0.0.0 단계의 초기 버전인 codereview 프로젝트를 통해 웹 브라우저 환경에서의 변경 사항 리뷰도 가능합니다 ², ¹.

에디터 플러그인 VS Code 및 Neovim용 플러그인(omnidiff-vscode, omnidiff.nvim)이 제공되며, Open VSX를 통해 Cursor나 VSCodium 등에서도 설치 및 사용이 가능합니다 ², ¹.

OmniDiff의 기술적 제한과 프로젝트 현황

콘텐츠를 비교하는 뷰어와 병합 충돌을 해결하는 도구는 구분해야 합니다. 가장 대표적인 과제는 3방향 병합(3-way merge)을 지원하지 않는다는 점입니다. APTED 알고리즘은 기본적으로 2방향 비교에 최적화되어 있어 병합 충돌(conflict) 해소를 위한 3방향 diff 기능은 개발자가 앞으로 해결하고 싶다고 밝힌 과제입니다 ³. README에서는 개발 속도를 유지하기 위해 현재 외부 기여를 받지 않는다고 설명합니다 ², ¹. 개발 과정에서는 AI 에이전트(Claude Code)를 활용했으며, AGPL-3.0-only 라이선스를 채택하고 있습니다 ², ¹. 먼저 공개 데모에서 자신이 자주 보는 변경 유형을 살펴보고, 익숙한 파일 두 개로 결과를 비교해 보는 편이 좋겠습니다. 코드 이동이나 이미지·폰트 변경이 잦은 저장소라면 일반적인 줄 단위 비교와 어떤 차이가 나는지 확인하기 쉽습니다.