JSON은 원래 사람이 읽기 어려운 형식은 아니다
JSON은 키와 값으로 이루어진 객체, 그리고 값의 묶음인 배열을 중심으로 만든 텍스트 형식이다.
예를 들어 설정 파일 몇 줄, API 응답 일부, 짧은 데이터 한 묶음 정도라면 JSON은 꽤 읽기 편하다.
- 어떤 키가 있는지 보인다
- 배열 안에 무엇이 들어 있는지 감이 온다
- 중첩이 깊지 않으면 눈으로도 따라갈 수 있다
문제는 JSON 자체보다 크기와 깊이다.
짧은 JSON은 사람이 바로 읽을 수 있지만, 수만 줄을 넘기거나 배열 안에 객체가 반복되고 그 안에 또 배열이 들어가면 이야기가 달라진다.
JSON이 커지는 순간 읽는 일이 갑자기 불편해진다
처음에는 그냥 검색하면 되겠다고 생각한다.
하지만 실제로 큰 JSON을 다뤄 보면, 필요한 값 하나를 찾는 일과 그 값이 어디에 들어 있는지 이해하는 일은 전혀 다른 문제라는 걸 금방 느끼게 된다.
예를 들어 이런 상황이 자주 생긴다.
- 같은 키 이름이 여러 군데 반복된다
- 검색 결과는 찾았는데 어느 객체 안에 있는 값인지 헷갈린다
- 배열이 너무 커서 앞뒤 문맥을 따라가기 어렵다
- 응답 일부만 보면 맞는 것 같은데, 실제로는 상위 구조 해석이 틀려 있다
결국 큰 JSON에서는 "찾기"만으로는 부족하고, "구조를 따라가며 확인하기"가 같이 되어야 한다.
보통은 익숙한 도구부터 먼저 시도하게 된다
브라우저나 DevTools에서 바로 본다
API 응답이라면 제일 먼저 브라우저 개발자 도구나 기본 JSON 보기 화면을 열게 된다.
짧은 응답에서는 충분히 괜찮다. 예쁘게 접히고, 기본 검색도 되고, 복사도 쉽다.
하지만 응답이 커지면 스크롤이 길어지고, 접고 펼치는 동작만으로도 어디를 보고 있는지 잃기 쉽다. 검색 결과를 찾더라도 그 값이 전체 구조에서 어디에 놓여 있는지 파악하기가 금방 번거로워진다.
VS Code 같은 편집기로 연다
그다음 많이 하는 시도는 편집기로 여는 것이다.
전역 검색, 접기, 다중 선택, 포맷팅 같은 기능이 있어서 처음에는 더 나아 보인다. 실제로 몇 MB 안쪽의 JSON은 이 방식으로도 충분히 처리할 수 있다.
하지만 파일이 커지면 메모리를 많이 쓰거나, 포맷팅과 하이라이팅이 느려지거나, 검색은 되는데 구조를 따라가기가 여전히 어렵다. 결국 "텍스트 에디터로 큰 구조체를 읽고 있다"는 한계가 그대로 남는다.
jq 같은 CLI 도구로 잘라 본다
터미널에 익숙하면 jq를 쓴다.
이 방식은 아주 강력하다. 정확한 경로를 알고 있거나, 어떤 필드만 뽑아야 하는지가 분명할 때는 특히 빠르다.
다만 처음 구조를 파악하는 단계에서는 오히려 진입 장벽이 있다. 어디를 잘라야 하는지 모르는 상태에서는 필터를 먼저 쓰기가 어렵고, 탐색보다는 추출에 더 가깝기 때문이다.
jless 같은 전용 뷰어도 찾게 된다
조금 더 찾아보면 jless 같은 터미널용 JSON 뷰어도 나온다.
이런 도구는 jq보다 브라우징에 가깝고, 일반 텍스트 뷰어보다 구조 탐색에는 더 잘 맞는다.
문제는 여기서도 분명하다. 전용 도구가 아예 없는 것은 아니지만, 대부분은 명령줄에 익숙해야 하거나 설치가 필요하고, 일반 사용자가 바로 쓰기 편한 방식은 아니다.
그래서 별도의 전용 도구가 마땅치 않다는 느낌을 받게 된다
거대한 JSON을 다룰 때 사람들이 느끼는 불편은 대체로 비슷하다.
- 기본 브라우저 화면은 빠르게 보기에는 괜찮지만 오래 탐색하기에는 불편하다
- 편집기는 익숙하지만 큰 구조를 읽는 데 최적화되어 있지는 않다
- CLI 도구는 강력하지만 구조를 처음 파악하는 단계에서는 부담이 있다
즉 도구가 전혀 없는 것은 아니다. 다만 "큰 JSON을 열고, 구조를 따라가고, 검색하고, 필요한 값만 확인하는 흐름"을 한 번에 편하게 맡길 만한 도구는 의외로 드물다.
그래서 보통은 이렇게 나눠서 본다
큰 JSON을 다룰 때는 하나의 도구로 모든 걸 해결하려 하기보다, 목적에 따라 작업을 나누는 편이 빠르다.
먼저 하는 일은 구조 파악이다
처음부터 전체 내용을 읽으려 하지 않는다.
보통은 아래처럼 본다.
- 최상위가 객체인지 배열인지 확인한다
- 반복되는 배열 이름이 무엇인지 본다
- 관심 있는 값이 어느 레벨에 있을지 감을 잡는다
- 중첩 깊이가 어느 정도인지 확인한다
이 단계에서는 "정답 값을 뽑는 것"보다 "어디를 봐야 하는지 아는 것"이 더 중요하다.
그다음은 검색이다
구조 감이 잡히면 필요한 키나 값을 검색한다.
다만 큰 JSON에서는 검색 결과만 바로 믿기보다, 그 결과가 어느 객체 안에 있고 주변에 어떤 필드가 붙어 있는지 같이 봐야 한다. 같은 키가 여러 곳에 반복될 수 있기 때문이다.
마지막은 추출과 비교다
구조를 이해한 뒤에는 jq 같은 도구나 별도 처리 코드로 필요한 값만 뽑아내는 방식이 잘 맞는다.
즉 큰 JSON에서는 보통 아래 순서가 자연스럽다.
- 구조를 본다
- 검색한다
- 필요한 값만 추출한다
- 여러 객체를 비교한다
API 응답 분석도 결국 같은 문제다
이 흐름은 파일 분석에만 쓰이지 않는다.
개발자가 아니더라도 광고 도구, 백오피스, 운영 화면, 로그 응답처럼 JSON 결과를 확인해야 하는 순간이 있다. 이때도 핵심은 같다.
응답 전체를 다 읽는 것이 아니라, 구조를 빨리 파악하고, 필요한 필드가 어디 있는지 찾고, 그 값을 기준으로 다음 작업을 이어가는 것이다.
그래서 중간에 탐색용 도구가 하나 있으면 편하다
큰 JSON을 다룰 때는 보통 편집기나 CLI 도구만으로 끝내기보다, 중간에 구조를 훑고 필요한 값을 찾아보는 단계가 한 번 들어간다.
특히 아래 같은 상황에서는 이런 단계가 꽤 도움이 된다.
- 파일이 너무 커서 일반 에디터로 읽기 피곤할 때
- API 응답에서 같은 키가 여러 번 반복될 때
- 특정 값이 어느 배열과 객체 안에 속하는지 같이 봐야 할 때
- 추출용 스크립트를 짜기 전에 구조부터 먼저 이해하고 싶을 때
필요한 것이 "가공"보다 "탐색"에 가깝다면, 이런 중간 단계 도구가 생각보다 시간을 많이 줄여 준다.
관련 글
같은 맥락에서 이어서 읽기 좋은 글들입니다.