검토하기 전에 JSON 포맷 및 검사하기

압축된 JSON은 기계를 위한 것입니다. 한 줄, 들여쓰기 없음, 키 순서는 직렬화기 마음. 그 벽을 눈으로 검토하게 하면 삭제된 권한, 뒤집힌 플래그, 예상치 못한 엔드포인트가 빠져나갑니다.

포맷터는 당신이 가진 가장 저렴한 유효성 검사이기도 합니다. 파싱에 실패하는 문서는 프로덕션에서도 제대로 동작하지 않았을 것이고, 그 사실을 배포 로그가 아니라 검토 탭에서 알게 되는 편이 훨씬 낫습니다.

• 가독성만포맷은 가독성 변환입니다. 공백과 줄 바꿈만 바꿀 뿐 데이터는 절대 바꾸지 않으므로, 포맷된 사본은 항상 원본과 안전하게 대조할 수 있습니다.
• 깊이가 신호일관된 들여쓰기는 중첩 깊이를 한눈에 드러냅니다. 설정 실수는 깊이에 숨는 법이고, 한 단계 깊게 놓인 옵션은 그냥 무시됩니다.
• 기대하는 형태로 배포검토는 포맷된 사본으로 하되, 배포는 시스템이 기대하는 형태로 하세요. 보기 좋은 인쇄는 사람을 위한 것이지 전송을 위한 것이 아닙니다.

트리 뷰는 리뷰어가 실제로 던지는 질문에 답합니다. 어떤 키가 있는지, 각 값의 타입은 무엇인지, 구조가 얼마나 깊은지. 괄호를 세지 않고서요. 날것의 텍스트는 어느 하나도 빨리 답하지 못합니다.

JSON Tree Viewer는 명시적으로 파싱합니다. Parse JSON을 누르기 전에는 아무것도 렌더링되지 않고, 잘못된 입력에는 조용한 실패 대신 위치가 표시된 오류와 수정 힌트가 돌아옵니다. 결과는 노드별 타입과 개수가 있는 펼칠 수 있는 트리로 열리고, Formatted 탭에는 선택한 들여쓰기로 정규화된 문서가 표시됩니다.

파싱 요약은 노드 수와 최대 깊이를 보고해 페이로드가 가져야 할 규모와 빠르게 대조할 수 있게 합니다. 예약된 프로토타입 키는 거부되므로, 악의적인 페이로드가 검사하는 동안 무해한 척할 수 없습니다.

트리는 리뷰 대화도 평평하게 합니다. “items의 세 번째 요소의 price가 null”이라는 코멘트는 누구나 몇 초 만에 검증할 수 있지만, 압축된 줄의 바이트 오프셋은 그렇지 않습니다.

키 순서가 바뀌는 순간, 눈으로 두 JSON을 비교하는 것은 실패합니다. 구조적 diff는 양쪽을 파싱해 실제로 바뀐 것—추가, 삭제, 수정된 값—을 순서나 공백과 무관하게 보고합니다.

Text & JSON Diff는 줄, 문자, JSON 세 가지 모드를 제공합니다. 리뷰에서 결정적인 것은 JSON 모드입니다. 두 문서가 파싱된 뒤 값 단위로 비교되므로, 재정렬된 키와 재포맷된 공백은 올바르게 동일하다고 보고됩니다.

JSON이 아닌 텍스트의 경우 줄과 문자 모드에 공백 무시와 줄 끝 정규화 토글이 있고, 요약은 추가, 삭제, 변경을 셉니다. 페이로드와 설정에는 JSON 모드를 쓰고, 한쪽이 아예 유효한 JSON이 아닐 때는 줄 모드로 돌아가세요.

결정성은 편의 이상의 의미가 있습니다. 두 리뷰어가 같은 비교를 실행하면 같은 답이 나와야 합니다. 그렇지 않으면 리뷰는 변경에 대한 결정이 아니라 도구에 대한 협상이 됩니다.

이것들은 명시적 상한이 있는 로컬 런타임으로, 대량 데이터 처리가 아니라 리뷰 페이로드용 크기입니다. 상한을 알면 데스크톱 도구로 바꿔야 할 시점을 알 수 있습니다.

상한이 있는 이유는 파싱과 diff가 당신이 읽고 있는 바로 그 탭에서 실행되기 때문입니다. 정직한 상한이 멈춘 페이지보다 낫고, 작업 공간은 초과를 조용한 절단이 아니라 명시적 오류로 보고합니다.

• 뷰어 상한JSON Tree Viewer는 최대 256KiB 입력, 40단계 중첩, 10,000노드까지 받습니다. API 응답이나 설정 파일에는 충분하고도 남습니다.
• diff 상한Text & JSON Diff는 한쪽당 256KiB까지 비교하고 최대 10,000개의 차이 레코드를 보고한 뒤, 그 이상이면 비교가 너무 복잡하다고 선언합니다.
• 브라우저 밖더 큰 내보내기—데이터베이스 덤프, 로그 아카이브, 생성된 픽스처—는 브라우저 탭이 아니라 데스크톱 편집기나 명령줄 도구의 영역입니다.

대부분의 페이로드 문제가 프로덕션에 닿기 전에 잡아내는 짧은 루틴입니다.

실제 페이로드뿐 아니라 생산자의 샘플 데이터에도 체크리스트를 돌려 보세요. 현실과 어긋나는 픽스처는 버그만큼 확실하게 리뷰를 무효화합니다.

• 파싱먼저 포맷하고 파싱하세요: 문서가 유효한지 확인하고 노드 수와 깊이가 기대와 맞는지 훑어봅니다.
• 검사트리를 검사하세요: 리프의 타입을 확인합니다. 숫자 식별자가 문자열로 도착하는 것은 전형적인 통합 버그입니다.
• diff마지막으로 알려진 정상 버전과 JSON 모드로 diff하고, 보고된 변경을 모두 읽은 뒤 승인하세요.

검토 페이로드에는 고객 레코드, 토큰, 내부 URL이 들어 있는 경우가 많습니다. 로컬 뷰어는 그 자료를 탭 안에 둡니다. 텍스트는 당신의 기기에서 실행되는 코드가 파싱하며, 작업의 일부로 전송되는 일이 없습니다.

이 경계가 있기에 리뷰 중 실제 스테이징 페이로드로 이 도구들을 쓸 수 있습니다. 그렇다고 당신의 의무가 사라지는 것은 아닙니다. 내보낸 파일, 클립보드 내용, 트리의 스크린샷은 작업 공간을 떠난 뒤에도 신중히 다뤄야 할 것들입니다.

리뷰에서 페이로드 일부를 공유해야 한다면 문제를 보여 주는 최소 발췌만 붙여 넣고 식별자는 먼저 가리세요. 지원 채널이 요구하는 것과 같은 수칙입니다.