diff는 색이 아니라 우선순위로 읽힙니다.
diff 화면에서 초록색과 빨간색은 익숙한 표현입니다. 하지만 색만으로 변경의 의미가 전달되지는 않습니다. 사용자는 먼저 파일 전체가 얼마나 바뀌었는지 보고, 다음으로 실제 검토가 필요한 구간을 찾고, 마지막으로 줄 단위 변경을 읽습니다. 화면이 이 순서를 돕지 않으면 많은 색이 오히려 노이즈가 됩니다.
그래서 diff 도구는 변경량, 변경 위치, 변경 내용의 계층을 분리해서 보여줘야 합니다. 짧은 텍스트 비교에서는 한 화면 안에서 충분하지만, 긴 코드나 문서에서는 접기, 이동, 줄 번호, 컨텍스트 표시가 중요해집니다. 사용자가 처음부터 모든 줄을 읽게 만들면 작은 변경도 피곤한 작업이 됩니다.
Split과 Unified는 서로 다른 상황에 맞습니다.
Split View는 왼쪽과 오른쪽을 나란히 비교할 수 있어 변경 전후의 위치를 확인하기 좋습니다. 함수 이름, 문단 흐름, 설정 키처럼 줄 위치가 중요한 경우에 특히 유용합니다. 반면 Unified View는 변경만 이어서 볼 수 있어 화면 폭이 좁거나 모바일에서 읽기 편합니다.
한 가지 보기 방식만 제공하면 사용자의 문맥을 제한하게 됩니다. 코드 리뷰에서는 Split이 편한 순간이 있고, 문서 수정안에서는 Unified가 더 빠른 순간이 있습니다. Diff Viewer에서 두 모드를 전환할 수 있게 하는 이유도 이 때문입니다. 도구는 사용자의 현재 작업 방식에 맞춰 화면 밀도를 바꿀 수 있어야 합니다.
공백 변경은 때로 중요하고 때로 방해가 됩니다.
공백은 diff에서 까다로운 요소입니다. 들여쓰기 수정, 줄 끝 공백 제거, 빈 줄 정리는 실제 의미를 바꾸지 않는 경우가 많습니다. 하지만 YAML, Markdown, 일부 코드 포맷에서는 공백이 구조를 바꾸기도 합니다. 따라서 공백을 항상 무시하거나 항상 강조하는 방식은 충분하지 않습니다.
좋은 비교 도구는 공백을 볼지 말지 사용자가 선택할 수 있게 해야 합니다. 처음에는 의미 있는 변경을 빨리 찾기 위해 공백을 무시하고, 검토가 필요할 때 다시 켜서 정확한 줄 차이를 확인하는 흐름이 자연스럽습니다. 옵션은 많지 않아도 되지만, 변경을 해석하는 데 필요한 선택지는 있어야 합니다.
긴 변경 구간에서는 길을 잃지 않게 해야 합니다.
작은 변경은 줄 색상만으로 충분하지만, 수백 줄의 변경에서는 현재 위치를 놓치기 쉽습니다. 이때 필요한 것은 더 화려한 장식이 아니라 기준점입니다. 줄 번호, 변경 블록 간격, 섹션 제목, 이전/다음 변경 이동 같은 요소가 사용자의 방향 감각을 유지해 줍니다.
특히 리뷰어는 모든 변경을 같은 깊이로 읽지 않습니다. 먼저 큰 구조를 훑고, 위험한 구간을 찾고, 필요한 줄만 자세히 봅니다. diff 도구가 이 스캔 과정을 지원하면 검토 시간이 줄어듭니다. 반대로 모든 줄을 같은 강도로 보여주면 실제로 중요한 변경이 묻힐 수 있습니다.
붙여넣기 도구도 결과를 설명해야 합니다.
간단한 웹 diff 도구는 사용자가 두 텍스트를 붙여 넣고 결과를 확인하는 구조가 많습니다. 이때 “변경 없음”, “왼쪽만 있음”, “오른쪽만 있음” 같은 빈 상태 안내가 중요합니다. 결과가 비어 있을 때 그것이 정상인지, 입력이 잘못된 것인지 알 수 있어야 하기 때문입니다.
Diff Viewer는 복잡한 협업 플랫폼을 대체하려는 도구가 아닙니다. 짧은 코드 조각, 문서 수정안, 설정 파일 변경을 빠르게 비교하는 데 초점을 둡니다. 이 목적에서는 빠른 입력, 명확한 강조, 보기 전환, 공백 옵션이 핵심입니다. 작은 도구일수록 “무엇을 하지 않을지”가 분명해야 사용자가 기대를 정확히 맞출 수 있습니다.