JSON 차이 비교
두 JSON 문서를 비교하여 추가・삭제・변경된 키를 키 경로 단위로 한눈에 확인할 수 있습니다. 객체와 배열을 재귀적으로 탐색하며, 타입이 다른 경우도 변경으로 표시됩니다. 모든 처리는 브라우저 내에서 완결되며 서버로 전송되지 않습니다.
팁
- 키 경로는 `user.address[0].city`와 같은 점・대괄호 표기법으로 표시되므로, JSON 구조가 아무리 깊어도 어느 계층의 값이 바뀌었는지 즉시 파악할 수 있습니다.
- 배열은 같은 인덱스끼리 대응시켜 비교합니다. 배열 요소의 순서만 바뀌어도 모든 요소가 변경된 것으로 감지된다는 점에 주의하세요.
- 같은 키가 한쪽에서는 문자열, 다른 쪽에서는 객체처럼 타입 자체가 다른 경우에도 변경으로 감지되며, 양쪽의 원시 값이 그대로 표시됩니다.
- 배포 전후의 API 응답을 비교할 때는 타임스탬프나 요청 ID처럼 매번 달라지는 필드를 미리 제거하면, 실제로 확인해야 할 차이에만 집중할 수 있습니다.
- 변경되지 않은 값이 매우 많은 JSON이라도 일치하는 리프(leaf)의 개수만 집계해 표시하므로, 결과가 지나치게 길어지지 않고 파악하기 쉽습니다.
자주 묻는 질문
여담 ― CSV 차이 비교와 JSON 차이 비교, 키 대응 방식의 차이
본 사이트의 CSV 차이 비교 도구（dev.csv.csv_diff）는 행을 식별하는 키 열을 하나 지정해 행・셀 단위로 비교하는 방식이었습니다. JSON은 행과 열이라는 평면 구조를 갖지 않고 객체의 중첩과 배열이라는 계층 구조를 허용하기 때문에, 같은 "차이 비교"라도 비교 알고리즘의 설계가 크게 다릅니다. 이 도구는 키 열이라는 개념 대신, 루트에서 리프까지 재귀적으로 따라가는 "키 경로"를 비교 단위로 사용합니다.
JSON 차이 감지에서 특히 까다로운 부분이 배열 처리입니다. CSV의 행은 키 열의 값으로 고유하게 식별할 수 있지만, JSON 배열 요소에는 식별자가 보장되지 않습니다. 이 도구는 단순히 인덱스（출현 순서）로 대응시키는 방식을 채택했으며, 이는 배열 내용이 추가・삭제되는 상황보다 객체 구조나 원시 값의 변화를 추적하고 싶은 상황（설정 파일이나 API 응답 비교 등）에 더 적합한 설계입니다.
실무에서는 REST API의 응답 사양이 변경되지 않았는지 지속적 통합（CI）에서 자동으로 점검하는 용도에도 비슷한 발상이 사용됩니다. 이 도구는 브라우저에서 완결되는 간편함을 중시하지만, 그 사고방식 자체는 스냅샷 테스트나 계약 테스트（Contract Testing）와 공통되며, JSON 구조의 차이를 기계적으로 감지한다는 과제는 개발의 다양한 단계에서 반복적으로 등장합니다.