짧은 답
- JSON 포매터를 열고, 첫 파일을 붙여 넣고, 들여쓰기를 두 칸으로 두고, 모든 객체의 키 정렬에 체크하세요. 결과를 복사합니다.
- 텍스트 비교를 열고 왼쪽 상자에 붙여 넣으세요.
- 두 번째 파일도 같은 과정을 거쳐, 오른쪽 상자에.
이제 켜지는 것은 진짜입니다. 바뀐 값, 새로 생긴 키, 사라진 항목. 보통의 diff를 익사시켰을 서식 차이와 순서 바뀐 키들은 사라졌습니다. 비교가 시작되기 전에 양쪽이 같은 철자로 쓰여 있었으니까요.
두 페이지 모두 네트워크 기능이 아예 없다는 것도 알아 둘 만합니다. 사람들이 비교하는 JSON은 그토록 자주, 자격 증명이 아직 든 설정 파일이니까요.
날것의 JSON diff는 왜 거의 잡음뿐인가
JSON은 공백에 무심하고, 키 순서에 의미를 주지 않습니다. 같은 문서가 한 줄일 수도 사백 줄일 수도 있고, 키는 친 순서대로일 수도 어느 라이브러리가 내뱉은 순서일 수도 있습니다. 도구들은 묻지 않고 둘 다 다시 씁니다. 한쪽은 압축, 한쪽은 펼침. 한쪽은 손으로 저장, 다른 쪽은 알파벳순으로 정렬하는 직렬화기로. 줄 단위 diff에게는 남남인 두 파일로 보입니다.
최악의 두 경우가 요점을 보여 줍니다. 압축된 파일은 한 줄이라, 그에 대한 diff는 거대한 바뀐 줄 하나입니다. 맞는 말이지만 쓸모없죠. 그리고 같은 내용이 다른 순서로 든 두 파일은 전부-바뀜으로 비교되는데, 정직한 답은 “아무것도”일 것입니다.
포매터의 표준형이 고치는 것
두 파일을 같은 설정의 같은 포매터에 통과시키는 것이 diff에게 꼭 필요한 것입니다. 문서마다 철자 하나.
- 같은 들여쓰기는 키마다 제 줄을 줍니다. diff는 줄 단위로 일하게 되고, 단어 표시는 한 줄 안에서 바뀐 그 값 하나를 짚을 수 있습니다.
- 정렬된 키는 양쪽을 같은 순서로 세워, 순서가 차이이기를 그만두게 합니다. 정렬은 코드 포인트가 아니라 키가 읽히는 방식을 따르고 —
item2가item10보다 앞 — 양쪽에 똑같이 적용됩니다. - 그 밖에는 아무것도 움직이지 않습니다. 이 포매터는 숫자를 쓴 그대로의 자릿수로 두고, 중복 키도 해소하는 대신 보존합니다. 표준형 만들기가 스스로 차이를 지어낼 수 없다는 뜻입니다. 포매터 가이드가 그것이 왜 마땅한 것보다 드문지 설명합니다.
정직한 단서 하나: 정렬된 출력은 키가 옮겨진 문서입니다. 하류의 도구가 키 순서를 따진다면 — 드물지만 존재합니다 — 정렬된 사본은 비교되는 대상으로 취급하고, 원본의 대체물로 삼지는 마세요.
결과 읽기, 그리고 가져가기
비교는 지워진 줄을 왼쪽에, 더해진 줄을 오른쪽에 표시하고, 바뀐 줄 안에서는 다른 단어를 강조합니다. 표준형 위에서라면 대개 false에서 true로 옮겨 간 그 값 하나입니다. 바뀌지 않은 가운데는 개수로 접혀서, 이천 줄짜리 설정에 손질이 세 군데면 짧은 대목 셋으로 읽힙니다.
내려받는 것은 통합 패치, .patch입니다. 코드 리뷰가 이해하는 그 포맷이죠. 표준형들을 기술하는데, 리뷰가 어차피 원하는 것도 대개 그것입니다. 재서식 없이, 변경만.
같은 요리법이 두 페이지가 할 줄 아는 다른 모든 것에도 통합니다. YAML과 XML도 같은 길로 표준형이 되고, 출처가 다른 같은 꼴의 두 파일이라면 비교의 무시 스위치들 — 공백, 대소문자, 빈 줄 — 이 같은 발상의 가벼운 판입니다.
매주 이 일을 한다면
두 번 정렬하고 두 번 붙여 넣기. 단계들이 두 페이지에 사는 것은 페이지마다 일 하나씩을 하고, 각자가 붙여 넣은 무엇도 어디로도 가지 않았음을 스스로 증명할 수 있기 때문입니다. 하지만 둘 다 오픈 소스입니다. MIT 라이선스, 의존성 없는 ES 모듈 — 포매터의 파서는 키 순서와 자릿수를 지키고, diff는 마이어스 알고리즘 — 각자 설명해 주는 README와 함께.
이것이 일상의 일부라면, 코딩 에이전트를 저장소로 보내, 비교하면서 표준형으로 만드는 두 상자짜리 페이지를 부탁하세요. parseJson, printJson, compareText는 임포트 세 줄 거리입니다. 모듈들은 읽히기 위해 쓰였고, 들어내 가는 것이야말로 라이선스가 있는 이유입니다.