두 JSON 문서를 (코드에 쓰는 것과 같은) 일반 텍스트 diff로 비교하면 결과가 종종 오해를 불러일으킵니다: 같은 데이터라도 키 순서, 들여쓰기, 공백 개수가 다르게 쓰일 수 있는데, 이때 텍스트 diff는 실제로는 동일한 데이터에 대해 "차이"를 보여줍니다.
구조적 비교
구조적 JSON Diff는 두 문서를 값의 트리로 파싱하고 실제 데이터를 비교합니다: 필드가 존재하는지, 어떤 값을 담고 있는지, 타입이 일치하는지. 객체의 키 순서, 불필요한 공백, 들여쓰기 스타일은 여기서 고려되지 않습니다 — 이들은 데이터 자체의 일부가 아니기 때문입니다.
diff가 보여주는 것
일반적인 구조적 비교 결과는 세 가지 유형의 변경 사항을 강조합니다: 두 번째 문서에서 추가된 필드, 첫 번째 문서에서 제거된 필드, 양쪽에 모두 존재하지만 값이 다른 필드. 배열의 경우 비교가 더 복잡합니다 — 요소를 위치로 비교할지, 비슷한 객체끼리 매칭을 시도할지 결정해야 합니다.
왜 필요한가
- 백엔드 변경 전후의 API 응답을 비교해 데이터의 실제 변화를 확인할 때.
- 설정 파일의 변경이 의도치 않은 부분을 건드리지 않았는지 확인할 때.
- 예상 JSON과 실제 JSON이 다른 테스트에서 회귀를 찾아낼 때.
ko.json이 en.json보다 키가 적은 게 정상인 이유
한국어 문법은 명사의 수에 따라 형태가 바뀌지 않습니다 — "책 1권"이든 "책 5권"이든 "책"이라는 단어 자체는 그대로입니다. 그래서 CLDR 복수형 규칙에서 한국어는 단 하나의 카테고리("other")만 가지는 반면, 영어는 "one"과 "other" 두 가지를 가집니다. react-i18next 같은 라이브러리로 관리되는 en.json에 item_one과 item_other 두 키가 있어도 ko.json에는 대응하는 키가 하나만 있는 것이 정상이며, 구조적 diff에서 이를 "누락된 키"로 착각하지 않는 것이 중요합니다.
배열 비교: 위치 기준인가, 키 기준인가
가장 단순한 방식은 배열 요소를 인덱스 대 인덱스로 비교하는 것이지만, 배열 중간에 새 요소가 삽입되면 이후의 모든 위치가 "밀려나면서" diff는 삽입 지점 이후의 모든 요소가 변경된 것처럼 표시합니다 — 실제로는 하나의 요소만 바뀌었는데도 그렇습니다. 더 정교한 도구는 id처럼 고유한 필드로 요소를 매칭해, 잘못된 변경의 연쇄가 아니라 실제 삽입이나 삭제만 정확히 보여주려 합니다.