JSON 트리 뷰 vs 테이블 뷰: 어느 쪽이 디버깅을 더 빠르게 해 줄까

대부분의 JSON 뷰어는 트리 뷰(중첩되고 접을 수 있으며 한 줄에 값 하나)와 테이블 뷰(행과 열, 스프레드시트 스타일) 중 하나를 선택하게 해 줍니다. 같은 데이터에 씌운 두 가지 스킨처럼 보이기 때문에 도구가 기본으로 여는 쪽을 그냥 쓰고 싶어지죠. 그건 잘못된 직감입니다. 두 뷰는 실제로 서로 다른 데이터 형태와 서로 다른 디버깅 작업에 최적화되어 있고, 작업에 맞지 않는 뷰를 고르면 실제로 시간을 낭비하게 됩니다.

각 뷰가 실제로 잘하는 것

트리 뷰는 JSON의 실제 구조를 그대로 반영합니다. 모든 객체와 배열은 접을 수 있는 노드이고, 모든 말단 값은 키 옆 한 줄에 놓입니다. 다음과 같을 때 올바른 선택입니다.

• 구조 자체가 디버깅 대상일 때 — 깊게 중첩된 객체 안에서 어떤 값이 어디에 있는지 찾거나, 필드가 존재하는지 자체를 확인하려는 경우.
• 데이터가 불규칙할 때 — 같은 응답 안의 객체들이 서로 다른 키 집합, 선택적 필드, 제각각인 중첩 깊이를 가진 경우. 테이블은 이를 깔끔하게 표현할 수 없지만 트리는 할 수 있습니다.
• 특정 객체가 어느 배열에 속하는지 추적하는 것처럼, 부모-자식 관계를 명시적으로 봐야 할 때.

테이블 뷰는 객체 배열을 키마다 열 하나씩, 행과 열로 평탄화합니다. 다음과 같을 때 유리합니다.

• 균일한 객체 배열이 있을 때 — 모두 같은 형태를 공유하는 사용자, 주문, 로그 항목 목록.
• 이상값을 훑어 찾을 때 — 숫자를 기대한 자리의 null, enum 값의 오타, 딱 한 행에만 빠진 필드. 테이블에서는 눈으로 열을 위에서 아래로 훑을 수 있어 이상값이 시각적으로 확 드러나지만, 트리는 같은 이상값을 수십 개의 따로 펼쳐야 하는 노드 속에 파묻어 버립니다.
• 정렬하거나 어느 행들이 같은 값을 공유하는지 눈대중하는 등, 스프레드시트에 가까운 사고 모델을 원할 때.

잘못 골랐을 때의 구체적인 실패 양상

깊게 중첩된 API 응답(세션 객체 안의 사용자 객체 안의 인증 토큰)을 테이블 뷰로 열면, 대부분의 셀이 그저 [Object]나 [Array]라고 적힌 테이블을 보게 됩니다. 평탄화가 중첩 구조를 놓을 자리가 없어서 쓸모없는 자리표시자로 뭉개 버리고, 결국 하나하나 클릭해 들어가야 하니 처음부터 트리 뷰로 시작하는 것보다 명백히 나쁩니다.

거의 동일한 로그 항목 200개짜리 배열을 트리 뷰로 열면, status가 예상외로 null인 딱 한 행을 찾기 위해 200개의 노드를 하나씩 펼쳐야 합니다. 테이블에서라면 2초면 끝날 훑기가 트리에서는 몇 분짜리 클릭 노동이 됩니다.

간단한 경험칙

먼저 한 가지만 물어보세요. 흥미로운 차이가 형제들 사이에 있는가, 아니면 깊이 방향에 있는가?

• 비슷한 항목 여러 개를 서로 비교하고 있다면(형제 방향) — 테이블 뷰를 쓰세요.
• 값 하나를 중첩 구조 속으로 따라 내려가고 있다면(깊이 방향) — 트리 뷰를 쓰세요.

들여쓰기 확인, 괄호 짝 맞추기, 후행 쉼표 찾기처럼 데이터가 읽기 좋고 문법적으로 유효하기만 하면 되는 일상적인 JSON 디버깅이라면, 어느 뷰도 꼭 필요하지 않습니다. 제대로 들여쓰기된, 보기 좋게 출력된 원본 JSON(JSON 포매터가 만들어 주는 것)만으로도 대부분의 빠른 확인에 충분할 만큼 구조가 명확히 드러나고, 뷰어를 특정 모드로 전환하는 것보다 도달도 빠릅니다. 트리 뷰나 테이블 뷰는 데이터가 위에서 아래로 그냥 읽기에는 너무 크거나 너무 중첩됐을 때 꺼내 드세요.