설정 변경 전후에 어떤 값이 달라졌나요?

사용할 도구

• 도구 열기: JSON 구조 비교

두 입력은 같은 범위를 나타내나요?

비교 전에 각 입력의 시점, 환경, 범위를 확인하세요. 전체 설정과 부분 갱신을 비교하면 많은 삭제가 나올 수 있습니다. 비교기는 생략과 삭제를 추론하지 못합니다. 하위 트리를 추출한다면 양쪽의 같은 부모를 고르고 범위를 기록하세요.

API 응답에는 매번 바뀌는 시각이나 식별자도 있습니다. 차이 수를 줄이려고 지우지 말고 조사 질문에 포함되는 값인지 판단하세요. 시각 변동이 질문과 무관할 때만 제외합니다. 원본 작업 사본을 남기고 제외 항목과 이유를 기록하면 검증 범위를 설명할 수 있습니다.

공백에도 두 역할이 있습니다. 값 바깥 들여쓰기는 구조를 바꾸지 않지만 "test " 끝의 공백은 문자열 일부입니다. 수신 측의 trim 여부는 별개이므로 차이를 없애려 모두 trim하지 마세요. 숫자 표기 차이도 검출할 수 있습니다. 1과 1.0을 같은 금액으로 보는 것과 저장 표기가 같은지는 구별하세요.

설정이 바뀌지 않은 예제부터 비교하기

왼쪽에 변경 전, 오른쪽에 변경 후를 넣습니다. 다음 두 예제를 각각 붙여 넣으세요. 문자 순서는 다르지만 설정 세 개는 같습니다. 이 예제는 좌우를 바꿔도 같지만 실제 추가·삭제를 검토할 때는 방향을 일정하게 유지하세요.

{"timeout":30,"region":"test","enabled":true}

{"enabled":true,"region":"test","timeout":30}

실행하면 차이 합계는 0입니다. 값 바깥의 들여쓰기나 공백만 바꿔도 같습니다. 이는 구조 비교상 차이가 없다는 뜻이지 바이트까지 같다는 뜻은 아닙니다. 파일 해시는 다를 수 있습니다. 설정 검토와 파일 동일성 확인에는 다른 도구가 필요합니다.

값 하나를 바꾸고 변경 방향 읽기

{"enabled":true,"region":"test","timeout":60}

30에서 60으로 한 번 바뀝니다. before와 after로 방향을 확인하세요. 숫자의 내부 표현 때문에 결과 경로에 추가 단계가 나타날 수 있으므로 마지막 이름만 보지 말고 상위 timeout과 전후 값을 함께 읽으세요. 진단 경로가 원본에서 편집할 문자열과 항상 같지는 않습니다.

좌우를 바꾸면 60에서 30으로 바뀌고 추가·삭제도 반대가 됩니다. 사라진 항목을 찾으면서 버전을 반대로 넣으면 추가로 오해합니다. 결과를 전달할 때 좌우 버전도 명시하면 혼란이 줄어듭니다.

항목 없음과 null은 다릅니다

{"label":"demo","note":null}

{"label":"demo","memo":""}

note는 삭제되고 memo는 추가됩니다. 빈 문자열, null, 항목 없음은 화면에서 모두 빈칸처럼 보여도 다릅니다. 앱은 설정 생략 시 기본값을 쓰고 null이면 기능을 끌 수도 있습니다. 도구는 차이를 찾지만 의도에 맞는 동작을 결정하지는 못합니다.

true를 문자열 "true"로 바꾸는 것도 단순 표기 변경이 아닙니다. 차이가 적다고 안전한 이전은 아닙니다. 자료형 하나의 변경이 수십 줄 재배치보다 동작에 큰 영향을 줄 수 있습니다. 수신 앱의 해석이 중요합니다.

배열 앞에 하나 넣었는데 차이는 왜 많을까요?

{"steps":["build","test","deploy"]}

{"steps":["prepare","build","test","deploy"]}

배열 순서를 고려하면 같은 위치끼리 비교합니다. 0번 build가 prepare로, 1번 test가 build로, 2번 deploy가 test로 바뀌고 마지막에 deploy가 추가됩니다. 사람은 한 항목 삽입으로 보지만 위치 비교는 변경 세 개와 추가 하나를 보고합니다. 차이 네 개가 편집 네 번은 아닙니다.

이 도구는 id로 같은 상품이나 사용자를 자동 연결하는 레코드 비교기가 아닙니다. 많은 위치가 밀렸다면 앞부분의 삽입·삭제를 먼저 확인하세요. 인덱스를 고정 식별자로 보지 말고 원본의 ID와 주변 요소를 함께 살펴보세요.

순서를 무시하기 전에 의미부터 확인하기

{"tags":["blue","green"]}

{"tags":["green","blue"]}

순서 고려 시 변경 두 개, 무시 시 차이 0개입니다. 어떤 태그가 있는지만 볼 때는 유용합니다. 하지만 작업 순서나 우선순위 배열에서는 중요한 변경을 숨깁니다. 배포 전 테스트와 배포 후 테스트는 단어가 같아도 다른 작업입니다.

순서 무시는 중복 제거가 아닙니다. 같은 태그 두 개와 한 개는 여전히 다릅니다. 현재 옵션은 중첩 배열도 정렬하므로 바깥 순서만 무시하고 내부 절차는 유지할 수 없습니다. 배열이 여럿이면 순서를 고려한 결과를 먼저 보고 무순서 비교를 보조로 사용하세요.

차이 0개가 동작 보장은 아닙니다

같은 설정도 앱 버전, 환경 변수, 외부 파일이 다르면 동작이 달라집니다. 입력하지 않은 정보는 비교 범위 밖이며 차이 개수로 위험도를 평가하지도 않습니다. 선택한 조건에서 두 JSON이 어떻게 다른지라는 좁은 질문에 답하는 도구로 사용하세요.

검토를 마치기 전에 바뀐 값, 추가·삭제 항목, 배열 순서 무시 여부를 함께 기록하세요. 예상 밖 차이는 두 입력을 정렬해 해당 부분을 살펴봅니다. 필수 항목이나 자료형 검사까지 필요하면 지원 범위를 확인하고 JSON Schema 검증을 사용하세요. 차이 발견과 변경 승인 판단을 구분하면 검토가 명확해집니다.

참고 자료

• RFC 8259 — Objects and arrays (새 탭에서 열립니다)

사용할 도구

• JSON 구조 비교